システムの耐障害性を検討する上でネットワーク機器の高可用性は必要不可欠です。このブログでは、AWS環境におけるNetScalerの冗長性を考えます。
始めにオンプレミス環境のNetScalerでは、2台のNetScalerでプライマリ/セカンダリの関係を確立するHigh Availability(以降HA)と、複数台のNetScalerをグルーピングしてトラフィックを捌くCluster、この2つの機能を使用することができます。シンプルにプライマリ/セカンダリで動くHAの方が馴染みあるかと思います。AWS環境においては、NetScalerのClusterがサポートされていません。また、HAも一部制約があり、オンプレミス環境同様に構成することができません。本稿では、AWS環境上でNetScalerの冗長構成を取るにはどのように構成したら良いか説明します。
NetScalerのHAは仮想IPアドレスをプライマリ/セカンダリで共有し、HAフェイルオーバーが発生した際にはGARPを使用することが一般的で、IPとMACアドレスのバインディングの更新を他のネットワークデバイスに通知します。
しかしながらここでまた制限があります。AWS環境ではGARPがサポートされていません。(AWS環境でNetScalerをご利用いただく際の制限はこちらです)
したがって、AWS環境でのNetScalerのHAの考え方はオンプレミス環境での動作の考え方/必要要件とは異なります。AWS環境の機能をうまく利用した別のARPテーブルの更新手段が必要です。
では、HAフェイルオーバー発生時にAWS環境でどのような処理が必要か下図をベースに説明していきます。
例としてAWS環境に構築されたCitrix Virtual Apps and Desktopsへの入り口として、NetScaler(Gateway)が動いています。オンプレミス環境のユーザーからのアクセスがTransit Gatewayを通過しAWSのVPCに到達、NetScaler#1がトラフィックを処理していて、HA切り替わりが発生する前の状態です。
Figure 1
次に、HAフェイルオーバーが発生します。
Figure 2
①NetScaler HAフェイルオーバーが発生
②NetScalerが以下のFQDNをDNSサーバーに名前解決
・ec2.ap-northeast-1.amazonaws.com(東京リージョンの場合)
・iam.amazonaws.com
③NetScalerに付与されたIAM権限をもってNetScalerがAWSコンソール(EC2、IAM)にアクセス
④NetScaler#1を指していた該当のルートをNetScalerが書き換える
Before: 宛先 <VIP address> Nexthop <NetScaler#1のENI ID>
After: 宛先 <VIP address> Nexthop <NetScaler#2のENI ID>
この動作によってユーザーからのアクセスはNetScaler#2に向かっていき、処理されます。GARPが使用できないため、HAファイルオーバーをトリガーにルートテーブルを書き換えることで提供するサービスを維持する仕組みです。上記簡易シーケンス説明に加えて、ポイントを説明します。
まず②で使用されるDNSサーバーは/etc/resolv.confに自動的に設定されるDNSサーバーになります。AWS環境のNetScalerの仕様上、Amazon VPC の DHCP オプションセットからresolv.confの内容が決定します。
③では、名前解決されたEC2とIAMコンソールを宛先にNetScalerのNSIPから通信が発生します。つまり、NetScalerのNSIPからインターネットアクセスが必要です。(EC2はVPCエンドポイントを使用している場合にはその限りではありません)
その他のIAM Role、IPアドレス設計等の要件については弊社Docsをご確認ください。これらのポイントはこのソリューションを実装するための必要要件となってきます。
AWSを使用する際に様々な運用面でのルール、セキュリティのルールを策定しているお客様がほとんどだと思います。その中で、このNetScalerのHAを構成するための要件は少なくありません。必要要件を把握した上での構築計画をお勧めいたします。
HAを組むことはシンプルでわかりやすい冗長性ですが、上記要件を満たせず、断念せざるを得ない状況もあるかと思います。その場合には、独立したNetScalerを並べてその前段にロードバランサーを配置する構成も採れます。
Figure 3
この手法は全てのNetScalerがアクティブに稼働しています。ルート変更の様なAWS環境を操作することもないため、IAM Roleやインターネットアクセスなどの要件もありません。デメリットとして、AWS LBのインスタンスが別途必要なのでコストと運用負荷に影響があることと、オンプレミスとCluster構成と比べた場合、一台一台個別に設定しないといけないため、同様に構築と運用の負荷がかかる点です。
今回は、AWS環境でNetScalerを使用する一例を紹介させていただきました。一言にクラウド移行と言っても、環境変化に伴って必要な要件も増減するかと思います。コンサルティングサービスでは、今回ご紹介した様な見えにくい、かつ構成検討に必須の要件を抑えています。円滑なソリューション導入に向けて、弊社コンサルティングサービスの活用もご検討いただければ幸いです。
