リファレンスアーキテクチャ:App Layering

オーディエンス

このドキュメントは、技術専門家、IT 意思決定者、パートナー、システムインテグレータを対象としています。これにより、管理者はCitrix App Layeringを探索して採用し、エンドユーザーへのイメージとアプリケーションの配信を管理することができます。読者は、Citrix製品、イメージ管理サービス、およびアプリケーション仮想化の概念に関する基本的な知識を持っている必要があります。イメージ管理の詳細については、Citrix Tech Zoneのリファレンスアーキテクチャを参照してください。

このドキュメントの目的

このドキュメントでは、Citrix App Layeringテクノロジを使用してアプリケーションを管理および配信するための技術的な概要、アーキテクチャの概念について説明します。このドキュメントでは、App Layering 仕組みと、異なるプラットフォーム上のCitrix Virtual Apps and Desktops との統合の両方について説明します。

Citrix App Layering 概要

Citrix App Layeringは、永続的なサポート対象でないプラットフォーム上の多様なユーザーに対して、複雑なWindowsアプリケーションセットを提供するための柔軟なソリューションです。

Citrix App Layering は、独自の方法でイメージ管理を実行します。オペレーティングシステムとアプリケーションは、「Layers」と呼ばれる異なるコンテナに分割されます。レイヤーは個別に作成および更新され、「公開イメージ」にコンパイルされ、サポートされているプロビジョニングシステムを使用して配布されます。

アプリケーションのライブラリが作成されると、レイヤの任意の組み合わせを使用して、さまざまなイメージのセットが多くのプラットフォームにデプロイされます。

Citrix App Layering 主な目標は、単一のインターフェイスを使用してWindowsアプリケーション管理を簡素化することです。これにより、管理者は、基盤となるハイパーバイザーやクラウドインフラストラクチャに関係なく、エンタープライズアプリケーションを作成および管理できます。

OSとアプリケーションは、個別の管理可能なユニットに分割されています。アプリケーションアクセスを適切に制御するために多くのイメージが必要な場合でも、各オペレーティングシステムとそのアプリケーションは 1 つのインスタンスとして管理されます。この方法では、環境内のすべてのイメージに対して更新を実行する必要はありません。オペレーティングシステムとアプリケーション管理に伴う管理時間、複雑さ、コストを削減しながら、環境を簡素化します。

OS とアプリケーションは、特定のレイヤーのファイルとレジストリエントリを含む仮想ディスクとして格納されます。仮想マシン内にアプリケーションを含めるには、次の 2 つの方法があります。

• 公開イメージ： この方法では、OSレイヤー、プラットフォームレイヤー、および一連のアプリケーションレイヤーを組み合わせて、Citrix ProvisioningやCitrix Machine Creation Servicesなどのプロビジョニングシステム用のイメージを作成します。App Layering では、同じレイヤーセットから、複数のプロビジョニングシステムおよび複数のハイパーバイザーにイメージを公開できます。

Citrix イメージ管理の詳細については、 リファレンスアーキテクチャのドキュメントを参照してください 。

• Elastic Layers: AD グループのメンバーシップとアプリケーションの割り当てに基づいて、ログオン時に仮想マシンにアタッチされるアプリケーションレイヤーはほとんどありません。標準化されたイメージへのアプリケーションの動的な配信を可能にし、アプリケーションの割り当ての柔軟性を高めます。

アプリケーションとパーソナライゼーションをオペレーティングシステムから分離することで、永続的なイメージ管理に対する柔軟かつ管理が容易なソリューションとなります。

Citrix App Layering が選ばれる理由

Citrix App Layeringは、異なるパッケージ要件を持つ複数の環境にわたる複雑なアプリケーションセットを管理するための、コスト効率の高いソリューションを提供します。カーネルドライバ、OS、およびシステムサービスの依存関係に組み込まれているほぼすべてのアプリケーションは、App Layering テクノロジと互換性があります。

イメージ管理にCitrix App Layering アプローチを採用すると、多くの利点があります。

• PVSおよびMCSのマスターイメージ管理を簡素化： Citrix App Layeringは、Citrix Hypervisorとサードパーティ製ハイパーバイザーで使用されるプロビジョニングモデルの両方をサポートする単一のイメージ管理ソリューションです。App Layeringを使用すると、画像の管理とアップグレードの両方が簡素化され、画像の直接編集やリバースイメージングは不要です。

• Azureのサポート： Citrix App Layering はMicrosoft Azureをサポートしており、App Layering のお客様がAzureプラットフォームに簡単に移行できるようにします。

• アプリとプロビジョニングシステムをイメージから切り離します 。Citrix App Layeringは、パッケージとイメージを分離します。通常のイメージ管理では、イメージに対する更新は、イメージごとに個別に実行されます。App Layeringの使用は、多くの画像の一部にすることができます。すべての画像を更新するには、レイヤーが一度更新され、画像が再生成されます。ハイパーバイザーツール、仮想配信エージェント（VDA）、Citrix Provisioning ツールなどのコンポーネントへのアップグレードが簡単になります。

• 複雑なユースケースをサポート： Citrix App Layeringを使用すると、カーネルドライバー、システムサービス、サードパーティードライバー、コンソールアクセスを備えた複雑なアプリケーションすべてをサポートできます。そのため、App Layeringのアプリレイヤー展開用の 2 つのモードは、ほとんどすべてのアプリケーションが互換性があります。

• 非永続性デスクトップユーザーレイヤー: ユーザーレイヤーは書き込み可能な Elastic Layer です。ユーザーがデスクトップにログオンした書き込み操作は、ユーザーレイヤーに入ります。これにより、ユーザーはアプリケーションをインストールし、ユーザープロファイルの外部にある構成設定を保存できます。また、共有デスクトップモデルの利点を活かして、ユーザーのデスクトップが永続的に見えるようにすることで、ユーザーのデータファイルを保存します。

• 必要なイメージの数を減らす: Elastic Layering では、ログオン時に割り当てられたユーザーだけにアプリケーションを動的に配信することで、必要なイメージの数を大幅に削減できます。エラスティックレイヤーは、Citrix Virtual Desktopsの両方と互換性があります。

Citrix App Layering の使用例

App Layering は、上記の多くの利点を提供するCitrixテクノロジーポートフォリオの重要な追加です。それは利点を提供しますが、App Layering はすべてのユースケースのためにそれを使用することを意味するものではありません。このセクションでは、App Layering テクノロジの利点を示すために、最も関連性の高いユースケースをいくつか概説します。

1-管理する画像が多すぎます

多くのCitrixのお客様は、多数のアプリケーションと複雑なユーザー要件をサポートする必要があります。イメージベースのプロビジョニングテクノロジーを使用する場合、これらの要件を満たすには、多くの場合、多数のイメージを管理する必要があります。これらのイメージは、異なるユーザーグループまたは競合するアプリケーションの異なるセットをサポートする必要があります。多くの場合、各イメージにデプロイされたアプリケーションにも重複があります。

Citrix App Layeringにより、この複雑なシナリオの管理が簡素化されます。

App Layering を使用すると、管理者はレイヤーを使用して、オペレーティングシステムとアプリケーションを個々のエンティティとして管理できます。たとえば、Windowsにパッチを適用する必要があり、パッチはOSレイヤーに一度作成され、OSレイヤーを使用するすべてのイメージはApp Layering アプライアンスによって更新されます。10 個のイメージで Microsoft Office を使用している場合は、Office レイヤーにバージョンを追加することで、この Office をアップグレードする方が簡単です。最終的に、これら10個の画像はすべて自動的に更新されます。

Elastic Layering を追加すると、必要な画像の数を大幅に減らすことができます。Elastic Layer を使用すると、管理者はログオン時にアプリケーションを動的に配信できます。すべてのユーザーが使用していないアプリケーションの場合、Elastic Layers を使用すると、ユーザーごとにカスタマイズしながら、イメージをより一般的な方法で作成できます。

2-複数のハイパーバイザーと Azure のサポート

多くの組織では、オンプレミスとクラウドリソースを混在させたハイブリッドマルチクラウド環境に移行し、ユーザーエクスペリエンスを向上させています。Citrix App Layering は、ほとんどのハイパーバイザーとMicrosoft Azure をサポートすることで、必要な環境ごとに異なるプラットフォームレイヤーを作成するだけで、イメージの移植性を提供します。

通常、ハイパーバイザーとハイブリッドクラウドの混在構成では、管理者は複数の異なるイメージとアプリケーションのセットを複数の異なる管理プラットフォームで管理する必要があります。App Layering テクノロジを使用すると、オンプレミスで使用されているのと同じ OS とアプリケーションを、クラウドまたは別のハイパーバイザーにプッシュできます。

App Layering クロスプラットフォーム機能について理解するには、以下の「 Citrix App Layering クロスプラットフォームサポート 」セクションを参照してください。

3-移行のためのハイパーバイザの移植性

多くの場合、新しいテクノロジーへの移行には法外なコストがかかるため、ベンダーのテクノロジーに「立ち往生」することがあります。また、企業は、さまざまなテクノロジーを選択している他の組織と合併することがよくあります。App Layering 明確な利点の1つは、異なるプラットフォームレイヤーを作成し、インポートエクスポートを使用してApp Layering アプライアンスを新しいプラットフォームに移行するだけで、プラットフォーム間で移動できることです。

たとえば、vSphere から Citrix Hypervisor、オンプレミスのハイパーバイザーから Azure へのシームレスな移行を可能にします。

共有 VDI デスクトップの 4 永続性

多くの組織では、デスクトップ上で高いレベルの永続性を必要とする複数のユーザーがあります。任意のグループ、開発者、エンジニア、建築家などのパワーユーザーを含む。App Layering ユーザーレイヤーは、プールされたデスクトップアーキテクチャの上にかなりの量の永続性を提供します。

ユーザーレイヤーはログオン時にマウントされ、デスクトップへのその後の書き込みはすべてユーザーレイヤーに書き込まれます。ほとんどのアプリケーションはユーザーレイヤーにインストールできます。ユーザレイヤで機能するルールは、Elastic Layering の場合と同じです。アプリケーションがカーネルドライバー、サードパーティードライバー、およびブート中に他のサービスに依存するサービスをインストールしない限り、それらはユーザー Layer でほとんど動作する可能性があります。

永続性を必要とするユースケースでは、ユーザーレイヤーが最適です。Microsoft Outlook OST ファイルとインデックスファイルのみをサポートするユースケースでは、ユーザーレイヤーが最適な選択ではない場合があります。ユーザーレイヤーは、ユーザーがログオンした後、VDI デスクトップへのすべての書き込みを処理することを目的としています。Citrix Profile Management Outlookコンテナ、FSLogixプロファイルまたはOffice 365コンテナなどの他のテクノロジーでは、Outlook OST とインデックスが対象を絞った方法で処理されるため、コンテナによって処理されるI/Oの量がはるかに小さくなります。これらのソリューションはすべて、Outlook OST、Outlook ストリーミングファイル、および Outlook インデックスファイルの管理を処理するため、インデックス作成をサポートすることは、もう 1 つのテクノロジを他よりも選択する理由ではありません。

Citrix App Layering 技術概要

レイヤの種類

レイヤーは、パッケージング中に変更または追加されたファイルとレジストリエントリを含む仮想ディスクです。オペレーティングシステムレイヤーの最初のバージョンを除き、レイヤーはハイパーバイザーに統合されたApp Layering アプライアンスによって作成されます。管理者がレイヤーを作成すると、アプライアンスはブートディスクとレイヤーディスクを使用してパッケージングマシンを動的にプロビジョニングします。パッケージングマシンが起動すると、パッケージングマシン上のすべての変更がレイヤーディスクに書き込まれます。パッケージングが完了すると、このディスクがアプライアンスにコピーされ、すべてのファイルとレジストリの変更が新しいレイヤーに書き込まれ、VHD形式でレイヤーリポジトリに保存されます。

App Layering では、次の異なるタイプのレイヤが使用されます。

• オペレーティングシステムレイヤ
• プラットフォームレイヤー
• アプリケーションレイヤー
• 完全なユーザーレイヤー

OSレイヤー： Windows 10またはWindows Server 2019のようなオペレーティングシステム。ハイパーバイザーの「ゴールドイメージ」仮想マシンから構築

プラットフォーム層: プラットフォーム層には、特定のプラットフォームをサポートするために必要なソフトウェアが含まれています。ハイパーバイザーがデフォルトのハイパーバイザーと異なる場合は、ブローカーエージェント、プロビジョニングシステム、およびハイパーバイザーツールを含めます。プラットフォーム層はまた、最も優先度の高いレイヤーであり、時にはソフトウェアがここにインストールされ、最高の優先順位でコンパイルされます。

アプリレイヤー: メインレイヤーの種類。ほとんどのアプリケーションソフトウェアで使用されます。

ユーザーレイヤー: 弾力性 (次のセクションを参照) 書き込み可能なレイヤー。ユーザーレイヤーはログオン時にマウントされ、一度マウントされたデスクトップのほとんどすべての書き込みがユーザーレイヤーに適用されます。このレイヤーを使用すると、ユーザーは共有デスクトップモデルを使用している場合でも、VDI エクスペリエンスを大幅にカスタマイズできます。

Citrix App Layering アプライアンス

Citrix App Layering アプライアンス（アプライアンス）は、App Layering の管理インターフェイスと、すべてのApp Layering プロセスのエンジンの両方を提供します。

App Layering アプライアンスは、アプリケーションパッケージングとイメージの公開が行われるデータセンターに仮想マシンとしてデプロイされます。App Layering・アプライアンスはCentOS上に構築され、4つの仮想CPUと8 GBのRAMで構成されています。アプライアンスがその構成で動作するように設計されているため、これらの設定は変更されません。

アプライアンスは 2 つのディスクで構築されています。最初のディスクは、オペレーティングシステム用の 30 GB ブートディスクです。2 番目のディスクは 300 GB のレイヤーリポジトリです。このディスクは、より多くの領域が必要な場合は、必要に応じて拡張または拡張できます。

Citrix App Layering レイヤーアプライアンスは、レイヤーの作成とイメージ公開の処理中に、仮想ディスクファイルをVHD形式でアプライアンス内のレイヤーリポジトリに保存します。アプライアンスは SMB 共有とインターフェイスして、アプライアンスのアップグレードプロセスをサポートし、Elastic Layer を格納します。

アプライアンスは、レイヤー、イメージ、および Elastic Layer 割り当ての管理にのみ使用されます。仮想デスクトップと仮想アプリケーションサーバーは、アプライアンスと直接インターフェースしません。レイヤーが弾力的に割り当てられると、アプライアンスは Elastic Layer 共有に Layer をコピーします。共有には、これらの VHD ファイルと、ユーザーにレイヤー割り当てを提供する一連の JSON ファイルが含まれます。

Citrix App Layering アプライアンスでは、App Layering 管理コンソールもホストされます。App Layering アプライアンスのデプロイは、インストールプロセスの最初の手順です。アプライアンスのインストール後、管理コンソールにアクセスしてインストール手順を完了します。

Citrix App Layering アプライアンスのインストールについて詳しくは、 製品ドキュメントを参照してください。

Citrix App Layering 管理コンソールは、App Layering アプライアンスでホストされるWebベースのアプリケーションです。App Layering 管理コンソールには、次のためのインターフェイスが用意されています。

• オペレーティングシステム、プラットフォーム、アプリケーションレイヤーの作成と管理
• パブリッシュされたイメージテンプレートの作成
• レイヤードイメージのパブリッシュと管理
• 管理者ロールをユーザーに割り当てるApp Layering
• タスクとログの保持、セキュリティ設定、ネットワークファイル共有などのアプライアンスとシステム設定の管理

合成エンジン

バージョン 1910 以降の新機能には、合成エンジンと呼ばれる機能があります。合成エンジンは、App Layering Applianceでも実行できるパッケージングと公開タスクのほとんどをオフロードします。これらのタスクをオフロードすることで、パッケージングとパブリッシングプロセスの拡張性が大幅に向上します。また、使用されるテクノロジの利点により、プロセスのパフォーマンスも大幅に向上します。

コンポジットエンジンは、ハイパーバイザーコネクタによって Windows PE 仮想マシンとして構築され、一連の公開タスクを実行し、パッケージマシンまたは公開イメージで自身を再起動します。Compositing Engine は、キャッシュされたレイヤディスクの作成、パッケージマシンの作成、イメージの公開に使用されます。このリファレンスアーキテクチャの執筆時点では、それぞれバージョン 1910 と 1911 で導入された HyperV と vSphere の合成エンジンがあります。

合成エンジンには次の特徴があります。

• Windows PE を実行する軽量のエフェメラルアプライアンス
• 自己合成
• REST API 経由で制御
• ハイパーバイザディスク形式（VHD、VHDX、VMDK）
• UEFI サポート (Gen2)
• 公開イメージでのセキュアブート（Elastic Layering または User Layer が使用されていない場合のみ）
• iSCSI は、App Layering アプライアンス上でホストされているディスクを接続するために使用されます
• 同時パブリッシングジョブの数に制限はありません (実用的な制限があります)

合成エンジンの利点

合成エンジンの使用は選択肢です。HyperV コネクタと vSphere コネクタには、[オフロード合成] を有効にするチェックボックスがあります。この設定は、vSphere のマシン作成および VMware Horizon View コネクタでも使用できます。コンポジットエンジンの大きな利点は、ハイパーバイザーディスクに直接アクセスできる Windows デバイス上で実行されていることです。これにより、HyperV の GEN2 マシン、ネイティブの ESX VMDK 形式、vSphere のシンプロビジョニングと UEFI の両方をサポートするメカニズムが提供されます。パッケージングとパブリッシングのパフォーマンスが向上します。これは、大きなレイヤーファイルの処理量が少なく、コンポジットエンジンによってハイパーバイザー上のディスクに直接書き込まれるためです。コンポジットエンジンは、App Layering Applianceに接続してiSCSI接続を使用してレイヤーにアクセスします。

注：PVS公開はまだコンポジットエンジンを使用して実行できないため、VHDXファイルまたはGEN2仮想マシンをPVSに直接公開することはできません。

レイヤ配信

レイヤーは 2 つの方法で配信できます。公開イメージの一部として、App Layering アプライアンスがすべてのレイヤーを単一のディスクファイルに結合し、そのファイルをプロビジョニングシステムにアップロードするか、またはログオン時にレイヤーがマウントされ、ユーザーが動的に利用できるようにする、公開イメージの一部です。

公開イメージ： ここでは、OS、プラットフォーム、および一連のアプリケーションレイヤーが1つのディスクファイルに結合され、Citrix ProvisioningやMachine Creation Servicesなどのプロビジョニングシステムに公開されます。このプロセスは、OS層のクローンを作成し、次に優先順位の順にアプリケーション層からファイルに1つずつ書き込み、新しい層はその優先順位が高く、最後にプラットフォーム層に書き込むことから開始されます。パブリッシュイメージを作成するためのマージ処理は高度です。イメージが作成されると、ファイルシステム、レジストリ、および環境変数がマージされ、Windows ドライバストアが再作成されます。

エラスティックレイヤー: これらのレイヤーは、Active Directory グループメンバーシップによってユーザーに割り当てられ、ログオン中またはわずかに後にアタッチされるアプリケーションレイヤーです。Elastic Layer は動的であるため、管理者はイメージの数を最小限に抑えながらユーザーエクスペリエンスをカスタマイズできます。

コネクタとコネクタの構成

App Layering アプライアンスは、コネクタを使用してハイパーバイザーおよびプロビジョニングシステムと統合されます。

コネクタには、ハイパーバイザーとプロビジョニングの 2 種類があります。

• ハイパーバイザーコネクタは 、ハイパーバイザーとインターフェースするためのメカニズムを提供します。現在、Citrix Hypervisor、vSphere、Hyper-V、Nutanix AHV、Azure、Azure Gov用のハイパーバイザーコネクタがあります。

• プロビジョニングシステムコネクタを使用すると 、管理者はプロビジョニングシステムにイメージを公開できます。現在、Citrix Provisioning プロビジョニング用のプロビジョニングシステムコネクタ、各ハイパーバイザーおよびHorizon ViewにCitrixマシン作成サービスがあります。

複数のコネクタを定義することで、単一のアプライアンスが任意の数のハイパーバイザーまたはプロビジョニングシステムに接続できます。コネクタ構成は、ハイパーバイザーまたはプロビジョニングシステムとの統合に必要な設定を定義します。通常、構成には、認証用の資格情報、格納場所、仮想マシンテンプレート、および管理者がレイヤーを作成またはイメージを公開する環境とのインターフェースに必要なその他の情報が含まれます。管理者は、複数のコネクタ構成を作成できます。各コネクタ構成は、環境内の固有の場所にアクセスするように構成されます。コネクタは次の用途に使用されます。

• OS レイヤーの作成時のゴールドイメージのインポート
• レイヤーとレイヤーバージョンの作成
• レイヤー化されたイメージをハイパーバイザーまたはプロビジョニングサービスに公開します。コネクタ構成には、Provisioning Server、またはホストエージェントのあるシステムで実行し、公開イメージの後処理を実行するPowerShellスクリプトを含めることもできます。

参照: コネクタ構成

コネクタの種類

このセクションでは、Citrix App Layering で使用できるコネクタの種類を定義します。

ハイパーバイザコネクタ

ハイパーバイザーコネクタは、レイヤーを作成するとき、またはゴールドイメージをインポートしてOSレイヤーを作成するときに使用されます。ハイパーバイザーコネクタは、動的にパッケージングするときに、コネクタ構成によって定義されたストレージとホスト上にパッケージングマシンを作成します。ハイパーバイザー接続を使用して、ハイパーバイザーに仮想マシンを作成することもできます。

Citrix Provisioning

Citrix Provisioning コネクタは、Citrix Provisioning サーバー上のApp Layering Agentと統合して、仮想ディスクとしてプロビジョニングサーバーに直接イメージを公開します。Citrix Provisioning の前提条件は次のとおりです。

1. コネクタサービスアカウントは、PVS内の管理者権限を持つドメインアカウントである必要があります。
2. コネクタサービスアカウントは、Citrix Provisioningサーバーのローカル管理者である必要があります。
3. Citrix App Layering エージェントは、コネクタで定義されている各Citrix Provisioningサーバーにインストールする必要があります。コネクタごとに定義できるエージェントは 1 つだけです。

参照： Citrix Provisioning

Machine Creation Services

Citrix App Layering Applianceは、MCSのマスターイメージとして使用される仮想マシンとして、レイヤードイメージをハイパーバイザーに直接プロビジョニングおよび公開できます。コネクタを使用すると、レイヤイメージをハイパーバイザーに直接パブリッシュできます。MCS コネクタは、ハイパーバイザーコネクタとほぼ同じです。ただし、MCSコネクタは、MCSによって展開される前に、レイヤーに定義されたスクリプトをマスターイメージ上で実行できる公開仮想マシンを起動します。マスターイメージのシャットダウンと、このプロセスの一環として作成された仮想マシンのスナップショット。

コネクタスクリプト

この手順は、コネクタ構成の作成時に使用できるオプションの高度な機能です。この機能を使用するには、コネクタ構成で定義されているエージェントサーバーで実行するようにオプションの PowerShell スクリプトを構成します。この手順はCitrix Provisioningで最もよく使用されますが、WindowsシステムにApp Layering エージェントをインストールして、公開イメージに対してスクリプトを実行することにより、他の公開コネクタで使用できます。エージェントがインストールされているマシンにスクリプトをコピーします。このスクリプトは、レイヤードイメージを正常に展開した後に実行されます。この機能を使用するには、ハイパーバイザー上のマスターイメージを使用して、スクリプトはハイパーバイザーの管理プラットフォームとインターフェースする必要があります。たとえば、vSphere の場合、スクリプトで vCenter に対して PowerCLI を使用して、マスターイメージ仮想マシンに対してコードを実行する必要があります。

いくつかのプリセット変数は、異なるテンプレートイメージおよび異なるコネクタ構成でスクリプトを再利用できるようにするために使用できます。変数には、公開されたイメージの一部として仮想マシンを識別する情報も含まれています。

サンプルスクリプトの詳細については、次のサポート記事「 CTX226060 」および「 CTX226062」を参照してください。

パブリッシュされたイメージテンプレート

App Layering を使用する場合、OS、プラットフォーム、およびアプリケーションレイヤーはApp Layering アプライアンスによってマージされ、公開イメージが作成されます。イメージは公開され、ターゲットプロビジョニングシステムに必要な形式で作成されます。たとえば、管理者がCitrix Provisioningに公開する場合、アプライアンスはVHDを作成し、定義されたProvisioningサーバーに仮想ディスクとしてアップロードします。ソリューションがCitrix Hypervisorでマシン作成サービスを使用する場合、アプライアンスはVHDを作成し、Citrix Hypervisorにアップロードし、VHDを使用してマスターイメージ仮想マシンを作成します。

パブリッシュされたイメージの構成を定義するには、イメージテンプレートを使用します。イメージテンプレートは、イメージに含めるOS、プラットフォーム、およびアプリケーションレイヤーを定義します。また、イメージのパブリッシュに使用されるコネクタ、結果のイメージの大きさ（GB 単位）、画像で Elastic Layering が有効になっているか、または異なるタイプのユーザーレイヤーの 1 つかを定義します。イメージテンプレートは、イメージ設定のポイントインタイムスナップショットであり、バージョン管理をサポートしていません。ただし、同じイメージのわずかに異なるバージョンが必要な場合は、イメージテンプレートを複製して変更できます。

App Layering エージェント

Citrix App Layering エージェントは、App Layering アプライアンスと、Citrix Provisioningサーバー、Hyper-Vサーバー、またはスクリプトサーバーとして使用されるWindowsマシンの間の通信を提供します。App Layering エージェントを使用して、Citrix Hypervisor や vSphere などの他のハイパーバイザーへのイメージの公開に続くスクリプト作成を自動化することもできます。 Citrix ProvisioningおよびHyper-Vの場合、App LayeringコネクタはApp Layeringエージェントに接続し、アプライアンスがコンパイルしたVHDをエージェントのサーバーに転送するように要求します。この転送は、BITS を使用してエージェントから開始され、ファイルはアプライアンスからダウンロードされます。

Citrix App Layeringエージェントの詳細は、Citrixのドキュメントを参照してください。

参照: エージェントのインストール

Active Directory

App Layeringアプライアンスは Active Directory に接続して、アプライアンスへの認証と Elastic Layer の割り当ての両方を行います。管理者は、アプライアンスにログインすると、同じ資格情報を使用して Active Directory へのログオンを試みます。そのログオンが機能する場合、ユーザーはアプライアンスへのログインが許可されます。

ディレクトリサービスへのアクセスは、次の目的のために必要です。

• ロールベースのアクセス制御 (RBAC)
• エラスティックレイヤとユーザレイヤの割り当て

ディレクトリサービスとの最初のバインド中、App Layering アプライアンスは SSL 3.0 セキュアソケットレイヤ、および TLS 1.1 および 1.2 トランスポート層セキュリティと互換性があります。

ディレクトリジャンクションを作成するには、 製品ドキュメントを参照してください。

画層

次のセクションでは、各タイプのレイヤの使用方法について詳しく説明します。

OSレイヤー

OS レイヤーは、Windows オペレーティングシステムを含むレイヤーです。Windows Update で更新されるコンポーネントを OS レイヤーに含めることで、すべてが Windows Update によって更新されるようにするのが主要な方法です。このため、.NET や Visual C++ ランタイムライブラリなど、すべてのオペレーティングシステムの役割とコンポーネントは、オペレーティングシステムイメージの一部として含まれています。

特定の OS 層で作成されたすべてのアプリケーション層は、その OS 層に関連付けられるため、エンドユーザアプリケーションを OS 層にインストールしないことが望ましい。アプリケーションが OS 層にインストールされている場合、その層を使用するすべてのイメージがこのプロセスを含むようにするには、そのレイヤーを使用するすべてのイメージが OS 層を普遍化するという戦略では問題が発生します。オペレーティングシステムからアプリケーションを分離することは、管理するOSイメージの数を制限するための鍵です。ドライバ、サービス、カーネルデバイスを持つアプリケーションであっても、アプリケーション層でサポートされるため、OS レイヤーに含める必要はありません。

OSレイヤーの作成中に、覚えておくべきいくつかのポイントがあります：

• サポートされているオペレーティングシステムをリンクから確認してください
• OS レイヤーがドメインに接続されていません。ドメイン参加はプラットフォーム層の一部です
• プライマリハイパーバイザー用のハイパーバイザーツールは、OS レイヤーにインストールされます。ほとんどのパッケージングが実行されるハイパーバイザ
• 代替ハイパーバイザー用のハイパーバイザーツールは、そのハイパーバイザーのプラットフォームレイヤーにインストールされます。
• .NET コンポーネント (Microsoft から) をインストールし、OS レイヤーに更新する
• Microsoftランタイムが必要な場合は、OSレイヤーにインストールされます
• Windows Update で更新できるように、OS レイヤーにインストールされた RDS ロールなどの Windows ロールと機能
• ローカルユーザーまたはグループを仮想マシンに追加する必要がある場合、このタスクは OS レイヤーでのみ実行できます。これは、Windows セキュリティアカウントマネージャー (SAM) が OS レイヤーからキャプチャされたためです。

参考: OS レイヤーを作成する

プラットフォーム層

プラットフォームレイヤーは、特定のプラットフォームで公開イメージを実行するために必要な構成設定、ツール、およびその他のソフトウェアを含むレイヤーです。次の 2 つのプラットフォームレイヤタイプを作成できます。

Publishing Platform Layer: このタイプのプラットフォームレイヤーは、ターゲットプロビジョニングシステム、ブローカー、ハイパーバイザーに必要なソフトウェアを含めるために使用されます。たとえば、vSphere for Citrix Virtual AppsでProvisioning Servicesをサポートする公開プラットフォームレイヤーには、Citrix VDAとPVSデバイスドライバーがインストールされています。vSphere がパッケージングが実行されるハイパーバイザーと同じでない場合、このレイヤーには VMware Tools もインストールされます。

パッケージングプラットフォームレイヤー: パッケージングプラットフォームレイヤーは、パッケージングマシンをサポートするためにパッケージングレイヤーが必要な場合に使用されます。これらのレイヤーはしばしば必要ではありませんが、以下を含むいくつかのインスタンスが必要です。

1. レイヤーを標準とは異なるハイパーバイザーにパッケージ化する必要があるかどうか。たとえば、ほとんどのレイヤーが Hyper-V 上に作成され、何らかの理由で vSphere 内で作成された特定のレイヤーの場合、VMware Tools を使用したパッケージングプラットフォームレイヤーを使用して vSphere 上のパッケージングマシンがサポートされます。

2. VDAソフトウェアを使用してパッケージングマシンにアクセスする必要がある場合。この層は、デバイスを正しくインストールする必要があるUSB周辺機器用のドライバをインストールするときに最も必要になります。VDAソフトウェアがインストールされたパッケージングプラットフォームレイヤーを作成し、Studio で手動でプロビジョニングされたカタログにパッケージングマシンを追加することで、このタイプのアクセスをサポートできます。

プラットフォームレイヤーの作成

プラットフォームレイヤーを作成するために、いくつかの点を覚えておいてください。

• Citrix Provisioningの場合、イメージ作成ウィザードを実行せずにターゲットデバイスソフトウェアをインストールし、再起動します
• Citrix VDAおよびCitrix Provisioningデバイスドライバーのインストールはプラットフォームレイヤーで行う
• ドメイン参加はプラットフォームレイヤーで実行されます。つまり、複数のプラットフォームレイヤーを作成して、異なるドメインをサポートできます
• プラットフォームレイヤーは優先度の高いレイヤーでもあるため、ImprivataなどのSSOソフトウェア、代替ハイパーバイザー用のハイパーバイザーツール、Citrix Workspace Environment Managementエージェントなど、一部のオプションコンポーネントをインストールできます。

プラットフォームレイヤーの作成について詳しくは、 CTX225997の記事を参照してください。

アプリレイヤー

アプリレイヤーは、ほとんどのアプリケーションをパッケージ化するために使用されます。App Layer には、アプリケーションまたはアプリケーションのグループのファイルシステムおよびレジストリオブジェクトが含まれます。レイヤーを作成または編集すると、パッケージングマシンが動的に作成され、ファイルシステムとレジストリの変更がすべてそのマシンでキャプチャされます。パッケージマシンには、OS レイヤーと含まれている前提条件のアプリケーションレイヤーが含まれています。パッケージディスクと呼ばれる 2 番目の仮想ディスクが、書き込み可能なボリュームとしてパッケージマシンに接続されます。このディスクは、パッケージング中にファイルシステムのすべての変更をキャプチャし、すべてのレジストリの変更をキャプチャするために使用されるレジストリハイブ (RSD ハイブと呼ばれる) も含まれています。パッケージングマシンがファイナライズされると、パッケージディスクのみがダウンロードされます。ブートディスクが削除されます。

アプリレイヤーの作成と編集の詳細については、 製品ドキュメントを参照してください。

ほとんどの時間は、管理者が通常サポートしているプロビジョニングシステムに使用するのと同じ構成でアプリケーションがインストールされます。アプリレイヤーを作成するときは、自動更新を無効にするように作業することが常に重要です。管理者は、通常、展開後にアプリケーションを自動的に更新したくないためです。Citrixでは、いくつかの一般的なアプリケーションの階層化プロセスを文書化しました。これらのApp Layering の「レシピ」は、次のリンクで見つけることができます。

参考: App Layering レシピ

Elastic Layering

Elastic Layeringは、ユーザーログオン時にアプリケーションを仮想セッションに動的に展開する方法で、VHDファイルとして保存されたレイヤーをSMB共有にマウントし、Citrixコンポジットファイルシステム（CFS）を使用してファイルシステムに統合します。Elastic Layeringは、Citrix LayeringサービスによってVDA上で管理されます。Elastic Layer リポジトリは、レイヤサービスのレイヤ割り当てを定義するために使用されるレイヤ VHD ファイルと JSON 設定ファイルの両方を含む SMB 共有です。レイヤーサービスは、構成ファイルを読み取り、Windows SDK 呼び出しを使用してレイヤーVHD ファイルをマウントします。

Elastic Layer はログオン時にマウントされるため、すべてのアプリケーションが Elastic Layering テクノロジでサポートされていません。次のアプリケーション要件では、Elastic Layers 内でのアプリケーションの使用が除外されます。

1. カーネルドライバを使用するアプリケーション
2. 他のブートタイムサービスの依存関係であるサービスを持つアプリケーション
3. サードパーティ製のプリンタードライバーのように Windows ドライバストアを変更するアプリケーション

これらの要件を持つアプリケーションはレイヤー化できますが、レイヤーをパブリッシュイメージに含める必要があります。

設定ファイル (JSON)

前述のように、Elastic Layer の割り当ては、Elastic Layer リポジトリ上の.JSON ファイルストアのセットで定義されます。これらのファイルは次のように定義されます。

• ElasticLayerAssignment.json: このファイルには、アプリケーションレイヤーへのユーザーとグループのマッピングに関する情報が含まれています。このファイルには、アプリケーションが割り当てられている各グループまたはユーザー ID のエントリが含まれ、その AD オブジェクトの SID の下にレイヤ割り当てが一覧表示されます。

• Layers.json: このファイルは、リポジトリ内のレイヤーとレイヤーに関するメタデータを定義します。このファイルは、VHDのマウントに使用するパスを取得するために使用されます。

• MachineasSociations.json: 名前が示すように、マシンと任意の AD グループとの関連付けが定義されているように、このフォーマットでは、ワイルドカードを含むマシン名のパターンを使用して、一連のコンピュータを定義された AD グループに関連付けます。パターンに一致するマシンにユーザーがログオンすると、そのグループに割り当てられた Elastic Layers を受け取ります。これらの設定は、App Layering 管理コンソールの [ ユーザー] > [グループ] セクションで定義します。

ユーザーレイヤー

ユーザーレイヤーは、共有デスクトップコンピューティングモデルをサポートしながら、より永続的なエクスペリエンスをユーザーに提供します。その後、ユーザーレイヤーがマウントされると、ほとんどのシステム書き込みはユーザーレイヤーにリダイレクトされます。このレイヤーでは、次のサポートが可能です。

• 各ユーザーのプロファイルとデータ設定は、ユーザーレイヤーに格納されます
• ユーザーがインストールしたアプリケーションは、Elastic Layer で許可されているルールに準拠している限り、User Layer でサポートされます。

ユーザーレイヤーは、1 つに 1 つ割り当てられます。1 人のユーザーは、ドメインごとに OS レイヤーごとに 1 つのユーザー書き込み可能レイヤーのみを持つことができます。したがって、ユーザーは、ユーザーレイヤーを有効にした同じOSレイヤーとプラットフォームレイヤーの組み合わせを使用して、デスクトップを持つ1つのデリバリーグループまたはプールにのみログオンできます。このレイヤーは、ユーザーが初めてログオンしたときに、ファイル共有上に仮想ディスクとして作成されます。

バージョン 1910 では、フルユーザレイヤはセッション間の検索インデックスの永続性をサポートしています。これをサポートするために、VDAの起動時にWindows検索サービスは無効（4）に設定されます。ユーザーが Ulayer サービスにログオンすると、Windows 検索サービスの開始の種類を START_ON_DEMAND (3) に変更します。WSearch を有効にする前に、ULAyer サービスは、インデクサーの「クロールスコープ」レジストリ設定が正しいことを確認する必要があります。クロールスコープは、インデックス化されるユーザーのデータの領域を決定するレジストリキーのセットです。クロールスコープへの入力は、ベースイメージに組み込まれたデフォルトから取得されますが、エラスティックレイヤーとユーザーの永続レイヤー設定からも入力できます。これらの入力は、クロールスコープの場所の完全なセットを提供するためにログオン時に処理され、ログオンごとにこれを構築するには、控えめではあるが測定可能なオーバーヘッドがあります。このオーバーヘッドを回避するために、ULayer サービスは、ベースイメージの展開（BIC インスタンスなど）と Elastic Layer 割り当てを表すハッシュ文字列を生成し、この文字列をユーザーの\ プログラムファイル\ Unidesk\ Etc\ UserLayer.json ファイルに「indexerHash」として格納します。後続のログオン時に、この文字列は再計算された IndexerHash と比較され、クロールスコープが再構築される場合にのみ、異なる場合のみです。

次のタイプのユーザーレイヤーを使用できます。

• フル: ユーザーのデータ、設定、ローカルにインストールされたアプリはすべて、そのユーザーレイヤーに格納されます
• Office 365: ユーザーの Outlook データと設定のみがユーザーレイヤーに保存されます。検索インデックスは、ログオンごとに再作成されます。
• セッション Office 365: ユーザーの Outlook データと設定のみがユーザーレイヤーに保存されます。検索インデックスは、ログオンごとに再作成されます。

注：Office 365レイヤーを使用する場合は、Citrix Profile Managementを使用してOutlookの設定を維持することをお勧めします。

ユーザーレイヤーのデフォルトの最大サイズは 10 GB です。このサイズは、ユーザー層共有のクォータを定義することによって変更できます。また、VDAのレジストリエントリを使用して、デフォルトのユーザーレイヤーの最大サイズを上書きすることもできます。既定の最大サイズを変更するには、次のレジストリオーバーライドを追加します。

HKLM\Software\Unidesk\ULayer\

DWORD: DefaultUserLayerSizeInGb

VALUE: <Size in GB>

エラスティックレイヤー共有とユーザーレイヤー共有

Elastic Layers は、クライアントまたはサーバーのオペレーティングシステムが VM ネットワーク経由でマウントする VHD ファイルです。Elastic Layers は読み取り専用としてマウントされ、多くのマシンではまったく同じ VHD ファイルをマウントできます。Elastic Layers に使用されるファイルサーバーまたは共有は、読み取り I/O 用に最適化されています。

ユーザーレイヤーは、書き込み可能な Elastic レイヤーです。ユーザーレイヤーは、単一のデスクトップによってのみ読み取り/書き込みでマウントされます。ユーザーレイヤーに使用されるファイルサーバーまたは共有は、書込みI/O用に最適化されています。ユーザーレイヤーを使用する場合、記憶域のパフォーマンスはユーザーエクスペリエンスに重要です。ユーザー層共有には、フラッシュストレージアレイを使用することを強くお勧めします。

Elastic Layer のアーキテクチャは、大きく拡張可能です。Elastic Layer 共有リポジトリパスは、VDI および RDS ワークロードの両方について、VM HKLM レジストリで定義されます。この設計により、負荷を分散するためのレプリカの数に制限はありません。

Elastic Layer リポジトリとユーザー層共有は、アプライアンスで定義されます。Elastic Layer 共有は、[ システム] > [設定と構成 ] セクションで定義します。このパスは、グループポリシーを使用して、次のレジストリ値を変更することにより、VDA上で変更できます。

HKLM\SOFTWARE\Unidesk\ULayer\RepositoryPath

Value = \\Server\Share

大規模な VDI 実装の場合、このレジストリ値により、異なるデスクトップセットに複数の Elastic Layer リポジトリを使用できます。イメージを再作成せずにレジストリ内のElastic Layerリポジトリを変更する方法の詳細については、Citrixの記事CTX222107を参照してください。

ユーザーレイヤーに使用される場所は Active Directory グループによって割り当てられます。したがって、必要な数の共有を使用できるため、スケーラビリティも高いです。これらの割り当ては、[ システム] > [ストレージの場所] で定義します。

Elastic Layers 共有のアーキテクチャの詳細については、「 可用性、バックアップ、およびリカバリ」セクションを参照してください。

ユーザー層ファイル共有

イメージがユーザーレイヤー用に構成されているときのログインプロセスでは、ユーザーがイメージに割り当てた後に初めてログオンしたときに、ユーザーレイヤー VHD ファイルが作成されます。ユーザー層共有設定は、Active Directory グループによってアプライアンスで定義されます。ユーザーレイヤー共有が割り当てられている複数のグループに属している場合、その共有とそのユーザーレイヤーファイルの優先順位は、最も優先度の高い共有に作成されます。ユーザー層ディスクは、一度に 1 台のマシンでのみ使用できます。

ユーザーレイヤーは、ログインしているデスクトップのドメインとOSレイヤーの両方に結び付けられます。特定のユーザーレイヤーへのパスは次のとおりです。

\\Server\Share\Users\Domain_Username\OSLayerID_OSLayerName

ユーザーレイヤーは書き込みを大量に消費します。書き込み用に最適化されたファイル共有を使用することをお勧めします。ユーザーレイヤー共有が Elastic Layer 共有と異なる場合は、AD ユーザーグループによって定義されたユーザー割り当てです。

ユーザーレイヤーの割り当ては、App Layering コンソールの [ システム] > [ストレージの場所 ] セクションで定義します。共有と共有に関連付けられたグループを入力します。

Elastic Layers 共有のアーキテクチャの詳細については、「 可用性、バックアップ、およびリカバリ」セクションを参照してください。

App Layering 統合

以下のセクションでは、Citrix App Layering とプロビジョニングシステムおよびハイパーバイザーとの統合について説明します。

Citrix App Layering と Citrix Provisioning サービス

App Layering は、Citrix Provisioning（PVS）と簡単に統合できます。統合は、1つまたは複数のPVSサーバーにApp Layering エージェントをインストールすることで容易になります。エージェントは、アプライアンスとProvisioning Services間の接続を提供します。

前の図は、Citrix Provisioningを使用したレイヤーイメージの公開を示しています。イメージは、App Layering アプライアンスからCitrix Provisioningサーバーに公開することにより、展開用に一元的に管理および配布されます。Citrix Provisioningをサポートするために作成できるアーキテクチャはいくつかあります。最もよく使用されるアーキテクチャは、統合ポイントとして使用される単一の本番PVSサーバーを統合することです。その後、イメージが公開されると、仮想ディスクはApp Layering AgentによってPVSサーバーストアにダウンロードされます。エージェントは、Windows BITS サービスを使用して転送を実行します。

イメージが公開されると、イメージのアップロード後にイメージに対して実行するように Connector PowerShell スクリプトを構成できます。この機能を使用する際、スクリプトがプロセッサを大量に消費する場合は、ストリーミングの実行に使用しない「事前ステージング」Provisioning Serverを使用することをお勧めします。これにより、公開とスクリプトの処理が、Provisioning Servicesファームのストリーミング機能に悪影響を及ぼすことはありません。この設計をサポートするには、単一のサーバーで「DEV」Citrix Provisioningファームを作成する最も簡単な方法です。この「DEV」サーバーは、テストイメージのストリーミングにも使用できます。イメージのテストが完了すると、仮想ディスクを本番Citrix Provisioningファームにレプリケートして、さらなるテストと展開を行うことができます。

このタイプのスクリプトについて詳しくは、Citrix サポート記事「 CTX226060」の次のサンプルスクリプトを参照してください。

Citrix Provisioningにイメージが公開されると、イメージテンプレート名に従って、バージョン管理用の日付とタイムスタンプが付いたイメージの名前が付けられます。仮想ディスクは、App Layeringなしで管理する場合と同じ方法でProvisioning Servicesで管理されます。App Layering が使用されている場合、バージョン管理は使用されません。代わりに、新しいイメージが公開されるたびに、新しい日付とタイムスタンプを使用してフル仮想ディスクが作成されます。イメージを緊急に変更する必要がある場合は、Citrix Provisioningのバージョン管理を使用してイメージをすばやく変更できます。その後、問題が迅速に修正された後、同じ変更を適切なレイヤーに追加できます。

エラスティックレイヤリングのCitrix Provisioningキャッシュディスクへの影響

Citrix Provisioningは、予約済みメモリとローカルに接続されたキャッシュディスクを使用して、セッション中にローカルファイルシステムの変更を一時的に保存します。App Layering とCitrix Provisioningを使用するときは、キャッシュディスクのサイズはApp Layering を使用しない場合よりも大きくする必要があります。ファイルが開かれるたびに、App Layeringを使用した書き込み操作のために、ファイル全体が仮想マシンの書き込み可能なボリュームにコピーされ、編集できるようになります。Citrix Provisioningは通常、変更されたブロックのみをキャッシュにコピーするときに、ファイル全体をディスクキャッシュにコピーします。

上の図は、Provisioning ServerターゲットにApp Layeringフィルタードライバーがインストールされている場合と使用しないキャッシュディスクへの書き込みを示しています。Elastic Layersを使用したキャッシュの詳細については、 CTX227454の記事を参照してください。

ユーザー層とCitrix Provisioning キャッシュディスク

ユーザーレイヤーが使用されている場合、ユーザーがログオンする前に、プロビジョニングキャッシュディスクのみが使用されます。

この場合、ローカルの書き込み可能なパーティションディスクはブートアップ時にのみ使用されます。ユーザーがログインすると、すべての新しいファイル変更は、ストリーム配信される仮想ディスクではなく、ファイル共有のユーザーレイヤーディスクにリダイレクトされます。つまり、Provisioningキャッシュは書き込み可能なパーティション上のI/Oを認識しなくなります。

Citrix App Layering およびマシン作成サービス

レイヤー化されたイメージをマシン作成サービスに公開するには、公開先のハイパーバイザー用に作成されたマシン作成サービスコネクタを作成します。Connector構成には、ホスト、ストレージの場所、テンプレートなどに加えて、ハイパーバイザーへのアクセスに使用されるサービスアカウントの認証情報が含まれます。

このコネクタは、仮想マシンの「マスターイメージ」としてハイパーバイザーにレイヤーイメージを公開するために使用されます。

MCSコネクタは、公開後にマスタイメージを起動し、任意のレイヤで定義されているレイヤースクリプトを実行します。すべてのスクリプトを実行したら、マスターイメージをシャットダウンし、ハイパーバイザーが仮想マシンのスナップショットを作成します。このプロセスが完了すると、Machine Creation Services を使用してマスターイメージを展開できます。仮想マシンの名前は、Citrix Provisioningに似ています。仮想マシンは、公開イメージテンプレート名として名前が付けられ、その後に日付と時刻のスタンプが付けられます。イメージの新しいバージョンが公開されると、そのイメージは新しい仮想マシンになります。その後、新しい仮想マシンを使用して既存のカタログを更新し、変更をロールアウトします。MCSを使用する場合は、マスターイメージの作成に使用するテンプレートが実際の仮想マシンから作成されている必要があります。マシンは Windows で起動され、適切なタイムゾーンが設定されています。この作業により、仮想 BIOS が正しく設定されていることが保証されます。このタスクが実行されない場合、結果として起動されたイメージには、UTC に基づいて時間オフ時間がかかります。テンプレートを作成する最良の方法は、OS レイヤーの作成に使用した元のゴールドイメージのクローンを使用することです。この手順により、仮想ハードウェアの設定が OS レイヤーからマスターイメージまで一致します。

Citrix App Layering クロスプラットフォームサポート

Citrix App Layering アーキテクチャは、1つのプラットフォームに固有のレイヤーを作成することなく、多くのハイパーバイザーとプロビジョニングシステムをサポートするように設計されています。多くの組織がマルチクラウドまたはハイブリッドクラウド環境に移行するにつれて、Citrix App Layeringはこの移行を容易にします。

App Layering は、コネクタとプラットフォームレイヤーの組み合わせにより、複数のハイパーバイザー上の複数のプラットフォームをサポートします。

App Layering コネクタ- App Layering コネクタは node.js で開発され、App Layering アプライアンスから実行されます。コネクタは、ハイパーバイザーとプロビジョニングシステムの両方を含む、サポートされているすべてのプラットフォームに統合されます。

プラットフォームレイヤー — このレイヤーはアプリケーションレイヤーに似ていますが、常に優先順位が最も高く、イメージのクリーンアップの「レシピ」がアプリケーションレイヤーとは異なるプラットフォームレイヤーに対して実行されます。プラットフォームレイヤーは、定義された「プラットフォーム」用にソフトウェアドライバがインストールされる場所です。たとえば、Citrix Provisioningを使用すると、VDAソフトウェアとPVSソフトウェアの両方がプラットフォームレイヤーにインストールされます。

App Layering コネクタとプラットフォームレイヤーは、利用可能なプラットフォームをサポートするために結合されています。複数のハイパーバイザーとクラウドプラットフォームの展開の詳細と構成の詳細については、 製品ドキュメントを参照してください。

App Layering 通信フロー

App Layering では、接続とポートはほとんど使用されません。これらの通信フローは、次に説明されています。通信の詳細については、 要件は製品ドキュメントを参照してください。

App Layering アプライアンス

App Layering 管理コンソールは、ポート 80 (HTTP) または 443 (HTTPS) で TCP/IP 経由でアクセスする Microsoft Silverlight ベースのコンソールです。

管理アプライアンスのアクセス

プロトコル	ポート
HTTP	80
HTTPS	443
SSH	22
ログのダウンロード	8888

HTTP と HTTPS に加えて、管理者はポート 22 で SSH を使用してApp Layering アプライアンス仮想マシンに直接アクセスできます。セキュリティで保護されていない Telnet ポートまたは FTP ポートでは、アクセスは許可されません。SSH は、フルアクセス用の「root」としてアプライアンスにログオンし、「管理者」アカウントを使用して限定メニューにアクセスしてネットワーク設定を構成します。Azure では、「ルート」と「管理者」の両方が無効になっています。代わりに、アプライアンスのプロビジョニング中に、ローカル管理ユーザー・アカウントの管理者プロンプトが表示されます。

管理コンソールからログをエクスポートすると、ダウンロードリンクが生成され、タスクの詳細に表示されます。ログをダウンロードするには、ポート 8888 を使用します。

ポート 8161 は ActiveMQ の管理と構成に使用されますが、このポートへのアクセスは App Layering アプライアンス内からのみ使用できます。

オプションで、App Layering アプライアンスはアップグレードをチェックし、HTTPS/443またはHTTP/80を使用してインターネット経由でCitrixサーバーからアップグレードをダウンロードできます。インターネット接続が利用可能な場合は、www.citrix.comおよびcdn.citrix.comにアクセスします。

Connectorの構成

コネクタタイプごとに異なるポートが使用されます。コネクタの現在のリストは次のとおりです。

コネクタ	HTTP ポート	HTTPS ポート	内部ポート
Azure	3000	3500	3001/3501
Citrix Hypervisor	3002	3502	3003/3501
vSphere	3004	3504	3005/3505
Nutanix	3006	3506	3007/3507
Citrix Provisioning	3009	3509	3010/3510
Hyper-V	3012	3512	3011/3511

コネクタは、管理コンソール内で別の Web ページとして開きます。各コネクタには、HTTP および HTTPS リスニングポートの両方があります。コネクタを開くと、管理者は新しいタブの HTML5 ベースのインターフェイスにリダイレクトされます。管理者のブラウザは、各コネクタについて、上記のポートの App Layering アプライアンスにアクセスできる必要があります。

その他のポート

App Layering アプライアンスは、それぞれのポート上のさまざまなネットワークサーバーおよびサービスと通信します。App Layering アプライアンスは、次の TCP ポートで次のサービスに接続します。

接続先	プロトコル	ポート
Active Directory サーバー	LDAPS（SSLを介したLDAP）	636
Active Directory サーバー	LDAP	389
Active Directory サーバー	DNS	53
Windows ファイルサーバー	SMB	445
ネットワークタイムサーバ	NTP	123
DHCPサーバ	DHCP	UDP/67
App Layering アプライアンス	DHCP	UDP/68

エージェントサービス

エージェントサービスは、次の 3 つの機能に使用できます。

• Citrix Provisioning との統合
• Hyper-V との統合
• 一般的なスクリプトサーバーとの統合

エージェントサービスは、次のポートでアクセスされます。

エージェントサーバー	接続先	機能またはプロトコル	ポート
すべて	App Layering アプライアンス	登録または HTTPS	443
すべて	エージェントサーバー	App Layering アプライアンスまたは SOAP からのコマンド	8016
すべて	App Layering アプライアンス	ログエクスポート	8787
Citrix Provisioning	App Layering アプライアンス	ディスクアップロードまたは HTTP	3009
Citrix Provisioning	App Layering アプライアンス	ディスクアップロードまたは HTTPS	3509

App Layering エージェントを最初にインストールすると、インストーラはポート443でApp Layering アプライアンスへの接続を開き、エージェントサーバを登録します。App Layering アプライアンスは、エージェントサービスホストの完全修飾ドメイン名と短縮名を格納し、エージェントサーバーのレジストリには、App Layering アプライアンスのレコードが含まれています。

エージェントと App Layering アプライアンスが ID を交換すると、App Layering アプライアンスは、ポート 8016 のセキュアな SOAP チャネルでエージェントサービスと直接通信します。アプライアンスとエージェント間のほとんどの通信は、次のように動作します。

ホスト	アクション
App Layering アプライアンス	ポート8016のエージェントにこんにちは
App Layering アプライアンス	エージェントへのコマンド要求が開かれて
エージェント	構成されたユーザーアカウントとして PowerShell コマンドを実行します
エージェント	既存の要求チャネルでApp Layering アプライアンスに応答を送信します
エージェント	さようなら

送信される実際のコマンドの詳細は、アプリケーションレイヤアプライアンスのコネクタログや Agent Service サーバの App Layering ering.agent.log ファイルに表示されることがよくあります。

アプライアンスがログバンドルの生成を要求されると、アプライアンスに登録されているすべてのエージェントサービスに、エージェントからのログを要求する要求が送信されます。各エージェントサービスは、独自のログバンドルを生成し、ポート 8787 App Layering アプライアンスに転送します。

エージェントサービスの主な機能は、Citrix ProvisioningまたはHyper-Vにファイルを転送することです。ファイルを転送する場合、エージェントはエージェントサービスサーバー上の Windows バックグラウンドインテリジェント転送サービス (BITS) を使用して、仮想ディスクをサーバーにプルしてストアに配置するか、Hyper-V から VHD をアップロードまたはダウンロードします。

ファイルを転送するプロセスは次のように動作します。

ホスト	アクション
App Layering アプライアンス	ポート8016のエージェントにこんにちは
App Layering アプライアンス	ファイルアップロードのコマンドリクエスト
エージェント	設定されたユーザーアカウントとして BITS を実行します。
BITS	App Layeringアプライアンスのポート3009でCitrix Provisioningコネクタへの接続を開きます
BITS	指定したリポジトリの場所に、ファイルをダウンロードします。
App Layering アプライアンス	転送ステータスを取得するコマンド
エージェント	BITS をポーリングしてステータスを確認し、App Layering アプライアンスにレポートします。
BITS	終了
エージェント	App Layering アプライアンスに完全なステータスを報告します

通常、ファイル転送はポート 3009 で実行されます。ポートは暗号化されません。この通信はパフォーマンス上の理由で行われます。HTTPS 接続で実行するオーバーヘッドは、スループットに大きな影響を与えます。ただし、HTTPS を強制し、代わりに 3509 を使用するように Agent を設定できます。

エージェントが BITS を実行する場合、BITS は、ファイルのダウンロードの URL と宛先ファイルパスの 2 つの項目を提供します。BITS は、コネクタで構成されているユーザーアカウントとして実行されます。したがって、このユーザーには、ProvisioningサーバーからApp Layeringアプライアンスのポート3009への送信接続を確立する権限と、仮想ディスクストアにファイルを書き込む権限が必要です。

ハイパーバイザー

ハイパーバイザーコネクタは、次のポートを使用します。

コネクタ	接続先	ポート
Azure と Hyper-V	Azure 管理	443
Citrix Hypervisor	Citrix Hypervisor	5900
vSphere	バーチャルセンター	443
vSphere	ディスク転送用のESXホスト	443
Nutanix	Nutanix CVM	9440

これらのポートは、ハイパーバイザーブラウザベースの管理コンソールも使用するポートと同じです。App Layering では、ハイパーバイザーとの通信に、ハイパーバイザーの通常の Web サービスを通じて明確に定義された API 呼び出しを使用します。

vSphere ファイルのアップロードおよびダウンロードは、vCenter との通信によって実行されません。また、ESXi ホストとの直接通信によって処理されます。このため、vSphere コネクタでは、ホストを定義する必要があり、ポート 443 の App Layering アプライアンスからのアクセスを許可するようにホストファイアウォールを構成する必要があります。

合成エンジン

コンポジットエンジンは、ポート 3260 で iSCSI 接続用のApp Layering アプライアンスに接続し、ポート 443 でアプライアンスにAPI呼び出しを行います。App Layering アプライアンスは、ポート 443 でも合成エンジンへの API 呼び出しを実行します。

可用性、バックアップ、リカバリ

App Layering には、アプライアンス、Elastic Layer 共有、ユーザーレイヤー共有など、バックアップが適切ないくつかのコンポーネントを含めることができます。

注:

このセクションでは接続ブローカーの可用性について説明しますが、VDI ブローカーインフラストラクチャの回復と可用性についてはここでは説明しません。回復オプションの詳細については、デスクトップ接続ブローカソフトウェアのドキュメントとサポートチームを参照してください。

App Layering の可用性戦略は、ワークスペースソリューション全体の全体的な可用性とリカバリの設計に適合する必要があります。プールとデリバリーグループは、ホストとストレージのプールに分散しているため、すでに高可用性になっています。

ストレージは、さまざまな方法で高可用性を実現できます。一般的な方法の1つは、複数のストレージプロセッサまたはヘッド、およびRAIDテクノロジーを含む、高度な冗長性を備えたストレージアレイを使用することです。ただし、各ホスト上のローカル RAID コントローラとフラスコディスクに基づくローカルストレージを使用し、管理対象マシンを複数のホストに分散させることで、より高い可用性を得ることも可能です。何らかの理由でホストに障害が発生した場合、使用可能なデスクトップのプールにある管理対象マシンを使用して他のホストが実行され、ユーザーセッションが取得されます。

ハイパーバイザーは可用性を考慮して設計されているため、ネットワークも簡単に利用できるようにすることができます。ただし、環境内の各管理対象マシンに少なくとも 2 つのネットワークパスを使用できるようにすることが重要です。

App Layering に固有のコンポーネントは、アプライアンス、Elastic Layer、およびユーザーレイヤーです。

アプライアンスのバックアップ

前述のように、App Layering アプライアンスは、エンドユーザーがApp Layering をフルに使用するために必要ではないため、アプライアンスの可用性を高める必要はありません。ただし、アプライアンスを定期的にバックアップするための要件を考慮する必要があります。アプライアンスのバックアップにより、アプライアンスが何らかの理由で破壊または破損した場合でも、すべてのレイヤーを使用できるようになります。App Layering アプライアンスには、仮想マシンのバックアップテクノロジを使用できます。また、2つのアプライアンスとインポート/エクスポート機能を使用して、それらの同期を維持することもできます。ただし、このステップは現在手動プロセスです。

Elastic Layer の可用性と障害復旧

Elastic Layerは、SMB共有からのWindowsゲストマウントを使用してログオン中に仮想デスクトップエージェント（VDA）にマウントされたファイルです。レイヤーサービスは、ログオン時にレイヤーを接続しますが、切断された VHD ファイルは再接続されません。したがって、ある種のクラスター化されたファイルシステムを使用して、Elastic Layer に使用されるファイルサーバーの高可用性を確保することが重要です。ターゲットに障害が発生した場合、別のログオンが発生するまで、マウントされた VHD ファイルを別のターゲットに再マップできないため、このユースケースでは複数の DFS-R ターゲットを使用するだけでは不十分です。

ディザスタリカバリでは、Elastic Layer を処理するために使用できる 2 つのモデル（レプリケーションモデルまたはデュアルアプライアンスモデル）があります。

レプリケーションモデル

このモデルでは、ファイルシステムレプリケーションテクノロジを使用して Elastic Layer 共有をレプリケートできます。このモデルには、DFS-R、Microsoftのストレージレプリカ、Veeam、NASベンダーのレプリケーション、Zerto、VMware vSphereレプリケーション、さらにはロコピーなどのテクノロジーを含めることができます。

その後、DRデータセンター内のVDAは、GPOを介してそのデータセンター内のElastic Layer共有を指すことができます。リポジトリの場所を設定するGPOテンプレートは、 CTX222107にあります。

デュアルアプライアンスモデル

このモデルでは、アプライアンスが各データセンターにインストールされます。Applianceが提供するインポートおよびエクスポート機能は、レイヤーの観点から2つのアプライアンスの同期を維持するために使用されます。ここでは、管理者は DR レイヤーを個別に管理し、ローカルアプライアンスから DR にイメージを構築します。

このオプションを選択すると、インポートおよびエクスポート操作中に定義された SMB 共有から WAN 経由で同期が転送されます。その後、DR アプライアンスでレイヤーを割り当てて、DR の Elastic Layer 共有にコピーします。このモデルでは、すべてのレイヤーではなく、目的のレイヤーのみを同期するソリューションを開発することもできます。レイヤーは手動でエクスポート用に選択されるため、選択したレイヤーのみをプロセスに含めることができます。現時点では、インポートおよびエクスポートプロセスを手動で開始する必要があります。

デュアルアプライアンスモデルでは、コネクタとエラスティック共有のアクセス許可を両側に作成する必要があります。読み込まれるオブジェクトは、実際のレイヤそのものだけです。ただし、このモデルでは、必要に応じてサイトごとに異なるレイヤーを持つことができます。たとえば、それが本当にアクティブ/アクティブサイトのシナリオである場合などです。

ユーザー層の可用性とディザスタリカバリ

ユーザーレイヤーは、ログオン時に Windows がゲストマウントを使用してマウントした VHD ファイルであるという点で、Elastic Layers に似ています。ただし、書き込み可能としてマウントされ、ファイルは Windows デスクトップによってロックされます。この作業により、これらのディスクをバックアップおよび複製するオプションは、通常の Elastic Layer よりもはるかに困難になります。

この制限により、DFS-R または robocopy スクリプトを使用する場合、同期プロセスは (時間外と見なされる時間がある場合) 時間外に実行する必要があります。このプロセスは、ファイルを同期できるかどうかを常に確認する必要があります。大きなファイルであってもよく User Layer の場合、robocopy は正常に機能せず、変更されたブロックではなくファイル全体を常にコピーします。DFS-Rは、変更されたブロックのみをコピーするので、より良い選択になります。ただし、ストレージレベルでのレプリケーションは、ファイルロックが削除されるのを待たずに、変更が行われるとより均等に同期されるため、さらに優れています。

ユーザーレイヤーVHDファイルを保存するために選択した技術に応じて、ここだけでなく、サポートされている他のオプションがあります。ファイルサーバーがボリュームシャドウコピーサービス (VSS) をサポートしている場合、VSS スナップショットが作成され、ユーザーレイヤーのバックアップとレプリケーションが可能になります。プロセスの頻度を変えることによって、ユーザーレイヤーは、ユーザーに悪影響を与える破損や間違いが行われた場合、以前の時点にロールバックすることができます。

ストレージコントローラがNDMPをサポートしている場合、この機能はユーザー層のバックアップにも使用できます。NDMPは、ストレージ・レベルで機能し、NASスナップショットを使用して、NASストレージをディスクまたはテープに直接バックアップします。

大容量のディスクのレプリケーションが難しく、そのための帯域幅の費用がかかるため、多くのお客様は、レプリケートされたユーザー層を持たないユーザーに DR デスクトップを提供することを選択しています。このモデルでは、2つのオプションがあります。ユーザーは、ユーザーレイヤーが有効になっているDRサイトで別のデリバリーグループをプロビジョニングできます。その後、DR サイトにログオンし、必要なものを使用してそのレイヤーを事前に構成できます。または、通常の非永続的な DR デスクトップを使用してユーザーをプロビジョニングすることもできます。後者の場合、ユーザー設定をDRサイトにレプリケートできるように、Citrix Profile Managementとユーザーレイヤーを混在させることが有益であることがよくあります。

コンポーネントマルチサイトディザスタリカバリ

マルチサイトディザスタリカバリのアプローチは、ローカルリカバリと似ています。イメージの場合は、レプリケーションプロセスを使用する必要があります。Citrix Provisioning を使用している場合は、Robocopyを使用してvDiskをセカンダリサイトにコピーできます。vSphere でマシン作成サービスまたは Horizon View を使用している場合は、Veeam、Zerto、VMware vSphere Replication、またはサイトリカバリマネージャなどの仮想マシンをレプリケートするプロセスが必要です。これはELMを保護するためにも機能します。

Elastic Layers では、SAN レプリケーションまたはスクリプト化されたコピーの両方が機能します。ユーザーレイヤーを使用している場合は、共有に使用されるクラスター化されたファイルシステムの下で変更されたブロックをレプリケートできるように、SAN/NAS レベルでレプリケートする必要があります。

このアプローチは、ELM で複数のコネクタを定義し、両方のサイトに直接公開するよりも優れています。公開時には、イメージを作成してストアにアップロードする必要があるためです。既に作成されたイメージを複製するプロセスを使用する場合、これによって合成プロセスがスキップされ、より効率的です。

注:

ディザスタリカバリにデプロイされたイメージに別の設定が必要な場合は、ELM から直接公開することをお勧めします。これにより、回復するイメージテンプレートに異なるレイヤーを定義できます。

各サイトに 1 つずつ、2 つの ELM アプライアンスを使用することもできます。その後、エクスポート/インポート機能を使用して、レイヤーの観点からこれらの ELM の同期を維持できます。その後、リカバリを個別に処理し、ローカル ELM からイメージをビルドできます。

このオプションを選択すると、同期は WAN 経由で Settings で定義された SMB 共有に転送されます。レイヤーは、Robocopy と /MIR スイッチを使用して、2 番目のサイトで使用される SMB 共有に同期できます。現在、インポートとエクスポートのプロセスは手動で開始する必要があります。

また、すべてのレイヤーではなく、目的のレイヤーのみを同期することもできます。このオプションを希望する場合は、App Layering ソリューションアーキテクトに詳細を問い合わせてください。

デュアル ELM モデルでは、Elastic Shares のコネクタと権限を両側に作成する必要があります。インポートされるオブジェクトは、実際のレイヤだけです。ただし、このモデルでは、必要に応じて各サイトに異なるレイヤーを含めることができます。

ソース

このリファレンスアーキテクチャの目的は、お客様独自の実装計画を支援することです。この作業を簡単にするために、独自の詳細な設計と実装ガイドに適応できるソース図を提供します。 ソース図です。

参照ドキュメント

Citrix App Layering について理解を深めるために、以下のリソースを参照しています。

App Layering 製品ドキュメント

プラットフォームレイヤーの作成方法

エラスティックレイヤーの理解

Windows とApp Layering 最適化

App Layering アンチウイルスガイド

オフィスのレシピを理解する

App Layering ベストプラクティス