运行在谷歌云平台上的 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 的第二种方法是通过“自己动手”的方法。今天有超过 150,000 个这样的部署在 GCP 上运行。使“自己动手”更容易的一种方法是利用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 提供的所有公共云上本地运行。

最终效果是简化应用程序开发并提供对跨云数据的同构应用程序访问。

虽然我们是谷歌云的忠实粉丝——它有令人难以置信的基础设施选项和一些令人惊叹的服务（其中一个是 BigQuery……）——但 GCS 对象存储 API 是主要云中采用最少的。这可能会给应用程序开发、应用程序集成甚至开发人员的熟悉程度带来问题。例如，客户发现谷歌在 ACL、CORS 结构和对象生命周期策略等元素中对 S3 API 的实施存在应用程序破坏性差异。

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

利用多个存储层提高应用程序效率

稍微切换一下，MinIO 中还内置了一些非常复杂的功能，这些功能在 GCP 内部运行得非常好，并进一步增强了在那里运行它的理由。这些功能集之一是数据生命周期管理。使用 MinIO 本机工具——在界面选项（Operator、Console、mc、CLI）中可用——用户可以配置 MinIO，以便将数据分层到从 TPC 实例到不经常访问的 HDD 的任何 Google 存储层选项。这些策略甚至可以管理数据到其他云或本地实例的分层。您的业务需求就是指南——MinIO 成为支持软件。

例如，我们可以使用裸机本地 NVMe 存储将 MinIO 配置为具有最大“热层”吞吐量，然后将 HDD 作为暖层，将 Google Cloud Storage 作为第三层以实现可扩展性。再加上多云、主动-主动复制的腰带和吊带选项，您可以集中在 Google 上，同时构建到其他云的故障转移策略。出于显而易见的原因，其他公共云无法轻松实现到竞争云的复制和故障转移——但 MinIO 做到了。

现在都在一起了

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

最好的部分是您可以自己评估我们的立场。查看市场应用程序或推出自己的应用程序。欢迎加入我们的 Slack讨论或获得商业许可并直接与工程团队交谈。