serverサーバ設計
パワーをメテオに
→だから二重化します
マスター
更新系クエリーがきたらバイナリログに書く
スレーブ
I/Oスレッド
マスターに接続してデータを貰う
貰ったデータを自身のログ(リレーログ)に書く
SQLスレッド
リレーログからクエリを読み取って実行
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: localhost
Master_User: root
Master_Port: 3306
Connect_Retry: 3
Master_Log_File: gbichot-bin.005 ← マスターのバイナリログファイル名
Read_Master_Log_Pos: 79 ← ↑の、どの位置か？
Relay_Log_File: gbichot-relay-bin.005 ←自分のリレーログ
Relay_Log_Pos: 548 ↑の。どの位置か？
Relay_Master_Log_File: gbichot-bin.005
Slave_IO_Running: Yes ← I/Oスレッドの動作状況
Slave_SQL_Running: Yes ← SQLスレッドの動作状況
Replicate_Do_DB:
Replicate_Ignore_DB:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 79
Relay_Log_Space: 552
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 8
・機能ごとの分散
(サービスA専用サーバ サービスB専用サーバ)
・テーブルのパーテション
(会員1～1000はサーバA1001～2000はサーバB)
・バックアップバッテリつきRAIDカード
(syncの負荷対策)
・キューとバッチ
(非同期処理、裏方でこそこそ)
・セッションをデータベース(key value store)に書く
・ロードバランサがヘッダで切り替え
・URLパラメータ
誰か教えて!!
非常に遅くなる。
ディスクに書きまくり、読みまくり。
load average 急上昇
→スラッシング
ようするに超デカイ
VPN(ベストチョイス!!)
・htdocs以下
普通の所はソース管理にあるから
サーバでは何もすることなし
・データべース
ものによっては毎日フルバックアップ取れるよね。
画像を入れたりしていなければ、そんなにでかくならん
・システムログ
httpd.log / syslog / message(めっさげ)
標準の logrotate とかで移動する(結構癖がある)
・アプリケーションログ
上に同じ？ アプリでローテートしてもいいかも。
バグ/トラブル対処には絶対必要になる。
・ユーザデータ(ユーザーがアップした画像とか)
差分バックアップ？
理由:
バックアップスクリプトの集中管理
サーバが複数台が同時にバックアップしないように
→お客様がテストしてNGだったのが障害/バグとなる。
バグをサポートに伝えるお客様が少ないように、
サーバがダウンしていて教えてくれるお客様は少ない。
ビジネス機会の損失
・install時に環境をスキャンして
勝手にプラグインを追加
・何もしないでそこそこの環境が整う。
・追加プラグインでさらに便利
・複数台構成(親子関係)
・異常時のメール送信
サーバーによって用途が
違うので何とも言えない
運営をしながら、
監視の増減を変化させていく
ものらしいよ。
日頃の数字がわかっていないと、
監視数字の増減も決めれないし、
サーバの増設計画も立てられない
グラフぐらい欲しいよね
障害発生件数
障害対応時間
サービスのダウンタイム
処理時間
(apacheのCUSTOMLOG %T or %D)
一度動いているサーバを
変更するのは非常に大変。
ソフトウェアではなくハードウェアだし。
止まるといろんな人に怒られるし。
→動かす前に適切な設計を！
・バックアップはちゃんととりましょう。
・ログはちゃんとローテートさせましょう。
・監視はちゃんとしましょう。
・障害対処はフローを決めて適切にやりましょう。
・社内SLAを結んで数値化するといいんぢゃないの？
ひとりで無理なら力をあわせて
耐障害性
構築するとき注意すること
サーバ設計
・可用性
1台壊れても大丈夫。
・大切なデータは二重化
タスク
・耐障害性
by rti
みんなで手分けして分散
・早く増設できるように
サーバA
サーバB
・管理を楽できるように
複数台マシンで運用する意義
可用性
ひとりが倒れてももう一人で支える
一台なら死んだら終わり
もし、VPNでなかったら
VPNのさらにいいところ
データセンターへのアクセス(VPN)
まず玄関サーバにアクセス
えんいー\e
サーバが非グローバルIPで運用できる。
自社から全サーバにアクセス可能になる。
VPNさいこー
telnet(超危険)
ftp(危険)
samba(危険)
ssh
(プロトコルは安全だけど、攻撃の可能性大)
踏み台にしてアクセス
玄関サーバ(201.x.x.x グローバルIP)
|
|
|
|--------ノード1(192.168.x.x)
|--------ノード2(192.168.x.x)
玄関サーバ(201.x.x.x グローバルIP)
|
|--------ノード1(192.168.x.x)
|--------ノード2(192.168.x.x)
とってもめんどくさい
VPNならローカルIPに直アクセス可能
ただし、レンジに注意してね
ロードバランサ(LB)
L2/L3って何？
えーと、なんかこんなのあったでしょ
web 80/443
上位層の役割
TCP/IP
OSI参照モデル
アクセスをサーバに振り分ける
必要なポートのみ転送する
第7層: アプリケーション層
第4層: アプリケーション
例: HTTP・FTP・DNS
第6層: プレゼンテーション層
第5層: セッション層
外部からの侵入から守る
ロードバランサ
第4層: トランスポート層
第3層: トランスポート
例: TCP・UDP
・外部からのアクセスを
適切なサーバに振り分ける(LB)
・外部からの攻撃を防ぐ(FW)
・その他機器 (L2スイッチ / L3スイッチ)
第3層: ネットワーク層
第2層: インターネット
例: IP・ICMP・ARP・RARP
サーバC
サーバB
サーバA
第1層: ネットワークインタフェース
例: Ethernet・PPP
ファイアーウォール(FW)
第2層: データリンク層
第1層: 物理層
第0層: ハードウェア
例: UTP ケーブル・RC-232C
http://x68000.q-e-d.net/~68user/net/osi7.htmlより
データストア
readを増やすのは簡単、
writeを増やすのはムズイ。
スレーブノード
セッション(COOKIE)
ノード自体のデプロイ
64bitだと
httpdといっても沢山あるよね
1エクサバイト＝
100万テラバイト =
1兆メガバイト
スレーブ
メモリの上限と64bit
phpとfork
ログの同期
一般的にreadはwriteより多い。
今のが主要なサーバ構成
writeをどうにかするために
非常に遅くなるとどうなるか
サーバ10台増やすとしたらどうする？
php は fork モデル？
64bitは、普通に8Gとかさせるよ。
コピー
rsync(lsyncd)
scp
tar
dd
共有
nfs
samba
その他...
SWAP-in SWAP-out が
繰り返されるとシステムはどうなるか。
スレーブから書き込み処理を行う
updateクエリのみ
落ちたらサービスが停止する
必ず冗長化
不必要なライトはさけましょう。
コンテンツのデプロイ(複製)
よくある対策
2回目が同じサーバとは限らない
HTTPD
スレーブデータベース
(SQL selectクエリーのみ)
→readの処理
WebサービスはSWAPしたら負け。
こんなプログラムが書かれていると
スレッドでは動作しないよね。
・HTTPD
リクエストを受ける。
PHP等を実行し、プログラムを処理する。
貧乏は辛い
メモリの上限より、
物理的なメモリスロットの上限があるよね。
金を湯水のように使えるエンタープライズだと、
メモリ100Gとかさせるらしいけど。
ハンコみたいに沢山増設
大抵のアプリは64bit対応しているし。
apache
1.0系 fork
2.0系 fork / thread /event
32ビットメモリ3G～4Gまで
64ビット16E(エクサ)バイトまで
ちょっと横道にそれて、HTTPDについて
これをフロントオフィスとすれば、
ここから裏方のバックオフィスの紹介
セッション(COOKIE)
沢山のリクエストをSWAPしないで動かすか。
dd
tar
ネットワークインストール
その他
サービスが止まる >_<
特に理由がない限り
サーバは64bitOSにするべき。
apache
みんな大好き高機能なhttpd
lighttpd
機能はapacheに劣るが超高速なhttpd
最近人気
Nginx
軽いらいけどチューニングが必要
tux
linux kernel組み込み
IIS
windows 結構早いよ。
一時期の悪評が今でも。。。
某webサーバ
(ry
phpを間違えて threadで動かして半年ぐらいたったけど何もおきなかった事例を知ってる。
もしかしたら、古いプラグインだけが forkぢゃないとダメとか？
適切なパラメータでリコンパイルすればいいとか？
よくわかんない、
主要なサーバの役割まとめ
エロゲも動くよ。
メモリが少なくなると
どうなるか。
→SWAPする
消費メモリが
少ないと何が嬉しいの？
ロードバランサ
php -> apache
画像 -> lighttpd
・スレーブデータベース
selectクエリを実行し、データをHTTPDに返す
複製が比較的容易
複数あることの問題点
DRBD / HA
レプリケーション / HA
http://wiki.mm2d.net/win64/index.php?%A5%B2%A1%BC%A5%E0%A1%A6%A5%A8%A5%ED%A5%B2%C6%B0%BA%EE%CA%F3%B9%F0
コンテンツのデプロイ(複製)
int test(int a)
{
static int abc; //これ
abc = abc + a ;
return abc;
}
swapしたら負けかなと思ってる。
元ニート
スレッドの方が消費メモリが少ない。
サーバC
サーバB
サーバA
利点
要するに住み分け。
判子のように増やすには？
スレーブデータベースを
どこにおくか。
SQL select専用。
データをたくさんやり取りする。
loopback(127.0.0.1)のメリット
ステートを持たないこと。
slave
web
超絶大規模でなく、
お金がないなら、
webと同居でも
いいんぢゃない？
このサーバにしかない
データを作ってはいけない。
ふつーのwebサーバの
CPUは遊んでいるため。
db
増設容易性。
判子でサービスが増える。
共有データは、
データストアへ
データストア
監視と同期
HeartBeat(HA)
大切です
HeartBeat(HA)
データベース
対応状況
master 運用者だったら一度は見たことある
show slave status￥G
共有IP
共有IPは二人に一つ
共有IP
落ちたり、壊れたりしたらサービスが停止します
mysqlのレプリケーションの概要
スレーブ
ユーザー情報
マスター
昇格
mysqlのレプリケーションは
「非同期」である。
salve
master
アプリケーション
SQLスレッド
スレーブ
I/Oスレッド
マスター
サービス情報
データが失われたらビジネスが止まりますw
マスター
これを切り替えるコマンドが、
CHANG MASTER TO.
・監視
Heartbeat
・データ同期
DRBD
レプリケーション
rsync(データベース系は無理)
nfs(データベース系は無理)
参照系クエリ
更新系クエリ
update
ログに書く
スターリングラードかよ
データ頂戴
mysql
標準でサポート
postgresql
次期 8.5 9 から標準サポート
現在は外部ソフトで対応
リ
レ
ー
ロ
グ
バ
イ
ナ
リ
ロ
グ
→((ログ以外でwriteが発生情報するもの) )
ヘルスチェック
salve
mysqlだと複数代のレプリケーションでのスレーブ昇格は至難の業
マスター
スレーブ
同期
間違ったマシンを昇格させると、
最悪データの歯抜けや、
レプリケーションの停止を招く。
ほれよ
master
続きは映画で(嘘
詳しくは別の機会にでも話すよ。
新しいデータある？
もらった
から書く
salve
ちょっと横道にそれてレプリケーション
salve
step1
step3
salve
master
データベース更新
step2
salve
誰を昇格させるか、、、
salve
step3
管理サーバ
管理サーバにも
レプリケーションを
外部からアクセスできない
その他雑務
監視サーバ
grepもここでやれば
本番サーバに負荷かからない
スレーブ
ログ保存と監視、
内部向けサービスを運営する(+雑務)
まとめ
VPNを経由しないとアクセスできない。
デプロイの指示とか
マスター、スレーブノードから
ログをここに集める
マスター
データベース
スレーブ
内部向けサービスの運営に適している。
全サーバの動作を監視
問題があれば通知もここでやる
グラフの閲覧
cronの指示とか
管理サーバ
ここにも引く
管理画面とか
一台でいいから、
いると非常に便利。
ログ集計とgrep
バックアップ、
ログ保存等の具体的な処理を説明します。
重たい集計クエリーを流しても平気
このサーバでデータベースdumpできる
管理サーバにも
レプリケーションするメリット
・上位層
入れ口
・データセンターへのアクセス
VPNがあると便利だよ。
・管理ノード
色々やってくれる便利なヤツ
次は、
バックアップの目的
バックアップソフト
バックアップ対象1
よくある間違い
フルバックアップと差分
バックアップ対象2
バックアップ
容量が少なければフルバックアップ。
多ければ差分/増分バックアップかなぁ
・バックアップなんて不要(男の生き様)
・実は同一ディスクにバックアップ
・復元できないバックアップ
tar
dd
rsync
DAR(この前知ったw)
Amanda(この前知ったw)
・障害対応
機械が壊れた!
・オペミス対応
間違ってファイル消しちゃった >_<
・サポート対応
過去のログが見たい
リストアするまでがバックアップ(遠足)
次は
ログについてです。
実はあんまり詳しくないw
ログローテート
ログはpushかpullか
俺が思うログ保存ポリシー
なぜhtdocsの下にログを吐くのか
ログ
予め置き場を決めておく
放置しておくとこんなことに
→情報漏えいにつながる
・ログは障害対応に必須
保存が必要
ノードから scp して管理サーバへpush
・毎日ログを管理ノードにコピーする
こんな自由すぎるhtdocsは嫌だ
htdocsの下に
ログやテンポファイルつくり人っているよね
アプリのフォルダの下に吐いた方が
アプリ単体でまとまっているから
・各ノードには、31日分のログを入れる。
or
・放置しているとどんどん増える
適切なローテートが必要
/htdocs/myapp/log/
何でもないような配慮が
必要になってくると思われ
/var/applog/アプリ1log/
他にログを吐くとこがないから
次は監視についてです。
・名前は↓こんな感じで
YYYYMMDD_SERVERNAME_ログファイル.tar.gz
管理サーバからノードに取りに行くpull
/htdocs/test/user/log/....
/var/applog/アプリ2log/
っていうかサーバのディレクトリ構造が良く解らん
↑コッチのほうがいいらしい。
ユーザーのログ領域
・保存用のHDやDVD、テープに入れて倉庫へ
/htdocs/myapp2/writable/log/...
/var/applog/アプリ3log/
ソフトウェアは
三回テストされる
サーバも
3回監視される。
電話通知
適当にアクセスしたサーバが
サーバがエラーになっていたらどうしますか？
muninここがだめだよmunin
監視ツールあれこれ
muninいいよmunin
報告してくれたお客様に感謝
と、いうわけで
アラートだけでいいの？
個人的にはmuninがおすすめw
・開発者
・テスター
・お客様
何もせずに立ち去る。
・監視ソフト
・社内スタッフ(偶然w)
・お客様
ダメ
メールまたは電話で通知
↓
対処
↓
復旧
↓
復旧アナウンス
↓
障害日誌をつける
(BTSとかがおすすめ)
↓
おしまい
linuxだと ATコマンド と
シェルスクで wav を電話送信できるらしいよ
監視
基本は監視ソフトの
ディフォルトを推奨
インストールするだけでこんなグラフが出ます。
・監視しない時間帯を設定出来ない
・複数台構成だと異常の瞬間の
ps/netstat 等を取るのが難しい
・死活監視プラグインがディフォルトではない
数値化したデータが
次の社内SLAにつながります。
そして、お客様から問題を指摘されるまで気がつかなかった体制を恥じるべき。
自動監視
mrtg(元祖であり設定地獄)
munin(perl)
nagios(よく知らないw)
cacti(php/mysql)
OpenManage(有償)
http://www.experts-exchange.com/Hardware/Networking_Hardware/Modems/Q_20930611.html
死活監視プラグイン作った
監視のしきい値は？
http://d.hatena.ne.jp/rti7743/20090827
障害発生時のフロー
http://muninexchange.projects.linpro.no/
フロー
翌月or翌年目標
反省
たとえば、ある月
ここまでのまとめ
社内SLAの主な項目
これを繰り返せば、
障害が限りなく少なくなるはず(多分)
現実にあった目標を立てること
社内SLA
障害発生件数9件/月 -1件
障害対応時間8時間/月 -2時間
サービスのダウンタイム50分/月 10分
処理時間5秒以上の処理が70件 -30件
目標
↓
コミット
達成できた場合:
ハードを上げる/給与もあがてね!
達成出来ない場合:
反省して改善する
↓
評価
障害発生件数10件/月
障害対応時間10時間/月
サービスのダウンタイム1時間/月
処理時間5秒以上の処理が100件
何が悪かったのか
一番多いトラブルは何か？
(障害日誌を見る)
問題点:
すごく保守的なになりそうな気もする。
大切なこと
なんというボロボロ。。。
次は失敗しません、ご期待下さい。
最後に総括