Clever Geek Handbook

Cisco IP SLAベースのキャッシングDNSバランシング

DNSが失敗する







インターネットサービスプロバイダーのネットワークでは、キャッシュDNSサービスなどの必須要素を見つけることができます。 また、DNSサービスを使用しないインターネットの作業は不可能であるため、必須の冗長性とバランスを備えたこのようなサーバーが少なくとも2つ存在します。 このメモでは、Cisco IP SLAに基づいて複数のキャッシュサーバー間で負荷を分散するためのオプションの1つを説明しようとします。







可能な解決策



クライアント側のバランス



キャッシュDNSを予約する最も簡単な方法は、クライアント側でDNSサーバーアドレスを使用して複数のレコードを構成することです。 DNSサーバーアドレスは、さまざまな方法でクライアントに報告できます。









クライアントは、最初のサーバーが利用できない場合、自動的に2番目のサーバーに切り替わります。 しかし、この方法には2つの明らかな欠点があります。







最初の-完全な負荷分散はありません。 最初のサーバーがアクセス可能で動作している間（そしてサーバー障害は不快なものであると想定していますが、非常にまれです）、サブスクライバーは2番目のサーバーに切り替える理由がなく、アイドル状態です。







2番目の欠陥は最初の欠陥に完全に由来していますが、非常に重要です。 バックアップサーバーに切り替える基準は、クライアント側の設定によって完全に決定されます。 たとえば、ここに、 標準のWindows XP DNSクライアントタイミングの説明があります 。 この記事から、メインサーバーが1秒以内に応答しない場合にのみ、Windows XPがバックアップサーバーの使用に切り替えることがわかります。 つまり オーバーロード、構成エラー、または障害の結果として、メインサーバーが正常に機能しないが、0.95秒以内に応答する状況を想像できます。 明らかに、このような遅延があるため、加入者は通常のインターネット操作について話すことができません。 しかし、応答時間が1秒未満であるため、サブスクライバーは「泣き、刺しますが、サボテンを食べ続けます」、またはサービスの低下を経験しますが、アイドル状態のバックアップDNSサーバーに切り替えません。







もちろん、DNSサービスのこの動作は異常であり、監視システムによって検出され、その後の問題のエスカレーションが必要です。 しかし、監視の問題はメモのトピックから離れています。







宛先NAT



別のバランシング方法は、宛先NATです。 このソリューションは、Webサーバーのクラスターでの負荷分散に積極的に使用されています。 この場合、サブスクライバーは単一のDNSサーバーアドレス（NATインターフェイスアドレス）を使用し、実際のDNSサーバーにはプライベートアドレス指定があります。 加入者がDNSサーバーにアクセスすると、宛先IPアドレス要求でいずれかのサーバーにブロードキャストします。 このアプローチにより、負荷を均等に分散できます。 しかし、Webサーバーの場合、本格的なNATは、通常DNSクエリに使用されるステートレスUDPトランスポートとは対照的に、そこでのトランスポートがステートフルなTCPプロトコルを提供するという事実により正当化されるため、この方法はやや冗長です。 Webサーバーとのトラフィック交換とは異なり、クライアントとDNSサーバーとの対話は非常に簡潔で、要求と応答のペアのみが関係しています。







静的ルーティング



より簡単な方法は、静的ルートを使用することです。 IPアドレスを持つ3つのDNSサーバーがあるとします。









ループバックインターフェイスが10.10.10.10に設定されているそれぞれ。 DNSはこのアドレスの要求を受信するように構成されており、ファイアウォールにはTCP / UDPポート53のルールがあります。







この場合、これらのサーバーはいずれも、宛先アドレス10.10.10.10でDNSクエリを処理する準備ができています。 これは、すべてのサブスクライバーによって使用されるDNSサーバーのIPアドレスになります。 実サーバー間で要求を分散することは残っています。 特別なことは何もありません。 サーバーが接続されているルーターに3つの静的ルートを構成します。 







ip route 10.10.10.10 255.255.255.255 10.0.0.1 ip route 10.10.10.10 255.255.255.255 10.0.0.2 ip route 10.10.10.10 255.255.255.255 10.0.0.3


その結果、次の図が得られます。 







 Router#show ip route 10.10.10.10 Routing entry for 10.10.10.10/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.1 Route metric is 0, traffic share count is 1 10.0.0.2 Route metric is 0, traffic share count is 1 10.0.0.3 Route metric is 0, traffic share count is 1


これで、標準のフローごとのバランシングメカニズムは、3つの利用可能なルートに沿って異なるサブスクライバーからのリクエストを順番にレイアウトします。







バランススキーム







フェールオーバーにIP SLA DNSを使用する



バランス調整が完了したので、サーバーの1つに障害が発生した場合にトラフィックを切り替える問題を解決する必要があります。 Cisco IP SLAメカニズム、またはむしろIP SLA DNSオペレーション機能は、これに役立ちます。







職務内容



簡単に言うと、この関数の操作は次のように説明できます。







  1. 3つのIP SLAエントリがルーター構成で作成され、3つのDNSサーバー（たとえば、標準のA-RRリクエストwww.google.com）のそれぞれに定期的にクエリが実行されます。 クエリ結果により、レコードの状態が決まります。







  2. 対応するIP SLAのステータスがOKと異なる場合、 DOWNステータスになるIP SLAエントリに関連付けられた3つのTrackオブジェクトがあります。







  3. 上記のセクションからの3つの静的ルートは、それぞれのTrackオブジェクトにリンクしています。


現在、ある時点でサーバーの1つがDNSクエリに応答しない、または正しく応答しない場合、対応するTrackオブジェクトはDOWN状態になり、それに関連付けられた静的ルートはルーティングテーブルから消えます。 その結果、問題のあるサーバーはバランシングメカニズムから除外されます。







構成例



IP SLA設定： 







 ip sla 1 dns www.google.com name-server 10.0.0.1 timeout 5000 frequency 9 threshold 10 ip sla 2 dns www.google.com name-server 10.0.0.2 timeout 5000 frequency 9 threshold 10 ip sla 3 dns www.google.com name-server 10.0.0.3 timeout 5000 frequency 9 threshold 10


追跡のアクティブ化と構成： 







 ip sla schedule 1 life forever start-time now ip sla schedule 2 life forever start-time now ip sla schedule 3 life forever start-time now track 1 ip sla 1 track 2 ip sla 2 track 3 ip sla 3


追跡を参照してルートを設定する： 







 ip route 10.10.10.10 255.255.255.255 10.0.0.1 track 1 ip route 10.10.10.10 255.255.255.255 10.0.0.2 track 2 ip route 10.10.10.10 255.255.255.255 10.0.0.3 track 3


テスト中



現在、ルート自体に加えて、現在機能している3つのIP SLAがあり、最後の要求の結果は誰でもOKです。 







 Router# show ip sla statistics IPSLA operation id: 1 Latest RTT: 1 milliseconds Latest operation start time: 15:33:27 UTC+7 Wed Aug 17 2016 Latest operation return code: OK Number of successes: 373 Number of failures: 0 Operation time to live: Forever IPSLA operation id: 2 Latest RTT: 1 milliseconds Latest operation start time: 15:33:27 UTC+7 Wed Aug 17 2016 Latest operation return code: OK Number of successes: 373 Number of failures: 0 Operation time to live: Forever IPSLA operation id: 3 Latest RTT: 1 milliseconds Latest operation start time: 15:33:27 UTC+7 Wed Aug 17 2016 Latest operation return code: OK Number of successes: 373 Number of failures: 0 Operation time to live: Forever


DNS-1サーバーでDNSサービスを無効にしてみましょう。 次のチェック（9秒に1回発生）で、対応するIP SLAが問題を報告します。 







 Router# show ip sla statistics 1 IPSLA operation id: 1 Latest RTT: NoConnection/Busy/Timeout Latest operation start time: 15:37:48 UTC+7 Wed Aug 17 2016 Latest operation return code: Timeout Number of successes: 1 Number of failures: 1 Operation time to live: Forever


そして、ネクストホップ10.0.0.1の対応するルートはルーティングテーブルから消えます： 







 Router#show ip route 10.10.10.10 Routing entry for 10.10.10.10/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.2 Route metric is 0, traffic share count is 1 10.0.0.3 Route metric is 0, traffic share count is 1


クライアント要求は、残りの2つのサーバー間で分散されます。 サービスを再起動すると、次にIP SLAを確認したときにルートが返され、サーバーは再びバランシングに参加し始めます。







メソッドの欠点



この方法の主で最も重大な欠点は、可能な最小ポーリング頻度が9秒であることです。 多くの場合、このような「応答性」が重要です。 残念ながら、これはシスコの機能の制限です。 誰かが彼を回避する方法を教えてくれたら、私は非常に感謝します。







おわりに



キャッシュされたDNSサービスのバランスを取り、予約する際に、静的ルーティングとCisco IP SLAの使用を検討しました。 この方法の明らかな利点：







  1. セットアップの容易さ;
  2. すべてがルーターで動作し、追加の資金を必要としません。
  3. ICMPエコー要求の可用性などだけでなく、サービスの応答が制御されます。


欠点：







  1. 最小ポーリング期間は9秒です。これは、最大9 * 2 = 18秒の反応時間を意味します。


More articles:


All Articles