零停机、零数据丢失迁移 MinIO 集群实例

随着云计算的兴起，短暂的计算实例变得无处不在。这带来了一系列围绕软件管理、应用DevOps原则、解决安全漏洞和确保自动化的挑战。这些对于防止数据盗窃和服务中断至关重要。

解决安全漏洞尤其具有挑战性，因为它通常以更新和重启软件的形式出现。

计算机漏洞和披露 (CVE) 是一个公开披露的计算机安全漏洞编号列表。供应商和研究人员发布的安全公告几乎总是会提及至少一个 CVE ID。CVE 帮助 IT 专业人员协调他们的工作，优先处理并解决已知的漏洞，以提高计算机系统的安全性。

源源不断的 CVE 对产品供应商、软件工程师和云架构师提出了重大挑战，并且增加了为短暂的云解决方案架构设计和构建的本来就很复杂的任务的复杂性。底层基础设施、平台以及在其上构建的供应商提供的产品和服务必须具有足够的弹性和灵活性，以应对修复这些漏洞所需的许多频繁更新。

随着高性能对象存储的兴起，企业现在为云原生应用程序提供互联网规模，为之前描述的等式增添了新的维度。现在，企业必须考虑短暂存储，这是一个巨大的挑战，因为这意味着频繁更改机器映像，并可能导致停机和数据丢失。

了解本地连接存储与网络连接存储

在我们着手解决云环境带来的运营挑战之前，我们需要首先讨论存储的一般情况。具体来说，我们需要解决设备与软件定义、驱动器类型的权衡以及这些驱动器向实例呈现的方式。

软件定义存储是云原生世界中存储的方式。它易于使用 Kubernetes 进行容器化和编排。这使其具有弹性和敏捷性。另一方面，基于设备的解决方案不可容器化，因此您不会在公共云或其他云运营模型部署场景中找到它们。

软件定义存储确实带来了相关的挑战。它要求组织解决网络附加存储 (NAS) 设计并解决网络带宽挑战。为了减轻网络带宽需求，我们需要设计直接附加存储 (DAS)。DAS 的引用通常与存储设备（如 HDD 或 SSD/NVMe）相关。

直接附加存储设备不是联网的。与网络附加存储 (NAS) 或存储区域网络 (SAN) 不同，它没有通过以太网或光纤通道 (FC) 交换机的连接。

外部 DAS 设备通过诸如小型计算机系统接口 (SCSI)、串行高级技术附件 (SATA)、串行连接 SCSI (SAS)、FC 或 Internet SCSI (iSCSI) 等接口直接连接到计算机。该设备连接到插入计算机内部总线上的卡。

在 Kubernetes 平台上采用容器化时，此类驱动器被称为本地持久卷 (localpv) 和网络附加持久卷 (networkpv)。与网络附加存储解决方案相比，此类软件定义的高性能对象存储解决方案的架构如下面的图表所示。

本地持久卷的优缺点

本地持久卷为数据湖和 AI/ML 等用例提供了更好的性能，因为它可以减轻读取和写入数据的网络带宽瓶颈。因此，复杂的企业会为需要高性能的应用程序采用本地 pv。本地 pv 还具有比基于网络的存储系统更简单的额外优势，从而简化了实施和维护，从而节省了第一天和第二天的成本。

虚拟化技术的进步改变了 localpv。在查看现代超融合基础设施 (HCI) 系统时，这一点尤其明显。HCI 系统由多个服务器和本地 pv 存储节点组成，存储合并到逻辑资源池中，提供了比传统 localpv 更灵活的存储解决方案。

然而，本地 pv 也并非没有挑战。它具有可扩展性有限，并且缺乏其他存储平台提供的集中式管理和备份功能。此外，它不容易共享，并且如果服务器崩溃，无法轻松地实现故障转移。由于这些挑战，传统形式的本地 pv 不适合许多企业工作负载。

软件定义的存储解决方案需要围绕这些挑战构建工具和功能。以下是用例以及本地 pv 如何提供帮助及其优点和挑战。

有足够的理由表明，在数据密集型存储需求方面，直接持久卷是正确的架构。

实例级别的驱动器连接

进一步深入到实例级别，我们将比较 AWS EC2 实例可用的不同类型的存储。这些实例支持两种类型的块级存储，HDD 或 NVMe/SSD 驱动器。

我们可以选择由弹性块存储 (EBS) 支持的实例或实例存储（短暂存储）实例。弹性块存储是从实例分离的存储，而实例存储卷是与其他卷一起本地附加的根卷。由实例存储支持的 EC2 实例是短暂的，并且卷默认不可分离，因此是短暂的。

使用并排图表更容易理解差异及其含义。

比较由 EBS 支持的实例和本地实例存储

当我们注意到由 EBS 支持的实例和本地实例存储的功能（或缺乏功能）时，我们可以比较和对比这两种类型的存储在多个特征上的差异，以便做出明智的决定，以确定哪种存储更适合满足用例的特定需求。

*默认情况下，由 Amazon EBS 支持的实例根卷的 DeleteOnTermination 标志设置为 true。您必须要么保持根卷较小并且不存储任何数据，要么翻转标志，以便在终止时不会删除卷。

每个用例都不同，因为每个企业都不同，每个数据集都不同。因此，没有单一的答案。本地实例存储对于要求苛刻的数据工作负载最合适，但由 EBS 支持的实例提供了在短暂实例外部持久化数据的功能。这意味着我们可以将卷从实例分离并将其重新附加到另一个实例，而不会丢失任何数据。

解决集群实例迁移挑战

现在我们了解了存储模式、直接持久卷与网络持久卷之间的区别，并且我们已经了解了 Amazon 实例级别驱动器映射模式的差异，我们需要了解由于架构中的短暂存储、弹性和敏捷性而出现的新活动及其定义。这些在我们采用云原生解决方案时出现，并在下面定义

1. **映像重水化**：映像重水化是在新服务器上启动已安装最新漏洞补丁（如问题陈述中所述）的过程，并停用/销毁旧服务器。在公共云中，可以同时重水化数十、数百甚至数千台服务器。
2. **实例升级**：随着新高性能实例的发布，明智的做法是升级到这些实例以获得高性能和改进的弹性。
3. **更换驱动器**：MinIO 支持擦除编码以有效地管理驱动器故障以避免数据丢失，但在其他情况下，我们可能会决定根据特定客户的需求将驱动器从 HDD 升级到 SDD。
   

所有这些场景的关键挑战是，我们希望避免停机并保护自己免受数据丢失。这就是在 Kubernetes 上部署的容器化 MinIO 的巨大优势所在。采用 Kubernetes 第二天运营方法可以提高您管理和更新集群（以及在其上运行的所有工作负载）的能力。在这种情况下，让我们继续使用 Amazon 在 AWS 上利用 EKS 中的托管 Kubernetes 集群。

使用 Amazon EKS 托管 Kubernetes，节点组可以获得节点的自动化预配和生命周期管理。我们无需单独预配或注册 EC2 实例，每个托管节点都作为 EC2 自动扩展组的一部分进行预配，由 Amazon EKS 为您管理。包括实例和自动扩展组在内的每个资源都在您的 AWS 账户中运行。每个节点组都跨您定义的多个可用区运行。

我们需要选择 EBS 支持的卷，以便能够执行零停机和零数据丢失的实例迁移。一个包含八个节点的集群，每个节点都使用一个 EBS 支持的驱动器，部署方式如下面的图所示。

利用 MinIO Operator 将 MinIO 容器部署到 eks 集群中，以简化部署，如此处所示。

设置好集群并成功部署 MinIO 后，我们必须在平台上生成一些负载。实现此目的的一种方法是利用WARP，这是一个完整的对象存储基准测试工具。尽管 WARP 测试中指示的步骤可能过于激进，因为它是在基准测试中定义的，但可以配置降低并创建稳定负载。

现在让我们看看如何精确地利用 Kubernetes 执行零停机和零数据丢失的实例迁移。例如，假设一个 EKS 集群部署具有 c6gn.8xlarge EBS 支持的实例，网络性能为 50 Gbps，并且您遇到网络瓶颈。您需要通过切换到具有 100 Gbps 网络性能的 c6gn.16xlarge EBS 支持的实例来提高集群的整体性能（有关详细信息，请参阅下表）。

下图显示了实例迁移过程是如何发生的。

一旦集群启动并运行，并且 WARP 在 MinIO 上生成负载，我们就可以创建一个具有 16x 大节点组的节点组。可以采用任意数量的自动化技术来启动您的 Kubernetes 服务。MinIO Operator 简化了在 Kubernetes 集群上的部署，并允许您选择适当数量的节点和驱动器，以满足您的性能、容量和弹性需求。如前所述，部署 WARP 比此练习的其余部分更简单，我们这样做是为了证明 MinIO 服务不会中断。在 MinIO 集群处理实时流量的情况下，让我们继续创建具有 c6gn.16xlarge EBS 支持的实例的节点组，并使用最新的 AWS 机器镜像，理想情况下应根据（并获得您的企业组）组织的安全策略进行配置。

创建 16x 大节点组后，您可以通过更改其节点选择器调度项将入口控制器请求迁移到 16x 大节点组。此更改更新入口控制器部署规范，要求在调度期间使用 c6gn.16xlarge 节点，并强制对 16x 大节点组进行滚动更新。入口控制器能够成功跨节点组迁移，因为它配置了 HA 设置、spread-type 调度谓词，并且可以在 Kubernetes 的Pod 生命周期中优雅地终止。

一旦所有旧 Pod 被杀死并且新 Pod 在节点组中启动并运行，我们就可以准备终止旧节点组。再次注意，MinIO 会继续读取和写入，而不会中断服务。

停用旧节点组涉及以下步骤

• 清空 Kubernetes 节点。
• 将节点组的自动扩展组缩减到 0。
• 删除节点组。
  

此技术也可用于 AMI 重新加载、实例升级和驱动器升级。

EBS 支持的 EC2 实例与实例存储 EC2 实例的性能分析

MinIO 工程师对不同类型的节点（带有本地卷和 EBS 支持的卷以及其他存储类）进行了彻底的分析。根据我们的分析，使用实例存储的 EC2 实例的性能至少比 EBS 支持的实例高 1 GiB/s。详细信息在下表中提供。

关键要点是，我们无法使用具有 HDD（SC1 存储类）和 SSD（GP2 存储类）的 EBS 支持的实例来实现具有本地卷的实例的性能。我们必须多花一点钱才能获取 GP3 存储类 EBS 卷，以达到与具有本地卷的实例类似的性能。

注意：这些性能数字受基础设施创建的条件和配置以及在组织约束下完成的验证的影响，显然每个组织的条件和配置都会决定性能数字。这些结果应被视为可能的潜在数字，而不是所有用例和所有客户的硬性数字。

具有本地卷的实例与 EBS 支持的卷的成本分析

考虑到不同存储类的性能和成本，我们发现利用 GP3 和 HDD 温层相结合的方法比不同存储类的 EBS 卷更具成本效益。从上面的实例性能评估中，我们知道要匹配本地卷实例的性能，您必须选择具有存储类 GP3 或 IO2 的 EBS，并且它们的成本会比分层高得多。

结论

与所有架构决策一样，利弊并存。在 EKS 上选择实例类型时，清楚地了解利用高性能实例存储（本地卷）部署的利弊至关重要。

由本地卷支持的短暂实例比具有 EBS 卷的短暂实例提供更好的性能。

在本地卷上运行的 MinIO 可以通过利用其他功能（例如创建更多实例池）来扩展和/或升级，而不会造成中断。但是，EBS 支持的卷提供了持久化数据的能力，并且可以通过分离卷并将其附加到不同节点组中的节点来实现，从而使企业能够获得改进的操作、零停机和零数据丢失的优势，而不会受到性能降低或与昂贵的 EBS 存储类相关的成本增加的影响。

最终，业务和企业目标推动了这些决策。要深入了解，请下载 MinIO 并亲自查看或启动一个市场实例。您可以在此处找到我们的AWS 实例。与往常一样，您可以在Slack 上或通过hello@min.io 继续对话。