nginxで特定ホスト以外からのアクセスをメンテナンス画面にする方法 (2)
d:id:sfujiwara:20100812:1281587030 の revise。
Nginxのifは条件節に&&(and)が使えない、ifのネストもできないので、複数の条件で判別したい場合は変数を使うといいよって感じです。
server {
...
#error_page 500 502 503 504 /static/50x.html;
### maintenance
error_page 500 502 504 /static/50x.html;
set $go_maintenance "true";
if ($uri ~ "^/error/") {
set $go_maintenance "false";
}
if ($remote_addr ~ "^192\.0\.2\.") {
set $go_maintenance "false";
}
if ($remote_addr ~ "^10\.0\.0\.") {
set $go_maintenance "false";
}
if ($http_user_agent ~ "nakanohito-desu") {
set $go_maintenance "false";
}
if ($http_x_open = "sesame!") {
set $go_maintenance "false";
}
error_page 503 /error/503.html;
location /error/ {}
if ($go_maintenance = "true") { return 503; } # maintenance
### /maintenance
location /static {
alias /usr/irori/contents/example.com/static;
expires 1h;
gzip on;
gzip_types text/css application/javascript application/x-javascript;
keepalive_timeout 3 3;
}
location / {
proxy_pass http://127.0.0.1:2006;
...
}
location ... {
...
}
}
- ミソは「### maintenance」から「### /maintenance」まで。
- カスタムのメンテページを出したい && 既存の設定(error_page)で503の制御をしている場合はコメントアウトして503だけはカスタムのメンテページを表示するようにする。
- カスタムメンテページは /error/ 下に配置する。メンテページで画像とか使う場合もこのディレクトリ配下に置く。
- 既存設定のlocationに食われないように、location /error/ {}と設定しておく。
- 503にするかどうかは変数$go_maintenanceで判断する。初期値は"true"。(メンテ前は"false"にしておけばよろし)
- カスタムメンテページは503になっちゃまずいので、^/error/ は "false"
- ほか、メンテ中に中の人が動作確認したい条件をひっかけて "false" にする
- $remote_addr でアクセス元のIPアドレスとか
- $remote_addrをたくさん羅列したい場合は、HttpGeoModuleを使った方が効率的。
- $http_user_agent でUser-Agentヘッダとか
- $http_x_open とかでカスタムのHTTPリクエストヘッダとか
- $remote_addr でアクセス元のIPアドレスとか
- で、if ($go_maintenance = "true") { return 503; }
- server {}の中でreturn 503してるので、後続にlocationブロックがたくさんあってもこれだけでOK
memcached(プロトコル)のデータレプリケーション
国内だけでなく国外(なぜか主に中国語)でもまだrepcachedについて言及してるのをちらほら見かけるのですが、repcachedはmemcached 1.2.8ベースですし(memcached 1.4.5に対応してる人もいるようですが)いまならKyoto Tycoon使えばいいんじゃないかと思うのです。
Kyoto Tycoonなら:
- memcachedプロトコルプラグインを使えば、Kyoto Tycoonがそのままmemcachedの代替になる（memcachedプロトコルを喋るクライアントコードはそのままでよい）
- Tokyo Tyrantと違ってexpireもOK
- memcachedの代替が目的なら、速いオンメモリDB(StashDBとか)でOK
- 非同期レプリケーションもできる
- ホットスタンバイ側のサーバリソースが無駄に思うなら、keyに応じてmodとかでリクエストするサーバを2台のどちらかに固定化してマルチマスタ構成にするのも手
- オンメモリDBで運用しつつスナップショットも採れるので、再起動してもデータが全部消えることはない。
性能面で心配してる人は、だれかのベンチマークは参考までにして、自身の要件、サーバ環境でベンチマークをとるのがいいと思います。ただ、memcachedもKTもかなり高いreq/sを出せますので、よっぽどマシン性能に差がない限りクライアント１台ではサチれないでしょう。要件のreq/sが出ればそれでヨシとするか、どうしてもサチらせたいなら、LLとかじゃなくてlibmemcached(かlibmemcache)を使ってCで書いたクライアントを複数マシンから実行し、計測するのがいいでしょう。
ちなみに、
- ログレベルを"SYSTEM"に
- Kyoto Tycoonプロトコルのポートは1975に
- タイムアウトは5秒に
- スレッド数は8に
- レプリケーションで必要なサーバIDは101に
- 更新ログは/kt/kt101/ulog-101/の下に保存
- レプリケーションタで必要なタイムスタンプを記録するファイルは/kt/kt101/101.rtsに
- レプリケーションの相方のホストはkt102に
- レプリケーションの相方のポートは1975に
- 外部コマンド(ホットバックアップを採るコマンドとか)は/kt/bin/の下に置く
- memcachedプロトコルプラグインをロード
- memcachedプロトコルはポート11401で受ける
- データベースはオンメモリのStashDBで、バケット数は100万コ
な場合の起動はこんな感じです。詳しくはktserverのリファレンスを参照のこと。
ktserver \ -ls \ -port 1975 \ -tout 5 \ -th 8 \ -sid 101 \ -ulog /kt/kt101/ulog-101 \ -rts /kt/kt101/101.rts \ -mhost kt102 \ -mport 1975 \ -cmd /kt/bin \ -plsv /usr/local/app/kyototycoon/libexec/ktplugservmemc.so \ -plex 'port=11401#opts=f' \ :#bnum=1m \ ;
Kyoto Tycoonの運用TIPSなどなど
チャオ！みんな、Kyoto Tycoonライフをエンジョイしてるかい！？
今日はKTライフを満喫してるミーからの運用TIPSアンドソーオンをお届けするＹＯ！
kchashmgrとktremotemgrコマンドの補完
人間の脳活動のピークは22歳の今日このごろ、みなさんいかがおすごし？ もうね、ミーは全然コマンドオプションとか覚えられないからシェル(bash)で補完しまくってるＹＯ！
kchashmgrとktremotemgrだけだしオプション網羅してないし補完ルールもアレだけどオープン＆シェアなマインドとガッツで気になる人はfork & push！
Nagiosで死活監視
ナギオス！みんな使ってるよね？
ミーはcheck_httpでKTのHTTP RPCのechoにアクセスしてデッドオアアライブの監視してる！
define command {
command_name check_kyototycoon
command_line $USER1$/check_http -I $HOSTADDRESS$ -p $ARG1$ -u /rpc/echo
}
define service {
use critical-service
hostgroup_name kt
service_description Kyoto Tycoon server health check
check_command check_kyototycoon!1975
}
define hostgroup {
hostgroup_name kt
members kt101, kt102
}
define host {
use service-only
host_name kt101
address 10.19.75.1
}
define host {
use service-only
host_name kt102
address 10.19.75.2
}
レプリケーションの復旧方法
ちょっと再起動しちゃった
ディスクベースのDB使ってるときは再起動は問題ないんだけど、StashDBとかオンメモリDBを使ってるときに再起動するとデータ消えちゃうよね？でもイヤだよね？どう？
そんなときはバックグラウンドスナップショット(自動スナップショット)をとるようにしていればノープロブレムッ！
ktserverのオプションにスナショの出力先ディレクトリの指定(-bgs)と書き出しの間隔秒(-bgsi)を指定するダケ！
ktserverを(再)起動するときは起動したときと同じく-bgsと-bgsiをつけたままでスタート！ そすると初期データはスナショから読みこむし、レプリケーションのタイムスタンプを記録しているRTSファイルもそのままあるだろうから、落ちてる間にレプリケーションのペアになされたsetとかもレプられてデータ同期するよ！
これでカジュアルにリスターツできるね！
フルダンプから
KTはホットバックアップをとれるＹＯ！
レプってて片方のサーバのディスクが木っ端微塵にエクスプロードしても、デイリーでホットバックアップをとっていれば、このフルダンプから新しいレプペアをこさえられるのですぞ！
デイリーでとってなくても、片肺状態の生きているktserverからＤＯＫＩＤＯＫＩしながらその場でフルダンプとってもいいけどね！
だからktserverには↑のドキュメンツにあるように、-cmdとdbbackupスクリプトを置いておくのをドントフォーゲット！
エニウェイ、ホットバックアップをとるのはこんな感じで。
$ ktremotemgr sync -host kt101 -port 1975 -cmd dbbackup
ユーノー、ホットバックの指令はリモートからも発行できるぜ！
ホットバックアップが成功すると、「db.kch.01306840014856000000」というファイルがボーンする。ファイル名の末尾のメニーメニーなナンバーはベリーインポータントだから、デイリーでフルダンプとって別ホストにコピーして保存するときは、このファイル名のまま保存するようにな！
で、このフルダンプを使ってどうやってブランニューレプペアのデータセットを作り上げるかだが、こんな感じだ！
# cd /kt/kt101 # cp -p db.kch.01306840014856000000 db.kch # echo 01306840014856000000 > 101.rts # chown kt:kt 101.rts; chmod 644 101.rts
スナショファイルをktserverが期待するDBファイル名でcpするのはいいとして、ミソはスナショファイル名末尾のメニーなナンバーはスナショをとった時刻なので、それをレプリケーションを再開するタイムスタンプ(rts)としているところダ！rtsがないと、オールデータをレプするので時間とディスクI/Oがメニー発生するからアテンションプリーズな！(このへんの挙動と手順の妥当性は、リトルビッツ自信ないでげす…)
データセットができたらktserverをスターツすればおｋ。
あとあとバイザウェイ、ホットバックアップをとれるのはディスクベースのDBを使ってるときオンリーな！オンメモリDBのときは(DB＊ファイル＊が存在しないので)とれないぜ！
バット！ナウなKTなら、前述のバックグラウンドスナップショットにスナショ作成時のタイムスタンプもインクルードされているんで、オンメモリDBでも無駄なく復旧ができるぜ！詳しくは↓を読んでネ
kchファイルを消しちゃった！キャハ★
アルアル！アルよね！ちょっと指がスリップしちゃってKTのデータディレクトリ全部rm -frしちゃったりとか！
レプっていれば前述のとおり、ホットバックアップやバックグラウンドスナップショットから復旧できるのでノープロブレブ！
オールゾー！ レプってないとき！ フェイスがブルーになるネ！！
そんなときはちょっと強引だけどこんな方法で復元できるよ！(Linux限定)
まず、素数を数えて心を落ち着けよう（エラトステネス、サンクス！）。次に、ktserverのプロセスIDを調べよう。
プロセスIDが分かったら、おもむろにKTの実効ユーザかrootで:
# ls -l /proc/$KT_PID/fd/
ゼン、ktserverのプロセスがオープンしているファイルのファイル記述子(数字)とその実ファイルのパスがリストされるので、kchファイルを探してファイル記述子のナンバーをリメンバー！(たぶん 3)
そしたらば！ kchashmgrのcopyコマンドで、さっきのファイル記述子なファイルからデータを読んでダンプする！
# kchashmgr copy -onl /proc/$KT_PID/fd/3 dump.kch
オフコース、copyをとる前にはクライアント(アプリケーションサーバとか)を落したり、iptablesでKTへのリクエストをリジェクトしたりして、更新がかからないようにしたほうがモアベターだぜ！
