web-dev-qa-db-ja.com

EC2 Elastic Load Balancer DNSとルーティングに関する問題

Amazon EC2でかなり簡単なセットアップを実行しようとしています。AmazonElastic Load Balancer（ELB）の背後にあるいくつかのHTTPサーバーです。

私たちのドメインはRoute53で管理されており、ELBを指すように設定されたCNAMEレコードがあります。

一部（すべてではない）の場所が断続的にロードバランサーに接続できないという問題が発生しました。これはELBのドメイン名の解決であると思われます。

Amazonサポートから、ロードバランサーの基になるElastic IPが変更されていること、および一部のISPのDNSサーバーがTTLを受け入れないことが問題であることが通知されました。 Amazon独自のDNSサーバーを使用してEC2インスタンスから、およびオーストラリアのローカルISPおよびGoogleのDNSサーバー（8.8.8.8）を使用して問題を再現したため、この説明には満足できません。

Amazonは、一部の場所からのダウンタイムに気づいた期間中に、ELBを通過するトラフィックが大幅にダウンしたことも確認しました。そのため、問題はエンドポイントにはありません。

興味深いことに、ドメインは接続できないサーバーで正しいIPに解決されるようですが、TCP接続を確立する試みは失敗します。

ELBに接続されているすべてのインスタンスは常に正常でした。彼らはすべてです

この問題をより深く診断する方法を誰かが知っていますか？他の誰かがElastic Load Balancerでこの問題を経験しましたか？

おかげで、

amazon-ec2load-balancingcloud
19
Cera

Amazon Elastic Load Balancer（ELB）を診断する方法をグーグルで調べているときにこの質問を見つけました。私のようなこのような問題が発生したことがある他の誰に対しても多くのガイダンスなしに答えたいと思います。

ELBプロパティ

ELBにはいくつかの興味深い特性があります。例えば：

  • ELBは1つ以上のノードで構成されています
  • これらのノードは、ELB名のAレコードとして公開されます
  • これらのノードは失敗するかシャットダウンされる可能性があり、接続はnot正常に閉じられます
  • ELBの問題を掘り下げるには、Amazonサポート（$$$）との良好な関係が必要になることがよくあります

注：別の興味深いプロパティですが、少し関連性が低いのは、ELBがトラフィックの突然のスパイクを処理するように設計されていないことです。彼らは通常、スケールアップする前に15分の大量のトラフィックを必要とするか、サポートチケットを介して要求に応じて事前に暖めることができます

ELBのトラブルシューティング（手動）

Update：AWSはすべてのELBを移行し、DNSにRoute 53を使用します。さらに、すべてのELBには、ELBのノードの完全なリストを返すall.$elb_nameレコードがあります。たとえば、ELB名がelb-123456789.us-east-1.elb.amazonaws.comの場合、Dig all.elb-123456789.us-east-1.elb.amazonaws.comのようなことを行うと、ノードの完全なリストが表示されます。 IPv6ノードの場合、all.ipv6.$elb_nameも機能します。さらに、Route 53はUDPを使用して最大4KBのデータを返すことができるため、+tcpフラグを使用する必要がない場合があります。

これを知っていれば、少しトラブルシューティングを自分で行うことができます。まず、ELB名をノードのリスト（Aレコードとして）に解決します。

$ Dig @ns-942.Amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

ELBのレコードが多すぎて単一のUDPパケットに収まらない可能性があるため、tcpフラグが推奨されます。私はまた、個人的には確認していませんが、Amazonは最大6つのノードしか表示しないこともわかっていますnlessANYクエリを実行します。このコマンドを実行すると、次のような出力が得られます（簡潔にするためにトリミングされています）。

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.Amazon.com. root.Amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.Amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

ここで、Aレコードごとに、たとえば、 ELBへの接続をテストするには、curlを使用します。もちろん、バックエンドに接続せずに、テストをELBのみに分離することもできます。 ELBに関する最後のプロパティとほとんど知られていない事実：

  • ELBを介して送信できる要求メソッド（動詞）の最大サイズは127文字です。それ以上の場合、ELBはHTTP 405-Method not allowedで応答します。

つまり、この動作を利用して、ELBが応答していることだけをテストできます。

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

HTTP/1.1 405 METHOD_NOT_ALLOWEDが表示されている場合、ELBは正常に応答しています。 curlのタイムアウトを許容できる値に調整することもできます。

Elbpingを使用したELBのトラブルシューティング

もちろん、これを行うのはかなり退屈な作業になる可能性があるため、これを自動化するためのツール elbping を作成しました。 Ruby gemとして利用できるので、rubymemがある場合は、次のようにしてインストールできます。

$ gem install elbping

これで実行できます：

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

code=405が表示されている場合は、ELBが応答していることを意味します。

次のステップ

どちらの方法を選択しても、少なくともELBのノードが応答しているかどうかがわかります。この知識を武器に、スタックの他の部分のトラブルシューティングに集中するか、何かが間違っているというAWSに対してかなり合理的なケースを立てることができます。

お役に立てれば！

21
Charles Hooper

修正は実際には簡単です。Route53ではAではなくCNAMEレコードを使用します。

AWSマネジメントコンソールで、[Aレコード]を選択し、[エイリアス]というラベルの付いたラジオボタンを[はい]に移動します。次に、ドロップダウンメニューからELBを選択します。

7
jamieb

このAWS開発者フォーラムで試すことができるいくつかの潜在的なソリューションがあります。 https://forums.aws.Amazon.com/message.jspa?messageID=387552 。

例えば：

潜在的な修正＃1

ELBに移行したときにも同様の問題があり、ELBの名前を1文字に減らすことで解決しました。 ELBの2文字の名前でも、ネットワークソリューションのDNS解決でランダムな問題が発生しました。

ELBのDNS名は-> X. <9chars> .us-east-1.elb.amazonaws.comのようになります。

潜在的な修正＃2

私はオリジナルのポスターです。すべての応答をありがとう。 TTLを非常に高く設定することで、DNSの問題が発生する頻度を減らすことができました（ネットワークソリューション以外のサーバーによってキャッシュされるため）。しかし、ネットワークソリューションにとどまることはできませんでした。サービスに関する優れたレポートに基づいてUltraDNSに移行することを考えましたが、ルート53（カバーの下でUltraDNSを使用しているため、表示される）の方が安価であるように見えました。 Route 53では、DNSの問題はなくなりました。ELB名は、Niceで長くなる場合があります。

その投稿では他にも試してみることがありましたが、それらが最良のリードであるようです。

0
slm