先日のGMOクラウドVPS
ダウンで、サポートに入れてあった問い合わせに返信メールが来て、SLA適用で月額の10％分をデポジットとしてチャージしたとの事。
管理画面で確認すると118円がチャージされていた。 しかし、6ヶ月契約してるから、次回の契約更新時にすこし（７０８０－１１８）値引きされる感じだね。
しかし、デポジットだから契約を継続しないと受けられないわけだな。
まぁ、どこの世界にも絶対に落ちないサーバは無いんだし、一度ミスった方が安全かもしれない？ しばらくつきあいますか・・・
(373)
先日のGMOクラウドVPSのダウン時に活躍した簡易スクリプト。
現在運用しているさくらVPS
、お名前.com VPS
と共に、このバッチを走らせて相互に簡易監視している。
#!/bin/sh
serverlist=(‘server1.hoge.tld’ ‘server2.hoge.tld’ ‘www.piyo.tld’)
mailto=’address@hoge.tld’
date=date '+%Y-%m-%d %H:%M:%S'
for server in ${serverlist[@]}
do
loss=ping -c 1 $server | grep "% packet loss" | sed -e "s/^.* \([0-9]*\)% packet loss.*/\1/"
if test $loss -ne 0; then
echo "[$server] : No responding." | mail -s "Server alert [$server] @ $date" $mailto
fi
done
HTTP監視とか一切せず、pingを一回打ってみて帰ってこなかったらサーバ名をメールするシェル。
serverlistに監視対象サーバを列挙して、mailtoに通知先アドレスを入れるだけ。
実行権限をつけてcronで、
*/5 * * * * /home/myhome/bin/pingwatch.sh
みたいにして回す。
ちょっと書き足して、wgetとかcurlを使うようにすればHTTP等の監視も出来るけど、これくらいがコンパクトで良いかと。
(214)
昨日（2012/10/18 20:47）からこのブログを入れているGMOクラウドVPSで障害が発生、結局、今日2時7分頃になってやっとサーバが立ち上がった。
ダウンタイムは5時間強、SLAで返金があるのかな。
会社から帰宅途中に監視のアラートメールがケータイに飛んできてなかなか慌てた（GMOクラウドとさくらで相互に監視している）
当初2時間近くアナウンスもなく公式サイトにも接続できず、ユーザのTwitterや掲示板で状況確認する羽目になった。
結局、得られた公式情報は22:30の公式Twitterが最初だった。 障害情報すら得られないのは困りものだ。
メールがバックアップサーバに飛んでいるからマスタサーバに統合しなきゃなぁ・・・
(334)
最近、島問題の影響のようでさくらVPSやお名前.com VPS(KVM)のホストにも大陸や半島方面からのDoS的なアクセスがままあってそのたびにホスト制限していたのですが、面倒くさいので、アドレス割り当て情報から大陸と半島からのアクセスを制限するためのiptables設定をしました。
-Aじゃなくて-Iなのは、許可ルール以前にこのIPを拒否したいため。
シェル実行してから /etc/init.d/iptables save で保存できる。
ドロップしたパケットを記録したい場合は、
-N LOGDROP
-A LOGDROP -j LOG –log-prefix “[iptables drop]”
-A LOGDROP -j DROP
みたいに、新しい挙動LOGDROPを定義して、LOGDROP挙同時にはLOGってDROPする動きにする。
で、従来の-j DROPの代わりに-j LOGDROPにしてやると、messagesログファイルにドロップした情報が記録されるようになる。
LOGDROPを定義せずにLOGって、DROPしてを繰り返し書いても良いけど、数が多いときはこの方が楽。
(1041)
MySQLの便利機能でGROUP_CONCATってのがある。
SELECT primary_id, GROUP_CONCAT(item_id) AS item_id_list FROM stock GROUP BY primary_id ORDER BY primary_id ASC LIMIT 50
みたいにすると、stockテーブルのprimary_idでグループ化して、そのグループ内のitem_idをカンマ区切りで返してくれる。
このとき、item_id_listはBLOBになったりする。
こんな感じでもっと複雑なテーブルについてきたとき、ORDERやLIMITの関係でtmpテーブルでの作業が発生するんだけど、BLOBがMEMORYエンジンに乗らないのでボトルネックになっていた。
さくらVPSやお名前.com VPS(KVM)では、物理マシンに比べてディスクI/Oが弱いのでTmp to Diskになると著しく遅くなるので改善したい。
ORDERやLIMITがINDEXで直ちに確定できない場合に、巨大なデータセットがtmpになるので、とりあえずこれをサブクエリにして
SELECT s.*, GROUP_CONCAT(item_id) AS item_id_list FROM (SELECT primary_id FROM stock GROUP BY primary_id ORDER BY primary_id ASC LIMIT 50) p LEFT JOIN stock s ON s.primary_id = p.primary_id GROUP BY s.primary_id ORDER BY s.primary_id ASC
みたいにした方が高速になった。
この場合は、外のクエリは結局tmpの処理があるんだけど、LIMIT処理がサブクエリ中でかかっているから、JOINの段階でデータサイズが小さくなってCopy to Tmp Tableの時間が短縮できる。
中間処理テーブルが大きくてLIMITが小さい場合ほど効果的。
まぁ、根本を直した方が良いんだけど、とりあえず、簡単な修正で処理時間を短縮できるメモ。
(1261)
