XenApp and XenDesktop

Framehawk

Framehawkは、ブロードバンドワイヤレス接続(Wi-Fiおよび4G/LTEセルラーネットワーク)でのモバイルワーカー向けディスプレイリモートテクノロジです。Framehawkはスペクトル干渉や 多重伝搬による課題を克服し、仮想アプリおよびデスクトップのユーザーに、滑らかで対話的なユーザーエクスペリエンスを提供しています。Framehawkは、少量のパケット損失がユーザーエクスペリエンスを低下させる可能性がある、長距離(低速)ブロードバンドネットワーク接続を利用しているユーザーに適している場合があります。このユースケースではアダプティブトランスポートを使用することをお勧めします。詳しくは、「アダプティブトランスポート」を参照してください。

Citrixポリシーテンプレートを使用し、組織に適した方法で、一連のユーザーとアクセスシナリオ用にFramehawkを実装します。Framehawkは、ラップトップやタブレットなど、単一画面でのモバイルユースケースをターゲットにしています。リアルタイムの対話的なパフォーマンスによってサーバーリソースの追加コストやブロードバンド接続の要件の正当性が証明される場合にFramehawkを使用します。

Framehawkはどのようにして円滑なユーザーエクスペリエンスを維持するか

Framehawkは人間の目をソフトウェアとして実装したもので、フレームバッファーの中に何があるかを確認したり、画面上のさまざまなコンテンツの種類を識別したりするものと考えてください。ユーザーにとって重要なものはなんでしょうか。画面エリアが動画や動くグラフィックのように急速に変化している場合は、多少のピクセルが失われていても、新しいデータですぐに上書きされますから、人間の目にとっては大したことではありません。

しかし、通知エリアやツールバーのアイコン、読み始めたいところまでユーザーがスクロールした後のテキストのように画面で変化しない領域は、人間の目が細部にまでこだわるところです。ユーザーは、このようなエリアではピクセルが完璧であることを期待します。0と1の観点で技術的に正確であることを目的としたプロトコルと異なり、Framehawkの目的は、このテクノロジーを使用する人にとって適切なものであることです。

Framehawkは、次世代QoS信号増幅器に加え、ワークロードをきめ細かく、より効率的に識別するための時間をベースにしたヒートマップを搭載しています。Framehawkはデータ圧縮に加えて、自動自己回復変換を使用します。また、データの再送信を回避し、クリック応答、線形性、一貫したリズムを維持します。損失の多いネットワーク接続では、Framehawkは補間を使って損失を隠すため、ユーザーは良好なイメージ品質を感じながら、流れるようなエクスペリエンスを楽しむことができます。さらに、Framehawkのアルゴリズムはさまざまな種類のパケット損失をインテリジェントに区別します。たとえば、ランダム損失(補正のためにさらにデータを送信)と輻輳損失(チャネルはすでに渋滞しているので追加のデータは送信しない)などです。

Citrix ReceiverのFramehawk Intent Engineは、上スクロールと下スクロール、ズーム、左または右方向への移動、読み込み、入力などの一般的な操作を区別します。エンジンはまた、共有ディクショナリを使用して、Virtual Delivery Agent(VDA)への通信を管理します。ユーザーが読もうとしているテキストは、高い品質で表示されなければなりません。スクロールはすばやく、スムーズであることが必要です。また、一時停止もできなければなりません。これにより、ユーザーはアプリケーションやデスクトップとのやりとりを常に制御できる立場でいられます。

ネットワーク接続のリズムを測定すること(自転車のチェーンの張力にたとえて「ギアリング」)により、Framehawkロジックはよりすばやく反応し、遅延の大きな接続でも優れたエクスペリエンスを実現します。特許を取得したこの独特なギアリングシステムから、ネットワーク接続について、継続的に最新のフィードバックが得られるため、Framehawkは帯域幅や遅延性、損失率の変化に即対応できます。

ThinwireとFramehawkを使用する場合の設計について考慮すべきこと

Thinwireは帯域幅効率において業界をリードし、さまざまなアクセス条件やネットワーク状態に適合していますが、信頼できるデータ通信を実現するためにTCPを使用しています。そのため、損失率の高いネットワークや過負荷状態のネットワークでは、パケットを再送信しなければならず、これがユーザーエクスペリエンスの低下につながります。Enlightened Data Transport(EDT)レイヤー上でThinwireを使用可能にすることによって、高遅延ネットワーク接続上でのTCP制限に対処しています。

Framehawkは、UDP(ユーザーデータグラムプロトコル)上に作成されたデータ転送レイヤーを使用します。Framehawkとその他のUDPベースのプロトコルのパフォーマンスを比較すればわかるとおり、UDPは、Framehawkで損失性を打開する方法のほんの一部に過ぎません。UDPは、Framehawkを際立たせる、人間を主体にした技術の重要な基礎を提供します。

Framehawkで必要な帯域幅

ブロードバンドワイヤレスの意味は、接続を共有するユーザーの人数、接続の品質、使用しているアプリなどいくつかの要素によって変わります。最適なパフォーマンスを上げるには、基本の4Mbpsまたは5Mbpsに、同時に使用しているユーザー1人につき約150Kbpsを加えることをCitrixではお勧めします。

Thinwireの帯域幅の推奨は、通常、基本の1.5Mbpsに、ユーザー1人につき150Kbpsを追加します。詳しくは、XenApp およびXenDesktop帯域幅ブログを参照してください。Thinwire over TCPでは3%のパケットが失われるため、有益なユーザーエクスペリエンスを保証するには、Framehawkよりもかなり大きな帯域幅が必要であることがわかります。

Thinwireは、ICAプロトコルのディスプレイリモート処理では、プライマリチャネルのままです。Framehawkは、デフォルトで無効になっています。Citrixは必要に応じて有効、無効を切り替えることで、組織のブロードバンドワイヤレスアクセスシナリオに対応することを推奨します。Framehawkは、Thinwireよりかなり多くのサーバーリソース(CPUとメモリ)を必要とすることに注意してください。

FramehawkおよびHDX 3D Pro

Framehawkでは、XenApp(サーバーOS)およびXenDesktop(デスクトップOS)アプリの両方で、すべてのHDX 3D Proのユースケースがサポートされます。遅延が400~500ミリ秒、パケット損失が1~2%の顧客環境で検証されました。そのため、AutoCADやSiemens NXなどの一般的な3Dモデリングアプリで素晴らしい対話操作性が得られます。これにより、移動中や、国外または劣悪なネットワーク環境で作業を行う場合も、より大規模なCADモデルを表示させて操作できるようになりました。(長距離ネットワーク接続上で3Dアプリケーションを提供する必要がある組織は、アダプティブトランスポートを使用することをお勧めします。詳しくは、「アダプティブトランスポート」を参照してください。)

この機能を有効にするために、追加の構成作業を行う必要はありません。VDAをインストールするとき、最初に3DProオプションを選択してください。

HDX 3D Pro

このように選択すると、HDXはCitrixビデオドライバーでなくGPUベンダーのビデオドライバーを使用します。通常のデフォルトであるSelective H.264エンコーディングを使用するアダプティブ表示でなく、Thinwire上の全画面H.264エンコーディングをデフォルトとします。

要件および考慮事項

Framehawkでは、少なくとも、VDA 7.6.300およびグループポリシー管理7.6.300が必要です。

エンドポイントには、少なくとも、Citrix Receiver for Windows 4.3.100、またはCitrix Receiver for iOS 6.0.1が必要です。

デフォルトではFramehawkでは、双方向のユーザーデータグラムプロトコル(UDP)ポート範囲(3224~3324)を使用してFramehawk表示チャネルデータがCitrix Receiverと交換されます。この範囲は、ポリシー設定Framehawk表示チャネルポートの範囲でカスタマイズできます。クライアントと仮想デスクトップの間の同時接続1つにつき、固有のポートが1つ必要になります。XenAppサーバーなど、マルチユーザーOS環境では、同時ユーザーセッションを上限までサポートするために、十分な数のポートを定義してください。VDIデスクトップのようなシングルユーザーOSでは、UDPポートを1つ定義すれば十分です。Framehawkは最初に定義されたポートを使用しようとし、範囲内で指定された最後のポートまで進みます。これは、NetScaler Gatewayを通過する場合と、StoreFrontサーバーへの直接内部接続の両方に当てはまります。

リモートアクセスの場合は、NetScaler Gatewayを必ず展開してください。デフォルトでは、NetScalerは、クライアントCitrix ReceiverとGatewayの間での暗号化通信のためにUDPポート443を使用します。双方向通信を確実に行うためには、外側のファイアウォールすべてで、このポートを開いておく必要があります。この機能はDatagram Transport Layer Security(DTLS)と呼ばれます。

注:

Framehawk/DTLS接続は、FIPSアプライアンスではサポートされません。

暗号化されたFramehawk接続は、NetScaler Gateway Version 11.0.62およびNetScaler Unified Gateway Version 11.0.64.34からサポートされています。

NetScaler High Availability(HA)は、XenAppおよびXenDesktop 7.12以降でサポートされています。

Framehawkを実装する前に、以下のベストプラクティスを検討してください:

  • セキュリティ管理者に問い合わせ、Framehawk用に定義されたUDPポートがファイアウォールで開かれていることを確認してください。インストール中にファイアウォールが自動的に構成されることはありません。
  • 多くの場合、NetScaler GatewayはDMZにインストールされ、外側だけでなく内側もファイアウォールで守られます。外側のファイアウォールでUDPポート443が開いていることを確認してください。デフォルトのポート範囲を使用している環境では、内側のファイアウォールでUDPポート3224~3324が開いていることを確認してください。

構成

注意:

大きなパケット損失が発生していると思われるユーザーについてのみ、Framehawkを有効化することが推奨されます。また、Framehawkを、サイト内にあるすべてのオブジェクトのユニバーサルポリシーとすることは推奨しません。

Framehawkは、デフォルトで無効になっています。この機能を有効にすると、ユーザーのグラフィックスおよび入力に対して、サーバーでFramehawkの使用が試みられます。何らかの理由で前提条件が満たされていない場合、接続はデフォルトモード(Thinwire)で確立されます。

Framehawkに影響を与えるポリシー設定は以下のとおりです:

  • Framehawkディスプレイチャネル:この機能を有効または無効にします。
  • Framehawkディスプレイチャネルのポート範囲:ユーザーデバイスとFramehawkディスプレイチャネルデータの交換にVDAで使用するUDPポート番号の範囲(最小ポート番号と最大ポート番号)を指定します。VDAは、各ポートの使用を試行します。まず、最小のポート番号から始めて、2回目以降の試行では1つずつ番号を増やしていきます。ポートは、受信トラフィックと送信トラフィックに使用されます。

Framehawkディスプレイチャネル用のポートの開放

XenAppおよびXenDesktop 7.8より、VDAインストーラーの [機能] 手順で、ファイアウォールを再構成する新たなオプションが使用できるようになりました。このチェックボックスをオンにすると、WindowsのファイアウォールでUDPポート3224~3324が開放されます。以下の場合は、手動でファイアウォールを構成する必要があります。

  • ネットワークファイアウォールの場合。
    または
  • デフォルトのポート範囲がカスタマイズされている場合。

これらのUDPポートを開放するには、[Framehawk]チェックボックスをオンにします:

UDPポートの開放

コマンドラインで/ENABLE_FRAMEHAWK_PORTを使用して、Framehawk用にUDPポートを開放することもできます。

FHポートの開放

FramehawkのUDPポートの割り当ての確認

インストール中に、Framehawkに割り当てられたUDPポートを、以下のように[ファイアウォール]画面で確認できます。

デフォルトのUDPポート

[概要]画面には、Framehawk機能が有効になっているかどうかが表示されます。

[概要]画面 - FH

FramehawkでのNetScaler Gatewayのサポート

暗号化されたFramehawkトラフィックは、NetScaler Gateway 11.0.62.10以降、およびNetScaler Unified Gateway 11.0.64.34以降でサポートされています。

  • NetScaler Gatewayは、エンドユーザーのデバイスから直接、Gateway VPN vServerにアクセスできる展開アーキテクチャを参照します。つまり、VPN vServerには、パブリックIPアドレスが割り当てられていて、ユーザーはこのIPアドレスに直接接続します。
  • Unified Gatewayを伴うNetScalerとは、Gateway VPN vServerがターゲットとしてContent Switching vServer(CS)にバインドされた展開を言います。この展開では、CS vServerはパブリックIPアドレスを持ち、Gateway VPN vServerはダミーのIPアドレスを持ちます。

NetScaler GatewayでFramehawkのサポートを可能にするには、Gateway VPN vServerレベルでDTLSパラメーターを有効化する必要があります。このパラメーターを有効化し、XenAppまたはXenDesktopでコンポーネントが正常に更新されると、Gateway VPN vServerとユーザーデバイスの間で、Framehawkのオーディオ、ビデオ、およびインタラクティブなトラフィックが暗号化されるようになります。

Framehawkでサポートされるのは、NetScaler Gateway、Unified Gateway、およびNetScaler Gatewayとグローバルサーバー負荷分散の組み合わせです。

Framehawkでは、次のシナリオはサポートされません。

  • HDX Insight
  • IPv6モードのNetScaler Gateway
  • NetScaler Gatewayのダブルホップ
  • クラスターセットアップ付きNetScaler Gateway
シナリオ Framehawkのサポート
NetScaler Gateway はい
NetScaler+グローバルサーバー負荷分散 はい
Unified Gatewayを伴うNetScaler はい。注: サポートされるのはUnified Gatewayバージョン11.0.64.34以降です。
HDX Insight いいえ
IPv6モードのNetScaler Gateway いいえ
NetScaler Gatewayのダブルホップ いいえ
NetScaler Gateway上にSecure Ticket Authorityを複数配置 はい
High Availability機能付きNetScaler Gateway はい
クラスターセットアップ付きNetScaler Gateway いいえ

FramehawkをサポートするNetScalerの構成

NetScaler GatewayでFramehawkのサポートを可能にするには、Gateway VPN vServerレベルでDTLSパラメーターを有効化してください。このパラメーターを有効化し、XenAppまたはXenDesktopでコンポーネントが正常に更新されると、Gateway VPN vServerとユーザーデバイスの間で、Framehawkのオーディオ、ビデオ、およびインタラクティブなトラフィックが暗号化されるようになります。

リモートアクセスのために、NetScaler GatewayでUDP暗号化を実現するには、この構成が必須です。

FramehawkをサポートするようにNetScalerを構成する場合:

  • 外側のファイアウォールすべてでUDPポート443が開いていることを確認します
  • 外側のファイアウォールすべてでCGPポート(デフォルトは2598)が開いていることを確認します
  • VPN仮想サーバーの設定でDTLSを有効化します
  • SSL証明書とキーのペアのバインドをいったん解除してから、再びバインドしますNetScalerバージョン11.0.64.34以降をお使いの場合、この手順を行う必要はありません。

FramehawkをサポートするようにNetScaler Gatewayを構成するには、以下の手順を実行します:

  1. StoreFrontと通信し、XenAppおよびXenDesktopのユーザーを認証するように、NetScaler Gatewayを展開し、構成します。
  2. NetScalerの[構成]タブで、[NetScaler Gateway]を展開し、[仮想サーバー] を選択します。
  3. [編集] をクリックして、VPN仮想サーバーの[基本設定]を表示し、DTLS設定の状態を確認します。
  4. その他の構成オプションを表示するには、[詳細] をクリックします:
  5. Framehawkなどのデータグラムプロトコルを通信セキュリティで保護するには、[DTLS] を選択します。[OK] をクリックします。VPN仮想サーバーの[基本設定]領域には、DTLSフラグが[真]に設定されています。
  6. サーバー証明書の[バインド]画面を再度開き、証明書のキーペアをバインドするために、[+] をクリックします。
  7. 前述の証明書のキーペアを選択し、[選択]をクリックします。
  8. サーバー証明書のバインドに変更を保存します。
  9. 保存後、この証明書のキーペアが表示されます。[バインド] をクリックします。
  10. No usable ciphers configured on the SSL vserver/service」という警告メッセージが表示されても、無視してください。

旧バージョンのNetScaler Gatewayにおける手順

11.0.64.34より古いバージョンのNetScaler Gatewayを使用している場合は、以下の手順に従います。

  1. サーバー証明書の[バインド]画面を再度開き、証明書のキーペアをバインドするために、[+] をクリックします。
  2. 前述の証明書のキーペアを選択し、[選択]をクリックします。
  3. サーバー証明書のバインドに変更を保存します。
  4. 保存後、この証明書のキーペアが表示されます。[バインド] をクリックします。
  5. No usable ciphers configured on the SSL vserver/service」という警告メッセージが表示されても、無視してください。

FramehawkをサポートするようにUnified Gateway設定を構成するには:

  1. Unified Gatewayがインストールされ、適切に構成されていることを確認します。詳しくは、Citrix製品ドキュメントサイトでUnified Gatewayの情報を参照してください。
  2. ターゲットvServerとしてCS vServerにバインドされているVPN vServer上で、DTLSパラメーターを有効にします。

制限事項

クライアントデバイス上に古いNetScaler Gateway仮想サーバーのDNSエントリがある場合、アダプティブトランスポートとFramehawkはUDPトランスポートではなくTCPトランスポートへフォールバックすることがあります。TCPトランスポートへのフォールバックが発生する場合は、クライアントのDNSキャッシュをクリアし、UDPトランスポートを使用して再接続しセッションを確立させます。

ほかのVPN製品のサポート

NetScaler Gatewayは、Framehawkで必要なUDP暗号化をサポートする唯一のSSL VPN製品です。ほかのSSL VPNや誤ったバージョンのNetScaler Gatewayが使用された場合、Framehawkポリシーの適用に失敗する可能性があります。従来型のIPSec VPN製品では、変更を加えなくともFramehawkがサポートされます。

FramehawkをサポートするCitrix Receiver for iOSの構成

以前のバージョンのCitrix Receiver for iOSをFramehawkをサポートするように構成するには、default.icaを手作業で編集する必要があります。

  1. StoreFrontサーバーで、c:\inetpub\wwwroot\にある自分のストアのApp_Dataディレクトリにアクセスします。
  2. default.icaファイルを開き、[WFClient]セクションに「Framehawk=On」という行を追加します。
  3. 変更を保存します。

この手順により、iOSデバイス上の互換性のあるCitrix ReceiverからFramehawkセッションを確立できるようになります。Receiver for Windowsを使用している場合、この手順は必要ありません。

注:

iOSバージョン7.0以降のReceiverを使用している場合、default.icaファイルにパラメーターFramehawk=Onを明示的に追加する必要はありません。

Framehawkのモニター

Citrix DirectorからFramehawkの利用状況とパフォーマンスをモニターすることができます。HDX仮想チャネル詳細ビューには、あらゆるセッションで、Framehawkのトラブルシューティングやモニターに役立つ情報が表示されます。Framehawk関連のメトリックスを確認するには、[グラフィック - Framehawk]を選択します。

Framehawk接続が確立されていれば、詳細ページに「プロバイダー=VD3D」および「接続済み=はい」と表示されます。仮想チャネルの状況がアイドルであるのは正常です。これは、モニターの対象がシグナリングチャネルで、これは最初のハンドシェイク中にしか使用されないからです。このページには、接続に関するその他の有益な統計も表示されます。

問題が発生した場合は、Framehawkのトラブルシューティングブログを参照してください。