在 Google Cloud Platform 上运行 MinIO 对象存储

随着组织围绕数据进行自身组织，它们正变得以应用为中心。现代应用是云原生且以数据为中心的应用，受益于解耦的无状态、不可变的服务，这些服务能够实现卓越的性能和扩展性。虽然 MinIO 可在所有云环境（公有云、私有云和边缘云）中使用，但这篇文章重点关注 Google Cloud Platform，并着眼于您为何需要在 GCP 中使用 MinIO 才能实现一致的用户体验和应用性能。

本文将重点介绍以下几个方面

1. 在 GCP 中部署 MinIO
2. 提高数据密集型工作负载的性能
3. 提供跨公有云和 Kubernetes 的可移植性
4. 利用多个存储层级来提高应用效率
   

在 GCP 中部署 MinIO

当 Kubernetes 部署在 Google Cloud 上时，无论是 Google Kubernetes Engine (GKE) 还是 Red Hat OpenShift 或 VMWare Tanzu 等商业发行版，应用在很大程度上都与底层的计算、网络和存储相隔离；每个都是可以独立于集群进行配置和管理的弹性云服务。但是，这种抽象并不会降低每个服务作为数据存储、检索和处理的潜在约束的影响。

MinIO 是一个现代数据存储，在 GCP 上部署它主要有两种方式。第一种是 市场模型。 我们研究了所有不同类型的基础设施选项，并提供了一个涵盖所有关键领域的意见性实现。我们评估了数十种最适合 MinIO 的实例类型，考虑了 CPU 类型、核心数量、存储类型和网络性能等因素。然后，我们在这些实例类型上对 MinIO 进行了基准测试，以确定 最佳的性价比。最终结果是四个 n2-standard-32 实例。使用这些实例，您可以预期获得高达 2.4 GiB/s 的 PUT 吞吐量和 5.1 GiB/s 的 GET 吞吐量。

除了对基础设施进行预先筛选之外，市场模型还有助于将 MinIO 数据存储成本整合到客户的 Google 总购买承诺中。

部署 MinIO 的第二种方式是采用“自行构建”的方法。目前在 GCP 上运行着超过 150,000 个这样的部署。利用 MinIO Operator 可以使“自行构建”变得更加容易。MinIO Operator 可以与任何版本的 Kubernetes 无缝协作，在 GCP 基础设施之上配置 MinIO。

我们鼓励开发者选择任一方向，因为最终结果都是一样的——提供兼容 S3 的对象存储，降低操作复杂性，在规模上实现高性能，并在 Kubernetes 集群之间保持可移植性。

提高数据密集型工作负载的性能

诸如 AI/ML、数据库、云原生应用、流式数据服务和灾难恢复等数据密集型工作负载特别依赖于优化的软件定义存储来提高应用性能。MinIO 优化了数据访问，提供了卓越的吞吐量、可扩展性和可移植性。鉴于上面概述的吞吐量统计数据，MinIO 能够提供运行 Apache Spark、Starburst Presto/Trino、Clickhouse 以及几乎任何其他云原生数据库、分析或 AI/ML 工作负载所需的性能。

这对 GCP 部署有什么影响？根据您的预算/工作负载选择最快的网络。如果使用 NVMe，MinIO 将最大限度地利用网络。对于 HDD，我们可能会首先最大限度地利用驱动器。但是，优化数据密集型工作负载通常会导致在达到 MinIO 的最大限度之前先达到底层基础设施的最大限度。相应地进行架构设计。

提供跨公有云和 Kubernetes 的可移植性

公有云的一个不那么明显的特点是它们之间实际上是不兼容的——尤其是在存储方面。AWS 有 S3，它是事实上的标准。Azure 有自己的 Blob API。GCP 有自己的对象存储 API。为一个云环境中的数据构建的应用无法在另一个云环境中无缝运行。

有一种方法可以解决存储不兼容性问题——那就是将 MinIO 作为对象存储运行，并使用任何适合预算或工作负载的基础设施。原因是 MinIO 不仅与 S3 兼容，而且由于 Kubernetes 的存在，它可以在所有公有云上原生运行。

最终效果是简化应用开发，并在云之间提供对数据的同类应用访问。

虽然我们非常看好 Google Cloud——它拥有令人难以置信的基础设施选项和一些出色的服务（例如 BigQuery）——但 GCS 对象存储 API 是主要云中采用率最低的。这可能会给应用开发、应用集成甚至开发者熟悉度带来问题。例如，客户发现 Google 在 ACL、CORS 结构和对象生命周期策略等方面对 S3 API 的实现存在 导致应用中断的差异。

通过 MinIO 采用以 S3 为中心的应用方法将提供对最广泛的应用和最大生态系统的访问。这可能是运行 MinIO 在 GCP 中的最强有力论据。

利用多个存储层级来提高应用效率

稍微改变一下思路，MinIO 中还内置了一些非常复杂的功能，这些功能在 GCP 内部运行得非常好，并且进一步增强了在 GCP 中运行 MinIO 的理由。其中一个功能集是 数据生命周期管理。通过 MinIO 原生工具（在 Operator、控制台、mc、CLI 等所有接口选项中可用），用户可以配置 MinIO，使数据跨 Google 的任何存储层级选项进行分层，从 TPC 实例到不常访问的 HDD。这些策略甚至可以管理数据到其他云或本地实例的分层。您的业务需求是指南——MinIO 成为使能软件。

例如，我们可以使用 裸机本地 NVMe 存储 配置 MinIO 以获得最大的“热层”吞吐量，然后使用 HDD 作为暖层，以及 Google Cloud Storage 作为第三层以实现可扩展性。再加上 多云、主动-主动复制 的安全保障，您可以在 Google 上集中管理，同时构建到其他云的故障转移策略。出于显而易见的原因，其他公有云不会轻易提供到竞争对手云的复制和故障转移功能——但 MinIO 可以。

现在，让我们总结一下

如引言中所述，我们对 Google Cloud 评价很高。这就是我们进入市场以及支持众多自行构建或运行混合基础设施的客户的原因。话虽如此，我们认为（并且我们承认存在偏见），设计数据架构的最佳方式是使用 GCP 的服务和基础设施以及 MinIO 的对象存储，以确保云内和跨云的兼容性、应用可移植性和简单性。通过这样做，您还可以获得围绕 S3 安全性、弹性、简单性和性能的关键功能。

最好的部分是您可以自己评估我们的立场。查看 市场应用 或自行构建。欢迎您 加入我们的 Slack 进行讨论，或获取 商业许可证 并直接与工程团队联系。