MinIO | 多云环境对象存储

成功的多云存储策略利用架构
以及能够在广泛的环境中运行的工具。

公有云

这是一个日益庞大的领域，但始于 AWS、Azure、GCP、IBM、阿里巴巴、腾讯和政府云。您的混合/多云存储软件需要在您的应用程序堆栈运行的任何地方运行。即使是声称在单个云上运行的公司也不例外——总会有其他云。MinIO 提供跨每个公有云提供商的存储一致性，避免在扩展到新云时需要重写应用程序。

私有云

Kubernetes 是现代私有云的主要软件架构。这包括所有 Kubernetes 发行版，例如 VMware (Tanzu)、RedHat (OpenShift)、Rancher/SUSE、HP (Ezmeral) 和 Rafay。多云 Kubernetes 需要软件定义且云原生的对象存储。私有云还包括更传统的裸机实例，但企业工作负载正日益容器化和编排。

边缘

边缘是指将计算转移到数据生成的地方。处理后，数据将移动到更集中的位置。边缘存储解决方案必须轻量级、强大、云原生且具有弹性，以便在此多云架构中运行。做好这一点非常困难，这就是为什么很少有供应商讨论它，他们没有一个好的答案——即使是亚马逊。

混合/多云存储的属性

多云存储遵循公有云中建立的模型，公有云提供商已一致采用云原生对象存储。公有云的成功有效地使文件和块存储过时。每个新的应用程序都是针对 AWS S3 API 编写的——而不是 POSIX。为了像云原生技术一样扩展和执行，较旧的应用程序必须针对 S3 API 重写并重构为微服务以与容器兼容。

Kubernetes 原生

Kubernetes 原生设计需要一个 Operator 服务来配置和管理多租户对象存储即服务基础设施。这些租户中的每一个都在自己的隔离命名空间中运行，同时共享底层硬件资源。Operator 模式通过自定义资源定义 (CRD) 扩展 Kubernetes 熟悉的声明式 API 模型，以执行常见的操作，例如资源编排、无中断升级、集群扩展和维护高可用性。

MinIO 专门构建以充分利用 Kubernetes 架构。由于服务器二进制文件快速且轻量级，MinIO Operator 能够密集地共置多个租户而不会耗尽资源。利用可移植的 Kubernetes 原生存储获得多云能力，该存储利用 Kubernetes 和相关生态系统的优势。

一致性

混合/多云存储必须在 API 兼容性、性能、安全性和合规性方面保持一致。它需要根据底层硬件始终如一地独立执行。任何变化，即使是最微小的变化，也可能破坏应用程序——造成巨大的运营负担。

由于 MinIO 非常轻量级，我们可以在几分钟内跨公有云、私有云和边缘推出无中断更新，保持相同的持续体验。MinIO 抽象了这些架构之间的底层差异，包括密钥管理、身份管理、访问策略以及硬件/操作系统差异。

高性能

由于对象存储用作主存储和辅助存储，因此它需要提供大规模性能。从移动/Web 应用程序到 AI/ML，数据密集型工作负载需要底层对象存储提供卓越的性能。即使是数据保护工作负载也需要高性能访问才能进行重复数据删除和快照。任何企业都无法承受缓慢的恢复过程。传统上，这些工作负载需要裸机性能。现在，所有这些工作负载都可以容器化——正如公有云提供商的成功所证明的那样。

MinIO 是世界上最快的对象存储，在 NVMe 上的读/写速度分别为 325 GiB/s 和 171 GiB/s，在 HDD 上分别为 11 GiB/s 和 9 GiB/s。以这些速度，每个工作负载都可以在任何基础设施上运行的任何多云架构中触手可及。

可扩展性

许多人认为扩展仅仅指的是系统可以达到的规模。但是，这种思维方式忽略了随着环境增长运营效率的重要性。多云对象存储解决方案必须能够高效且透明地扩展，而不管底层环境如何，并且只需最少的人工干预和最大程度的自动化即可实现。这只能通过构建在简单架构之上的 API 驱动的平台来实现。

MinIO 对简单性的不懈追求意味着，可以使用最少的人力资源管理大型的多 PB 数据基础设施。这是 API 和自动化的功能，并创建了一个环境，在此环境上可以创建可扩展性显著的多云存储。

软件定义

在多云中取得成功的唯一方法是使用软件定义的存储。原因很简单。硬件设备不能在公有云或 Kubernetes 上运行。公有云存储服务产品并非旨在在其他公有云、私有云或 Kubernetes 平台上运行。即使它们确实如此，带宽的成本也会高于存储，因为它们并非为跨网络复制而开发。确实，软件定义的存储可以在公有云、私有云和边缘运行。

MinIO 起源于软件，可在各种操作系统和硬件架构中移植。证据可以在我们运行在 AWS、GCP 和 Azure 上的 200 多万个 IP 中找到。