ゾーン
注:
Citrix Virtual Apps and Desktops™展開は、Web Studio(Webベース)とCitrix Studio(Windowsベース)の2つの管理コンソールを使用して管理できます。この記事ではWeb Studioのみを扱います。Citrix Studioについては、Citrix Virtual Apps and Desktops 7 2212以前の同等の記事を参照してください。
WANで接続された広範囲に分散した場所にまたがる展開では、ネットワークの遅延と信頼性の問題に直面する可能性があります。これらの課題を軽減する2つのオプションがあります。
-
複数のサイトを展開し、それぞれに独自のSQL Serverサイトデータベースを持たせる。このオプションは、大規模なエンタープライズ展開に推奨されます。複数のサイトは個別に管理され、それぞれに独自のSQL Serverサイトデータベースが必要です。各サイトは独立したCitrix Virtual Apps™展開です。
-
単一サイト内に複数のゾーンを構成する。ゾーンを構成することで、遠隔地のユーザーがWANの大部分を通過するように接続を強制することなく、リソースに接続できるようになります。ゾーンを使用すると、単一のWeb Studioコンソール、Citrix Director、およびサイトデータベースから効果的なサイト管理が可能になります。これにより、遠隔地に個別のデータベースを含むより多くのサイトを展開、人員配置、ライセンス供与、および運用するコストを節約できます。ゾーンは、あらゆる規模の展開で役立ちます。ゾーンを使用すると、アプリケーションとデスクトップをエンドユーザーに近づけることができ、パフォーマンスが向上します。ゾーンには、冗長性と回復性のために1つ以上のControllerをローカルにインストールできますが、必須ではありません。サイトに構成されているControllerの数は、サイト自体に新しいControllerを追加するなどの一部の操作のパフォーマンスに影響を与える可能性があります。これを避けるため、Citrix Virtual AppsまたはCitrix Virtual Desktops™サイトのゾーン数を50以下に制限することをお勧めします。ゾーンのネットワーク遅延が250ミリ秒RTTを超える場合は、ゾーンではなく複数のサイトを展開することをお勧めします。
この記事全体を通して、「ローカル」という用語は、議論されているゾーンを指します。たとえば、「VDAがローカルControllerに登録する」とは、VDAがVDAが配置されているゾーン内のControllerに登録することを意味します。
このリリースでのゾーンは、XenAppバージョン6.5以前のゾーンと似ていますが、同一ではありません。たとえば、このゾーンの実装では、データコレクターはありません。サイト内のすべてのControllerは、プライマリゾーンの1つのサイトデータベースと通信します。また、このリリースではフェイルオーバーゾーンと優先ゾーンの動作が異なります。
ゾーンの種類
サイトには常に1つのプライマリゾーンがあります。オプションで1つ以上のサテライトゾーンを持つこともできます。サテライトゾーンは、災害復旧、地理的に離れたデータセンター、支店、クラウド、またはクラウド内のアベイラビリティゾーンに使用できます。
プライマリゾーン:
プライマリゾーンのデフォルト名は「Primary」です。このゾーンには、SQL Serverサイトデータベース(および使用されている場合は高可用性SQLサーバー)、Web Studio、Director、Citrix StoreFront™、Citrix License Server、Citrix Gatewayが含まれます。サイトデータベースは常にプライマリゾーンに保持してください。
プライマリゾーンには、冗長性のために少なくとも2つのControllerが必要です。プライマリゾーンには、データベースおよびインフラストラクチャと密接に連携するアプリケーションを持つVDAを含めることができます。
サテライトゾーン:
サテライトゾーンには、1つ以上のVDA、Controller、StoreFrontサーバー、およびCitrix Gatewayサーバーが含まれます。通常の運用では、サテライトゾーンのControllerはプライマリゾーンのデータベースと直接通信します。
サテライトゾーン、特に大規模なゾーンには、そのゾーンのマシンをプロビジョニングおよび保存するために使用されるハイパーバイザーが含まれる場合もあります。サテライトゾーンを構成する際、ハイパーバイザーまたはその他のサービス接続を関連付けることができます。(その接続を使用するカタログがすべて同じゾーンにあることを確認してください。)
サイトには、独自のニーズと環境に基づいて、さまざまな構成のサテライトゾーンを含めることができます。次の図は、プライマリゾーンとサテライトゾーンの例を示しています。
プライマリゾーンとサテライトゾーンの図(/en-us/citrix-virtual-apps-desktops/2311/media/zones1.png)
図では次のようになっています。
-
プライマリゾーン: 2つのController、Web Studio、Director、StoreFront、License Server、およびサイトデータベース(高可用性SQL Server展開を含む)が含まれます。プライマリゾーンには、複数のVDAとCitrix Gatewayも含まれます。
-
サテライトゾーン1: Controllerを持つVDA: サテライトゾーン1には、Controller、VDA、およびStoreFrontサーバーが含まれます。このサテライトゾーンのVDAは、ローカルのControllerに登録されます。ローカルのControllerは、プライマリゾーンのサイトデータベースおよびライセンスサーバーと通信します。WANに障害が発生した場合、ローカルホストキャッシュ機能により、サテライトゾーンのControllerは、そのゾーンのVDAへの接続の仲介を継続できます。このような展開は、従業員がローカルのStoreFrontサイトとローカルのControllerを使用してローカルリソースにアクセスするオフィスで効果的です。
-
サテライトゾーン2: 冗長Controllerを持つVDA: サテライトゾーン2には、2つのController、VDA、およびStoreFrontサーバーが含まれます。これは最も回復力の高いゾーンタイプであり、WANとローカルControllerのいずれか一方の同時障害に対する保護を提供します。
VDAの登録場所とControllerのフェイルオーバー場所
プライマリゾーンとサテライトゾーンを含むサイトで、VDAが最小バージョン7.7の場合:
-
Primary zoneのVDAは、Primary zoneのControllerに登録します。Primary zoneのVDAは、Satellite zoneのControllerに登録しようとすることはありません。
-
Satellite zoneのVDAは、可能であればローカルのControllerに登録します。(これは優先Controllerと見なされます。) ローカルのControllerが利用できない場合 (たとえば、これ以上VDA登録を受け入れられない、または障害が発生した場合など)、VDAはPrimary zoneのControllerに登録しようとします。この場合、Satellite zoneのControllerが再び利用可能になったとしても、VDAはPrimary zoneに登録されたままになります。Satellite zoneのVDAは、別のSatellite zoneのControllerに登録しようとすることはありません。
-
ControllerのVDA検出で自動更新が有効になっており、VDAのインストール中にControllerアドレスのリストを指定した場合、最初の登録のためにそのリストからControllerがランダムに選択されます (Controllerがどのゾーンにあるかに関係なく)。そのVDAがインストールされているマシンが再起動されると、VDAはローカルゾーンのControllerへの登録を優先するようになります。
-
Satellite zoneのControllerで障害が発生した場合、可能であれば別のローカルControllerにフェールオーバーします。ローカルControllerが利用できない場合は、Primary zoneのControllerにフェールオーバーします。
-
Controllerをゾーンの内外に移動し、自動更新が有効になっている場合、両方のゾーンのVDAは、どのControllerがローカルで、どのControllerがPrimary zoneにあるかを示す更新されたリストを受け取ります。これにより、VDAはどのControllerに登録し、どのControllerから接続を受け入れることができるかを知ることができます。
-
カタログを別のゾーンに移動すると、そのカタログ内のVDAは、カタログを移動したゾーンのControllerに再登録します。(カタログを別のゾーンに移動するときは、このゾーンと関連するホスト接続があるゾーンが適切に接続されていることを確認してください。帯域幅が制限されている場合や、待ち時間が長い場合は、ホスト接続を関連するマシンカタログを含む同じゾーンに移動してください。)
Primary zoneのすべてのControllerで障害が発生した場合:
-
Web Studioはサイトに接続できません。
-
Primary zoneのVDAへの接続はできません。
-
Primary zoneのControllerが利用可能になるまで、サイトのパフォーマンスが低下します。
VDAバージョン7.7より前のバージョンを含むサイトの場合:
-
Satellite zoneのVDAは、ローカルゾーンおよびPrimary zoneのControllerからの要求を受け入れます。(最小バージョン7.7のVDAは、他のSatellite zoneのControllerからの要求を受け入れることができます。)
-
Satellite zoneのVDAは、Primary zoneまたはローカルゾーンのControllerにランダムに登録します。(最小バージョン7.7のVDAはローカルゾーンを優先します。)
ゾーンの優先順位
ゾーンの優先順位機能を使用するには、StoreFront 3.7およびCitrix Gateway 11.0-65.x以降を使用している必要があります。
マルチゾーンサイトでは、ゾーン優先機能により、管理者はアプリケーションまたはデスクトップの起動に使用するVDAをより柔軟に制御できます。
ゾーンの優先順位の仕組み
ゾーン優先には3つの形式があります。特定のゾーンのVDAを使用することを好む場合があります。その判断基準は次のとおりです。
-
アプリケーションのデータが保存されている場所。これはアプリケーションホームと呼ばれます。
-
ユーザーのホームデータ(プロファイルやホーム共有など)の場所。これはユーザーホームと呼ばれます。
-
ユーザーの現在の場所(Citrix Workspace™アプリが実行されている場所)。これはユーザーロケーションと呼ばれます。
次の図は、マルチゾーン構成の例を示しています。
この例では、VDAは3つのサテライトゾーンに分散されていますが、すべて同じデリバリーグループに属しています。したがって、ブローカーはユーザーの起動要求に対してどのVDAを使用するかを選択する可能性があります。この例は、ユーザーがCitrix Workspaceアプリのエンドポイントを実行できる場所がいくつかあることを示しています。
-
ユーザーAは、サテライトゾーン1でCitrix Workspaceアプリがインストールされたデバイスを使用しています。
-
ユーザーBは、サテライトゾーン2でデバイスを使用しています。
-
ユーザーのドキュメントはさまざまな場所に保存できます。
-
ユーザーAとBは、サテライトゾーン1にある共有を使用します。
-
ユーザーCは、サテライトゾーンCの共有を使用します。
-
公開されているアプリケーションの1つは、サテライトゾーン1にあるデータベースを使用します。
-
ユーザーまたはアプリケーションのホームゾーンを構成することで、ユーザーまたはアプリケーションをゾーンに関連付けます。その後、Delivery Controller™内のブローカーは、これらの関連付けを使用して、リソースが利用可能な場合にセッションが起動されるゾーンの選択を支援します。次のことができます。
-
ユーザーをゾーンに追加して、ユーザーのホームゾーンを構成する。
-
アプリケーションのプロパティを編集して、アプリケーションのホームゾーンを構成する。
ユーザーまたはアプリケーションは、一度に1つのホームゾーンしか持つことができません。(ユーザーグループのメンバーシップにより複数のゾーンメンバーシップが発生する場合、ユーザーに例外が発生することがあります。「その他の考慮事項」セクションを参照してください。ただし、この場合でも、ブローカーは1つのホームゾーンのみを使用します。)
ユーザーおよびアプリケーションのゾーン設定を構成できますが、ブローカーは起動に対して1つの優先ゾーンのみを選択します。優先ゾーンを選択するためのデフォルトの優先順位は、アプリケーションホーム \> ユーザーホーム \> ユーザーロケーションです。この順序を制限できます。詳細については、「ゾーン設定の調整」を参照してください。ユーザーがアプリケーションを起動すると、次のようになります。
-
そのアプリケーションに構成済みのゾーン関連付け(アプリケーションホーム)がある場合、優先ゾーンはそのアプリケーションのホームゾーンになります。
-
アプリケーションに構成済みのゾーン関連付けがないが、ユーザーに構成済みのゾーン関連付け(ユーザーホーム)がある場合、優先ゾーンはそのユーザーのホームゾーンになります。
-
アプリケーションにもユーザーにも構成済みのゾーン関連付けがない場合、優先ゾーンはユーザーがCitrix Workspaceアプリインスタンスを実行しているゾーン(ユーザーロケーション)になります。そのゾーンが定義されていない場合、ランダムなVDAとゾーンの選択が使用されます。優先ゾーン内のすべてのVDAに負荷分散が適用されます。優先ゾーンがない場合、Delivery Group内のすべてのVDAに負荷分散が適用されます。
ゾーンの優先順位の調整
ユーザーまたはアプリケーションのホームゾーンを構成(または削除)する際に、ゾーン設定の使用方法をさらに制限することもできます。
-
ユーザーホームゾーンの強制使用: Delivery Groupでは、ユーザーのホームゾーンに利用可能なリソースがない場合でも、セッションがユーザーのホームゾーン(構成されている場合)で起動され、他のゾーンへのフェイルオーバーが行われないように指定できます。この制限は、ゾーン間で大きなプロファイルやデータファイルをコピーするリスクを回避する必要がある場合に役立ちます。つまり、異なるゾーンでセッションを起動するよりも、セッションの起動を拒否する方が望ましいということです。
-
アプリケーションホームゾーンの強制使用: 同様に、アプリケーションのホームゾーンを構成する際に、アプリケーションがそのゾーンでのみ起動され、アプリケーションのホームゾーンにリソースがない場合に他のゾーンへのフェイルオーバーが行われないように指定できます。
-
アプリケーションホームゾーンなし、および構成済みユーザーホームゾーンを無視: アプリケーションのホームゾーンを指定しない場合、そのアプリケーションを起動する際に、構成済みのユーザーゾーンを考慮しないように指定することもできます。たとえば、一部のユーザーが異なるホームゾーンを持っている場合でも、ユーザーロケーションゾーン設定を使用して、ユーザーがデバイスの近くのVDAでアプリケーションを実行することを好む場合があります。
優先ゾーンがセッションの使用に与える影響
ユーザーがアプリケーションまたはデスクトップを起動すると、ブローカーは既存のセッションを使用するよりも優先ゾーンを使用することを優先します。
アプリケーションまたはデスクトップを起動するユーザーが、起動されるリソースに適したセッションをすでに持っている場合(たとえば、アプリケーションのセッション共有を使用できるセッション、または起動されるリソースがすでに実行されているセッション)、そのセッションがユーザー/アプリケーションの優先ゾーン以外のゾーンにあるVDAで実行されている場合、システムは新しいセッションを作成する可能性があります。これにより、そのユーザーのセッション要件にとって優先度の低いゾーンのセッションに再接続するよりも、正しいゾーンでの起動(利用可能な容量がある場合)が満たされます。
到達できなくなった孤立セッションを防ぐため、既存の切断されたセッションへの再接続は、たとえそれが非優先ゾーンにある場合でも許可されます。
起動を満たすためのセッションの望ましさの順序は次のとおりです。
-
優先ゾーン内の既存のセッションに再接続します。
-
優先ゾーン以外のゾーンにある既存の切断されたセッションに再接続します。
-
優先ゾーンで新しいセッションを開始します。
-
優先ゾーン以外のゾーンにある接続済みの既存セッションに再接続します。
-
優先ゾーン以外のゾーンで新しいセッションを開始します。
その他のゾーン優先度に関する考慮事項
-
ユーザーグループ(セキュリティグループなど)にホームゾーンを構成すると、そのグループのユーザー(直接的または間接的なメンバーシップを通じて)は指定されたゾーンに関連付けられます。ただし、ユーザーは複数のセキュリティグループのメンバーになることができ、そのため、他のグループメンバーシップを通じて異なるホームゾーンが構成されている場合があります。このような場合、そのユーザーのホームゾーンの決定は曖昧になる可能性があります。
ユーザーがグループメンバーシップを通じて取得されていない構成済みのホームゾーンを持っている場合、そのゾーンがゾーン優先度に使用されます。グループメンバーシップを通じて取得されたゾーン関連付けはすべて無視されます。
ユーザーがグループメンバーシップのみを通じて取得した複数の異なるゾーン関連付けを持っている場合、ブローカーはゾーンの中からランダムに選択します。ブローカーがこの選択を行うと、そのゾーンは、ユーザーのグループメンバーシップが変更されるまで、以降のセッション起動に使用されます。
-
ユーザーロケーションゾーンの優先度では、エンドポイントデバイス上のCitrix Workspaceアプリが、そのデバイスが接続しているCitrix Gatewayによって検出される必要があります。Citrix Gatewayは、IPアドレスの範囲を特定のゾーンに関連付けるように構成する必要があり、検出されたゾーンIDはStoreFrontを介してControllerに渡される必要があります。
ゾーン優先度について詳しくは、「ゾーン優先度の内部」を参照してください。
考慮事項、要件、およびベストプラクティス
-
ゾーンには、次の項目を配置できます。コントローラー、マシンカタログ、ホスト接続、ユーザー、およびアプリケーション。カタログがホスト接続を使用する場合、カタログと接続が同じゾーンにあることを確認してください。(ただし、低遅延で高帯域幅の接続が利用可能な場合は、異なるゾーンに配置できます。)
-
サテライトゾーンにアイテムを配置すると、サイトがそれらやそれらに関連する他のオブジェクトとどのようにやり取りするかに影響します。
-
コントローラーがサテライトゾーンに配置されると、それらのマシンは同じゾーン内のハイパーバイザーおよびVDAと良好な(ローカル)接続性を持つと想定されます。そのサテライトゾーン内のコントローラーは、それらのハイパーバイザーおよびVDAマシンの処理において、プライマリゾーン内のコントローラーよりも優先的に使用されます。
-
ハイパーバイザー接続がサテライトゾーンに配置されると、そのハイパーバイザー接続を介して管理されるすべてのハイパーバイザーもそのサテライトゾーンに存在すると想定されます。そのサテライトゾーン内のコントローラーは、そのハイパーバイザー接続との通信において、プライマリゾーン内のコントローラーよりも優先的に使用されます。
-
マシンカタログがサテライトゾーンに配置されると、そのカタログ内のすべてのVDAマシンがサテライトゾーンにあると想定されます。各VDAの初回登録後にコントローラーリストの自動更新メカニズムがアクティブになった後、サイトへの登録を試みる際には、プライマリゾーン内のコントローラーよりもローカルコントローラーが優先的に使用されます。
-
Citrix Gateway インスタンスもゾーンに関連付けることができます。これは、ここで説明されている他の要素のようにサイト構成の一部としてではなく、StoreFront Optimal HDX™ Routing 構成の一部として行われます。Citrix Gateway がゾーンに関連付けられている場合、そのゾーン内のVDAマシンへのHDX接続が使用される際に、優先的に使用されます。
-
-
本番サイトを作成し、最初のカタログとデリバリーグループを作成すると、すべての項目はプライマリゾーンに配置されます。この初期設定が完了するまでサテライトゾーンを作成することはできません。(空のサイトを作成した場合、プライマリゾーンには最初はコントローラーのみが含まれます。カタログとデリバリーグループを作成する前または後にサテライトゾーンを作成できます。)
-
1つ以上の項目を含む最初のサテライトゾーンを作成すると、サイト内の他のすべての項目はプライマリゾーンに残ります。
-
プライマリゾーンはデフォルトで「Primary」という名前ですが、その名前は変更できます。Web Studio はどのゾーンがプライマリゾーンであるかを示しますが、プライマリゾーンには識別しやすい名前を使用することがベストプラクティスです。プライマリゾーンを再割り当て(つまり、別のゾーンをプライマリゾーンにする)できますが、常にサイトデータベースと高可用性サーバーが含まれている必要があります。
-
サイトデータベースは常にプライマリゾーンに保持してください。
-
ゾーンを作成した後、後で項目をあるゾーンから別のゾーンに移動できます。この柔軟性により、近接して動作するのが最適な項目を分離できる可能性があります。たとえば、カタログ内のマシンを作成する接続(ホスト)とは異なるゾーンにカタログを移動すると、パフォーマンスに影響を与える可能性があります。項目をゾーン間で移動する前に、予期せぬ影響を考慮してください。カタログとそれが使用するホスト接続は同じゾーンに、または良好に接続されたゾーン(たとえば、低遅延で高帯域幅のネットワークを介して)に保持してください。
-
For optimal performance, install Web Studio and Director only in the primary zone. You can access Web Studio and Director from a satellite zone (for example, a satellite zone containing Controllers to use as failover if the primary zone becomes inaccessible) because they are web application.
-
Ideally, Citrix Gateway in a satellite zone is used for user connections coming into that zone from other zones or external locations, although you can use it for connections within the zone.
-
注意:ゾーン優先機能を使用するには、最低でもStoreFront 3.7およびCitrix Gateway 11.0-65.xを使用している必要があります。
接続品質の制限
サテライトゾーンのコントローラーは、サイトデータベースと直接SQL対話を行います。これにより、サテライトゾーンとサイトデータベースを含むプライマリゾーン間のリンクの品質にいくつかの制限が課されます。具体的な制限は、サテライトゾーンに展開されているVDAの数と、それらのVDA上のユーザーセッションの数に比例します。したがって、VDAとセッションの数が少ないサテライトゾーンは、VDAとセッションの数が多いサテライトゾーンよりも、データベースへの接続品質が低い場合でも機能できます。
詳しくは、「待機時間とSQLブロッキングクエリの改善」を参照してください。
ブローカリングパフォーマンスに対する遅延の影響
ゾーンによってユーザーは遅延の大きいリンクを使用できますが、ローカルブローカーがある場合でも、追加の遅延はエンドユーザーエクスペリエンスに必然的に影響を与えます。ユーザーが行うほとんどの作業において、サテライトゾーンのコントローラーとサイトデータベース間のラウンドトリップによって引き起こされる遅延を経験します。
アプリケーションの起動では、セッションブローカリングプロセスがセッション起動要求を送信するのに適したVDAを特定する際に、余分な遅延が発生します。
ゾーンの作成と管理
フル管理者は、すべてのゾーン作成および管理タスクを実行できます。ただし、ゾーンの作成、編集、削除を許可するカスタムロールを作成することもできます。ゾーン間でアイテムを移動する場合、ゾーン関連の権限(ゾーン読み取り権限を除く)は必要ありませんが、移動するアイテムに対する編集権限が必要です。たとえば、カタログをあるゾーンから別のゾーンに移動するには、そのカタログに対する編集権限が必要です。詳しくは、「委任管理」を参照してください。
Citrix Provisioning™を使用する場合: Citrix Provisioningコンソールはゾーンを認識しないため、Web Studioを使用してサテライトゾーン用のカタログを作成することをお勧めします。Web Studioでカタログを作成し、正しいサテライトゾーンを指定します。その後、Citrix Provisioningコンソールを使用して、そのカタログ内のマシンをプロビジョニングします。(Citrix Provisioningウィザードを使用してカタログを作成した場合、カタログはプライマリゾーンに配置されます。後でWeb Studioを使用してサテライトゾーンに移動する必要があります。)
ゾーン名または説明の変更
-
Web Studioにサインインします。
-
左ペインでゾーンを選択します。
-
中央ペインでゾーンを選択し、アクションバーでゾーンの編集を選択します。
-
ゾーン名、説明、またはその両方を変更します。プライマリゾーンの名前を変更する場合は、そのゾーンがプライマリゾーンとして簡単に識別できることを確認してください。
-
保存または適用をクリックします。
項目をあるゾーンから別のゾーンに移動する
-
Web Studioにサインインします。
-
左ペインでゾーンを選択します。
-
中央ペインでゾーンを選択し、1つ以上の項目を選択します。
-
項目を移動先のゾーンにドラッグするか、アクションバーで項目の移動を選択し、移動先のゾーンを指定します。
確認メッセージには、選択した項目が一覧表示され、それらすべてを移動してもよろしいか尋ねられます。
注意: カタログがハイパーバイザーまたはその他のサービスへのホスト接続を使用する場合、カタログと接続の両方を同じゾーンに配置してください。そうしないと、パフォーマンスに影響が出る可能性があります。一方を移動する場合は、もう一方も移動してください。
ゾーンを削除する
ゾーンは、削除する前に空である必要があります。プライマリゾーンは削除できません。
-
Web Studioにサインインします。
-
左ペインでゾーンを選択します。
-
中央ペインでゾーンを選択します。
-
アクションバーからゾーンの削除を選択します。ゾーンが空でない場合(項目が含まれている場合)、それらの項目を移動するゾーンを選択するよう求められます。
-
削除を確認します。
ユーザーのホームゾーンを追加する
ユーザーのホームゾーンを構成することは、ユーザーをゾーンに追加するとも呼ばれます。
-
Web Studioにサインインします。
-
左ペインでゾーンを選択し、中央ペインでゾーンを選択します。
-
アクションバーでゾーンへのユーザーの追加を選択します。
-
ゾーンへのユーザーの追加ダイアログボックスで、追加をクリックし、ゾーンに追加するユーザーとユーザーグループを選択します。すでにホームゾーンを持つユーザーを指定した場合、メッセージが表示され、2つの選択肢が提示されます。はい = ホームゾーンを持たない指定したユーザーのみを追加します。いいえ = ユーザー選択ダイアログに戻ります。
-
OKをクリックします。
ホームゾーンが構成されているユーザーの場合、セッションをそのホームゾーンからのみ起動するように要求できます。
-
デリバリーグループを作成または編集します。
-
「ユーザー」ページで、「セッションは、構成されている場合、ユーザーのホームゾーンで起動する必要があります」チェックボックスをオンにします。
そのデリバリーグループのユーザーが起動するすべてのセッションは、そのユーザーのホームゾーン内のマシンから起動する必要があります。デリバリーグループ内のユーザーに構成済みのホームゾーンがない場合、この設定は無効です。
ユーザーのホームゾーンを削除する
この手順は、ゾーンからユーザーを削除することとも呼ばれます。
-
Web Studioにサインインします。
-
左側のペインで「ゾーン」を選択し、中央のペインでゾーンを選択します。
-
アクションバーで「ゾーンからユーザーを削除」を選択します。
-
「ゾーンにユーザーを追加」ダイアログボックスで、「削除」をクリックし、ゾーンから削除するユーザーとグループを選択します。この操作では、ユーザーはゾーンからのみ削除されます。それらのユーザーは、所属するデリバリーグループおよびアプリケーショングループに残ります。
-
プロンプトが表示されたら、削除を確認します。
アプリケーションのホームゾーンを管理する
アプリケーションのホームゾーンを構成することは、アプリケーションをゾーンに追加することとも呼ばれます。デフォルトでは、マルチゾーン環境では、アプリケーションにホームゾーンはありません。
アプリケーションのホームゾーンは、アプリケーションのプロパティで指定されます。アプリケーションをグループに追加するとき、または後でアプリケーションのプロパティを構成できます。
-
アプリケーションの追加後にアプリケーションのプロパティを変更するには、左側のペインで「アプリケーション」を選択します。アプリケーションを選択し、アクションバーで「アプリケーションプロパティの編集」を選択します。
-
アプリケーションにホームゾーンを設定する場合:
-
選択したゾーンを使用して決定するラジオボタンを選択し、ゾーンを選択します。
-
アプリケーションを、選択したゾーンからのみ(他のゾーンからは起動しないように)起動する場合は、ゾーン選択の下にあるチェックボックスをオンにします。
-
-
アプリケーションにホームゾーンを設定しない場合:
-
ホームゾーンを構成しないラジオボタンを選択します。
-
このアプリケーションを起動する際に、ブローカーが構成済みのユーザーゾーンを考慮しないようにする場合は、ラジオボタンの下にあるチェックボックスをオンにします。この場合、アプリケーションのホームゾーンもユーザーのホームゾーンも、このアプリケーションをどこで起動するかを決定するために使用されません。
-
ゾーンの指定を含むその他のアクション
少なくとも1つのサテライトゾーンを作成した後、ホスト接続を追加するか、カタログを作成する際にゾーンを指定できます。
通常、プライマリゾーンがデフォルトです。Machine Creation Services™を使用してカタログを作成する場合、ホスト接続用に構成されたゾーンが自動的に選択されます。
サイトにサテライトゾーンが含まれていない場合、プライマリゾーンが想定され、ゾーン選択ボックスは表示されません。