7.9. 调整 Red Hat OpenShift 存储的大小
镜像和对象存储服务可以配置为在 Red Hat OpenShift 后备存储中分配空间。在这种情况下，应该根据这些服务的预期使用 Red Hat OpenShift 存储大小来估算。
7.9.1. 镜像服务注意事项
镜像服务(glance)需要一个暂存区域在导入操作过程中操作数据。镜像数据可以复制到多个存储中，以便镜像服务需要一些持久性。虽然 PVC 代表镜像服务的主要存储模型，但也可以选择外部模型。
外部模型
如果选择了 External，则不会创建 PVC，镜像服务的行为与没有提供持久性的无状态实例类似。在本实例中，必须使用 extraMounts 提供持久性。NFS 通常用于提供持久性。它可以映射到 /var/lib/glance ：
...
default:
storage:
external: true
...
...
extraMounts:
- extraVol:
- extraVolType: NFS
mounts:
- mountPath: /var/lib/glance/os_glance_staging_store
name: nfs
volumes:
- name: nfs
nfs:
path: <nfs_export_path>
server: <nfs_ip_address>-
将
<nfs_export_path> 替换为 NFS 共享的导出路径。 -
将
<nfs_ip_address> 替换为 NFS 共享的 IP 地址。此 IP 地址必须是覆盖网络的一部分，该网络可由镜像服务访问。
应该注意的是，配置示例与分布式镜像导入功能冲突。分布式镜像导入需要 RWO 存储插入到特定实例中；它拥有数据，并在上传操作需要暂存数据时接收请求。当采用外部模型时，如果将 Red Hat Ceph Storage 用作后端，并且镜像转换操作在其中一个现有副本中运行，则 glance-operator 不必对与 staging 区域关联的底层存储进行任何假设，并且使用 os_glance_staging_store 目录的 转换操作（具有 Pod）与 RWX NFS 后端交互。在这种情况下，不能请求镜像缓存 PVC 并挂载到 subPath，因为它应该是管理员使用 extraMounts 来计划持久性的责任。
PVC 模型
PVC 模型是默认的。部署 GlanceAPI 实例时，会根据 storageClass 和 storageRequest 传递，创建 PVC 并绑定到 /var/lib/glance。
...
default:
replicas: 3
storage:
storageRequest: 10G
...
在这个模型中，如果将 Red Hat Ceph Storage 设置为后端，则不会创建专用镜像转换 PVC。管理员必须提前考虑 PVC 大小；PVC 的大小应至少为最大转换的镜像大小。同一 Pod 中的并发转换在 PVC 大小方面可能会有问题。如果 PVC 已满且没有足够的空间，转换将失败或无法进行。在之前的转换超过并释放了暂存区域空间后，应重试上传。但是，在不同 Pod 中可能会发生并发转换操作。您应该为特定的 glanceAPI 部署至少 3 个副本。这有助于处理大量操作，如镜像转换。
对于基于 PVC 的布局，以副本形式横向扩展的 glanceAPI 受 storageClass 提供的可用存储的限制，并依赖于 storageRequest。storageRequest 是一个关键参数，可以为所有 glanceAPI 全局定义，或者为每个 API 使用不同的值定义。它会影响每个操作的横向扩展操作。除了 staging 区域所需的本地 PVC 外，也可以启用镜像缓存，它转换为绑定到每个 glanceAPI 实例的额外 PVC。glance-cache PVC 绑定到 /var/lib/glance/image-cache。glance-operator 相应地配置 glanceAPI 实例，同时设置 image_cache_max_size 和 image_cache_dir 参数。镜像缓存 PVC 的数量遵循与本地 PVC 描述的规则相同，请求的 PVC 数量与副本数成比例。
7.9.2. 对象存储服务注意事项
对象存储服务需要存储设备进行数据。这些设备必须在其生命周期内使用相同的主机名或 IP 地址访问。如何实现带有无标头服务的 StatefulSet 的配置。
如果要使用存储卷为工作负载提供持久性，您可以使用 StatefulSet 作为解决方案的一部分。虽然 StatefulSet 中的单个 Pod 容易失败，但持久性 Pod 标识符可以更轻松地将现有卷与替换任何失败的 Pod 匹配。
对象存储服务需要很少的服务来访问这些 PV，并且所有这些 PV 都在单个 pod 中运行。
另外，如果 StatefulSet 被删除，卷不会被删除。不必要的删除 StatefulSet （或整个部署）不会立即造成灾难性数据丢失，但可以从管理员交互中恢复。
无头服务使可以使用 DNS 名称直接访问存储 pod。例如，如果 pod 名称为 swift-storage-0，并且 SwiftStorage 实例命名为 swift-storage，它可以通过 swift-storage-0.swift-storage 访问。这使得它可在对象存储服务环中轻松使用，IP 更改现在为透明的，不需要更新环。
并行 pod 管理会告知 StatefulSet 控制器并行启动或终止所有 Pod，且不会等待 Pod 变为 Running，并在启动或终止另一个 Pod 前完全终止。这个选项只会影响扩展操作的行为。更新不会受到影响。
这需要多个扩展；包括有多个副本的新部署。需要同时创建所有 pod，否则将有没有绑定的 PVC，且无法创建对象存储服务环，最终阻塞这些 pod 的启动。
存储 pod 应该分布到不同的节点上，以避免出现单点故障。具有 preferredDuringSchedulingIgnoredDuringExecution 的 podAntiAffinity 规则用于尽可能将 pod 分发到不同的节点。使用位于不同节点上的单独 storageClass 和 PersistentVolume，可用于强制实施进一步的发布。
对象存储服务后端服务必须只能被其他后端服务和对象存储服务代理访问。要限制访问，添加了 NetworkPolicy 来只允许这些 pod 之间的流量。NetworkPolicy 本身依赖于标签，它们必须与允许流量匹配。因此，标签不能唯一；相反，所有 pod 都必须使用相同的标签才能允许访问。这也是 swift-operator 没有使用 lib-common 中的标签的原因。
对象存储服务 ring 需要有关要使用的磁盘的信息，这包括大小和主机名或 IP。当使用 PVC 启动 StatefulSet 时，大小未知，大小要求是一个较低限制，但实际的 PV 可能非常大。
但是，StatefulSet 在 ConfigMap 可用前创建 PVC，并只等待启动 pod，直到这些 pod 可用为止。SwiftRing 协调器正在监视 SwiftStorage 实例，并迭代 PVC 来获取有关使用磁盘的实际信息。绑定这些大小后，会知道大小，swift-ring-rebalance 作业将创建 Swift 环，最终是 ConfigMap。ConfigMap 变为可用后，StatefulSet 将启动服务 pod。
Ring 存储在 SwiftProxy 和 SwiftStorage 实例使用投射卷的 ConfigMap 中。这样便可同时挂载所有必需的文件，而不会将其与其他位置合并。更新的 ConfigMap 将更新这些文件，并且这些更改由 Swift 服务最终重新加载它们。
有些 Operator 使用 customServiceConfig 选项来自定义设置。但是，SwiftRing 实例部署多个后端服务，各自需要自定义特定的文件。因此，在使用 swift-operator 时，只支持将特定密钥用作文件名的 defaultConfigOverwrite。
