读数据掩护：工作负载的可恢复性16Docker与Kubernetes

1. 混淆云平台里的数据

1.1. 许多盘算环境采用的都是混淆云(hybrid cloud)模子，这种模子会把得当放在云端处理的任务移动到云端，同时把那些得当在本地处理的任务留在数据中心
1.2. NFS/SMB网关

• 1.2.1. 最经典的混淆云产品，就是那种通常称为云网关(cloud gateway)的东西
  
• 1.2.2. 让应用步调与用户去使用数据中心里的某台装备，该装备看上去好像跟其他装备一样，但实际上，此装备会将数据生存到云端（而不是生存在本地的数据中心里）
  
• 1.2.3. 比力常见的云网关是NFS或SMB服务器，由于它把数据生存到云端，因此在存储容量方面不受限制
  
• 1.2.4. 网关装备是否仅充当云端的缓存
  
  
  
  • 1.2.4.1. 要看云平台在整个存储方案里的地位
    
  • 1.2.4.2. 如果本地装备会把需要生存的所有数据都发往云端，那么这个装备就仅是一个缓存
    
  • 1.2.4.3. 不需要担心如何备份这些缓存数据，要考虑的只是云端的数据副本，至于那些数据副本是否需要备份，则要看它们是如何受到掩护的
    
  • 1.2.4.4. 如果云端只是整个存储体系里的一层，那就完全是另一回事了
    
  • 1.2.4.5. 有一些数据是生存在本地的，而且这些数据只出现在你的本地装备里面，因此，你必须像备份数据中心里的其他数据那样来备份这些数据
    
  
  
• 1.2.5. 网关装备是否具有版本管理机制
  
• 1.2.6. 网关装备自身的存储计谋
  
  
  
  • 1.2.6.1. 如果网关装备会把现在的所有数据（也就是现在每一个文件的最新版本）都生存到本装备里，那么意味着这些数据都会在云端留有一个备份副本（也就是备用的副本）​，而本地装备里生存的这个副本则是我们的主要副本
    
  • 1.2.6.2. 如果网关装备只会生存生动的文件（比方说，只会生存在过去30年内使用的文件）​，那就是另一码事了
    
  • 1.2.6.3. 不生动的文件只会生存在云端（那些文件在本地装备里是没有副本的）​，因此，你必须按照上一条所说的来考虑云端文件的备份方案
    
  
  
• 1.2.7. 网关装备是否将数据复制到多个云平台
  
  
  
  • 1.2.7.1. 如果你能将每个文件的所有版本都分别在AWS S3与Azure Blob上生存一份，那么从数据掩护的角度来看，就很难挑出毛病了，在启用WORM特性之后，这种方案会更加可靠
    
  • 1.2.7.2. WORM特性对某些对象存储体系来说是相当重要的
    

    1.2.7.2.1. 该特性能够防止入侵者或本构造的雇员恶意删除整个账号中的内容
    

    1.2.7.2.2. 如果不启用此特性，那么他们只需要敲几下键盘就能把数据全删掉
    

    1.2.7.2.3. 启用WORM特性之后，就连你自己都没办法在保留期还未到时删除数据，至于那些想要破坏数据的人，自然也就同样无法删除数据了
    

    
    
  
  

1.3. 云盒

• 1.3.1. cloud in a box，也称盒中云
  
• 1.3.2. 可以从云提供商那边租借这样的硬件装备，把它放在你的数据中心里面，并在其中运行云提供商的某些服务或全部服务
  
• 1.3.3. 由于这种装备只不外是把云提供商所提供的那套服务搬到你这里来运行，因此备份云端数据时所遵循的那套原则现在依然需要服从，而且其中有些资源可能需要掩护得比云端更加精密
  
• 1.3.4. 安装了云盒装备的数据中心，也会作为一个availability zone出现在可选名单中
  

2. Docker与Kubernetes

2.1. 容器与编排器（orchestrator，也叫协调器）​
2.2. Docker与Kubernetes给传统的备份与恢复流程所带来的变化，比从前好长一段时间里发生的变化都要大
2.3. 容器就是一个轻量级的假造机

• 2.3.1. 通常只具备某一种功能
  
• 2.3.2. Docker是一个容器运行时环境(container runtime environment)
  
  
  
  • 2.3.2.1. 负责在运行于Docker中的这些容器与Docker所处的这台主机上的操作体系之间对接（这个操作体系通常是Linux体系）​
    
  • 2.3.2.2. Docker所在的主机运行的基本上都是Linux体系
    
  • 2.3.2.3. 它只需要负责把自己应该具备的功能呈现出来
    
  
  
• 2.3.3. 假造机专门运行在某种特定的假造机管理器里，而假造机管理器又专门运行在某一套特定的硬件之上，与假造机相比，容器要灵活得多
  
• 2.3.4. 容器可以运行在任何一种Linux体系上，如果安装了适当的软件，那么它也能运行在Windows体系上
  
• 2.3.5. 容器的存在时间远比假造机短暂
  
  
  
  • 2.3.5.1. 一般的假造机可能会运行几个月以致几年时间
    
  • 2.3.5.2. 大多数容器的存留时间都不会超过一星期
    
  
  

2.4. Kubernetes

• 2.4.1. 在生产环境中运行大量容器是需要做出编排的，这也正是Kubernetes派上用场的地方（Kubernetes通常简写为K8s）​
  
• 2.4.2. K8s能够为容器分组，让它们形成多个pod，这些pod之间很容易沟通，而且能够共用某个已经挂载的卷
  
• 2.4.3. K8s pod通常称为逻辑主机(logical host)，这种逻辑主机跟假造机有点像，其中所容纳的一个或多个容器，就相当于假造机里运行着的某条线程
  
• 2.4.4. 在Kubernetes里界说应用步调的时候，你需要指定构成该步调的各种资源，还需要指定初始化、访问及烧毁这些资源所需的设置信息
  
• 2.4.5. Kubernetes总是运行在集群里，容器也总是能够按照需要来创建并烧毁
  

2.5. 从数据掩护的角度来看，Docker与Kubernetes真是让人又喜好又讨厌

• 2.5.1. 讨厌的地方在于，每出现一种新产品，我们的数据备份工作就有可能变得更加复杂
  
• 2.5.2. Kubernetes确着实数据掩护领域取得了一些重要突破
  

3. 容器如何改变传统的备份方式

3.1. 在假造化技术出现之前，我们是通过给服务器里放置agent来做备份的
3.2. 在假造机管理器这一层面来运行agent，并令其将假造机作为镜像加以备份
3.3. 到了容器时代，这两种模式都不管用了
3.4. 对于容器来说，现在还没办法将agent放在容器运行时（例如Docker）这一层运行
3.5. 不要把可用性与恢复能力混为一谈

• 3.5.1. 可用性高，并不意味着遇到灾难之后的恢复能力也比力高
  
• 3.5.2. 容器的基础办法，其每一部分都已经内置了相应的机制，以确保高可用性(high availability)
  

3.6. 除了DR（灾难恢复）​，你还需要确保自己能够重制整个环境，例如能够从测试/开发环境移动到生产环境（也就是正式环境）​，或者从生产环境移动到升级之前的staging环境（预备环境/过渡环境）​
3.7. 运行在K8s集群里的应用步调可能也需要备份，以便处理用户错误及软件bug，并与相干的法律法规符合
3.8. 无论你选用什么样的备份方案，都必须保证有待掩护的数据确实全都得到了掩护
4. Dockerfile

4.1. Docker容器需要根据镜像运行，而镜像则需要根据Dockerfile构建

• 4.1.1. 通过Docker image history命令，根据当前的镜像创建一个Dockerfile出来
  

4.2. 如果你想设置一套合理的Docker工作环境，那么首先应该考虑用GitHub这样的代码仓库来做版本管理体系，以控制所有的Dockerfile

• 4.2.1. GitHub，它提供了许多种方式，让你能够备份其中的库
  
• 4.2.2. 可以使用第三方的收费工具来备份GitHub
  

4.3. 应该先把所有的Dockerfile都存放到代码仓库里，这样的话，如果当前构建的这一版有题目，那你就可以把这个Dockerfile过去的版本pull（拉取/提取）出来，并根据那一版去构建
4.4. 即便是第三方的Docker镜像，也应该这样管理，因为那些镜像的制作者未必会保留以往的版本
4.5. 如果你需要回滚到某个旧的版本，那么在自己管控这些镜像的场所里操作起来会更加方便
4.6. 与每个K8s deployment有关的YAML文件也应该纳入代码库

• 4.6.1. 属于文本文件，把它们纳入版本控制体系是有好处的
  

4.7. Docker镜像

• 4.7.1. 你运行容器所依据的那些镜像也应该生存在某个库里
  

5. Kubernetes etcd

5.1. Kubernetes的etcd设置数据库相当重要
5.2. 把这个数据库备份下来，能够帮助我们对整个集群做元数据恢复(metadata recovery)，因为它既生存了集群的状态，还生存了设置信息
5.3. 通过etcdctl snapshot save snapshot.db命令来备份
6. 持久卷

6.1. 容器可以通过各种方式来访问用于存放或创建数据的持久存储
6.2. 传统的方案是Docker卷，它是以Docker环境中的子目次情势存在的
6.3. 从备份的角度看，传统的卷与刚说的bind mount在本质上是一样的
6.4. 持久卷(persistent volume)的备份方式取决于你在容器里面是怎样使用它们的
6.5. 持久卷里的数据可能在不断地变化，你必须办理好这一点，才能创建出application-consistent镜像

• 6.5.1. 一种办理办法是把使用这个卷的容器全都停掉
  
  
  
  • 6.5.1.1. 虽然有点老派，但绝对管用
    
  • 6.5.1.2. 把容器关停之后，你就可以备份这个卷了
    
  • 6.5.1.3. 如果这是一个传统的Docker卷，那就在开始备份时把它挂载到别的一个不会改变该卷数据的容器，然后，你可以在一个以bind mount情势挂载的卷里给你要备份的卷创建tar镜像，末了，你可以用你的备份体系所支持的办法来备份这个bind mount
    
  
  
• 6.5.2. CSI（容器存储接口）
  
  
  
  • 6.5.2.1. CSI的好处在于，它是一种标准的插件，让K8s管理员能够通过这套标准的API来申请存储空间，同时又允许每个存储提供商采用不同的方式来实现这套API
    
  • 6.5.2.2. CSI还内置了数据掩护功能
    
  
  

7. 数据库

7.1. 一个办法是直接连到数据库引擎，让它把数据备份到一个文件里，然后你去把谁人文件备份下来
7.2. 另一种办法是在另一台主机上运行数据库备份命令，让该命令针对容器里的谁人数据库做备份

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。