皆様、こんにちは。
ネットワールド SEの目木です。
今回はWorkspaces Core検証レポートPart2ということで、Part1にて事前準備まで進めた環境においてCitrix DaaSとWorkspaces Coreの連携を行い、Workspacesを展開してユーザーから利用できる状態まで構築を進めてまいります。
連携作業のためにはCitrix DaaSのコンソールにて作業が必要になります。
Citrix DaaSのコンソールにて[管理]→[クイック展開]→[Amazon Workspaces Core]→[開始]と展開すると初期構成用のセットアップウィザードが表示されるので、こちらの手順に従って手順を進めていきます。
- リソースの場所を作成する
- Amazon Web Serviceアカウントを接続する
- ディレクトリ接続の作成
- イメージのインポート
- 展開をユーザに配信する
なお、前回同様、以下のCitrixドキュメントについても参考にしています。
Citrix DaaS for Amazon WorkSpaces Core | Citrix DaaS
Part1はこちら
Citrix DaaS for Workspaces Core 検証レポート Part1 ー 製品概要の確認 ー - ネットワールド らぼ
1.リソースの場所を作成する
リソースロケーションについては事前準備で作成済みですので、ここではEC2上でCitrix Cloud Connectorサーバを構成してリソースロケーションへの登録を行います。
Citrix Cloud ConnectorはWindows Serverでの構成が必要ですので、Windows Server 2022 OS の仮想インスタンスを2つ構築し、日本語化、ドメイン参加まで進めたのち、Citrix Cloud Connectorのインストールを実行します。
Citrix Cloud ConnectorのインストールモジュールはCitrix Cloudコンソールの「リソースの場所」画面より入手可能ですので、対象のサーバへログイン後にCitrix Cloudのコンソールへアクセスして入手しています。
インストールはウィザードの指示に従って進めていきます。
マイアカウントによるログイン、Citrix Cloudのテナント、リソースロケーションを指定してインストールを実施、インストール完了後には接続テストが自動で実行され、そちらのテストをクリアすれば完了となります。
最後の接続テストはCitrixが管理するControl Planeへの接続確認ですので、もしエラーが出る場合は通信要件について今一度確認が必要となります。
接続テストが完了すると、Citrix Cloudのコンソール側でもステータスがグリーン状態で表示されます。
2.Amazon Web Servicesアカウントを接続する
Workspaces Coreとの連携についてはCitrix DaaSからAPIにてAmazon Workspacesとやり取りすることになりますので、連携時に使用するアカウントを定義していきます。
まず、AWSアカウントの認証では役割IDとしてIAM Roleの情報を登録します。
役割ID：<前提条件で作成した「CitrixAssumeRole」のARN>
名前：<任意の名前>
続けてWorkspacesの展開先リージョンの選択として、今回はAsia Pacific (Tokyo)を選択しています。
なお、対象のAWSのアカウントにおいてBYOLを有効にしていないため警告文が表示されていますが、サーバOSにて構成するのであれば問題ないため、無視します。
最後に設定値を確認して接続アカウントの定義は完了となります。
3.ディレクトリの接続
続けて、先ほど設定したアカウント情報をもとにWorkspacesのディレクトリ情報へ接続していきます。
ディレクトリ接続情報として以下の内容を指定します。
リソースの場所：<リソースロケーションを選択>
アカウント：<手順2で作成したAmazon Web Servicesアカウントを選択>
テナント：共有
※Windows 10 / 11を使用する場合はBYOLを有効にして占有を選択
ディレクトリ：<未登録のディレクトリを選択>
サブネット：<Workspacesの展開先サブネットを2か所選択>
なお、ディレクトリについては登録済みになっているとグレーアウトして選択できませんので、Part1で準備したように事前にWorkspacesのコンソールにて登録解除しておく必要があります。
続けて、展開するWorkspaceに対する設定を選択します。
組織単位：<Workspaceのコンピュータアカウントを格納するOU>
セキュリティグループ：<Part1で調整したセキュリティグループを選択>
ローカル管理者権限の付与：はい ※用途に応じて選択
最後にディレクトリ接続名を入力して作成を実行します。
以上で、Citrix DaaS側から展開を指示するAmazon Workspacesが認識できるようになりました。
4.イメージのインポート
Amazon Workspacesのイメージ作成では、一度Workspaceを展開してアプリケーションのインストール等を行い、そこからイメージ化を行います。Workspaces Coreの場合でもその手順に差はありません。
まずは、マスタイメージを作成するために先ほど登録したディレクトリを使ってAmazon Workspaces側でマシンを作成します。作成時の条件は以下の通りです。
- Workspaceタイプ：個人用
- バンドル：Standard with Windows 10 (Server 2022 base)
- 実行モード：自動停止（従量課金）
- ディレクトリ：<任意のディレクトリ>
- ユーザ：<管理者用のユーザアカウント>
- ルートとユーザーボリュームを暗号化：無効（イメージ化するため暗号化はNG）
- ユーザーボリューム：ルート80GB、ユーザ10GB
ちなみにAWSのベストプラクティスとしては、イメージ作成時のディレクトリと展開用のディレクトリは分けておいた方がいいとの情報も確認できましたが、今回は検証ということもあり同一のディレクトリに展開しました。
展開後はAmazon Workspacesアプリケーションにて展開したWorkspaceにログインし、日本語化言語パックとCitrix Virtual Delivery Agent（VDA）のインストールを行ないした。
日本語化については特に言及するところはないのですが、VDAのインストールではサーバVDIの構築ということでシングルセッション用のインストーラを用意して、/servervdiオプションをつけてWorkspace上で実行しました。
参考：
コマンドラインを使用したVDAのインストール | Citrix DaaS
最後にWorkspaceからイメージの作成を行います。
起動した状態のWorkspaceを選択して[アクション]から[イメージの作成]と選択して、イメージ名とイメージの説明を入力することでイメージの作成が開始されます。
通常のWorkspacesではこの後にイメージからバンドルを作成し、そのバンドルを展開時のマスタとして使用するのですが、Citrix DaaSと連携するWorkspaces Coreでは、ここからCitrix DaaSのコンソールへと移ってイメージのインポートを行います。
インポートするイメージについては、VDAがインストールされていること、EC2のイメージはVDAのインストールおよびBYOLが有効となっていること、がそれぞれ要件として表示されますので、そちらを確認してからイメージの選択へ進みます。
イメージの選択として、以下の内容を設定します。
名前：<任意の名前>
アカウント：<Amazon Web Servicesアカウントを選択>
イメージ：<作成したイメージの選択>
セッションサポート：シングルセッション
Graphics G4dnの取り込みプロセスの仕様：無効
こちらの設定後、概要を確認してインポートを開始します。
イメージ画面において[状態]が「使用可能」となるとインポート完了となります。
インポートの時間はイメージのサイズにもよるかとは思いますが、実測としてインポートには10分ほどかかりました。（ドキュメント上では1時間程度かかる可能性がある、といった記述もあります）
イメージの準備はこれで完了となります。
5．展開をユーザに配信する
先ほどインポートしたイメージをもとにWorkspaceを展開して、ユーザが利用可能な状態にしていきます。
イメージとパフォーマンスということで、利用するディレクトリ、イメージを指定のうえ、どのようなインスタンスサイズで展開するのか、決定します。
先ほどインポートしたイメージをもとにWorkspaceを展開して、ユーザが利用可能な状態にしていきます。
イメージとパフォーマンスということで、利用するディレクトリ、イメージを指定のうえ、どのようなインスタンスサイズで展開するのか、決定します。
ディレクトリ接続：<リソースロケーションを選択>
イメージ：<インポートしたイメージを選択>
パフォーマンス：スタンダート
デフォルトのボリュームサイズ：ルート 80GB, ユーザ 10GB
※リソースについては最低限テスト可能な値としました。
続けて、ボリュームの暗号化を設定します。
ボリュームを暗号化する：無効
※検証の都合上、再度イメージ化する可能性があったため無効としました。
（有効の場合）
暗号キーの選択：AWS管理KMSキーを使用する／顧客管理キーを使用する
デスクトップの展開条件についても設定します。
デスクトップの作成方法：デスクトップ作成中にユーザーを割り当てる
ユーザアカウント：<任意のユーザを指定>
ここでは、以下のとおりに選択します。
「ユーザーを割り当てずにデスクトップを作成する」＝プール型
「デスクトップ作成中にユーザーを割り当てる」＝個人型
ここで個人型を選択した場合は、ユーザーアカウントについても選択します。
最後に概要画面にて「展開の名前」を入力して展開を実行します。
展開の名前：<任意>
こちらで指定した名前はCitrix側のマシンカタログ名、デリバリーカタログ名としても使用されますので、そこを意識して命名するとよいかと思います。
Workspaceの展開が完了しますと、Workspaces側ではバンドルとWorkspaceが、Citrix DaaS側では、マシンカタログ、デリバリーグループがそれぞれ作成され、管理下のVDIとしても表示されるようになります。
Workspaceの起動はAmazon Workspaceのコンソール側からしかできませんので、そちらのコンソールへ移り、Workspaceを起動してCitrix DaaSとしてVDAが登録済みなることを確認して展開作業は完了となります。
接続テスト
展開したVDIについてはデリバリーグループ上でも割り当てが完了していますので、そのまま接続することが可能です。テストのためにユーザ端末にCitrix Workspace Appをインストールしてからテストは実行しています。
Citrix CloudのコンソールからポータルサイトのURL情報を取得してアクセスします。
表示された認証画面にて<ドメイン>\<ユーザ名>とパスワードを入力してログインを実行します。
ちなみに、Amazon Workspacesの認証ではsAMAccountNameが使用できましたが、Citrix DaaSではドメイン情報が必要となります。
実行可能なアプリケーションの一覧に先ほど展開したWorkspaceが表示されていますので、こちらをクリックしてICAファイルをダウンロードします。
ICAファイル内の接続情報をWorkspace Appが読み込むことで、セッションが形成され、画面転送が開始されます。
接続後の動作については、従来のCitrixにおける利用手順と変わりありませんでした。Citrix Policyの適用も別途試していますが、その点でも問題なく動作します。
注意することとして、Workspaces Coreの連携方法ではホストとの連携が行われておらずCitrix DaaS側で電源管理機能を利用することができませんでした。
そのため、Workspaceが停止している状態ではユーザ側から起動することができなくなってしまいます。
おそらくこれが原因かとは思いますが、AutoStopの実行モードについては非サポートであるとの記述も確認でき、また展開されるWorkspaceはデフォルトでAlwaysOnに設定されていました。
一応、AutoStopへと変更した場合であっても接続動作自体は問題ありませんでしたので、管理側として検証を実行する分にはAutoStopに実行モードを変更しておくとコスト削減になるかと思います。
以上にて、Workspaceの動作確認も完了となりましたので、構築パートは終了となります。
ドキュメントから想像した通り、VDIの管理にかかわる部分以外は従来のCitrix DaaS構成とおおよそ同じ構造となりました。AWSという環境に慣れる必要はありますが、構築上の選択肢はあまり多くないため、シンプルな手順で展開できるかと思います。
利用者視点であれば特別違いもないため、今までオンプレで利用していたCitrixユーザもスムーズに移行可能かと思います。
とはいえ、Citrix DaaSであれば利用可能なアプリケーション配信など、現時点で満たすことができない要件もございますので、対応範囲の拡張含め今後の開発に期待したいところです。個人的には各サービス間の処理においてブラックボックス化してしまっているところが散見されたため、もう少し状況が可視化できるようなアップデートがあると嬉しいですね。
今回も最後まで読んでいただきありがとうございました。
次回のパートでは今回展開した環境の詳細を確認しながら、途中疑問に思った内容をテストしていく予定ですので、興味がありましたらそちらもよろしくお願いいたします。
