BIG-IP LTM によってローカルに負荷分散されるノードのクラスターを収容する各サイトは、BIG-IP DNS に入力する必要があります。トラフィック管理をサポートするために DNS 同期グループを作成しているため、この設定はグループの DNS メンバー間で共有されるため、この操作は 1 つの BIG-IP DNS でのみ実行する必要があります。

TMUI GUI から、[DNS] > [GSLB] > [データ センター] > [データ センター リスト] を選択し、 StorageGRIDサイトごとにエントリを作成します。図 1 に沿ったネットワーク設定を使用する場合、DNS アプライアンスがStorageGRID以外の他のサイトに配置されている場合は、ストレージ サイトに加えてこれらのサイトのデータ センターを追加します。この例では、サイト a と b がオハイオ州とオレゴン州に作成され、BIG-IP はデュアル DNS および LTM アプライアンスです。

これで、個々のStorageGRIDサイト クラスターを BIG-IP DNS セットアップに接続する準備が整いました。各サイトの BIG-IP アプライアンスは、「バックエンド」 IP アドレス/ポートを使用して、「フロントエンド」の到達可能な IP アドレス/ポートをストレージノードアプライアンスのバックエンド「プール」のセットに結び付ける仮想サーバーの構成を通じて、S3 トラフィックの実際の負荷分散を実行します。

たとえば、サイトの廃止のため、またはリアルタイムのヘルス チェックの失敗によって予期せず、プール内のすべてのストレージ ノードが管理上オフラインになった場合、DNS クエリ応答が変更され、トラフィックは他のサイトに送信されます。

StorageGrid サイト、具体的にはローカル仮想サーバーを各アプライアンスの BIG-IP DNS 構成に結び付けるには、セットアップを 1 回だけ実行する必要があります。次のステップでは、BIG-IP DNS アプライアンスのグループ全体の設定が同期されます。

簡単に言うと、DNS、LTM、または DNS と LTM の両方のライセンスが付与されているすべての BIG-IP アプライアンスのリスト (サーバー リストと呼ばれる) を作成します。このマスター リストは、リストが完成するとすべての BIG-IP DNS アプライアンスと同期されます。

1 台の BIG-IP DNS ライセンス アプライアンスで、[DNS] > [GSLB] > [サーバー] > [サーバー リスト] を選択し、追加ボタン (+) を選択します。

各 BIG-IP を追加する際の 4 つの重要な要素は次のとおりです。 * 製品のプルダウンから BIG-IP を選択すると、他のロード バランサも選択できますが、通常、各サイトでバックエンド ノードの健全性が低下した場合のリアルタイムの可視性の応答性が欠如します。* BIG-IP DNS アプライアンスの IP アドレスを追加します。おそらく、BIG-IP DNS アプライアンスを初めて追加する場合、アドレスは現在の GUI アクセスされたアプライアンスになり、将来のアプライアンスはソリューション内の他のアプライアンスになります。* ヘルスモニターを選択し、追加するロードバランサーが BIG-IP アプライアンスである場合は、バックエンドのStorageGRIDノードのヘルスを考慮して、常に「BIG-IP」を使用します。* アプライアンスがデュアル DNS/LTM アプライアンスである場合は、オプションで仮想サーバーの自動検出を要求します。

一時的なネットワークの問題やネットワークの場所間のファイアウォール ACL ルールなどの状況によっては、この段階でリモート アプライアンスを追加すると、仮想サーバーの検出で LTM が設定されたリモート アプライアンスのエントリが表示されないことがあります。このような場合、新しいアプライアンス (「サーバー」) を追加した後、以下に示すように仮想サーバーを手動で追加できます。BIG-IP DNS のみのアプライアンスを追加する場合、そのデバイスに検出または追加される仮想サーバーは存在しません。

すべてのサイトで、ソリューション内の各アプライアンス（BIG-IP DNS アプライアンス、BIG-IP LTM アプライアンス、DNS ユニットと LTM ユニットの両方の役割を果たすアプライアンスを含む）にこれらのサーバー エントリを追加する必要があります。

次の例では、4 つのアプライアンスがサーバーとして追加され、2 つのサイトに分散されています。各サイトには専用の BIG-IP DNS と BIG-IP LTM があることに注意してください。ただし、現在ログインしているアプライアンス以外のすべてのアプライアンスの「ステータス」列には青いアイコンが表示されています。これは、他の BIG-IP アプライアンスとの信頼関係がまだ確立されていないことを意味します。

信頼を追加するには、GUI 経由で構成の詳細を入力した BIG-IP に SSH で接続し、「root」アカウントを使用して BIG-IP のコマンドライン インターフェイスにアクセスします。プロンプトで次の単一コマンドを発行します: bigip_add

「bigip_add」コマンドは、クラスタ内のGSLBサーバ間の暗号化された「iQuery」チャネルのセットアップ時に使用するために、宛先BIGIPデバイスから管理証明書を取得します。iQueryはデフォルトでTCPポート4353を使用して実行され、BOG-IP DNSメンバーが同期状態を維持できるようにするハートビートです。暗号化されたチャネルでは xml と gzip を使用します。オプションなしで「bigip_add」を実行すると、現在のユーザー名を使用してエンドポイントに接続し、GSLB サーバー リスト内のすべての BIGIP デバイスに対してコマンドが実行されます。成功を簡単に確認するには、BIG-IP GUI に戻り、表示されたプルダウン メニューにすべてのサーバーの証明書がリストされていることを確認します。

最後のステップでは、1 つのユニットの TMUI GUI を使用するだけで、すべての BIG-IP DNS アプライアンスを完全に構成できるようになります。サンプルのケースでは、2 つのStorageGRIDサイトがあり、これは SSH を使用して 他の サイトの BIG-IP DNS のコマンド ラインにアクセスすることを意味します。ルートとして接続し、ファイアウォール ポリシー/ACL によって 2 つの BIG-IP DNS デバイスが TCP ポート 22 (SSH)、443 (HTTPS)、および 4354 (F5 iQuery プロトコル) で通信できることを確認した後、プロンプトで次のコマンドを実行します: gtm_add <すべての GUI 手順が以前に実行された最初のサイトの BIG-IP DNS の IP アドレス>

この時点で、グループに追加されたすべての BIG-IP DNS アプライアンスで、以降のすべての DNS 構成作業を実行できます。上記のコマンド gtm_add は、LTM のみであるアプライアンス メンバーに適用する必要はありません。DNS をサポートするアプライアンスのみ、同期された DNS グループの一部になるためにこのコマンドが必要です。

簡単な架空の例として、storage.quantumvault.com という名前の WIP では、潜在的な仮想サーバーの 2 つのプールにリンクされた BIG-IP DNS ソリューションが表示される場合があります。最初のプールは北米の 4 つのサイトから構成され、2 番目のプールはヨーロッパの 3 つのサイトから構成される可能性があります。

選択されたプールは、さまざまなポリシー決定から決定される可能性があります。たとえば、トラフィックの大部分を北米のStorageGRIDサイトに誘導するには、単純な 5:1 の比率を使用できます。おそらくもっと可能性が高いのは、トポロジ ベースの選択で、たとえば、ヨーロッパからのすべての S3 トラフィックがヨーロッパのサイトに送られ、世界の残りの S3 トラフィックが北米のデータ センターに送られるようなプールが選択されることです。

BIG-IP DNS によってプールに到達すると、北米のプールが選択されたと仮定すると、storage.quantumvault.com を解決するために返される実際の DNS A リソース レコードは、4 つの北米サイトのいずれかにある BIG-IP LTM によってサポートされている 4 つの仮想サーバーのいずれかになります。どちらが選択されるかについても、ポリシーに基づいており、ラウンドロビンなどの単純な「静的」アプローチが存在する一方で、ローカル DNS リゾルバーから各サイトの待ち時間を測定するパフォーマンス プローブなどのより高度な「動的」選択が維持され、サイト選択の基準として使用されます。

BIG-IP DNS 上に仮想サーバーのプールを設定するには、メニュー パス DNS > GSLB > プール > プール リスト > 追加 (+) に従います。この例では、さまざまな北米の仮想サーバーがプールに追加され、このプールが選択されたときに、負荷分散の優先アプローチが階層的に選択されていることがわかります。

DNS > GSLB > ワイド IP > ワイド IP リスト > 作成 (+) の順に選択して、DNS によって解決されるサービスの名前である WIP (ワイド IP) をデプロイメントに追加します。次の例では、S3 対応ストレージ サービスの WIP の例を示します。

多くの可能なアプローチの 1 つは、上記の単純な「ラウンドロビン」の例ではなく、「グローバル可用性」モードを使用することです。グローバル可用性を使用すると、プールの順序、または単一のプール内の仮想サーバーにトラフィックを送信できます。この方法では、すべての S3 トラフィックを、たとえばニューヨーク市のサイトにデフォルトで送信することができます。

ヘルス チェックによってこのサイトのStorageGRIDノードの可用性に問題があることが示された場合、その時点でトラフィックはセントルイスに送信される可能性があります。セントルイスで健康上の懸念が生じた場合、フランクフルトのサイトが S3 の読み取りまたは書き込みトランザクションの受信を開始する可能性があります。したがって、グローバルな可用性は、S3 StorageGRIDソリューション全体の回復力に対する 1 つのアプローチです。もう 1 つのアプローチは、階層型アプローチを使用して負荷分散アプローチを組み合わせることです。

この例では、「動的」オプションが、構成されたプール内のサイトの最初の負荷分散の選択肢になります。示されている例では、ローカル DNS リゾルバのパフォーマンスのアクティブ プロービングを使用した継続的な測定アプローチが維持され、サイト選択のきっかけとなっています。この方法が利用できない場合は、各サイトに割り当てられた比率によって個々のサイトを選択できます。比率により、大規模で高帯域幅のStorageGRIDサイトは、小規模なサイトよりも多くの S3 トランザクションを受信できます。最後に、おそらく災害復旧シナリオとして、プール内のすべてのサイトが正常でなくなった場合、指定されたフォールバック IP が最後の手段としてサイトとして使用されます。BIG-IP DNS の興味深い負荷分散方法の 1 つは「トポロジ」です。これは、DNS クエリの受信ソースである S3 ユーザーのローカル DNS リゾルバを監視し、インターネット トポロジ情報を使用して、プールから一見「最も近い」サイトを選択するものです。

最後に、サイトが地球全体に広がっている場合は、F5 BIG-IP DNS マニュアルで詳細に説明されている動的「プローブ」テクノロジの使用を検討する価値があるかもしれません。プローブを使用すると、頻繁に発生する DNS クエリのソースを監視できます。たとえば、トラフィックで通常同じローカル DNS リゾルバを使用する B2B パートナーなどが挙げられます。BIG-IP DNS プローブは、世界中の各サイトの BIG-IP LTM から起動して、S3 トランザクションのレイテンシが最も低くなる可能性のあるサイトを大まかに判断できます。そのため、アジアからのトラフィックは、北米やヨーロッパにあるサイトよりもアジアのStorageGRIDサイトの方が適切に処理される可能性があります。