规划部署

在 Red Hat OpenShift Container Platform 中完全部署 Red Hat OpenShift Data Foundation 具有基于 Operator 的部署和管理优势。您可以使用图形用户界面(GUI)中的内部附加设备方法，使用本地存储 operator 和本地存储设备以内部模式部署 Red Hat OpenShift Data Foundation。

易于部署和管理是在 OpenShift Container Platform 内部运行 OpenShift Data Foundation 服务的关键。当 Red Hat OpenShift Data Foundation 完全在 Red Hat OpenShift Container Platform 中运行时，可以使用两种不同的部署模式：

简单的部署最适合以下情况，

要使 Red Hat OpenShift Data Foundation 与应用程序共同运行，节点必须具有动态附加本地存储设备或可移植存储设备，如 EC2 上的 EBS 卷或 VMware 上的 vSphere 虚拟磁盘或 SAN 卷。

优化的方法最适合以下情况，

Red Hat OpenShift Data Foundation 将 OpenShift Container Platform 集群外运行的 Red Hat Ceph Storage 服务作为存储类公开。

在以下情况下最适合使用外部方法：

Red Hat OpenShift Data Foundation 支持存储集群中所有磁盘和多云对象网关操作的集群范围加密 (encryption-at-rest)。OpenShift Data Foundation 使用基于 Linux 统一密钥系统 (LUKS) 版本 2 的加密，其密钥大小为 512 位，以及 aes-xts-plain64 密码，其中每个设备都有不同的加密密钥。密钥使用 Kubernetes secret 或外部 KMS 存储。两种方法都是互斥的，您不能在方法之间迁移。

对于块存储和文件存储，默认会禁用加密。您可以在部署时为集群启用加密。MultiCloud 对象网关默认支持加密。如需更多信息，请参阅部署指南。

集群范围内的加密在没有 Key Management System (KMS) 的 OpenShift Data Foundation 4.6 中被支持。从 OpenShift Data Foundation 4.7 开始，使用和不使用 HashiCorp Vault KMS 都被支持。从 OpenShift Data Foundation 4.12 开始，使用和不使用 HashiCorp Vault KMS 和 Thales CipherTrust Manager KMS 都被支持。

安全常见实践需要定期加密密钥轮转。Red Hat OpenShift Data Foundation 每周自动轮转 kubernetes secret 中存储的加密密钥。

使用 HashiCorp Vault KMS 进行集群范围内的加密提供了两种身份验证方法：

您可以使用外部密钥管理系统 (KMS) 使用存储类加密来加密持久性卷（仅限块）来存储设备加密密钥。永久卷加密仅可用于 RADOS 块设备 (RBD) 持久卷。请参阅 如何使用持久性卷加密创建存储类。

存储类加密在使用 HashiCorp Vault KMS 的 OpenShift Data Foundation 4.7 或更高版本中被支持。存储类加密在使用 HashiCorp Vault KMS 和 Thales CipherTrust Manager KMS 的 OpenShift Data Foundation 4.12 或更高版本中被支持。

Red Hat OpenShift Data Foundation 版本 4.12 引入了 Thales CipherTrust Manager 作为部署的附加密钥管理系统 (KMS) 供应商。Thales CipherTrust Manager 提供了中央化的密钥生命周期管理功能。CipherTrust Manager 支持密钥管理互操作性协议(KMIP)，它启用了密钥管理系统之间的通信。

CipherTrust Manager 在部署期间被启用。

从 OpenShift Data Foundation 版本 4.14 开始，可以使用 Red Hat Ceph Storage 的 messenger 版本 2 协议来加密转换数据。这为您的基础架构提供重要的安全要求。

在创建集群时，可以在部署期间启用 in-transit 加密。有关在集群创建过程中启用数据加密的说明，请参阅环境的 部署指南。

msgr2 协议支持两种连接模式：

crc

secure

默认模式是 crc。

确定特定系统是否消耗一个或多个内核目前取决于配置的并发多线程级别 (SMT)。IBM Power 为每个内核提供并发多线程级别 1、2、4 或 8，每个内核对应于下表中的 vCPU 数量。

对于配置 SMT 的系统，用于订阅所需的内核数取决于 SMT 级别。因此，2 核订阅对于 SMT 级别 1 是 2 个 vCPU、对于 SMT 级别 2 是 4 个 vCPU，对于 SMT 级别 4 是 8 个 vCPU，对于 SMT 级别 8 是 16 个 vCPU，如上表所示。一个大型虚拟机 (VM) 可能有 16 个 vCPU，在 SMT 级别 8 中，需要一个 2 核订阅。计算方法是 vCPU 的数量除以 SMT 级别（对于 SMT-8，16 个 vCPU / 8 = 2）。当订阅以 2 核为单位时，您将需要一个 2 核订阅来满足这 2 个内核或 16 个 vCPU。

IBM Power 有共享处理器池的概念。共享处理器池中的处理器可以在集群的节点之间共享。Red Hat OpenShift Data Foundation 所需的聚合计算容量应当是多个内核对。

只支持内部 Red Hat OpenShift Data Foundation 集群。

内部集群必须满足存储设备要求，并且具有通过 aws-ebs 置备程序提供 EBS 存储的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

OpenShift Data Foundation 支持由 Amazon Web Services (AWS) 提供的 gp2-csi 和 gp3-csi 驱动程序。这些驱动程序提供更好的存储扩展功能，并减少了每月的价格点 (gp3-csi)。现在，您可以在选择存储类时选择新驱动程序。如果需要高吞吐量，建议在部署 OpenShift Data Foundation 时使用 gp3-csi。

如果您需要每秒的高输入/输出操作(IOPS)，则推荐的 EC2 实例类型为 D2 或 D3。

支持内部集群和使用外部集群。

内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD (NVMe/SATA/SAS、SAN)的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

支持内部集群和使用外部集群。

推荐的版本：

如需了解更多详细信息，请参阅 VMware vSphere 基础架构要求。

另外，内部集群必须满足存储设备要求，并具有提供存储类的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

只支持内部 Red Hat OpenShift Data Foundation 集群。

内部集群必须满足存储设备要求，并且具有通过 azure-disk 置备程序提供 azure 磁盘的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

只支持内部 Red Hat OpenShift Data Foundation 集群。

内部集群必须满足存储设备要求，并且具有通过 gce-pd 置备程序提供 GCE Persistent Disk 的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

支持内部 Red Hat OpenShift Data Foundation 集群和使用外部集群。

内部集群必须满足存储设备要求，并且具有通过 Cinder 置备程序提供标准磁盘的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

支持内部 Red Hat OpenShift Data Foundation 集群和使用外部集群。

内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD (NVMe/SATA/SAS、SAN)的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

支持内部 Red Hat OpenShift Data Foundation 集群。另外，支持在 x86 上运行 Red Hat Ceph Storage 的外部模式。

内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD (NVMe/SATA/SAS、SAN)的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

只支持内部 Red Hat OpenShift Data Foundation 集群。

内部集群必须满足存储设备要求，并且具有通过 gp3-csi 置备程序提供 AWS EBS 卷的存储类。

支持内部集群和使用外部集群。

内部集群必须满足存储设备要求，并且具有通过 Local Storage Operator 提供本地 SSD (NVMe/SATA/SAS、SAN)的存储类。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#storage-device-requirements_rhodf

要以外部模式检查 Red Hat Ceph Storage (RHCS) 与 Red Hat OpenShift Data Foundation 的支持性和互操作性，请转至 lab Red Hat OpenShift Data Foundation 支持性和互操作性检查器。

有关如何安装 RHCS 集群的说明，请参阅 安装指南。

要将 IBM FlashSystem 用作其他供应商上的可插拔外部存储，您需要先部署它，然后才能部署 OpenShift Data Foundation，这会使用 IBM FlashSystem 存储类作为后备存储。

有关最新支持的 FlashSystem 存储系统和版本，请参阅 IBM ODF FlashSystem 驱动程序文档。

有关如何部署 OpenShift Data Foundation 的说明，请参阅 为外部 IBM FlashSystem 存储创建 OpenShift Data Foundation。

Red Hat OpenShift Data Foundation 服务由一组初始的基础服务组成，并可使用附加设备集进行扩展。

所有这些 Red Hat OpenShift Data Foundation 服务 pod 都由 OpenShift Container Platform 节点上的 kubernetes 调度。以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则的一种简单方法。

当不符合标准部署资源要求时，将使用最低配置部署 OpenShift Data Foundation 集群。

如果要添加额外的设备集，我们建议将最小部署转换为标准部署。

Red Hat OpenShift Data Foundation 可以安装到三节点 OpenShift 紧凑裸机集群中，所有工作负载都在三个强大的 master 节点上运行。没有 worker 或存储节点。

要在紧凑的裸机集群中配置 OpenShift Container Platform，请参阅配置三节点集群 和 为 Edge Deployment 提供三节点架构。

仅使用 Multicloud Object Gateway(MCG)组件部署的 OpenShift Data Foundation 集群在部署时提供了灵活性，有助于减少资源消耗。

您可以使用网络文件系统(NFS)创建导出，然后可以从 OpenShift 集群外部访问。如果您计划使用这个功能，NFS 服务会消耗 3 个 CPU 和 8Gi 内存。NFS 是可选的，并默认禁用。

NFS 卷可以通过两种方式访问：

有关 NFS 功能的更多信息，请参阅使用 NFS 创建导出

OpenShift Data Foundation 提供三个性能配置集，以增强集群的性能。您可以根据部署期间的可用资源和所需的性能级别选择其中一个配置集。

Red Hat OpenShift Data Foundation 允许选择 0.5 TiB、2 TiB 或 4 TiB 容量作为动态存储设备大小的请求大小。可以每个节点运行的动态存储设备数量取决于节点大小、底层置备程序限制 和资源要求。

对于本地存储部署，可以使用任何大小为 16 TiB 或更少的磁盘大小，并且所有磁盘的大小和类型都应相同。可以每个节点运行的本地存储设备数量是节点大小和资源要求的功能。https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/planning_your_deployment/index#resource-requirements_rhodf以三个节点（每个故障域中一个节点）来扩展集群是满足 pod 放置规则 的一种简单方法。

始终确保可用的存储容量保持领先于消费。如果可用存储容量已完全耗尽，则需要更多的干预，而不是简单地添加容量或删除或迁移内容。

当集群存储容量达到总容量的 75%（接近满）和 85%（满）时，会发出容量警报。始终及时处理容量警告，并定期检查您的存储以确保您不会耗尽存储空间。达到 75%（接近满）时，释放空间或扩展集群。当您收到 85%（满）警报时，这表示您已完全耗尽存储空间，并且无法使用标准命令释放空间。此时，请联系红帽客户支持。

下表显示了带有动态存储设备的 Red Hat OpenShift Data Foundation 节点配置示例。

为了使 Ceph-CSI 与启用了 Multus 的 CephCluster 通信，Kubernetes 主机需要一些设置。

这些先决条件需要了解 Multus 网络的配置方式以及 Rook 如何使用它们。本节将有助于说明可能出现的问题。

必须满足两个基本要求：

这两个要求可以进一步划分，如下所示：

节点配置和 pod 配置是相互相关的且紧密耦合。必须同时计划这两者，而 OpenShift Data Foundation 不支持 Multus 公共网络，而无需两者。

对于这两者，"public-network-interface"必须相同。通常，连接技术(Macvlan)对于两者来说也应该相同。NetworkAttachmentDefinition 中的 IP 范围必须编码为节点上的路由，而 mirror 中，节点的 IP 范围必须在 NetworkAttachmentDefinition 中编码为路由。

有些安装可能不希望为 pod 和节点使用相同的公共网络 IP 地址范围。如果 pod 和节点有不同的范围，则必须执行额外的步骤来确保每个范围路由到另一个范围，以便它们充当一个连续的网络。这些要求需要仔细规划。请参阅 Multus 示例 来帮助理解并实现这些要求。

OpenShift Container Platform 建议使用 NMState Operator 的 NodeNetworkConfigurationPolicies 作为配置主机要求的好方法。如果需要，也可以使用其他方法。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: multus-public-test
  namespace: openshift-storage
  labels:
    app: multus-public-test
spec:
 selector:
   matchLabels:
     app: multus-public-test
 template:
   metadata:
     labels:
       app: multus-public-test
     annotations:
       k8s.v1.cni.cncf.io/networks: openshift-storage/public-net #
   spec:
     containers:
       - name: test
         image: quay.io/ceph/ceph:v18 # image known to have ‘ping’ installed
         command:
           - sleep
           - infinity
         resources: {}

$ oc -n openshift-storage describe pod -l app=multus-public-test | grep -o -E 'Add .* from .*'
Add eth0 [10.128.2.86/23] from ovn-kubernetes
Add net1 [192.168.20.22/24] from default/public-net
Add eth0 [10.129.2.173/23] from ovn-kubernetes
Add net1 [192.168.20.29/24] from default/public-net
Add eth0 [10.131.0.108/23] from ovn-kubernetes
Add net1 [192.168.20.23/24] from default/public-net

$ oc debug node/NODE
Starting pod/NODE-debug ...
To use host binaries, run `chroot /host`
Pod IP: ****
If you don't see a command prompt, try pressing enter.


sh-5.1# chroot /host


sh-5.1# ping 192.168.20.22
PING 192.168.20.22 (192.168.20.22) 56(84) bytes of data.
64 bytes from 192.168.20.22: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 192.168.20.22: icmp_seq=2 ttl=64 time=0.056 ms
^C
--- 192.168.20.22 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1046ms
rtt min/avg/max/mdev = 0.056/0.074/0.093/0.018 ms


sh-5.1# ping 192.168.20.29
PING 192.168.20.29 (192.168.20.29) 56(84) bytes of data.
64 bytes from 192.168.20.29: icmp_seq=1 ttl=64 time=0.403 ms
64 bytes from 192.168.20.29: icmp_seq=2 ttl=64 time=0.181 ms
^C
--- 192.168.20.29 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1007ms
rtt min/avg/max/mdev = 0.181/0.292/0.403/0.111 ms


sh-5.1# ping 192.168.20.23
PING 192.168.20.23 (192.168.20.23) 56(84) bytes of data.
64 bytes from 192.168.20.23: icmp_seq=1 ttl=64 time=0.329 ms
64 bytes from 192.168.20.23: icmp_seq=2 ttl=64 time=0.227 ms
^C
--- 192.168.20.23 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1047ms
rtt min/avg/max/mdev = 0.227/0.278/0.329/0.051 ms

此集群的相关网络计划如下：

节点的网络策略必须配置为路由到 Multus 公共网络上的 pod。

由于 Pod 将通过 Macvlan 连接，因此 Macvlan 不允许主机和 pod 互相路由，因此还必须通过 Macvlan 连接主机。通常，主机必须使用与 pod 相同的技术连接到 Multus 公共网络。Pod 连接在 Network Attachment 定义中配置。

由于主机 IP 范围是整个范围的子集，因此主机无法仅通过 IP 分配路由到 pod。必须向主机添加路由，以允许它们路由到整个 192.168.0.0/16 范围。

NodeNetworkConfigurationPolicy desiredState specs 将类似如下：

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ceph-public-net-shim-compute-0
  namespace: openshift-storage
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    kubernetes.io/hostname: compute-0
 desiredState:
   interfaces:
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan
       state: up
       mac-vlan:
         base-iface: eth0
         mode: bridge
         promiscuous: true
       ipv4:
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.1 # STATIC IP FOR compute-0
             prefix-length: 22
   routes:
     config:
       - destination: 192.168.0.0/16
         next-hop-interface: odf-pub-shim
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ceph-public-net-shim-compute-1
  namespace: openshift-storage
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    kubernetes.io/hostname: compute-1
 desiredState:
   interfaces:
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan
       state: up
       mac-vlan:
         base-iface: eth0
         mode: bridge
         promiscuous: true
       ipv4:
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.1 # STATIC IP FOR compute-1
             prefix-length: 22
   routes:
     config:
       - destination: 192.168.0.0/16
         next-hop-interface: odf-pub-shim
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ceph-public-net-shim-compute-2 # [1]
  namespace: openshift-storage
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    kubernetes.io/hostname: compute-2 # [2]
 desiredState:
   interfaces: [3]
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan # [4]
       state: up
       mac-vlan:
         base-iface: eth0 # [5]
         mode: bridge
         promiscuous: true
       ipv4: # [6]
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.2 # STATIC IP FOR compute-2 # [7]
             prefix-length: 22
   routes: # [8]
     config:
       - destination: 192.168.0.0/16 # [9]
         next-hop-interface: odf-pub-shim

公共网络的 NetworkAttachmentDefinition 类似，使用 Whereabouts 的 exclude 选项来简化 范围 请求。Whereabouts routes[].dst 选项确保 pod 通过 Multus 公共网络路由到主机。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: public-net
  namespace: openshift-storage
spec:
  config: '{
     "cniVersion": "0.3.1",
     "type": "macvlan", # [1]
     "master": "eth0", # [2]
     "mode": "bridge",
     "ipam": {
       "type": "whereabouts", # [3]
       "range": "192.168.0.0/16", # [4]
       "exclude": [
          "192.168.252.0/22" # [5]
       ],
       "routes": [              # [6]
         {"dst": "192.168.252.0/22"} # [7]
       ]
     }
   }'

由于升级过程中对拥有者 pod 的重复维护影响（当启用 Multus 时存在拥有者 pod），因此拥有者 pod 在 ODF v4.17 版本中已弃用，并在 ODF v4.17 发行版本中删除。此弃用需要在删除拥有者 pod 前完成额外的网络配置操作。在 ODF v4.15 中，启用了 Multus 的集群会根据标准升级步骤升级到 v4.16。当 ODF 集群（启用 Multus）成功升级到 v4.16 后，管理员必须完成文章 Disabling Multus holder pod 中记录的步骤来禁用和删除拥有者 pod。请注意，这个禁用过程会消耗大量时间，但在升级到 v4.16 后，无法立即完成整个进程。在将 ODF 升级到 v4.17 前，务必要完成这个过程。

默认情况下，Red Hat OpenShift Data Foundation 被配置为使用 Red Hat OpenShift Software Defined Network (SDN)。默认 SDN 执行以下类型流量：

通过三种方法将 OpenShift Data Foundation 与 OpenShift 默认网络隔离：

当您需要以下内容时，使用 Multus for OpenShift Data Foundation：

改进了带有 ODF 的延迟 - Multus 始终提高了延迟。在近主机网络速度中使用主机接口，并绕过 OpenShift 软件定义的 Pod 网络。您还可以为每个接口执行每个接口级别的 Linux。

改进了 OpenShift Data Foundation 客户端数据流量和内部数据流量的带宽 Dedicated 接口。这些专用接口保留完整的带宽。

改进了 security - Multus 将存储网络流量与应用程序网络流量隔离，以提高安全性。但是，当网络共享一个接口时，带宽或性能可能无法隔离，但您可以使用 QoS 或流量整形来优先选择共享接口的带宽。

要使用 Multus，您必须在部署 OpenShift Data Foundation 集群前创建网络附加定义(NAD)，该集群稍后附加到集群。如需更多信息，请参阅 创建网络附加定义。

要将额外网络接口附加到 pod，您必须创建配置来定义接口的附加方式。您可以使用 NetworkAttachmentDefinition 自定义资源(CR)来指定每个接口。每个 CR 中的 Container Network Interface (CNI)配置定义如何创建该接口。

OpenShift Data Foundation 支持 macvlan 驱动程序，其中包括以下功能：

OpenShift Data Foundation 支持以下两种类型的 IP 地址管理：

如需了解配置基于裸机的 Multus 配置所需的步骤，请参阅创建 Multus 网络。