この記事はvExperts Advent Calendar 2024の５日目の記事です。
Avi Load Balancerはコントロールプレーンとデータプレーンが分離したアーキテクチャを持っている仮想ロードバランサーで、テナントを作成してコントローラの設定をテナント毎に分割したり、データプレーンの提供方法も管理者が一元的に行うのか、テナントユーザがセルフサービス的に利用するのかを選択できたりと、マルチテナントに関わる設定が充実しています。
ただ私自身あまりこの辺りの設定に関する整理と理解が追いついていないので、この機に触りながら整理をしてみようという記事です。
注）ロードバランサーとしての使い方や設定については本記事で触れません。
前提条件
バージョン 30.2.1
Cloud設定はNo Ochestratorで設定
Cloud設定の説明
CloudはAviの設定において、データプレーンの供給元基盤の設定となります。
vSphereをOchestratorとするCloudを作成した場合は、vCenterやESXiのクレデンシャルとIPアドレスなどを入力して連携することで、データプレーン仮想マシンが連携先の基盤上に作成されます。AWS等のパブリッククラウドをCloudとして設定することも可能です。
No Ochestratorは特に他と連携せず、手動でコントローラからデータプレーン仮想マシン（サービスエンジン、SEと呼ばれる）のOVAをダウンロードし、同じくコントローラ上でAuth Tokenを生成してOVAデプロイ時に登録する方法となります。
画像の右の方にある下矢印のアイコンでOVA（もしくはqcow2）のダウンロード、鍵のアイコンでAuth Tokenの生成をそれぞれ行います。
テナントとユーザ
初期状態ではadminテナントとadminユーザが存在しています。
adminユーザにはスーパーユーザという属性が設定されており、全テナントに対する書き込み権限を有しています。
また、別のテナントやユーザ、ロールの作成が可能です。
テナントの作成画面は下記のようにシンプルです。
（2つのチェックボックスについては後ほど説明します）
テナント作成後、ユーザに対してどのテナントにどの権限を割り当てるかを設定できます。
下記画像はユーザ設定の中のテナントとロールに関する部分です。
すべてのテナントを対象としたロールと個別のテナントに対するロールを設定可能です。
ロール自体についてはいくつかビルトインされたものがあり、カスタムロールを作成することもできます。
下記画像のようにそれぞれの設定項目について、書き込み、読み込み、アクセス不可の3種類から権限を設定できます。
adminユーザにはデフォルトですべてのテナントに対する「Tenant-Admin」ロールが割り当てられており、Tenant-AdminロールはCloudやサービスエンジンなどデータプレーンに関わる設定、ロードバランサーとしての設定含め、そのテナント内のほぼすべての設定を行うことができます。（テナントやユーザの追加削除編集等は行えない）
複数のテナントにアクセス権を有するユーザはGUI右上にテナントコンテキストを切り替える箇所があり、そこから特定のテナントのGUIに切り替えることができます。
テナントを切り替えると、そのテナント内の設定のみが表示され、他のテナントの設定は見えなくなります。
また、スーパーユーザは「すべてのテナント」に切り替えることで全テナントの設定を確認できます。
サービスエンジン コンテキスト
Aviのコントローラをデプロイし、初回のGUIアクセスの際の初期設定画面にも出てくるのが、このサービスエンジンコンテキストの設定です。サービスエンジン（SE）はAviのデータプレーンを担う仮想マシンになります。
冒頭でもお話した、データプレーンの提供を管理者が一元的に行うか、テナントユーザがセルフで行うか、を決定するための設定となります。（そのため、どちらかのモードでテナントを作成後は、既存テナントをすべて削除しない限り変更できません）
プロバイダコンテキスト（共有）を設定した場合、サービスエンジンはadminが管理・供給するものとなります。
admin以外の各テナントのユーザはadminが作成したCloudを使用してSEをデプロイするということができなくなります。（Auth Tokenを生成できなくなる）
Cloud設定はadminテナントのものか、それ以外の一般テナントのものかで区別されており、adminテナントに作成したCloud設定は基本的にどのテナントに切り替えても（自分のテナントのCloud設定にアクセスできるロール権限があれば）表示され、アクセスを行うことが可能です。ただ、表示はされますがAuth Tokenは生成できない状態となるため、そのCloudにサービスエンジンをデプロイすることはできません。
そもそもadminがサービスエンジンを提供するなら一般テナントユーザはCloudやサービスエンジンの設定を確認できる必要がないのでは、という疑問があります。その場合、テナント設定にあった2つのチェックボックスのうちの1つ、「プロバイダサービスエンジンへのテナントアクセス」をOFFにします。
これをOFFにした場合、Cloudやサービスエンジン、VRFの確認、設定が行える、「インフラストラクチャ」設定タブに、そのテナントのユーザがアクセスすることはできなくなります。
逆にサービスエンジンコンテキストをテナントコンテキストに設定した場合、adminテナントにあるCloudを利用しAuth Tokenを生成してサービスエンジンをデプロイすることが、他のテナントユーザにも可能となります。
adminテナントのCloudを利用して作成されたサービスエンジンも、Auth Token生成時にどのテナントのTokenなのかが判別できる情報が含まれており、デプロイされたサービスエンジンはAuth Tokenで指定されたテナントのものとして、そのテナントのサービスエンジングループ（サービスエンジンをグループ化して冗長化方式などを決める設定）に所属する形となります。
上記の図のように、「すべてのテナント」に切り替えてサービスエンジングループを確認すると、Admin-Cloud配下に各テナント用のサービスエンジングループが存在します。
その他、adminテナント以外のテナントユーザが自分のテナント上にCloud設定を作成することも権限があれば可能です。
その場合、そのCloud設定は他のテナントからは見えず、作成したテナント専用のCloud設定となります。
テナントVRF
1つのサービスエンジン内に複数のVRFを作成し、テナントのVLANを収容してルーティングすることができます。
No OchestratorのCloudで作成したサービスエンジンであればVLANインターフェースを作成できるので、1つのvNICに対して複数のテナントのVLANを持たせて、それぞれのVLANインターフェース毎にVRFを設定できます。
これによりテナント間でIPアドレスが重複していても、VRFが別れていれば正しくロードバランスできます。
AviのVRF設定はCloudに紐づいており、デフォルトではCloud毎にglobal VRFのみ存在しています。
adminであれば、adminテナントのCloudにあるVRFに対して、追加でVRF作成やルート設定を行うことが可能です。他のテナントユーザはadmin CloudのVRFに対してなにか操作を行うことはできません。
そのため、サービスエンジンコンテキストがテナントコンテキストで、かつadminの用意したCloudを利用して各テナントがサービスエンジンを作成する想定だと、VRFの作成やルート設定の部分のみセルフではなくadminが行うことになります。
一貫性という意味ではテナント側にセルフでルーティング設定も行えるようにしたいという場面もあると思いますので、その場合、テナント設定の中にあった「テナントVRF」のチェックをONにします。
これをONにすることで、テナント作成されると同時にadmin CloudのVRFに対して追加でそのテナント用のVRFが自動作成されます。また他のテナントからは分離された状態で自テナント用の他のVRFを追加したりルートを追加・編集することもテナントユーザ自身で可能になります。
adminテナントのCloudではなく、各個別のテナントが作成したCloudのVRFに対しては、元々そのテナントのユーザが権限に応じてVRFの設定を行う事が可能ですので、上記テナントVRFの設定は特に影響しません。あくまでadminのCloudに対する設定となります。
まとめ
まとめてみると言いつつまとまりのない記事になっておりますが、ここまでの設定と挙動を見ると、以下の2つがベースとなるのかなと個人的に思いました。
- adminがインフラストラクチャ（Cloud、サービスエンジン、VRF）を一元管理する場合
・サービスエンジンコンテキスト：プロバイダコンテキスト
・プロバイダサービスエンジンへのテナントアクセス：OFF
・テナントVRF：OFF
・各テナントユーザのロール：ビルトインのものだとApplication-Adminなどインフラストラクチャ設定に権限が無いもの
- 各テナント自身でインフラストラクチャまで管理する場合（Cloud設定はadmin提供）
・サービスエンジンコンテキスト：テナントコンテキスト
・プロバイダサービスエンジンへのテナントアクセス：ON
・テナントVRF：ON
・各テナントユーザのロール：Tenant-Adminなどインフラストラクチャの設定まで権限をもつもの