皆様、こんにちは。
ネットワールド SEの目木です。
Workspaces Core検証レポートPart3ということで、今回は前パートまでに構築した環境をもとにコンソールから利用可能な機能について確認しつつ、また、構築途中に感じた疑問を解消していきたいと思います。
では、さっそく見ていきましょう。
前回の記事はこちら
運用コンソールの確認
まずは、Workspaceを展開した後のCitrix DaaS側のコンソールにて操作可能な範囲を確認していきます。
今までの展開において使用してきたコンソールは[管理]→[クイック展開]→[Amazon Workspaces Core]→[開始]と開いた先の展開ウィザード画面でしたが、それ以外のメニューから今回構成した環境の詳細が確認できます。
まず、[展開]画面では展開したWorkspaceと管理グループが確認できます。
こちらの画面では主にWorkspaceの追加を実行する際に使用することになるかと思います。そのほかイメージの更新というメニューもありますので、プール型で展開している場合は、こちらからマスタイメージを修正することができるのかもしれません。
残念ながら、個人型の場合は更新処理後に展開するWorkspacesのイメージが差し替えられるだけでした。Amazon Workspaces のコンソールからはWorkspacesの移行という機能で作成済みのWorkspacesにおいてイメージの差し替えができるのですが、こちらの機能は連携できていないようです。
また、デスクトップグループを選択して詳細画面を開いた画面では、展開済みのWorkspacesの一覧が確認できます。
一覧から選択したWorkspaceに対しては削除、再起動、ボリュームサイズの編集などの操作が可能です。なお、Workspaceの起動、停止はできません。
そのほか、「カスタムイメージを作成する」といったメニューが見えますが、こちらを実行すると対象のWorkspaceにおいて「イメージの作成」を実行し、作成できたイメージをCitrix DaaS側へインポートして新しいイメージとして使用できる状態まで進めることが可能です。
こちらの機能はイメージ作成の手順が短縮できる便利なものですので、管理者向けにWorkspaceを展開してアップデート用として利用するのもよいかもしれません。
次に[イメージ]画面では、インポートしたイメージが一覧で表示されます。
こちらの画面でできることはイメージの詳細確認、イメージの新規インポート、既存イメージの削除となります。一方でイメージ名の変更、説明書きの変更などすでにインポートしたイメージ情報を修正することはできませんでしたので、命名規則についてはインポート前にしっかりと決めておいた方がよさそうです。
続けて、[ディレクトリ接続]ですが、こちらはAmazon Workspacesと連携するために行った設定情報を確認することができます。
新規作成、削除も可能ですが、原則一度展開まで進めてしまえば、テナントが増えない限り同じ環境を使い続けることになるかと思いますので、こちらは特に触ることもないかと思います。
最後のアカウントは、Amazon Workspaces Coreとの連携に使用したアカウントの情報が表示されます。
設定値の詳細確認のほか、新規作成・削除、アカウントの更新といったことも可能なようですが、設定画面を見る限り別のIAM Roleへと変更することが可能、という意味合いのようですので、利用中のIAM Roleを修正して使用し続けるのであれば、特に利用することもなさそうです。
続けて、従来Citrix DaaSで利用するマシンカタログ、デリバリーグループ、検索などの画面からもステータスを見ていきましょう。
マシンカタログの画面から見てみると、ホスト連携なし、手動展開の条件にてマシンカタログが作成されていることが分かります。
「クイック展開」画面内で設定した値についてはこちらから変更することができず、[マシンカタログ名の変更]などグレーアウトしている項目も多く見受けられます。展開後の変更もAmazon Workspaces Core専用のメニューを使用させることで、不要な変更による差分たが生じることを防止できますので、妥当かと思います。
一方でデリバリーグループについては少し微妙でした。
こちらは先のウィザードとは独立しているようで、設定値に対する変更が自由にできる状態でした。デリバリーグループ名を変更するぐらいであれば問題ないかと思いますが、ユーザーの割当先を変えたりすると利用できなくなってしまいますので、基本的には触らない方が無難かと思います。
なお、ホスト連携していませんので、CitrixのAutoScale機能は利用できず、グレーアウトしています。
以上の操作メニューからもわかる通り、すべての操作がCitrix DaaS側に統合されているわけではないので、運用の際にはAmazon Workspacesのコンソールと併せて管理していくことになるかと思います。
ざっくりとですが、Citrix DaaSコンソールにおける操作可否を整理してみます。
【Citrix DaaSコンソールで操作可能】
- Workspaceの追加・削除
- 展開時のイメージ定義更新
- Citrix Policyの適用
- 接続状況の確認
- 新しいイメージの作成 ※管理者向けにWorkspaceを展開していることが条件
【Amazon Workspacesコンソールにて操作が必要】
- Workspacesの起動・停止・再起動
- インスタンスタイプの変更
- 実行モード（課金タイプ）の変更
- バックアップからのリストア
- ユーザに対するローカル管理者権限の付与
利用頻度が多い機能としてはWorkspaceの電源操作機能があげられますので、こちらの統合については早々に改善されることを期待したいところです。
さて、ここからは環境構築中に個人的に気になった点について見ていきたいと思います。
1. Amazon Workspacesの認証設定はCitrix Workspace認証時も有効なのか？
Amazon Workspacesのディレクトリ設定では「アクセスコントロールオプション」、「IPアクセスコントロールグループ」など、Workspace利用環境を制限する機能がありますが、こちらがWorkspaces Coreでも利用できるのか確認しました。
結論として、これらの機能はCitrixのポータルから起動した場合には機能しませんでした。どうやらWorkspacesのAuth Gatewayへアクセスする際に条件を満たしていない接続を禁止しているようで、Workspacesへのログインについてはこちらの機能の範囲外となるようです。
仮にこのような接続環境の制限を行うのであれば、Citrix DaaS側でDevice Posture、Set-BrokerAccessPolicyRuleコマンドによるアクセス制御などの制限機能の実装を検討するとよいかと思います。
2. Citrix DaaSコンソールより展開したWorkspaceはDCVでも接続可能なのか？
Citrix DaaSのコンソールから展開しているとはいえ、実態はAmazon Workspaces上からも確認できますので、DCVによる接続への影響はなさそう、ということでの確認になります。
結果、ICAとDCVのどちらにおいても接続は可能でした。仮にCitrix Cloudに障害がでるような事態があった場合はDCVによる接続をワークアラウンドとして残しておくこともできそうです。
逆にDCVによる接続を禁止したければ、先の「アクセスコントロールオプション」、「IPアクセスコントロールグループ」によって利用を制限しておくのもよいかと思います。
3. GPOの必要性
WorkspacesにインストールしたVDAからCitrix Cloud Connectorサーバへ通信ができるようにGPO上でCitrixポリシーを構成していましたが、こちらの必要性について確認を行います。
GPOを無効としたうえで、VDAのインストールから手順をやり直し、Delivery Controllerの指定にて手動でCloud ConnectorサーバのFQDNを指定してインストールすることで、この設定値が展開後も引き継がれるか確認しています。
結果として、展開後のWorkspaceに対してListOfDDCsの値は正常に引き継がれていました。
少なくとも個人型であればGPOの設定はなくとも問題ないように見受けられます。
4. 完全閉域網は実現可能か？
クラウド基盤＋VDIにて構成する際によく要件としてあがる内容として完全閉域網による構成があります。こちらはユーザーがVDIを利用するための認証、ストリーミングのための通信をインターネット上に出さないことでセキュリティを強固にするといった内容であり、Citrixが選定される理由の一つでもあります。
結論としてこちらの構成自体はWorkspaces Coreであっても実装可能でした。
まず、認証パスについては認証サーバであるStoreFrontをEC2に構成します。
StoreFrontを通して認証を行った場合のストリーミング通信については、デフォルトでVDIのIPアドレスをもとに接続されます。
このことによりユーザの端末とWorkspaces間の経路が確保されている状況であれば、閉域環境においてもWorkspacesを提供することが可能になります。
5. WorkspaceタイプがプールのディレクトリはCitrix DaaSから接続できるのか？
今回確認してきた構築手順を追っていきますと、作成されるディレクトリは必ず個人向けとして設定されてしまいます。
こちらはそもそもプール型の場合ディレクトリサービスを使用することができないため、未登録状態のディレクトリを生成しておくことができないためです。
このような状況で、プール型のWorkspacesを構成することができるのかについては、現在調査中でして、結論が分かりしだいこちらのブログで報告したいと思います。
※現時点では個人型のディレクトリと連携している状況において、ユーザを紐づけないプール型での展開に失敗しています。
まとめ
ということで、今回の検証ではCitrix DaaS for Workspaces Coreについて検証してまいりました。
現時点では、操作が統合できていない部分もありますので、従来どおりの使用感で管理できるわけではないですが、AWS上でコストを抑えつつCitrixの機能を利用可能であるVDIソリューションの選択肢として検討いただければと思います。
なお、弊社としましてもCitrixおよびAWSの構築サービスを提供しておりますので、ご興味がありましたら弊社営業までご連絡くださいませ。
最後まで読んで頂きありがとうございました。
