既存の環境に NSX Advanced Load Balancer を展開する場合、アプリケーション ワークロードを他のロード バランサから NSX Advanced Load Balancer に移行することが必要になることがよくあります。NSX Advanced Load Balancer は、お客様の厳しい要件と、ライブ マイグレーション中に稼動状態を維持する必要性を認識しています。このセクションでは、F5 の BIG-IP LTM から NSX Advanced Load Balancer に移行するプロセスについて説明します。
NSX Advanced Load Balancer は、競合他社のアプリケーション提供コントローラやロード バランサが共通して搭載する幅広い機能を提供します。 また、広範な分析データ、一元化された制御プレーン、最新の分散データ プレーン アーキテクチャを組み込むことで、ロード バランサの機能と価値も高めています。結果的に、極めて直感的で高度に自動化されたロード バランサ ファブリックが生まれ、これが、運用の複雑さを軽減し、展開、学習、および管理にかかる時間を短縮します。
概念
F5 と NSX Advanced Load Balancer は、類似する高レベルの機能を多数提供していますが、各種機能の操作方法、および機能や概念の名称についても、アーキテクチャ上の重要な違いがあります。
F5 からの移行を正常に行うため、VMware エンジニアが違いについて説明し、NSX Advanced Load Balancer の最適な展開が確実に行われるようにします。一部のお客様は、F5 構成をできるだけそのままの状態で再作成することをご希望です。一方で、ロード バランシング インフラストラクチャを再設計し、最新化してもよいとお考えのお客様もいらっしゃいます。
概念 |
F5 の用語 |
NSX Advanced Load Balancer 用語 |
|---|---|---|
アプリケーション プロキシ |
仮想サーバ |
仮想サービス 詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』の「仮想サービス」トピックを参照してください。 |
サーバ グループ |
プール |
プール 詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』の「サーバ プール」トピックを参照してください。 |
データ プレーンのスクリプティング |
iRules™ |
DataScript 詳細については、『VMware NSX Advanced Load Balancer DataScript ガイド』の「DataScript ガイドの概要」トピックを参照してください。 |
API |
iControl™ |
|
ロード バランサ |
BIG-IP™ LTM™ + GTM™ |
サービス エンジン 詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「サービス エンジン」トピックを参照してください。 |
接続の集約 |
OneConnect™ |
多重化 詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』の「接続の多重化」トピックを参照してください。 |
中央構成マネージャ |
Enterprise Manager™ / BIG-IQ™ |
コントローラ 詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「制御プレーン」トピックを参照してください。 |
Orchestrator |
なし |
コントローラ 詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「制御プレーン」トピックを参照してください。 |
制御プレーン
アーキテクチャ上、NSX Advanced Load Balancer はコントローラまたはコントローラの冗長クラスタによって管理されます。 NSX Advanced Load Balancer ファブリックは、ロード バランサ アプライアンスの各ペアにログインして管理するのではなく、Controller クラスタによって管理されます。単一の Controller クラスタで、数百ものサービス エンジンを（VMware や OpenStack などの異なるクラウドに展開されている場合でも）管理できます。複数の Controller クラスタを展開することもできますが、これは通常、地理的に離れたデータセンターの場合に行われます。 1 つのクラスタで、異なるテナントによって分離されたテスト環境と本番環境の両方を管理することも、それぞれ独自のクラスタを作成することもできます。
データ プレーン
サービス エンジン (SE) と呼ばれる NSX Advanced Load Balancer のロード バランサは、アクティブ/スタンバイ ペアで BIG-IP と同様に展開することも（NSX Advanced Load Balancer のレガシー HA モードを使用）、完全にアクティブなグループを使用して Elastic HA モードで展開することもできます。テナント、VRF、クラウド、および SE グループを介して個別のグループを切り分ける構成オプションは多数あります。各アプリケーションに独自のロード バランサがある場合や、すべてのアプリケーションがサービス エンジンのグループを共有している場合があります。BIG-IP から移行する際、アプライアンスペアとファブリックのどちらを選択するかは、アーキテクチャに関する最初の問いの 1 つであり、その答えとして、どのように統合し、未使用のロード バランサのキャパシティを最小限に抑えるかを決定する必要があります。
移行
既存のライブ環境からの移行は、繊細なプロセスです。NSX Advanced Load Balancer は、移行ツールと数十年にわたるロード バランシングの経験を持つエンジニアを組み合わせた移行サービスを提供します。
自動化
BIG-IP LTM 構成は、NSX Advanced Load Balancer の JSON 構成形式に自動的にインポートできます。BIG-IP から Vantage への構成の移行ツールは、仮想サービス、プール、および bigip.conf ファイルで構成された隣接するほとんどの機能をインポートします。自動的にインポートできる追加の構成オブジェクトには、グループ、SSL キー、証明書が含まれます。これにより、数万に及ぶ行が含まれることが多い BIG-IP 構成ファイルを変換するときのエラーを排除できます。構成ユーティリティは、変換されたすべての構成設定を示す完全な出力を提供します。
手動
BIG-IP LTM の一部の機能は自動的に変換できません。たとえば、F5 の iRule は移行されません。NSX Advanced Load Balancer の経験では、全 iRule の約 75% はネイティブのポイントアンドクリック機能に変換できますが、その決定を行うためにプロフェッショナル サービス エンジニアが iRule を手動で検査します。ネイティブ機能として実行できない iRule は、NSX Advanced Load Balancer の DataScript 形式で書き換えられます。これは、ロジックと関数に似ていますが、より新しい Lua 言語に基づいています。
LTM 構成のみが移行され、他のモジュールは手動で実行する必要があります。機能を直接変換できない場合は、VMware エンジニアがお客様をサポートしながら解決策を提示するか、最善の対策を決定します。
カットオーバー
構成を NSX Advanced Load Balancer 展開に移行したら、テストを開始します。すべての仮想サービスが移行され、無効状態のままになるため、ARP の競合は発生しません。カットオーバー前に構成をテストする方法がいくつもあります。最もよくあるのは、仮想サービスに新しい IP アドレスを指定し、有効としてマークすることです。
仮想サービスはサービス エンジンに展開され、テストに使用できるようになります。これには、DNS で代替名を使用するか、クライアント ホスト ファイルを変更することによって、仮想サービスに直接アクセスすることが伴います。このテスト シナリオでは、サーバでの変更を不要にするために通常 SNAT が推奨されますが、トラフィックはサーバのデフォルト ゲートウェイではなく、NSX Advanced Load Balancer のロード バランサ経由で同期的に返されます。
仮想サービスを本番用に稼動する準備ができたら、仮想サービスは BIG-IP で無効になり、NSX Advanced Load Balancer で有効になります。追加の IP アドレスが使用可能な場合は、仮想サービスに一意の IP アドレスを使用するように NSX Advanced Load Balancer を構成できます。カットオーバーは、DNS を介してアドバタイズされた IP アドレスを変更することによって実行されます。新しいトラフィックはライブ トラフィックを中断することなく NSX Advanced Load Balancer を介して処理され、トラフィックは BIG-IP からグレースフルになくなります。
このプロセスは、必要に応じてすべてのアプリケーションに対して繰り返すことができます。
