Templateドキュメント履歴PDFを表示このコンテンツは動的に機械翻訳されています。放弃このコンテンツは動的に機械翻訳されています。2024寄稿者:C展開がWANで接続された広範な場所に分散している場合、ネットワークの遅延と信頼性に関する問題が発生することがあります。Serverサイトデータベースを持つ複数のサイトの展開このオプションは、大規模な環境で推奨されます。Serverサイトデータベースが必要です。単一サイト内に複数のゾーンを構成します。ゾーンを構成することにより、リモートのユーザーが、WANの大規模セグメントを経由する接続を必ずしも必要とせず、リソースに接続できるようにサポートできます。Director、およびサイトデータベースからの効果的なサイト管理が実現します。これにより、リモートの場所への追加サイト(個別のデータベースを含む)の展開、それに要する人員の配置、ライセンス取得、および運用のコストが削減されます。ゾーンは、あらゆる規模の展開で有用です。ゾーンを使用して、アプリケーションおよびデスクトップとエンドユーザーの距離を縮めることにより、パフォーマンスを改善することができます。1つのゾーンにおいて、1つまたは複数のControllerをローカルでインストールして冗長性と回復性を確保することができますが、これは必須ではありません。サイトで多数のControllerを構成すると、サイト自体へのControllerの新規追加など一部の操作のパフォーマンスが低下する可能性があります。Desktopsサイトのゾーンの数は、50以下に制限することをお勧めします。ゾーンのネットワーク待機時間が250ミリ秒(RTT)を超える場合は、ゾーンではなくサイトを複数展開することをお勧めします。このアーティクルを通じ、「ローカル」という用語は、対象となるゾーンを指しています。「VDAはローカルControllerに登録されます」という場合、VDAが存在するゾーンのControllerに登録されることを意味します。6.5以前と大きな違いはありませんが、同一ではありません。このゾーン実装では、データコレクターが存在しません。サイトのすべてのControllerが、プライマリゾーンの1つのサイトデータベースと通信します。このリリースではフェールオーバーおよび優先ゾーンの機能が異なります。ゾーンの種類1つのサイトには、必ず1つのプライマリゾーンがあります。サイトにはオプションで1つまたは複数のサテライトゾーンを含めることもできます。離れたデータセンター、ブランチオフィス、クラウド、またはクラウドのアベイラビリティゾーンに使用できます。プライマリゾーン:プライマリゾーンのデフォルト名は「プライマリ」です。Gatewayが含まれます。サイトデータベースは、必ずプライマリゾーンに含まれている必要があります。プライマリゾーンには、冗長性確保のために少なくとも2つのControllerが含まれている必要があります。データベースおよびインフラストラクチャと密結合されたアプリケーションを含む1つまたは複数のVDAが含まれる場合があります。Gatewayサーバーが含まれます。通常時には、サテライトゾーンのControllerはプライマリゾーンのデータベースと直接通信します。大きなサテライトゾーンには、そのゾーンのマシンのプロビジョニングまたは保存(もしくはその両方)に使用されるハイパーバイザーも含まれる場合があります。サテライトゾーンの構成時には、ハイパーバイザーまたはクラウドサービス接続をサテライトゾーンに関連付けることができます(この接続を使用するマシンカタログが同じゾーンに含まれていることを確認してください)。ニーズと環境に応じて、1つのサイトに異なる構成のサテライトゾーンを含めることができます。次の図は、1つのプライマリゾーンと、複数のサテライトゾーンの例を示しています。Server展開)が含まれています。Gatewayも含まれています。サテライトゾーン1には、1つのController、複数のVDA、1つのStoreFrontサーバーが含まれています。このサテライトゾーンのVDAは、ローカルControllerに登録されます。ローカルControllerは、プライマリゾーンのサイトデータベースおよびライセンスサーバーと通信します。ローカルホストキャッシュ機能を使用すると、WANで障害が発生した場合に、サテライトゾーン内のControllerがそのゾーン内のVDAへの接続を引き続き仲介できるようになります。このような展開は、オフィスを社内ネットワークに接続するWANリンクで障害が発生しても、作業者がローカルStoreFrontサイトおよびローカルControllerを使用してローカルリソースにアクセスするオフィスで効果的です。サテライトゾーン2には、2つのController、複数のVDA、1つのStoreFrontサーバーが含まれています。この種類のゾーンは回復性が最も高く、WANとローカルControllerの1つで同時に障害が発生しても、それに耐えることができます。VDAの登録とControllerのフェールオーバープライマリゾーンとサテライトゾーンを含み、VDAのバージョンが7.7以降のサイトでは、以下のルールが適用されます。プライマリゾーンのVDAは、プライマリゾーンのControllerに登録されます。プライマリゾーンのVDAでは、サテライトゾーンのControllerへの登録が試行されることはありません。サテライトゾーンのVDAは、可能な場合はローカルControllerに登録されます(これが優先Controllerになります)。ローカルControllerを利用できない場合(ローカルControllerで追加のVDA登録を受け入れられない場合や、ローカルControllerで障害が発生している場合など)、VDAではプライマリゾーンのControllerへの登録が試行されます。この場合、サテライトゾーンのControllerが再び利用可能になっても、VDAはプライマリゾーンで登録されたままになります。サテライトゾーンのVDAでは、別のサテライトゾーンのControllerへの登録が試行されることはありません。ControllerのVDA検出で自動更新が有効になっており、VDAのインストール時にControllerアドレスの一覧を指定した場合、初回登録では、(Controllerが含まれるゾーンに関係なく)その一覧からランダムにControllerが選択されます。そのVDAが含まれるマシンが再起動された後、そのローカルゾーン内のControllerがVDA登録の優先Controllerになります。サテライトゾーンのControllerで障害が発生した場合、可能であれば別のローカルControllerへのフェールオーバーが実行されます。ローカルControllerを利用できない場合は、プライマリゾーンのControllerへのフェールオーバーが実行されます。Controllerをゾーン内またはゾーン外に移動し、自動更新が有効である場合、両方のゾーンのVDAに対し、ローカルのControllerとプライマリゾーンのControllerを示す更新された一覧が送信されます。これにより、登録および接続の受け入れが可能なControllerがVDAで認識されます。マシンカタログを別のゾーンに移動すると、そのカタログのVDAが、カタログを移動したゾーンのControllerに再登録されます(カタログを別のゾーンに移動するときは、このゾーンと、関連付けられたホスト接続のあるゾーンとが正しく接続されていることを確認します。帯域幅が制限されているか遅延が長い場合は、ホスト接続を、関連付けられたマシンカタログを含む同じゾーンに移動します。プライマリゾーンですべてのControllerが失敗すると、以下の状態になります。Studioがサイトに接続できない。プライマリゾーンでVDAに接続できない。プライマリゾーンのControllerが使用できるようになるまで、サイトのパフォーマンスが低下し続ける。7.7よりも前のVDAバージョンが含まれるサイトでは、以下のルールが適用されます。7.7以降のVDAでは、ほかのセカンダリゾーンからのController要求を受け入れることができます)。7.7以降のVDAでは、ローカルゾーンが優先されます)。11.0-65.x以上を使用している必要があります。複数のゾーンがあるサイトでは、管理者は、アプリケーションやデスクトップの起動にどのVDAが使用されるかを、ゾーンの優先度機能によってより柔軟に制御できます。ゾーンの優先度のしくみゾーンの優先度には以下の3つの形式があります。以下によっては、特定のゾーンにVDAを使用するのが好ましい場合があります。アプリケーションのデータの保存先。これを「アプリケーションホーム」と呼びます。プロファイルやホームシェアなどの、ユーザーのホームデータの場所。これを「ユーザーホーム」と呼びます。Workspaceアプリが実行されている)ユーザーの現在位置。これを「ユーザーの場所」と呼びます。次の図は、マルチゾーン構成の例を示しています。この例では、VDAは3つのサテライトゾーンにまたがっていますが、同じデリバリーグループに属しています。そのため、ブローカーはユーザーの起動依頼にどのVDAを使用するかを選択できる場合があります。Workspaceアプリエンドポイントを実行できる場所の数が示しています。Workspaceアプリを搭載したデバイスを使用しています。ユーザーBは、サテライトゾーン2でデバイスを使用しています。1人のユーザーのドキュメントをさまざまな場所に格納できます。ユーザーAとBは、サテライトゾーン1をベースに共有を使用します。ユーザーCはサテライトゾーンCからの共有を使用します。公開アプリケーションのいずれかによって、サテライトゾーン1にあるデータベースが使用されます。ユーザーまたはアプリケーションにホームゾーンを構成して、ユーザーまたはアプリケーションをゾーンと関連付けることができます。Controllerのブローカーがこれらの関連付けを使用して、セッションが開始されるゾーンを選択します(リソースが利用可能な場合)。次の操作を実行できます:ユーザーをゾーンに追加して、ユーザーのホームゾーンを構成します。アプリケーションプロパティを編集して、アプリケーションのホームゾーンを構成します。ユーザーまたはアプリケーションに構成できるホームゾーンは1回あたり1つのみです(ユーザーについては、複数のゾーンメンバーシップがある場合は例外となることがあります。「そのほかの考慮事項」セクションを参照してください。その場合においても、ブローカーが使うホームゾーンは1つのみです)。ユーザーおよびアプリケーションのゾーン優先度を構成できますが、ブローカーは起動する優先ゾーンを1つだけ選択します。優先ゾーンの選択におけるデフォルトの優先順位は、アプリケーションホーム、ユーザーホーム、ユーザーの場所の順になります。この順序は調整可能です。「ゾーン優先度の調整」を参照してください。ユーザーがアプリケーションを起動すると、優先ゾーンは次のように選択されます:アプリケーションに構成済みのゾーンの関連付け(アプリケーションホーム)がある場合、優先ゾーンはそのアプリケーションのホームゾーンとなります。アプリケーションには構成済みのゾーンの関連付けがなく、ユーザーには構成されたゾーンの関連付け(ユーザーホーム)がある場合、優先ゾーンはそのユーザーのホームゾーンとなります。Workspaceアプリインスタンスを実行しているゾーン(ユーザーの場所)となります。このゾーンが定義されていない場合は、VDAおよびゾーンのランダム選択が使用されます。負荷分散は、優先ゾーン内のすべてのVDAに適用されます。優先ゾーンがない場合、負荷分散はデリバリーグループ内のすべてのVDAに適用されます。ゾーン優先度の調整ユーザーまたはアプリケーションのホームゾーンを構成(または削除)すると、ゾーン優先度がどのように使われるか(または使われないか)をさらに制限できます。デリバリーグループで、セッションをユーザーのホームゾーンで開始し(ユーザーのホームゾーンがある場合)、ホームゾーンでリソースが利用可能でない場合には別のゾーンにフェールオーバーしないように指定できます。この制限は、大きなプロファイルやデータファイルがゾーン間でコピーされないようにする必要がある場合に有用です。他のゾーンでセッションを開始するのではなく、他のゾーンではセッションが開始されないようにします。同様に、アプリケーションのホームゾーンを構成する際に、アプリケーションをそのゾーンでのみ起動し、アプリケーションのホームゾーンでリソースが利用可能でない場合には他のゾーンにフェールオーバーしないように指定できます。アプリケーションのホームゾーンを指定しない場合は、アプリケーションを起動するときに構成済みのユーザーゾーンを考慮しないように指定することもできます。Workspaceアプリを実行中の)マシンの近くにあるVDAで特定のアプリケーションが実行されるようにできます。優先ゾーンによるセッション使用への影響ユーザーがアプリケーションやデスクトップを起動すると、ブローカーは既存のセッションよりも優先ゾーンを使用しようとします。アプリケーションまたはデスクトップを起動しているユーザーに、起動中のリソースに最適なセッション(アプリケーションのセッション共有を使用できるセッション、または起動中のリソースを既に実行しているセッションなど)があるにもかかわらず、セッションがユーザーまたはアプリケーションの優先ゾーン以外のゾーンのVDAで実行されている場合、新しいセッションが作成されることがあります。これにより、セッションは、ユーザーのセッション要件に対して優先度の低いゾーンに再接続される前に、正しいゾーンで開始されます(そのゾーンに使用可能な容量がある場合)。操作できなくなる孤立セッションが発生しないようにするため、優先ではないゾーンにあっても、再接続は既存の切断されたセッションにのみ許可されます。セッション開始の望ましさの順は、以下のとおりです。優先ゾーンにある既存セッションに再接続する。優先ゾーン以外のゾーンにある既存の切断されたセッションに再接続する。優先ゾーンで新しいセッションを開始する。優先ゾーン以外のゾーンにある接続中の既存セッションに再接続する。優先ゾーン以外のゾーンで新しいセッションを開始する。ゾーン優先度に関するそのほかの考慮事項ユーザーグループ(セキュリティグループなど)のホームゾーンを構成する場合、(直接または間接メンバーシップによる)そのグループのユーザーは、指定されたゾーンに関連付けられます。ユーザーは複数のセキュリティグループのメンバーになることができるため、他のグループのメンバーシップで他のホームゾーンが構成されている可能性があります。そのような場合は、そのユーザーのホームゾーンの特定があいまいになる可能性があります。ユーザーに、グループメンバーシップで取得されなかった構成済みのホームゾーンがある場合、そのゾーンがゾーン優先度に使用されます。グループメンバーシップで取得されたゾーンの関連付けはすべて無視されます。ユーザーに、グループメンバーシップのみで取得された複数の異なるゾーンの関連付けがある場合、ブローカーはそれらのゾーンの中からランダムに選択します。ブローカーがゾーンを選択すると、そのゾーンはユーザーのグループメンバーシップが変更されるまで、後続のセッションの開始に使用されます。Workspaceアプリが検出される必要があります。Gatewayは、IPアドレスの範囲を特定のゾーンに関連付けるように構成する必要があり、検出されたゾーンのIDは、StoreFrontからControllerに渡される必要があります。ベストプラクティスゾーンには、Controller、マシンカタログ、ホスト接続、ユーザー、およびアプリケーションを配置することができます。マシンカタログでホスト接続が使用される場合、カタログと接続の両方が同じゾーンに含まれている必要があります。(ただし、遅延が少ない高帯域幅接続を利用可能な場合は、異なるゾーンに存在できます。)サテライトゾーンにアイテムを配置すると、これらのアイテムおよびこれらに関連する他のオブジェクトとサイトとの通信方法に影響します。Controllerマシンがサテライトゾーンに配置されている場合、これらのマシンは同一のサテライトゾーンにあるハイパーバイザーおよびVDAマシンと良好に(ローカルに)接続できるものとみなされます。そのため、サテライトゾーンにあるハイパーバイザーやVDAマシンを処理する場合、プライマリゾーンのControllerではなく同じサテライトゾーンにあるControllerが使用されます。ハイパーバイザー接続がサテライトゾーンに配置されている場合、このハイパーバイザー接続で管理されているすべてのハイパーバイザーも同じサテライトゾーン内に存在するものとみなされます。そのため、サテライトゾーンにあるハイパーバイザー接続を使用して通信する場合、プライマリゾーンのControllerではなく同じサテライトゾーンにあるControllerが使用されます。マシンカタログがサテライトゾーンに配置されている場合、このカタログ内のすべてのVDAマシンも同じサテライトゾーンにあるとみなされます。このため、各VDAの初回登録後にControllerリストの自動更新メカニズムが有効になると、サイトへの登録時にはプライマリゾーンのControllerではなくローカルのControllerが使用されます。Gatewayインスタンスもゾーンに関連付けることができます。この関連付けはこの記事で説明する他の要素と同様に、サイト構成ではなくStoreFrontの最適なHDXルーティング構成の一環として行います。Gatewayは、そのゾーンにあるVDAマシンへのHDX接続で優先して使用されます。実稼働サイトを作成してから、最初のマシンカタログおよびデリバリーグループを作成した場合、すべてのアイテムがプライマリゾーンに含まれます。初期セットアップを完了するまで、サテライトゾーンは作成できません(空のサイトを作成した場合、初期段階ではプライマリゾーンにはコントローラのみが含まれます。マシンカタログとデリバリーグループグループの作成前または作成後に、サテライトゾーンを作成することができます)。1つまたは複数のアイテムが含まれる最初のサテライトゾーンを作成する場合、サイトのそのほかすべてのアイテムはプライマリゾーンに残ります。プライマリゾーンのデフォルト名は「プライマリ」です。この名前は変更できます。Studio表示ではどのゾーンがプライマリゾーンかが示されますが、プライマリゾーンには容易に特定できる名前を使用するのがベストプラクティスです。プライマリゾーンは再割り当てする(すなわち、別のゾーンをプライマリゾーンにする)ことができます。プライマリゾーンには必ずサイトデータベースと高可用性サーバーが含まれている必要があります。サイトデータベースは、必ずプライマリゾーンに含まれている必要があります。ゾーンを作成した後、アイテムをゾーン間で移動できます。この柔軟性により、近くに配置することによって最適に機能する複数のアイテムを別々のゾーンに配置してしまう可能性があります。マシンカタログを、カタログ内のマシンを作成する接続(ホスト)とは別のゾーンに移動すると、パフォーマンスが低下する場合があります。そのため、アイテムをゾーン間で移動する前に、意図しない影響が出る可能性を考慮してください。カタログとホスト接続(同じゾーンまたは適切に接続されているゾーン(遅延が少なく高帯域幅のネットワーク経由など)でカタログが使用するもの)を維持します。パフォーマンスを最適化するため、StudioとDirectorはプライマリゾーンのみにインストールします。サテライトゾーンに追加のStudioインスタンスが必要な場合(Controllerが含まれるサテライトゾーンが、プライマリゾーンにアクセスできなくなった場合のフェールオーバーとして使用されている場合など)、Studioをローカル公開アプリケーションとして実行します。DirectorはWebアプリケーションであるため、サテライトゾーンからもアクセスできます。Gatewayはゾーン内の接続に使用できますが、ほかのゾーンまたは外部からそのゾーンへのユーザー接続に使用するのが理想的です。11.0-65.x以上を使用している必要があります。接続の質の制限サテライトゾーンのControllerは、サイトデータベースに対してSQL操作を直接実行します。このため、サテライトゾーンと、サイトデータベースが含まれるプライマリゾーンとのリンクの質はある程度制限されます。一部の制限は、サテライトゾーンに展開されているVDAの数とこれらのVDA上のユーザーセッションの数に関係します。このため、VDAとセッションの数が少ないサテライトゾーンでは、VDAとセッションの数が多いサテライトゾーンよりもデータベースへの接続の質が低下します。詳しくは、「遅延およびSQLブロッキングクエリの向上」を参照してください。仲介のパフォーマンスに対する遅延時間の影響ゾーンではリンクの遅延時間が大きくなりますが、ローカルブローカーが存在する場合、エンドユーザーのエクスペリエンスではさらに遅延が生じることになります。したユーザーが行う作業のほとんどで、サテライトゾーンのControllerとサイトデータベース間での往復時間による遅れが生じます。アプリケーションを起動する場合、セッションの仲介プロセスでセッション開始の要求を送信するのに適したVDAが見つかるまで、さらに遅れが生じます。ゾーンの作成と管理すべての管理権限を実行できる管理者は、ゾーンの作成および管理に関するすべてのタスクを実行できます。ゾーンを作成、編集、または削除できるカスタムの役割を作成することもできます。アイテムをゾーン間で移動するために、ゾーン関連の権限(ゾーン読み取り権限を除く)は必要ありません。移動するアイテムの編集権限は必要になります。マシンカタログをゾーン間で移動するには、そのマシンカタログの編集権限が必要です。詳しくは、「委任管理」を参照してください。Provisioningコンソールではゾーンが認識されないため、サテライトゾーンに配置するマシンカタログを作成する場合は、Studioを使用することをお勧めします。Studioウィザードを使用してカタログを作成し、適切なサテライトゾーンを指定します。Provisioningウィザードを使用してカタログを作成した場合、カタログはプライマリゾーンに配置されます。後でサテライトゾーンに移動するにはStudioを使用する必要があります)。