Openmix

概要

NetScaler Intelligent Traffic Management (ITM) Openmix は、グローバル・トラフィック管理/グローバル・サーバー負荷分散 (GTM/GSLB) に対する革新的なアプローチを提供します。従来のグローバル・トラフィック管理では、ITM は負荷分散に DNS ベースのアプローチを提供します。ITM は、必要なビジネスロジックに基づいて DNS 応答がリアルタイムで変更される DNS CNAME またはレコードを使用します。Openmix は、ビデオワークフローと配信に複数の方法で統合できます。

GTM または GSLB ツールとサービスは、フェイルオーバー、ラウンドロビン、およびジオターゲティングのための一連の固定ポリシーを定義および制御するために、独自の拡張不可能な静的ルールエンジンに依存しています。NetScaler ITM の使命は、リアルタイムデータフィードに基づいた次世代のクラウド戦略を可能にすることです。Openmix プラットフォームは、さまざまなソースからのリアルタイムデータを取り込むための非常に堅牢な手段を提供します。これは、メタデータを環境「変数」として公開し、各リクエストで評価できます。

Openmix: 主な利点

• 単一ベンダーへの依存を排除し、100% の可用性を確保
• 価格/パフォーマンスのトレードオフを制御し、マルチソーシングに伴う問題を解消
• レガシーパフォーマンスツールの不確実性を排除し、トラフィックを選択的かつ戦略的にオフロード
• 特定のプロバイダーを適用して個々の市場をターゲットに

Openmix の仕組み

お客様は Citrix ITM ポータルにログインして、最初のアプリケーションを展開します。開始に役立つサンプルアプリのライブラリが利用可能であり、最も一般的なルーティングロジックでアプリケーションを作成するのに役立つステップバイステップのウィザードツールも提供されています。ITM Openmix アプリケーションは、トラフィックを誘導するために DNS または HTTP の 2 つのプロトコルをサポートできます。

アプリケーション定義による制御

グローバルに分散されたオンデマンドの Openmix プラットフォームは、GTM/GSLB の意思決定をアプリケーションのオーディエンスに近づけます。各ホストは、現在のメトリックと変数を考慮した独自のカスタム定義 Openmix アプリケーションを持つことができ、あらゆるルーティングリクエストに最適な最適化を提供します。

Openmix スクリプトは JavaScript でプログラムされており、これはほとんどの Web プログラマーやネットワーク管理者にとってアクセスしやすい言語です。このスクリプトベースのアプローチは、真に動的なトラフィック管理ポリシーの基盤として、最小限のコーディングの複雑さで事実上あらゆるビジネスロジックを実装できる場所です。お客様コミュニティの協力的な性質のおかげで、ITM はコードを必要としない標準アプリケーションである「クイックスタートアプリ」も提供しています。

HTTP または DNS サービスを使用する場合

ITM Openmix は、幅広いコンテンツ配信最適化を可能にします。Openmix を有効にする方法は、ユースケースの具体的な内容に大きく依存します。DNS メソッドは実装が容易で、クライアントに対してほとんど透過的であり、さまざまなコンテンツで利用できます。ただし、プロバイダーを切り替える機能は、DNS 応答に設定された TTL によって制限され、一部のコンテンツはストリームの途中で別のプロバイダーに切り替えることができません。HTTP はより柔軟な統合を提供し、クライアントにとって最適なときに最適化の決定を行うことができます。この柔軟性の向上には、CMS またはクライアントとの統合により多くの作業が必要です。

次の表は、DNS および HTTP インターフェースの顧客ユースケースをまとめたものです。

Openmix: DNS

CNAME 委任

ITM のお客様にとって最も簡単な統合は、DNS CNAME 委任を使用することです。CNAME 委任は、お客様がエンドユーザー向けのホスト名 (以下の例では www.acme.com) を ITM ホスト名にポイントすることで機能します。

www.acme.com  600  IN  CNAME  2-02-123d-000d.cdx.cedexis.net.
<!--NeedCopy-->

エンドユーザーからの DNS リクエストを受信すると、ITM システムはリアルタイムで決定を下します。この決定は、Radar データ、アプリケーション内のビジネスロジック、およびサードパーティ情報に基づいています。この決定は、別の CNAME レコード (以下の例では acme.cdn1.net) または 111.222.111.222 のような A レコードとして明確に示されます。

CNAME レコードを提供することで、ITM はエンドユーザーを CDN、クラウド、または選択したデータセンターに「ポイント」します。これにより、エンドユーザーは別のプロバイダーではなく、そのプロバイダーを使用するようにルーティングされます。

2-02-123d-000d.cdx.cedexis.net.  19  IN  CNAME acme.cdn1.net.
<!--NeedCopy-->

CDN またはクラウド CNAME が提供されると、エンドユーザーのマシンは解決チェーンを続行します。ノードまたはサーバーの IP アドレスが受信されるまで、CDN ネームサーバーにリクエストを送信します。その後、コンテンツのダウンロードプロセスが開始されます。 ロジックの一部としてレコードが提供された場合、エンドユーザーのマシンは IP アドレスを受信します。サーバーに直接接続し、コンテンツのダウンロードを開始します。

acme.cdn1.net.  132  IN  A  111.222.222.111
<!--NeedCopy-->

ゾーン委任

さらに、権威 DNS ゾーン委任は Openmix を実装するためのオプションです。お客様は DNS ゾーンを作成し、ITM ポータルで作成された予測 DNS ゾーンに委任します。委任されたゾーンにホスト名を作成します。Openmix アプリケーションまたは動的な予測 DNS レコードを使用して応答を生成するように構成します。 このオプションの利点は、ホスト名と ITM プラットフォームからの動的応答の間に CNAME 委任が必要ないことです。上記の例 www.acme.com を使用すると、ホスト名は最適な CDN、クラウド、またはデータセンターの構成値に直接解決されます。

www.acme.com. 19 IN CNAME acme.cdn1.net.

A/AAAA レコードも CNAME の代わりに使用でき、ホスト名は最適な宛先のレコードに直接解決されます。

www.acme.com. 19 IN A 111.222.222.111

DNS と Time To Live の影響

Time To Live (TTL) 値などの要素は、コンテンツに適した時間と、ユーザーにとって意思決定がどのように行われるべきかを考慮して慎重に検討されます。ほとんどの場合、ITM はページおよびオブジェクトコンテンツに 20 秒の TTL を推奨します。ビデオコンテンツの場合、ITM コンサルタントは、チャンク長と統合方法に基づいて最も適切なバランスを見つけるために顧客と協力します。

Openmix: HTTP

DNS の代替手段として、HTTP API を使用する方法があります。Openmix は HTTP リクエストを使用して、ビデオプレーヤーや CMS などのクライアントに、特定の時点でどのプラットフォームを使用するかを通知します。

http://hopx.cedexis.com/zones/1/customers/0/apps/1/decision
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 22 Apr 2015 20:25:24 GMT
< Connection: keep-alive
< Content-Length: 177
<
{
  "providers" : [
    {
    "provider" : "cdn2",
    "host" : "foo.cdn2.net"
    },
    {
    "provider" : "cdn1",
    "host" : "acme.cdn1.net"
    }
  ]
}
<!--NeedCopy-->

HTTP Openmix サービスは、DNS ベースの対応するサービスと同じアプリケーションロジックを使用します。また、クライアントマシンのさらなるプロファイリングを可能にする追加の拡張機能も含まれています。たとえば、HTTP Openmix を使用すると、User-Agent String、X-Forwarded-For、および Referer のヘッダーを調べることができます。クエリ文字列パラメーターを使用して IP オーバーライドを提供します。 HTTP Openmix のペイロードは DNS よりも拡張性が高いため、CDN、クラウド、またはサーバーの決定選択をさまざまな方法で提供することも可能です。これまでのところ最も一般的なのは、最も優先されるプラットフォームから最も優先されないプラットフォームへの順序付きリストです (上記のとおり)。完全なリストにより、決定ランクを CMS またはクライアントに提供できますが、プロバイダーを選択する際に内部ヒューリスティックを使用することもできます。

CMS 統合

一部の顧客は、すべてのクライアントでプロバイダー選択を実装するよりも、サーバー側でプロバイダー選択を処理することを好みます。HTTP API を使用して、クライアントからのリクエスト時に Openmix から最適化の決定を取得できます。これは、CMS からクライアントに返されるファイルを生成するために使用できます。

デフォルトでは、Openmix HTTP エンドポイントは、ジオロケーションと決定基準に呼び出し元の IP を使用します。エンドユーザーのクライアントと Openmix の間に位置する CMS またはその他のシステムから呼び出す場合、決定に使用するパラメーターとして IP を指定できます。

http://hopx.cedexis.com/zones/1/customers/0/apps/1/decision?ip=1.2.3.4
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 22 Apr 2015 20:25:24 GMT
< Connection: keep-alive
< Content-Length: 177
<
{
  "providers" : [
    {
    "provider" : "cd1",
    "host" : "acme.cdn1.net"
    },
    {
    "provider" : "cdn2",
    "host" : "foo.cdn2.net"
    }
  ]
}
<!--NeedCopy-->

この方法により、CMS 統合を使用して Openmix から決定を取得できます。また、エンドユーザーのジオおよび ISP ルート最適化のメリットも得られます。Openmix から返されたホスト名は、ビデオマニフェストファイルなどの応答にパッケージ化され、CMS からクライアントに返されます。クライアントは、Openmix 最適化をサポートするための変更を必要とせずに、最適化された決定を使用します。

Openmix アプリケーション

Openmix クイックスタート・アプリケーションは、負荷分散およびトラフィック管理アプリケーションです。これらのアプリケーションは、一連のルールに基づいて最適なプロバイダーへのリアルタイムトラフィックルーティングを提供します。

アプリケーションは、Openmix への各リクエストに対して処理され、指定されたロジックに基づいてルーティングの決定が行われます。顧客は、ビジネス価値の高いコンテンツには 1 つのアプリケーションを、価値の低いコンテンツには別のアプリケーションを持つことができます。これらのリクエストは個別にルーティングされます。

アプリケーションを呼び出すと、単一のリクエストが Citrix のロードバランサーの 1 つに送信されます。DNS の場合、DNS ロードバランサーへの単一の DNS リクエストです。HTTP の場合、Openmix HTTP エンドポイントへの GET または HEAD リクエストです。

以下のアプリは現在、NetScaler Intelligent Traffic Management ポータルを通じて利用可能です。

• 静的ルーティング
• フェイルオーバー
• ラウンドロビン
• 最適なラウンドトリップ時間 (ORTT)
• スループット
• 静的近接性

Openmix カスタム JavaScript アプリケーションは、特殊な Openmix サーバーによって使用され、スクリプト内のロジックに基づいて DNS または HTTP リクエストに応答します。スクリプトの展開は、アプリが構成および公開される顧客ポータルを介して行われます。独自の JavaScript スクリプトを作成する機能の詳細については、Developer Exchange の情報をご参照ください。

アプリを設定する前に、以下の概念を理解しておくことが重要です。

可用性しきい値

可用性しきい値は、ルーティングの対象となるためにプラットフォームが満たす必要がある最小可用性スコアです。すべてのアプリケーションのデフォルトの最小可用性しきい値は 80% です。ただし、このパーセンテージは、場所、ネットワーク可用性、および信頼性に応じて適切な値に修正できます。

注: どのプラットフォームもこの最小可用性しきい値 (デフォルトの 80% または設定した値) を満たさない場合、ラウンドロビン、ORTT、およびスループット・アプリケーションに対してランダムルーティングが実行されます。

フォールバック

フォールバック応答は、Openmix アプリケーションが何らかの理由で正常に実行されなかった場合、または Sonar が利用可能なプラットフォームがないことを確認した場合に返されます。したがって、Openmix が応答できる有効なフォールバック CNAME/A/AAAA レコードまたは IP (または HTTP のパス) を指定する必要があります。このフォールバック URL または CNAME レコードは、Openmix で事前に構成されたプラットフォームのものである可能性があります。 フォールバックは、次のようなシナリオでも発生することがあります。

• アプリケーションのバージョンを切り替える際に、新しいスクリプトをアップロードして公開します。新しいスクリプトが初期化され、古いスクリプトが削除されるまで、短いミリ秒のフォールバック期間があります。
• 過負荷が発生した場合 (まれに発生します)、Openmix はフォールバック CNAME/A/AAAA で応答します。これは、フォールバックがサービスの負荷を相殺するためです。

フォールバックの場合、DNS では有効なホスト名 (CNAME/A/AAAA レコード) または IP アドレスを、HTTP では有効な URI ( scheme:[//host[:port]][/path][?query][#fragment]) の形式) を入力する必要があります。

TTL

Openmix では、アプリケーションの DNS Time to Live (TTL) は、リゾルバーが Openmix に再度問い合わせる前に決定を保持する必要がある期間を伝えます。 TTL は、Openmix アプリが取得するトラフィックの量を制御するために使用されます。また、アプリが作用するデータの変更に対してどの程度敏感である必要があるかを制御します。 デフォルトの TTL は 20 秒です。この値は変更できますが、変更することはお勧めしません。TTL を下げると、ボリュームが増え、リアルタイムの DNS クエリが増えます。これにより、DNS クエリがクライアントで時間がかかるため、コストが増加し、パフォーマンスが低下する可能性があります。したがって、TTL のデフォルト値を変更しないのが最善です。

注: Time to Live は、クイックスタートアプリ、コードで TTL が指定されていないカスタム JS アプリ、およびすべてのフォールバック応答に適用されます。

重み (ラウンドロビンで使用)

各プラットフォームの優先順位付けと選択のために、グローバルおよび/または市場または国ごとに重みを割り当てることができます。

たとえば、アプリケーション用に P1、P2、P3 の 3 つのプラットフォームを選択したとします。これらにそれぞれ 60、50、10 の重みを付けます。ラウンドロビンアプリはこれらの値をパーセンテージに変換し、P1=50%、P2=42%、P3=8% となり、合計で 100% になります。これらのパーセンテージは、ユーザーの 50% が P1 を介して、42% が P2 を介して、8% が P3 を介してルーティングされることを意味します。

プラットフォームに与える重みは、合計で 100 になる必要はありません。0 から 1,000,000 の間の任意の整数にすることができます。プラットフォームに与えられた重みは、パーセンテージに変換されると (バックエンドのアプリによって)、合計で 100% になります。選択されたすべてのプラットフォームに同じ重みが与えられた場合、トラフィックは時間とともに均等に分散されます。プラットフォームが 1 つしかない場合、そのプラットフォームは、与えられた重みに関係なく、常に 100% 使用されます。

重みは、Radar および Sonar の可用性チェック (アプリケーションの構成による) に従って利用可能と見なされるプラットフォームにのみ使用されます。利用できないプラットフォームは、構成された重みに分布が一致しない原因となります。たとえば、P1 の重みが 100 で P2 の重みが 0 であっても、P1 が Radar の可用性チェックに失敗した場合、すべてのトラフィックは P2 に送られます。

ハンディキャップ (ORTT およびスループットで使用)

ハンディキャップは、プラットフォームに適用できるパーセンテージ値で、RTT およびスループットのレーダースコアを変更します。つまり、応答時間 (ミリ秒単位) を人為的に増加させたり、スループット (kbps 単位) を減少させたりします。これらの値を増減すると、プラットフォームのパフォーマンスが低下し、選択される可能性が低くなります。ハンディキャップは、グローバルに、または特定の市場や国ごとに個別にプラットフォームに追加できます。 特定の市場や国で 1 つのプラットフォームが高価であり、同等のプロバイダーがパフォーマンスの点で近い場合に、そのプラットフォームが選択される可能性を減らしたい場合。ハンディキャップ値を乗数として設定し、応答時間の値を増やしたり、スループットの値を減らしたりします。その結果、プラットフォームが選択される確率が低下します。

以下は、ハンディキャップがバックエンドでどのように機能するかを大まかに示したものです。

• ハンディキャップ適用後のプラットフォーム RTT = RTT (ラウンドトリップ時間 (ミリ秒)) * (1 + ハンディキャップ) または
• ハンディキャップ適用後のプラットフォームスループット = (スループット (kbps)) * (1 – ハンディキャップ)

注: プラットフォームの RTT およびスループット値は、Radar データからのスコアです。 次の表は、ハンディキャップが 2 つのプラットフォーム (P1 と P2) にどのように影響するかを示しています。また、ハンディキャップが P1 が選択される可能性をどのように低下させるかを示しています。

フィルタリング、ランキング、選択のワークフロー

スループット・アプリのサンプルフロー図

プラットフォーム選択基準

Openmix クイックスタート・アプリは、最適なプラットフォームをランク付けして選択するための第 1、第 2、第 3 レベルのフィルターとして、以下の基準を使用します。

理由コードレポート

理由コードは、決定が下された理由と、アプリのコードのどの部分が実行されたかについての可視性を提供します。実行中、アプリはいつでも理由コードフィールドに何かを追加できます。 理由コードは、クイックスタート・アプリごとに異なる意味を持ちます。各アプリの理由コードにはいくつかの共通点がありますが、包括的ではありません。

注: 理由コードが正しく表示されるためには、最大文字数 200 文字を超えてはなりません。この制限を超えると、理由コードは Unknown と表示されます。ユーザーが理由コードを追加していない場合も、Unknown と表示されます。

以下は、クイックスタート・アプリの理由コードです。

Openmix クイックスタート・アプリケーション

1. NetScaler Intelligent Traffic Management ポータルにログインします。
2. 左側のナビゲーションメニューから、Openmix > Application Configuration に移動します。
3. Openmix アプリを初めて構成する場合は、Openmix > Application Configuration をクリックすると、Get Started ページが表示されます。
4. 新しいアプリを構成するには、Get Started ボタンまたはページの右上隅にある Add ボタンをクリックします。Openmix アプリが以前に構成されている場合は、このページにアプリのリストが表示されます。

以下のセクションでは、ポータルで Openmix アプリを構成するプロセスについて説明します。

静的ルーティング

このタイプのアプリケーションは、エンドユーザーに提供する必要がある DNS 応答を決定するために評価ロジックを使用しません。アプリは常に、ユーザーが指定した単一のプラットフォームを選択します。したがって、アプリは単一の DNS CNAME または IP アドレス応答のみを使用します。静的ルーティング・アプリケーションは、Application Configuration ページでポータルを通じて構成できます。

注: アプリケーションを構成する前に、プラットフォームが最初に構成されていることを確認してください。プラットフォームの構成については、プラットフォーム ページをご参照ください。

ナビゲーション

1. Openmix > Application Configuration に移動します。
2. 右上にある Add ボタンをクリックします。

Basic Information ダイアログボックスが開きます。

基本情報

Basic Information を入力するには、次の手順に従います。

1. Protocol で、リストから DNS または HTTP を選択します。
2. Application Type で、Static Routing を選択します。または、別の種類のアプリを構成する場合は、リストから選択します。
3. アプリケーションに Name (必須フィールド) を付け、Description (オプションフィールド) と Tag (オプションフィールド) を追加します。
4. Next をクリックして Configuration に進みます。

設定

アプリを構成するには、次の手順を実行します。

1. Platform リストから関連するプラットフォームを選択します。これは、プラットフォーム ページで設定したプラットフォームであり、CDN、クラウド、またはデータセンターを表します。
2. CNAME/A/AAAA レコード (DNS の場合) または URL (HTTP の場合) を入力します。選択したプラットフォームの DNS CNAME または HTTP URL は、有効な IP アドレスまたはホスト名を指している必要があります。
3. CORS の場合、HTTP プロトコルで None、All、または Custom を選択します。CORS を使用すると、他のサイトからのサイトへのアクセスを制御できます。他のサイトからのサイトへのアクセスを完全に制限する ( None をクリック)、すべての他のサイトからのアクセスを許可する ( All をクリック)、または特定のサイトからのみアクセスを許可する ( Custom をクリック) ことができます。
4. 応答の TTL (Time-To-Live) を入力します。デフォルトは 20 秒ですが、オーバーライドできます。
5. Complete をクリックします。
6. 確認ポップアップで Done または Publish をクリックすると、Openmix アプリケーションページにアプリがリストされます。Publish をクリックすると、アプリはすぐに公開され、緑色のステータスになります。これは、アプリケーションが本番環境にあることを意味します。Done をクリックすると、アプリはアプリケーションページにリストされたままですが、未公開であり、ステータスは赤色です。

フェイルオーバー

フェイルオーバー・アプリケーションは、プラットフォームがその順序と可用性に基づいて選択される単純なルーティングロジックをサポートします。顧客は、どのプラットフォームを最初に、次に、というように選択するかを決定するフェイルオーバーチェーンを作成できます。このフェイルオーバーチェーンは、グローバルに、または個々の市場や国で機能するように作成できます。

フェイルオーバー・アプリケーションは、ポータル内の Application Configuration ページで構成できます。

注: アプリケーションを構成する前に、プラットフォームが最初に構成されていることを確認してください。プラットフォームの構成については、プラットフォーム ページをご参照ください。

ナビゲーション

1. ポータルにログインします。
2. 左側のナビゲーションメニューから、Openmix > Application Configuration に移動します。
3. 右上にある Add ボタンをクリックして、新しい Openmix アプリケーションの Basic Information ダイアログボックスに移動します。

基本情報

1. Protocol リストから DNS を選択します。
2. Application Type リストから Failover を選択します。
3. アプリケーションに Name (必須フィールド) を付け、Description (オプションフィールド) と Tag (オプションフィールド) を追加します。
4. 完了したら、Next をクリックします。

設定

1. Configuration ダイアログボックスで、Availability Threshold チェックボックスを選択します。可用性しきい値のデフォルト値は 80% です。プラットフォームは、ルーティングの対象となるために、このしきい値以上の可用性スコアを持っている必要があります。
   • デフォルトの可用性しきい値を変更する場合は、新しい値を入力してデフォルトを置き換えます。
   • どのプラットフォームも指定されたしきい値以上の可用性スコアを持っていない場合、フォールバック CNAME または A または AAAA または IP アドレスが使用されます。
   • チェックボックスが選択されていない場合、プラットフォームはゼロの可用性しきい値を想定します。これは、このプラットフォームで Radar 可用性チェックがないことを意味します。
2. Fallback の CNAME/A/AAAA または IP アドレスを入力します。フォールバック CNAME/A/AAAA または IP は、通常、アプリケーションで問題やエラーが発生した場合に使用されます。
3. 応答の TTL (Time-To-Live) を入力します。デフォルトは 20 秒です。必要に応じてこの値をオーバーライドできます。

プラットフォーム情報

1. Platform Information ダイアログボックスで、リストから Platform を選択します。
   • Add Platforms ボタンを使用して複数のプラットフォームを選択できます。これは、グローバルおよびジオ (市場および国) ルーティングに適用可能なすべての利用可能なプラットフォームを選択するという考え方です。
   • このリストのプラットフォームは、ポータル内の プラットフォーム ページで設定したもので、CDN、クラウド、またはデータセンターを表します。
   • すべての Openmix アプリは、事前に設定された関連プラットフォームを必要とします。リストにプラットフォームが見つからない場合は、ポータル内の プラットフォーム ページで設定できます。
2. プラットフォームの CNAME/A/AAAA レコードを入力します。
3. 次のステップに進む前に、Enabled チェックボックスが選択されていること (プラットフォームが有効であることを示す) を確認します。
4. Sonar が構成されており、初期の意思決定プロセスで Sonar データを使用したい場合は、Use Sonar for Platform Availability チェックボックスをクリックしてください。注: Sonar チェックボックスは、そのプラットフォームで Sonar が有効になっている場合にのみ表示されます。
5. Next をクリックして Location Configuration に進みます。

ロケーション設定

1. Location Configuration ダイアログボックスで、Global ルーティングに必要なプラットフォームを選択します。
   • Global は、グローバルルーティング用のプラットフォームチェーンを設定していることを示します。
   • Global フィールド内をクリックすると、Platform Information ステップで選択したすべてのプラットフォームのリストが表示されます。
   • 可用性ベースのグローバルルーティングのために、リストから必要なプラットフォームを選択します。
   • このフィールドにプラットフォーム名を配置する順序は、選択の優先順位を決定します。たとえば、リストの最初のプラットフォームが利用できない場合、2 番目のプラットフォームが選択されます。リストのどのプラットフォームも利用できない場合、フォールバックが使用されます。
   • プラットフォーム名をドラッグして、優先順位を変更できます。
2. ローカルジオルーティング用のプラットフォームを設定したい場合は、Markets & Countries をクリックします。
   • Markets & Countries フィールド内をクリックすると、Platform Information ステップで選択したすべてのプラットフォームのリストが表示されます。
   • 各ジオ (市場/国) ごとに個別に、ローカルジオルーティング用のプラットフォームを選択します。
   • このフィールドにプラットフォーム名を配置する順序は、選択の優先順位を決定します。たとえば、中国では中国の POP を最初に利用したいが、それが利用できない場合にのみシンガポールの POP を利用したい場合、シンガポールの POP を次に配置します。
   • プラットフォーム名をドラッグして、優先順位を変更できます。

   

3. Complete をクリックして、アプリの構成を完了します。
4. 確認ポップアップで Done または Publish をクリックすると、Openmix ページにアプリがリストされます。
   • Publish をクリックすると、アプリはすぐに公開され、緑色のステータスになります。アプリケーションは本番環境にあります。
   • Done をクリックすると、アプリは Openmix ページにリストされたままですが、未公開であり、ステータスは赤色です。

ラウンドロビン

このアプリケーションは、ラウンドロビンの典型的なグローバル・サーバー負荷分散手法に従い、DNS リクエストが行われると、各 CNAME がエンドユーザーに交互に返されます。Sonar データ (Sonar が有効な場合) と Platform Availability しきい値を使用して、リクエストしているユーザーにとって最適なプラットフォームを評価します。その後、各プラットフォームはラウンドロビン分散手法に基づいて選択されます。たとえば、P1、P2、P3 のプラットフォームが可用性しきい値を満たしている場合、最初のリクエストは P1 に、2 番目は P2 に、3 番目は P3 にルーティングされます。4 番目のリクエストは再び P1 にルーティングされます。

新しいラウンドロビン・アプリを構成するには、Openmix ページの右上隅にある Add ボタンをクリックします。Basic Information ダイアログボックスが開きます。

ナビゲーション

1. ポータルにログインします。
2. 左側のナビゲーションメニューから、Openmix > Application Configuration に移動します。
3. 右上にある Add ボタンをクリックして、新しい Openmix アプリケーションの Basic Information ダイアログボックスに移動します。

基本情報

1. Basic Information ダイアログボックスで、ラウンドロビンのプロトコルとして DNS を選択します。注: ラウンドロビン・アプリの場合、ルーティングは DNS CNAME を介してのみ利用可能です。
2. リストから Application Type を選択します。アプリに Name (必須フィールド)、Description (オプションフィールド)、および Tag (オプションフィールド) を付けます。
3. Next をクリックして Configuration に進みます。

設定

1. Availability Threshold のデフォルト値は 80% です。この値を変更するには、新しい値を入力してデフォルトを置き換えます。
2. Fallback の CNAME/A/AAAA または IP アドレスを入力します。フォールバック CNAME/A/AAAA または IP は、通常、アプリケーションで問題やエラーが発生した場合に使用されます。
3. 応答の TTL (Time-To-Live) を入力します。デフォルトは 20 秒ですが、必要に応じてこの値をオーバーライドできます。
4. Next をクリックして Platform Information に進みます。

プラットフォーム情報

1. Platform リストからプラットフォームを選択します。注: すべての Openmix アプリは、事前に設定された関連プラットフォームを必要とします。リストにプラットフォームが見つからない場合は、ポータル内の プラットフォーム ページで設定できます。
2. Add Platform ボタンをクリックして、さらにプラットフォームを選択します。
3. このプラットフォームの CNAME または A/AAAA レコードまたは IP (DNS の場合)、または URL (HTTP の場合) を入力します。有効な URL、ホスト名、または IP アドレスである必要があります。形式は scheme:[//host[:port]][/path][?query][#fragment] です。
4. 次のステップに進む前に、Enabled チェックボックスが選択されていること (プラットフォームが有効であることを示す) を確認します。
5. Sonar が利用可能であり、初期の意思決定プロセスで Sonar データを使用したい場合は、Use Sonar for Platform Availability チェックボックスをクリックしてください。
6. Save をクリックして、ステップ 4 に進み、各プラットフォームに適切な重みを割り当てます。

ロケーション設定

1. 各プラットフォームの優先順位付けと選択のために、グローバルおよび/または市場または国ごとに Weights を割り当てます。
2. 市場または国ごとにプラットフォームの重みを個別に割り当てるには、Markets & Countries 検索ボックスに名前を入力し、リストから選択します。
3. Complete をクリックすると、アプリケーションが作成されます。
4. 確認ポップアップで Done または Publish をクリックすると、Openmix ページにアプリがリストされます。Publish をクリックすると、アプリはすぐに公開され、緑色のステータスになります。アプリケーションは本番環境にあります。Done をクリックすると、アプリは Openmix ページにリストされたままですが、未公開であり、ステータスは赤色です。

最適なラウンドトリップ時間 (ORTT) アプリ

ORTT アプリは、Radar 応答時間、Sonar データ (Sonar が有効な場合)、およびプラットフォーム可用性しきい値を使用して、リクエストしているユーザーにとって最適なプラットフォームを評価します。可用性しきい値は、プラットフォームが選択されるために満たす必要がある最小可用性 (デフォルト値は 80%) です。さらに、ORTT アプリは、グローバルまたはローカルで顧客がエンドユーザーをルーティングする方法に影響を与えることができるハンディキャップ値も使用します。

最初の 3 つのステップ (基本情報、構成、プラットフォーム情報) は、他のアプリと同じ方法で入力されます。

ロケーション情報を構成し、グローバルまたはロケーション/市場ごとに各プラットフォームの Handicap の値を入力するには、次の手順に従います。

ロケーション設定

1. Location Configuration ダイアログボックスで、選択した 1 つまたはすべてのプラットフォームの Handicap の値を入力します。ハンディキャップ値は 0 から 6000 の間で入力できます。ハンディキャップを使用する目的は、コストや利便性の点でより優れたプラットフォームが利用可能な場合に、特定のプラットフォームがルーティングに選択される可能性を手動で低くすることです。ハンディキャップ値が大きいほど、プラットフォームが選択される可能性は低くなります。Platform Selection ボタンをオフにすることで、必要に応じてプラットフォームの選択を解除できます。

2. Markets & Countries をクリックして、リストから特定の市場または国を選択し、関連する各プラットフォームの Handicap 値を個別に入力します。

3. Complete をクリックして、アプリの構成を完了します。

4. 確認ポップアップで Done または Publish をクリックすると、Openmix アプリケーションリストページにアプリがリストされます。Publish をクリックすると、アプリはすぐに公開され、緑色のステータスになります。アプリケーションは本番環境にあります。Done をクリックすると、アプリはアプリケーションページにリストされたままですが、未公開であり、ステータスは赤色です。

スループット

スループット・アプリは、Sonar データ (Sonar が有効な場合)、最高スループット (Radar データを使用)、およびプラットフォーム可用性しきい値 (デフォルトで 80%) に基づいてプラットフォームを選択します。さらに、このアプリでは、特定のプラットフォームのスループットを低下させ、エンドユーザーのルーティング方法に影響を与えるために、ハンディキャップ値を追加できます。このオプションのハンディキャップ値は、グローバルおよび/またはローカル (特定の市場または国の場合) に割り当てることができます。

最初の 3 つのステップ ( Basic Information、Configuration、および Platform Information ) は、他のアプリと同じ方法で入力されます。Location Configuration は、ORTT アプリと同じ方法で入力されます。

完了したら、Complete をクリックして Openmix アプリケーションリストページに戻ります。最後に、公開する準備ができたら Publish をクリックしてアプリケーションを公開します。

アプリケーションのステータス

アプリのステータスは、現在の構成を示します。

• 赤は未公開を表します。構成を完了した後、Done をクリックすると、アプリケーションは未公開であることを示す赤い点でアプリケーションページにリストされます (後でさらに編集するため)。
• 緑は公開済みを表します。Publish をクリックすると、アプリはすぐに公開され、緑色の点で示されます。これは、アプリケーションが本番環境にあることを意味します。
• 黄色は、未公開の最新バージョンを表します。黄色の点は、アプリケーションが作成および編集され、最後に変更された設定がまだ公開されていないことを示します。

静的近接性

静的近接性アプリケーションは、リクエストしているユーザーの緯度と経度に近くに位置するプラットフォームに応答します。

注:

すべての Openmix アプリは、事前に設定された関連プラットフォームのセットを必要とします。リストにプラットフォームが見つからない場合は、ポータル内のプラットフォームページで設定できます。

ナビゲーション

1. NetScaler Intelligent Traffic Management ポータルにログインします。
2. 左側のナビゲーションメニューから、Openmix > Application Configuration に移動します。
3. 右上にあるプラスボタン Add Openmix App をクリックします。
4. Quickstart App を選択します。

基本情報

1. Basic Information ダイアログボックスで、プロトコルとして DNS を選択します。
2. アプリケーションタイプとして Static Proximity を選択します。アプリに名前 (必須フィールド)、説明 (オプションフィールド)、およびタグ (オプションフィールド) を付けます。
3. Next をクリックして Configuration に進みます。

設定

1. 有効な場合、Availability Threshold のデフォルト値は 80% です。新しい値を入力してデフォルトを置き換えます。
2. Fallback の CNAME/A/AAAA または IP アドレスを入力します。フォールバック CNAME/A/AAAA または IP は、通常、アプリケーションで問題やエラーが発生した場合に使用されます。このフィールドは空にできません。
3. 応答の TTL (Time-To-Live) を入力します。デフォルトは 20 秒ですが、必要に応じてこの値をオーバーライドできます。
4. Next をクリックして Persistency Controls に進みます。

永続性制御

Local Persistence を設定します。詳細については、ローカル永続性 をご参照ください。Next をクリックして Platform Information に進みます。

プラットフォーム情報

各プラットフォームは、Platforms ページを通じて緯度と経度を設定する必要があります。コミュニティプラットフォームのエイリアスは、最初はコミュニティプラットフォームからジオ情報を継承しますが、エイリアスを作成した後で変更できます。プライベートプラットフォームは、作成時または後で構成ペインを通じて設定する必要があります。構成ペインを表示するには、テーブルのプラットフォームエントリをクリックするだけです。

以下のカテゴリに属するプラットフォームのみがジオ情報を持つことができ、opx アプリの回答リストの一部になることができます。

• クラウドコンピューティング
• クラウドストレージ
• データセンター

1. Platform リストからプラットフォームを選択します。

2. プラットフォームの CNAME または A/AAAA レコードまたは IP (DNS の場合)、または URL (HTTP の場合) を入力します。有効な URL、ホスト名、または IP アドレスである必要があります。形式は次のとおりです。

   scheme:[//host[:port]][/path][?query][#fragment]

3. 次のステップに進む前に、Enabled チェックボックスが選択されていること (プラットフォームが有効であることを示す) を確認します。

4. このプラットフォームで Sonar が利用可能であり、DNS 解決中に Sonar データが考慮されるようにしたい場合は、Use Sonar for Platform Availability チェックボックスをクリックしてください。

5. Add Platform をクリックして、さらにプラットフォームを追加できます。

6. Next をクリックして Location Configuration に進みます。

ロケーション設定

1. Location Configuration ダイアログボックスの Global 部分で、グローバルルーティング用のプラットフォームチェーンを設定できます。各プラットフォームのグローバルな選択を有効または無効にできます。

2. Markets & Countries では、市場または国ごとに異なる設定を作成でき、それらのジオフェンシングルールを効果的に設定できます。

3. Complete をクリックしてアプリケーションを作成します。

確認ポップアップで Publish, Add another または Done をクリックします。

• Publish をクリックすると、アプリはすぐに公開され、ステータスは緑色になります。これは、アプリケーションが本番環境にあることを意味します。

• Done をクリックすると、アプリは Openmix ページにリストされますが、未公開であり、ステータスは赤色です。

• Add another をクリックすると、アプリのステータスは Done と同じですが、新しいアプリを作成するために同じプロセスを再開します。

クイックスタート・アプリケーションの管理

アプリケーションマネージャーパネル内の上部のタブを使用して、アプリケーションの編集、複製、削除、テスト、レポートの表示、ソースの表示、およびバージョン履歴の表示を行います。Openmix アプリケーションリストページでアプリケーションをクリックすると、アプリケーションマネージャーが展開されます。

レポートの表示

View Report をクリックすると、Openmix Decision Reports ページに移動し、各アプリケーション、プラットフォーム、および地理の Openmix 決定の傾向を表示できます。

編集

Openmix アプリを編集するには、アプリケーションマネージャーパネルの上部にある Edit アイコンをクリックするだけです。図に示すように、パネル内の Edit ボタンをクリックして、基本情報、構成、プラットフォーム、またはロケーション情報に対して個別の編集を行うこともできます。編集が完了したら、Done をクリックしてアプリを未公開ステータスでリストするか (後でさらに編集するため)、Publish をクリックしてすぐに公開します。

複製

Duplicate をクリックすると、現在のアプリケーションの構成が複製され、新しい名前で保存されます。

削除

不要になったアプリケーションを削除するには、Delete をクリックします。

公開

Publish をクリックすると、Openmix アプリケーションマネージャーからアプリケーションを直接公開できます。このオプションは、アプリがまだ公開されていない場合にのみ表示されます。

Openmix カスタム JavaScript アプリケーション

Openmix JavaScript アプリケーションは、カスタマイズ可能な Java スクリプトを持つアプリです。ITM ポータルの UI を使用して、作成、構成、テスト、および公開できます。

注: このガイドでは、カスタムスクリプトの実際の作成 (構文、変数など) については説明していません。カスタム JavaScript の作成の詳細については、Developer Exchange をご参照ください。

ナビゲーション

1. ITM ポータルにログインします。
2. 左側のナビゲーションメニューから、Openmix に移動します。
3. Application Configuration を選択します。
4. 新しい Openmix アプリを構成するには、右上隅にある追加アイコンをクリックします。
5. Custom JS App を選択します。
6. Openmix Application Configuration ページが開きます。

基本情報

1. Application Name: アプリに名前を付けます。
2. Description: アプリの説明またはリリースノートをここに追加します。オプションフィールドです。

3. Tags: 必要に応じて適切なタグを入力します。タグは、アプリを識別して整理するのに役立ちます。オプションフィールドです。

4. Protocol: プロトコルとして DNS または HTTP を選択します。
   • DNS: DNS を選択した場合、TTL 値を入力する必要があります。
   • HTTP: HTTP を選択した場合、Secure Access を有効にできます。
5. TTL: アプリケーションの DNS Time to Live を入力します。推奨値は 20 秒です。注: この TTL は、カスタム JS アプリによって TTL が設定されていない場合、または応答がフォールバック値である場合に適用されます。

6. Fallback: Fallback の CNAME/A/AAAA または IP アドレスを入力します。フォールバック CNAME/A/AAAA または IP は、通常、アプリケーションで問題やエラーが発生した場合に使用されます。

7. Secure Access: Secure Access が有効になっている場合、HTTP API は、呼び出されるときにクライアントからの OAuth アクセスキーを要求する必要があります。Openmix HTTP API の保護 を参照して詳細を確認してください。

   注: セキュアアクセスを有効にすると、Openmix のフロントページのアプリリストのアプリ名の横にロックアイコンが表示されます。

カスタム JavaScript

構成情報を入力したら、カスタム JavaScript をアップロードできます。

1. Choose File ボタンをクリックし、アップロードする JavaScript ファイルを選択します。既存のファイルを上書きするために、いつでも新しいファイルをアップロードできます。

2. Save & Test をクリックしてアプリケーションを保存します。

   注: アプリケーションは、アップロードおよび保存時にアプリケーションチェッカーを使用して自動的にテストされます。エラーがある場合、アプリケーションチェッカーはエラー情報とエラーの場所を表示します。アプリケーションチェッカーから利用できるデータの詳細については、「アプリケーション検証」セクションをご参照ください。

   

3. Cancel をクリックして Openmix Applications ページに戻るか、アプリケーションを公開する準備ができたら Publish をクリックします。

   注: Publish をクリックすると、アプリはすぐに公開され、緑色のステータスになります。アプリケーションは本番環境にあります。

   Cancel をクリックすると、アプリはアプリケーションページにリストされたままですが、未公開であり、ステータスは赤色です。ステータスの詳細については、「アプリケーションのステータス」セクションをご参照ください。

段階的なアプリケーション展開

アプリケーションの展開は、Web トラフィックの少量を新しいバージョンに送信することで管理できます (カナリア展開と呼ばれることもあります)。ITM を使用すると、Web トラフィックの指定されたパーセンテージを新しいバージョンのアプリに送信して、アプリケーションロジックが期待どおりに動作することを確認できます。既存バージョンと新しいバージョンの動作をレポートして、ライブ環境でのアプリへの変更を評価できます。このオプションを使用すると、新しく編集されたアプリを通じて Web トラフィックの 100% をルーティングする前に発生する問題や異常を修正できます。目的の動作を確認した後、新しいバージョンへのトラフィックのパーセンテージを増やすか、すべてのユーザーにアプリケーションを展開できます。

アプリケーションの展開を段階的に行い、新しく変更されたアプリのテストバージョンをリリースするには、次の手順を実行します。

• アプリ名 (Openmix アプリケーションリストページ内) をクリックします。アプリケーションマネージャーパネルが開きます。
• Edit アイコンをクリックしてアプリを編集します。
• 既存のアプリを必要なすべての変更で修正します。
• 編集が完了したら、Save and Test をクリックします。
• Cancel および Publish ボタンのあるページの下部までスクロールします。この新しく変更されたバージョンを通じて流したい Web トラフィックのパーセンテージ (1% から 99%) を入力します。
• この新しいバージョンのアプリケーションを通じてトラフィックを部分的に分散するためのチェックボックスをオンにします。残りのトラフィックは以前のライブバージョンに送信されます。
• Publish をクリックします。この新しいテストバージョンのアプリは、新しい Status アイコンとともに Openmix Configuration ページのアプリリストに表示されます。新しい Status アイコンは、このバージョンを通じて部分的な Web トラフィックのみがライブで流れていることを示します。

テストバージョンへのトラフィックフローを変更し、トラフィックフローのパーセンテージを変更してパフォーマンスを表示できます。

![カナリア](/en-us/citrix-intelligent-traffic-management/media/openmix-jsapp-edit-canary.png)

アプリのパフォーマンスを確認するには、Openmix Decision Report に移動します。プライマリディメンションとして Application を、セカンダリディメンションとして Version を選択します。次に、リストからアプリケーションを選択した後、Apply Filters をクリックします。チャートには、アプリケーションの異なるバージョンのパフォーマンスが表示されます。

このバージョンのアプリのパフォーマンスに満足したら、Go Live ボタンをクリックして、Web トラフィックの 100% をこのバージョンを通じてルーティングできます。

このバージョンは、現在のライブバージョンを新しく編集されたバージョンに置き換えます。

このバージョンで公開したくない場合は、Unpublish をクリックします。変更は保存され、Openmix Configuration ページのアプリリストに未公開のアプリとして表示されます。これで、Web トラフィックの 100% が現在のライブバージョンのアプリを通じて流れます。

テスト

JavaScript アプリケーションは、公開前または公開後に Test App ボタンを使用してテストできます。

これにより、特定の市場、国、地域、および州のセット全体でテスト結果を表示できます。特定の IP アドレスからアプリを照会できます。

テスト結果には、アプリによって選択された Platform、受信した Response、Reason Code、Reason Log、Radar Scores、Distribution などが含まれます。

この機能により、異なるプラットフォーム間での決定の分布を表示することもできます。たとえば、ルーティングに 2 つのプラットフォームが使用されている場合、それぞれの決定数と受信した応答を表示できます。

Show All Details リンクをクリックすると、アプリのテスト結果が表示されます。

テスト結果として以下の値が表示されます。

注: このテストは、ライブアプリまたは未公開バージョン (つまり、アプリがまだ公開されていない場合) で実行できます。

アプリが公開されると、Test Live App オプションをクリックしてライブアプリをテストするオプションがあります。アプリを編集したり、新しいバージョンをアップロードしたりした場合、Test Unpublished App ボタンをクリックして公開前にテストできます。

アプリケーション検証

カスタム JavaScript アプリが期待どおりに動作することを確認するために、ITM ポータルにアップロードするときに、コードおよびロジック検証ツールを通じてアプリを実行します。アプリケーション検証ツールは、アプリケーションがコンパイルおよび正常に実行されるかどうかをテストするために、合成トラフィックを使用して決定サーバーを通じてアプリを実行します。

アプリケーションがエラーなしで実行された場合、検証ツールは決定分布と実行特性に関する情報を提供します。一方、決定サーバーがアプリの実行中にエラーに遭遇した場合、検証ツールはエラーに関する情報を提供します。公開する前に、アプリケーションにエラーがないことをお勧めします。

エラーが発生した場合は、ローカルで JavaScript ファイルを修正し、Choose File ボタンをクリックしてポータルに再アップロードできます。

公開

アプリを公開してライブにするには、Publish ボタンをクリックします。このオプションは、アプリがまだ保存されていないか、すでに公開されている場合はグレー表示されます。アプリがライブになると、Openmix アプリケーションマネージャーページに緑色のステータスで表示されます。アプリのステータスの詳細については、「アプリケーションのステータス」セクションをご参照ください。

注: 必要に応じて、アプリはエラーがあっても公開されます。

カスタム JavaScript アプリケーションの管理

アプリケーションマネージャーパネル内の上部のタブを使用して、レポートの表示、編集、複製、削除、公開、ソースの表示、ライブバージョンの表示、履歴の表示を行います。

Openmix アプリケーションリストページでアプリをクリックすると、アプリケーションマネージャーパネルが展開されます。

レポートの表示

View Report をクリックすると、Openmix Decision Reports ページに移動し、各アプリ、プラットフォーム、および地理の Openmix 決定の傾向を表示できます。

編集

Openmix カスタム Javascript アプリを編集するには、アプリ名 (Openmix アプリケーションリストページ内) をクリックします。アプリケーションマネージャーパネルが開きます。Edit アイコンをクリックすると、構成に変更や更新を加えることができます。

ソースの表示

View Source を使用すると、アプリの JavaScript ソース、つまり公開されたかどうかにかかわらず、アプリの最新バージョンを表示できます。このオプションは、カスタム JavaScript アプリでのみ利用できます。

ライブバージョンの表示

アプリの最新の公開バージョンを表示、コピー、およびダウンロードできます。このオプションは、カスタム JavaScript アプリでのみ利用できます。

アプリケーション履歴

Application History を使用すると、アプリの異なるバージョンを表示できます。Select a Version リストを使用して、ライブバージョンから古いバージョンに切り替えることができます。Get Content をクリックすると、古いバージョンに切り替わります。このオプションは、カスタム JavaScript アプリでのみ利用できます。

比較

Compare 機能を使用すると、JavaScript ファイルの異なるバージョンを比較できます。スクリプトの強調表示された行で、アプリの 2 つのバージョン間の違いが明確に表示されます。

削除

Openmix アプリを削除するには、アプリ名 (Openmix アプリケーションリストページ内) をクリックします。アプリケーションマネージャーパネルが開きます。Delete アイコンをクリックし、確認ダイアログボックスで Delete ボタンを選択します。アプリはリストから消えます。

アプリの復元

Restore App 機能を使用すると、削除されたアプリを再度有効にできます。 アプリを復元するには、次の手順を実行します。

1. ページの右上にある Add + アイコンをクリックします。

2. ドロップダウンメニューから Restore App を選択します。Restore Application ウィンドウが開きます。

   

3. リストから再度有効にしたいアプリを見つけ、対応する Restore ボタンをクリックします。

アプリは、同じステータスで Openmix ページのリストに戻されます。

ローカル永続性

ローカル永続性機能は、Openmix アプリケーションで有効になっている場合に、決定のスティッキネス機能を提供します。リクエストは、構成可能な長さの IP サブネットマスクを使用して識別されます。たとえば、クライアントが一定期間内に同じアプリケーションにリクエストを繰り返した場合、元の決定が返されます。これは、クライアントが特定のセッション中に異なる決定間でバウンスしないようにする必要がある場合に不可欠な機能です。DNS または HTTP Openmix アプリケーションの両方で利用できます。

メカニズムの根底にある自然な制限により、永続性はリクエストの 100% で保証されません。代わりに、最善の努力アプローチが適用されます。テストでは、予想される永続性の精度が 95〜97% の範囲であることが示されています。

注:

アカウントでローカル永続性機能を有効にするには、サポートチケットを開くか、カスタマーサクセスマネージャーにお問い合わせください。さらに、ネームサーバー ns5.cedexis.net および ns6.cedexis.net で構成された予測 DNS ゾーンが必要です。DNS ゾーンの更新がインターネット全体に伝播するのにかかるかなりの時間を考慮してください。

設定

ローカル永続性を有効にするには、Openmix アプリケーションオプションの下にある Persistency Controls > Edit を選択します。

利用可能な設定は次のとおりです。

1. Configuration ダイアログボックスで、Persistency TTL を入力します。デフォルトオプションは 300 秒です。60 から 1440 の値が許可されます。最初のリクエストの後、提供された DNS 決定は最大 300 秒間保持されます。有効期限が切れる前に同じ IP サブネット範囲から別のリクエストがシステムに送信された場合、同じ決定が提供されます。

2. IPv4 と IPv6 の両方のマスクが、永続性のスティッキネスの粒度を設定するために提供されています。デフォルトは、IPv4 の場合は “/32”、IPv6 の場合は “/64” です。許可される値は次のとおりです。

   • IPv4 の場合、/8 から /32 まで
   • IPv6 の場合、/32 から /64 まで

   クライアントの IP アドレスに対するこのマスキングは、内部データストアで使用される永続性キーを決定します。たとえば、2 つ (またはそれ以上) のクライアント IP が同じマスクされた IP アドレスにマップされる場合、それらは同じ永続的な決定で提供されます。

同じ設定は、予測アプリケーション設定の下でも利用できます。

内部データストアを介して提供される Openmix の決定は、決定レポートで理由コード Persistent app とともに報告されます。

ヘルスチェック

永続性キャッシュから提供される決定は、提供される前に追加のヘルスチェックの対象となります。

1. アプリケーションが Sonar Availability Check で構成されている場合、キャッシュされた決定が提供される前に Sonar の可用性ヘルスがチェックされます。Sonar がプラットフォームが「ダウン」していると報告した場合、キャッシュされた決定は無視され、OpenMix アプリケーションが再度実行されます。

2. アプリケーションが Radar Availability Check で構成されている場合、キャッシュされた決定が提供される前に Radar の可用性ヘルスがチェックされます。プラットフォームの可用性が構成されたしきい値よりも低い場合、キャッシュされた決定は無視されます。

注:

永続性の場合、Radar 可用性ヘルスの最大しきい値は固定の 10% に設定されています。

Openmix HTTP API の保護

Openmix は、DNS または HTTP API を介して、非 DNS ワークフローに統合できます。デフォルトでは、HTTP API はプレーン HTTP 経由で呼び出されます。API は、TLS とキー認証を介して保護することもできます。これは、Require Secure API Access (HTTPS) のチェックボックスをオンにすることで、UI を介して行われます。

API キーの作成

キー認証を有効にするには、次の手順を実行します。

1. Openmix Application Configuration ページで Require Secure API Access (HTTPS) ボックスを選択して、各アプリケーションのセキュアアクセスをオンにします。

2. セキュアアクセスキーを生成するには、My Account -> API -> Openmix HTTP API Keys に移動します。

   

3. 初めてのユーザーの場合、クライアント ID を入力して開始するように求められます。New Client ダイアログに Client ID を入力し、Complete をクリックします。

4. Client Secret キーは、Openmix HTTP API Authentication Configuration ページの Client ID の横に表示されます。

5. これで、基本認証を使用して Openmix アプリにリクエストを行うことができます。ブラウザでアプリを呼び出すには、Client ID をユーザー名として、Client Secret をパスワードとして使用します。

   コマンドラインを使用してアプリを呼び出すには、次の cURL コマンドを使用します。

   curl https://hopx.cedexis.com/zones/<zone>/customers/<customer_id>/apps/<app_id>/decision --user <client_key>:<client_secret>
   <!--NeedCopy-->
   

注: 作成したキーは、Openmix アプリケーションのいずれかへのアクセスを許可します。

Openmix HTTP API の呼び出しの詳細については、Openmix HTTP API の使用に関するドキュメント をご参照ください。

API キーの削除

1. キーを削除するには、Openmix HTTP API Authentication Configuration ページに移動します。
2. Client ID をクリックします。
3. リストで Delete を選択します。キーはシステムから削除されます。これは、Openmix アプリケーションへの認証またはセキュアアクセスには無効です。

ログへのアクセス

Openmix によって行われた決定ログは収集され、セキュアなダウンロードのために利用可能にすることができます。これらのログは、Openmix アプリケーションによって行われた決定を分析し、リクエストの動作をデバッグするのに役立ちます。ログは、アカウントレベルでオン/オフを切り替え、保護することができます。Openmix ログを有効にしてダウンロードする方法と、ログの説明については、Netscope をご参照ください。

Openmix レポート

Openmix レポートは、DNS または HTTP トラフィックに対して行われた Openmix の決定に関する強力な可視性を提供します。各レポートは以下のセクションで定義されていますが、レポートに関するいくつかの重要な側面を以下に示します。

プライマリおよびセカンダリディメンション

チャートのプライマリディメンションは、チャートの上にあるリストを通じて選択されます。このリストをレポートの強力なピボットとして使用します。レポートをさらに絞り込むために、セカンダリディメンションも選択できます。

可視化背景の切り替え

チャートはデフォルトで白い背景に設定されています。背景を暗い色に切り替えて、高コントラストモニターに対応します。

データのエクスポート

さらに、エンドユーザーは、レポートの上部にあるダウンロードリンクを介して、チャートとテーブルデータをダウンロードできます。

フィルター: レポート期間

過去 60 分、24 時間、48 時間、7 日間、30 日間、またはカスタム範囲の期間でレポートを生成できます。デフォルトの表示は過去 24 時間です。

フィルター: 強力なドリルダウン機能

レポートは、データに基づいて適切なフィルターの点でわずかに異なります。最も一般的なものは次のとおりです。

• Statistic - チャートに表示される値を選択します。ほとんどの場合、決定の数です。
• Traffic Source – 表示するトラフィックのタイプ (DNS または HTTP) を選択します。
• Application – 表示する 1 つ以上の Openmix アプリケーションを選択します。
• Platform – 含める 1 つ以上のプラットフォーム (プロバイダー) を選択します。
• Continent – 含める 1 つ以上の大陸を選択します。
• Country – 含める 1 つ以上の国を選択します。
• Region – 含める 1 つ以上の地理的地域 (該当する場合) を選択します。
• State – 含める 1 つ以上の地理的州 (該当する場合) を選択します。
• Network – 含める 1 つ以上のネットワーク (ASN) を選択します。

ベネフィットレポート

ベネフィットレポートは、NetScaler Intelligent Traffic Management (ITM) サービスを使用した場合のアプリケーション配信パフォーマンスの全体的な改善を示します。ベネフィットは、応答時間とスループットの改善率として表示されます。レポートを生成するために、候補プラットフォームのプールから特定のプラットフォームを選択します。

ベネフィットレポートのプライマリディメンション

プライマリディメンションは、ベネフィットレポートが表示される独立した測定値です。以下のセクションでは、これらのプライマリディメンションのそれぞれについて詳しく説明します。

概要

Summary はデフォルトのプライマリディメンションです。概要チャートは、すべてのアプリケーションから受け取った合計パーセンテージベネフィット (応答時間またはスループットの観点から) の平均を示します。

注: Statistic フィルターを使用して、応答時間またはスループットの観点から表示されるベネフィットを切り替えることができます。

アプリケーション

Application がプライマリディメンションとして選択されている場合、チャートには各アプリケーションと、特定のプラットフォームを他の候補プラットフォームよりも選択した場合の対応するパフォーマンス (応答時間またはスループットの観点から) がパーセンテージベネフィットとして表示されます。

注: 0% は、特定のプラットフォームを他のプラットフォームよりも選択することによる追加のベネフィットや改善がなかったことを意味します。

ロケーション (大陸、国、地域、州)

ロケーション (Continent、Country、Region、または State) がプライマリディメンションとして選択されている場合、ベネフィットレポートは、各ロケーションのパフォーマンス (応答時間またはスループットの観点から) の合計パーセンテージ改善の平均を示します。大陸、国、地域、または州別にロケーションを選択できます。

注: ジオルールまたはその他の理由により選択できないプラットフォームは、計算に含まれません。ただし、問題のロケーションに対してジオフェンスされたプラットフォームはカウントされます。

ネットワーク

Network をプライマリディメンションとして選択すると、ユーザーが ITM にアクセスする特定のネットワーク (またはサービスプロバイダー) にグループ化されたユーザーのパフォーマンスの改善率が表示されます。これにより、どのユーザーグループがそれらの特定のネットワークからのパフォーマンスの恩恵を受けているかを知ることができます。

プラットフォーム

Platform をプライマリディメンションとして選択すると、異なるアプリによって選択された個々のプラットフォームと、それらが選択されたときの対応する改善されたパフォーマンスが表示されます。改善されたパフォーマンスまたはベネフィットは、応答時間またはスループット (パーセンテージ) の観点からです。

注: チャートに表示されるパフォーマンスの改善率は、アプリがそのプラットフォームを選択したときに示されます。リストは、これらのプラットフォーム間のパフォーマンスランキングを必ずしも示すものではありません。

理由コード

Reason Code をプライマリディメンションとして選択すると、チャートに表示されるパーセンテージは、特定の理由コードに対して決定が下された場合の全体的な平均ベネフィットです。

ベネフィットレポートでプラットフォームを無視

Openmix の決定の精度を向上させるために、ベネフィットレポートでは、特定のプラットフォームを無視し、比較に最も適したプラットフォームのみから選択するようにアプリを設定できます。

たとえば、アプリケーションに比較対象として 5 つのプラットフォームがあるとします。ヨーロッパのトラフィック用にヨーロッパに 3 つ、米国のトラフィック用に米国に 2 つです。ジオルールでは、ヨーロッパのトラフィックはヨーロッパのプラットフォームを介して、米国のトラフィックは米国のプラットフォームを介してルーティングされるように指定されています。

計算が 3 つのヨーロッパのプラットフォームを使用して行われることを確実にするために、他の 2 つの非ヨーロッパのプラットフォームを無視するようにアプリを設定できます。JavaScript で ignoredProvider() メソッドを使用します。

このメソッドは、プロバイダーのエイリアス (例: provider-1、provider-2) を入力引数として取ります ( requireProvider() メソッドと非常によく似ています)。API はエイリアスごとに 1 回呼び出す必要があります。

JavaScript ファイルの onRequest 関数内でこのサンプルコードを使用します。

function onRequest(request, response) {
  response.ignoredProvider('provider-1');
  response.ignoredProvider('provider-2');
  response.setReasonCode('Ignoring provider-1 and provider-2');
  response.setTTL(this.__defaultTTL);
  response.respond('provider-3', 'cmg.test.fake.cname');
}
<!--NeedCopy-->

決定地理ロケーションレポート

このレポートは、国ごとの Openmix 決定のボリュームを示します。このマップビューは、チャートの下部にある Play ボタンを選択することで、時間経過とともに (レポートに選択された期間に基づいて) 表示できます。

決定レポート

このレポートは、各アプリケーション、プラットフォーム、および地理の Openmix 決定の傾向を示します。