实例存储解决方案

作为计算集群架构设计的一部分,您必须指定实例运行的磁盘的存储。提供临时存储的主要方法有三种

  • 计算节点之外的存储 — 共享文件系统

  • 计算节点上的存储 — 共享文件系统

  • 计算节点上的存储 — 非共享文件系统

通常,在选择存储时,您应该考虑以下问题

  • 我的工作负载是什么?

  • 我的工作负载是否有 IOPS 要求?

  • 是否有读取、写入或随机访问性能要求?

  • 我对计算存储的扩展有什么预测?

  • 我的企业目前正在使用什么存储?是否可以重新利用?

  • 我如何操作性地管理存储?

许多运维人员使用独立的计算和存储主机,而不是超融合解决方案。计算服务和存储服务具有不同的要求,计算主机通常比存储主机需要更多的 CPU 和 RAM。因此,对于固定的预算,为您的计算节点和存储节点配置不同的配置是合理的。计算节点将投资于 CPU 和 RAM,而存储节点将投资于块存储。

但是,如果您在创建云的可用物理主机数量上受到更多限制,并且希望尽可能多地将您的主机用于运行实例,那么在同一台机器上运行计算和存储或使用可用的现有存储阵列是合理的。

在接下来的几个部分中,将提供三种主要的实例存储方法。

非计算节点基于的共享文件系统

在这种选项中,存储正在运行的实例的磁盘托管在计算节点之外的服务器中。

如果您使用独立的计算和存储主机,您可以将您的计算主机视为“无状态”。只要您没有在计算主机上运行任何实例,就可以将其离线或完全擦除,而不会对您的云的其余部分产生任何影响。这简化了计算主机的维护。

这种方法有几个优点

  • 如果计算节点发生故障,实例通常可以轻松恢复。

  • 运行专用的存储系统在操作上可能更简单。

  • 您可以扩展到任意数量的磁盘。

  • 可以将外部存储用于其他目的。

这种方法的主要缺点是

  • 根据设计,某些实例的密集 I/O 使用情况可能会影响不相关的实例。

  • 网络的使用会降低性能。

  • 网络架构会影响可扩展性。

计算节点上的存储 — 共享文件系统

在这种选项中,每个计算节点都指定了大量的磁盘空间,但一个分布式文件系统将每个计算节点的磁盘绑定到一个单一的挂载点。

此选项的主要优点是它可以扩展到外部存储,当您需要额外的存储时。

但是,此选项有几个缺点

  • 运行分布式文件系统可能会导致您与非共享存储相比失去数据局部性。

  • 依赖于多个主机使实例恢复变得复杂。

  • 计算节点的机箱尺寸会限制可以在计算节点中使用的磁盘数量。

  • 网络的使用会降低性能。

  • 计算节点的丢失会降低所有主机的存储可用性。

计算节点上的存储 — 非共享文件系统

在这种选项中,每个计算节点都指定了足够的磁盘来存储它托管的实例。

有两个主要优点

  • 一个计算节点上的密集 I/O 使用不会影响其他计算节点上的实例。直接 I/O 访问可以提高性能。

  • 每个主机可以具有不同的存储配置文件,用于主机聚合和可用区。

有几个缺点

  • 如果计算节点发生故障,与该节点上运行的实例相关的数据将丢失。

  • 计算节点的机箱尺寸会限制可以在计算节点中使用的磁盘数量。

  • 从一个节点到另一个节点的实例迁移更加复杂,并且依赖于可能不再继续开发的特性。

  • 如果需要额外的存储,此选项无法扩展。

在计算节点之外的存储系统上运行共享文件系统非常适合可靠性和可扩展性是最重要的云。在计算节点本身上运行共享文件系统可能最适合您必须部署到预先存在的服务器的场景,您对其规格几乎没有控制权,或者您有特定的存储性能需求,但不需要持久存储。

关于实时迁移的问题

实时迁移是云操作的组成部分。此功能提供了在物理主机之间无缝移动实例的能力,对于执行需要重新启动计算主机的升级是必需的,但只有在共享存储的情况下才能很好地工作。

也可以使用非共享存储进行实时迁移,使用称为 *KVM 实时块迁移* 的功能。虽然 KVM 和 QEMU 中较早的基于块的迁移实现被认为不可靠,但从 Mitaka 版本开始,有一种更新的、更可靠的基于块的实时迁移实现。

实时迁移和块迁移仍然存在一些问题

  • Mitaka 和 Newton 中已经关注错误报告,但仍需要改进。

  • 实时迁移资源跟踪问题。

  • 救援镜像的实时迁移。

文件系统的选择

如果您想支持共享存储实时迁移,则需要配置分布式文件系统。

可能的选项包括

  • NFS(Linux 默认值)

  • Ceph

  • GlusterFS

  • MooseFS

  • Lustre

我们建议您选择运维人员最熟悉的选择。NFS 最易于设置,并且社区对其有广泛的了解。