Docker数据容器保护方式利弊

208次阅读

共计 3581 个字符，预计需要花费 9 分钟才能阅读完成。

Docker 是一个非常成功的 Linux 开源项目。它在 Linux 操作系统下无需增加管理器即可虚拟化应用程序。该应用程序常被抽象地误认为是操作系统（具有 Linux 内核资源隔离功能的 OS）的唯一的应用程序。换句话说，该 Linux 应用程序部署在 Docker 数据容器中，该容器能利用 Linux OS 的所有功能并能隔离应用程序。

Docker 容器具有移动性并且与虚拟机（VMs）相互隔离, 且仅在虚拟机上进行部分操作。在深入研究 Docker 数据保护这个问题之前，弄清楚 Docker 镜像和 Docker 数据容器之前的差异是十分必要的。一个 Docker 镜像包括一或多个应用程序的操作系统。而 Docker 容器（本文的重点）是独立于镜像之外的运行实例。

Docker 数据容器保护机制目前十分简单，不像 VM 数据保护机制那么复杂成熟。这种保护机制与 VMware vSphere 存储接口数据保护、Microsoft Hyper-V Volume 卷影复制服务或内核 VM 快照 API 不同。这就使得 Docker 容器保护机制更具有挑战性。好消息是我们有几种方法来实现它。

在备份 Docker 数据容器之前，容器当前状态必须保存成 Docker 镜像。该容器的运行状态需要简要暂停以便获取快照，并将该镜像重名为一个新的 Docker 镜像 – 通常是基于时间线前一个镜像的变型。将 Docker 容器备份当成一个镜像在不同 Docker 主机系统上部署时，你要么将其推送懂啊 Docker 私有仓库中要么将其保存为一个.tar 文件只有这样，该镜像才能被移植到任一 Docker 主机系统上。

Docker 容器的恢复取决于它的部署方式。如果镜像被推送到 Docker 私有仓库中，使用 Docker 命令“run”命令即可启动一个新的容器实例。如果该镜像存储成一个.tar 文件，该.tar 备份文件必须加载到 Docker 主机系统的本地镜像仓库中然后利用“run”命令来启动一个新的容器实例。

建立 Docker 备份和恢复并非自动进行。每一次都需手动进行这些备份和恢复或者写一个脚本来实现该功能。大多数 IT 管理人员是采取写脚本这一方式。尽管脚本并不复杂，但是当软件改变或者基础设施发生变化时，它们需要重写。在前期以及每当生态系统变化时，记录脚本和进行质量保证（QA）都是十分有必要的，以此防止备份和恢复故障。当质量保证团队发现脚本的问题时，脚本需要进行修改或者重写来纠正这些错误，进而保证 Document 升级。尽管这看起来是一个很繁琐的过程，但这是保证 Docker 数据容器保护方式的关键。

许多 IT 管理员不希望面对 Document、QA、故障排除或修复、修补程序和更新脚本等等麻烦，更不想手动进行所有的备份和恢复。他们更喜欢独立、第三方支持的 Docker 数据保护方式。

传统的文件备份方式已流行多年，因为该方式支持多种类型的服务器、操作系统、文件系统、虚拟机管理程序、数据库或结构化应用程序。因为该技术可同时在 Linux 和 Window 上使用，所以同样可用于 Docker 数据容器上。

传统的基于文件的备份和恢复需要一个操作系统或者是文件系统代理；一个结构化应用程序代理如关系数据库、电子邮件等等；以及备份（即媒体）服务器。文件系统代理具有管理员权限，能够扫描文件系统并将其备份。结构化应用代理在应用进行备份时能短暂地暂停应用。Docker 容器可以看做文件系统代理 - 仅是另一份需要备份的文件。如果容器中存在结构化应用程序，结构化应用程序代理必须作为 Docker 镜像和运行容器的一部分安装。

该方法存在几个问题。代理是一个软件，它需要不断地运行、管理、修复、更新等等。很多代理都具有破坏性，需要操作系统重启时进而破坏了所有的容器；而另一些在每一次部署、修复或更新时都需要应用程序重启。这意味着它们需要预定在中断对操作影响最少的时刻，通常是周末或者深夜。这同样是很多的 IT 公司已经使用虚拟机管理程序 APIs 提供的无代理备份原因。如前所述，现在不存在与 Docker 容器相连 API。如果 IT 经理决定在 Docker 容器中不使用结构化应用程序代理，然后备份只是 crash-consistent 与 application-consistent 相比较了。

存储快照的方式十分简单，大多数快照消耗很少额外内存，除非需要实际地数据拷贝。然后快照被复制并移动到另一个 Volume、存储系统甚至是云存储上。每个 volume、LUN 或文件系统中可用快照的数量 – 假设每一 Docker 数据容器 – 各供应商存储系统各不相同。一些可能容纳很多一些仅能容纳少量快照。一个相对较新的公司 Reduxio 甚至可以在每次写入上都添加时间戳然后基于这些写操作分发一个虚拟快照，这就提供了连续快照能力。使用这些功能需要该存储器作为 Docker 镜像和容器的主要存储器。

快照存储的关键问题在于它们是 crash-consistent，而非 application-consistent– 唯一的例外是 Reduxio。此外，许多存储系统在给定的任一 Volume、LUN 或者文件系统的快照数目都有很强的限制。这就要求早期的快照需要复制下来，这就会消耗更多的存储空间并且需要额外的存储系统。

存储快照经常与备份应用程序相结合以此来保持与应用程序一致性。结构化应用程序的备份代理与结构化应用同时安装。在储存系统获取快照之前，该代理能暂停结构化应用，媒体备份服务器告诉存储系统获取快照，然后告诉该代理重启结构化应用程序。这就提供了应用程序一致的快照，目前 Commvault、EMC、Hewlett Packard Enterprise、Veritas 和其他几家公司能够提供。这种方法在管理结构化应用程序代理时仍然存在问题。

刚刚描述的组合的一个变本是复制数据管理，可由 Actifio、Cohesity 和 Rubrik 提供。复制数据管理是在一个系统中将文件备份和存储快照的两者结合。这里并没有外部媒体备份服务器。这些产品往往集中在虚拟管理程序 API 上。只有 Actifio 一个产品，存在操作系统代理可以备份 Docker 容器和镜像。但他们之中不存在任一产品同时具有结构化应用程序的一致性。

在撰写本文的时候，只有 Asigra-powered 云备份和恢复服务提供 Docker 数据容器和 Docker 镜像备份。该服务提供了一个 on-site 物理或虚拟设备，无需代理来备份操作系统和所有的 Docker 容器。最新的备份保存在本地云，该方式具有很快的回收率。此外，所有的备份都保存在云备份和恢复服务提供商的数据中心内。在第一次全卷备份后，所有的额外的备份都是永久增量，提供虚拟的、全容量的、一次性回收。所有云端备份数据删除重复数据并对数据压缩。

这种方法的缺点是：它必须得到云服务提供商而非软件开发人员（尽管它可以作为一个私有许可证。）的许可。

原文链接： Docker data container protection methods: Pros and cons（译者 / 刘崇鑫审校 / 朱正贵责编 / 仲浩）

译者简介：刘崇鑫，北京邮电大学研究生在读，专业光通信工程。

更多 Docker 相关教程见以下内容：

Docker 安装应用(CentOS 6.5_x64) http://www.linuxidc.com/Linux/2014-07/104595.htm

Ubuntu 14.04 安装 Docker http://www.linuxidc.com/linux/2014-08/105656.htm

Ubuntu 使用 VNC 运行基于 Docker 的桌面系统 http://www.linuxidc.com/Linux/2015-08/121170.htm

阿里云 CentOS 6.5 模板上安装 Docker http://www.linuxidc.com/Linux/2014-11/109107.htm

Ubuntu 15.04 下安装 Docker http://www.linuxidc.com/Linux/2015-07/120444.htm

在 Ubuntu Trusty 14.04 (LTS) (64-bit)安装 Docker http://www.linuxidc.com/Linux/2014-10/108184.htm

在 Ubuntu 15.04 上如何安装 Docker 及基本用法 http://www.linuxidc.com/Linux/2015-09/122885.htm

Docker 的详细介绍：请点这里
Docker 的下载地址：请点这里