vSphere 7.0 U2 で、vSphere with Tanzu ＋ NSX Advanced Load Balancer のラボ環境を構築していきます。今回は、デプロイして初期設定を済ませた NSX-ALB コントローラで、スーパーバイザー クラスタ有効化のための準備を進めていきます。
前回はこちら。今回の設定内容は、前回のデプロイ直後の初期設定内容を前提としています。
ドキュメントでは、下記のあたりを参考にしています。
NSX-ALB コントローラでの設定内容です。
- 証明書の割り当て
- Service Engine Group の設定
- データ ネットワークの IP アドレス プール設定
- スタティック ルートの設定
- IPAM プロファイルの作成
- DNS プロファイルの作成
- Cloud へのプロファイル割り当て
なお今回は、NSX-ALB コントローラにデフォルトで適用されている評価ライセンスのまま進めています。
証明書の割り当て
NSX-ALB コントローラの証明書を、デフォルトで生成されるものから置き換えます。
NSX-ALB コントローラにログインして、「Administration」→「Settings」→「Access Settings」を開いて、編集ボタンをクリックします。
「SSL/TLS Certificate」にある、デフォルトの証明書を削除します。
「Create Certificate」で、あらたに証明書を作成します。
Self Signed の証明書を作成します。今回は最低限のパラメータだけ入力しています。
- Name： コントローラで管理する、証明書の名前。例では cert-lab-avi-51。
- Common Name： コントローラの FQDN。例では、lab-avi-51.go-lab.jp
- （他は省略・デフォルト値のままにしてしまいましたが、適宜設定するとよいと思います）
入力したら、下にスクロールします。
残りのパラメータを入力して、「Save」をクリックします。
- Subject Alternative Name (SAN)： コントローラの IP アドレスを入力。例では 192.168.10.96。
作成した証明書が選択されていることを確認して、「Save」をクリックします。
証明書が置き換えられたので、Web ブラウザを更新します。
せっかくなので、ここからは Web ブラウザからホスト名（FQDN）でアクセスします。ただし、自己証明書なので結局はブラウザのエラーが出ます。（そしてこのエラーは無視して進めます。）
あらためて、コントローラに管理者ユーザでログインします。
ユーザ（admin）とパスワードは、前回の手順で設定したものです。
コントローラの「Access Settings」画面でも、証明書が置き換えられたことが確認できます。
後続の、vCenter Server での「ワークロード管理」有効化手順で必要となるため、証明書を記録しておきます。
「Templates」→「Security」→「SSL/TLS Certificate」で、作成した証明書を選択して、「＋」ボタンをクリックします。
「Certificate」の内容を、なにかファイルなどに記録しておきます。
もしくは、あとで vCenter Server にて「ワークロード管理」の有効化をする際に、またこの画面を開いて確認します。
Service Engine Group の設定
NSX-ALB のデータ プレーンになる「Service Engine」のデプロイするために必要な、「Service Engine Group」を、環境にあわせて設定変更します。
「Infrastructure」→「Service Engine Group」を開き、「Default-Group」の編集ボタンをクリックします。
「Basic Settings」タブにある「High Availability Mode」で、「Legacy HA」→「Active/Standby」を選択します。（vSphre 7.0 U2 の vSphere with Tanzu でサポートされた NSX-ALB Essentials エディションでは、Active/Standby モードだけサポートされているとのこと）
「Advanced」タブで、Service Engine のデプロイ先となる、クラスタとデータストアを選択します。次のように選択してから「Save」をクリックします。
- 「Cluster」では、「Include」を選択して、vSphere クラスタを選択。
- 「Data Store」では、「Shared」を選択、「Include」を選択して、あらかじめ ESXi ホストにマウントしておいた共有 NFS データストアを選択。
Default-Group の HA Mode が「Legacy Active/Standby」に変更されたことがわかります。
データ ネットワークの IP アドレス プール設定
NSX-ALB で VIP を払い出す、IP アドレス プールを作成しておきます。
「Infrastructure」→「Networks」を開いて、データ ネットワーク（LB VIP のネットワーク。分散ポート グループと同名で、例では DPortGroup-0024-LBData）の編集ボタンをクリックします。
NSX-ALB のもつ IPAM 機能を利用するため、「DHCP Enabled」は OFF のままにしておきます。
「Add Subnet」をクリックします。
IP サブネットを入力（例では 192.168.24.0/24）を入力します。
IP アドレス プールを追加するため、「Add Static IP Address Pool」をクリックします。
「Use Static IP Address for VIPs and SE」は ON、IP アドレス プールのレンジを入力（例では 192.168.24.11-192.168.24.99）して、「Save」をクリックします。
IP Address Pool が保存されたことを確認して「Save」をクリックします。
「Networks」画面でも、IP プールの追加が確認できます。
スタティック ルートの設定
このラボでは、NSX-ALB の VIP があるデータ ネットワークと、VIP のメンバー サーバとなる Tanzu Kubernetes クラスタ ノードの配置されるワークロード ネットワークが別ネットワークです。そこで、データ ネットワーク（192.168.24.0/24。ゲートウェイは192.168.24.1）からワークロード ネットワーク（192.168.25.0/24）への、スタティックルートを追加します。
「Infrastructure」→「Routing」→「Static Route」を開き、「CREATE」をクリックします。
次のようにルート情報を入力して、「Save」をクリックします。
- Gateway Subnet： Tanzu Kubernetes クラスタの、ワークロード ネットワークのネットワーク アドレスを入力します。このラボでは 192.168.25.0/24。
- Next Hop： データ ネットワークのゲートウェイを入力します。このラボでは 192.168.24.1。
※ただ、よく考えるとこのラボのネットワーク構成であれば、（192.168.25.0/24 宛だけではなく）下記のようにDefault Gateway として登録してしまった方が無難だなと思いました。
- Gateway Subnet： 0.0.0.0/0（これで Default Gateway になります）
- Next Hop： 192.168.24.1
スタティック ルートが作成されました。
ちなみに、Tanzu Kubernetes クラスタからデータ ネットワーク宛の通信は、クラスタ ノードのデフォルト ゲートウェイで戻れます。
IPAM プロファイルの作成
NSX-ALB で VIP を払い出すための、IPAM プロファイルを作成します。
「Templates」→「Profiles」→「IPAM/DNS Profiles」を開き、「CREATE」→「IPAM Profile」をクリックします。
次のように、プロファイルのパラメータを入力していきます。
- Name： プロファイルの名前。例では profile-avi-ipam-01
- Type： 「Avi Vantage IPAM」を選択。
- Allocate IP in VRF： チェックを ON にする。
そして、「Add Usable Network」をクリックします。
IPAM を利用するネットワークを選択して、「Save」をクリックします。
- Cloud for Usable Network： Default-Cloud
- Usable Network： データ ネットワークを選択。例では DPortGroup-0024-LBData
DNS プロファイルの作成
同様に「IPAM/DNS Profiles」画面で、DNS プロフィルを作成します。
「Templates」→「Profiles」→「IPAM/DNS Profiles」にて、「CREATE」→「DNS Profile」をクリックします。
次のように、プロファイルのパラメータを入力します。
- Name： プロファイルの名前。例では profile-avi-dns-01
- Type： 「Avi Vantage DNS」を選択。
そして、「Add DNS Service Domain」をクリックします。
パラメータを入力して「Save」をクリックします。
- Domain Name： ドメイン名を入力。ただし、L4 ロードバランサとして利用する場合は関係ないようです。このラボでは、まずは L4 までの機能を利用するつもりです。（Kubernetes の Service リソースは作成するが、L7 にあたる Ingress リソースは NSX-ALB で作成しない）
IPAM プロファイルと、DNS プロファイルが作成されました。
Cloud へのプロファイル割り当て
IPAM / DNS プロファイルが利用されるように、NSX-ALB の「Cloud」に割り当てます。
ちなみに Cloud には、連携する vCenter Server の情報などが設定されています。
それでは、プロファイルを割り当てます。
「Infrastructure」→「Clouds」を開き、「Default-Cloud」の編集ボタンをクリックします。
「Infrastructure」タブを下にスクロールし、「IPAM Profile」と「DNS Profile」で、さきほど作成したプロファイルを選択して、「Save」で保存します。
これで、NSX-ALB 側での準備は完了です。まだ NSX-ALB のデータ プレーンにあたる Service Engine VM がありませんが、これは「ワークロード管理」の有効化の際に、自動的に作成されます。
次は、vCenter Server 側で「ワークロード管理」を有効化します。
つづく。
