Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

8.2. マルチネットワークプラグイン (Multus) のサポート

OpenShift Data Foundation は、ベアメタルインフラストラクチャー上でマルチネットワークプラグイン Multus を使用する機能をサポートし、さまざまなタイプのネットワークトラフィックを分離することでセキュリティーとパフォーマンスを向上させます。Multus を使用すると、OpenShift Data Foundation 専用に、ホスト上の 1 つ以上のネットワークインターフェイスを予約できます。

Multus を使用するには、まず Multus 前提条件検証ツールを実行します。ツールの使用方法は、OpenShift Data Foundation - Multus 前提条件検証ツール を参照してください。Multus ネットワークの詳細は、複数ネットワーク を参照してください。

IPv4 を使用するように Multus ネットワークを設定できます。また、IPv6 を使用するようにネットワークを設定することもできます (これはテクノロジープレビューです)。Multus ネットワークでは、IPv4 または IPv6 の一方のみを使用するように設定できます。混合モードはサポートされていません。

重要

テクノロジープレビュー機能は、今後の製品イノベーションへの早期アクセスを提供するもので、開発プロセス中に機能をテストし、フィードバックを提供できるようにします。ただし、この機能は Red Hat のサービスレベルアグリーメントで完全にサポートされていないため、機能的に完全でない可能性があり、実稼働環境での使用を目的としていません。Red Hat ではテクノロジープレビュー機能を今後も繰り返し使用することで一般提供に移行できると考えていることから、お客様がこの機能を使用する際に発生する問題の解決に取り組みます。

詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

8.2.1. Multus の前提条件
リンクのコピー

Ceph-CSI が Multus 対応の CephCluster と通信するには、Kubernetes ホストに設定が必要です。

以下の前提条件を満たすには、Multus ネットワークの設定方法と Rook による使用方法の理解が必要です。このセクションは、発生する可能性のある疑問を明確にするのに役立ちます。

次の 2 つの基本要件を満たす必要があります。

  • OpenShift ホストが、Multus パブリックネットワークに正常にルーティングできる必要があります。
  • Multus パブリックネットワーク上の Pod が、OpenShift ホストに正常にルーティングできる必要があります。

これら 2 つの要件は、さらに次のように細分化できます。

  • Kubernetes ホストを Multus パブリックネットワークにルーティングするには、各ホストで次の点を確認する必要があります。

    • ホストに、Multus パブリックネットワークに接続されたインターフェイス ("public-network-interface") が必要です。
    • "public-network-interface" には IP アドレスが必要です。
    • Multus パブリックネットワーク上の Pod 宛てのトラフィックを "public-network-interface" 経由で送信するためのルートが存在する必要があります。

  • Multus パブリックネットワーク上の Pod を Kubernetes ホストにルーティングするには、パブリック NetworkAttachmentDefinition を設定して、次の点を確認する必要があります。

    • 定義に、ネットワークを介してノード宛てのトラフィックをルーティングするように IP アドレス管理 (IPAM) が設定されている必要があります。
  • 2 つのネットワーク間のルーティングが適切に機能するように、ノードに割り当てられた IP アドレスが、Multus パブリックネットワーク上の Pod に割り当てられた IP アドレスと重複していない必要があります。
  • 通常、NetworkAttachmentDefinition とノード設定の両方で、Multus パブリックネットワークに接続するために同じネットワークテクノロジー (Macvlan) を使用する必要があります。

ノード設定と Pod 設定は相互に関連しており、密接に結び付いています。両方を同時に計画する必要があります。どちらも OpenShift Data Foundation で Multus パブリックネットワークをサポートするのに不可欠です。

“パブリックネットワークインターフェイス” は両方で同じである必要があります。一般的に、接続テクノロジー (Macvlan) も両方で同じである必要があります。NetworkAttachmentDefinition 内の IP 範囲は、ノード上のルートとしてエンコードする必要があります。ミラーでは、ノードの IP 範囲は NetworkAttachmentDefinition 内のルートとしてエンコードする必要があります。

一部のインストールでは、Pod とノードの両方に同じパブリックネットワーク IP アドレス範囲を使用しない場合があります。Pod とノードに異なる範囲がある場合は、各範囲が他の範囲にルーティングされ、単一の連続したネットワークとして機能するように、追加の手順を実行する必要があります。これらの要件には慎重な計画が必要です。これらの要件を理解して実装するには、Multus の例 を参照してください。

ヒント

多くの場合は、ストレージノードごとに 10 個以上の OpenShift Data Foundation Pod が存在します。通常、Pod のアドレス空間は、ホストのアドレス空間よりも数倍 (またはそれ以上) 大きくする必要があります。

OpenShift Container Platform では、ホストの要件を満たすようにホストを設定する適切な方法として、NMState Operator の NodeNetworkConfigurationPolicies を使用することを推奨しています。必要に応じて他の方法も使用できます。

8.2.1.1. Multus ネットワークのアドレス空間サイズの設定
リンクのコピー

ネットワークには、ネットワークにアタッチされるストレージ Pod の数に対応できる十分な数のアドレスと、フェイルオーバーイベントに対応できる追加のスペースが必要です。

将来のストレージクラスターの拡張も事前に計画し、OpenShift Container Platform および OpenShift Data Foundation クラスターが将来どの程度大きくなる可能性があるかを予測することを強く推奨します。将来の拡張を見越してアドレスを予約しておくと、拡張時に IP アドレスプールが予期せず枯渇するリスクが低くなります。

最も安全なのは、ストレージクラスターの稼働期間中に同時に必要になると予想されるアドレスの最大合計数よりも 25% (またはそれ以上) 多くのアドレスを割り当てることです。これにより、フェイルオーバーやメンテナンス中に IP アドレスプールが枯渇するリスクが軽減されます。

対応するネットワーク CIDR 設定を簡単に記述できるように、合計を最も近い 2 の累乗に切り上げることも推奨されます。

次の 3 つの範囲を計画する必要があります。

  • パブリック Network Attachment Definition のアドレス空間を使用する場合、openshift-storage namespace で実行されている ODF Pod の合計数に応じた十分な IP がアドレス空間に含まれている必要があります。
  • クラスター Network Attachment Definition のアドレス空間を使用する場合、openshift-storage namespace で実行されている OSD Pod の合計数に応じた十分な IP がアドレス空間に含まれている必要があります。
  • Multus パブリックネットワークを使用する場合、ノードパブリックネットワークのアドレス空間に、Multus パブリックネットワークに接続されている OpenShift ノードの合計数に応じた十分な IP が含まれている必要があります。
注記

クラスターで、パブリック Network Attachment Definition とノードパブリックネットワークアタッチメントに 1 つのアドレス空間を使用する場合は、上記の 2 つの要件を加算してください。これは、DHCP を使用してパブリックネットワークの IP を管理する場合などに関係します。

8.2.1.1.1. 推奨設定
リンクのコピー

ほとんどの組織では、次の推奨設定で十分です。この推奨設定では、範囲の先頭が使用中であると想定して、または望ましいと想定して、予約済みプライベートアドレス空間 (192.168.0.0/16) の最後の 6.25% (1/16) を使用します。おおよその最大値 (25% のオーバーヘッドを考慮) を示します。

Expand
表8.1 Multus の推奨設定
ネットワークネットワーク範囲 CIDRおおよその最大値

パブリック Network Attachment Definition

192.168.240.0/21

合計 1,600 個の ODF Pod

クラスター Network Attachment Definition

192.168.248.0/22

800 個の OSD

ノードパブリックネットワークアタッチメント

192.168.252.0/23

合計 400 ノード

8.2.1.1.2. 計算
リンクのコピー

より詳細なアドレス空間のサイズは次のように決定できます。

  1. 将来必要になる可能性のある OSD の最大数を決定します。25% を足してから 5 を足します。結果を最も近い 2 の累乗に切り上げます。これがクラスターのアドレス空間のサイズです。
  2. ステップ 1 で計算した四捨五入されていない数値から始めます。64 を足してから 25% を足します。結果を最も近い 2 の累乗に切り上げます。これが Pod のパブリックアドレス空間のサイズです。
  3. 将来必要になる可能性のある OpenShift ノード (ストレージノードを含む) の合計最大数を決定します。25% を足します。結果を最も近い 2 の累乗に切り上げます。これがノードのパブリックアドレス空間のサイズです。

8.2.1.2. 要件が満たされていることを確認する
リンクのコピー

ノードを設定し、Multus のパブリック NetworkAttachmentDefinition を作成した後 (ネットワークアタッチメント定義の作成 を参照)、ノード設定と NetworkAttachmentDefinition 設定に互換性があることを確認します。これを行うには、各ノードがパブリックネットワーク経由で Pod に ping できることを検証します。

次の例のような daemonset を起動します。 

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: {}
Copy to Clipboard Toggle word wrap

次の例のようなコマンドを使用して、テスト Pod に割り当てられた Multus パブリックネットワーク IP をリスト表示します。この例のコマンドは、すべてのテスト Pod に割り当てられたすべての IP をリスト表示します (各 Pod には 2 つの IP があります)。出力から、Multus パブリックネットワークに関連付けられた IP を手動で簡単に抽出できます。 

$ 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
Copy to Clipboard Toggle word wrap

前の例では、Multus パブリックネットワーク上のテスト Pod IP は次のとおりです。

  • 192.168.20.22
  • 192.168.20.29
  • 192.168.20.23

各ノード (NODE) がパブリックネットワーク経由ですべてのテスト Pod IP にアクセスできることを確認します。 

$ 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
Copy to Clipboard Toggle word wrap

いずれかのノードが実行中の Pod への ping に成功しない場合、次に進むのは安全ではありません。問題を診断して修正し、このテストを繰り返してください。問題が発生する原因としては次のようなものが考えられます。

  • ホストが Multus パブリックネットワークに (Macvlan 経由で) 正しくアタッチされていない可能性がある
  • ホストが Pod の IP 範囲にルーティングするように適切に設定されていない可能性がある
  • パブリック NetworkAttachmentDefinition がホストの IP 範囲にルーティングして戻すように適切に設定されていない可能性がある
  • ホストのファイアウォールルールが、どちらかの方向の接続をブロックしている可能性がある
  • ネットワークスイッチのファイアウォールまたはセキュリティールールが、接続をブロックしている可能性がある

推奨されるデバッグ手順:

  • パブリックネットワークの “shim” IP を使用してノードが相互に ping を実行できることを確認する
  • ip address の出力を確認する

8.2.2. Multus の例
リンクのコピー

このクラスターに関連するネットワークプランは次のとおりです。

  • 専用の NIC が Multus パブリックネットワークに eth0 を提供します。
  • Macvlan を使用して OpenShift Pod を eth0 にアタッチします。
  • この例のクラスターでは、IP 範囲 192.168.0.0/16 が空いています。この IP 範囲を、Pod とノードが Multus パブリックネットワーク上で共有します。
  • ノードは IP 範囲 192.168.252.0/22 を取得します (これにより、この例の組織が必要とする数よりも多い、最大 1024 個の Kubernetes ホストを使用できます)。
  • Pod は残りの範囲 (192.168.0.1 から 192.168.251.255) を取得します。
  • この例の組織では、必要がない限り DHCP を使用しません。そのため、ノードには、NMState Operator の NodeNetworkConfigurationPolicy リソースを使用して静的に割り当てられる Multus ネットワーク上の IP (eth0 経由) が与えられます。
  • DHCP を使用できないため、すぐに使用できる Whereabouts を使用して、Multus パブリックネットワークに IP を割り当てます。
  • OpenShift クラスターには、3 つのコンピュートノード (compute-0、compute-1、compute-2) があります。このクラスター上で OpenShift Data Foundation も実行されます。

ノードのネットワークポリシーは、Multus パブリックネットワーク上の Pod にルーティングするように設定する必要があります。

Pod は Macvlan 経由で接続され、Macvlan ではホストと Pod が相互にルーティングできないため、ホストも Macvlan 経由で接続する必要があります。一般的に、ホストは Pod と同じテクノロジーを使用して Multus パブリックネットワークに接続する必要があります。Pod 接続は、ネットワークアタッチメント定義で設定されます。

ホストの IP 範囲は、範囲全体のサブセットであるため、ホストは IP 割り当てだけでは Pod にルーティングできません。ホストが 192.168.0.0/16 の範囲全体にルーティングできるようにするには、ホストにルートを追加する必要があります。

NodeNetworkConfigurationPolicy の desiredState 仕様は次のようになります。 

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
Copy to Clipboard Toggle word wrap
  1. 静的 IP 管理の場合、各ノードに異なる NodeNetworkConfigurationPolicy が必要です。
  2. 静的ネットワークを設定するには、ポリシーごとに個別のノードを選択します。
  3. “shim” インターフェイスは、Network Attachment Definition が使用するのと同じテクノロジーを使用して、ホストを Multus パブリックネットワークに接続するために使用されます。
  4. ホストの “shim” は、Pod 用に計画したものと同じタイプ (この例では macvlan) である必要があります。
  5. インターフェイスは、計画時に選択した Multus パブリックネットワークインターフェイス (この例では eth0) と同じである必要があります。
  6. ipv4 (または ipv6) セクションでは、Multus パブリックネットワーク上のノード IP アドレスを設定します。
  7. このノードの shim に割り当てられる IP が、計画と同じである必要があります。この例では、Multus パブリックネットワーク上のノード IP として 192.168.252.0/22 を使用します。
  8. 静的 IP 管理の場合は、必ず各ノードの IP を変更してください。
  9. routes セクションでは、Multus パブリックネットワーク上の Pod に到達する方法をノードに指示します。
  10. ルートの宛先は、Pod 用に計画した CIDR 範囲と同じである必要があります。この場合、192.168.0.0/16 の範囲全体を使用しても、ノードが “shim” インターフェイスを介して他のノードに到達する能力に影響しないため、安全です。通常、これは Multus パブリック NetworkAttachmentDefinition で使用される CIDR と一致する必要があります。

パブリックネットワークの NetworkAttachmentDefinition は、次のようになります。ここでは、range 要求を簡素化するために、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]
       ]
     }
   }'
Copy to Clipboard Toggle word wrap
  1. これは、Pod を Multus パブリックネットワークにアタッチする方法の計画と同じである必要があります。ノードは同じテクノロジー (Macvlan) を使用してアタッチする必要があります。
  2. インターフェイスは、計画時に選択した Multus パブリックネットワークインターフェイス (この例では eth0) と同じである必要があります。
  3. この例の計画では、Pod に IP を割り当てるために、DHCP ではなく Whereabouts を使用します。
  4. この例では、ノードに割り当てられる一部の範囲を除いて (5 を参照)、192.168.0.0/16 の範囲内の任意の IP を Pod に割り当てることができると決定しました。
  5. whereabouts は、ノードに割り当てられる範囲をプールから簡単に除外できる exclude ディレクティブを提供します。これにより、range ディレクティブ (4 を参照) を簡素化できます。
  6. routes セクションでは、Multus パブリックネットワーク上のノードに到達する方法を Pod に指示します。
  7. ルートの宛先 (dst) は、ノード用に計画した CIDR 範囲と同じである必要があります。

8.2.3. ホルダー Pod の非推奨化
リンクのコピー

アップグレード時にホルダー Pod のメンテナンスの影響が繰り返し発生するため (ホルダー Pod は Multus が有効な場合に存在します)、ホルダー Pod は ODF v4.16 リリースで非推奨となり、ODF v4.17 リリースで削除される予定です。この非推奨化に伴い、ホルダー Pod を削除する前に、追加のネットワーク設定アクションを完了する必要があります。ODF v4.15 の Multus が有効になっているクラスターを、標準のアップグレード手順に従って v4.16 にアップグレードします。ODF クラスター (Multus が有効) を v4.16 に正常にアップグレードした後、管理者は記事 Disabling Multus holder pods に記載されている手順を完了して、ホルダー Pod を無効化および削除する必要があります。この無効化手順は時間がかかることに注意してください。ただし、v4.16 にアップグレードした直後にすべての手順を完了する必要はありません。ODF を v4.17 にアップグレードする前に、このプロセスを完了することが重要です。

8.2.4. Multus を使用したストレージトラフィックの分離
リンクのコピー

デフォルトで、Red Hat OpenShift Data Foundation は Red Hat OpenShift Software Defined Network (SDN) を使用するように設定されています。デフォルトの SDN には、以下のトラフィックタイプがあります。

  • Pod 間のトラフィック
  • Pod からストレージへのトラフィック (ストレージが OpenShift Data Foundation の場合はパブリックネットワークトラフィックと呼ばれます)
  • OpenShift Data Foundation の内部レプリケーションおよびリバランストラフィック (クラスターネットワークトラフィックと呼ばれます)

OpenShift Data Foundation を OpenShift のデフォルトネットワークから分離する方法は 3 つあります。

  1. OpenShift Data Foundation のパブリックネットワーク用にホスト上でネットワークインターフェイスを予約する

    • Pod からストレージへのトラフィックと内部ストレージのレプリケーショントラフィックは、Pod 間のネットワークトラフィックから分離されたネットワーク上に共存します。
    • OpenShift Data Foundation クラスターが正常な場合、アプリケーション Pod は最大のパブリックネットワークストレージ帯域幅にアクセスできます。
    • ただし、OpenShift Data Foundation クラスターが障害から回復している場合、進行中のレプリケーションとトラフィックの再バランスにより、アプリケーション Pod の帯域幅が減少します。

  2. OpenShift Data Foundation のクラスターネットワーク用にホスト上のネットワークインターフェイスを予約します。

    • Pod 間のトラフィックと Pod からストレージへのトラフィックはどちらも OpenShift のデフォルトネットワークを使用し続けます。
    • Pod からストレージまでの帯域幅は、OpenShift Data Foundation クラスターの正常性の影響をあまり受けません。
    • Pod 間および Pod からストレージへの OpenShift Data Foundation トラフィックは、OpenShift クラスターがビジーな場合に、ネットワーク帯域幅をめぐって競合する可能性があります。
    • ストレージの内部ネットワークには、障害時の使用のために予約された、未使用の帯域幅が過剰に存在することがよくあります。

  3. OpenShift Data Foundation 用にホスト上で 2 つのネットワークインターフェイス (1 つはパブリックネットワーク用で、もう 1 つはクラスターネットワーク用) を予約します。

    • Pod から Pod、Pod からストレージ、ストレージの内部トラフィックはすべて分離されており、どのトラフィックタイプもリソースをめぐって競合することはありません。
    • すべてのトラフィックタイプのサービスレベルアグリーメントを確保できます。
    • 正常な実行時には、より多くのネットワーク帯域幅が予約されますが、3 つのネットワークすべてで使用されません。

デュアルネットワークインターフェイスの分離設定の概略例:

Dual network interface segregated configuration schematic

トリプルネットワークインターフェイスの完全分離設定の概略例:

Triple network interface full segregated configuration schematic

8.2.5. Multus を使用する場合
リンクのコピー

以下が必要な場合は、OpenShift Data Foundation に Multus を使用します。

遅延の改善 - ODF を使用した Multus は常に遅延を改善します。ホストインターフェイスをホストネットワークに近い速度で使用し、OpenShift のソフトウェア定義の Pod ネットワークをバイパスします。各インターフェイスのインターフェイスレベルごとの Linux チューニングを実行することもできます。

帯域幅の向上 - OpenShift Data Foundation クライアントデータトラフィックと内部データトラフィックの専用インターフェイス。これらの専用インターフェイスは、完全な帯域幅を予約します。

セキュリティーの向上 - Multus は、ストレージネットワークトラフィックをアプリケーションネットワークトラフィックから分離して、セキュリティーを強化します。ネットワークがインターフェイスを共有している場合、帯域幅またはパフォーマンスが分離されない場合がありますが、QoS またはトラフィックシェーピングを使用して、共有インターフェイス上の帯域幅に優先順位を付けることができます。

8.2.6. Multus 設定
リンクのコピー

Multus を使用するには、OpenShift Data Foundation クラスターをデプロイする前にネットワーク接続定義 (NAD) を作成する必要があります。これは後でクラスターに接続されます。詳細は、ネットワークアタッチメント定義の作成 を参照してください。

追加のネットワークを Pod に割り当てるには、インターフェイスの割り当て方法を定義する設定を作成する必要があります。それぞれのインターフェイスは、NetworkAttachmentDefinition カスタムリソース (CR) を使用して指定します。これらの各 CR 内のコンテナーネットワークインターフェイス (CNI) 設定は、対象のインターフェイスの作成方法を定義します。

OpenShift Data Foundation は、次の機能を含む macvlan ドライバーをサポートしています。

  • 各接続は、独自の MAC アドレスを持つ親インターフェイスのサブインターフェイスを取得し、ホストネットワークから分離されます。
  • Linux ブリッジや ipvlan よりも CPU の使用量が少なく、スループットが向上します。
  • ほとんどの場合、ブリッジモードが最適な選択肢です。
  • ネットワークインターフェイスカード (NIC) がハードウェアで仮想ポート/仮想ローカルエリアネットワーク (VLAN) をサポートする場合の、ホストに近いパフォーマンス。

OpenShift Data Foundation は、次の 2 つのタイプの IP アドレス管理をサポートします。

Expand

whereabouts

DHCP

OpenShift/Kubernetes の leases を使用して、Pod ごとに一意の IP アドレスを選択します。

range フィールドは必要ありません。

Pod に IP を提供するために DHCP サーバーを必要としません。

ネットワーク DHCP サーバーは、Multus Pod および同じネットワーク上の他のホストに同じ範囲を割り当てることができます。

Important

DHCP サーバーがある場合は、ネットワーク上の複数の MAC アドレスに同じ IP が割り当てられないように、Multus で設定された IPAM により、同じ範囲が設定されないようにします。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る