Red Hat OpenShift Data Foundation 架构

odf-operator 依赖于 ocs-operator 软件包。它还管理 stc g-operator 的订阅。此外，odf-operator 捆绑包为 OpenShift 控制台的 OpenShift Data Foundation 外部插件定义第二个部署。这会定义基于 nginx 的 Pod，它提供必要的文件来注册 OpenShift Data Foundation 仪表板并将其集成到 OpenShift Container Platform 控制台中。

本图演示了 odf-operator 如何与 OpenShift Container Platform 集成。

图 3.1. OpenShift Data Foundation Operator

odf-operator 创建 Operator Lifecycle Manager Resources CR，它为 Operator 创建一个 订阅。

odf-operator 本身不提供任何数据存储或服务。它作为其他存储系统的集成和管理层存在。

高可用性并不是 odf-operator Pod 的主要要求，与其他多数操作器类似。总体而言，并没有操作需要或受益于流程分布。在当前 Pod 不可用或被删除时，OpenShift Container Platform 会快速启动一个替换的 Pod。

odf-operator 附带一个变量 ConfigMap，可用于修改 Operator 的行为。

要了解 OpenShift Data Foundation 并排除问题，您可以查看以下内容：

需要存在 odf-operator，只要 OpenShift Data Foundation 捆绑包仍然被安装。这是作为 OLM 对 OpenShift Data Foundation CSV 协调的一部分进行管理。至少一个 pod 实例应该处于 Ready 状态。

CRD 等 operator 操作对象不应影响 Operator 的生命周期。创建和删除 StorageClusters 是 Operator 控制之外的操作，必须由管理员发起，或者通过适当的应用程序编程接口(API)调用自动执行。

ocs-operator 没有任何依赖组件。但是，Operator 依赖于是否存在来自其他 Operator 的所有自定义资源定义(CRD)，这些定义在 ClusterServiceVersion (CSV)中定义。

本图演示了 OpenShift Container Storage 如何与 OpenShift Container Platform 集成。

图 3.2. OpenShift Container Storage Operator

这两个 ocs-operator CRD 是：

OCSInitialization 是一个单例 CRD，用于封装应用到 operator 级别的操作。操作器负责确保一个实例始终存在。CR 会触发以下内容：

StorageCluster CRD 代表提供 OpenShift Container Storage 完整功能的系统。它触发操作器，以确保 Rook-Ceph 和 NooBaa CRD 的生成与协调。ocs-operator 算法根据 StorageCluster spec 中的配置生成 CephCluster 和 NooBaa CRD。Operator 还会创建额外的 CR，如 CephBlockPools 和Routes 等。启用 OpenShift Container Storage 的不同功能需要这些资源。目前，每个 OpenShift Container Platform 集群只支持一个 StorageCluster CR。

ocs-operator 会根据定义的 CRD 的 spec 创建以下 CR。可以覆盖其中部分资源的配置，允许更改生成的 spec 或不能完全创建这些资源。

ocs-operator 都部署或协调 OpenShift Data Foundation 的其他 Pod。ocs-operator CSV 定义顶层组件，如 operator Deployments，Operator Lifecycle Manager(OLM)协调指定的组件。

高可用性并不是 ocs-operator Pod 的主要要求，与其他多数操作器类似。总体而言，并没有操作需要或受益于流程分布。在当前 Pod 不可用或被删除时，OpenShift Container Platform 会快速启动一个替换的 Pod。

ocs-operator 配置完全由 CSV 指定，在没有 CSV 自定义构建的情况下不可修改。

要了解 OpenShift Container Storage 并排除问题，您可以参阅以下内容：

只要仍然安装了 OpenShift Container Storage 捆绑包，就需要 ocs-operator。这是作为 OLM 对 OpenShift Container Storage CSV 协调的一部分进行管理。至少一个 pod 实例应该处于 Ready 状态。

CRD 等 operator 操作对象不应影响 Operator 的生命周期。OCSInitialization CR 应始终存在。如果不存在，Operator 会创建一个。创建和删除 StorageClusters 是在 Operator 控制之外的操作，必须由管理员发起，或者使用适当的 API 调用自动执行。

Rook-Ceph 操作器管理许多组件，作为 OpenShift Data Foundation 部署的一部分。

下图说明了 Ceph Rook 如何与 OpenShift Container Platform 集成。

图 3.3. Rook-Ceph Operator

当 Ceph 在 OpenShift Container Platform 集群中运行时，OpenShift Container Platform 应用程序可以挂载由 Rook-Ceph 管理的块设备和文件系统，或者使用 S3/Swift API 进行对象存储。

Rook-Ceph 操作器是一个引导和监控存储集群的容器。它执行以下功能：

Rook-Ceph 操作器镜像包含管理集群所需的所有工具。数据路径没有改变。但是，操作器不会公开所有 Ceph 配置。PG 和 crush map 等许多 Ceph 功能都隐藏给用户，在物理资源、池、卷、文件系统和存储桶方面提供更好的用户体验。

rook-Ceph operator 添加了对在 openshift-storage 命名空间中创建的所有资源的所有者引用。卸载集群时，所有者会引用确保资源都已清理。这包括 OpenShift Container Platform 资源，如 configmaps, secrets, services, deployments, daemonsets 等。

Rook-Ceph 操作器监视 CR，以配置由 OpenShift Data Foundation 决定的设置，其中包括 CephCluster、CephObjectStore、CephFilesystem 和 CephBlockPool。

rook-Ceph 操作器管理 Ceph 集群中以下 pod 的生命周期：

MCG 操作器没有子组件。但是，它由一个协调循环组成，用于由它控制的不同资源。

MCG 操作器具有命令行界面(CLI)，并作为 OpenShift Data Foundation 的一部分提供。它支持创建、删除和查询各种资源。此 CLI 在应用配置前添加了一个输入和状态验证层，这与直接应用 YAML 文件不同。

MCG Operator 协调并负责自定义资源定义(CRD)和 OpenShift Container Platform 实体。

根据 OpenShift Container Platform 运行的平台，作为部署的一部分创建默认后备存储。例如，当 OpenShift Container Platform 或 OpenShift Data Foundation 部署在 Amazon Web Services(AWS)上时，它会生成一个默认的后备存储，即 AWS::S3 存储桶。同样，对于 Microsoft Azure，默认后备存储是一个 blob 容器，以此类推。

默认后备存储使用云凭证操作器的 CRD 创建，该 CRD 附带了 OpenShift Container Platform。可添加到 MCG 的后备存储的数量没有限制。bucket 类 CRD 中使用后备存储来定义存储桶的不同策略。参考特定 OpenShift Data Foundation 版本的文档，以确定作为后备存储支持的服务或资源的类型。

部署期间会创建一个默认的 bucket 类，它使用使用默认后备存储的放置策略进行设置。对可添加的 bucket 类数量没有限制。

请参阅特定 OpenShift Data Foundation 版本的文档，以确定受支持的策略类型。

作为操作器，唯一提供的高可用性是 OpenShift Container Platform 重新调度失败的 pod。

要排除 NooBaa Operator 的问题，您可以查看以下内容：

在部署 OpenShift Data Foundation 并卸载前，MCG 操作器会运行和协调。

内部和外部附加存储集群的设置过程相同，如下所示：

对于外部存储集群，ocs-operator 的设置过程略有不同。ocs-operator 会查找是否存在 rook-ceph-external-cluster-details ConfigMap，该 ConfigMap 必须由其他人（管理员或控制台）创建。有关如何创建 ConfigMap 的详情，请参考为外部模式创建 OpenShift Data Foundation。然后，ocs-operator 会创建部分或全部以下资源，如 ConfigMap 中指定的：

创建 ConfigMap 中指定的资源后，StorageCluster 创建过程会进行如下：

在这种模式中，不会创建 CephCluster。相反，会使用默认值创建一个 NooBaa 系统 CR，以利用 OpenShift Container Platform 中的预先存在的 StorageClasses。

下图显示了使用 Multus 公共网络的 OpenShift Data Foundation 部署的集群网络架构：

图 6.2. 使用 Multus 公共网络部署 OpenShift Data Foundation

此架构实现 Multus 网络的所有三个优点：

但是，如果公共网络的吞吐量低于 Pod 网络，存储流量可能比传统部署要快。

公共网络是大多数 OpenShift Data Foundation 集群部署的推荐架构。在这个架构中，所有存储流量都使用专用的公共网络，其中包括来自应用程序的 I/O 流量、存储系统中的数据复制流量以及存储系统中的数据恢复流量。

下图显示了使用 Multus 公共网络和 Multus 集群网络网络的 OpenShift Data Foundation 部署的集群网络架构：

图 6.3. 使用 Multus 公共网络和 Multus 集群网络的集群网络架构

当同时使用公共和集群网络时，Multus 的所有三个优势都会实现。在这种情况下，每个存储网络在 OpenShift Data Foundation 集群中执行特定的角色。公共网络仅处理来自应用程序和集群网络的 I/O 流量，用于处理存储复制和恢复流量。

集群网络定期处理数据复制流量。假设 OpenShift Data Foundation 的默认 3x 复制，集群网络会处理每个数据写入的应用程序 I/O 流量，以将存储数据总数复制到 3x。在存储节点或区故障事件中，集群网络也会处理集群中的恢复数据。

在这个构架中，集群网络的大小建议 2-3x 大于公共网络。较大的大小可以缩短故障转移时间，但也会在正常的集群操作过程中造成大量带宽。存储故障事件期间的总存储带宽可能会受到公共或集群网络的限制，具体取决于网络的大小。

这个架构比推荐的仅公共架构复杂，且有多个可能会影响用户 SLO 的因素。因此，作为替代方案，OpenShift Data Foundation 建议将所有存储网络接口绑定到一起，以创建单个、更大的公共网络。

下图显示了使用 Multus 集群网络的 OpenShift Data Foundation 部署的集群网络架构：

图 6.4. 集群网络架构

在集群网络架构中，部分实现 Multus 的好处。集群网络获取复制和恢复角色。OpenShift Pod 网络从应用中获取处理存储 I/O 的角色。这样可保证减少非邻居干扰，但应用程序 I/O 仍然会受到其他应用程序网络的影响，反之亦然。

由于软件定义的 Pod 网络，应用程序 I/O 到存储系统应该比其他 Multus 架构有更高的延迟。同样，存储网络不会与应用程序隔离。例如，特权 Pod 仍然可以 snoop 存储流量。

Multus 网络的一般要求如下：

带有 Multus 的 OpenShift Data Foundation 在每个存储网络接口上创建多个虚拟 MAC 地址。这需要网卡和切换硬件来支持混杂模式。有些智能交换机具有检查每个数据包的安全进程，这些交换机可能会因为 OpenShift Data Foundation 的大量 MAC 地址而出现大量。最好禁用需要高级处理的智能交换机安全功能。

同样，虚拟或软件交换机可能会难以处理大量 MAC 地址。有些无法禁用此功能。因此，不要在没有支持例外的情况下使用虚拟交换机。

要使 OpenShift Data Foundation 持久性卷声明(PVC)正常工作，部署到每个 OpenShift 节点(worker 和存储)的 Ceph-CSI 驱动程序 pod 必须使用主机网络。Ceph-CSI 驱动程序还必须能够通过 Multus 公共网络访问 OpenShift Data Foundation Ceph 集群。这意味着每个 OpenShift 节点都必须与公共网络连接，反之亦然。

要使它尽可能简单，且无 IP 重叠问题的风险，请为连接到公共网络的节点连接选择不同的子网(IP 范围)。在节点公共子网和 Pod 公共子网上设置路由，以便它们相互路由。最后结果是，节点公共子网和 Pod 公共子网将作为一个连续的公共网络一起充当一个连续的公共网络。

如果使用集群网络，请不要将 Pod 公共网络或节点公共网络路由到集群网络。集群网络应独立且隔离。下图演示了子网路由要求：

图 6.5. 子网路由要求

带有 Multus 的 OpenShift Data Foundation 需要每个 OpenShift Data Foundation Ceph 存储守护进程的 IP 地址。网络必须具有足够的 IP 地址才能考虑附加到网络的存储 pod 数量，以及一些额外的空间才能考虑故障转移事件。以后扩展网络可能需要停机，因此建议为可预见的集群大小分配空间。

对于 Multus 公共网络，必须规划以下范围：

对于 Multus 集群网络，必须计划以下范围：

Red Hat Ceph underpins OpenShift Data Foundation。Red Hat Ceph 网络建议对于了解 OpenShift Data Foundation Multus 网络以及查找特定建议很有用。如需更多信息，请参阅链接： 适用于 OpenShift Data Foundation 网络的 Red Hat Ceph Storage 的网络注意事项。

下表建议每个 Multus 网络或子网的 IP 范围：

这应该足以满足大多数机构的需要。建议使用保留专用地址空间(192.168.0.0/16)的最后 6.25%(1/16th)。记录大约的最大 ODF 和 OpenShift 大小，以便有 25% 开销安全处理失败事件。

下图显示了为每个节点类型计划的接口和连接示例：

图 6.6. 接口和连接示例

本例包括集群网络以实现完整性。

在本例中，vlan220 (public)和 vlan221 (cluster)是要用于 OpenShift Data Foundation 配置的接口。如果部署的环境中 VLAN 未使用，则将改为使用 bond1 和 bond2。如果没有使用绑定或 VLAN，则使用主机接口（如 eth 2、eth4）。OpenShift Data Foundation

对于仅使用公共网络的 OpenShift Data Foundation Multus 架构（大多数用户推荐），可以使用上例中的相同节点。eth0、eth1、eth2 和 eth4 将绑定为 bond1，并标记为 vlan220。此架构确保存储节点具有额外的可用带宽，用于 OpenShift Data Foundation Ceph OSD 所需的复制和恢复。vlan220 用于 OpenShift Data Foundation 配置。但是，存在许多有效环境的变体。

图 6.7. 推荐的主机接口连接

不需要将额外的公共网络带宽专用于存储节点，但这很有用。eth4 和 eth5 可以从存储节点完全省略，将相同的带宽专用于 worker 和存储节点。客户环境中经常看到这种设计。

或者，eth2 和 eth3 可以在存储节点上具有较高的吞吐量接口（例如，worker 节点上的 10Gbps 和 25Gbps 存储节点为 25Gbps）。这允许更多存储节点带宽，同时仍然仅在存储节点上使用两个接口。

示例的建议 Pod 公共网络配置如下。如果没有使用 Multus 公共网络，则省略此项。确保包含 routes 部分，以允许公共网络上的 Pod 通过公共网络访问节点。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: public-net
  namespace: openshift-storage
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "type": "macvlan",
      "master": "vlan220", # host public network interface
      "mode": "bridge",
      "ipam": {
        "type": "whereabouts",
        "range": "192.168.240.0/21", # pod public network range
        "routes": [
          {"dst": "192.168.252.0/23"} # node public network range
        ]
      }
    }

示例的建议 Pod 集群网络配置如下。如果没有使用 Multus 集群网络，则省略此项（大多数用户推荐）。此配置不应具有 routes 部分。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: cluster-net
  namespace: openshift-storage
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "type": "macvlan",
      "master": "vlan221", # host cluster network interface
      "mode": "bridge",
      "ipam": {
        "type": "whereabouts",
        "range": "192.168.248.0/22" # pod cluster network range
      }
    }

OpenShift worker 和存储节点必须配置为通过主机公共网络接口将主机流量路由到公共网络上的 Pod。

配置节点的建议方法是使用 OpenShift NodeNetworkConfigurationPolicy 对象。无论部署策略是什么，所有 OpenShift 用户都可支持此方法。此方法需要安装并启用 NMState Operator。如需更多信息，请参阅链接： Kubernetes NMState Operator。

每个节点都必须获取节点公共网络地址范围内的 ODF 公共网络上的 IP 地址。静态 IP 地址管理是唯一可以支持任何 OpenShift 集群的 IPAM 方法。因此，静态管理是 OpenShift Data Foundation 只支持静态管理方法。这每个主机都需要一个 NodeNetworkConfigurationPolicy 对象。可用于配置主机的模板如下所示。

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ceph-public-net-shim-{{NODE_NAME}}
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    kubernetes.io/hostname: {{NODE_NAME}}
  desiredState:
    interfaces:
      - name: odf-pub-shim
        description: Shim interface to connect to ODF public network
        type: mac-vlan
        state: up
        mac-vlan:
          base-iface: vlan220 # host public network interface
          mode: bridge
          promiscuous: true
        ipv4:
          enabled: true
          dhcp: false
          address:
            - ip: 192.168.252.1 # static IP in node public network range
              prefix-length: 23 # node public network range mask
    routes:
      config:
        - destination: 192.168.240.0/21 # pod public network range
          next-hop-interface: odf-pub-shim

首先，请按照模板中的注释为要部署的环境更新基本模板。然后，对于每个节点，复制模板，然后填写 {{NODE_NAME}} 和每个节点的唯一静态 IP。

除了 OpenShift Data Foundation 健康检查外，请通过执行以下操作确保 Multus 配置为预期：