VMware Cloud Director採用時のテナントネットワーク構成② (T0,T1 router構成)
前回までの記事は以下から参照頂けます。
VMware Cloud Director採用時のテナントネットワーク構成① (NSX for vSphere NSX-T比較)
前回はテナントネットワーク(組織VDCネットワーク)の置き換えに関しての考え方をご紹介しましたが、今回は旧NSXEdgeをどう置き換えるかに関してご紹介致します。
既存のNSX-V環境では組織VDCに対して単一or複数のEdgeVMを払い出す形でVXLANを利用した経路指定ネットワークやGWサービス(NAT,FW,LB等)を提供していました。
NSX-Tを採用する新たな環境ではこれまでのEdgeVMの役割はTier-1GWが引き継ぎます。
これまでとの大きな変更点はTier-0 router(EdgeVM,EdgeCluster)をテナント間で統合するかor分割するかを設計しなければなりません。
上記の図の通り統合する場合はTier1でのNATは必須項目となります。
分割する場合は下記の通り、専用の外部ネットワークとして指定する事により、ルートアドバタイズが有効になり、追加の設定は不要となります。
運用としては分割してしまうのも手ですが、必要リソースは非常に大きくなる為、そのあたりに注意しての設計が必要です。
次回は以下です。
VMware Cloud Director採用時のテナントネットワーク構成 ③ Tier1 GWをテナント管理者が作成可能にする方法
VMware Cloud Director採用時のテナントネットワーク構成① (NSX for vSphere NSX-T比較)
VMware Cloud Director環境のアップデートやリプレースを行わないといけないと頭を抱えている皆様。
一番の悩みは以下の二点になると思います。
・これまではNSX for vSphere(以下NSX-V) 構成だったが今後はNSX-T構成で考えないといけない。
・リプレースを行う場合はどうやって移行を行なえばいいんだ。できればオンラインで行いたい。
何れも運用面を含め非常に大きな課題となりますが今回はNSX-Tを用いた場合のテナントネットワークをどうやって既存のNSX-Vに置き換える事が可能かをご紹介いたします。
まず以下の図はNSX-Vを用いたテナントネットワークのおさらいです。
既存のNSX-V構成では上記の図の通り、以下の何れかのネットワーク構成を用いてテナントネットワークを構成可能でした。
・直接接続(VLAN)
・経路指定ネットワーク(VXLAN)
・隔離ネットワーク(VXLANアップリンク無し)
・vAppネットワーク(VXLAN、その他のテナントネットワークに接続可能(nat,FW))
※レアなケースとしてVLANネットワークプール等を利用し、経路指定ネットワークのネットワークバッキングをVLAN構成にされているケースも御座います。稀に。
上記の様に構成してテナントネットワークは今後NSX-Tを用いて以下の様に構成する必要があります。
・旧直接接続⇒直接接続 or インポート
・旧経路指定⇒経路指定
・旧隔離⇒隔離
・旧vAppネットワーク⇒vAppネットワーク
まず旧直接接続に関しては、10.2.2(2021/4/8 release)版からこれまでのvDSで作成したVLANポートグループを外部ネットワークから直接取り込む事が可能となりました。
上記とは別にNSX-Tから払い出したVLANセグメントをインポートする事も可能です。
両者ともにVLANネットワークとして機能しますが大きな違いはNSX-Tで払い出したVLANセグメントのみが分散FWの対象となる点です。
既存の運用に沿いたい場合はvDSでVLANポートグループを作成して運用するケースもあるかと思いますがその場合は分散FWの対象外となる点がネックになります。
旧経路指定、旧隔離に関してはNSX-V(VXLAN)がNSX-T(Genave)プロトコルに変更されますが同様の利用方法が可能です。
旧vAppネットワークに関しては、10.3(2021/7/15 release)からこれまでと同様の利用方法が可能(その他の組織vDCネットワークへの接続、NAT、FW)となりました。
※vApp ネットワークのフェンスは未実装です。
その他ネットワークプールに関しては現時点では基本的にはGeneveしか利用できないません。NSX-V環境下でVLANネットワークプールを利用してる場合には注意が必要です。中の人からブログで案内されているとおり、利用出なかったです。
Provider Networking in VMware Cloud Directorfojta.wordpress.com
そのネットワーク構成の比較に関しては下記のブログで分かりやすい表がアナウンスされております。
New Networking Features in VMware Cloud Director 10.3fojta.wordpress.com
今後NSX-T構成でリプレースを行う場合に上記どのネットワークに置き換える事が可能か検討する必要があります。
今回はテナントネットワークに絞ってご紹介しましたが、次回は以下をご紹介します。
VMware Cloud Director採用時のテナントネットワーク構成② (T0,T1 router構成)
VMware Cloud Director ＆ Tenant App ①
前回の記事はこちら
VMware Cloud Director(vCD)とvROps(tenant app)について
今回からはTenant Appの導入の流れをご紹介します。
Tenant Appインストールの前提条件
1：インストール及び構成されたvCD。
2：外部RabbitMQ及びvCDへの拡張設定。
3：インストールおよび構成されたvROPs。(vCDマネージメントパックの構成)
4：マーケットプレイスからダウンロードしたTenant AppのOVA
①Tenant Appovaを展開します。
ovaのデプロイの手順は非常に単純なので、ここでは取り上げません。
②Tenant Appがデプロイされて起動したら、
https://tenant-app-fqdnからアクセスします。
上記のPOPUPが表示される為、vCDを選択し、終了を押します。
③ログインページにリダイレクトされます。vROPの管理者資格情報を使用してTenantAppにログインします。
④エラー画面がPOPUPしますが[OK]をクリックして続行します。
※TenantAppでvROP管理者の資格情報を設定するための表示です。
⑤[Solutions]-[vRealize Operations]-[Username,Password]-[SAVE]をクリックし、成功表示が出る事を確認します。
⑥[Access Management]-[Access Management]-[有効化するテナントに☑]
UI統合プラグインをテナント毎に有効無効に設定可能です。
⑦[Support]-[Self Health]-[Configure with VCD Tenant UI]をクリックします。
⑧赤枠を入力し、[START]をクリックします。
※vCDのバージョンが10.2ではない場合やAMQPのポート番号を変更している場合はその旨修正してください。
⑨/tenant-app-plugin_fqdnが追加されstatusがrunningである事を確認します。
⑩[Access Management]-[Manage Users]-[ADD USER]をクリックします。
⑪作成するユーザのテナントを選択し[NEXT]をクリックします。
⑫認証情報を入力し、[FINISH]をクリックします。
※Tenant Appでの設定は上記までとなります。
⑬vCDUIにログインし[詳細]-[Customize Portal]-[Operations Plugin]-[PUBLISH]をクリックします。
⑭公開するテナントに☑をいれ[SAVE]をクリックします。
⑮チェックを入れたテナントポータルに遷移すると以下が追加されております。
[詳細]-[Operations Manager]をクリックするとログインページが表示される為、認証情報を入力します。
⑯ログインが可能になりました。
現在はvCDテナントユーザでのログインは出来かねそうです。
VMware Cloud Director(vCD)とvROps(tenant app)について
vRealize Operations は、プライベートクラウド、ハイブリッドクラウド、マルチクラウド環境向けの、キャパシティ管理、可視化プラットフォームです。
vCDとも連携が可能になっており、連携方法は下記の二種類です。
vRealize Operations Management Pack for VMware Cloud Director 8.6
vRealize Operations Tenant App for VMware Cloud Director 2.6
Management Pack for VMware Cloud Director 8.6に関しては
上記URLからマネージメントパックをダウンロードし、vROps上でインポートを行います。専用のアダプタ設定としてvCDアダプタを作成後に、vCD用のダッシュボードが表示可能になります。
ダッシュボードの編集や作成でカスタマイズを行うことも可能ですが基本的にはプロバイダ側が見る為のダッシュボードが用意されてます。
vRealize Operations Tenant App for VMware Cloud Director 2.6に関しては
テナント管理者にVMware Cloud Director環境の可視性を提供する、テナント向けアプリケーションです。プロバイダー管理者は、任意のテナントがアプリケーションにアクセスできるようにすることができます。テナントの監視、トラブルシューティング、および容量計画のユースケースを解決します。
次回はTenantAppの実装方法を紹介致します。
VMware Tanzu デプロイしてみた③ Tanzu Kubernetes Clusterのデプロイ
前回までの記事は以下から参照頂けます。
事前準備編
NSX-T 3.0 Tier0、Tier1ゲートウェイの作成、テナントネットワークの作成
TANZUデプロイ編
VMware Tanzu デプロイしてみた① ワークロード管理の有効化から名前空間の作成
VMware Tanzu デプロイしてみた② コンテンツライブラリの作成
VMware Tanzu デプロイしてみた(番外編) vSphere Podの作成からアクセスまで①
VMware Tanzu デプロイしてみた(番外編) vSphere Podの作成からアクセスまで②
今回はTanzu Kubernetes Clusterを作成します。
ログインコマンドを実行後、名前空間を指定し、デプロイコマンドを実行します。
①ログイン
kubectl.exe vsphere login --server 10.12.52.65 --vsphere-username administrator@vsphere.local --insecure-skip-tls-verify
②名前空間の指定
kubectl config use-context tanzu-ns
③TKCのデプロイ
kubectl apply -f C:\Users\tech\Desktop\k8s\tkgcluster.yaml
利用したYAMLファイルはドキュメント上のファイルの例を参考にしました。
Tanzu Kubernetes クラスタをプロビジョニングするための YAML ファイルの例
名前空間「gt-ns」配下にクラスタ「tg-tkc-01」が作成され、masternode1台、workernode3台の構成で払い出されTanzu Kubernetes Clusterのステータスが実行中と表示されます。
さっそくTanzu Kubernetes Clusterへログインを試みます。
ログイン①
kubectl vsphere login --server=10.12.52.65 --tanzu-kubernetes-cluster-name gt-tkc-01 --tanzu-kubernetes-cluster-namespace gt-ns --vsphere-username administrator@vsphere.local --insecure-skip-tls-verify
Tanzu Kubernetes Clusterのクラスタ情報②
kubectl cluster-info
Pod情報③
kubectl get pod -o wide
kubectl get pod -o wide
クラスタへのログインが行え、クラスタの情報等が確認できます。
別途Podを作成してみましたが正常に表示されました。vSphere上からはmasternode,workernodeまでしか閲覧できず配下で稼働しているコンテナに関してはTanzu Kubernetes Cluster上から確認する仕様の様です。
次回は一癖ありそうなVMware Tanzuのシステム停止及び起動方法を確認します。
VMware Tanzu デプロイしてみた(番外編) vSphere Podの作成からアクセスまで②
前回までの記事は以下から参照頂けます。
事前準備編
NSX-T 3.0 Tier0、Tier1ゲートウェイの作成、テナントネットワークの作成
TANZUデプロイ編
VMware Tanzu デプロイしてみた① ワークロード管理の有効化から名前空間の作成
VMware Tanzu デプロイしてみた② コンテンツライブラリの作成
VMware Tanzu デプロイしてみた(番外編) Netive Podの作成からアクセスまで①
前回はvSpherePodの作成からPodIPアドレスの疎通確認を実施致しました。
今回は外部からのアクセスが可能な事を確認します。
vSpherePodデプロイ時LoadBalancerを指定すると自動でNSX-Tと連携しEXTERNAL-IPを保持します。
YAML内のService でtype:LoadBalancerとして指定します。参考は以下の公式ドキュメントを参考にして下さい。
Tanzu Kubernetes サービス ロード バランサの例
EXTERNAL-IPはTanzuワークロードを構築時に指定した入力方向CIDRの範囲から払い出されます。
NSX-TからはEXTERNAL-IPがL4のロードバランサとして存在しています。
無事にアクセスできました。
次回は以下です。
VMware Tanzu デプロイしてみた(番外編) Netive Podの作成からアクセスまで①
前回までの記事は以下から参照頂けます。
事前準備編
NSX-T 3.0 Tier0、Tier1ゲートウェイの作成、テナントネットワークの作成
TANZUデプロイ編
VMware Tanzu デプロイしてみた① ワークロード管理の有効化から名前空間の作成
VMware Tanzu デプロイしてみた② コンテンツライブラリの作成
今回は番外編としてvSphere Podの作成からアクセスまでを紹介します。
※1Pod 1コンテナのシンプルな環境でのアクセス確認が目的です。
※ Tanzu Kubernetes Clusterをデプロイする為に直接必要な作業ではありません。
前々回のおさらい
上記からCLIモジュールをダウンロードします。
インストールの必要はなく、コマンドプロンプトから直接叩けます。
ログインコマンドを実行し、パスワードを入力します。
【コマンド備忘録】
kubectl.exe vsphere login --server 10.10.60.49 --vsphere-username administrator@vsphere.local --insecure-skip-tls-verify
※Serverアドレスはモジュールのダウンロードページの値を入力します。
前々回の記事で作成した名前空間へアクセスします。
【コマンド備忘録】
kubectl config use-context ns-tanzu01
※前々回記事にて作成した名前空間の名前を入力
サンプルのyamlからPodを払い出してみます。
【コマンド備忘録】
kubectl apply -f .\nginx_sample.yaml
※任意 yamlファイルは別途ご用意ください。
PodのステータスがRunning表示になりました。正常にデプロイされた様です。
【コマンド備忘録】
kubectl get pod
vSphere上からも名前空間配下にPodが作成されている事が確認できます。
Podにも自動でIPアドレスが割り当てられています。
どうやらNSX-T上から自動で払い出されたオーバレイセグメントが割り当てられています。
接続用のテストVMに該当セグメントのPortGroupを割り当てたVMからアクセスを試みましたがアクセスできません。ブラウザアクセスも同様にアクセス不能です。
切り分けようにCentOSのPodを払い出しました。
【コマンド備忘録】
kubectl apply -f .\centos.yaml
※任意 yamlファイルは別途ご用意ください。
CentOSのPodが払い出されました。
kubectlからCentOSへコンソールアクセスを行い、Ping疎通を試みます。アクセス可能でした。
次回は外部からのアクセスを確認します。
