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

现代基础设施的核心在于可用性。

• 以在线抵押贷款业务为例。提供商需要在 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。

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

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

总结

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

本文首发于The New Stack。