もう、この時期から新規構築で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名で名前引きができれば通信は可能です）
vCenter Serverをインストールする際は、
- DNSサーバーを構築し、vCenter Server、PSC（別立てする時）の正引き、逆引きをかならず設定する
- Windows版の場合、vCenter Serverのインストール前に、DNSドメインサフィックスを設定し、ホスト名をFQDNの形式で設定をする
