このセクションでは、NSX Advanced Load Balancer Controller のインターフェイスとルート管理について説明します。
NSX Advanced Load Balancer Controller では、1 つのインターフェイスを、次のようなさまざまな制御プレーン関連タスクに使用できます。
オペレータによる CLI、ユーザー インターフェイス、API 経由での Controller へのアクセス。
Controller とサービス エンジンとの間の通信。
自動化や可観測性その他を目的とした Controller とサードパーティ エンティティとの間の通信。
Controller とサードパーティ製ハードウェア セキュリティ モジュール (HSM) との間の通信。
Controller の新しいインターフェイスでは、前述のエンティティの通信の一部を分離できるようになっています。
さらに、Controller のインターフェイスに追加されるスタティック ルートでは、/etc/network/interfaces サブシステムではなくクラスタ構成を活用しなければならなくなっています。この構成は、Controller の再起動やアップグレードの後も保持されます。
この機能がサポートされるのは、vCenter Server に展開されている Controller のみであり、その新しいインターフェイスを使用できるのは HSM のみです。
分類にラベルを使用する
分類には次のラベルが使用できます。
- MGMT:
-
ここで示されるのは、Controller アクセスと、Controller で通信を開始する際の管理通信全般(ログ作成、サードパーティ API 呼び出しなど)です。
- SE_SECURE_CHANNEL:
-
このラベルは、サービス エンジンと Controller との間のセキュア通信を分類するために使用されます。
- HSM:
-
これは、Controller と HSM デバイスとの間の通信を分類するために使用されます。
この分類が構成されていれば、トラフィックをデフォルトのメイン インターフェイスから新しいインターフェイスに移動できます。
MGMT と
SE_SECURE_CHANNEL
が実行できるのは、プライマリ (eth0) インターフェイスのみです。HSM は、新しいインターフェイスに移動できます。
運用モデル
Controller は元来、vCenter Server(のインストール時)に展開される際、1 つのインターフェイスでプロビジョニングされていました。
新しいインターフェイスを追加するには、次の手順を実行します。
Controller の仮想マシンをシャットダウンし、vCenter Server のユーザー インターフェイスからインターフェイスを追加します。
Controller の仮想マシンをパワーオンすると、NSX Advanced Load Balancer で新しいインターフェイスが認識されるので、新しい構成が NSX Advanced Load Balancer の CLI から実行できます。
インターフェイスのホットプラグ(仮想マシンをパワーオフせずに仮想マシンに追加すること)はサポートされていません。
インターフェイスが NSX Advanced Load Balancer Controller ソフトウェア内で認識され、ラベルによる分類がさらに実行されるようにするには、NSX Advanced Load Balancer の「クラスタ」構成モデルを使用しなければなりません。
単一ノードの Controller の構成
新しいインターフェイスを構成するには、次の手順を実行します。
Controller をシャットダウンし、vCenter Server から新しいインターフェイスを追加します。
Controller をパワーオンします。クラスタ構成では次のように、新しいインターフェイスは
eth1
と表示され、プライマリ インターフェイスは常にeth0
と表示されます。
[admin:controller]: > show cluster +-----------------+----------------------------------------------+ | Field | Value | +-----------------+----------------------------------------------+ | uuid | cluster-83e1ebf5-2c63-4690-9aaf-b66e7a7b5f08 | | name | cluster-0-1 | | nodes[1] | | | name | 10.102.64.201 | | ip | 10.102.64.201 | | vm_uuid | 00505681cb45 | | vm_mor | vm-16431 | | vm_hostname | node1.controller.local | | interfaces[1] | | | if_name | eth0 | | mac_address | 00:50:56:81:cb:45 | | mode | STATIC | | ip | 10.102.64.201/22 | | gateway | 10.102.67.254 | | labels[1] | MGMT | | labels[2] | SE_SECURE_CHANNEL | | labels[3] | HSM | | interfaces[2] | | | if_name | eth1 | | mac_address | 00:50:56:81:c0:89 | +-----------------+----------------------------------------------+
ここでは、eth1 が 2 つ目のインターフェイスとして検出されています。
新しいインターフェイスのモードと IP アドレスの詳細を次のように構成します。
[admin:controller]: > configure cluster [admin:controller]: cluster> nodes index 1 [admin:controller]: cluster:nodes> interfaces index 2 [admin:controller]: cluster:nodes:interfaces> mode static [admin:controller]: cluster:nodes:interfaces> ip 100.64.218.90/24 [admin:controller]: cluster:nodes:interfaces> labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> interfaces index 1 [admin:controller]: cluster:nodes:interfaces> no labels HSM [admin:controller]: cluster:nodes:interfaces> save
この CLI 構成では、
2 つ目のインターフェイス (index 2) に IP アドレスとラベルが追加されています。
プライマリ インターフェイス (index 1) からラベル HSM が削除されています。
追加のインターフェイスとルートでノードがすでに構成されていると、クラスタに追加されます。
単一ノード コントローラの新しいインターフェイスの構成を解除する
構成を元に戻してプライマリ インターフェイスが使用されるようにするには、次の手順を実行します。
2 つ目のインターフェイス (eth1) から構成(モード、IP、ラベル)を削除します。
プライマリ インターフェイス (eth0) にラベル HSM を追加します。
[admin:controller]: > configure cluster [admin:controller]: cluster> nodes index 1 [admin:controller]: cluster:nodes> interfaces index 2 [admin:controller]: cluster:nodes:interfaces> no mode [admin:controller]: cluster:nodes:interfaces> no ip [admin:controller]: cluster:nodes:interfaces> no labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> interfaces index 1 [admin:controller]: cluster:nodes:interfaces> labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> save [admin:controller]: cluster> save
スタティック ルートを構成する
スタティック ルートは、クラスタ構成で、プライマリとセカンダリに構成します。
/etc/network/interfaces
ファイルは編集しないでください。
すべての構成(IP アドレス、スタティック ルート)は、クラスタ構成によって、次に示すように行わなければなりません。
[admin:controller]: > configure cluster [admin:controller]: cluster> nodes index 1 [admin:controller]: cluster:nodes> static_routes New object being created [admin:controller]: cluster:nodes:static_routes> prefix 1.1.1.0/24 [admin:controller]: cluster:nodes:static_routes> next_hop 100.64.218.20 [admin:controller]: cluster:nodes:static_routes> route_id 1 [admin:controller]: cluster:nodes:static_routes> if_name eth1 [admin:controller]: cluster:nodes:static_routes> save [admin:controller]: cluster:nodes> save [admin:controller]: cluster> where Tenant: admin Cloud: Default-Cloud +--------------------+----------------------------------------------+ | Field | Value | +--------------------+----------------------------------------------+ | uuid | cluster-83e1ebf5-2c63-4690-9aaf-b66e7a7b5f08 | | name | cluster-0-1 | | nodes[1] | | | name | 10.102.64.201 | | ip | 10.102.64.201 | | vm_uuid | 00505681cb45 | | vm_mor | vm-16431 | | vm_hostname | node1.controller.local | | interfaces[1] | | | if_name | eth0 | | mac_address | 00:50:56:81:cb:45 | | mode | STATIC | | ip | 10.102.64.201/22 | | gateway | 10.102.67.254 | | labels[1] | MGMT | | labels[2] | SE_SECURE_CHANNEL | | interfaces[2] | | | if_name | eth1 | | mac_address | 00:50:56:81:c0:89 | | mode | STATIC | | ip | 100.64.218.90/24 | | labels[1] | HSM | | static_routes[1] | | | prefix | 1.1.1.0/24 | | next_hop | 100.64.218.20 | | if_name | eth1 | | route_id | 1 | +--------------------+----------------------------------------------+ [admin:controller]: cluster> save
3 ノード クラスタの構成
3 ノード クラスタの場合、次の手順が必要になります。
セカンダリ インターフェイスが検出されるよう、Controller ノードをクラスタの一部ではなくスタンドアローンにする必要があります。これは 1 回限りの操作であり、NSX Advanced Load Balancer で新しいインターフェイスを検出するためのものです。
セカンダリ インターフェイスが検出されると、クラスタを形成するのにリーダー ノードが使用できます。詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』のトピック「NSX Advanced Load Balancer Controller クラスタの展開」を参照してください。
クラスタが完全に形成されると、すべてのノードのセカンダリ インターフェイス構成が実行できます。
[admin:controller]: cluster> nodes index 1 [admin:controller]: cluster:nodes> interfaces index 2 [admin:controller]: cluster:nodes:interfaces> mode static [admin:controller]: cluster:nodes:interfaces> ip 100.64.218.90/24 [admin:controller]: cluster:nodes:interfaces> labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> interfaces index 1 [admin:controller]: cluster:nodes:interfaces> no labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> save [admin:controller]: cluster> nodes index 2 [admin:controller]: cluster:nodes> interfaces index 2 [admin:controller]: cluster:nodes:interfaces> mode static [admin:controller]: cluster:nodes:interfaces> ip 100.64.218.100/24 [admin:controller]: cluster:nodes:interfaces> labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> interfaces index 1 [admin:controller]: cluster:nodes:interfaces> no labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> save [admin:controller]: cluster> nodes index 3 [admin:controller]: cluster:nodes> interfaces index 2 [admin:controller]: cluster:nodes:interfaces> mode static [admin:controller]: cluster:nodes:interfaces> ip 100.64.218.110/24 [admin:controller]: cluster:nodes:interfaces> labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> interfaces index 1 admin:controller]: cluster:nodes:interfaces> no labels HSM [admin:controller]: cluster:nodes:interfaces> save [admin:controller]: cluster:nodes> save [admin:controller]: cluster> save
インターフェイスの検出を正常に実行するためにノードへログインする必要はありません。要件は、インターフェイスが仮想マシンで接続状態になっていることと、Controller がパワーオンされていることだけです。
クラスタの形成とセカンダリ インターフェイスの構成は、別個の手順で実行しなければなりません。
セカンダリ インターフェイスの IPv6 アドレスを構成する
NSX Advanced Load Balancer の IPv6 インターフェイスには、モード、IP、ゲートウェイの代わりに mode6、ip6、gateway6 を追加することができます。このインターフェイス構成では、22.1.3 のデュアル スタック モードをサポートしていません。したがって、インターフェイスは V4 IP か V6 IP のいずれかであり、両方というのはありません。
SE_SECURE_CHANNEL ラベルをセカンダリ インターフェイスに移動すると、サービス エンジンとの通信を有効化できます。このセカンダリ インターフェイスは、IPv4 か IPv6 のいずれかです。これで、ユーザーは管理とサービス エンジンとで通信のインターフェイスを別にすることができます。
SE_SECURE_CHANNEL ラベル付き IPv6 インターフェイスが IPv6 インターフェイスに適用されている構成のサンプルを次に示します。
+-----------------+----------------------------------------------+ | Field | Value | +-----------------+----------------------------------------------+ | uuid | cluster-f29ed7c8-0da5-4fb6-87f7-e792584643b3 | | name | cluster-0-1 | | nodes[1] | | | name | 100.65.9.203 | | ip | 100.65.9.203 | | vm_uuid | 000000675c79 | | vm_mor | vm-22988 | | vm_hostname | node1.controller.local | | interfaces[1] | | | if_name | eth0 | | mac_address | 00:00:00:67:5c:79 | | mode | STATIC | | ip | 100.65.9.203/20 | | gateway | 100.65.15.254 | | labels[1] | MGMT | | labels[2] | HSM | | interfaces[2] | | | if_name | eth1 | | mac_address | 00:00:00:1a:ab:e8 | | mode | STATIC | | ip | 100.65.14.66/20 | | interfaces[3] | | | if_name | eth2 | | mac_address | 00:00:00:3e:8b:ef | | labels[1] | SE_SECURE_CHANNEL | | mode6 | STATIC | | ip6 | 2402:740:0:40e::20:3/128 | +-----------------+----------------------------------------------+
Controller の IP アドレス変更に続いて構成を更新する
各 Controller ノードの管理 IP アドレスは、静的でなければなりません。これが適用されるのは、単一ノード展開と 3 ノード展開です。
クラスタ構成とランタイム構成には、クラスタの IP 情報が含まれています。リーダー ノードかフォロワー ノードの IP アドレスが(たとえば DHCP によって)変更された場合、ここで示すスクリプトを実行して IP 情報を更新することになります。クラスタ構成が更新されるまで、クラスタは正しく機能しません。
Controller ノードの IP アドレスが何らかの原因(DHCP など)で変更された場合、この後に示すスクリプトを使用してクラスタ構成を更新する必要があります。これは、単一ノード展開とクラスタ展開に適用されます。
Controller ノードの IP アドレスが変更された後にクラスタ構成を修復するには、change_ip.py
スクリプトを実行します。
そのスクリプトは、ディレクトリ /opt/avi/python/bin/cluster_mgr/change_ip.py にあります。
IP 変更スクリプトは、NSX Advanced Load Balancer クラスタ構成のみを変更します。コントローラ サービスが実行されているホストまたは仮想マシンの IP アドレスは変更されません。たとえば、VMware でホストする Controller の /etc/network/interfaces ファイルは更新しません。VMware の vApp プロパティの仮想マシンの IP アドレスは、変更しなければなりません。
ベアメタル構成でコントローラの IP アドレスを変更する場合は、特別な注意が必要です。
スクリプト オプション
スクリプトを実行する前に、新しい IP がすべてのノードで機能しており、ノード間でアクセス可能であることを確認します。1 つ以上の IP がアクセス不可能な場合、スクリプトではベストエフォートの更新を行いますが、接続が復旧したときにクラスタが再び同期される保証はありません。
スクリプトは、管理 IP アドレスが変更された Controller ノードでも、同じクラスタ内の別の Controller ノードでも実行できます。
スクリプトは、クラスタ内のノードの 1 つで実行する必要があります。このスクリプトをクラスタ内にないノードで実行すると、スクリプトは失敗します。
-i ipaddr
: スクリプトを実行するノードの新しい IP アドレスを指定します。
-o ipaddr
:クラスタにある別のノードの IP アドレスを指定します。
-m subnet-mask
:サブネットも変更された場合は、このオプションを使用して新しいサブネットを指定します。マスクは 255.255.255.0. という形式で指定します。
-g gateway-ipaddr
:デフォルトのゲートウェイも変更された場合は、このオプションを使用して新しいゲートウェイを指定します。
-m
および -g
オプションは、クラスタ内のすべての IP アドレスに適用されます。
単一ノード展開の IP 情報の更新
単一ノード展開の Controller の IP 情報を更新するには、次のようなコマンド文字列を使用します。
*change_ip.py -i **ipaddr*
このコマンドはノード 10.10.25.81 で実行されます。他のノードが指定されていないため、これは単一ノード クラスタ(この Controller のみ)と見なされます。
username@avi:~$ | change_ip.py -i 10.10.25.81
次の例では、ノードのデフォルト ゲートウェイも変更されています。
username@avi:~$ | change_ip.py -i 10.10.25.81 -g 10.10.10.1
Controller クラスタの IP 情報を更新する
change_ip.py
を実行する前に、すべての新しい IP が SSH ポート(通常の場合は 22、コンテナの場合は 5098)経由で相互にアクセスできるようにしておいてください。
クラスタの Controller の IP 情報を更新するには、次のようなコマンド文字列を使用します。
change_ip.py -i **ipaddr **-o ipaddr -o ipaddr
例:
username@avi:~$ | change_ip.py -i 10.10.25.81 -o 10.10.25.82 -o 10.10.25.83
このコマンドは、ノード 10.10.25.81 で実行されます。これはノード 10.10.25.82 および 10.10.25.83 も含む 3 ノード クラスタのメンバーです。
スクリプトは、クラスタ内の任意のノードで実行できます。次の例は、ノード 10.10.25.82 で実行されます。
username@avi:~$ | change_ip.py -i 10.10.25.82 -o 10.10.25.81 -o 10.10.25.83
change_ip.py を実行した後、失敗した場合は、recover.py を使用してノードを単一ノードに変換し、3 ノード クラスタを再度作成します。詳細については、『VMware NSX Advanced Load Balancer 管理ガイド』の「動作しない Controller クラスタのリカバリ」を参照してください。
システムが十分に機能しているかどうかを確認するには、[Controller ノード] ページに移動して、すべてのノードが CLUSTER_ACTIVE
であるようにしてください。
Nutanix クラスタでコントローラ IP アドレスを変更する手順
Nutanix クラスタでコントローラ IP アドレスを変更するには、次の手順を実行します。
ホストのネットワーク スクリプトを手動で編集し、インターフェイス構成を変更して、クラスタ内の各 Controller ノードの IP アドレスを新しい IP アドレスに変更します。
たとえば、Controller の仮想マシンの
/etc/network/interfaces/
ファイルは、次のように変更する必要があります(静的 IP を使用している場合)。auto lo iface lo inet loopback auto eth0 iface eth0 inet static address <ipv4 address> netmask 24 gateway <ipv4 gw>
新しいコントローラ IP アドレスが、他のコントローラ ノードからネットワーク内でアクセス可能であることを確認します。
スクリプト
/opt/avi/python/bin/cluster_mgr/change_ip.py
を Controller で実行して、先の IP アドレス変更を反映します。Controller を再起動します。
3 ノード クラスタ展開の場合は、すべての Controller で IP アドレスを変更してから、次に示すコマンドを任意の Controller ノードから実行してクラスタの Controller の IP 情報を更新する必要があります。
username@avi:~$ change_ip.py -i **ipaddr **-o ipaddr -o ipaddr
以下に、各コマンドについて説明します。
-i ipaddr
:スクリプトを実行するノードの新しい IP アドレスを指定します。-o ipaddr
:クラスタ内の別のノードの IP アドレスを指定します。-m subnet-mask
:サブネットも変更された場合は、このオプションを使用して新しいサブネットを指定します。マスクは 255.255.255.0 という形式で指定します。-g gateway-ipaddr
:デフォルトのゲートウェイも変更された場合は、このオプションを使用して新しいゲートウェイを指定します。注:再起動した Controller クラスタは新しい IP アドレスになっていなければなりません。
考慮事項
次の考慮事項に注意してください。
インターフェイス名(eth0、eth1 など)と、検出された MAC アドレスは、静的なので変更はできません。
プライマリ (eth0) インターフェイスは、ラベルの他は変更できません。
デフォルト ゲートウェイを新しいインターフェイスに構成することはできません。
すべてのラベルは、何らかのインターフェイスの一部である必要があるため、1 つのラベルを複数のインターフェイスで繰り返し使うことはできません。
新しいインターフェイスでは、静的 IP モードのみがサポートされます。DHCP はサポートされていません。
アクセス コントロールが適用されるのは、プライマリ インターフェイスのみです。新しいインターフェイスへのインバウンド SSH などのアクセスを制限するには、これまでどおり外部ファイアウォール設定を使用してください。
/etc/network/interfaces ファイルは編集しないでください。すべての構成(IP アドレス、スタティック ルートなど)は、クラスタ構成経由でなければなりません。
セカンダリ インターフェイスは、仮想マシン内での接続状態が保持されなければなりません。この接続を切断すると、仮想マシンが再起動された場合にインターフェイスが削除される可能性があります。