ゾーン
注:
バージョン 2511 以降、Citrix Web Studio (Web ベース) は Citrix Virtual Apps and Desktops™ の唯一の管理コンソールです。Citrix Studio (MMC ベース) はインストーラーから削除されました。この記事は 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 つ以上のコントローラーをローカルにインストールできますが、必須ではありません。
サイトに構成されているコントローラーの数は、サイト自体に新しいコントローラーを追加するなどの一部の操作のパフォーマンスに影響を与える可能性があります。これを避けるため、Citrix Virtual Apps または Citrix Virtual Desktops™ サイトのゾーン数を 50 以下に制限することをお勧めします。
ゾーンのネットワーク遅延が 250 ミリ秒 RTT を超える場合は、ゾーンではなく複数のサイトを展開することをお勧めします。
この記事全体を通して、「ローカル」という用語は、議論されているゾーンを指します。たとえば、「VDA がローカルコントローラーに登録する」とは、VDA が配置されているゾーン内のコントローラーに VDA が登録することを意味します。
このリリースでのゾーンは、XenApp バージョン 6.5 以前のゾーンと似ていますが、同一ではありません。たとえば、このゾーンの実装では、データコレクターはありません。サイト内のすべてのコントローラーは、プライマリゾーン内の 1 つのサイトデータベースと通信します。また、このリリースではフェイルオーバーゾーンと優先ゾーンの動作が異なります。
ゾーンの種類
サイトには常に 1 つのプライマリゾーンがあります。オプションで 1 つ以上のサテライトゾーンを持つこともできます。サテライトゾーンは、災害復旧、地理的に離れたデータセンター、支社、クラウド、またはクラウド内のアベイラビリティゾーンに使用できます。
プライマリゾーン:
プライマリゾーンには、デフォルト名「Primary」が付けられています。このゾーンには、SQL Server サイトデータベース (および使用されている場合は高可用性 SQL サーバー)、Web Studio、Director、Citrix StoreFront™、Citrix License Server、および Citrix Gateway が含まれます。サイトデータベースは常にプライマリゾーンに保持してください。
プライマリゾーンには、冗長性のために少なくとも 2 つのコントローラーが必要です。プライマリゾーンには、データベースおよびインフラストラクチャと密接に結合されたアプリケーションを持つ VDA を配置できます。
サテライトゾーン:
サテライトゾーンには、1 つ以上の VDA、コントローラー、StoreFront サーバー、および Citrix Gateway サーバーが含まれます。通常の運用では、サテライトゾーン内のコントローラーはプライマリゾーン内のデータベースと直接通信します。
サテライトゾーン、特に大規模なゾーンには、そのゾーンのマシンをプロビジョニングおよび保存するために使用されるハイパーバイザーが含まれる場合もあります。サテライトゾーンを構成するときは、ハイパーバイザーまたはその他のサービス接続を関連付けることができます。(その接続を使用するカタログが同じゾーンにあることを確認してください。)
サイトは、独自のニーズと環境に基づいて、異なる構成のサテライトゾーンを持つことができます。次の図は、プライマリゾーンとサテライトゾーンの例を示しています。
図では、次のようになります。
-
プライマリゾーン: 2 つのコントローラー、Web Studio、Director、StoreFront、License Server、およびサイトデータベース (高可用性 SQL Server 展開を含む) が含まれます。プライマリゾーンには、複数の VDA と Citrix Gateway も含まれます。
-
サテライトゾーン1: コントローラーを持つVDA サテライトゾーン1には、コントローラー、VDA、およびStoreFrontサーバーが含まれています。このサテライトゾーンのVDAは、ローカルコントローラーに登録されます。ローカルコントローラーは、プライマリゾーンのサイトデータベースおよびライセンスサーバーと通信します。
WANに障害が発生した場合、ローカルホストキャッシュ機能により、サテライトゾーンのコントローラーは、そのゾーン内のVDAへの接続の仲介を継続できます。このような展開は、従業員がローカルのStoreFrontサイトとローカルコントローラーを使用してローカルリソースにアクセスするオフィスで効果的です。
-
サテライトゾーン2: 冗長コントローラーを持つVDA サテライトゾーン2には、2つのコントローラー、VDA、およびStoreFrontサーバーが含まれています。これは最も回復力のあるゾーンタイプであり、WANとローカルコントローラーのいずれかの同時障害に対する保護を提供します。
VDAの登録とコントローラーのフェールオーバー
最小バージョン7.7のVDAを含むプライマリゾーンとサテライトゾーンで構成されるサイトでは、次のようになります。
- プライマリゾーンのVDAは、プライマリゾーンのコントローラーに登録されます。プライマリゾーンのVDAがサテライトゾーンのコントローラーに登録を試みることはありません。
- サテライトゾーンのVDAは、可能であればローカルコントローラーに登録されます。（これは優先コントローラーと見なされます。）ローカルコントローラーが利用できない場合（たとえば、これ以上VDA登録を受け入れられない、または障害が発生しているため）、VDAはプライマリゾーンのコントローラーに登録を試みます。この場合、サテライトゾーンのコントローラーが再び利用可能になったとしても、VDAはプライマリゾーンに登録されたままになります。サテライトゾーンのVDAが別のサテライトゾーンのコントローラーに登録を試みることはありません。
- コントローラーのVDA検出で自動更新が有効になっており、VDAのインストール中にコントローラーアドレスのリストを指定した場合、初期登録のためにそのリストからコントローラーがランダムに選択されます（コントローラーがどのゾーンにあるかに関わらず）。そのVDAを持つマシンが再起動された後、VDAはローカルゾーンのコントローラーへの登録を優先するようになります。
- サテライトゾーンのコントローラーに障害が発生した場合、可能であれば別のローカルコントローラーにフェールオーバーします。ローカルコントローラーが利用できない場合は、プライマリゾーンのコントローラーにフェールオーバーします。
- コントローラーをゾーンに出入りさせ、自動更新が有効になっている場合、両方のゾーンのVDAは、どのコントローラーがローカルで、どのコントローラーがプライマリゾーンにあるかを示す更新されたリストを受け取るため、どのコントローラーに登録し、どのコントローラーから接続を受け入れるかを知ることができます。
- カタログを別のゾーンに移動すると、そのカタログ内のVDAは、カタログを移動したゾーンのコントローラーに再登録されます。（カタログを別のゾーンに移動するときは、このゾーンと関連するホスト接続があるゾーンが適切に接続されていることを確認してください。帯域幅が制限されているか、高遅延である場合は、ホスト接続を関連するマシンカタログを含む同じゾーンに移動してください。）
プライマリゾーンのすべてのコントローラーに障害が発生した場合：
- Web Studioはサイトに接続できません。
- プライマリゾーンのVDAへの接続は確立できません。
- プライマリゾーンのコントローラーが利用可能になるまで、サイトのパフォーマンスが低下します。
VDAバージョン7.7より前のバージョンを含むサイトの場合：
- サテライトゾーンのVDAは、ローカルゾーンとプライマリゾーンのコントローラーからの要求を受け入れます。（最小バージョン7.7のVDAは、他のサテライトゾーンのコントローラー要求を受け入れることができます。）
- サテライトゾーンのVDAは、プライマリゾーンまたはローカルゾーンのコントローラーにランダムに登録されます。（最小バージョン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に渡される必要があります。
ゾーン設定の詳細については、「Zone preference internals」を参照してください。
考慮事項、要件、およびベストプラクティス
-
次の項目をゾーンに配置できます: Controller、マシンカタログ、ホスト接続、ユーザー、およびアプリケーション。カタログがホスト接続を使用する場合、カタログと接続が同じゾーンにあることを確認してください。(ただし、低遅延で高帯域幅の接続が利用可能な場合は、異なるゾーンに配置することもできます。)
- 項目をサテライトゾーンに配置すると、サイトがそれらやそれらに関連する他のオブジェクトとどのように対話するかに影響します。
- Controllerがサテライトゾーンに配置されると、それらのマシンは同じゾーン内のハイパーバイザーおよびVDAとの良好な (ローカル) 接続性を持つと想定されます。そのサテライトゾーンのControllerは、それらのハイパーバイザーおよびVDAマシンを処理するために、プライマリゾーンのControllerよりも優先して使用されます。
- ハイパーバイザー接続がサテライトゾーンに配置されると、そのハイパーバイザー接続を介して管理されるすべてのハイパーバイザーもそのサテライトゾーンに存在すると想定されます。そのサテライトゾーンのControllerは、そのハイパーバイザー接続と通信する際に、プライマリゾーンのControllerよりも優先して使用されます。
- マシンカタログがサテライトゾーンに配置されると、そのカタログ内のすべてのVDAマシンがサテライトゾーンにあると想定されます。各VDAの最初の登録後にControllerリストの自動更新メカニズムがアクティブになった後、サイトへの登録を試みる際に、プライマリゾーンのControllerよりもローカルControllerが優先して使用されます。
- Citrix Gatewayインスタンスもゾーンに関連付けることができます。これは、ここで説明されている他の要素のようにサイト構成の一部としてではなく、StoreFront Optimal HDX™ルーティング構成の一部として行われます。Citrix Gatewayがゾーンに関連付けられている場合、そのゾーン内のVDAマシンへのHDX接続が使用されるときに、そのCitrix Gatewayが優先的に使用されます。
-
本番サイトを作成し、最初のカタログとDelivery Groupを作成すると、すべての項目はプライマリゾーンに配置されます。この初期設定が完了するまで、サテライトゾーンを作成することはできません。(空のサイトを作成した場合、プライマリゾーンには最初はControllerのみが含まれます。カタログとDelivery Groupを作成する前または後にサテライトゾーンを作成できます。)
-
1つ以上の項目を含む最初のサテライトゾーンを作成すると、サイト内の他のすべての項目はプライマリゾーンに残ります。
-
プライマリゾーンはデフォルトで「Primary」という名前ですが、その名前を変更できます。Web Studioはどのゾーンがプライマリゾーンであるかを示しますが、プライマリゾーンには簡単に識別できる名前を使用することがベストプラクティスです。プライマリゾーンを再割り当てする (つまり、別のゾーンをプライマリゾーンにする) ことはできますが、常にサイトデータベースと高可用性サーバーが含まれている必要があります。
-
サイトデータベースは常にプライマリゾーンに保持します。
-
ゾーンを作成した後、後でアイテムをあるゾーンから別のゾーンに移動できます。この柔軟性により、近接して最も効果的に機能するアイテムを分離できる可能性があります。たとえば、カタログ内のマシンを作成する接続（ホスト）とは異なるゾーンにカタログを移動すると、パフォーマンスに影響を与える可能性があります。アイテムをゾーン間で移動する前に、意図しない潜在的な影響を考慮してください。カタログとそれが使用するホスト接続は、同じゾーン内、または適切に接続されたゾーン（たとえば、低遅延で高帯域幅のネットワーク経由）に保持してください。
-
最適なパフォーマンスを得るには、Web StudioとDirectorはプライマリゾーンにのみインストールしてください。Web StudioとDirectorはWebアプリケーションであるため、サテライトゾーン（たとえば、プライマリゾーンにアクセスできなくなった場合のフェイルオーバーとして使用するControllerを含むサテライトゾーン）からアクセスできます。
-
理想的には、サテライトゾーンのCitrix Gatewayは、他のゾーンまたは外部の場所からそのゾーンに入ってくるユーザー接続に使用されますが、ゾーン内の接続にも使用できます。
- 注意：ゾーン優先機能を使用するには、StoreFront 3.7およびCitrix Gateway 11.0-65.x以降を使用している必要があります。
接続品質の制限
サテライトゾーンのControllerは、サイトデータベースと直接SQLインタラクションを実行します。これにより、サテライトゾーンとサイトデータベースを含むプライマリゾーン間のリンクの品質にいくつかの制限が課せられます。具体的な制限は、サテライトゾーンに展開されているVDAの数と、それらのVDA上のユーザーセッションの数に比例します。したがって、VDAとセッションの数が少ないサテライトゾーンは、VDAとセッションの数が多いサテライトゾーンよりも、データベースへの接続品質が低い場合でも機能できます。
詳細については、「待機時間とSQLブロッキングクエリの改善」を参照してください。
待機時間がブローカリングパフォーマンスに与える影響
ゾーンによってユーザーが高遅延リンク上にいても、ローカルブローカーが存在すれば問題ありませんが、追加の待機時間は必然的にエンドユーザーエクスペリエンスに影響を与えます。ユーザーが行うほとんどの作業において、サテライトゾーンのControllerとサイトデータベース間のラウンドトリップによって引き起こされる遅延を経験します。
アプリケーションの起動では、セッションブローカリングプロセスがセッション起動リクエストを送信するのに適したVDAを特定する際に、追加の遅延が発生します。
ゾーンの作成と管理
フル管理者であれば、すべてのゾーン作成および管理タスクを実行できます。ただし、ゾーンの作成、編集、または削除を許可するカスタムロールを作成することもできます。ゾーン間でアイテムを移動するのにゾーン関連の権限は必要ありません（ゾーン読み取り権限を除く）。ただし、移動するアイテムに対する編集権限が必要です。たとえば、カタログをあるゾーンから別のゾーンに移動するには、そのカタログに対する編集権限が必要です。詳細については、「委任管理」を参照してください。
Citrix Provisioning™を使用する場合： Citrix Provisioningコンソールはゾーンを認識しないため、サテライトゾーン用のカタログを作成するにはWeb Studioを使用することをお勧めします。Web Studioでカタログを作成し、正しいサテライトゾーンを指定します。次に、Citrix Provisioningコンソールを使用して、そのカタログ内のマシンをプロビジョニングします。（Citrix Provisioningウィザードを使用してカタログを作成した場合、カタログはプライマリゾーンに配置されます。後でWeb Studioを使用してサテライトゾーンに移動する必要があります。）
ゾーンの作成
- Web Studioにサインインします。
- 左ペインで [ゾーン] を選択します。
- アクションバーで [ゾーンの作成] を選択します。
- ゾーンの名前と説明（オプション）を入力します。名前はサイト内で一意である必要があります。
- 新しいゾーンに配置するアイテムを選択します。選択可能なアイテムのリストをフィルタリングまたは検索できます。空のゾーンを作成することもできます。その場合は、何もアイテムを選択しないでください。
- [保存] をクリックします。
この方法の代替として、Web Studioで1つ以上のアイテムを選択し、アクションバーで [ゾーンの作成] を選択することもできます。
ゾーン名または説明の変更
- Web Studioにサインインします。
- 左ペインで [ゾーン] を選択します。
- 中央ペインでゾーンを選択し、アクションバーで [ゾーンの編集] を選択します。
- ゾーン名、説明、またはその両方を変更します。プライマリゾーンの名前を変更する場合は、そのゾーンがプライマリゾーンとして容易に識別できることを確認してください。
- [保存] または [適用] をクリックします。
アイテムをゾーン間で移動
- Web Studioにサインインします。
- 左ペインで [ゾーン] を選択します。
- 中央ペインでゾーンを選択し、1つ以上のアイテムを選択します。
- アイテムを目的のゾーンにドラッグするか、アクションバーで [アイテムの移動] を選択し、移動先のゾーンを指定します。
確認メッセージには、選択したアイテムが一覧表示され、それらすべてを移動してもよろしいか尋ねられます。
注意： カタログがハイパーバイザーまたはその他のサービスへのホスト接続を使用する場合、カタログと接続の両方を同じゾーンに配置してください。そうしないと、パフォーマンスに影響が出る可能性があります。一方を移動する場合は、もう一方も移動してください。
ゾーンの削除
ゾーンを削除するには、ゾーンが空である必要があります。プライマリゾーンは削除できません。
- Web Studio にサインインします。
- 左側のペインで [ゾーン] を選択します。
- 中央のペインでゾーンを選択します。
- アクションバーから [ゾーンの削除] を選択します。ゾーンが空でない場合 (項目が含まれている場合)、それらの項目を移動するゾーンを選択するよう求められます。
- 削除を確認します。
ユーザーのホームゾーンの追加
ユーザーのホームゾーンの構成は、ゾーンへのユーザーの追加 とも呼ばれます。
- Web Studio にサインインします。
- 左側のペインで [ゾーン] を選択し、中央のペインでゾーンを選択します。
- アクションバーで [ゾーンにユーザーを追加] を選択します。
- [ゾーンにユーザーを追加] ダイアログボックスで、[追加] をクリックし、ゾーンに追加するユーザーとユーザーグループを選択します。すでにホームゾーンを持つユーザーを指定した場合、メッセージが表示され、2つの選択肢が提示されます: [はい] = ホームゾーンを持たない指定したユーザーのみを追加します。[いいえ] = ユーザー選択ダイアログに戻ります。
- [OK] をクリックします。
ホームゾーンが構成されているユーザーの場合、セッションをホームゾーンからのみ起動するように要求できます。
- デリバリーグループを作成または編集します。
- [ユーザー] ページで、[セッションをユーザーのホームゾーンで起動することを要求する (構成されている場合)] チェックボックスをオンにします。
そのデリバリーグループ内のユーザーが起動するすべてのセッションは、そのユーザーのホームゾーン内のマシンから起動する必要があります。デリバリーグループ内のユーザーにホームゾーンが構成されていない場合、この設定は無効です。
ユーザーのホームゾーンの削除
この手順は、ゾーンからのユーザーの削除とも呼ばれます。
- Web Studio にサインインします。
- 左側のペインで [ゾーン] を選択し、中央のペインでゾーンを選択します。
- アクションバーで [ゾーンからユーザーを削除] を選択します。
- [ゾーンにユーザーを追加] ダイアログボックスで、[削除] をクリックし、ゾーンから削除するユーザーとグループを選択します。この操作では、ゾーンからのみユーザーが削除されます。これらのユーザーは、所属するデリバリーグループおよびアプリケーショングループに残ります。
- プロンプトが表示されたら削除を確認します。
アプリケーションのホームゾーンの管理
アプリケーションのホームゾーンの構成は、ゾーンへのアプリケーションの追加とも呼ばれます。デフォルトでは、マルチゾーン環境では、アプリケーションにホームゾーンはありません。
アプリケーションのホームゾーンは、アプリケーションのプロパティで指定されます。アプリケーションをグループに追加するとき、または後でアプリケーションのプロパティを構成できます。
- デリバリーグループの作成、アプリケーショングループの作成、または既存のグループへのアプリケーションの追加時に、ウィザードの [アプリケーション] ページで [プロパティ] を選択します。
- アプリケーションの追加後にアプリケーションのプロパティを変更するには、左側のペインで [アプリケーション] を選択します。アプリケーションを選択し、アクションバーで [アプリケーションプロパティの編集] を選択します。
アプリケーションのプロパティ/設定の [ゾーン] ページで:
- アプリケーションにホームゾーンを設定する場合:
- [選択したゾーンを使用して決定する] ラジオボタンを選択し、ゾーンを選択します。
- アプリケーションを、選択したゾーンからのみ起動し (他のゾーンからは起動しない)、ゾーン選択の下にあるチェックボックスをオンにします。
- アプリケーションにホームゾーンを設定しない場合:
- [ホームゾーンを構成しない] ラジオボタンを選択します。
- このアプリケーションを起動するときに、ブローカーが構成済みのユーザーゾーンを考慮しないようにする場合は、ラジオボタンの下にあるチェックボックスをオンにします。この場合、アプリケーションまたはユーザーのホームゾーンのいずれも、このアプリケーションを起動する場所を決定するために使用されません。
ゾーンの指定を含むその他の操作
少なくとも1つのサテライトゾーンを作成した後、ホスト接続を追加するとき、またはカタログを作成するときにゾーンを指定できます。
通常、プライマリゾーンがデフォルトです。Machine Creation Services™ を使用してカタログを作成する場合、ホスト接続用に構成されているゾーンが自動的に選択されます。
サイトにサテライトゾーンが含まれていない場合、プライマリゾーンが想定され、ゾーン選択ボックスは表示されません。