第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 ボンディングは、eno0eno1 などの物理インターフェイスリンクを介して、異なる仮想マシンポートからのトラフィックを分散します。さらに、どちらの物理インターフェイスからの Ingress トラフィックも、OVS ブリッジのセットを通過して仮想マシンに到達できます。

図3.1 2 つの NAD を持つローカルネット上で動作する OVS balance-slb モード

2 つの NAD を持つローカルネット上で動作する OVS `balance-slb` モード

OVS ボンディングを使用して、balance-slb モードインターフェイスをプライマリーまたはセカンダリーネットワークタイプに統合できます。OVS ボンディングでは、次の点に注意してください。

  • OVN-Kubernetes CNI プラグインをサポートし、プラグインと簡単に統合できます。
  • ネイティブで balance-slb モードをサポートします。

前提条件

  • プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを MachineConfig ファイルで定義した。
  • マニフェストオブジェクトを作成し、カスタマイズした br-ex ブリッジをオブジェクト設定ファイルで定義した。
  • プライマリーネットワークに複数の物理インターフェイスが接続されており、それらのインターフェイスを NAD CRD ファイルで定義した。

手順

  1. クラスター内に存在するベアメタルホストごとに、クラスターの 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 を実行する最小設定の一部です。
  2. 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-ex MTU を手動で設定します。
  3. base64 コマンドを使用して、NMState 設定ファイルのインターフェイスコンテンツをエンコードします。

    $ base64 -w0  <nmstate_configuration>.yml

    <nmstate_configuration>: -w0 オプションは、base64 エンコード操作中の行折り返しを防止します。

  4. 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 など、ノードへの短いホスト名パスを指定できます。
  5. MachineConfig マニフェストファイルを ./<installation_directory>/manifests ディレクトリーに保存します。<installation_directory> は、インストールプログラムがファイルを作成するディレクトリーです。

    Machine Config Operator (MCO) が各マニフェストファイルからコンテンツを取得し、ローリング更新中に選択されたすべてのノードにそのコンテンツを一貫して適用します。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る