Multi-Region Latency Based Routing (http://goo.gl/wkkra ) という機能がAWSのDNSサービスであるRoute53から発表されました。
そもそも、cdn.debian.netの全体図はこんな具合。cdn.debian.netの再実装開始という記事
dns_balanceが動作しているホスト(当然DNSサーバが動いている)に対して、どうやって早く接続するのか、という問題がある。
今回発表された、Multi-Region Latency Based Routing で、日米欧で動作させているdns_balanceに対してエンドユーザ(の使っているDNSキャッシュサーバ)を誘導するようになりました。
これまでは、日本のユーザでも一定の割合でヨーロッパのDNSサーバを参照する場合があった(キャッシュサーバの実装次第)のが、なくなり、300から500msecほど(平均ではその1/3)解決までの時間が短かくなったはずです。
こんばんは。cdn.debian.net、ftp.jp.debian.orgなどの管理をしている荒木です。
本日未明から14:06まで上記Debianミラーサーバへの到達性が著しく低下する事故が発生しました。
100%ではありませんが、日本からの80%を越えるアクセスについて、到達できない状態が続きました。
本MLに情報をおよせになった、野田様、ご意見ありがとうございます。
おっしゃる通り、「いかがなもの」と感じられたのかと思います。
今回の事は、本来動作しているべき死活監視が意図通り作動しなかったことによるものでした。
死活監視は
1. 死活監視対象情報をキューに蓄積、
2. 死活監視プログラムがキューから取得、死活監視情報をDBにかきこみ、キューから消去
という二つのプログラムで構成されています。
今回の問題は、1は正常動作しているものの、通常2箇所で動作している2のプログラムが停止したことによります。
時間経過で示します。
未明(時間不明) jaistにおけるミラーがメンテナンス開始。それに伴いミラーサーバの利用が困難に。
11:47 twitterで、石川むつみさんから、第一報。その後数分で問題を確認。
13:44 死活監視キューの処理を開始
13:50 通常の方法ではキュー処理がまにあわないのでキューを全削除
14:06 3つあるDNSのうちひとつ目の処理終了
14:11 障害対応終了
14:20 キューの最大保持時間を削減
15:11 キューの数を監視し、一定数を越えると通知する仕組みを実装し、利用開始
今回の対策により確認キュー処理の遅れに気がつかずにそのままになることはないはずですが、
2のプログラムそのものを動作させることができるノード数は現状の2からさらに追加することで対策をします。
今回は死活監視システムそのものに問題があったため、対応できるのが荒木しかおりませんでした。
[皆様にお願い]
障害情報を私に伝えてくださる方がいらっしゃったら、どうぞ遠慮なくお知らせください。
関係しそうなサーバの計画メンテナンスなど私にリマインダ下さるかたがいれば大歓迎です。
また、2のプログラムを動作させててもかまわない方がいらっしゃれば御一報ください。
外部から接続できる必要はありません。HTTPでの外部インターネットにアクセス可能であればノートパソコンでも
動作します。
最後に、本サービスは今後も改善を続けてまいります。
公開の場であれば、障害情報や要望なども広く受けつけておりますので、どうぞ遠慮なく。
