第3章 ネットワーク結合に関する考慮事項
ネットワークボンディング (リンクアグリゲーション とも呼ばれる) を使用すると、複数のネットワークインターフェイスを単一の論理インターフェイスに統合できます。これは、ボンディングされたインターフェイス間でネットワークトラフィックをどのように分散させるかを処理するために、異なるモードを使用できることを意味します。各モードは耐障害性を提供し、一部のモードではネットワークの負荷分散機能も提供します。Red Hat は、Open vSwitch (OVS) ボンディングとカーネルボンディングをサポートしています。
3.1. Open vSwitch (OVS) ボンディング リンクのコピーリンクがクリップボードにコピーされました!
OVS ボンディング設定では、各物理ネットワークインターフェイスコントローラー (NIC) を特定のボンディングのポートとして接続することにより、単一の論理インターフェイスを作成します。この単一のボンディングがすべてのネットワークトラフィックを処理し、個々のインターフェイスの機能を効果的に代替します。
OVS インターフェイスと連携する OVS ブリッジのアーキテクチャー設定として、以下の例を検討してください。
- ネットワークインターフェイスは、プロトコルレベルのトラフィックや IP アドレスの割り当てなどのその他の管理タスクを管理するために、ブリッジ Media Access Control (MAC) アドレスを使用します。
- 物理インターフェイスの物理 MAC アドレスは、トラフィックを処理しません。
- OVS は、OVS ブリッジレベルで全ての MAC アドレス管理を処理します。
このレイアウトでは、ボンディングがデータパスとして機能し、MAC アドレスの一元管理が OVS ブリッジレベルで行われるため、ボンディングインターフェイスの管理が簡素化されます。
OVS ボンディングでは、アクティブ/バックアップ モードまたは バランス/SLB モードのいずれかを選択できます。ボンディングモードは、ネットワーク伝送中にボンディングインターフェイスがどのように使用されるかに関するポリシーを指定します。
3.1.1. クラスターのアクティブ/バックアップモードを有効にしてください リンクのコピーリンクがクリップボードにコピーされました!
アクティブ/バックアップ モードは、プライマリーリンクに障害が発生した場合にバックアップリンクに切り替えることで、ネットワーク接続の耐障害性を提供します。
このモードでは、クラスター用に以下のポートを指定します。
- アクティブなポートとは、常に 1 つの物理インターフェイスがトラフィックの送受信を行うポートのことです。
- 他のすべてのポートがバックアップリンクとして機能し、リンクの状態を継続的に監視するスタンバイポート。
フェイルオーバー処理中に、アクティブポートまたはそのリンクに障害が発生した場合、ボンディングロジックによってすべてのネットワークトラフィックがスタンバイポートに切り替わります。このスタンバイポートが新しいアクティブポートになります。フェイルオーバーを機能させるには、ボンディングされたすべてのポートが同じ Media Access Control (MAC) アドレスを共有している必要があります。
3.1.2. クラスターで OVS balance-slb モードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
2 つ以上の物理インターフェイスがネットワークトラフィックを共有できるように、Open vSwitch (OVS) の balance-slb モードを有効にできます。balance-slb モードのインターフェイスは、ネットワークスイッチとのソースロードバランシングを必要とせずに、仮想化ワークロードを実行するクラスターにソース負荷分散 (SLB) 機能を提供できます。
現在、ソースロードバランシングはボンディングインターフェイスで実行されます。このインターフェイスは br-phy などの補助ブリッジに接続します。ソースロードバランシングは、Media Access Control (MAC) アドレスと仮想ローカルエリアネットワーク (VLAN) の組み合わせが複数存在する場合にのみ、負荷分散を行います。OVN-Kubernetes Pod のトラフィックはすべて同じ MAC アドレスと VLAN を使用するため、このトラフィックを多数の物理インターフェイス間で負荷分散することはできないことに注意してください。
次の図は、単純なクラスターインフラストラクチャーレイアウトでの balance-slb モードを示しています。仮想マシン (VM) は、特定の localnet NetworkAttachmentDefinition (NAD) カスタムリソース定義 (CRD)、NAD 0 または NAD 1 に接続します。各 NAD は、仮想マシンに基盤となる物理ネットワークへのアクセスを提供し、タグ付きまたはタグなしの VLAN トラフィックをサポートしています。br-ex OVS ブリッジは仮想マシンからのトラフィックを受信し、そのトラフィックを次の OVS ブリッジである br-phy に渡します。br-phy ブリッジは SLB ボンディングのコントローラーとして機能します。SLB ボンディングは、eno0 や eno1 などの物理インターフェイスリンクを介して、異なる仮想マシンポートからのトラフィックを分散します。さらに、どちらの物理インターフェイスからの Ingress トラフィックも、OVS ブリッジのセットを通過して仮想マシンに到達できます。
図3.1 2 つの NAD を持つローカルネット上で動作する OVS balance-slb モード
OVS ボンディングを使用して、balance-slb モードインターフェイスをプライマリーまたはセカンダリーネットワークタイプに統合できます。OVS ボンディングでは、次の点に注意してください。
- OVN-Kubernetes CNI プラグインをサポートし、プラグインと簡単に統合できます。
-
ネイティブで
balance-slbモードをサポートします。
前提条件
-
プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを
MachineConfigファイルで定義した。 -
マニフェストオブジェクトを作成し、カスタマイズした
br-exブリッジをオブジェクト設定ファイルで定義した。 - プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを NAD CRD ファイルで定義した。
手順
クラスター内に存在するベアメタルホストごとに、クラスターの
install-config.yamlファイルで、次の例のようにnetworkConfigセクションを定義します。# ... networkConfig: interfaces: - name: enp1s0 type: ethernet state: up ipv4: dhcp: true enabled: true ipv6: enabled: false - name: enp2s0 type: ethernet state: up mtu: 1500 ipv4: dhcp: true enabled: true ipv6: dhcp: true enabled: true - name: enp3s0 type: ethernet state: up mtu: 1500 ipv4: enabled: false ipv6: enabled: false # ...ここでは、以下のようになります。
enp1s0- プロビジョニングされるネットワークインターフェイスコントローラー (NIC) のインターフェイス。
enp2s0- ボンディングインターフェイス用の Ignition 設定ファイルを取り込む最初のボンディングされたインターフェイス。
mtu-
ボンディングポートの
br-ex最大伝送単位 (MTU) を手動で設定します。 enp3s0- 2 つ目のボンディングされたインターフェイスは、クラスターのインストール中に Ignition を実行する最小設定の一部です。
NMState 設定ファイルで各ネットワークインターフェイスを定義します。
多数のネットワークインターフェイスを定義する NMState 設定ファイルの例
ovn: bridge-mappings: - localnet: localnet-network bridge: br-ex state: present interfaces: - name: br-ex type: ovs-bridge state: up bridge: allow-extra-patch-ports: true port: - name: br-ex - name: patch-ex-to-phy ovs-db: external_ids: bridge-uplink: "patch-ex-to-phy" - name: br-ex type: ovs-interface state: up mtu: 1500 ipv4: enabled: true dhcp: true auto-route-metric: 48 ipv6: enabled: false dhcp: false auto-route-metric: 48 - name: br-phy type: ovs-bridge state: up bridge: allow-extra-patch-ports: true port: - name: patch-phy-to-ex - name: ovs-bond link-aggregation: mode: balance-slb port: - name: enp2s0 - name: enp3s0 - name: patch-ex-to-phy type: ovs-interface state: up patch: peer: patch-phy-to-ex - name: patch-phy-to-ex type: ovs-interface state: up patch: peer: patch-ex-to-phy - name: enp1s0 type: ethernet state: up ipv4: dhcp: true enabled: true ipv6: enabled: false - name: enp2s0 type: ethernet state: up mtu: 1500 ipv4: enabled: false ipv6: enabled: false - name: enp3s0 type: ethernet state: up mtu: 1500 ipv4: enabled: false ipv6: enabled: false # ...ここでは、以下のようになります。
mtu-
ボンディングポートの
br-exMTU を手動で設定します。
base64コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。$ base64 -w0 <nmstate_configuration>.yml<nmstate_configuration>:-w0オプションは、base64 エンコード操作中の行折り返しを防止します。masterロールとworkerロールのMachineConfigマニフェストファイルを作成します。前のコマンドからの base64 エンコード文字列を各MachineConfigマニフェストファイルに必ず埋め込んでください。次のマニフェストファイルの例では、クラスター内に存在するすべてのノードに対してmasterロールを設定します。ノード固有のmasterロールとworkerロールのマニフェストファイルを作成することもできます。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 10-br-ex-master spec: config: ignition: version: 3.2.0 storage: files: - contents: source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> mode: 0644 overwrite: true path: /etc/nmstate/openshift/cluster.ymlここでは、以下のようになります。
name- ポリシーの名前。
source- エンコードされた base64 情報を指定されたパスに書き込みます。
path-
cluster.ymlファイルへのパスを指定します。クラスター内の各ノードに対して、<node_short_hostname>.yml など、ノードへの短いホスト名パスを指定できます。
各
MachineConfigマニフェストファイルを./<installation_directory>/manifestsディレクトリーに保存します。<installation_directory>は、インストールプログラムがファイルを作成するディレクトリーです。Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。