纠删码计算器
参考硬件
以零停机时间和零数据丢失迁移 MinIO 集群实例
随着云计算的出现，临时计算实例变得无处不在。这在管理软件、应用 DevOps 原则、解决安全漏洞和确保自动化方面带来了一系列挑战。为了防止数据被盗和服务中断，这些都是关键任务。
解决安全漏洞特别具有挑战性，因为它经常采用更新和重启软件的形式。
Computer Vulnerabilities and Exposures (CVE) 是公开披露的计算机安全漏洞的编号列表。供应商和研究人员发布的安全公告几乎总是提到至少一个 CVE ID。CVE 帮助 IT 专业人员协调他们的工作，以确定优先级并解决已知漏洞，从而使计算机系统更加安全。
永无休止的 CVE 攻击给产品供应商、软件工程师和云架构师带来了重大挑战，并使本来就很复杂的临时云解决方案架构设计和构建任务变得更加复杂。底层基础设施、平台以及构建在其之上的供应商提供的产品和服务必须具有足够的弹性和灵活性，以应对修复这些漏洞所需的许多频繁更新。
随着高性能对象存储的兴起，企业现在正在为云原生应用程序提供互联网规模，为之前描述的等式增加了一个新的维度。现在企业必须考虑临时存储，这是一个巨大的挑战，因为这将意味着频繁的机器映像更改和潜在的停机时间以及可能的数据丢失。
了解本地附加存储与网络附加存储
在我们能够应对云环境带来的运营挑战之前，我们需要首先总体上讨论一下存储。具体来说，我们需要解决设备与软件定义、驱动器类型的权衡以及这些驱动器呈现给实例的方式。
软件定义存储是在云原生世界中完成存储的方式。它很容易使用 Kubernetes 进行容器化和编排。这使其具有弹性和敏捷性。另一方面，基于设备的解决方案不可容器化，这就是为什么您不会在公共云或其他云操作模型部署场景中找到它们的原因。
软件定义存储确实带来了相邻的挑战。它要求组织解决网络附加存储 (NAS) 设计并应对网络带宽挑战。为了减轻网络带宽需求，我们需要针对直接附加存储 (DAS) 进行设计。对 DAS 的引用通常与 HDD 或 SSD/NVMes 等存储设备相关。
直连存储设备没有联网。没有像网络附加存储 (NAS) 或存储区域网络 (SAN) 那样通过以太网或光纤通道 (FC) 交换机进行连接。
外部 DAS 设备通过小型计算机系统接口 (SCSI)、串行高级技术附件 (SATA)、串行连接 SCSI (SAS)、FC 或 Internet SCSI (iSCSI) 等接口直接连接到计算机。该设备连接到插入计算机内部总线的卡上。
在 Kubernetes 平台上采用容器化时，此类驱动器被称为本地持久性卷 (localpv) 和网络附加持久性卷 (networkpv)。与网络附加存储解决方案相比，此类软件定义的高性能对象存储解决方案的架构如下图所示。
本地持久卷的优点和缺点
本地持久性卷为数据湖和 AI/ML 等用例提供了更好的性能，因为它缓解了读取和写入数据的网络带宽瓶颈。出于这个原因，复杂的企业为需要高性能的应用程序采用本地光伏。本地 pv 的额外好处是比基于网络的存储系统更简单，使其更易于实施和维护，从而在第 1 天和第 2 天节省成本。
虚拟化技术的进步改变了 localpv。在查看现代超融合基础架构 (HCI) 系统时，这一点尤为明显。HCI系统由多个服务器和本地pv存储节点组成，存储整合成逻辑资源池，提供比传统localpv更灵活的存储方案。
然而，本地光伏并非没有挑战。它的可扩展性有限，并且缺乏其他存储平台可用的集中管理和备份功能。此外，它不容易共享，并且在服务器崩溃时不利于故障转移。由于这些挑战，传统形式的本地 pv 不适用于许多企业工作负载。
软件定义的存储解决方案需要围绕这些挑战构建工具和功能。以下是用例以及本地光伏如何提供帮助及其优势和挑战。
当涉及到数据密集型存储需求时，有足够的理由表明直接持久卷是正确的架构。
在实例级别驱动附件
将对话进一步深入到实例级别，我们将比较可用于 AWS EC2 实例的不同类型的存储。这些实例支持两种类型的块级存储，HDD 或 NVMe/SSD 驱动器。
我们可以选择弹性块存储 (EBS) 支持的实例或实例存储（临时存储）实例。弹性块存储是与实例可分离的存储，而实例存储卷是本地附加的根卷以及其他卷。实例存储支持的 EC2 实例是短暂的，卷不可分离，因此默认情况下是短暂的。
使用并排图表更容易理解差异及其含义。
比较 EBS 支持的实例和本地实例存储
当我们注意到 EBS 支持的实例和本地实例存储的特性（或缺乏特性）时，我们可以比较和对比这两种类型的存储的几个特性，以便就哪种更适合满足特定要求做出明智的决定用例的。
*默认情况下，Amazon EBS 支持的实例根卷的 DeleteOnTermination 标志设置为 true。您必须保持根卷较小并且不在其上存储任何数据，或者翻转标志以便在终止时不会删除该卷。
每个用例都是不同的，因为每个企业都不同，每个数据集也不同。结果，没有单一的答案。本地实例存储最适合要求苛刻的数据工作负载，但 EBS 支持的实例提供了在临时实例之外持久保存数据的能力。这意味着我们可以从实例中分离卷并将其重新附加到不同的实例，而不会丢失任何数据。
解决集群实例迁移挑战
既然我们了解了存储模式、直接持久卷与网络持久卷之间的差异，并且我们已经了解了 Amazon 实例级驱动器映射模式的差异，我们将需要了解由于短暂性而出现的新活动及其定义架构中的存储、弹性和敏捷性。这些是在我们采用云原生解决方案时出现的，它们的定义如下：
Image Rehydration：Image Rehydration 是启动新服务器的过程，其上已安装已识别的漏洞的最新补丁（如问题陈述中所述），并停用/销毁未安装的旧服务器。可以在公共云中同时对数十、数百甚至数千台服务器进行再水化。
实例升级：随着新的高性能实例的发布，明智的做法是升级到这些实例以获得高性能和更高的弹性。
更换驱动器：MinIO 支持擦除编码来管理驱动器故障以有效避免数据丢失，但在其他情况下，我们可能会根据特定客户的需求决定将驱动器从 HDD 升级到 SDD。
所有这些场景的主要挑战是，我们希望避免停机并保护自己免受数据丢失。这就是部署到 Kubernetes 上的容器化 MinIO 的巨大优势所在。采用 Kubernetes Day 2 操作方法可以提高您管理和更新集群的能力，以及在集群上运行的所有工作负载。在这种情况下，让我们继续使用 Amazon 在 AWS 上的 EKS 中利用托管的 Kubernetes 集群。
借助 Amazon EKS 托管的 Kubernetes，节点组可以获得节点的自动预置和生命周期管理。我们不需要单独配置或注册 EC2 实例，每个托管节点都配置为 EC2 自动扩展组的一部分，该组由 Amazon EKS 为您管理。每个资源，包括实例和 Auto Scaling 组，都在您的 AWS 账户中运行。每个节点组都运行在您定义的多个可用性区域中。
我们需要选择 EBS 支持的卷，以便我们能够在零停机和零数据丢失的情况下执行实例迁移。一个八节点集群，每个集群都有一个 EBS 支持的驱动器，如下图所示：
将 MinIO 容器部署到 eks 集群上，利用 MinIO Operator 来简化部署，如此处所示。
设置好集群并成功部署 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 设置、传播类型的调度谓词，并且可以在 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 存储类相关的成本增加。
最终，业务和企业目标推动了这些决策。