Product Documentation

StoreFrontの展開計画

Dec 15, 2016

StoreFrontでは、Microsoftインターネットインフォメーションサービス(IIS)上で動作するMicrosoft .NETテクノロジーを使用して、リソースを集約してユーザーに配信するエンタープライズアプリケーションストアを提供します。 XenDesktop、XenApp、およびApp Controller展開環境にStoreFrontを統合して、ユーザーにデスクトップおよびアプリケーションに対する単一のセルフサービスアクセスポイントを提供できます。

StoreFrontは、次のコアコンポーネントにより構成されています。

  • 認証サービスにより、ユーザーがMicrosoft Active Directoryで認証され、ユーザーが再ログオンすることなくデスクトップやアプリケーションにアクセスできるようになります。 詳しくは、「ユーザー認証」を参照してください。
  • ストアには、XenDesktop、XenApp、およびApp Controllerで配信されるデスクトップやアプリケーションが列挙および集約されます。 ユーザーは、Citrix Receiver、Citrix Receiver for Webサイト、デスクトップアプライアンスサイト、XenApp ServicesサイトのURL経由でストアにアクセスします。 詳しくは、「ユーザーアクセスオプション」を参照してください。
  • サブスクリプションストアサービスにより、ユーザーのアプリケーションサブスクリプションの詳細が記録され、ユーザーが複数のデバイスを使用しても一貫性のあるユーザーエクスペリエンスが提供されます。 ユーザーのエクスペリエンスの向上について詳しくは、「ユーザーエクスペリエンスの最適化」を参照してください。

StoreFrontでは、単一サーバーの展開環境または複数サーバーの展開環境を構成できます。 複数サーバーの環境では、処理能力だけでなく可用性も向上します。 StoreFrontのモジュラーアーキテクチャにより、構成情報やユーザーのアプリケーションサブスクリプションの詳細がサーバーグループ内のすべてのサーバー上に格納され、複製されます。 このため、何らかの理由でいずれかのStoreFrontサーバーが停止しても、ユーザーはほかのサーバーを使用してストアにアクセスできます。 停止したサーバーが動作を再開してサーバーグループに再接続すると、構成およびサブスクリプションのデータが自動的に更新されます。 サブスクリプションデータは、サーバーがオンラインに復帰したときに更新されますが、オフライン中の更新が反映されていない場合は、管理者が構成の変更を反映させる必要があります。 ハードウェア障害などによりサーバーの交換が必要な場合でも、新しいサーバーにStoreFrontをインストールして既存のサーバーグループに追加するだけです。 これにより、新しいサーバーが自動的に構成され、最新のアプリケーションサブスクリプションデータが同期されます。

次の図は、一般的なStoreFront展開環境を示しています。
localized image

負荷分散

複数サーバーの展開環境の場合は、NetScalerまたはWindowsのネットワーク負荷分散などによる外部の負荷分散機能が必要です。 負荷分散環境を構成してサーバー間のフェールオーバーを有効にして、耐障害性を向上できます。 NetScalerを使用した負荷分散について詳しくは、「負荷分散」を参照してください。 Windowsのネットワーク負荷分散について詳しくは、http://technet.microsoft.com/ja-jp/library/hh831698.aspxを参照してください。

何千ものユーザーが使用したり、特定の時間帯に多くのユーザーのログオンが集中するなど、高負荷状態が発生したりする展開環境では、StoreFrontからXenDesktopサイトやXenAppファームへの要求を負荷分散することをお勧めします。 この場合、NetScalerなど、XMLの監視機能やセッションパーシステンス機能を持つロードバランサーを使用してください。

SSL終了ロードバランサーを展開するか、またはトラブルシューティングの必要がある場合は、PowerShellコマンドレットのSet-STFWebReceiverCommunicationを使用できます。

構文:

Set-STFWebReceiverCommunication [-WebReceiverService] <WebReceiverService> [[-Loopback] <On | Off | OnUsingHttp>] [[-LoopbackPortUsingHttp] <Int32>]

有効な値は以下のとおりです。

  • On – 新しいCitrix Receiver for Webサイトのデフォルト値です。 Citrix Receiver for Webはスキーマ(HTTPSまたはHTTP)およびベースURLのポート番号を使用しますが、ホストをループバックIPアドレスと置き換えてStoreFront Servicesと通信します。 これは単一サーバー展開および非SSL終了ロードバランサーがある展開で機能します。
  • OnUsingHttp - Citrix Receiver for WebはHTTPおよびループバックIPアドレスを使用してStoreFront Servicesと通信します。 SSL終了ロードバランサーを使用している場合はこの値を選択します。 また、デフォルトのポート80でない場合は、HTTPポートも指定する必要があります。
  • Off - これはループバックをオフにし、Citrix Receiver for WebはStoreFrontベースURLを使ってStoreFront Servicesと通信します。 インプレースアップグレードを実行する場合は、既存の展開に対する混乱を避けるため、これがデフォルトの値となります。

たとえば、SSL終了ロードバランサーを使用していて、HTTPに対してポート81を使用するようにIISが構成され、Citrix Receiver for Webサイトのパスが/Citrix/StoreWebの場合, 次のコマンドを使ってCitrix Receiver for Webサイトを構成できます。

$wr = Get-STFWebReceiverService -VirtualPath /Citrix/StoreWeb 
Set-STFWebReceiverCommunication -WebReceiverService $wr -Loopback OnUsingHttp -LoopbackPortUsingHttp 81


Citrix Receiver for WebおよびStoreFront Services間のネットワークトラフィックをキャプチャするには、ロープバックをオフにして、Fiddlerのような任意のWebプロキシツールを使用する必要があります。

Active Directoryに関する注意事項

単一サーバーの展開では、ドメインに参加していないサーバーにStoreFrontをインストールできます(ただし利用できない機能があります)。それ以外の場合、各StoreFrontサーバーは、XenAppまたはXenDesktopサイト/ファームに対する認証の委任を有効にしない限り、ユーザーアカウントが属しているActive Directoryドメイン、またはそのドメインと信頼関係があるドメインに属している必要があります。 同一デリバリーグループで使用するすべてのStoreFrontサーバーが同じドメインに属している必要があります。

ユーザー接続

実務環境では、StoreFrontとユーザーデバイスの間の通信を保護するためにHTTPSを使用することをお勧めします。 HTTPSを使用するには、認証サービスおよびストアをホストするIISインスタンスで、HTTPSを有効にする必要があります。 IISでHTTPSが構成されていない場合、StoreFrontの通信にHTTPが使用されます。 IISでHTTPSが適切に構成されている場合は、必要に応じていつでもHTTPをHTTPSに変更できます。

社内ネットワーク外からのStoreFrontへのアクセスを有効にする場合、安全な接続をリモートユーザーに提供するにはNetScaler Gatewayが必要です。 NetScaler Gatewayを社内ネットワークの外にNetScaler Gatewayを配置して、ファイアウォールで公共のネットワークと内部ネットワークの両方からそのNetScaler Gatewayを分離します。 NetScaler Gatewayが、StoreFrontサーバーを含んでいるActive Directoryフォレストにアクセスできることを確認してください。

複数のインターネットインフォメーションサービス(IIS)Webサイト

StoreFrontでは、Windowsサーバーごとに異なるIIS Webサイトで異なるストアを展開できます。これによって、ストアごとにそれぞれホスト名と証明書のバインドを持つことができます。

デフォルトのWebサイトに加えて、2つのWebサイト作成から始めます。 IISで複数のWebサイトを作成してから、PowerShell SDKを使用して、IIS WebサイトにそれぞれStoreFront展開環境を作成します。 IISでのWebサイトの作成方法について詳しくは、How to set up your first IIS Websiteを参照してください。

注:StoreFront管理コンソールとPowerShellコンソールを同時に開くことはできません。 StoreFront管理コンソールを閉じてからPowerShellコンソールを開いてください。 同様に、PowerShellのすべてのインスタンスを閉じてからStoreFront管理コンソールを開いてください。

例:2つのIIS Webサイト環境(1つはアプリケーション、1つはデスクトップ)を作成します。

1. Add-STFDeployment -SiteID 1 -HostBaseURL "https://www.storefront.app.com"
2. Add-STFDeployment -SiteID 2 -HostBaseURL "https://www.storefront.desktop.com"

StoreFrontは、複数のサイトを検出すると管理コンソールを無効にし、メッセージを表示します。

詳しくは、「インストールおよび構成する前に」を参照してください。

スケーラビリティ

単一のStoreFrontサーバーグループでサポートされるCitrix Receiverユーザーの数は、使用するハードウェアとユーザーアクティビティにより異なります。 ユーザーがログオンして1つのリソースを開始するシミュレーショにおいては、100個の公開アプリケーションが列挙され、基になるデュアルIntel Xeon L5520 2.27Ghzプロセッササーバーで実行中の2つの仮想CPUの最小推奨仕様である単一のStoreFrontサーバーが、1時間あたり最大30,000のユーザー接続を有効にするとされます。

グループ内に同様の2つの構成サーバーがあるサーバーグループでは、1時間あたり最大で60,000のユーザー接続を有効にするとされます。3つのノードでは1時間あたり最大で90,000の接続、4つのノードでは1時間当たり最大で120,000の接続、5つのノードでは1時間あたり最大で150,000の接続、6つのノードでは1時間当たり最大で175,000の接続となります。

また、1時間当たり最大で55,000のユーザー接続を有効にする4つの仮想CPUと1時間当たり80,000の接続を有効にする8つの仮想CPUを使って、システムにより多くの仮想CPUを割り当てて単一のStoreFrontサーバーのスループットを増やすこともできます。

各サーバーの最小推奨メモリ割り当ては4GBです。 Citrix Receiver for Webを使用する場合、基本のメモリ割り当てに加えてリソースごと、ユーザーごとに700バイトを追加で割り当てます。 Citrix Receiver for Webを使用する場合、リソースごとおよびユーザーごとに、このバージョンのStoreFrontで基本の4GBメモリ要件に加えて、追加の700バイトを使用できるよう環境を設計します。

実際のユーザーアクティビティは上記シミュレーションとは異なるため、サーバーでサポートされるユーザー接続数は異なります。 

重要:サーバーグループ内のすべてのサーバーは同じ場所に配置されている必要があります。 StoreFrontサーバーグループ内でオペレーティングシステムのバージョンやロケール設定が異なるサーバーを混在させることはサポートされていません。

タイムアウトに関する注意事項

場合によっては、StoreFrontストアと接続先のサーバーの間でネットワークなどの問題が発生し、ユーザーにとっては遅延や障害が発生する可能性があります。 これを回避するために、管理者はストアのタイムアウト設定を変更できます。 タイムアウトの設定を短く指定すると、StoreFrontはサーバーとの接続試行をいつまでも繰り返さずに別のサーバーに接続しようとします。 この設定は、フェールオーバーを目的として複数のサーバーを構成している場合などに便利です。

タイムアウトを長く設定すると、StoreFrontは1つのサーバーからの応答をその期間だけ待機します。 この設定は、ネットワークやサーバーの信頼性が保証されず、遅延がよく発生する環境でメリットがあります。

Citrix Receiver for Webにもタイムアウトの設定があり、Citrix Receiver for Webサイトがストアからの応答を待つ時間を制御します。 このタイムアウト値を変更するときは、ストアのタイムアウト以上の時間を設定します。 タイムアウトの時間を長くすると耐障害性が向上しますが、ユーザーは長い遅延を経験する可能性があります。 タイムアウトの時間を短くすると、ユーザーにとっての遅延は減りますが、接続の失敗が増える可能性があります。

タイムアウトの設定について詳しくは、「通信のタイムアウト期間およびサーバー再試行回数の構成」および「通信のタイムアウト期間および再試行回数の構成」を参照してください。