2012年3月25日日曜日

Route53のlatency based routingの利用

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)解決までの時間が短かくなったはずです。

2012年3月18日日曜日

ftp.jp.debian.orgが半日止まっていた件

こんばんは。cdn.debian.netftp.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での外部インターネットにアクセス可能であればノートパソコンでも
動作します。

最後に、本サービスは今後も改善を続けてまいります。
公開の場であれば、障害情報や要望なども広く受けつけておりますので、どうぞ遠慮なく。

2012年1月8日日曜日

cdn.debian.netの作業

cdn.debian.netのDNSをひとつ日本でたちあげ。そしてサーバチェック用のスクリプトもちゃんとはしらせた。

もうひとつやることがあるので明日適当にやる。

2012年1月1日日曜日

EC2南米(ブラジル)リージョン用のDebian AMIを作成した

特に誰からも作ってくれとは言われてないのだが、南米リージョン用にDebian squeezeのAMIを作成した。例えば、EBS backedの64bit環境でブートできるようになった。



他のリージョン用にも、Debianでは半ばオフィシャルのAMIを公開している。詳細は、http://wiki.debian.org/Cloud/AmazonEC2Image で確認できる。

RightScaleのものは違うが、tomと私の作ったAMIは完全にクリーンなので安心して使ってOK。

















































archversionAMI IDdisksizemaintainerlogin user
32bitsqueezeami-a627f8bbinstance10GBar@debian.orgroot
32bitsqueezeami-d427f8c9EBS10GBar@debian.orgroot
64bitsqueezeami-0626f91binstance10GBar@debian.orgroot
64bitsqueezeami-3826f925EBS10GBar@debian.orgroot

2011年8月8日月曜日

SQSいじり

SQSをいじる via ruby-aws SDKで過ぎる休日であった。

2011年7月12日火曜日

cdn.debian.netの再実装開始

それにしてもこの通信貧弱な土地からでは、シンガポールも東京もUS東西も、GSLBもそんなのかんけーねえ。
が、テキストベースなIRCとtwitterならなんとかなることがわかったので、cdn.debian.netの再実装を開始。

中の構成はこんな具合。
  • dns_balanceは日本に2つ地理的に分散した場所(これはAWSではない)と、AWSのus-westとeu-westにおいてある。
  • 一般のユーザさんというかapt-getをすると、dns_balanceにつながって、そのユーザに近いサーバに誘導される。
  • dns_balanceは定期的にcheck_serverに対して最新のサーバ生死情報をELBのURLに対してとりにいく。そこではJSONが使われる。

開発:
このcheck-serverは東京リージョンで動かす。
だが、手元のマシンからでもSQSもSimpleDBもたたけるので、その状態でコードを書ける。



2011年7月10日日曜日

SINリージョン!

新リージョンではなく、シンガポールリージョン.
今回は1月に入社して以来の代休を連休のあいだにとることにしたらけっこう日があったので今日から旅行。

シンガポールリージョンができて以来はじめてシンガポールにやってきた。シンガポール自体は2年ぶりくらいか。
あたりまえだが、SINからだとSINはえーーー!。しかし東京から東京リージョンをつかう速さのほうがもっとはやい、という印象(アクセス回線の速度差のせい)

シンガポールにはDebianのフルミラーがないので、cdn.debian.netはjaistにつながる。それでも、cdn.debian.netのほうがftp.debian.orgより断然はやい。9倍くらい。

いろいろ考えて、cdn.debian.netのprobeをGAEからAWSに移すことにしよう。この休暇中に。