混合云架构针对一致的性能、安全性
和经济性进行了优化。 任何关于混合云的讨论都需要从定义开始。
它不仅仅是公共云和内部部署。
公有云
这是一个越来越大的领域，但从 AWS、Azure、GCP、IBM、阿里巴巴、腾讯和政府云开始。 您的混合云存储软件需要在您的应用程序堆栈运行的任何地方运行。 即使是声称在单一云上运行的公司也不是——总是有其他云。 MinIO 混合云存储解决方案在每个公共云提供商之间提供一致性，从而避免在扩展到新云时重写应用程序的需要。
私有云
Kubernetes 是现代私有云的主要软件架构。 这包括所有 Kubernetes 发行版，例如 VMware (Tanzu)、RedHat (OpenShift)、Rancher/SUSE、HP (Ezmeral) 和 Cisco (IKE)。 要充分利用 Kubernetes，混合云存储解决方案必须是对象存储、软件定义和云原生的。 私有云还包括更多传统的裸机实例，但企业工作负载越来越多地容器化和编排。
边缘网关
边缘是关于将计算移动到生成数据的地方。 处理后，数据将移动到更集中的位置。 边缘存储解决方案必须轻量级、功能强大、云原生且具有弹性，才能在这种混合云架构中运行。 做好这件事非常困难，这就是为什么很少有供应商讨论它，他们也没有一个好的答案——即使是亚马逊也是如此。
混合云存储沿用了在公有云中建立的模型，公有云提供商一致采用了云原生对象存储。 公共云的成功有效地使文件和块存储过时了。 每个新应用程序都是为 AWS S3 API 编写的，而不是 POSIX。 为了像云原生技术一样扩展和执行，必须为 S3 API 重写旧应用程序并重构为微服务以与容器兼容。
Kubernetes 原生设计需要运营商服务来配置和管理多租户对象存储即服务基础设施。 这些租户中的每一个都在自己隔离的命名空间中运行，同时共享底层硬件资源。 运算符模式使用自定义资源定义 (CRD) 扩展了 Kubernetes 熟悉的声明式 API 模型，以执行资源编排、无中断升级、集群扩展等常见操作，并保持高可用性。
MinIO 专为充分利用 Kubernetes 架构而构建。 由于服务器二进制文件快速且轻量级，MinIO 的操作员能够在不耗尽资源的情况下密集地共同定位多个租户。 在 Kubernetes 环境之外改造裸机部署或存储设备只会破坏 Kubernetes 必须提供的所有优势。
混合云存储必须在 API 兼容性、性能、安全性和合规性方面保持一致。 它需要始终独立于底层硬件执行。 任何变化，即使是微小的变化，都可能破坏应用程序 - 造成巨大的运营负担。
因为 MinIO 非常轻量级，我们可以在几分钟内跨公共、私有和边缘推出更新，保持相同的一致体验。 MinIO 抽象了这些架构之间的潜在差异，包括密钥管理、身份管理、访问策略和硬件/操作系统差异。
由于对象存储同时用作主存储和辅助存储，因此需要提供大规模的性能。 从移动/Web 应用程序到 AI/ML，数据密集型工作负载需要底层对象存储的卓越性能。 即使是数据保护工作负载也需要对重复数据删除和快照进行高性能访问。 任何企业都无法承受缓慢的恢复过程。 传统上，这些工作负载需要裸机性能。 现在可以将所有这些工作负载容器化 - 正如公共云提供商的成功所证明的那样。
MinIO 是世界上最快的对象存储，在 NVMe 上的读/写速度为 183 GiB/s 和 171 GiB/s，在 HDD 上为 11 GiB/s 和 9 GiB/s。 在这样的速度下，在任何基础设施上运行的任何混合云架构都可以处理每个工作负载。
许多人认为规模只是指系统可以变得多大。 然而，这种想法忽略了随着环境的发展运营效率的重要性。 无论底层环境如何，混合云对象存储解决方案都必须高效且透明地扩展，并且只需最少的人工交互和最大程度的自动化即可实现。 这只能通过构建在简单架构之上的 API 驱动平台来实现。
MinIO 对简单性的不懈关注意味着可以用最少的人力资源管理大规模、多 PB 的数据基础设施。 这是 API 和自动化的一项功能，并创建了一个环境，可在该环境上创建具有显着可扩展性的混合云存储。
要在混合云中取得成功，存储必须由软件定义。 原因很简单。 硬件设备不在公共云或 Kubernetes 上运行。 公共云存储服务产品并非设计用于在其他公共云、私有云或 Kubernetes 平台上运行。 即使他们这样做了，带宽也会比存储成本更高，因为它们不是为跨网络复制而开发的。 诚然，软件定义的存储可以在公共云、私有云和边缘运行。
MinIO 是作为软件诞生的，可以跨各种操作系统和硬件架构移植。 我们在 AWS、GCP 和 Azure 上运行的 770 万个 IP 就是证据。
混合云对象存储
裸机
纠删码计算器
参考硬件
