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