7.2. 推荐的可配置存储技术
下表总结了为给定的 OpenShift Container Platform 集群应用程序推荐的可配置存储技术。
存储类型 | ROX footnote:rox[ReadOnlyMany] | RWX footnote:rwx[ReadWriteMany] | Registry | 扩展的 registry | Metrics footnote:metrics-prometheus[Prometheus 是用于 metrics 的底层技术。] | Logging | Apps |
---|---|---|---|---|---|---|---|
Block | 是 footnote:disk[这不适用于物理磁盘、VM 物理磁盘、VMDK、loopback over NFS, AWS EBS,和 Azure 磁盘。] | 否 | 可配置 | 无法配置 | 推荐的 | 推荐的 | 推荐的 |
File | Yes footnote:disk[] | 是 | 可配置 | 可配置 | 可配置 footnote:metrics-warning[对于 metrics,使用 ReadWriteMany (RWX) 访问模式的文件存储不可靠。如果使用文件存储,请不要在配置用于指标数据的 PersistentVolumeClaims 上配置 RWX 访问模式。] | 可配置 footnote:logging-warning[对于 logging,不要使用任何共享的存储。每个 elasticsearch 都需要一个卷。] | 推荐的 |
对象 | 是 | 是 | 推荐的 | 推荐的 | 无法配置 | 无法配置 | 不可配置 footnote:object[对象存储不会通过 OpenShift Container Platform 的 PV/PVC 被使用。应用程序必须与对象存储 REST API 集成。] |
扩展的 registry 是指一个 OpenShift Container Platform registry,它有三个或更多个 pod 运行副本。
7.2.1. 特定应用程序存储建议
测试显示,在 RHEL 中使用 NFS 服务器作为容器镜像 registry 的存储后端可能会出现问题。这包括 OpenShift Container Registry 和 Quay,Cassandra for metrics 存储,以及 Elasticsearch for logging 存储。因此,不推荐使用 NFS 作为 PV 后端用于核心服务。
市场上的其他 NFS 实现可能没有这些问题。如需了解更多与此问题相关的信息,请联络相关的 NFS 厂商。
7.2.1.1. Registry
在一个非扩展的/高可用性 (HA) OpenShift Container Platform registry 集群部署中:
- 首选存储技术是对象存储,然后是块存储。存储技术不需要支持 RWX 访问模式。
- 存储技术必须保证读写一致性。对于应用于生产环境工作负载的 OpenShift Container Platform Registry 集群部署,我们不推荐使用任何 NAS 存储。
-
虽然
hostPath
卷对于一个非扩展的/HA OpenShift Container Platform Registry 是可配置的,但不推荐用于集群部署。
7.2.1.2. 扩展的 registry
在扩展的/HA OpenShift Container Platform registry 集群部署中:
- 首选存储技术是对象存储。存储技术必须支持 RWX 访问模式,且必须保证读写一致性。
- 对于应用于生产环境负载的扩展的/HA OpenShift Container Platform registry 集群部署,不建议使用文件存储和块存储。
- 对于应用于生产环境工作负载的 OpenShift Container Platform Registry 集群部署,我们不推荐使用任何 NAS 存储。
7.2.1.3. 指标
在 OpenShift Container Platform 托管的 metrics 集群部署中:
- 首选存储技术是块存储。
测试显示,使用文件存储会造成大量无法恢复的数据破坏问题,因此不建议在 metrics 中使用文件存储。
市场中某些文件存储可能没有这些问题。如需了解更多与此问题相关的信息,请联络相关的 存储厂商。
7.2.1.4. Logging
在 OpenShift Container Platform 托管的日志集群部署中:
- 首选存储技术是块存储。
- 在带有生产环境负载的托管 metrics 集群部署中不推荐使用 NAS 存储。
测试显示,在 RHEL 中使用 NFS 服务器作为容器镜像 registry 的存储后端可能会出现问题。这包括用于日志存储的 Elasticsearch。因此,不推荐使用 NFS 作为 PV 后端用于核心服务。
市场上的其他 NFS 实现可能没有这些问题。如需了解更多与此问题相关的信息,请联络相关的 NFS 厂商。
7.2.1.5. 应用程序
应用程序的用例会根据不同应用程序而不同,如下例所示:
- 支持动态 PV 部署的存储技术的挂载时间延迟较低,且不与节点绑定来支持一个健康的集群。
- 应用程序开发人员需要了解应用程序对存储的要求,以及如何与所需的存储一起工作以确保应用程序扩展或者与存储层交互时不会出现问题。
7.2.2. 其他特定的应用程序存储建议
-
OpenShift Container Platform 内部
etcd
:为了获得最好的etcd
可靠性,首选使用具有最低一致性延迟的存储技术。 -
强烈建议您使用带有可快速处理串口写入(fsync)的存储的
etcd
,比如 NVMe 或者 SSD。不建议使用 Ceph、NFS 和 spinning 磁盘。 - OpenStack Cinder: OpenStack Cinder 倾向于在 ROX 访问模式中使用案例。
- 数据库:数据库(RDBMS 、nosql DBs 等等)倾向于使用专用块存储来获得最好的性能。