vSphere6から誕生したPSCとSSOについておさらい

vSphere6が出て1年半が経とうとしています。
もう、この時期から新規構築でvSphere5.xを選択するケースは少なくなってきたかと思います。


vSphere6では、様々なところでアーキテクチャーの変更が加えられておりますが、構築の時点で一番に気が付くのは、vCenter Server Applianceのデプロイ方法だと思います。
昔は、OVFをぽいっとするだけで終わっていたのですが、今では少々面倒はWebのウィザードを経由してデプロイをする必要があります。

一方で、Windows版のvCenter Serverは、Embeded DBのアーキテクチャーが、PostgreSQLに変わったぐらいで、あまり変化がないように思いますが、プラットフォームに関係なく大きくアーキテクチャーが変わっているところがあります。

それが、「PSC」の存在です。
PSCは、Platform Service Controllerという名前で、vSphere5.5まであった、SSOの後継となります。

その昔、vSphere5.0までは、ADが必須という条件がありましたが、vSphere側にSSO機能を持つことで、AD必須という条件が取れたことは、非常に大きなアップデートだっだように思います。
（もともとV4.xやV5.0のvCenter Serverでも非サポートながら、Workgroupでのイストールで動作していた実績がありますが）

PSCは、従来のSSOと違い、

• Single Sign-On (SSO)
• ライセンス
• 認証局
• 証明書ストア
• サービス（製品）登録

の機能を保有しています。

さらに、このPSCと今までのvCenter Serverは、独立した仮想アプライアンス（仮想マシン）として展開することも可能です。

ここで重要になるのは、vCenter ServerとPSCは、サーバーをまたいで通信をする構成になっているということです。
ということは、PSCとvCenter Serverで、きちんと名前引きができるDNSを構築しておかなければならないという事情があります。

PSCとvCenter Serverを同一の構成で作成すれば、同じホスト名だから問題ないよねと思うケースもあるかもしれませんが、NSX ManagerやvShield Managerなど、PSCを経由して、vCenter Serverと接続する連携製品は、それら連携製品がPSCとvCenter Serverの両方のホスト名を名前引きできないと、ただしく接続できません。

ここで、ポイントです。
vCenter Serverをインストールする際に、PSCを共にインストールをしますが、PSCをインストールする際に定義されたホスト名が、そのままPSCで構築されるSSOのURLの一部として利用されます。

Windows Serverにインストールする際、あらかじめホスト名にドメインサフィックスを入れてないと、そのホスト名だけがSSOのURLとして利用されるため、NSX ManagerのようなほかのアプライアンスからSSOにアクセスする際、FQDNになっていないため、SSOサーバーにたどり着けず、認証に失敗するケースがあります。（検索ドメインを定義おり、DNS名で名前引きができれば通信は可能です）

上記から、vSphere Web Clientにアクセスするとまず、PSCにSAML認証されていることがわかります。

vCenter Serverをインストールする際は、

• DNSサーバーを構築し、vCenter Server、PSC（別立てする時）の正引き、逆引きをかならず設定する
• Windows版の場合、vCenter Serverのインストール前に、DNSドメインサフィックスを設定し、ホスト名をFQDNの形式で設定をする

の２つを忘れないことが、とりあえずvCenter Server入ったけど、外部製品との連携ができないとか、vSphere Web Clientが正しく開けないといったトラブルを防ぐことができます。