みなさま、こんにちは。ネットワンシステムズ株式会社の児玉と申します。
このエントリでは、ネットワンシステムズが VMware Cloud on AWS 上で Horizon 7 環境を構築した際に考慮した事項と検証の結果をご紹介させて頂きます。
VMware Cloud on AWS の概要やオンプレミス環境との接続方法はネットワンシステムズの匠コラムでご紹介させて頂いておりますのでこちらも併せてご覧いただけますと幸いです。
構成の検討
今回の ”Horizon 7 on VMware Cloud on AWS” の検証を実施するにあたっての大きな目的は2つありました。
1つ目は AWS 上で vSphere 環境が提供される VMware Cloud on AWS 環境において Horizon 7 の動作を実際に確認するという点。
2つ目は VMware Cloud on AWS のネットワークとオンプレミスを接続した上で、VMware Cloud on AWS とオンプレミス間で Cloud Pod アーキテクチャを利用したディザスタリカバリ検証を実施する点です。
Cloud Pod アーキテクチャとは、データセンターをまたいで Horizon 7 を展開する際などに利用できる技術となり、各データセンターで個々に利用されていたHorizon 7 の環境を統合することにより、複数のデータセンター間での管理を効率化や災害や障害発生時における可用性を高めることができる仕組みです。
今回の構成では VMware Cloud on AWS とオンプレミスの 2 つの環境を接続して検証を実施しますのでオンプレミスのシステムが停止した場合を想定した、ディザスタリカバリ用途での検証もすることとしました。
図1:Cloud Pod アーキテクチャ概要
上記の目的を踏まえ、私は次の図のような環境を作成することにしました。
この構成ではオンプレミス環境と VMware Cloud on AWS の SDDC を IPsec VPN を利用してネットワーク接続しています。
IPsec VPN は VMware Cloud on AWS が持つ VMware NSX Data Center の Gateway によって提供され、VMC Console から SDDC の VPN を有効化する事が可能です。
ネットワークを接続したのち、Active Directory の Replication と Horizon 7 Cloud Pod アーキテクチャの構成を実施するという順序になります。
図2:環境構成図
環境の構築
VMware Cloud on AWS では SDDC として vSphere 環境が提供されます。VMware Cloud on AWS 上で VMware Horizon 7 を利用するには vSphere 上に Horizon 7 の構成コンポーネントを構築する必要があります。これは、オンプレミス環境に VMware Horizon 7 を構築する際の手順と同様です。
VMware Cloud on AWS の vCenter Server は、SDDC 作成時に指定する管理用のプライベートネットワークアドレスから自動的に採番されます。
インターネット経由で vCenter Server に対してアクセスして管理することを可能にするために、vCenter Server の IP アドレスはグローバル IP アドレスに NAT され、FQDN として ”vcenter.sddc-xx-xx-xx-xx.vmwarevmc.com” が、VMware が管理する DNS に登録されます。
SDDC 内部で VMware Horizon を構築する際に、VMware Horizon 7 Administrator や App Volumes Manager などの管理マネージャから vCenter Server を登録する必要があります。
この際、SDDC 内部では vCenter Server の実IPアドレスに対してアクセスする必要がありますが、デフォルト状態では vCenter の FQDN に対してグローバル IP アドレスを返すため、SDDC 内に作成した管理マネージャから vCenter Server を指定する場合には下記の 2 つのうちどちらかの方式を検討する必要があります。
1 つ目のパターンは、vCenter Server の FQDN とグローバル IP アドレスが紐付けられているデフォルトの状態のまま、SDDC 内のコンポーネントの hosts ファイルを利用して vCenter Server とローカル IP アドレスを紐付ける方法です。
2つ目のパターンは、VMC Console の DNS の設定で vCenter Server の FQDN とローカル IP アドレスを紐付ける方法です。この場合、各コンポーネントの hosts ファイルを編集する必要はありませんが、インターネット越しに vCenter Server にアクセスすることができなくなります。
インターネット越しに vCenter Server にアクセスするホストがある場合、該当のホストの hosts ファイルで vCenter ServerのFQDN とグローバル IP アドレスを紐付ける必要があります。今回の検証では、パターン2を利用することとしました。
図3:vCenter ServerのFQDN解決パターン
検証
環境の構築が終わりましたのでいよいよ検証になります。まず初めに Horizon 7 インスタントクローン VDI を展開して問題なくアクセスができることを確認しました。
インスタントクローンとは、Horizon 7 VDI を展開する際に利用できる VM 展開方式の1つであり、従来のリンククローンと同様に vCenter Server の親 VM に基づいてクローン VM が作成されます。インスタントクローンはリンククローンに比べて高速であるため多くのデスクトップを短時間で展開することが可能です。
図4:実際にデプロイしたインスタントクローン VDI (vCenter Server 上より)
次にこれらのデスクトップ間で分散ファイアウォールを利用してみたいと思います。
分散ファイアウォールは、ハイパーバイザ上で提供されるファイアウォールであり、各仮想マシンの仮想 NIC 単位でパケットのフィルタリングを提供するため、従来の境界型ファイアウォールに比べて、きめ細かい制御を提供できる機能です。
VMware Cloud on AWS 上で利用できる分散ファイアウォールは VMware Cloud on AWS 内の NSX によって実現されており、今回はデスクトップ間のネットワーク通信を制御する検証を行いました。仮想マシン間のネットワーク通信を制限することにより、デスクトップがマルウェアに感染した場合の他のデスクトップへの感染リスクを低減し、ワークスペース全体のセキュリティを向上することが可能です。
VMware Cloud on AWS の分散ファイアウォールの設定は VMC Console の分散ファイアウォール画面で行います。今回はデスクトップ間の通信を制限するためにApplication Rules を追加しました。
対象となる仮想マシンをメンバーシップという形でグループ化し、送信先や送信元にグループを指定して通信を制限するルールを作成します。
今回は展開したインスタントクローンデスクトップを対象として「VDIs」というグループを作成しました。
赤枠で囲んである「Inter VDIs」というルールでは、「VDIs」グループ内のすべての通信を Reject (拒否)しています。この設定により、デスクトップ同士の通信を制限することができました。
図5:分散ファイアウォール(Application Rules)の設定
以下の画像では VDIs グループに登録されたデスクトップ上で開いたコマンドプロンプトから、VDIs グループに登録された他のデスクトップに対して ping を送信しています。
最初の方は ping が応答していますが、分散ファイアウォールルールをオンにしたタイミングで ping に応答しなくなり、分散ファイアウォールが機能することを確認できました。
図6:分散ファイアウォールの動作
最後に、分散ファイアウォールで利用するグループの作成方法を見てみましょう。グループのメンバーシップの評価基準として、次の要素を利用する事ができます。
- IP Address (静的)
- VM Instance (静的)
- 仮想マシン名 (動的)
- セキュリティタグ (動的)
今回はインスタントクローンで作成する仮想マシンのプリフィックスとして「awsinstant-」を指定したため、Property で「仮想マシン名」を選択し「awsinstant-」という文字列が名前に含まれる仮想マシンのすべてを対象に「VDIs」グループに登録しました。
図7:分散ファイアウォールのメンバーシップ作成
これまで、Horizon 7 の動作の確認と分散ファイアウォールによるネットワークセキュリティ機能を確認することができました。最後に Cloud Pod アーキテクチャを利用したディザスタリカバリ用途での検証をご紹介いたします。
今回の検証実施期間に弊社内の検証設備の法定停電が重なったことにより、期せずしてオンプレミス側障害発生時の挙動を確認することができました。
今回行った Cloud Pod の設定をご紹介します。VMware Cloud on AWS 上にある Horizon 7 Connection Server で構成される VMC Pod には、”VMC User” というユーザを割り当てています。
また、オンプレミス上にある Horizon 7 Connection Server で構成される ”On-Premise Pod” には ”On-Premise User” というユーザを割り当てています。
まず、VMware Cloud on AWS とオンプレミス双方が正常に動作している環境を見ていきましょう。
双方の環境が正常に動作している場合、自身の割り当てられている Pod 側の Horizon 7 Connection Server に接続を行うとその Pod 内のデスクトップにアクセスをすることができます。
図8:正常時の Cloud Pod 動作(1)
また、自身が割り当てられていない Pod の Horizon 7 Connection Server にアクセスした場合も、双方の環境が正常に動作を行っているのであれば自身の割り当てられている Pod のデスクトップに対して接続を行うという動作になります。
図9:正常時の Cloud Pod 動作(2)
次に、Cloud Pod 環境においてオンプレミス側がダウンした場合の動作を見ていきます。
正常時には前述のように、それぞれのユーザはアクセスする Horizon 7 Connection Server に関わらず、自身が割り当てられた Pod にあるデスクトップにアクセスを行います。
今回、オンプレミス側がダウンしたため、オンプレミス側Podのデスクトップにアクセスを行うことができません。
しかし、このような場合においても ”On-Premise User” が ”VMC Pod” 内のデスクトップにアクセスする動作をすることが確認できました。
図10:オンプレミスダウン時の Cloud Pod 動作
このように、既にオンプレミス環境において Horizon 7 を利用している環境であっても VMware Cloud on AWS と Cloud Pod アーキテクチャを併用することにより柔軟で可用性の高いワークスペース環境を提供・維持可能であることが分かりました。
まとめ
今回は VMware Cloud on AWS 環境を利用した VDI の動作確認と分散ファイアウォールを利用したセキュリティ機能、及び Cloud Pod アーキテクチャでオンプレミス環境と併用してデスクトップの可用性を高める検証をご紹介させて頂きました。
VMware Cloud on AWS では、このほかにも多種多様な AWS のネイティブサービスとの連携や Amazon VPC 上のサーバとの接続といった様々なメリットがあります。今回は全てをご紹介できませんでしたが、今後機会がございましたらご紹介させて頂きたいと考えております。
執筆者プロフィール
児玉 賢祐
ネットワンシステムズ株式会社 ビジネス開発本部
第3応用技術部 第1チーム 所属
ネットワンシステムズ入社後 VMware Horizon 7 を利用した VDI や RDSH、ワークスペース可視化製品などを担当。
