新私有云架构师指南

这篇文章最初出现在 The New Stack 上。

在那里的几年里，“私有云”一词具有负面含义。但正如我们所知，技术更像是一个轮子而不是一个箭头，而且就在提示下，私有云正在受到大量关注，而且这一切都是积极的。统计数据很清楚，Forrester 的 2023 年基础设施云调查显示，在 1,300 名企业决策者中，有 79% 的人表示他们正在实施私有云。根据 Citrix 在英国的一份报告，94% 的 IT 领导者参与了遣返工作。久负盛名的 IDC 发现，80% 的公司在将部分或全部数据迁移到云端后的一年内将其部分或全部数据汇回云端。云工业综合体声称“这里没什么可看的......”就这么多了。

原因多种多样，我们将详细介绍，但更重要的是，返回的正确架构是什么？私有云的工程首要原则是什么？最后，如何针对 AI 的数据基础设施要求进行设计？

遣返私有云背后的原因

公司遣返的主要原因是成本。他们通过遣返节省高达 70% 的费用。37 Signals、X 和 Ahrefs 等公司已经公开证明了这一点。与此相关但不相同的是可预测性。私有云的弹性较低，但可预测性较强（我们将在下面讨论一些弹性技巧）。对于大多数了解其工作负载的 CIO 来说，这种权衡是非常值得的。对于首席财务官来说，这是一个更容易的选择。安全问题排在第三位。这并不是说公有云本质上是不安全的，事实并非如此。它确实表明，首席信息安全官在这方面并不完全信任他们的公共云合作伙伴（事实上，大多数云提供商保留查看您的存储桶的权利）。在人工智能时代，赌注只会变得更高。

与此相关的是，控制是每个首席信息官的清单。再加上成本节约、可预测性和安全性，您不仅可以完全控制您的 AI 数据基础设施，而且这些数据几乎可以供您的所有应用程序使用，使您能够在 AI 数据基础设施上托管您的模型，您和您的团队可以设置安全标准，以匹配您独特的安全要求 - 甚至是物理访问。成熟度也排在前面。现代云是一种运营模式，而不是一个位置。这种模式曾经是主要公共云的独家产品，现在无处不在——从边缘到核心。容器化、编排、微服务、软件定义的基础架构、RESTful API 是标准操作程序。你在哪里运行它们并不重要——如果这无关紧要，你为什么要支付两到三倍的成本？法规也发挥了作用，尤其是在它们不断发展的过程中。一些架构、一些地理位置、一些部署方案（军事/情报）一开始并不需要私有云，但现在需要。

同样，原因会有所不同，但效果是一样的。私有云重新流行起来。问题是：过去几年发生了什么变化？

私有云最喜欢的设计模式是现代数据湖

如上所述，私有云与公有云一样，在云运营模型上运行。边缘云在云运营模型上运行。 主机托管在云运营模型上运行。

该操作模型定义了某种架构，并且一次又一次地使现代数据湖成为可能。可以肯定的是，还有其他架构，但使用私有云来构建现代数据湖允许组织只为他们需要的东西付费。当他们的业务增长时，扩展就像向集群添加更多资源一样简单。不需要重新设计。支持 AI/ML。高级分析 - 支持。Log Analytics/威胁分析 - 支持。HDFS 替换/迁移 — 支持。

现代数据湖是一半数据仓库和一半数据湖，所有内容都使用对象存储。对象存储层是软件定义的、可扩展的、云原生的和高性能的。通过选择硬件 （NVMe） 和网络（100 GbE 或更高）来调整性能，这些硬件和网络可方便地从 Supermicro、Dell 和 HPE 等供应商处获得。

在数据湖中使用对象存储是标准配置，将其与数据仓库一起使用是新的，通过 Apache Iceberg、Apache Hudi 和 Delta Lake 等开放表格式 （OTF） 成为可能。关于此体系结构的大量细节超出了本文的讨论范围。为此，我建议阅读 Keith Pijanowski 关于现代数据湖的完整文章。架构如下：

此体系结构旨在提供以下内容，所有这些原则都是核心云操作原则，并扩展为私有云的核心原则：高性能：虽然私有云可以针对容量进行设计，但现代私有云希望大规模提供性能。此体系结构优先考虑强调速度和效率的工具。正如杰夫·贝佐斯（Jeff Bezos）所说，谁愿意支付更多费用并等待更长的时间才能得到它？同样的原则也适用于这里：谁希望它慢一点？

解耦计算和存储：取消这些组件的链接可提高灵活性和可扩展性，使您选择的基础架构、服务和工具能够在各自的专业领域中脱颖而出。

开放标准：开放标准不仅鼓励互操作性，而且使您的投资面向未来。这不仅包括开源解决方案，还包括我们将要探索的开放表格式。由于这些原因，不要使用存储设备构建私有云（以及它们永远不会是云原生的）。

与 RESTful API 的兼容性：互联互通是必须的。您的工具应共享通用语言，其中 S3 是云存储的通用语言。因此，不要使用以 POSIX 为中心的解决方案构建私有云，即使它声称支持 S3。选择真正的交易。

软件驱动/基础架构即代码：自动化并让 Kubernetes 负责编排您的基础架构，使您能够抽象出手动管理的复杂性，并允许快速高效的可扩展性。

增强的安全性和合规性：由于私有云提供了专用的基础架构，因此它们可以更好地控制数据并增强安全措施。这对于处理敏感信息的行业（如金融和医疗保健）尤其有利。

法规遵从性：此体系结构可以通过提供可自定义的安全设置和审核控制来支持法规遵从性，以满足特定的行业标准。

让您的私有云发挥作用

我们已经看到了许多方法来点亮私有云。他们都可以工作;这实际上取决于企业和用例。

• 一种有时间限制的混合模型，其中一些数据和应用程序保留在公共云中，而私有云则处于水化状态。
• 完全从公有云迁移到私有云。
• 私有云的绿地构建。随着企业将人工智能实验投入生产，这一点尤其受欢迎。
• 棕地遣返，将公有云数据和基础架构移回现有的私有云部署。虽然经济实惠，但这种方法也有一些缺点。
• “其他”类别（突发表和外部表）。

限时混合方法：限时混合方法实质上是将公有云转变为冷存储，并在一段时间内（几个月/一个季度，而不是几年）构建您的私有云足迹。这涉及在私有云上购买和配置基础架构和软件堆栈。然后，将数据管道指向私有云，而不是公有云。在一段时间内，您可能会同时执行这两种操作。然而，目标是使用公共云作为分层冷存储，使用私有云作为热存储。随着时间的流逝，公有云从冷到冻结，而私有云成为主要和主要的存储类型。

这就是领先的网络安全参与者所做的。它首先与 MinIO 和 Equinix 一起建立了一个私有云，然后将每天 250 TB （TiB） 的数据转向这个方向。鉴于日志分析在运营价值方面具有很高的衰减功能，因此没过多久，新的私有云就成为威胁搜寻数据的主要来源。这个私有云已经发展到近一 EB（并且很快就会超过这个门槛），并且决定将这些工作负载（实际上是核心业务）转移到私有云上（运营支出而不是资本支出），从而将业务的毛利率提高了 2% 以上。因此，这家公司的估值倍数令同行羡慕。

完全遣返：有时将应用程序和数据保留在公共云和私有云上不是一种选择。在这些情况下，您需要与云提供商分手。这很难，即使取消了退出费，它们也会让人感到痛苦（细则基本上说一切都必须去才能获得任何退出费减免）。这是非常可行的;它只是需要更多的计划和更多的业务摩擦。在这种情况下，请预配 colo 或私有云和应用程序堆栈。然后备份数据卡车或租用网络，将数据传输到私有云数据基础架构。在这一点上，你是自由的，但如果你是腰带和吊带的类型，指望支付双倍的一两个月。一家领先的流媒体公司在离开公共云时采用了这种方法。它将半 EB 的垃圾叉运到新的私有云中，包括所有的电影、节目、纪录片等。这个过程花了大约四分之三的时间。然而，回报是巨大的，管理服务的团队的复杂性大大降低。他们还享受了“第一个字节时间”的附带好处——这是该领域的一个关键指标。

绿地私有云：

这是一个相当简单的命题，它通常涉及新的一切。该项目是新的，项目上的数据将是新的（或新的）或从即将上线的某个来源（如巨型制造厂或新的云视频点播服务）生成的。在这里，您可以确定工作负载的大小 - 您甚至可以在公共云上对其进行测试 - 但其想法是，从一开始，它将在私有云上运行。我们在人工智能数据基础设施中经常看到这种情况。早期的实验是在公共云中进行的。数据并不那么重要。GPU的可用性相当不错。尽管如此，企业知道工作负载需要在私有云上进行生产，这既是为了规模，也是为了安全、隐私和控制。世界领先的汽车公司之一最近将其完全自动驾驶计划从基于规则的系统转变为基于实际驾驶员行为的系统。这种行为是从其车辆上数以百万计的视频和日志文件中“学习”的。好司机，坏司机，普通司机。不仅来自视频，还来自汽车遥测的其他元素，例如制动、加速、转向扭矩等。基于规则的 ML 方法的规模为 PB;视频以 EB 为单位。该公司没有与任何人共享这些数据（事实上，两个公共云都有相互竞争的计划）。人工智能工作负载（所有 300+ 台服务器的价值）始终是一项私有云计划。

棕地私有云：

我们在这里要诚实：我们看到了这一点，但我们不喜欢它。这包括尝试在硬盘驱动器上运行高性能工作负载，以在 SAN/NAS（存储区域网络/网络连接存储）之上分层 MinIO。

它有效，但很少是最佳解决方案。它很经济（你正在重复使用硬件），它摩擦力低（无需采购），但很少是高性能的。尽管如此，我们将其包括在这里是为了全面。它确实提出了一个重要的观点。在设计私有云时，在任何方案中，都要规划异构性。这是一种保证，坦率地说应该是计划的一部分。在上述场景之一中，一半的硬件来自 Supermicro。另一半来自戴尔。随着世界的变化和新技术的出现，您的软件应该不在乎。

其他：

还有另外两种情况不太常见，但应该在考虑组合中。一种是混合突发方法，另一种是外部表方法。两者都与混合选项有关，但可能没有时间限制。在混合突发方法中，您可以维护私有云，同时将其设计为无缝扩展或“突发”到公有云中，以增加灵活性。通常采用此策略来利用额外的 GPU 容量或使用特定的云服务。在此模型中，某些任务会临时转移到公有云进行处理。分析完成后，结果将发送回私有云，然后停用公有云资源。我们有一个主要的金融服务客户，通过信用风险和市场风险计算来做到这一点。它使用公共云进行一些计算操作，并将其与使用MinIO和Dremio的私有云数据湖相结合。实际上，这是一条双向的道路。曾几何时，这是一条单行道，但世界已经改变，企业有选择性。借助外部表选项，组织仍可以通过将其现有的云数据仓库（如 Snowflake 和 SQL Server）与基于私有云构建的数据湖集成，从云运营模型的原则中受益。这种混合设置使企业能够从现代数据湖的性能、数据安全性和开放标准设计中受益，同时仍能利用对云基础设施的现有投资。现在，每个主要的数据库供应商都提供对外部表的支持。 此功能允许用户查询对象存储中的数据，无论它位于何处，就好像它是数据库中的常规表一样，而无需迁移。您的数据保留在私有云中，但可以在任何需要的地方使用。

最后的想法和建议

多年来，我们参与了许多私有云遣返/新建。让团队感到惊讶的一件事是再次管理硬件。在云中，它是透明的。DevOps 和站点可靠性工程师仅在 API 级别与基础架构进行交互。如果 VM 正在运行，请终止并启动新 VM。不幸的是，在新的私有云中，我们不仅要报废硬件并购买新硬件，还必须使现有硬件正常工作。基础设施管理是一回事。它随领土而来。它不应该是可怕的，但它应该被计划好。需要从软件工程/DevOps方面和数据中心工程师的角度划分职责。数据中心的 SME（主题专家）应该了解所有硬件的来龙去脉。他们将负责与硬件相关的任何事情，包括故障、更换和任何维护。软件在这里很重要。这就是 MinIO 在其全局控制台中构建可观测性的原因。在私有云的世界里，你应该运行智能软件和愚蠢的硬件。但是，该软件必须承担这种经济恩惠的运营负担。硬件人员根本无法构建可观测性层，MinIO 必须这样做。

如果您是一个每周部署一次的组织，这意味着每次部署都可能是一场奇观。这是因为在不频繁的部署中，很难预测和修复错误。当部署没有按计划进行时，一切都在甲板上。通常，流程如下所示：

• 设计以在分布式设置中部署应用程序
• 在本地环境中进行测试
• 在 Dev 和 Stage 环境中进一步验证
• 添加监控、指标、跟踪和更改
• 部署本地、混合和云环境

当这些 CI/CD 原则在实践中应用时，一位强大的数据中心工程师与另一位强大的 DevOps/SRE 工程师密切合作，可以轻松管理私有云或协作设施中的 5,000 多个节点。我们的客户正是这样做的。一旦遵循 CI/CD 基线原则，几乎所有事情都可以而且应该自动化，数据中心和 DevOps 工程师将只关注那些无法自动化的任务。最后，如果你错过了，colos是我们对私有云定义的代名词。主机托管在完全本地基础设施和公有云之间提供了一个中间地带，提供了两个世界的好处。通过访问顶级网络并靠近公共云提供商，colos 促进了低延迟连接和混合云设置，从而实现了高效的数据传输和处理。这种灵活性和成功部署混合云的潜力对于旨在优化运营和保持竞争优势的企业至关重要。