EDNS を使用してストレージトラフィックを最適化
ストレージインフラの負荷分散に DNS を使用する際には、DNS リクエストを送信したクライアントデバイスの可視性に関していくつかの制限があります。DNS リクエストは上位の DNS サーバーを経由して転送されるため、元のクライアントの IP アドレスは引き継がれません。その結果、地理的な負荷分散は最後の DNS フォワーダーの IP アドレスに基づいて行われることになります。これは、最後のフォワーダーが国内の ISP であれば、国単位の位置情報に基づく負荷分散が可能なため、広域なグローバルレベルではある程度機能します。しかし、同じ国の中やプライベートネットワーク内で DNS 負荷分散を行う場合には、すべてのトラフィックが単一、あるいは限られた数の送信元から来ているように見えてしまうという問題があります。
EDNS (DNS 拡張メカニズム) はこの課題を解決します。EDNS を使うことで、DNS フォワーダーチェーンを通じて元のクライアントサブネットの情報を伝えることが可能になり、DNS リゾルバーはリクエストの実際の送信元を識別できるようになります。LoadMaster は EDNS をサポートしており、DNS を使用した負荷分散においてより適切な判断と制御が可能になります。クライアントサブネットを識別できるこの機能により、単にユーザーを「近くの」サービスに接続するという一般的な用途を超えた、様々なユースケースが実現可能になります。
特定の業界分野では、アニメーションのレンダリングや金融シミュレーションの実行などのタスクにおいて、コンピュートとストレージを組み合わせた複数のラックが使用されることがあります。ストレージがラック間でレプリケーションされていたとしても、コンピュートリソースが自分のラック外のストレージにアクセスするのは非効率的です。この問題に対する一つの解決策は、各ラックに固有の名前空間 (Namespace) を割り当て、コンピュートノードが自分のラックの名前空間に明示的にアクセスするようにすることです。
図 1 – 一意の名前空間を使用してトラフィックをラック内に保持する
ラックごとの名前空間アプローチは、ストレージトラフィックをラック内に限定することができる一方で、ラック内ストレージに障害が発生すると、そのラック上で動作しているコンピュートノードのタスクが失敗してしまいます。シミュレーションやレンダリングのような長時間実行されるタスクにおいては、これによりタスクを最初からやり直す必要が生じ、遅延やエネルギーの無駄を引き起こす可能性があります。
この課題に対する代替手段として、EDNS(DNS 拡張メカニズム)をサポートする DNS ベースのロードバランサーと単一の名前空間を使用する方法があります。EDNS を利用することで、クライアント (コンピュートノード) を識別し、その情報に基づいてラック内のストレージに誘導することが可能になります。仮にストレージに障害が発生した場合でも、ロードバランサーが別のストレージラックへ自動的にリダイレクトするため、コンピュートタスクへの影響を回避することができます。
図 2 – 共有名前空間を使用してトラフィックをラック内に保持する
LoadMaster は、ObjectScale および Isilon ストレージ環境において EDNS と共有名前空間のシナリオをサポートしています。1つの名前空間 (FQDN) あたり最大 256 エンティティをサポートすることで、スケーラブルで、展開と管理が容易なインフラストラクチャを構築でき、ストレージノード障害時のレジリエンスも確保できます。
ストレージ環境では、一部のクライアントが頻繁かつ継続的に大量のトラフィックを生成することがあり、こうしたトラフィックをいかにインフラ全体に分散させるかが課題となります。単純なラウンドロビン方式などで負荷を分散しようとすると、トラフィックの偏りが発生する可能性があります。EDNS を使用すれば、このような高トラフィックデバイスに対して特定のストレージノードを優先的に割り当てることができ、インフラ全体においてトラフィックをより均等に分散させることが可能になります。
LoadMaster は EDNS をサポートしており、医療画像処理やメディア関連といった環境において、ストレージ管理者がトラフィックの均等分散を実現するための制御機能を提供します。ストレージ障害が発生した場合でも、こうした設定が施されたデバイスは、残存するストレージノードへ透過的にフェイルオーバーするため、サービスの継続性が確保されます。
プログレスへのメールによるお問い合わせ先:sales_japan@progress.com