AHV環境でアップリンクNICにLACPを利用したチーミングを行うケースがあります。
AHVは、もちろんLACPに対応しています。今回は、以前にも紹介しましたが改めてLACPを含めアップリンクのチーミング方法とLACPの設定方法についてお伝えします。
AHVのチーミング方法
AHVは、3つのアップリンクにおけるチーミング方法をサポートしています。
AHVのデフォルトは、「active-backup」構成であり、こちらがメーカー推奨の構成となります。複数NICでアップリンクを構成した場合、アクティブとして利用するNICがⅠ本になるため、4本アップリンク構成などの場合はNICが無駄になってしまいますので、Nutanixの構成の推奨としては、2本のNICでチーミング構成を作成し、「active-backup」構成を利用することです。こちらの構成が推奨な理由は、Nutanixは、10Gのネットワーク帯域をフルで利用しない仕組みであることと、LAGにおけるスイッチとの相性およびスイッチの設定ミスによる通信不能状態を引き起こすことをなくすというメリットがあるためです。
当然ながらActive-Backup構成であれば、接続するスイッチ側は、LAGなど設定の必要なく、通常のAccessもしくはTrunkポートで設定すればOKです。
▼Acrive-Backupのアップリンク利用イメージ
balance-slbは、複数のアップリンクNICに対して、仮想マシン毎に特定の物理NICを利用するという構成です。こちらもスイッチ側には、LAGなどのポートを束ねる設定は必要ありません。仮想マシンに搭載された仮想NIC毎に利用する物理NICが割り当てられるため、仮想マシントラフィックによっては、物理NICのトラフィック量が不均等になる可能性はあります。
▼balance-slbのアップリンク利用イメージ
物理NICが分散されて利用するため、負荷分散ができかつチーミングされた物理NICの性能を最大限利用することができます。
▼LACPを利用した場合のアップリンク利用イメージ
ここまで、アップリンクモードについて確認してみました。
重要なことは、LAG構成は、LACPのみサポートされており、静的LAGは非サポートであることに注意してください。
＜LACPの設定方法＞
では、LACPを利用する場合について考えてみましょう。
現在、Nutanixでは、Prism上でアップリンクNICのチーミングモードを変更することができ、Prismでのオペレーションが強く推奨されています。GUIで簡単に変更できることは大変便利です。しかし、Prismを利用して設定を変更するということは、Nutanixクラスターサービスが起動していることが前提です。
ノード追加を行う場合も、追加ノードのチーミングモードを設定できる項目がExpand Clusterの画面に追加されています。
▼Expand Cluster時に拡張ノードに対してチーミングの個別設定が可能
Nutanixの初期設定は、Active-Backupですのでこの状態でクラスターを起動させるために、Nutanixに接続される物理スイッチは、LACPモードではなく、通常のポートで設定する必要があります。一方、Prismからチーミングモードを変更すると1ノードずつチーミングモードがLACPに変更されます。（従来はここでノードの再起動が発生していましたが、AOS6.7においては、再起動は、発生しなくなっています）
しかし、1ノードのチーミングモードがLACPに変わると物理スイッチ側は、まだ通常のポートモードであることから、チーミングモードが変更されたノードは、疎通ができなくなってしまいます。
これを防ぐために、スイッチ側は、LACPの設定を行いつつもfallbackモードを有効化しておくことが必要となります。このfallbackモードは、物理スイッチでLACPを設定されたポートで、LACPのネゴシエーションができなかった場合、標準ポートとしてネゴシエーションするという機能です。この機能を利用することで、予め物理スイッチはLACPに設定しつつも、Nutanix側は、Active-Backupで起動時は、fallback機能が働き、通常ポートとして稼動し、PrismからLACPモードに変更すると、Nutanix側でLACPが有効化されるため、物理スイッチもLACPモードが有効化されるため、疎通が出来なくなるという事故をなくすことができます。
しかし、物理スイッチのメーカーにおいては、fallbackモードが実装されていない場合があります。この場合は、予めNutanixクラスターにLACPモードを有効化した上で、物理スイッチもLACPモードにしておけば、問題なくネゴシエーションができるかと思います。では、NutanixのノードをクラスタースタートせずにLACPモードにする方法としては、CVMから以下のコマンドを入力することでチーミングモードを変更します。
この手順は、クラスターメンバーに入る前のノードでもサ行が可能です。既にクラスターメンバーには行っているノードにおいて設定変更する場合は、クラスターサービスを「cluster stop」コマンドをCVMで実行し、予めクラスターサービスを停止しておきます。
まず、ノードの物理NICを確認します。
nutanix@NTNX-23SM6C-CVM:10.38.51.173:~$ manage_ovs show_uplinks
Bridge: br0
Bond: br0-up
bond_mode: active-backup
interfaces: eth5 eth4 eth3 eth2 eth1 eth0
lacp: off
lacp-fallback: false
lacp_speed: slow
lacp_status: off
ここでは、eth0からeth5全てが1つの仮想スイッチのアップリンクNICとして構成されており、現行はLACPモードではないことがわかります。
では、LACPモードを有効化します。
nutanix@NTNX-23SM6C-CVM:10.38.51.173:~$ manage_ovs --bridge_name br0 --interfaces eth0,eth1,eth2,eth3,eth4,eth5 --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true update_uplinks
2023-12-16 05:09:49,505Z WARNING manage_ovs:1361 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPool(host='127.0.0.1', port=2030): Max retries exceeded with url: /h/gflags?show=hypervisor_username (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f5e411bc350>: Failed to establish a new connection: [Errno 111] Connection refused',)).
2023-12-16 05:10:02,734Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:02,856Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,265Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,267Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,280Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,661Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:13,008Z INFO manage_ovs:700 Node: 10.38.51.173 failed to connect to IDF while validating virtual switch configuration. Continuing further may result in inconsistency with the existing virtual switch configuration and require manual remediation once IDF is available.
Do you want to proceed? (Y/[N]):
クラスターサービスが上がっていないので色々コンソールに出力されますが、気にせず、Y/Nの質問が来るまで待った上で、Yを入力設定を完了します。
設定が完了したら、再度アップリンクのステータスを確認します。
nutanix@NTNX-17SM6C100126-C-CVM:10.38.51.173:~$ manage_ovs show_uplinks
2023-12-16 05:19:26,915Z WARNING manage_ovs:1361 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPool(host='127.0.0.1', port=2030): Max retries exceeded with url: /h/gflags?show=hypervisor_username (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f687cc8b350>: Failed to establish a new connection: [Errno 111] Connection refused',)).
Bridge: br0
Bond: br0-up
bond_mode: balance-tcp
interfaces: eth5 eth4 eth3 eth2 eth1 eth0
lacp: active
lacp-fallback: true
lacp_speed: fast
lacp_status: configured ★
ここで確認すべき情報は、「lacp_status」です。
こちらの例では、LACP設定は完了していますが、スイッチとLACPでネゴシエーションで来てない状態になります。この項目が「negotiated」であれば、スイッチとのLACPネゴシエーションが確立されています。
なお、AOS6.7「el8.nutanix.20230302.207」のAHVバージョンにおいては、従来AHVがら設定をしていた「ovs-vsctl」や「ovs-appctl」コマンドが利用できなくなっているようです。
AHV上で、ovsコマンドの一覧を確認した際の結果
[nutanix@NX-AHV3 bin]$ ls -alg | grep ovs
-?????????? ? ? ? ? ovs-appctl
-rwxr-xr-x. 1 root 234440 May 1 2023 ovsdb-client
-rwxr-xr-x. 1 root 185560 May 1 2023 ovsdb-tool
-rwxr-xr-x. 1 root 8064 Feb 24 2023 ovs-docker
-rwxr-xr-x. 1 root 47168 May 1 2023 ovs-dpctl
-rwxr-xr-x. 1 root 61740 May 1 2023 ovs-dpctl-top
-rwxr-xr-x. 1 root 453544 May 1 2023 ovs-ofctl
-rwxr-xr-x. 1 root 2862 May 1 2023 ovs-parse-backtrace
-rwxr-xr-x. 1 root 3418 May 1 2023 ovs-pcap
-rwxr-xr-x. 1 root 15121 May 1 2023 ovs-pki
-rwxr-xr-x. 1 root 17347 May 1 2023 ovs-tcpdump
-rwxr-xr-x. 1 root 2195 May 1 2023 ovs-tcpundump
-rwxr-xr-x. 1 root 12104 May 1 2023 ovs-vlan-test
-?????????? ? ? ? ? ovs-vsctl
今後は、CVMから「manage_ovs」を利用することが前提となっている流れでは無いかと思います。
0 件のコメント:
コメントを投稿