Citrix ADC とAmazon Web Services 検証済みのリファレンスデザイン

概要:Citrix Networking VPX

Citrix ADCはオールインワンのアプリケーションデリバリーコントローラーで、アプリケーションの実行速度を最大5倍向上させ、アプリケーションの所有コストを削減し、ユーザーエクスペリエンスを最適化し、以下を使用してアプリケーションを常に利用できるようにします。

• 高度な Layer4-7 負荷分散とトラフィック管理
• HTTP 圧縮やキャッシュなど、実証済みのアプリケーションアクセラレーション
• アプリケーションセキュリティのための統合アプリケーションファイアウォール
• サーバオフロードによるコストの大幅な削減とサーバの統合

サービスとアプリケーションデリバリのリーダーとして、Citrix ADCは世界中の何千ものネットワークに展開され、エンタープライズおよびクラウドサービスの提供を最適化し、セキュリティで保護し、制御しています。Citrix ADC、Webサーバーとデータベースサーバーの前に直接導入され、高速負荷分散とコンテンツスイッチング、HTTP圧縮、コンテンツキャッシュ、SSLアクセラレーション、アプリケーションフローの可視性、強力なアプリケーションファイアウォールを統合した使いやすい統合プラットフォームに統合されています。ネットワークデータを実用的なビジネスインテリジェンスに変換するエンドツーエンドの監視により、SLA への対応が大幅に簡素化されます。Citrix ADCでは、プログラミングの専門知識を必要とせずに、シンプルな宣言型ポリシーエンジンを使用してポリシーを定義および管理できます。

Amazon Web Services における Citrix ADC の概要

Amazon Web Services（AWS）内のCitrix Networking VPXのサポートは、バージョン10.5～61.11以降でご利用いただけます。Citrix Networking VPXは、AWSマーケットプレイスでAmazonマシンイメージ（AMI）として入手できます。Citrix Networking VPX on AWSを使用すると、お客様はAWSクラウドコンピューティング機能を活用し、Citrix ADC 負荷分散機能とトラフィック管理機能をビジネスニーズに使用できます。Citrix ADC on AWSは、物理Citrix ADCアプライアンスのすべてのトラフィック管理機能をサポートします。AWSで実行されているCitrix ADCインスタンスは、スタンドアロンインスタンスとして、またはHAペアでデプロイできます。

Citrix Networking VPX AMIは、AWS VPC内で起動されるEC2インスタンスとしてパッケージ化されています。このVPX AMIインスタンスには2つ以上の仮想CPUと2GB以上のメモリが必要です。また、AWS VPC内で起動されるEC2インスタンスは、複数のインターフェイス、インターフェイスごとに複数のIPアドレス、VPX構成に必要なパブリックおよびプライベートIPアドレスも提供できます。現在、AWSでは、各VPXインスタンスには少なくとも3つのIPアドレスが必要なため、VPXはVPC内でのみ起動できます。（AWSのVPXは1つまたは2つのエラスティックなネットワークインターフェイスを使用して実装することもできますが、標準的なAWSのVPXでは3つのネットワークインターフェイスを使用することをお勧めします）。AWSでは現在、AWS VPC内で実行しているインスタンスについてのみ複数のIPを使用する機能をサポートしています。VPC内のVPXインスタンスを使用して、EC2インスタンスで実行しているサーバーの負荷を分散できます。

Amazon VPCを使用すれば、独自のIPアドレス範囲、サブネット、ルートテーブル、ネットワークゲートウェイなどを含めて、仮想ネットワーク環境を作成および管理できます。

注：

デフォルトでは、各AWSアカウントのAWSリージョンごとに最大5つのVPCインスタンスを作成できます。 Amazonのリクエストフォームを送信すると、VPC制限の引き上げをリクエストできます。

Citrix Networking VPX（AMIイメージ）のEC2インスタンスは、AWS VPC内で起動されます。

次の図は、AWSでの一般的なVPXの展開を示しています。

この図は、Citrix Networking VPXがデプロイされたAWS VPCの簡単なトポロジーを示しています。AWS VPCは、以下の要素で構成されています。

1. VPCからの送受信トラフィックをルーティングするための単一のインターネットゲートウェイ。
2. インターネットゲートウェイとインターネット間のネットワーク接続。
3. 3つのサブネット（管理、クライアント、サーバー用に1つずつ）。
4. インターネットゲートウェイと2つのサブネット（管理用とクライアント用）間のネットワーク接続。
5. VPC内にデプロイされた単一のCitrix Networking VPX。VPXインスタンスには、各サブネットに1つずつ接続されたENI（Elastic Network Interface：エラスティックネットワークインターフェイス）が3つあります。

制限事項と使用上のガイドライン

• クラスタリング機能は、VPXではサポートされていません。
• 高可用性機能を正しく使用するには、管理インターフェイスに専用のNATデバイスを関連付けるか、EIPをNSIPに関連付けてください。NAT の詳細については、「NAT インスタンス AWS ドキュメント」を参照してください。
• 異なるサブネットに属するENIを使用して、データトラフィックと管理トラフィックを分離する必要があります。
• 管理ENIには、NSIPアドレスだけを設定する必要があります。
• セキュリティ上の理由により、EIPをNSIPに関連付ける代わりにNATインスタンスを使用する場合は、VPCレベルでルーティングを適切に変更する必要があります。VPC レベルのルーティングの変更手順については、AWS ドキュメントの「 シナリオ 2: パブリックサブネットとプライベートサブネットを持つ VPC」を参照してください。
• VPXインスタンスは、あるEC2インスタンスタイプから別のインスタンスタイプに移動できます (たとえば、 m3.largeからm3.xlargeへ)。
• AWSでのVPXのストレージには、永続的でインスタンスから切断した後もデータにアクセス可能なEBSをお勧めします。
• VPXへのENIの動的追加はサポートされていません。更新を適用するには、VPXインスタンスを再起動する必要があります。スタンドアロンインスタンスまたはHAインスタンスを停止し、新しいENIを接続してからインスタンスを再起動することをお勧めします。
• 1つのENIに複数のIPアドレスを割り当てることができます。ENIごとのIPアドレスの最大数は、EC2インスタンスの種類によって異なります。「ENIおよびIPアドレスのEC2サポート」を参照してください。
• Citrix Networking VPXインターフェイスでは、インターフェイスの有効化および無効化コマンドは使用しないことをお勧めします。

AWS の制限により、次の機能はサポートされていません。

レイヤ 3 の制限事項

• 動的ルーティング
• IPV6

レイヤ 2 の制限事項:

• GARP（Gratuitous ARP）
• L2モード
• タグ付きVLAN
• 仮想MAC（VMAC）

サポートされている EC2 インスタンス、ENI、および IP アドレス容量

Citrix ADC AMI は、次のどの EC2 インスタンスタイプでも起動できます。この表は、サポートされている各 EC2 インスタンスタイプと、それに対応するサポートされている ENI の数、および ENI ごとのプライベート IPv4 アドレスの数を示しています。

* 優先インスタンスタイプ

詳細については、「 Amazon EC2 インスタンス」を参照してください。

使用例

各サービスを個別の仮想アプライアンスとして展開する必要がある代替ソリューションと比較して、Citrix ADC on AWSは、L4負荷分散、L7トラフィック管理、サーバーオフロード、アプリケーションアクセラレーション、アプリケーションセキュリティ、およびその他の重要なアプリケーション配信機能を単一のVPXに統合します。インスタンスを作成し、AWS Marketplace から便利に利用できます。さらに、すべてが単一のポリシーフレームワークによって管理され、オンプレミスのCitrix ADC展開を管理するのと同じ強力なツールセットで管理されます。その結果、Citrix ADC on AWS では、今日の企業の即時ニーズをサポートするだけでなく、レガシーコンピューティングインフラストラクチャからエンタープライズクラウドデータセンターへの継続的な進化をサポートするいくつかの魅力的なユースケースが可能になります。

Web アプリケーション、仮想アプリケーション、およびデスクトップアプリケーションのプロダクション配信

アプリケーションのプロダクション配信に AWS をサービスとしてのインフラストラクチャ (IaaS) として積極的に採用している企業は、世界最大のウェブサイトやクラウドサービスプロバイダーが使用しているのと同じクラウドネットワーキングプラットフォームを使用して、それらのアプリケーションをフロントエンドで利用できるようになりました。広範なオフロード、アクセラレーション、およびセキュリティ機能を活用して、パフォーマンスを向上させ、コストを削減できます。

Citrix Desktops as Serviceは、あらゆるWindowsアプリケーションやデスクトップを、あらゆるネットワークやデバイスに配信されるクラウドサービスに配信するためのクラウド対応ソリューションです。この拡張されたアプリケーションおよびデスクトップ配信プラットフォームを今すぐ導入することで、あらゆる仮想インフラストラクチャやクラウド管理プラットフォームを活用できるようになります。これにより、クラウドコンピューティングの自動化機能とオーケストレーション機能を活用できます。

ハイブリッドクラウド設計

ハイブリッドクラウド戦略を採用している企業のIT組織は、プライベートクラウドに最も適したアプリケーションと使用シナリオ、パブリッククラウドに最も適したアプリケーションと使用シナリオを選択することで、両方の長所を最大限に活用できます。これにより、現代の職場の要求に合わせて柔軟に、成長し、変革することができます。

Citrix ADC on AWSを使用すると、企業のデータセンターをまたがってAWSにまで拡張するハイブリッドクラウドでも、同じクラウドネットワークプラットフォームの恩恵を受けることができます。Citrix ADCを使用すると、プライベートデータセンターとAWS間でのアプリケーションとワークロードの移行が大幅に容易になります。DataStreamによるインテリジェントなデータベース負荷分散から、AppFlow® による前例のないアプリケーションの可視性、アクション分析によるリアルタイムの監視と対応に至るまで、あらゆる機能をAWS上のCitrix ADCで活用できます。

事業継続性

災害復旧計画や事業継続計画の一環として AWS を使用したいと考えている企業は、オンプレミスと AWS 内の両方で実行される Citrix ADC グローバルサーバー負荷分散を利用して、エンタープライズデータセンターと AWS 環境の両方の可用性とパフォーマンスを継続的に監視し、ユーザーを保護できます常に最適な場所に送られます。

Citrix ADCアプライアンスでGSLBを構成し、メトリック交換プロトコル（MEP）を有効にすると、アプライアンスはDNSインフラストラクチャを使用して、設定した基準に最も合致するデータセンターにクライアントを接続します。この基準では、負荷が最も少ないデータセンター、最も近いデータセンター、クライアントロケーションからのリクエストに最も迅速に応答するデータセンター、それらのメトリックの組み合わせ、および SNMP メトリックを指定できます。アプライアンスは各データセンターの場所、パフォーマンス、負荷、可用性を追跡し、これらの要素を使用してクライアントリクエストを送信するデータセンターを選択します。GSLB構成は、構成内の各アプライアンス上のGSLBエンティティのグループで構成されます。これらのエンティティには、GSLB サイト、GSLB サービス、GSLB 仮想サーバー、負荷分散および/またはコンテンツスイッチングサーバー、および ADNS サービスが含まれます。

開発とテスト

企業はオンプレミスで本番環境を配信していますが、開発とテストに AWS を使用することで、Citrix ADC を AWS テスト環境に組み込むことができるようになり、テスト環境内の本番環境での実装をより適切に模倣できるため、本番稼働までの時間を短縮できます。

いずれのユースケースでも、ネットワークアーキテクトは、スタンドアロンインスタンスとして、または Citrix ADC プラチナエディションインスタンスの機能として構成された Citrix CloudBridge を活用して、1 つ以上のエンタープライズデータセンターと AWS クラウド間の接続を保護および最適化することで、データ転送を高速化することもできます/同期とネットワークコストの最小化。

AWS ネットワークアーキテクチャ — ENI と EIP

VPC 内で起動された Citrix ADC インスタンスは、最大 8 つのエラスティックネットワークインターフェイス (ENI) を持つことができます。次に、各 ENI に 1 つ以上のプライベート IP アドレスを割り当てることができます。これらのそれぞれは、オプションで、パブリックにルーティング可能な Elastic IP アドレスにマッピングされます。

この場合、ネットワークインターフェイスと IP アドレスを「伸縮自在な」ものにしているのは、それらを他のインスタンスにプログラムで再マッピングする機能です。これは、ハードウェアの交換や DNS の変更がすべてのインスタンスに完全に伝達されるのを待たずに、インスタンスまたはアベイラビリティーゾーンの障害から復旧できる機能です。あなたの顧客。

考慮すべきその他の詳細は次のとおりです。

• インスタンスはサブネットごとに異なる ENI を持つことができます (ただし、アベイラビリティーゾーンが異なることはできません)。
• 各 ENI には、少なくとも 1 つの IP アドレスが割り当てられていて、セキュリティグループ (以下を参照) に割り当てられている必要があります。
• 各サブネットのアドレス 1 ～ 4 (つまり 10.x.x.1-4) は、Amazon が使用できるように予約されています。
• Citrix ADCはプライベートIPアドレスのみを認識します。割り当てられたEIPは、Citrix ADC CLIまたは関連する管理ツールには表示されません。

EC2 対 VPC

AWS には、Amazon シンプルストレージサービス (S3)、Amazon Elastic Compute Cloud (EC2)、Amazon Virtual Private Cloud クラウド (VPC) など、複数の異なるサービスが含まれています。この場合、後者の 2 つの区別が重要です。特に EC2 では、仮想マシンインスタンスは 1 つのネットワークインターフェイスと 1 つの IP アドレスに制限されます。さらに、最小限のネットワーク機能と制御しかありません。これにより、Citrix ADC (最低 3 つの IP アドレスが必要) に EC2 を使用できなくなります。そのため、Citrix ADC インスタンスは AWS VPC 内でのみ起動できます。

VPC は、複数のインターフェイスと複数のプライベート IP アドレスとパブリック IP アドレスを持つ仮想マシンをサポートするだけでなく、独自の IP アドレス範囲、サブネット、ルーティングテーブル、ネットワークゲートウェイを使用して、分離された仮想ネットワーク環境を作成して制御することもできます。

リージョンとアベイラビリティーゾーン

AWS クラウド内では、リージョンは米国東部などの特定の地理的位置を指します。各リージョン内には少なくとも 2 つのアベイラビリティーゾーンがあります。各ゾーンは、他のアベイラビリティーゾーンでの障害から隔離され、他のアベイラビリティーゾーンへのネットワーク接続を安価で低レイテンシーで提供するように設計された、独立したクラウドデータセンターと考えることができます。同じ地域。

インスタンスを別々のアベイラビリティーゾーンに実装することで、1 つの場所に影響する障害からアプリケーションを保護できます。

ネットワーク設計者がこのレベルで認識しておくべき制限と依存関係には、次のものがあります。

• 仮想プライベートクラウドは複数のアベイラビリティーゾーンにまたがることができますが、複数のリージョンにまたがることはできません。
• VPC 内の個々のサブネットが複数のアベイラビリティーゾーンにまたがることはできません。
• VPC に出入りするすべてのトラフィックは、対応するデフォルトのインターネットゲートウェイ経由でルーティングされる必要があります

AWSでVPXを設定

この演習では、VPC とサブネットを作成し、サブネット内でパブリック向けのインスタンスを起動します。インスタンスはインターネットと通信できるようになり、SSH (Linux インスタンスの場合) またはリモートデスクトップ (Windows インスタンスの場合) を使用してローカルコンピュータからインスタンスにアクセスできるようになります。実際の環境では、このシナリオを使用して、ブログをホストするなど、一般向けのウェブサーバーを作成できます。

注：

この演習は、デフォルト以外の VPC をすばやくセットアップできるようにすることを目的としています。すでにデフォルト VPC があり、その中でインスタンスの起動を開始する（新しい VPC の作成や設定ではない）場合は、「 デフォルト VPC への EC2 インスタンスの起動」を参照してください。

この演習を完了するには、次の操作を行います。

• 1 つのパブリックサブネットを持つデフォルト以外の VPC を作成します。サブネットを使用すると、セキュリティや運用上のニーズに基づいてインスタンスをグループ化できます。パブリックサブネットは、インターネットゲートウェイを介してインターネットにアクセスできるサブネットです。
• 特定のポートからのトラフィックのみを許可するセキュリティグループをインスタンスに作成します。
• Amazon EC2 インスタンスをサブネットで起動します。
• Elastic IP アドレスをインスタンスに関連付けます。これにより、インスタンスはインターネットにアクセスできるようになります。

Amazon VPC を初めて使用する前に、AWS にサインアップする必要があります。サインアップすると、AWS アカウントは、Amazon VPC を含む AWS のすべてのサービスに自動的にサインアップされます。AWS アカウントをまだ作成していない場合は、 http://aws.amazon.comにアクセスし、[ 無料アカウントを作成] を選択します。

手順 1: VPC を作成する

このステップでは、Amazon VPC コンソールの Amazon VPC ウィザードを使用して VPC を作成します。ウィザードは次のステップを自動的に実行します。

• /16 CIDR ブロック (65,536 個のプライベート IP アドレスを持つネットワーク) を持つ VPC を作成します。CIDR 表記と VPC のサイズ設定の詳細については、「Your VPC」を参照してください。
• インターネットGateway を VPC にアタッチします。インターネットゲートウェイの詳細については、「 インターネットゲートウェイ」を参照してください。
• VPC 内にサイズ /24 のサブネット（256 のプライベート IP アドレスの範囲）を作成します。
• カスタムルートテーブルを作成し、サブネットに関連付けて、サブネットとインターネットGateway の間でトラフィックが流れるようにします。ルートテーブルの詳細については、「 ルートテーブル」を参照してください。

次の図は、この手順を完了した後の VPC のアーキテクチャを示しています。

Amazon VPC ウィザードを使用して VPC を作成する

1. https://console.aws.amazon.com/vpc/で Amazon VPC コンソールを開きます。

2. ナビゲーションバーの右上に、VPC を作成するリージョンをメモします。別のリージョンから VPC にインスタンスを起動することはできないため、この演習の残りの部分でも同じリージョンで作業を継続してください。リージョンの詳細については、「 リージョンとアベイラビリティーゾーン」を参照してください。

3. ナビゲーションペインで、[VPC Dashboard] を選択し、 [VPC ウィザードの開始]を選択します。

   

   注：

   ナビゲーションペインで [Your VPC] を選択しないでください。このページから VPC ウィザードにアクセスすることはできません。

4. 最初のオプション [ 単一のパブリックサブネットを持つ VPC] を選択し、 [選択] を選択します。

5. 設定ページで、VPC 名フィールドに VPC の名前 (例:my-vpc) を入力し、[サブネット名] フィールドにサブネットの名前を入力します 。これにより、VPC とサブネットを作成した後に Amazon VPC コンソールで識別できます。この演習では、ページの残りの設定はそのままにして、[ Create VPC] を選択できます。

   (オプション) 必要に応じて、次のように構成設定を変更し、[ Create VPC] を選択できます。

   • IP CIDR ブロックには VPC に使用する IP アドレス範囲 (10.0.0.0/16) が表示され、パブリックサブネットフィールドにはサブネットに使用する IP アドレス範囲 (10.0.0.0/24) が表示されます。デフォルトの CIDR 範囲を使用しない場合は、独自の CIDR 範囲を指定できます。詳細については、「 VPC とサブネットのサイズ設定」を参照してください。

   • [Availability Zone] リストでは、サブネットを作成するアベイラビリティーゾーンを選択できます。[No Preference] のままにしておくと、アベイラビリティーゾーンが AWS によって選択されます。詳細については、「 リージョンとアベイラビリティーゾーン」を参照してください。

   • [S3 のエンドポイントをサブネットに追加する] セクションで、同じリージョンの Amazon S3 に VPC エンドポイントを作成するサブネットを選択できます。詳細については、「 VPC エンドポイント」を参照してください。

   • Enable DNS hostnamesオプションを [Yes] に設定すると、VPC 内で起動されるインスタンスが DNS ホスト名を受け取ります。詳細については、「 VPC で DNS を使用する」を参照してください。

   • [Hardware tenancy] オプションでは、VPC 内で起動されるインスタンスを共有ハードウェアで実行するか、専用ハードウェアで実行するかを選択できます。専用テナンシーを選択すると、追加コストが発生します。ハードウェアテナンシーの詳細については、「 ハードウェア専有インスタンス」を参照してください。

6. ステータスウィンドウには、進行中の作業が表示されます。作業が完了したら、「 OK」 を選択してステータスウィンドウを閉じます。

7. Your VPCs pageには、デフォルトの VPC と作成したばかりの VPCが表示されます。作成した VPC はデフォルト以外の VPC であるため、 Default VPC 列には No と表示されます。

VPC に関する情報を表示する

VPC を作成すると、サブネット、インターネットゲートウェイ、ルートテーブルに関する情報を表示できます。作成した VPC には 2 つのルートテーブルがあります。1 つはすべての VPC がデフォルトで持つメインルートテーブルで、もう 1 つはウィザードによって作成されたカスタムルートテーブルです。カスタムルートテーブルはサブネットに関連付けられます。つまり、そのテーブルのルートによって、サブネットのトラフィックがどのように流れるかが決まります。VPC に新しいサブネットを追加すると、デフォルトでメインルートテーブルが使用されます。

VPC に関する情報を表示するには

1. https://console.aws.amazon.com/vpc/で Amazon VPC コンソールを開きます。
2. ナビゲーションペインで [ Your VPC] を選択します。作成した VPC の名前と ID をメモしておきます ([名前] 列と [VPC ID] 列を参照)。この情報を使用して、VPC に関連付けられているコンポーネントを特定します。
3. ナビゲーションペインで [ サブネット] を選択します。コンソールには、VPC を作成したときに作成されたサブネットが表示されます。サブネットは [Name] 列で名前で識別できます 。または、前のステップで取得した VPC 情報を使用して VPC 列を確認することもできます。
4. ナビゲーションペインで、「 インターネットゲートウェイ」を選択します。VPC にアタッチされているインターネットゲートウェイは、VPC 列を見ると、VPC の ID と名前 (該当する場合) が表示されます。
5. ナビゲーションペインで [ Route Tables] を選択します。VPC には 2 つのルートテーブルが関連付けられています。カスタムルートテーブルを選択し ([メイン] 列に [いいえ] と表示されます)、[ルート] タブを選択すると、詳細ペインにルート情報が表示されます。
   • 表の最初の行は、VPC 内のインスタンスが通信できるようにするローカルルートです。このルートはデフォルトですべてのルートテーブルに存在し、削除することはできません。
   • 2 行目は、VPC 外の IP アドレス (0.0.0.0/0) を宛先とするトラフィックがサブネットからインターネットゲートウェイに流れるようにするために Amazon VPC ウィザードが追加したルートを示しています。
6. メインルートテーブルを選択します。メインルートテーブルにはローカルルートがありますが、他のルートはありません。

ステップ 2: セキュリティグループ 12 を作成する

セキュリティグループは、関連するインスタンスのトラフィックを制御する仮想ファイアウォールとして機能します。セキュリティグループを使用するには、インスタンスへの受信トラフィックを制御するインバウンドルールを追加し、インスタンスからの送信トラフィックを制御するアウトバウンドルールを追加します。セキュリティグループをインスタンスに関連付けるには、インスタンスの起動時にセキュリティグループを指定します。セキュリティグループにルールを追加したり削除したりすると、その変更はセキュリティグループに関連付けられているインスタンスに自動的に適用されます。

VPC にはデフォルトのセキュリティグループが付属しています。起動時に別のセキュリティグループに関連付けられていないインスタンスはすべて、デフォルトのセキュリティグループに関連付けられます。この演習では、WebServerSG という新しいセキュリティグループを作成し、VPC でインスタンスを起動するときにこのセキュリティグループを指定します。

トピック

• WebServerSG セキュリティグループの作成
• WebServerSG セキュリティグループのルール

WebServerSG セキュリティグループの作成

Amazon VPC コンソールを使用してセキュリティグループを作成できます。

WebServerSG セキュリティグループのルール

次の表では、WebServerSG セキュリティグループのインバウンドルールとアウトバウンドルールについて説明します。インバウンドルールは自分で追加します。アウトバウンドルールは、あらゆる場所へのすべてのアウトバウンド通信を許可するデフォルトのルールです。このルールを自分で追加する必要はありません。

WebServerSG セキュリティグループを作成してルールを追加するには

1. https://aws.amazon.com/console/で Amazon VPC コンソールを開きます。
2. ナビゲーションペインで [ セキュリティグループ] を選択します。
3. [ セキュリティグループの作成] を選択します。
4. [グループ名] フィールドに、セキュリティグループの名前として WebServerSG と入力し、説明を入力します。オプションで Name tag フィールドを使用して、Name のキーと指定した値を持つセキュリティグループのタグを作成できます。
5. VPC メニューから VPC の ID を選択し、[ Yes, Create] を選択します。
6. 先ほど作成した WebServerSG セキュリティグループを選択します (名前は [グループ名] 列に表示されます)。
7. [ インバウンドルール] タブで [編集 ] を選択し、次のようにインバウンドトラフィックのルールを追加します。完了したら [ 保存 ] を選択します。
   • 「タイプ」リストから「 HTTP 」を選択し、「 ソース 」フィールドに 0.0.0.0/0 と入力します。
   • [ 別のルールを追加] を選択し、[タイプ] リストから [ HTTPS ] を選択し、[ ソース ] フィールドに 0.0.0.0/0 と入力します。
   • [ 別のルールを追加]を選択します。Linux インスタンスを起動する場合は、タイプリストからSSHを選択します。Windows インスタンスを起動する場合は、タイプリストからRDPを選択します。Source フィールドに、ネットワークのパブリック IP アドレス範囲を入力します。このアドレス範囲がわからない場合は、この演習では 0.0.0.0/0 を使用できます。

注意：

0.0.0.0/0を使用すると、すべてのIPアドレスがSSHまたはRDPを使用してインスタンスにアクセスできるようになります。これは短い演習では問題ありませんが、実稼働環境では危険です。本番環境では、特定の IP アドレスまたはアドレス範囲のみにインスタンスへのアクセスを許可します。

ステップ 3: VPC 内にインスタンスを起動する 14

VPC で EC2 インスタンスを起動する場合、インスタンスを起動するサブネットを指定する必要があります。この場合、作成した VPC のパブリックサブネットにインスタンスを起動します。Amazon EC2 コンソールの Amazon EC2 起動ウィザードを使用してインスタンスを起動します。

次の図は、この手順を完了した後の VPC のアーキテクチャを示しています。

EC2 インスタンスを VPC 内に起動するには

1. Amazon EC2 コンソールを開きます。
2. 右上のナビゲーションバーで、VPC とセキュリティグループを作成したリージョンと同じリージョンが選択されていることを確認します。
3. ダッシュボードから [ インスタンスの起動] を選択します。
4. ウィザードの最初のページで、使用する AMI を選択します。この演習では、 Amazon Linux AMI またはWindows AMI**を選択することをお勧めします。
5. Choose an Instance Type ページでは、起動するインスタンスのハードウェア構成とサイズを選択できます。デフォルトでは、ウィザードは選択した AMI に基づいて最初に使用可能なインスタンスタイプを選択します。デフォルトの選択のままにして、[ 次へ:インスタンスの詳細の設定] を選択できます。
6. [ インスタンスの詳細の設定 ] ページで、[ネットワーク] リストから作成した VPC を選択し、[サブネット] リストからサブネットを選択します 。残りのデフォルト設定のままにし、タグインスタンスページが表示されるまでウィザードの次のページに進みます。
7. タグインスタンスページでは 、インスタンスに名前タグ (name=MyWebServer など) をタグ付けできます。これにより、起動後に Amazon EC2 コンソールでインスタンスを識別できます。完了したら、[ 次へ:セキュリティグループの設定 ] を選択します。
8. セキュリティグループの設定ページでは 、インスタンスに接続できるように launch-wizard-x セキュリティグループがウィザードによって自動的に定義されます。代わりに、[既存のセキュリティグループを選択] オプションを選択し、以前に作成した WebServerSG グループを選択し、[ 確認して起動] を選択します。
9. [ インスタンスの起動の確認 ] ページで、インスタンスの詳細を確認し、[ Launch] を選択します。
10. [既存のキーペアを選択するか 、 新しいキーペアを作成する ] ダイアログボックスで、既存のキーペアを選択するか、新しいキーペアを作成できます。新しいキーペアを作成する場合は、必ずファイルをダウンロードして安全な場所に保存してください。プライベートキーの内容は、起動後にインスタンスに接続するために必要になります。インスタンスを起動するには、確認のチェックボックスを選択し、次に [ Launch Instances] を選択します。
11. 確認ページで [ View Instances ] を選択すると、 インスタンスページにインスタンスが表示されます 。インスタンスを選択し、その詳細を [ Description ] タブに表示します。Private IP フィールドには、サブネット内の IP アドレスの範囲からインスタンスに割り当てられたプライベート IP アドレスが表示されます。

ステップ 4: インスタンスに Elastic IP アドレスを割り当てる

前のステップでは、パブリックサブネット、つまりインターネットゲートウェイへのルートがあるサブネットでインスタンスを起動しました。ただし、サブネット内のインスタンスには、インターネットと通信するためのパブリック IP アドレスも必要です。デフォルトでは、デフォルト以外の VPC のインスタンスにはパブリック IP アドレスは割り当てられません。このステップでは、Elastic IP アドレスをアカウントに割り当てて、それをインスタンスに関連付けます。Elastic IP アドレスの詳細については、「 Elastic IP アドレス」を参照してください。

次の図は、この手順を完了した後の VPC のアーキテクチャを示しています。

Elastic IP アドレスを割り当てて割り当てるには

1. https://console.aws.amazon.com/vpc/で Amazon VPC コンソールを開きます。
2. ナビゲーションペインで [ Elastic IP] を選択します。

3. [ 新しいアドレスを割り当て] を選択し、[ はい、割り当てます] を選択します。

   注：

   アカウントが EC2-Classic をサポートしている場合は、まず [ネットワークプラットフォーム] リストから EC2-VPC を選択します。

4. リストから Elastic IP アドレスを選択し 、[ アクション] を選択し、次に [ アドレスを関連付け] を選択します。
5. ダイアログボックスで、[ 関連付け] リストから[ インスタンス] を選択し、次に [インスタンス]リストからインスタンスを選択します。完了したら、[ はい、アソシエイト] を選択します。

これで、インスタンスにインターネットからアクセスできるようになりました。SSH またはリモートデスクトップを使用して、Elastic IP アドレスを使用してインスタンスに接続できます。Linux インスタンスへの接続方法の詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「 Linux インスタンスへの接続 」を参照してください。Windows インスタンスに接続する方法の詳細については、Windows インスタンス用 Amazon EC2 ユーザーガイドの「 RDP を使用して Windows インスタンスに接続する 」を参照してください。

これで実習は完了です。VPC でインスタンスを引き続き使用するか、インスタンスが必要ない場合は、インスタンスを終了し、Elastic IP アドレスを解放して、料金が発生しないようにすることができます。VPC を削除することもできます。この演習で作成した VPC と VPC コンポーネント (サブネットやルートテーブルなど) には課金されないことに注意してください。

Citrix Virtual Apps and Desktops用のUnified Gateway の設定

Citrix ADC の管理コンソールに移動します。

nsroot と、ビルドプロセス中にAWSが割り当てたインスタンスIDを使用して、Citrix ADCにログインします。

SSL 証明書のインストール:

1. 「 トラフィック管理 — SSL」に移動します。右クリックして、この機能を有効にします。
2. SSL 証明書をキーペアとしてインポートします。

SSL 証明書のインストール:

1. Citrix Gateway を展開し、「 仮想サーバー」を選択します

2. ［追加］ をクリックします。

   Citrix ADC Buildプロセス中に割り当てたパブリックサブネットにあるゲートウェイの名前とIPアドレスを入力します。

   注：

   後で Elastic IP アドレスを割り当てるときに必要になるので、この IP アドレスを書き留めてください。

3. 「 OK」をクリックし、「 サーバー証明書なし」をクリックして、先ほどインポートした証明書を選択します。［バインド］ をクリックします。
4. ［ OK］と［完了］をクリックすると、Citrix Gateway が「アップ」状態で表示されます。

Unified Gateway を設定するには、https://support.citrix.com/article/CTX205485/how-do-i-configure-unified-gateway-for-common-enterprise-applicationsを参照してください。

Unified Gateway インスタンスへの外部アクセスを提供します。

1. aws.amazon.com で AWS ポータルにログインし、インスタンスに移動します。

2. Citrix ADCを右クリックし、「 ネットワーク 」を選択し、「 プライベートIPアドレスの管理」を選択します。

   

3. Citrix ADC Gatewayを実行するインターフェイスの［ 新しいIPの割り当て ］をクリックします。

4. IPアドレスの割り当て Citrix ADC Gatewayに割り当てたものと同じアドレスを使用してください。

   

5. [ はい更新] をクリックします。これにより、新しい IP アドレスが AWS レベルでインスタンスに割り当てられます。これで、このプライベートIPに新しい Elastic IP を割り当てることができます。
6. [ネットワークとセキュリティ] と [Elastic IP] に移動します。

7. メッセージが表示されたら、[ 新しいアドレスを割り当て] をクリックします。新しい IP アドレスを取得するには [ はい ] を選択します。

   

8. 一覧から住所を選択し、[ 住所を関連付け] を選択します。

   

9. インスタンスリストから、以前に構築した Citrix ADC インスタンスを選択します。これを選択すると、インスタンスに静的に割り当てたIPアドレス（Citrix Gatewayと同じアドレス）を選択し、［ Associate］を選択できるようになります。

   

10. DNS 名レコードを Amazon から割り当てられた Elastic IP アドレスに紐付けてください。
11. Citrix Gateway にログインします。

StoreFront 用の高可用性負荷分散

Citrix 構成手順を参照してください。

2 つの AWS ロケーションで GSLB を設定する

AWSでのCitrix ADCのGSLBの設定は、主に、Citrix ADCが属するVPCの外部（別のアベイラビリティリージョンの別のVPC内やオンプレミスのデータセンターなど）にあるサーバーへのトラフィックを負荷分散するようにCitrix ADCを構成することで構成されます。

クラウドロードバランサーによるドメイン名ベースのサービス (GSLB DBS)

GSLB と DBS の概要

クラウドロードバランサーでDBS（ドメインベースサービス）を使用するCitrix ADC GSLBサポートにより、クラウドロードバランサーソリューションを使用して動的クラウドサービスを自動検出できます。この構成により、Citrix ADCはアクティブ/アクティブ環境でグローバルサーバー負荷分散ドメイン名ベースのサービス（GSLB DBS）を実装できます。DBS を使用すると、DNS ディスカバリーから AWS および Microsoft Azure 環境のバックエンドリソースをスケーリングできます。

このセクションでは、AWSとAzure Auto Scaling環境におけるCitrix ADC 統合について説明します。ドキュメントの最後のセクションでは、AWS リージョンに固有の 2 つの異なるアベイラビリティーゾーン（AZ）にまたがる Citrix ADC の HA ペアをセットアップする機能について詳しく説明します。

前提条件

Citrix ADC GSLB サービスグループの前提条件には、セキュリティグループ、Linux ウェブサーバー、AWS 内の Citrix ADC、Elastic IP、およびエラスティックロードバランサーを設定するための知識と能力を備えた、機能する AWS/Microsoft Azure 環境が含まれます。

GSLB DBS サービスの統合には、AWS ELB および Microsoft Azure ALB ロードバランサーインスタンス用に、Citrix ADC バージョン 12.0.57 が必要です。

Citrix ADC GSLB サービスグループ機能の強化

GSLB サービスグループエンティティ:Citrix ADC バージョン 12.0.57

BDS 動的検出を使用した自動スケーリングをサポートする GSLB サービスグループが導入されました。

DBS 機能コンポーネント (ドメインベースのサービス) は GSLB サービスグループにバインドされるものとする

例：

> add server sydney_server LB-Sydney-xxxxxxxxxx.ap-southeast-2.elb.amazonaws.com
> add gslb serviceGroup sydney_sg HTTP -autoScale DNS -siteName sydney
> bind gslb serviceGroup sydney_sg sydney_server 80
<!--NeedCopy-->

ドメイン名ベースのサービス — AWS ELB

GLSB DBS は Elastic Load Balancer の FQDN を利用して GSLB サービスグループを動的に更新し、AWS 内で作成および削除されるバックエンドサーバーを含めます。AWS のバックエンドサーバーまたはインスタンスは、ネットワーク需要または CPU 使用率に基づいてスケーリングするように設定できます。この機能を設定するには、Citrix ADC に Elastic Load Balancer を指定して、AWS 内でインスタンスが作成および削除されるたびに Citrix ADC を手動で更新しなくても、AWS 内のさまざまなサーバーに動的にルーティングされるようにします。GSLBサービスグループのCitrix ADC DBS機能は、DNS対応のサービス検出を使用して、AutoScalerグループで識別されたDBS名前空間のメンバーサービスリソースを特定します。

図:

Citrix ADC GSLB DBA AutoScale コンポーネントとクラウドロードバランサー

Citrix ADC HA を複数のアベイラビリティーゾーンで AWS で使用する

Citrix ADC 12.1でリリースされた新機能として、さまざまなアベイラビリティーゾーンにまたがるCitrix ADCをAWSにデプロイすることが挙げられます。これは、Citrix ADC を Elastic Network IP アドレス (ENI) に接続することによって行われます。

VPXでHAを設定し、独立したネットワーク構成を行う必要があるため、ソリューションの仕組みは他のソリューションとは少し異なります。このソリューションでは、仮想サーバの IP セット機能の新機能を使用してフェイルオーバーを維持します。

まず、Citrix ADCにログインし、サーバー側のネットワークアドレス、クライアント側のアドレス、および両方へのルーティングを定義または立ち上げる必要があります。

AWSコンソールでは、最初のVPXはエラスティックIPでセットアップされています。

エラスティックインターフェイスに入ると、まずソリューションが機能するようにするには、その Elastic IP をそのインターフェイス上の既存のプライベートアドレスに関連付けることです。

関連付けが完了したら、フェールオーバーを実行する準備は完了です。

一番下に、VPXに2つ目のElastic IPがあるはずです。

VPXに移動してフェイルオーバーを開始し、AWSコンソールに戻ってください。今回は、最初のCitrix ADCに属するElastic IPを見てみると、新しいEIPは2つ目のCitrix ADCに移動されているため、存在しないことに注意してください。

これを確認するには、1番目と2番目のCitrix ADCにshow nodeコマンドを入力して 、2つ目のCitrix **ADCがスタンバイ状態になる前と同じようにプライマリ状態に設定されていることを確認します**。

これで、リアルタイムのトラフィックフローを確認できます。

フェイルオーバー後に VIP にリクエストを送信できます。最初にアクティブになったCitrix ADC上のLB仮想サーバーで統計を実行すると、そこにリクエストがヒットしていないことがわかります。以前はスタンバイだったが現在はアクティブだったCitrix ADCで同じコマンドを実行すると、そこで仮想サーバーがヒットしていることがわかります。HA移行後、トラフィックが新しいCitrix ADCに送られたことを示しています。

ここで、デバッグを行ったり、現在のステータスを確認したりする場合は、シェルに移動して HA フェイルオーバーがいつ発生したか、AWS 構成または API の呼び出しによってすべての EIP がプライマリ Citrix ADC からセカンダリ ADC に切り替わるタイミングを示すレコードを探すことができます。

AWS コンポーネントの設定

セキュリティグループ

注：

ELB、Citrix ADC GSLB インスタンス、および Linux インスタンスにはそれぞれ異なるセキュリティグループを作成することをお勧めします。これらのエンティティに必要なルールセットはそれぞれ異なるためです。この例では、簡潔にするために、統合セキュリティグループ設定があります。

仮想ファイアウォールが適切に設定されていることを確認するには、 VPC のセキュリティグループを参照してください 。

手順 1:

AWS リソースグループにログインし 、 EC2に移動します。EC2 内で [ ネットワークとセキュリティ] > [セキュリティグループ] に移動します。

手順 2:

[ セキュリティグループの作成 ] をクリックし、名前と説明を入力します。このセキュリティグループには、Citrix ADC および Linux バックエンド Web サーバーが含まれます。

手順3：

下のスクリーンショットからインバウンドポートルールを追加します。

注：

きめ細かく強化するには、ソース IP アクセスを制限することを推奨します。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-web-server

Amazon Linux バックエンドウェブサービス

手順 4:

AWS リソースグループにログインし 、 EC2に移動します。EC2 内で [ インスタンス] に移動します。

手順 5:

以下の詳細を使用して [ インスタンスを起動 ] をクリックし、 Amazon Linux インスタンスを設定します。

このインスタンスでの Web サーバーまたはバックエンドサービスの設定に関する詳細を入力します。

Citrix ADC構成

手順 6:

AWS リソースグループにログインし 、 EC2に移動します。EC2 内で [ インスタンス] に移動します。

手順 7:

以下の詳細を使用して [ インスタンスを起動 ] をクリックし、 Amazon AMI インスタンスを設定します。

エラスティック IP 設定

注：

また、NSIP用のパブリックIPを使用しないことで、必要に応じてCitrix ADCを単一のElastic IPで実行してコストを削減することもできます。代わりに、GSLBサイトIPとADNS IPだけでなく、ボックスへの管理アクセスをカバーできるSNIPにエラスティックIPを接続します。

手順 8:

AWS リソースグループにログインし 、 EC2に移動します。EC2 内で [ ネットワークとセキュリティ ] に移動し、 Elastic IPを設定します。

[ 新しいアドレスを割り当て ] をクリックして、新しい Elastic IP アドレスを作成します。

AWS 内で実行中の Citrix ADC インスタンスを指すように Elastic IP を設定します。

2 つ目の Elastic IP を設定し、実行中の Citrix ADC インスタンスを再度指定します。

伸縮自在なロードバランサー

手順 9:

AWS リソースグループにログインし 、 EC2に移動します。EC2 内で、[負荷分散]、[ロードバランサー] の順に選択します。

手順 10:

[ ロードバランサーの作成 ] をクリックして、クラシックロードバランサーを設定します。

Elastic Load Balancers を使用すると、バックエンドの Amazon Linux インスタンスの負荷分散が可能になると同時に、需要に基づいてスピンアップされる追加のインスタンスを負荷分散できます。

グローバルサーバ負荷分散ドメイン名ベースのサービスの設定

トラフィック管理の設定

注：

Citrix ADCをネームサーバーまたはDNS仮想サーバーで構成する必要があります。これにより、DBSサービスグループのELB/ALBドメインが解決されます。

https://developer-docs.citrix.com/projects/netscaler-command-reference/en/12.0/dns/dns-nameserver/dns-nameserver/

手順 1:

［Traffic Management］>［Load Balancing］>［Servers］ の順に移動します。

手順 2:

[ 追加 ] をクリックしてサーバーを作成し、Elastic Load Balancer (ELB) の AWS の A レコード (ドメイン名) に対応する名前と FQDN を指定します。

手順 2 を繰り返して、AWS の 2 番目のリソースの場所から 2 番目の ELB を追加します。

GSLB構成

手順 1:

[ トラフィック管理] > [GSLB] > [サイト]に移動します。

手順3：

GSLB サイトを設定するには、[ 追加 ] ボタンをクリックします。

「サイト」に名前を付けます。タイプは、サイトを構成しているCitrix ADCに基づいて、リモートまたはローカルとして構成されます。サイトの IP アドレスは、GSLB サイトの IP アドレスです。GSLBサイトは、このIPアドレスを使用して他のGSLBサイトと通信します。パブリックIPアドレスは、特定のIPが外部のファイアウォールまたはNATデバイスでホストされているクラウドサービスを使用する場合に必要です。サイトは親サイトとして設定する必要があります。[トリガーモニター] が [常に] に設定されていることを確認し、[メトリック交換]、[ネットワークメトリック交換]、および [持続性セッションエントリ交換] の下部にある 3 つのチェックボックスをオフにします。

トリガモニタの設定を MEPDOWN に設定することが推奨されます。詳細については、「 GSLB サービスグループを構成する」を参照してください。

手順 4:

以下はAWS設定のスクリーンショットで、サイトIPアドレスとパブリックIPアドレスがどこにあるかを示しています。これらは [ ネットワークとセキュリティ] > [Elastic IP] の下にあります。

「 作成」をクリックし、手順3と4を繰り返して、Azureの他のリソースの場所用にGSLBサイトを構成します（これは同じCitrix ADCで構成できます）

手順 5:

[ トラフィック管理] > [GSLB] > [サービスグループ] に移動します。

手順 6:

[ 追加 ] をクリックして新しいサービスグループを追加します。サービスグループに名前を付け、HTTP プロトコルを使用してから、[サイト名] で、前の手順で作成したそれぞれのサイトを選択します。[AutoScaleモード] を DNS として設定し、[状態] および [ヘルスモニタ] のチェックボックスをオフにします。

OK をクリックしてサービスグループを作成します。

手順 7:

[ サービスグループメンバー ] をクリックし、[ サーバベース] を選択します。実行ガイドの冒頭で設定した Elastic Load Balancing Server を選択します。トラフィックがポート 80 を通過するように設定します。

［Create］ をクリックします。

手順 8:

サービスグループのメンバーバインディングには、Elastic Load Balancer から受信する 2 つのインスタンスが設定されます。

手順を繰り返して、AWS の 2 番目のリソースロケーションのサービスグループを設定します。（これは同じ場所から行うことができます）。

手順 9:

[ トラフィック管理] > [GSLB] > [仮想サーバー] に移動します。

[ 追加 ] をクリックして仮想サーバーを作成します。サーバーの名前を指定し、DNSレコードタイプがAに設定され、サービスタイプがHTTPに設定され、AppFlowロギングの作成後に有効にするチェックボックスをオンにします。 OK をクリックして GSLB 仮想サーバーを作成します。（Citrix ADC GUI）

手順 10:

GSLB仮想サーバーが作成されたら、「 GSLB仮想サーバーサービスグループバインドなし」をクリックします。

[ 追加 ] をクリックして仮想サーバーを作成します。サーバーの名前を指定し、DNSレコードタイプがAに設定され、サービスタイプがHTTPに設定され、AppFlowロギングの作成後に有効にするチェックボックスをオンにします。 OK をクリックして GSLB 仮想サーバーを作成します。（Citrix ADC GUI）

手順 11:

[サービスグループバインディング ] で [サービスグループ名の選択 ] を使用して、前のステップで作成したサービスグループを選択して追加します。

手順 12:

次に、 GSLB仮想サーバードメインバインディングなしをクリックして、GSLB仮想サーバードメインバインディングを設定します。FQDN とバインドを構成し、残りの設定をデフォルトのままにしておくことができます。

ステップ 13:

[ サービスなし] をクリックして ADNS サービスを設定します。サービス名を追加し、「新規サーバー」をクリックして、ADNS サーバーの IP アドレスを入力します。

また、ADNS が既に設定されている場合は、[ 既存のサーバー ] を選択し、メニューから ADNS を選択できます。プロトコルが ADNS で、トラフィックがポート 53 経由であることを確認します。

メソッドを LEASTCONNECTION、バックアップメソッドを ROUNDROBIN として設定します

Citrix ADC バックエンドの AWS による自動スケーリング

AWS には、管理者が設定したルールに基づいて AWS で実行されている追加のインスタンスを起動する Auto Scaling と呼ばれる機能があります。これらのルールは CPU 使用率によって定義され、オンデマンドでのインスタンスの作成と削除を中心に展開されます。Citrix ADC は AWS Auto Scaling ソリューションと直接統合されるため、Citrix ADC は負荷分散が可能なすべてのバックエンドサーバーを認識します。この機能の制限は、現在 AWS の 1 つの AZ 内でしか機能しないことです。

AWS コンポーネントの設定

手順 1:

AWS リソースグループにサインインし 、 EC2に移動します。EC2 内で AUTO SCALING > 起動設定に移動します。「 起動設定を作成」をクリックします。

手順 2:

このステップから、お好みのサーバータイプを選択できます。ここで、どの仮想マシンを自動スケーリングするかを設定します。この例では、 Amazon Linux AMIを選択する必要があります。

手順3：

バックエンドリソースの潜在的な差異から選択して、必要なインスタンスのタイプを選択します。ランガイドの残りの部分には、インスタンスに名前を付けてください。インスタンスの名前はバックエンドサーバーと呼ばれます。インスタンスのストレージを設定してセキュリティグループに追加するか、この実行ガイドで作成したすべての AWS コンポーネントを含む新しいセキュリティグループを作成します。

手順 4:

セキュリティグループに関する補足事項。このランガイドでは、次のポートが開いています。

Citrix ADC バックエンド自動スケーリンググループとポリシー

AWS での Citrix ADC フロントエンド自動スケーリングの設定:

手順 1:

AWS リソースグループにサインインし 、 EC2に移動します。EC2 内で [ 自動スケーリング] > [自動スケーリンググループ] に移動します。

ラジオボタンをクリックして 、既存の起動設定から Auto Scaling グループを作成します。ラボガイドの前のステップで作成した BackendServer を必ず選択してください。

[ Auto Scaling グループの作成 ] でグループ名を追加し、初期グループサイズを選択し、[ ネットワーク] と [サブネット] を選択して、[ 次へ] をクリックします。

注：

サブネットは、Citrix ADC サブネットIP（SNIP）からアクセスできる必要があります。

手順 2:

Auto Scaling グループの作成設定ページで 、スケーリングポリシーを設定します。そのためには、スケーリングポリシーを使用してこのグループの容量を調整するためのラジオボタンをクリックします。次に、 ステップスケーリングポリシーまたはシンプルスケーリングポリシーを使用して Auto Scaling グループをスケーリングをクリックします。

手順3：

[ 新しいアラームを追加] を選択します。

手順 4:

アラームの作成中に、Citrix ADC に通知を送信するように設定します。少なくとも 5 分間連続して 1 回 CPU 使用率の平均が 70 以上になるようにアラームを設定します。ポリシーを適用してください。

手順 5:

ポリシーがトリガーされたときに 1 つのインスタンスを追加するように Auto Scaling グループで設定します。

手順 6:

同じアラームとポリシーを設定しますが、今度は 5 分間の CPU の平均使用率が 30 以下のときにバックエンドサーバーを削除します。減少ポリシーがトリガーされたら、減少グループサイズを [1 インスタンスを削除] に設定します。

注：

サーバーの削除については、削除対象としてマークされたバックエンドサーバーにトラフィックを送信しないようにCitrix ADCに通知しています。

[通知の設定] と [タグの設定] をクリックして、Auto Scaling グループを確認して作成します。

注：

Min 変数と Max 変数は、Auto Scaling グループ内で作成および実行するインスタンスの最小数と最大数を設定するように設定できます。現在、AWS は 1 つのネットワークインターフェースのみで追加のインスタンスを起動することをサポートしています。

AWS で Citrix ADC を作成する

手順 1:

AWS リソースグループにサインインし 、 EC2に移動します。EC2 内で [インスタンス] > [インスタンス] に移動します。

手順 2:

左側AWS Marketplace に移動し、Citrix ADC を検索します。 Citrix Networking VPX — カスタマーライセンスを選択します。Auto Scaling を使用するには、バージョン番号が 12.0.51.x 以降であることを確認してください。以前のバージョンを選択して、Auto ScalingをサポートするCitrix ADC バージョンを選択できます。

手順3：

左側AWS Marketplace に移動し、Citrix ADC を検索します。 Citrix Networking VPX — カスタマーライセンスを選択します。Auto Scaling を使用するには、バージョン番号が 12.0.51.x 以降であることを確認してください。以前のバージョンを選択して、Auto ScalingをサポートするCitrix ADC バージョンを選択できます。

インスタンスタイプを選択します。たとえば、汎用 m4.xlarge 4vCPU や 16 GB RAM などです。［次へ］ をクリックします。

手順 4:

[インスタンスの詳細の構成] タブで、[サブネット] を選択します（3 つのサブネットは、最終的にNSIP、SNIP、VIP/Gateway用に構成する必要があります）。また、IAM ロールを追加する必要があります。クリックして新しい IAM ロールを作成します。次のステップにある IAM ロールを追加します。このロールを作成したら、Citrix ADC のクラウドプロファイルにこれを追加する必要があります。

手順 5:

クラウドプロファイルの構成は次のとおりです。

CloudFormationテンプレートは、デフォルトでは以下のIAMロールを作成し、割り当てます

"Version": "2012-10-17",
"Statement": [
    {
        "Action": [
            "ec2:DescribeAddresses",
            "ec2:AssociateAddress",
            "ec2:DisassociateAddress",
            "ec2:DescribeInstances",
            "ec2:DescribeNetworkInterfaces",
            "ec2:DetachNetworkInterface",
            "ec2:AttachNetworkInterface",
            "ec2:StopInstances",
            "ec2:StartInstances",
            "ec2:RebootInstances",
            "autoscaling:\*",
            "sns:\*",
            "sqs:\*",
            "iam:GetRole",
            "iam:SimulatePrincipalPolicy"
        ]
        Resource: "\*"
        Effect: Allow
    }
]
<!--NeedCopy-->

IAM ロールの権限は、次のようにさらに制限できます。

        "Action": [
            ec2:DescribeInstances,
            ec2:DescribeNetworkInterfaces,
            ec2:DetachNetworkInterface,
            ec2:AttachNetworkInterface,
            ec2:StartInstances,
            ec2:StopInstances,
            ec2:RebootInstances,
            ec2:DescribeAddresses,
            ec2:AssociateAddress,
            ec2:DisassociateAddress,
            ec2:AssignPrivateIpAddress,
            ec2:UnAssignPrivateIpAddress,
            autoscaling:*,
            sns:CreateTopic,
            sns:DeleteTopic,
            sns:ListTopics,
            sns:Subscribe,
            sqs:CreateQueue,
            sqs:ListQueues,
            sqs:DeleteMessage,
            sqs:GetQueueAttributes,
            sqs:SetQueueAttributes,
            iam:SimulatePrincipalPolicy,
            iam:GetRole
        ]
<!--NeedCopy-->

手順 6:

「 ストレージを追加 」オプションをクリックします。[ タグの追加 ] タブで、[キー] の値を [名前] に、値を [Citrix ADC-AutoScale] に設定して、これらの EC2 リソースにタグを付けます。

手順 7:

セキュリティグループの設定タブで 、次のポート要件を持つ新しいセキュリティグループを作成します。

インスタンスを確認して起動します。

手順 8:

[ ネットワークとセキュリティ] > [ネットワークインターフェース ] に移動し、[ ネットワークインターフェースの作成] をクリックします。

説明を追加して、サブネットを選択します。このサブネットはSNIPに使用されるため、内部ネットワークのサブネットに配置する必要があります。また、前のステップで作成したセキュリティグループを選択します。［Yes, Create］ をクリックします。

ネットワークインターフェイスを追加します。これは、Gateway/LB VIP 用のパブリック向けサブネットです。説明を作成し、上記で設定したセキュリティグループを選択します。

手順 9:

[ インスタンス ] に戻り、Citrix ADC を選択します。Citrix ADC にネットワークインターフェイスを追加するには、インスタンスを停止する必要があります。 アクションリストで 、「 インスタンス状態 」を選択し、「 停止」をクリックします。

もう一度 [ アクション ] ボタンをクリックし、[ ネットワーク] と [ネットワークインターフェイスの接続] に移動します。

NSIPインターフェースはすでにVMに接続されています。次に追加するインターフェースはLB-VIPで、続いてSNIP用のサーバー/内部インターフェースを追加する必要があります。ネットワークインターフェースがアタッチされたら、インスタンスを起動できます。

新しい Elastic IP を設定し、NSIP インターフェイスに関連付けます。

Citrix ADC を AWS 自動スケーリングと統合するように設定する

手順 1:

このラボガイドの前のステップでNSIPに関連付けたElastic IPに移動して、Citrix ADC管理コンソールにアクセスします。

Citrix ADCを構成するための最初のステップは、クラウドプロファイルを添付することです。[ AWS ] をクリックし、[ クラウドプロファイル] をクリックします。次に [ 追加 ] をクリックしてクラウドプロファイルを作成します。

クラウドプロファイルの名前を指定します。仮想サーバーのIPアドレスは、Citrix ADC 内部IPアドレスに入力され、関連付けられている必要があります。Auto Scale グループは、このラボガイドの前のステップで作成したグループです。 Gracefulを選択します。これにより、バックエンドインスタンスの削除がタイムアウトし、すべてのパケット転送が完了し、猶予期間内にセッションが終了しなくなります。猶予期間の遅延時間は調整できます。

Citrix ADC フロントエンド自動スケーリングを AWS で設定する

1. Auto Scaling グループを作成するには、Citrix ADM にサインインします。

2. [ ネットワーク] > [AutoScale グループ] に移動し、[ 追加 ] をクリックしてグループ名を作成します。

   

3. サイト設定で 、「 追加」をクリックします。

   

クラウドアクセスプロファイルの作成

1. サイトを作成するときに、 クラウドアクセスプロファイルにAWSを追加します。

   

2. プロファイルに名前を付けて、AWS ポータルにサインインします。 ID とアクセス管理 (IAM) サービスを検索して、ユーザーアクセスと暗号化キーを管理します。

   

3. IAMダッシュボードで、左側のパネルで［ 役割 ］を選択し、対応するCitrix ADM 役割を検索します。

   

4. ロール ARN をクリップボードにコピーします。

   

5. 名前をコピーしたら、Citrix ADM コンソールに戻り、名前を「 Role ARN 」テキストフィールドに貼り付けます。

6. 外部 ID を取得するには、AWS ロールダッシュボードに戻り 、 信頼関係タブに移動して 、 条件から値をコピーします。

   

7. Citrix ADM コンソールで、値を「 外部ID 」フィールドに貼り付け、「 作成」をクリックします。

   

8. リージョンを選択し、適切な VPC ネットワークを選択します。

   

9. エージェントを [ 使用可能] から [設定済み]に移動します。

   

10. 対応するクラウドアクセスプロファイルを選択します。

    

    

11. 読み込まれたら、アベイラビリティーゾーンを [ 利用可能 ] から [ 設定済み ] に移動し、対応するタグを AutoScale グループに追加します。[ 次へ ] を選択して AutoScale パラメータの設定を開始します。

    

AutoScaleのパラメータを設定します

1. AutoScaleのパラメータを設定するときは、しきい値とパラメータを必要な設定に調整します 。次に [ 次へ ] をクリックして、 プロビジョニングパラメータの設定を開始します 。

   

2. 「 プロビジョニングパラメータ 」セクションで、「 IAM ロール」フィールドからロールを選択します 。

   

3. 適切な Citrix ADC 製品とエディションを選択します。

   

4. AWS の特定のインスタンスから Amazon マシンイメージ (AMI) ID を収集します。その ID を AWS AMI ID フィールドに入力します。

   

   

5. AMI IDを追加したら、 適切なグループでセキュリティグループを更新します 。

   

6. ゾーン 1、2、3 の構成を開始するには、対応する管理サブネット、クライアントサブネット、サーバーサブネットを割り当てます。

   

7. [ 完了 ] をクリックして、この Auto Scaling グループの設定を作成します。作成プロセスには最大 10 ～ 20 分かかる場合があります。

   

   

AWS でインスタンスを初期化する

1. Auto Scaling グループの作成中に、AWS コンソールを開いて [ サービス ] タブに移動します。 Amazon Elastic Compute Cloud (EC2) サービスを選択します。

   

2. EC2 ダッシュボードで [ インスタンス ] タブを選択し、 AutoScale Group セクションに設定されているタグを使用してフィルタリングします。

   

3. フィルタリングすると、まだ初期化中の保留中のインスタンスが表示されます。

   

4. インスタンスは作成後に初期化を完了するはずです。

   

Auto Scaling グループのイベントを監視する

1. Auto Scaling グループを作成したら、グループを選択して AutoScale グループのダッシュボードに進みます 。

   

2. 特定の期間を除外して Auto Scaling グループをモニタリングします。リアルタイムのインサイトを得るには、モニタリング期間を「 ライブ」に変更します。

   

3. グラフに表示されている次のデータポイントをクリックすると、グループイベントが表示されます。

   

4. 特定のライブイベントを表示すると、対応する Auto Scaling グループの特定のイベントをモニタリングできます。

   

Citrix ADM サービスを使用して Citrix ADC VPX インスタンスをプロビジョニングします

Citrix ADM Serviceは、Citrix ADCインスタンスを監視し、アプリケーションの正常性、パフォーマンス、およびセキュリティを可視化する機能を提供するクラウドベースのソリューションです。さらに、プロビジョニングツールを活用してAWSなどのパブリッククラウドにインスタンスを自動作成することで、オンプレミスでもクラウドでも、複数の場所にあるADCインスタンスの管理を簡素化できます。

前提条件

Citrix ADM サービスを使用して AWS で Citrix ADC インスタンスをプロビジョニングするには、前提条件のドキュメントにまとめられているいくつかの手順を実行する必要があります。詳細については、「 AWSでのCitrix ADC VPXインスタンスのプロビジョニング」を参照してください。

これらの手順には、Citrix ADMでCitrix ADC VPXインスタンスをプロビジョニングする前に、AWSで以下のタスクを実行することが含まれます。

• サブネットの作成
• セキュリティグループの作成
• IAM ロールを作成してポリシーを定義する

IAMロールには、Citrix ADM ServiceがAWSアカウントにアクセスできるようにする権限を設定する必要があります。すべてを設定したら、Citrix ADM サービスを活用してAWSにVPXインスタンスをプロビジョニングできます。

Citrix ADM サービスを使用して Citrix ADC VPX インスタンスをプロビジョニングする

Citrix Cloud ADM サービスにサインインし、[ ネットワーク] > [インスタンス] > [Citrix ADC] に移動します。次に、 「アクションの選択」 タブで、「 クラウドでのプロビジョニング」をクリックします。

これにより、プロビジョニングするインスタンスに関する情報を定義するよう求められます。

具体的には、以下を定義する必要があります。

• インスタンスのタイプ: ここでは [スタンドアロンインスタンス] を選択します。
• 名前: インスタンスがプロビジョニングされるときに採用させたい名前。
• サイト: サイトは、展開を行う地域または地域を定義します。
• エージェント: エージェントは、サイト内でどのADMエージェントを利用できるかを決定します。これは、自動プロビジョニングを行う前に設定する必要があります。この演習を開始する前に、サイトとそのサイトに属するエージェントの両方を作成する必要があります。
• デバイスプロファイル: ユーザー名として「nsroot」と必要なパスワードを持つデバイスプロファイル。Citrix ADMによってCitrix ADCがプロビジョニングされると、ADCのnsrootユーザーのパスワードは、プロファイルに記載されているパスワードに設定されます。さらに、このプロファイルは、Citrix ADM がインスタンスにログインする必要があるときに必ず使用されます。
• タグ: インスタンスまたはインスタンスグループのオプションのタグ。

次に、AWS アカウントのクラウドアクセスプロファイルを選択します 。これは、Citrix ADM がAWSアカウントにサインインしてエンティティを取得し、プロビジョニングやプロビジョニング解除などの操作を実行するために使用するプロファイルです。このプロファイルを使用して、Citrix ADM Serviceは残りのフィールドにアカウントに関連するオブジェクトを入力します。

このシナリオでは、Citrix ADMサービスがVPXインスタンスをプロビジョニングするために使用するIAMロールが事前定義されていますが、他のロールを作成することもできます。

次に、希望するスループットに基づいて、デプロイするVPXインスタンスの製品エディションを選択する必要があります。

注：

ライセンスなしでVPXインスタンスをデプロイするためのVPX Expressが含まれています。

バージョン

メジャーリリースとマイナーリリースを選択して、実行するソフトウェアのリリースを決定します。

セキュリティグループ

セキュリティグループには、さまざまな仮想プライベートクラウド (VPC) にアクセスするための事前定義された権限が必要です。各インスタンスには3つのネットワーク・インタフェースまたはVNICが必要なため、デプロイするサービスには次の3つの異なるセキュリティ・グループを適用する必要があります。

• リモート管理用 (ロールNSIP)
• 1 つはクライアント側アクセス用 (ロール VIP)
• 1つはサーバー側の通信用（SNIPロール）

また、このソリューションのスケーラビリティに必要なIPの数を選択する必要があります。

最後に、デプロイするアベイラビリティーゾーンを選択し、サブネットごとに一致する VPC サブネット情報を定義する必要があります。

• 1 つは管理インターフェイス (NSIP) 用
• 1 つはクライアントがアクセスする (VIP)
• 1つはSNIPがバックエンドサーバーにアクセスするためのもの（SNIP）

[ Finish] をクリックすると、デプロイが開始されます。デプロイが正常に完了すると、VPXがデプロイされたという通知が届きます。

展開が完了すると、すべての管理と展開の目的でCitrix ADM にCitrix ADC VPXインスタンスを表示できます。

その後、EC2コンソールに移動して、Citrix ADM 設定で設定した名前で作成された新しいインスタンスを確認できます。これらはすべてCitrix ADMで管理できるように同期されており、アプリケーションをCitrix ADCに展開する準備ができています。

AWS デプロイ

これらのインスタンスをプロビジョニング解除するには、Citrix Cloud ADM サービスに戻り、[ ネットワーク] > [インスタンス] > [Citrix ADC]に移動します。「アクションを選択」タブで、「プロビジョニング解除」をクリックします。

AWS プロビジョニング解除

アクションを確認するように求められます。続行するには、[ はい ] を選択すると、すべてのプロビジョニングが取り消されます。

VPXインスタンスがプロビジョニング解除されたという確認を受け取ると、Citrix ADMコンソールにデバイスが表示されなくなります。

追加情報

• 実装ガイド:AWS でのCitrix XenDesktop
• 一般的なエンタープライズアプリケーション用に Unified Gateway を設定する方法
• Amazon Web Services (AWS) で Citrix ソリューションを実行してビジネスを加速させましょう
• AWS 向けクラウドネットワーキングおよびデスクトップ仮想化ソリューション
• AWSにVPXをデプロイするためのCitrix ADCクイックスタートガイド
• AWS のアベイラビリティーゾーン全体で Citrix ADC 高可用性 (HA) を迅速にプロビジョニングして構成する
• AWS での Citrix ADC HA ペアのデプロイが簡単に:クラウドフォーメーションテンプレートを使用
• Citrix ADM を使用して AWS での Citrix ADC VPX の自動スケーリング