多云业务连续性架构师指南

现代基础设施的关键在于可用性。

• 考虑在线抵押贷款业务。提供商有 30 秒的时间向潜在买家提供报价，否则另一家提供商将赢得客户的业务。

• 对于在线零售商而言，感恩节和新年之间的几周占其年收入的 25%。

• 客户对企业 SaaS 提供商的 SLA 期望通常远高于云基础设施提供商所保证的 SLA。

所有的共同点是，他们的基础设施中断可能会导致数百万美元的收入损失和/或客户流失，甚至可能意味着年底是盈利还是亏损。

数据中心将下降

这个普遍真理与位置无关。无论解决方案是在本地（或托管中心）还是在云端运行，都是如此。

本地解决方案具有专用硬件，但通过足够的地理分隔来维持冗余度太昂贵了。公共云通过提供多区域可用性在一定程度上缓解了这种情况；但由于有共享服务，它们仍然会出现故障——平均每年出现几次。

我们的客户不断了解到（通常是痛苦的）是，如果您的解决方案依赖于多项服务和/或组件（而且大多数都是），那么只需要其中一项服务和/或组件出现故障，您的应用程序就会不可用。您的可用性取决于最薄弱的环节。

备份还不够

备份是灾难恢复的解决方案。但是，目标首先是避免灾难。

随着不断生成的数据量的增加，在任何大中型公司中恢复完整数据集所花费的绝对时间会给运营人员带来噩梦。从备份中恢复绝对是最后的手段。

当今世界关乎业务连续性。应用程序需要始终可用，几乎不会或不会中断操作。

硬性要求是能够故障转移到另一个提供商——这可能是另一个公共云供应商或另一个本地目的地。

数据存储与众不同

所以，现在要选择数据存储了。有这么多人，你如何做出决定？

以下列表概述了我们根据与客户进行的数百次讨论得出的建议，每个客户的目标、资源和能力都略有不同：

避免应用程序锁定

供应商锁定通过定义限制了您的选择，并包含了架构师对备份和恢复策略的限制。避免它，不是不惜一切代价，而是几乎所有的代价。供应商锁定要求您将应用程序保留在单一供应商平台（公共或私有）上，并消除了跨云故障转移的选项。您的应用程序工作负载需要是可移植的——换句话说，确保它建立在事实上的行业标准 API 之上。当事情进展顺利时，很容易陷入自满状态，但这是在出现问题时投资于解决方案的时候。

历史上充满了这样的例子。

避免云锁定

从一个供应商转移到另一个供应商具有挑战性，而转移到另一个数据中心更具挑战性，无论是私有云还是公共云。即使您不想切换而只想添加另一个云，这也同样具有挑战性。

现在是时候重新审视您的申请，为不可避免的事情做好准备了。这可能需要能够在有竞争力的云上运行或在本地运行相同的工作负载。无论哪种方式，最初的构建块都是 S3 和 Kubernetes。虽然 S3 需要作为您的起点，但 Kubernetes 将使它无缝衔接。发展那些肌肉。

提升硬件灵活性

考虑到锁定的业务连续性总是会产生硬件异构性。这意味着选择一个可以跨基础设施无缝运行的数据存储，无论是在服务提供商、托管和/或本地数据中心。这还需要能够移动依赖于多种驱动器类型（包括 NVMe、SDD 和 HDD）的工作负载。同样，对象存储具有超越商品硬件的优势。纠删码将 HDFS 等传统存储的驱动器数量减少至少 50%，而不会牺牲任何可用性。

构建整体可移植性

当应用程序移动时，数据存储不是堆栈中唯一需要移动的项目。

应用程序可移植性始于容器化。您的工作负载应该完全在容器内运行。是的，您需要持久性，但是通过将完整的应用程序堆栈（包括存储）放在容器内，可移植性变得非常容易管理。

选择轻量快速

根据定义，便携式应用程序是轻量级的。例如，MinIO 大约有 100MB，其中一半是图形控制台。这意味着它可以适应 Redis 或 Elastic 等用户空间。轻便也快。并非总是如此，但在极简主义设计中确实如此。通过更少的妥协和 CPU 级优化，您可以继承在更多地方运行更多工作负载的能力。

可扩展性设计

您的数据将会增长。相应地扩展存储的性能非常重要。对象存储的可伸缩性属性是众所周知的，并且不会降低任何性能。恢复到另一个位置的能力，即使是 PB 级的规模，也是一个精心设计的实施的基准。

努力提高运营效率

拥有出色的开发经验仅占成功的 10% 左右。剩下的就是管理和运营生产环境。

消费者应用程序如此受欢迎的原因是因为它们易于使用。那么，为什么企业应用程序如此具有挑战性？这是因为让事情变得简单实际上是相当复杂的。

大多数 DevOps 团队将大部分时间花在管理数据存储上。他们真正想要的是：

• 一些简单的东西，他们大多可以设置并忘记。

• 具有针对高级用户的命令行界面 (CLI) 并支持自动化的东西。

• 支持标准 API 的东西，以便应用程序可以与特殊连接器自然交互。

• 还具有图形用户界面的东西，允许临时任务，并使新资源和初级资源能够快速增加。

• 具有开箱即用的监视功能的东西。

• 易于与其他企业身份和访问管理以及监控工具集成的东西。

• 具有与流行端点的开箱即用集成通知但可以轻松扩展的东西。

如果您希望云中的业务连续性，架构师要简化操作。

通过多云复制确保业务连续性

数据需要跨云可用。当涉及可用性和连续性时，这是问题的核心。

让我们从简单的东西开始。您必须能够轻松复制存储桶。这是赌注。但是，您应该能够复制到任何兼容的对象存储。这就是标准接口与众不同的地方。对于简单的东西，你不应该被锁定。

MinIO 提供高性能的 Kubernetes 原生对象存储。开源、软件定义和 S3 兼容，它们针对多云进行了优化。MinIO 运行在任何公共云、私有云、托管云或边缘云中，并且性能足以应对从数据库到 AI/ML 的任何主存储工作负载。

然而，要真正实现业务连续性，您需要站点或集群复制。您应该能够设置主动-主动或主动-被动配置。而且您不应仅限于拥有两份副本。您应该能够根据业务需求复制到尽可能多的站点。它应该是相同的过程——简单且一致。

您还应该能够设置与您的业务需求相关的复制策略。您应该能够选择优先级是跨集群的实时可用性还是写入性能。前者要求保证对象作为单个同步操作持久保存在所有集群上，否则写入将返回失败。在后者的情况下，对象保证持久保存到主数据存储，并且操作排队等待异步复制到所有其他集群。

概括

现代企业没有休息日。真正的数据可用性确保它不必这样做。