Citrix DaaS™

Google Cloud Platformカタログの作成

マシンカタログの作成では、マシンカタログを作成するウィザードについて説明します。以下の情報は、Google Cloud環境に固有の詳細を扱います。

注:

Google Cloud Platform (GCP) カタログを作成する前に、GCPへの接続の作成を完了する必要があります。Google Cloud環境への接続を参照してください。

マスターVMインスタンスと永続ディスクの準備

ヒント:

永続ディスクは、Google Cloudにおける仮想ディスクの用語です。

マスターVMインスタンスを準備するには、計画しているマシンカタログ内のクローンVDAインスタンスに設定したい構成と一致するプロパティを持つVMインスタンスを作成および構成します。この構成は、インスタンスのサイズと種類に限定されません。メタデータ、タグ、GPU割り当て、ネットワークタグ、サービスアカウントのプロパティなどのインスタンス属性も含まれます。

  • マスタリングプロセスの一環として、MCSはマスターVMインスタンスを使用してGoogle Cloudのインスタンステンプレートを作成します。このインスタンステンプレートは、マシンカタログを構成するクローンVDAインスタンスの作成に使用されます。クローンインスタンスは、インスタンステンプレートが作成されたマスターVMインスタンスのプロパティ(VPC、サブネット、永続ディスクのプロパティを除く)を継承します。

マスターVMインスタンスのプロパティを特定の要件に合わせて構成したら、インスタンスを起動し、インスタンスの永続ディスクを準備します。

ディスクのスナップショットまたはディスクのイメージを手動で作成することをお勧めします。これにより、意味のある命名規則を使用してバージョンを追跡し、マスターイメージの以前のバージョンを管理するためのより多くのオプションが得られ、マシンカタログ作成の時間を節約できます。独自のスナップショットを作成しない場合、MCSが一時的なスナップショットを作成します(プロビジョニングプロセスの終了時に削除されます)。OSディスクまたはイメージのマルチリージョンスナップショットを手動で作成することで、異なるGCPリージョンのマシンカタログに同じマスターイメージを使用することもできます。

ゾーン選択の有効化

  • Citrix DaaS™はゾーン選択をサポートしています。ゾーン選択を使用すると、VMを作成するゾーンを指定できます。ゾーン選択により、管理者は選択したゾーンにシングルテナントノードを配置できます。シングルテナンシーを構成するには、Google Cloudで以下を完了する必要があります。

  • Google Cloudシングルテナントノードの予約
  • VDAマスターイメージの作成

Google Cloudシングルテナントノードの予約

シングルテナントノードを予約するには、Google Cloudのドキュメントを参照してください。

重要:

  • ノードテンプレートは、ノードグループに予約されているシステムのパフォーマンス特性を示すために使用されます。これらの特性には、vGPUの数、ノードに割り当てられるメモリ量、ノードで作成されるマシンに使用されるマシンタイプが含まれます。詳細については、Google Cloudのドキュメントを参照してください。

VDAマスターイメージの作成

シングルテナントノードにマシンを正常に展開するには、マスターVMイメージを作成する際に追加の手順が必要です。Google Cloud上のマシンインスタンスには、ノードアフィニティラベルと呼ばれるプロパティがあります。シングルテナントノードに展開されるカタログのマスターイメージとして使用されるインスタンスには、ターゲットノードグループの名前と一致するノードアフィニティラベルが必要です。これを実現するには、次の点に留意してください。

    -  新しいインスタンスの場合、インスタンスの作成時にGoogle Cloudコンソールでラベルを設定します。詳細については、[シングルテナントVMのプロビジョニング](https://cloud.google.com/compute/docs/nodes/provisioning-sole-tenant-vms#provision_a_sole-tenant_vm)を参照してください。
    -  既存のインスタンスの場合、**gcloud**コマンドラインを使用してラベルを設定します。詳細については、[ノードアフィニティラベルの構成](https://cloud.google.com/compute/docs/nodes/provisioning-sole-tenant-vms#configure_node_affinity_labels)を参照してください。

    -  > **注:**
    -  >
    -  > 共有VPCでシングルテナンシーを使用する場合は、[共有Virtual Private Cloud](/ja-jp/citrix-daas/install-configure/machine-catalogs-create/create-machine-catalog-gcp.html#shared-virtual-private-cloud)を参照してください。

マシンカタログの作成

注:

マシンカタログを作成する前に、リソースを作成してください。マシンカタログを構成する際は、Google Cloudによって確立された命名規則を使用してください。詳細については、バケットとオブジェクトの命名ガイドラインを参照してください。

マシンカタログは2つの方法で作成できます。

-  [Studio](#create-a-machine-catalog-using-studio)
-  PowerShell。[Remote PowerShell SDKを使用したCitrix DaaSの管理](https://developer-docs.citrix.com/en-us/citrix-daas-sdk)を参照してください。PowerShellを使用して特定の機能を実装する方法については、[PowerShellの使用](#use-powershell)を参照してください。

Studioを使用したマシンカタログの作成

マシンカタログの作成のガイダンスに従ってください。以下の説明は、Google Cloudカタログに固有のものです。

  1. Studioの左ペインで、[マシンカタログ]を選択します。
      1. アクションバーで[マシンカタログの作成]を選択します。
          1. [マシンタイプ]ページで、[マルチセッションOS]を選択し、[次へ]を選択します。Citrix DaaSはシングルセッションOSもサポートしています。
          1. [マシン管理]ページで、[電源管理されているマシン][Citrix Machine Creation Services™]オプションを選択し、[次へ]を選択します。複数のリソースがある場合は、メニューから1つを選択します。
          1. [イメージ]ページで、必要に応じてこれらの手順を完了し、[次へ]をクリックします。
          1. マスターイメージを選択します。次のイメージタイプを選択できます。
        • 仮想マシン(選択したホスティングユニットと同じリージョン)。
        • スナップショット(マルチリージョンスナップショットをサポート)。 - OSイメージ(マルチリージョンパブリックおよび非パブリックイメージをサポート)。
        • シングルテナンシー機能を使用する場合は、ノードグループプロパティが正しく構成されているイメージを選択してください。ゾーン選択の有効化を参照してください。
          1. [マシンプロファイルの選択]ページで、[仮想マシン]タブまたは[インスタンステンプレート]タブからリソースを選択します。
      • 注:

      •       -  現在、このカタログ内のVMは、選択したマシンプロファイルからストレージ、マシンタイプ、ディスク暗号化の設定を継承します。
        -  インスタンステンプレートをマシンプロファイルとして選択した場合、すべてのゾーンがデフォルトで選択されます。必要に応じてゾーンを選択できます。
        
    1. カタログの最小機能レベルを選択します。

        1. ストレージページで、このマシンカタログのオペレーティングシステムを格納するために使用するストレージの種類を選択します。以下の各ストレージオプションには、固有の価格とパフォーマンス特性があります。IDディスクは常にゾーン標準永続ディスクを使用して作成されます。
      • 標準永続ディスク
      • バランス永続ディスク - SSD永続ディスク

    Google Cloudのストレージオプションの詳細については、「ストレージオプション」を参照してください。

  2. 仮想マシンページで、作成するVMの数、VMの詳細な仕様、Google Cloudマシンタイプを指定し、次へを選択します。マシンカタログに単一テナントノードグループを使用する場合は、予約済みの単一テナントノードが利用可能なゾーンをのみ選択してください。「ゾーン選択の有効化」を参照してください。

    :

    Google Cloudマシンタイプは、選択したマシンプロファイルに基づいて自動的に選択されます。必要に応じて、別のマシンタイプを選択できます。

  3. ディスク設定ページで、次の設定を構成できます。

    • ライトバックキャッシュを有効にするかどうかを選択します。ライトバックキャッシュを有効にすると、次のことができます。

      • 一時データのキャッシュに使用されるディスクとRAMのサイズを構成します。詳細については、「一時データのキャッシュの構成」を参照してください。
      • ライトバックキャッシュディスクのストレージタイプを選択します。ライトバックキャッシュディスクに使用できるストレージオプションは次のとおりです。
        • 標準永続ディスク
        • バランス永続ディスク
        • SSD永続ディスク

        Google Cloudのストレージオプションの詳細については、「ストレージオプション」を参照してください。

      • ライトバックキャッシュディスクのタイプを選択します。
        • 非永続ライトバックキャッシュディスクを使用。選択した場合、ライトバックキャッシュディスクはプロビジョニングされたVMに永続しません。ディスクは電源サイクル中に削除され、ディスクにリダイレクトされたデータは失われます。
        • 永続ライトバックキャッシュディスクを使用。選択した場合、ライトバックキャッシュディスクはプロビジョニングされたVMに永続します。このオプションを有効にすると、ストレージコストが増加します。
    • MCSストレージ最適化(MCS I/O)が有効になっている場合、次のいずれかを実行できます。
      • 電源サイクル中にVDAのシステムディスクを保持するかどうかを選択します。詳細については、「MCSストレージ最適化の更新の有効化」を参照してください。
      • メモリとディスクキャッシュのサイズを更新します。
    • ディスクの内容を保護するために独自のキーを使用するかどうかを選択します。この機能を使用するには、まず独自の顧客管理暗号化キー(CMEK)を作成する必要があります。詳細については、「顧客管理暗号化キー(CMEK)の使用」を参照してください。

    • 注:

    • Studioインターフェイスでのみ利用可能です。

    • キーを作成した後、リストからいずれかのキーを選択できます。カタログを作成した後でキーを変更することはできません。Google Cloudは、既存の永続ディスクまたはイメージでのキーのローテーションをサポートしていません。したがって、カタログをプロビジョニングすると、カタログは特定のバージョンのキーに紐付けられます。そのキーが無効化または破棄された場合、それによって暗号化されたインスタンスとディスクは、キーが再度有効化または復元されるまで使用できなくなります。

    • 顧客管理暗号化キー(CMEK)の設定は、以下の優先順位に従います。

      • カタログのカスタマイズされたCMEKが最優先されます。
      • 選択したマシンプロファイルが暗号化されている場合、CMEK設定は自動的にマシンプロファイルのCMEKを次の優先順位として使用します。
      • 選択したマシンプロファイルが暗号化されていない場合、CMEK設定は自動的にマスターイメージのCMEKを使用します。
  4. マシンIDページで、Active Directoryアカウントを選択し、次へを選択します。

    • 新しいActive Directoryアカウントを作成を選択した場合、ドメインを選択し、Active Directoryで作成されるプロビジョニング済みVMコンピューターアカウントの命名スキームを表す文字のシーケンスを入力します。アカウント命名スキームは1~64文字で、空白、非ASCII文字、または特殊文字を含めることはできません。
    • 既存のActive Directoryアカウントを使用を選択した場合、参照を選択して、選択したマシンの既存のActive Directoryコンピューターアカウントに移動します。
  5. ドメイン資格情報ページで、資格情報の入力を選択し、ユーザー名とパスワードを入力して保存を選択し、次へを選択します。

    • 入力する資格情報には、Active Directoryアカウント操作を実行する権限が必要です。
  6. スコープページで、マシンカタログのスコープを選択し、次へを選択します。

    • 必要に応じて、オプションのスコープを選択するか、カスタムスコープを選択してスコープをカスタマイズできます。
  7. 概要ページで、情報を確認し、カタログの名前を指定して完了を選択します。

    注:

    • カタログ名は1~39文字で、空白のみ、または次の文字を含めることはできません。\ / ; : # . * ? = < > | [ ] { } " ' ( ) ' )

    • マシンカタログの作成には時間がかかる場合があります。完了すると、カタログが一覧表示されます。Google Cloudコンソールで、マシンがターゲットノードグループに作成されていることを確認できます。

手動で作成されたGoogle Cloudマシンのインポート

この機能を使用すると、次のことができます。

-  手動で作成されたGoogle CloudマルチセッションOSマシンをCitrix DaaSカタログにインポートします。
-  手動で作成されたGoogle CloudマルチセッションOSマシンをCitrix DaaSカタログから削除します。
-  既存のCitrix DaaS電源管理機能を使用して、Google Cloud WindowsマルチセッションOSマシンの電源を管理します。たとえば、それらのマシンの再起動スケジュールを設定します。

この機能は、既存のCitrix DaaSプロビジョニングワークフローの変更や、既存機能の削除を必要としません。

手動で作成したGoogle Cloudマシンをインポートする代わりに、StudioでMCSを使用してマシンをプロビジョニングすることをお勧めします。

共有仮想プライベートクラウド

共有仮想プライベートクラウド(VPC)は、共有サブネットが利用可能になるホストプロジェクトと、そのリソースを使用する1つ以上のサービスプロジェクトで構成されます。共有VPCは、共有企業Googleクラウド資産の一元的な制御、使用、管理を提供するため、大規模なインストールに適したオプションです。詳細については、Googleドキュメントサイトを参照してください。

この機能により、Machine Creation Services(MCS)は、共有VPCに展開されたマシンカタログのプロビジョニングと管理をサポートします。このサポートは、ローカルVPCで現在提供されているサポートと機能的に同等ですが、次の2つの点で異なります。

-  ホスト接続の作成に使用されるサービスアカウントに追加の権限を付与する必要があります。このプロセスにより、MCSは共有VPCリソースにアクセスして使用できます。[必要な新しい権限](#new-permissions-required)を参照してください。
-  イングレスとエグレス用にそれぞれ1つずつ、2つのファイアウォールルールを作成する必要があります。これらのファイアウォールルールは、イメージマスタリングプロセス中に使用されます。[ファイアウォールルール](#firewall-rules)を参照してください。

共有VPCの構成については、共有VPCの構成を参照してください。

必要な新しい権限

ホスト接続を作成する際には、特定の権限を持つGoogle Cloudサービスアカウントが必要です。これらの追加権限は、共有VPCベースのホスト接続の作成に使用されるすべてのサービスアカウントに付与する必要があります。

ヒント:

これらの追加権限は、Citrix DaaSにとって新しいものではありません。これらはローカルVPCの実装を容易にするために使用されます。共有VPCでは、これらの追加権限により、他の共有VPCリソースへのアクセスが可能になります。

共有VPCをサポートするために、ホスト接続に関連付けられたサービスアカウントに最大4つの追加権限を付与する必要があります。

-  **compute.firewalls.list** - この権限は必須です。MCSが共有VPCに存在するファイアウォールルールの一覧を取得できるようにします。
  • compute.networks.list - この権限は必須です。MCSがサービスアカウントで利用可能な共有VPCネットワークを識別できるようにします。
  • compute.subnetworks.list – この権限は、VPCの使用方法によってオプションです。MCSが可視の共有VPC内のサブネットを識別できるようにします。この権限はローカルVPCを使用する場合にすでに必要ですが、共有VPCホストプロジェクトにも割り当てる必要があります。
  • compute.subnetworks.use - この権限は、VPCの使用方法によってオプションです。プロビジョニングされたマシンカタログでサブネットリソースを使用するために必要です。この権限はローカルVPCを使用する場合にすでに必要ですが、共有VPCホストプロジェクトにも割り当てる必要があります。

これらの権限を使用する際には、マシンカタログの作成に使用される権限の種類に基づいて異なるアプローチがあることを考慮してください。

  • プロジェクトレベルの権限:
    • ホストプロジェクト内のすべての共有VPCへのアクセスを許可します。
    • 権限 compute.subnetworks.list および compute.subnetworks.use をサービスアカウントに割り当てる必要があります。
  • サブネットレベルの権限:
    • 共有VPC内の特定のサブネットへのアクセスを許可します。
    • 権限 compute.subnetworks.list および compute.subnetworks.use は、サブネットレベルの割り当てに固有のものであるため、サービスアカウントに直接割り当てる必要はありません。

    • 組織のニーズとセキュリティ標準に合ったアプローチを選択してください。

    • ヒント:

    • プロジェクトレベルとサブネットレベルの権限の違いの詳細については、サービスプロジェクト管理者を参照してください。

ファイアウォールルール

-  マシンカタログの準備中に、カタログのマスターイメージシステムディスクとして機能するマシンイメージが準備されます。このプロセスが発生すると、ディスクは一時的に仮想マシンに接続されます。このVMは、すべてのインバウンドおよびアウトバウンドネットワークトラフィックを防止する隔離された環境で実行する必要があります。これは、イングレスとエグレスのトラフィック用にそれぞれ1つずつ、一対のすべての拒否ファイアウォールルールによって実現されます。Google CloudローカルVPCを使用する場合、MCSはこのファイアウォールをローカルネットワークに作成し、マスタリング用のマシンに適用します。マスタリングが完了すると、ファイアウォールルールはイメージから削除されます。

共有VPCを使用するために必要な新しい権限の数を最小限に抑えることをお勧めします。共有VPCはより上位の企業リソースであり、通常、より厳格なセキュリティプロトコルが導入されています。このため、共有VPCリソース上のホストプロジェクトに、イングレス用とエグレス用にそれぞれ1つずつ、一対のファイアウォールルールを作成してください。それらに最高の優先順位を割り当てます。次の値を使用して、これらの各ルールに新しいターゲットタグを適用します。

citrix-provisioning-quarantine-firewall
<!--NeedCopy-->

MCSがマシンカタログを作成または更新する際、このターゲットタグを含むファイアウォールルールを検索します。次に、ルールの正確性を確認し、カタログのマスターイメージの準備に使用されるマシンに適用します。ファイアウォールルールが見つからない場合、またはルールが見つかってもルールやその優先順位が正しくない場合、次のようなメッセージが表示されます。

"Unable to find valid INGRESS and EGRESS quarantine firewall rules for VPC <name> in project <project>. " Please ensure you have created 'deny all' firewall rules with the network tag  ‘citrix-provisioning-quarantine-firewall' and proper  priority." "Refer to Citrix Documentation for details."
<!--NeedCopy-->

共有VPCの構成

Citrix DaaSのStudioで共有VPCをホスト接続として追加する前に、プロビジョニングするプロジェクトからサービスアカウントを追加するために、次の手順を完了してください。

  1. ファイアウォールルールの作成

IAMロールの作成

ロールのアクセスレベルを決定します。

  • プロジェクトレベルのアクセス、または
  • サブネットレベルのアクセスを使用する、より制限されたモデル

IAM ロールに対するプロジェクトレベルのアクセス。プロジェクトレベルの IAM ロールには、次の権限を含めます。

  • compute.firewalls.list
  • compute.networks.list
  • compute.subnetworks.list
  • compute.subnetworks.use

プロジェクトレベルの IAM ロールの作成:

  1. Google Cloud コンソールで、IAM と管理 > ロールに移動します。
  2. ロールページで、ロールを作成を選択します。
  3. ロールの作成ページで、ロール名を指定します。権限を追加を選択します。
    1. 権限の追加ページで、ロールに個別に権限を追加します。権限を追加するには、テーブルをフィルタリングフィールドに権限の名前を入力します。権限を選択し、追加を選択します。
    1. 作成を選択します。
  • サブネットレベルの IAM ロール。このロールでは、ロールを作成を選択した後、compute.subnetworks.list および compute.subnetworks.use の権限の追加を省略します。この IAM アクセスレベルの場合、compute.firewalls.list および compute.networks.list の権限を新しいロールに適用する必要があります。

  • サブネットレベルの IAM ロールの作成:

    1. Google Cloud コンソールで、VPC ネットワーク > 共有 VPCに移動します。共有 VPCページが表示され、ホストプロジェクトに含まれる共有 VPC ネットワークのサブネットが表示されます。
    1. 共有 VPCページで、アクセスするサブネットを選択します。
  1. 右上隅で、サービスアカウントを追加するためにメンバーを追加を選択します。
  2. メンバーの追加ページで、次の手順を完了します。
    1. 新しいメンバーフィールドに、サービスアカウントの名前を入力し、メニューでサービスアカウントを選択します。
    2. ロールを選択フィールドを選択し、Compute Network Userを選択します。
    3. 保存を選択します。
  3. Google Cloud コンソールで、IAM と管理 > ロールに移動します。
  4. ロールページで、ロールを作成を選択します。
  5. ロールの作成ページで、ロール名を指定します。権限を追加を選択します。
    1. 権限の追加ページで、ロールに個別に権限を追加します。権限を追加するには、テーブルをフィルタリングフィールドに権限の名前を入力します。権限を選択し、追加を選択します。
    2. 作成を選択します。

ホストプロジェクトの IAM ロールへのサービスアカウントの追加

IAM ロールを作成した後、ホストプロジェクトのサービスアカウントを追加するには、次の手順を実行します。

  1. Google Cloud コンソールで、ホストプロジェクトに移動し、IAM と管理 > IAMに移動します。
  2. IAMページで、サービスアカウントを追加するために追加を選択します。
  3. メンバーの追加ページで:
    1. 新しいメンバーフィールドに、サービスアカウントの名前を入力し、メニューでサービスアカウントを選択します。
    2. ロールフィールドを選択し、作成した IAM ロールを入力し、メニューでそのロールを選択します。
    3. 保存を選択します。

これで、サービスアカウントがホストプロジェクト用に構成されました。

共有 VPC への Cloud Build サービスアカウントの追加

すべての Google Cloud サブスクリプションには、プロジェクト ID 番号の後に cloudbuild.gserviceaccount が続く名前のサービスアカウントがあります。例: 705794712345@cloudbuild.gserviceaccount

プロジェクトのプロジェクト ID 番号は、Google Cloud コンソールでCloud の概要 > ダッシュボードに移動することで確認できます。プロジェクト ID とプロジェクト番号は、プロジェクトのダッシュボードのプロジェクト情報カードに表示されます。

Cloud Build サービスアカウントを共有 VPC に追加するには、次の手順を実行します。

  1. Google Cloud コンソールで、ホストプロジェクトに移動し、IAM と管理 > IAMに移動します。
  2. 権限ページで、アカウントを追加するために追加を選択します。
  3. メンバーの追加ページで、次の手順を完了します。
    1. 新しいメンバーフィールドに、Cloud Build サービスアカウントの名前を入力し、メニューでサービスアカウントを選択します。
    2. ロールを選択フィールドを選択し、Computer Network User と入力し、メニューでそのロールを選択します。
    3. 保存を選択します。

ファイアウォールルールの作成

マスタリングプロセスの一環として、MCS は選択されたマシンイメージをコピーし、それを使用してカタログ用のマスターイメージシステムディスクを準備します。マスタリング中、MCS はディスクを一時的な仮想マシンにアタッチし、その仮想マシンが準備スクリプトを実行します。この VM は、すべてのインバウンドおよびアウトバウンドネットワークトラフィックを禁止する隔離された環境で実行する必要があります。

隔離された環境を作成するために、MCS には 2 つの すべて拒否 ファイアウォールルール(イングレスルールとエグレスルール)が必要です。したがって、ホストプロジェクトに次の 2 つのファイアウォールルール(イングレスとエグレス)を作成します。

  1. Google Cloud コンソールで、ホストプロジェクトに移動し、VPC ネットワーク > ファイアウォールに移動します。
  2. ファイアウォールページで、ファイアウォールルールを作成を選択します。
  3. ファイアウォールルールの作成ページで、以下を完了します。
    • 名前。ルールの名前を入力します。
    • ネットワーク。イングレスファイアウォールルールが適用される共有 VPC ネットワークを選択します。
    • 優先度。値が小さいほど、ルールの優先度が高くなります。小さい値(例: 10)を推奨します。
    • トラフィックの方向イングレスを選択します。
    • 一致時のアクション拒否を選択します。
    • ターゲット。デフォルトの指定されたターゲットタグを使用します。
    • ターゲットタグcitrix-provisioning-quarantine-firewall と入力します。
    • ソースフィルタ。デフォルトのIP 範囲を使用します。
    • ソース IP 範囲。すべてのトラフィックに一致する範囲を入力します。0.0.0.0/0 と入力します。
    • プロトコルとポートすべて拒否を選択します。
  4. ルールを作成するために作成を選択します。
  5. 別のルールを作成するために手順を繰り返します。トラフィックの方向には、エグレスを選択します。

顧客管理の暗号化キー (CMEK) の使用

注:

GCP での CMEK のサポートは現在プレビュー中です。

MCS カタログには、顧客管理の暗号化キー (CMEK) を使用できます。この機能を使用する場合、Google Cloud Key Management Service の CryptoKey Encrypter/Decrypter ロールを Compute Engine サービスエージェントに割り当てます。Citrix DaaS アカウントは、キーが保存されているプロジェクトで適切な権限を持っている必要があります。Citrix DaaS アカウントへの権限の割り当てを参照してください。詳細については、Cloud KMS キーを使用したリソースの保護を参照してください。

Compute Engine サービスエージェントは、service-<Project _Number>@compute-system.iam.gserviceaccount.com の形式です。この形式は、デフォルトの Compute Engine サービスアカウントとは異なります。

注:

この Compute Engine サービスアカウントは、Google コンソールのIAM 権限表示に表示されない場合があります。そのような場合は、Cloud KMS キーを使用したリソースの保護で説明されている gcloud コマンドを使用してください。

Citrix DaaS アカウントへの権限の割り当て

Google Cloud KMS の権限は、さまざまな方法で構成できます。プロジェクトレベルの KMS 権限またはリソースレベルの KMS 権限のいずれかを提供できます。詳細については、権限とロールを参照してください。

プロジェクトレベルの KMS 権限

Citrix DaaSアカウントにプロジェクトレベルの権限を付与してCloud KMSリソースを参照できるようにするオプションが1つあります。これを行うには、カスタムロールを作成し、次の権限を追加します。

  • cloudkms.keyRings.list
  • cloudkms.keyRings.get
  • cloudkms.cryptokeys.list
  • cloudkms.cryptokeys.get

このカスタムロールをCitrix DaaSアカウントに割り当てます。これにより、インベントリ内の関連プロジェクトでリージョンキーを参照できます。

リソースレベルのKMS権限

もう1つのオプションであるリソースレベルの権限については、Google Cloudコンソールで、MCSプロビジョニングに使用するcryptoKeyを参照します。Citrix DaaSアカウントを、カタログプロビジョニングに使用するキーリングまたはキーに追加します。

ヒント:

このオプションでは、Citrix DaaSアカウントにCloud KMSリソースに対するプロジェクトレベルのリスト権限がないため、インベントリ内のプロジェクトのリージョンキーを参照できません。ただし、ProvSchemeカスタムプロパティで正しいcryptoKeyIdを指定することにより、CMEKを使用してカタログをプロビジョニングすることは可能です。「カスタムプロパティを使用したCMEKによるカタログの作成」を参照してください。

顧客管理キーのローテーション

  • Google Cloudは、既存の永続ディスクまたはイメージでのキーのローテーションをサポートしていません。マシンがプロビジョニングされると、作成時に使用されていたキーバージョンに紐付けられます。ただし、新しいバージョンのキーを作成でき、その新しいキーは、新しくプロビジョニングされたマシン、またはカタログが新しいマスターイメージで更新されたときに作成されるリソースに使用されます。

キーリングに関する重要な考慮事項

キーリングは名前変更または削除できません。また、構成時に予期せぬ料金が発生する可能性があります。キーリングを削除または削除すると、Google Cloudはエラーメッセージを表示します。

Sorry, you can't delete or rename keys or key rings. We were concerned about the security implications of allowing multiple keys or key versions over time to have the same resource name, so we decided to make names immutable. (And you can't delete them, because we wouldn't be able to do a true deletion--there would still have to be a tombstone tracking that this name had been used and couldn't be reused).
We're aware that this can make things untidy, but we have no immediate plans to change this.
If you want to avoid getting billed for a key or otherwise make it unavailable, you can do so by deleting all the key versions; neither keys nor key rings are billed for, just the active key versions within the keys.
<!--NeedCopy-->

ヒント:

詳細については、「コンソールからのキーリングの編集または削除」を参照してください。

均一なバケットレベルのアクセス互換性

Citrix DaaSは、Google Cloudの均一なバケットレベルのアクセス制御ポリシーと互換性があります。この機能は、ストレージバケットを含むリソースの操作を許可するためにサービスアカウントに権限を付与するIAMポリシーの使用を強化します。均一なバケットレベルのアクセス制御により、Citrix DaaSは、アクセス制御リスト(ACL)を使用して、ストレージバケットまたはそこに保存されているオブジェクトへのアクセスを制御できます。Google Cloudの均一なバケットレベルのアクセスの概要情報については、「均一なバケットレベルのアクセス」を参照してください。構成情報については、「均一なバケットレベルのアクセスを要求する」を参照してください。

PowerShellの使用

このセクションでは、PowerShellを使用して次のタスクを実行する方法について詳しく説明します。

永続的なライトバックキャッシュディスクを使用したカタログの作成

永続的なライトバックキャッシュディスクを使用してカタログを構成するには、PowerShellコマンドNew-ProvScheme CustomPropertiesを使用します。

ヒント:

PowerShellパラメーターNew-ProvScheme CustomPropertiesは、クラウドベースのホスティング接続にのみ使用してください。オンプレミスソリューション(XenServer®など)で永続的なライトバックキャッシュディスクを使用してマシンをプロビジョニングする場合、ディスクが自動的に永続化されるため、PowerShellは不要です。

このコマンドは、MCSプロビジョニングされたマシンに対してライトバックキャッシュディスクがどのように永続化されるかを決定するために使用される追加のプロパティPersistWBCをサポートしています。PersistWBCプロパティは、UseWriteBackCacheパラメーターが指定され、WriteBackCacheDiskSizeパラメーターがディスクが作成されることを示すように設定されている場合にのみ使用されます。

注:

この動作は、AzureとGCPの両方に適用されます。これらの環境では、デフォルトのMCSIOライトバックキャッシュディスクは、電源サイクル時に削除され、再作成されます。ディスクを永続化することを選択することで、MCSIOライトバックキャッシュディスクの削除と再作成を回避できます。

PersistWBCをサポートする前のCustomPropertiesパラメーターに見られるプロパティの例は次のとおりです。

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
</CustomProperties>
<!--NeedCopy-->

注:

この例はAzureにのみ適用されます。GCP環境ではプロパティが異なります。

これらのプロパティを使用する場合、プロパティがCustomPropertiesパラメーターから省略された場合、それらにはデフォルト値が含まれることに注意してください。PersistWBCプロパティには、true または false の2つの可能な値があります。

PersistWBCプロパティをtrueに設定すると、Citrix DaaS管理者が管理インターフェイスからマシンをシャットダウンしても、ライトバックキャッシュディスクは削除されません。

PersistWBCプロパティをfalseに設定すると、Citrix DaaS管理者が管理インターフェイスからマシンをシャットダウンしたときに、ライトバックキャッシュディスクが削除されます。

注:

PersistWBC プロパティが省略されている場合、このプロパティはデフォルトで false に設定され、管理インターフェースからマシンがシャットダウンされるとライトバックキャッシュは削除されます。

たとえば、CustomProperties パラメーターを使用して PersistWBC を true に設定する場合:


<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistWBC" Value="true" />
</CustomProperties>
<!--NeedCopy-->

重要:

PersistWBC プロパティは、New-ProvScheme PowerShell コマンドレットを使用してのみ設定できます。作成後にプロビジョニングスキームの CustomProperties を変更しようとしても、マシンカタログや、マシンがシャットダウンされたときのライトバックキャッシュディスクの永続性には影響しません。

たとえば、New-ProvScheme を使用してライトバックキャッシュを使用し、同時に PersistWBC プロパティを true に設定する場合:

New-ProvScheme
-CleanOnBoot
-CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistWBC`" Value=`"true`" /></CustomProperties>"
-HostingUnitName "adSubnetScale1"
-IdentityPoolName "BV-WBC1-CAT1"
-MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

MCSIOによる起動パフォーマンスの向上

MCSIOが有効になっている場合、AzureおよびGCPマネージドディスクの起動パフォーマンスを向上させることができます。この機能を構成するには、New-ProvScheme コマンドでPowerShell PersistOSDisk カスタムプロパティを使用します。New-ProvScheme に関連するオプションは次のとおりです。

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="Resource<!--NeedCopy-->
``````<!--NeedCopy-->
````````Groups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistOsDisk" Value="true" />
</CustomProperties>
<!--NeedCopy-->

この機能を有効にするには、PersistOSDisk カスタムプロパティを true に設定します。例:

New-ProvScheme
-CleanOnBoot
-  -CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistOsDisk`" Value=`"true`" /></CustomProperties>"
-  -HostingUnitName "adSubnetScale1"
-  -IdentityPoolName "BV-WBC1-CAT1"
-  -MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-  -NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

カスタムプロパティを使用したCMEKによるカタログの作成

PowerShell を使用してプロビジョニングスキームを作成する際、ProvScheme CustomPropertiesCryptoKeyId プロパティを指定します。例:

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="<yourCryptoKeyId>" />
</CustomProperties>'
<!--NeedCopy-->

cryptoKeyId は次の形式で指定する必要があります。

projectId:location:keyRingName:cryptoKeyName

たとえば、us-east1 リージョン内の my-example-key-ring キーリングで my-example-key キーを、ID my-example-project-1 のプロジェクトで使用したい場合、ProvScheme カスタム設定は次のようになります。

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:us-east1:my-example-key-ring:my-example-key" />
</CustomProperties>'
<!--NeedCopy-->

このプロビジョニングスキームに関連するすべてのMCSプロビジョニングディスクとイメージは、この顧客管理暗号化キーを使用します。

ヒント:

グローバルキーを使用する場合、顧客プロパティの場所は global と記述する必要があり、上記の例の us-east1 のような リージョン 名ではありません。例:<Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:global:my-example-key-ring:my-example-key" />

マシンプロファイルを使用したマシンカタログの作成

Machine Creation Services (MCS) を使用してマシンをプロビジョニングするカタログを作成する際、マシンプロファイルを使用して仮想マシンからハードウェアプロパティをキャプチャし、カタログ内の新しくプロビジョニングされたVMに適用できます。MachineProfile パラメーターが使用されていない場合、ハードウェアプロパティはマスターイメージVMまたはスナップショットからキャプチャされます。 たとえば、StorageTypeCatalogZonesCryptoKeyId など、明示的に定義する一部のプロパティは、マシンプロファイルから無視されます。

  • マシンプロファイルを使用してカタログを作成するには、New-ProvScheme コマンドを使用します。例:New-ProvScheme –MachineProfile “path to VM”MachineProfile パラメーターを指定しない場合、ハードウェアプロパティはマスターイメージVMからキャプチャされます。
  • 新しいマシンプロファイルでカタログを更新するには、Set-ProvScheme コマンドを使用します。例:Set-ProvScheme –MachineProfile “path to new VM”。このコマンドは、カタログ内の既存のVMのマシンプロファイルを変更しません。カタログに追加された新しく作成されたVMのみが新しいマシンプロファイルを持ちます。
  • マスターイメージを更新することもできますが、マスターイメージを更新してもハードウェアプロパティは更新されません。ハードウェアプロパティを更新したい場合は、Set-ProvScheme コマンドを使用してマシンプロファイルを更新する必要があります。これらの変更は、カタログ内の新しいマシンにのみ適用されます。既存のマシンのハードウェアプロパティを更新するには、-StartsNow および -DurationInMinutes -1 パラメーターを指定して Set-ProvVMUpdateTimeWindow コマンドを使用できます。

    注:

    • StartsNow は、スケジュールされた開始時刻が現在時刻であることを示します。
    • 負の数(例:–1)を指定した DurationInMinutes は、スケジュールの時間枠に上限がないことを示します。

インスタンステンプレートとしてのマシンプロファイルを使用したマシンカタログの作成

GCPインスタンステンプレートをマシンプロファイルの入力として選択できます。インスタンステンプレートはGCPの軽量リソースであるため、非常に費用対効果が高いです。

インスタンステンプレートとしてのマシンプロファイルを使用した新しいマシンカタログの作成

  1. PowerShellウィンドウを開きます。
  2. asnp citrix* を実行して、Citrix固有のPowerShellモジュールをロードします。
  3. 次のコマンドを使用して、GCPプロジェクトでインスタンステンプレートを見つけます。

    cd XDHyp:\HostingUnits\<HostingUnitName>\instanceTemplates.folder
    <!--NeedCopy-->
    
  4. NewProvSchemeコマンドを使用して、インスタンステンプレートとしてマシンプロファイルを持つ新しいマシンカタログを作成します。

    New-ProvScheme -ProvisioningSchemeName <CatalogName>  -HostingUnitName <HostingUnitName> -IdentityPoolName <identity pool name> -MasterImageVM
    XDHyp:\HostingUnits\<HostingUnitName>\Base.vm\Base.snapshot -MachineProfile XDHyp:\HostingUnits\<HostingUnitName>\instanceTemplates.folder\mytemplate.template
    <!--NeedCopy-->
    

    New-ProvSchemeコマンドの詳細については、https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/New-ProvScheme/を参照してください。

  5. PowerShellコマンドを使用してマシンカタログの作成を完了します。

マシンカタログを更新してインスタンステンプレートをマシンプロファイルとして設定

  1. PowerShellウィンドウを開きます。
  2. asnp citrix*を実行して、Citrix固有のPowerShellモジュールをロードします。
  3. 次のコマンドを実行します。

    Set-ProvScheme -ProvisioningSchemeName  <CatalogName> -MachineProfile XDHyp:\HostingUnits\<HostingUnitName>\instanceTemplates.folder\<TemplateName>.template
    <!--NeedCopy-->
    

    Set-ProvSchemeコマンドの詳細については、https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/Set-ProvScheme/を参照してください。

シールドされたVMでカタログを作成

シールドされたVMプロパティを持つMCSマシンカタログを作成できます。シールドされた仮想マシンは、セキュアブート、仮想トラステッドプラットフォームモジュール、UEFIファームウェア、整合性監視などの高度なプラットフォームセキュリティ機能を使用して、Compute Engineインスタンスの検証可能な整合性を提供する一連のセキュリティ制御によって強化されています。

MCSは、マシンプロファイルワークフローを使用したカタログ作成をサポートしています。マシンプロファイルワークフローを使用する場合、VMインスタンスのシールドされたVMプロパティを有効にする必要があります。その後、このVMインスタンスをマシンプロファイルの入力として使用できます。

シールドされたVMでMCSマシンカタログを作成

  1. Google CloudコンソールでVMインスタンスのシールドされたVMオプションを有効にします。クイックスタート: シールドされたVMオプションを有効にするを参照してください。
  2. VMインスタンスを使用して、マシンプロファイルワークフローでMCSマシンカタログを作成します。
    1. PowerShellウィンドウを開きます。
    2. asnp citrix*を実行して、Citrix固有のPowerShellモジュールをロードします。
    3. まだ作成されていない場合は、IDプールを作成します。
    4. New-ProvSchemeコマンドを実行します。例:

      ``` New-ProvScheme -ProvisioningSchemeName

  • -HostingUnitName gcp-hostint-unit
  • -MasterImageVM XDHyp:\HostingUnits\gcp-hostint-unit\catalog-vda.vm
  • -MachineProfile XDHyp:\HostingUnits\gcp-hostint-unit\catalog-machine.vm ```
  1. マシンカタログの作成を完了します。

新しいマシンプロファイルでマシンカタログを更新

  1. Set-ProvSchemeコマンドを実行します。例:

    -Set-ProvScheme -ProvisioningSchemeName <catalog-name>
    -MasterImageVM XDHyp:\HostingUnits\<hostin-unit>\catalog-vda.vm
    -MachineProfile "DHyp:\HostingUnits\<hostin-unit>\catalog-machine.vm

<!--NeedCopy-->
  • Set-ProvSchemeで行われた変更を既存のVMに適用するには、Set-ProvVMUpdateTimeWindowコマンドを実行します。
  1. Set-ProvVMUpdateTimeWindowコマンドを実行します。例:

    Set-ProvVMUpdateTimeWindow -ProvisioningSchemeName my-catalog -VMName <List-Of-Vm-Names> -StartsNow -DurationInMinutes -1
    <!--NeedCopy-->
    
  2. VMを再起動します。

単一テナントノードにWindows 11 VMを作成

GCPでWindows 11 VMを作成できます。ただし、マスターイメージにWindows 11をインストールする場合は、マスターイメージ作成プロセス中にvTPMを有効にする必要があります。また、マシンプロファイルソース(VMまたはインスタンステンプレート)でvTPMを有効にする必要があります。

単一テナントノードにWindows 11 VMを作成する主な手順は次のとおりです。

  1. Google Cloud仮想化環境をセットアップします。詳細については、Google Cloud環境を参照してください。
  2. VDAをインストールします。VDAのインストールを参照してください。
  3. Google Cloud環境への接続を作成します。詳細については、Google Cloud環境への接続を参照してください。
  4. Windows 11 BYOLマスターイメージを作成し、そのイメージをGoogle Cloudにインポートします。Windows 11 BYOLマスターイメージの作成を参照してください。
  5. マシンプロファイルソースを作成します。単一テナントノードにVMをプロビジョニングし、ソースマシンプロファイルのvTPMを有効にします。単一テナントノードへのVMのプロビジョニングを参照してください。
  6. vTPMが有効なWindows 11マシンプロファイルソースを使用してMCSマシンカタログを作成します。マシンプロファイルソースは、単一テナントノードで説明されているものと同じインスタンスタイプである必要があります。Windows 11マシンプロファイルソースを使用したMCSマシンカタログの作成を参照してください。

Windows 11 BYOLマスターイメージの作成

Windows 11 BYOLマスターイメージを作成し、そのマスターイメージをGoogle Cloudにインポートするには、2つのオプションがあります。

  • Google Cloud Cloud Build Toolsを使用
  • 他のハイパーバイザーでマスターイメージを作成

Google Cloud Cloud Build Toolsの使用

  1. Windows 11 ISO、GCP SDK、.NET Framework、およびPowerShellインストーラーファイルをGCPストレージバケットにアップロードします。
  2. Cloud Buildの.yamlファイルに、ファイルの場所をパラメーターとして指定します。
  3. コマンドラインから以下のCloud Buildを実行して、最終的なWindows 11イメージを構築します。GCPは、GCPのDaisyワークフローを使用して、選択したプロジェクトでマスターイメージをブートストラップして作成し、マスターイメージはGCPにインポートされます。

    gcloud compute instances import INSTANCE-NAME--source-uri=gs://BUCKET/IMAGE-OVF-FILE.ovf --guest-os-features=UEFI_COMPATIBLE --byol --machine-type=MACHINE-TYPE --zone=ZONE
    <!--NeedCopy-->
    

    注:

    すべての大文字のテキストを実際のリソース詳細に置き換えてください。

詳細については、「カスタムWindows BYOLイメージの作成」を参照してください。

他のハイパーバイザーでのマスターイメージの作成

  1. 他のハイパーバイザーを使用してWindows 11マスターイメージを作成します。
  2. マスターイメージをOVF形式でローカルマシンにエクスポートします。
  3. ローカルのgcloud CLIを使用して、OVFファイルをGCPストレージバケットにアップロードします。

    gsutil cp LOCAL_IMAGE_PATH_OVF_FILES gs://BUCKET_NAME/
    <!--NeedCopy-->
    
  4. コマンドラインから以下のCloud Buildを実行して、最終的なWindows 11イメージを構築します。GCPは、GCPのDaisyワークフローを使用して、選択したプロジェクトでマスターイメージをブートストラップして作成し、マスターイメージはGCPにインポートされます。

    gcloud compute instances import INSTANCE-NAME --source-uri=gs://BUCKET/IMAGE-OVF-FILE.ovf --guest-os-features=UEFI_COMPATIBLE --byol --machine-type=MACHINE-TYPE --zone=ZONE
    <!--NeedCopy-->
    

    注:

    すべての大文字のテキストを実際のリソース詳細に置き換えてください。

ソロテナントノードでのVMのプロビジョニング

ソロテナントノードを使用すると、VMを他のプロジェクトのVMから物理的に分離したり、VMを同じホストハードウェア上にグループ化したりできます。ソロテナントノードに関する情報については、GCPドキュメント「ソロテナンシーの概要」を参照してください。

ソロテナントノードでのVM(マシンプロファイルソース)のプロビジョニングについては、GCPドキュメント「ソロテナントノードでのVMのプロビジョニング」を参照してください。

注:

Windows 11マシンプロファイルソースを使用したMCSマシンカタログの作成

StudioまたはPowerShellコマンドを使用して、Windows 11 VMを作成するためのMCSマシンカタログを作成できます。

注:

  • マスターイメージには、Windows 11のスナップショットまたはVMを選択します。
  • マシンプロファイルソースには、Windows 11 VMをマシンプロファイルとして選択します。マシンプロファイルソースは、ソロテナントノードで説明されているものと同じインスタンスタイプである必要があります。

Studioの使用に関する情報については、「Studioを使用したマシンカタログの作成」を参照してください。

PowerShellコマンドに関する情報については、「マシンプロファイルを使用したマシンカタログの作成」を参照してください。

カタログを作成してVMの電源をオンにすると、Google Cloudコンソールでソロテナントノードで実行されているWindows 11 VMを確認できます。

継承されたラベルを持つVMとディスク

MCSマシンカタログのVMとディスク(IDディスク、ライトキャッシュバックディスク、OSディスク)は、マシンプロファイルソース(GCP VMインスタンスまたはインスタンステンプレート)のラベルを継承できます。ラベルを使用して、異なるチームが所有するインスタンス(例: team:researchおよびteam:analytics)を区別し、さらにコスト計算や予算編成に使用できます。ラベルに関する詳細については、GCPドキュメント「ラベルを使用したリソースの整理」を参照してください。

新しいカタログを作成したり、既存のカタログを更新したり、既存のVMを更新して、マシンプロファイルソースを使用してラベルを継承させることができます。

この機能は、永続および非永続MCSマシンカタログに適用できます。

以下を実行できます。

継承されたラベルを持つカタログの作成

VMとディスクがマシンプロファイルソースからラベルを継承するMCSマシンカタログを作成するには、次の手順を実行します。

  1. ラベル付きのマシンプロファイルソース(VMインスタンスまたはインスタンステンプレート)を作成します。ラベル付きVMの作成については、GCPドキュメントのラベル付きリソースの作成を参照してください。インスタンステンプレートはVMから作成され、VMで定義されたラベルを引き継ぎます。
  2. StudioまたはPowerShellコマンドを使用してMCSカタログを作成します。
  3. Studioを使用する場合は、[イメージ] ページで [マシンプロファイルを使用] を選択し、VMまたはテンプレートを選択します。
  4. PowerShellコマンドを使用する場合は、次の手順を実行します。

    1. PowerShellウィンドウを開きます。
    2. asnp citrix* を実行します。
    3. IDプールを作成します。IDプールは、作成されるVMのActive Directory (AD) アカウントのコンテナです。
    4. Active Directoryで必要なADコンピューターアカウントを作成します。
    5. New-ProvScheme コマンドを実行してカタログを作成します。例:

      テンプレートをマシンプロファイル入力として使用したNew-ProvScheme(永続カタログ):

      New-ProvScheme `
      -ProvisioningSchemeName "catalog-name" `
      -HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -MasterImageVM "XDHyp:\HostingUnits\hosting-unit-name\vm-name.vm" `
      -MachineProfile "XDHyp:\HostingUnits\hosting-unit-name\instanceTemplates.folder\instance-template-name.template" `
      <!--NeedCopy-->
      

      インスタンステンプレートをマシンプロファイル入力として使用したNew-ProvScheme(非永続カタログ):

      New-ProvScheme `
      -ProvisioningSchemeName "catalog-name" `
      -HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -MasterImageVM "XDHyp:\HostingUnits\hosting-unit-name\vm-name.vm" `
      -MachineProfile "XDHyp:\HostingUnits\hosting-unit-name\instanceTemplates.folder\instance-template-name.template" `
      -CleanOnBoot
      <!--NeedCopy-->
      

      VMインスタンスをマシンプロファイル入力として使用したNew-ProvScheme(永続カタログ):

      New-ProvScheme `
      -ProvisioningSchemeName "catalog-name" `
      -HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -MasterImageVM "XDHyp:\HostingUnits\hosting-unit-name\vm-name.vm" `
      -MachineProfile "XDHyp:\HostingUnits\hosting-unit-name\vm-name.vm" `
      <!--NeedCopy-->
      

      VMインスタンスをマシンプロファイル入力として使用したNew-ProvScheme(非永続カタログ):

      New-ProvScheme `
      -ProvisioningSchemeName "catalog-name" `
      -HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
      -MasterImageVM "XDHyp:\HostingUnits\hosting-unit-name\vm-name.vm" `
      -MachineProfile "XDHyp:\HostingUnits\hosting-unit-name\vm-name.vm" `
      -CleanOnBoot
      <!--NeedCopy-->
      
    6. プロビジョニングスキームをブローカーカタログとして登録します。
    7. カタログにVMを追加します。

継承されたラベルを持つ既存のカタログの更新

既存のカタログを新しいマシンプロファイルを持つように更新するには、Set-ProvScheme コマンドを実行します。このコマンドを実行すると、カタログに追加されたすべての新しいVMは、新しいマシンプロファイルソースのラベルを持つようになります。非永続カタログは次回の電源投入時に更新されます。

例:

インスタンステンプレートをマシンプロファイル入力として使用したSet-ProvScheme:

Set-ProvScheme `
-ProvisioningSchemeName "catalog-name" `
-MachineProfile "XDHyp:\HostingUnits\hosting-unit-name\instanceTemplates.folder\instance-template-name.template" `
<!--NeedCopy-->

VMインスタンスをマシンプロファイル入力として使用したSet-ProvScheme:

Set-ProvScheme `
-ProvisioningSchemeName "catalog-name" `
-MachineProfile "XDHyp:\HostingUnits\hosting-unit-name\vm-name.vm" `
<!--NeedCopy-->

継承されたラベルを持つ既存のVMの更新

更新されたマシンプロファイルソースで既存のVMを更新するには、次のコマンドを実行します。

  1. Set-ProvScheme
  2. Set-ProvVMUpdateTimeWindow。例:

    Set-ProvVMUpdateTimeWindow -ProvisioningSchemeName my-catalog -VMName <List-Of-Vm-Names> -StartsNow -DurationInMinutes -1
    <!--NeedCopy-->
    
  3. VMを再起動します。

VMおよびブートディスクのラベル情報の取得

VMの作成後、Get-Item コマンドを AdditionalData パラメーターとともに使用して、VMおよびブートディスクのラベル情報を取得できます。

VMの削除

VMラベルの情報を取得するには、次のコマンドを実行します。

(Get-Item XDHyp:\HostingUnits\hosting-unit-name\vm_name.vm).AdditionalData.Tags
<!--NeedCopy-->

ブートディスクラベルの情報を取得するには、次のコマンドを実行します。

(Get-Item XDHyp:\HostingUnits\hosting-unit-name\vm_name.vm\bootdisk-name.attacheddisk).AdditionalData.Tags
<!--NeedCopy-->

注:

さまざまなハイパーバイザー間で一貫性を保つため、GCPラベルを表示する際に「タグ」という用語を使用しています。

VMの削除

VMをカタログから削除し、GCPからVMを削除しない選択ができます。この場合、CitrixラベルのみがVMから削除されます。その他の追加されたラベルはVMから削除されません。StudioからVMを削除するか、PowerShellコマンドを使用できます。

Studioの使用

  1. VMを選択して右クリックします。
  2. [削除] をクリックします。
  3. [カタログから仮想マシンを削除しますが、仮想マシンは削除しません] を選択します。

PowerShellコマンドの使用

ForgetVMパラメーターを指定して Remove-ProvVM を実行します。詳細については、SDKドキュメントの Remove-ProvVM を参照してください。

Google Cloud Marketplace

Google Cloud MarketplaceでCitrixが提供するイメージを参照および選択して、マシンカタログを作成できます。現在、MCSはこの機能に対してマシンプロファイルワークフローのみをサポートしています。

Google Cloud MarketplaceでCitrix VDA VM製品を検索するには、https://console.cloud.google.com/marketplace/ にアクセスしてください。

カスタムイメージまたはGoogle Cloud Marketplace上のCitrix ready®イメージを使用して、マシンカタログのイメージを更新できます。

注:

マシンプロファイルにストレージタイプ情報が含まれていない場合、値はカスタムプロパティから派生します。

サポートされているGoogle Cloud Marketplaceイメージは次のとおりです。

  • Windows 2019 Single Session
  • Windows 2019 Multi Session
  • Ubuntu

Citrix readyイメージをマシンカタログ作成のソースとして使用する例:

New-ProvScheme -ProvisioningSchemeName GCPCatalog \
-HostingUnitName GcpHu -IdentityPoolName gcpPool -CleanOnBoot \
-MasterImageVM XDHyp:\HostingUnits\GcpHu\images.folder\citrix-daas-win2019-single-vda-v20220819.publicimage \
-MachineProfile XDHyp:\HostingUnits\GcpHu\Base.vm
<!--NeedCopy-->

次のステップ

詳細情報