Citrix App Layering

寄稿者

著者： Nagaraj Manoli

謝辞：

Rob Zylowski Dan Morgan

オーディエンス

このドキュメントは、テクニカルプロフェッショナル、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」と呼ばれる異なるコンテナに分割されています。レイヤーは独立して作成および更新され、「公開イメージ」にコンパイルされ、サポートされているProvisioning システムを使用して配布されます。

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

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

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

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

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

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

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

アプリケーションとパーソナライゼーションをオペレーティング・システムから分離することで、非永続的なイメージ管理に対する柔軟で管理しやすいソリューションが提供されます。

Citrix App Layering が選ばれる理由

Citrix App Layering は、パッケージング要件が異なる複数の環境で複雑なアプリケーションセットを管理するための、費用対効果の高いソリューションを提供します。カーネルドライバー、OS、システムサービスの依存関係が埋め込まれているほとんどすべてのアプリケーションは、App Layering テクノロジと互換性があります。

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

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

• Azureのサポート： Citrix App Layering は、Microsoft Azureをサポートし、App Layeringのお客様は、Azureプラットフォームへの移行を容易にします。

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

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

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

• 必要なイメージの数を減らす: Elastic Layering では、ログオン時に割り当てられたユーザーのみにアプリケーションを動的に配信することで、必要なイメージの数を大幅に削減できます。Elastic Layersは、Citrix Virtual Apps および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 アプライアンスによって更新されます。Microsoft Office が 10 のイメージで使用されている場合、Office レイヤーにバージョンを追加することで、この Office のアップグレードが簡単になります。最終的に、これらの10枚の画像はすべて自動的に更新されます。

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

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

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

通常、Hypervisor とハイブリッドクラウドの混在構成では、管理者は複数の異なる管理プラットフォームで複数の異なるイメージとアプリケーションを維持する必要があります。App Layering テクノロジーにより、オンプレミスで使用された同じ OS とアプリケーションをクラウドまたは別のHypervisor にプッシュできます。余分な作業はほとんど必要ありません。

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

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

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

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

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

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

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

永続性を必要とするユースケースでは、ユーザーレイヤーが最適です。Microsoft Outlook OSTファイルとインデックスのためだけに永続性を提供することが主な要件である場合、ユーザー層は最良の選択ではありません。Outlook のインデックスは、ユーザー層を使用するすべてのログオン中に再構築する必要があるためです。Citrix Profile ManagementのOutlookコンテナやFSLogixプロファイルコンテナなどの他の技術は、Outlookインデックスをより最適な方法で処理し、Microsoft Outlookが永続性の主な用途である場合は考慮する必要があります。

Citrix App Layering 技術概要

レイヤーのタイプ

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

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

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

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

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

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

ユーザー層： 伸縮性（次のセクションを参照）書き込み可能なレイヤー。ユーザー層は、ログオン時にマウントされ、一度マウントされたほぼすべてのデスクトップ書き込みは、ユーザー層に行きます。このレイヤーにより、ユーザーは共有デスクトップモデルを使用している場合でも、VDI エクスペリエンスを大幅にカスタマイズできます。

Citrix App Layering アプライアンス

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

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

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

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

アプライアンスは、レイヤー、イメージ、および Elastic Layer 割り当ての管理にのみ使用されます。Virtual Desktops and Virtual Appサーバーは、アプライアンスと直接接続しません。レイヤーが伸縮自在に割り当てられると、アプライアンスはそのレイヤーを Elastic Layer 共有にコピーします。共有には、これらの VHD ファイルと、レイヤー割り当てをユーザーに提供する一連の JSON ファイルが保持されます。

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

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

Citrix App Layering 管理コンソールは、アプリケーションApp Layering アプライアンスでホストされるWebベースのアプリケーションです。App Layering 管理コンソールは、以下のインターフェースを提供します。

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

レイヤ配信

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

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

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

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

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

コネクタには、Hypervisor とProvisioning の 2 種類があります。

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

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

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

• OS レイヤーの作成時のゴールドイメージのインポート
• レイヤとレイヤバージョンの作成
• 階層化されたイメージをHypervisor またはProvisioning Servicesに公開します。コネクタ構成には、Provisioning Servicesサーバーで実行するPowerShell スクリプトや、公開イメージの後処理を実行するホスト・エージェントを持つシステムも含まれます。

参考資料：コネクタの構成

コネクタのタイプ

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

ハイパーバイザコネクタ

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

Citrix Provisioning

Citrix Provisioning コネクタは、Citrix Provisioning サーバー上のApp Layering エージェントと統合され、イメージを仮想ディスクとしてProvisioningサーバーに直接公開します。Citrix Provisioning の前提条件は次のとおりです。

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

参考資料：Citrix Provisioning

Machine Creation Services

Citrix App Layering アプライアンスは、階層化されたイメージを直接プロビジョニングし、MCSのマスターイメージとして使用される仮想マシンとしてハイパーバイザーに公開できます。コネクタを使用すると、階層化されたイメージをHypervisor に直接公開できます。MCS コネクタは Hypervisor コネクタとほとんど同じです。ただし、MCS コネクタは、MCS によってデプロイされる前に、レイヤで定義されたスクリプトをマスターイメージで実行できる公開仮想マシンを起動します。マスターイメージのシャットダウンと仮想マシンのスナップショットは、このプロセスの一環として取得されます。

コネクタスクリプト

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

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

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

公開されたイメージテンプレート

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

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

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 アプリケーションの階層化エージェントの詳細については、Citrix のドキュメントを参照してください。

参考資料：エージェントのインストール

Active Directory

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

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

• 役割ベースのアクセス制御 (RBAC)
• Elastic レイヤーとユーザーレイヤーの割り当て

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

参考資料：OS レイヤーの作成

プラットフォーム層

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

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

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

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

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

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

プラットフォームレイヤーの作成のために記憶すべきいくつかのポイント:

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

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

アプリケーションレイヤー

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

App Layer の作成と編集の詳細については、製品ドキュメントを参照してください。

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

参考資料：App Layering レシピ

Elastic Layering

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

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

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

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

設定ファイル (JSON)

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

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

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

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

ユーザレイヤ

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

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

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

中に、Windows Search 構成のすべてのエントリに対して、ユーザー層が有効なデスクトップの新しい検索インデックスのログオンプロセスが作成されます。インデックス作成が完了すると、検索が使用可能になります。次のタイプのユーザレイヤを使用できます。

• 完全: ユーザーのデータ、設定、およびローカルにインストールされたアプリはすべて、ユーザーレイヤーに格納されます。
• 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 レイヤー共有とユーザーレイヤー共有

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

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

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 Layer 共有のアーキテクチャの詳細については、「 可用性、バックアップ、およびリカバリ」セクションを参照してください。

ユーザ画層ファイル共有

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

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

\\Server\Share\Users\Domain_Username\OSLayerID_OSLayerName

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

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

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

App Layering 統合

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

Citrix App LayeringおよびCitrix Provisioning Services

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

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

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

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

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

Citrix Provisioning キャッシュディスクに対するElastic Layeringの影響

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

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

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

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

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

Citrix App LayeringおよびMachine Creation Service

レイヤードイメージをMachine Creation Serviceに公開するには、公開先のHypervisor 用に作成されたMachine Creation Serviceコネクタを作成します。Connector構成には、ホスト、ストレージの場所、テンプレートなどに加えて、Hypervisor へのアクセスに使用されるサービスアカウント資格情報が含まれます。

次に、コネクタを使用して、レイヤー化されたイメージを仮想マシン「マスターイメージ」としてHypervisor に公開します。

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

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

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

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

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

プラットフォームレイヤー- このレイヤーはアプリケーションレイヤーに似ていますが、常に優先順位が最も高く、イメージのクリーンアップ「レシピ」を公開すると、アプリケーションレイヤーとはプラットフォームレイヤーに対して異なる方法で実行されます。プラットフォーム層は、定義された「プラットフォーム」のソフトウェアドライバがインストールされている場所です。たとえば、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では、「ルート」と「管理者」の両方が無効になっています。代わりに、アプライアンスのProvisioning 中に、ローカル管理ユーザー・アカウントの管理者にプロンプトが表示されます。

管理コンソールからログをエクスポートすると、ダウンロードリンクが生成され、タスクの詳細に表示されます。ポート 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 Agent の初期インストール時に、インストーラーはポート 443 で App Layering アプライアンスへの接続を開き、Agent Server を登録します。App Layering アプライアンスは、エージェントサービスホストの FQDN と短縮名を格納し、エージェントサーバー上のレジストリには、App Layering アプライアンスのレコードが含まれます。

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

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

送信される実際のコマンドの詳細は、多くの場合、App Layering アプライアンス上のコネクタログまたはエージェントサービスサーバー上のApplayering.agent.logファイルに表示されます。

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

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

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

ホスト	操作（アクション）
App Layering アプライアンス	ポート 8016 のエージェントにHello
App Layering アプライアンス	ファイルアップロードのコマンドリクエスト
エージェント	構成されたユーザーアカウントとして BITS を実行します。
BITS	App Layering アプライアンスのポート3009でCitrix Provisioning コネクタへの接続を開きます。
BITS	指定したリポジトリの場所にファイルをダウンロードします。
App Layering アプライアンス	転送ステータスを取得するコマンド
エージェント	BITS をポーリングしてステータスを取得し、App Layering アプライアンスにレポートします。
BITS	仕上げ
エージェント	App Layering アプライアンスに完了ステータスを報告する

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

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

Hypervisors

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

コネクタ	接続先	ポート
AzureおよびHyper-V	Azure Management	443
Citrix Hypervisor	Citrix Hypervisor	5900
vSphere	Virtual Center	443
vSphere	ディスク転送用の ESX ホスト	443
Nutanix	Nutanix CVM	9440

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

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

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

App Layering は、バックアップが適切な複数のコンポーネントを持つことができます。アプライアンス、Elastic Layer 共有、ユーザーレイヤー共有を含みます。

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

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

Elastic Layer の可用性と災害復旧

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

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

参考資料：App Layering 4.x の可用性とリカバリの概念ガイド

レプリケーション・モデル

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

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

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

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

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

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

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

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

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

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

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

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

参考資料：Citrix App Layering バックアップとリカバリ

ソース

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

参照ドキュメント

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

App Layering 製品ドキュメント

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

Elastic Layeringの理解

App Layering 可用性とリカバリの概念ガイド

WindowsおよびApp Layering の最適化

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

Office レシピを理解する

App Layering ベストプラクティス