仮想化されているサーバに関してはスナップショットを取り、復帰させるなどの手が簡単だと思うけど、
物理サーバの停止／再起動前に気をつけることを自分の経験で書いておく。
＃きっちりしたシステムであれば、停止／起動に関するテストも実施しているだろうし、手順書やチェックリストもあるだろうが、
��残念ながらそうではないシステム向けの簡易なものと考えて頂きたい。
＃＃尚、計画停電も迫っており、拙速ながらエイやっと書いているので、
��＃もっと良い資料がどこかにあるはず。ありかを教えてください。リンクします。
��＃改善点があれば、教えてください。加筆／修正します。21:08書き始め。
＃＃朱記部分を追加 2011-03-14 22:45
＃＃青文字部分を若干加筆 2011-03-19 10:30
1.停止前に行うこと
基本は「正常動作状態とは、どのような状態であるかを認識し、記録しておく」こと。
＃本来なら、各サーバの設計書／設定書に「正常状態」の定義と、起動後の「確認項目」があるだろうけど、
��設計書が見当たらない事態もままある。そんな時には、まずは下記。
(1)停止可能なサービスは何かを明確にする。
そして、そのサービスを担当しているサーバを洗い出す。
- データバックアップサーバや日次でのバッチのためなど、
一定時刻／時間帯しか動かす必要がないサーバがもしあれば、止める対象としてリスト化する。 - 逆に、止められない／止めたくないサーバもリスト化する。
- この際、上記リストに従い電源供給系統の見直しを行うかどうかを考えておく。
（あまり欲張って、何もかもやろうとすると破綻するので、実力との見合いで実施を検討すべし） - サービス利用者への周知を行う。
若干でも時間幅の余裕を持って、サービス停止の連絡を行う。
また、その連絡の際には問い合せ先なども明示しておく。
(2)該当サーバ単体での状態の記録
- 動いているプロセス、インスタンスなどを記録する。
Unix系であれば、psコマンドに各種オプションを付けて出力しておく。
ps -axww > 正常時プロセス一覧.txt - mountしているファイルシステムを記録する。
mount > 正常時マウントファイルシステム一覧.txt - 各ファイルシステムの空き容量なども、同時に記録しておく。
df > 正常時ファイル使用量一覧.txt - 開いているportも記録する。
netstat -n > 正常時接続状態一覧.txt
��で良いかな？ - ネットワークの経路も記録する。
route -n > 正常時経路一覧.txt - runlevelも記録する。
runlevel > 正常時経路一覧.txt - 仮想サーバを動かしているなら、それらの状態も記録する。
- Active-Standbyなど、冗長構成になっている場合は、
どちらのサーバが運用系、どちらのサーバが待機系であるかをラベルなどで明示しておく。
(紙のラベルなど、アナログ的なものの方がこういう時は良かったりする） - もちろん、可能であればオフラインメディア（テープやDVD、外付けHDDなど)に
データバックアップを行っておく。
(3)他のサーバへのサービスを記録
- nfsやDNS、RDBMSなど、他のサーバへのサービスを提供していることが分かったら、どのサーバへ提供してるかを、記録。
��複数サーバで(2)の手順を行い、つきあわせれば分かるはず。 - 他のサーバへサービス提供をしている場合の、依存関係を整理する。
つまり、あるサーバの正常動作を行うのに前提となる別のサーバは何かを書き起こす。 - 上記をもとに、電源停止と電源投入の手順（サーバの順序）を書き起こす。
この際、一般には、停止順序と起動順序は全く逆になる。
��停止順がA→B→C→Dなら、起動はD→C→B→Aになるはず) - 再起動時に、他のサーバへのサービスを行っているプロセス／インスタンスなど
確認すべきものを書き起こす。出来るだけチェックリスト化する。
��この場合のチェックリストとは、計画書兼報告書となるようなもの...と言って分かるかなぁ) - 各種資料を、なるべく紙で出力しておくこと。
チェックリストや手順書はもちろん、参照すべき資料を探しておく。
電子データは、参照できなくなることが多い。Ecoではないだろうけど、必要。
2.停止作業
基本は「計画していない思いつき作業は絶対に行わない」
「計画していない事象が発生したら、深呼吸して、連絡取れる有識者に相談して対応を決める」です。
(1)手順に従い、粛々と停止する。
- サービス利用側サーバから正常にシャットダウンさせて行く。
- 前者サーバが停止してることを確認し、サービス提供側サーバをシャットダウンさせる。
一般に、DBサーバやDNSサーバなどを最後に落とすと思われる。
(2)停止状態の確認
- 正常に停止できていることの確認。
- 停電時に備えた照明などの準備。
- 再起動作業時に必要な道具類の準備。
普段必要ないディスプレイやキーボード、特殊なコンソールケーブルなど、取り揃えておく。
３.停止中に行うこと
これも基本は「計画していない思いつき作業は絶対に行わない」です。
(1)サーバ停止時にしか出来ないことを実施
- 掃除する
充電式掃除機などでのゴミ取りや、FAN／フィルタの掃除や交換など。
また、電源コンセントの差し込み口周辺のホコリなどは吸い取っておく。
さらに可能なら、未使用の差し込み口には、養生用テープ(粘着力が弱めでベタつきにくい）を貼り、予期せぬ電源ショートなどを未然に防止する。 - 配線の張り替えや部品交換などを行う
UPSとサーバの組み合わせの変更や絡み合ったネットワークケーブルの張り直しなど。
尚、一度に全部のケーブルを外すと大変なことになるので、計画していないことはやらないこと。
場合によっては、HDDなど寿命部品の交換も行えるかもしれない。
��これも、事前に計画が必須ですけど） - 滅多に無いと思いますが、復電時の電圧変動などで
機器にダメージが発生しないように、ブレーカや配電盤、元となっているコンセントなどは
抜いておくと良いかも。
(2)再起動に向けたリソースの確保
- まずは、再起動時に必要な人的リソースの確保
誰でも出来る訳ではない。連絡がつかないかもしれない。交通手段が確保できないかもしれない。
事前に、誰にいつ来てもらうかを計画する。また、予備の人も含めて計画しておく。
さらに、待機してもらう人／当日連絡を取る必要がある人にその旨お願いしておく。
��大災害の際に、連絡を取ることが困難な場合は、あらかじめ来てもらうしか無いんだけど） - 再起動時の各担当者／関係者にて、机上リハーサルを行う。
チェックリスト／手順書に、各担当者名を書いて、時系列に従い、誰が何をやるか（実施者）を確認する。
どのような道具を使うかも、道具の確認も含めて行う。
��ケーブル長が短くて届かないなど、しょぼい事態もあり得るので、細かく見てね） - 上記の机上リハーサル時に、複数名で確認すべきチェックポイントが何かを決める。
そのチェックポイントでの実施者に加えて、確認者を明確にする。 - 正常状態の記録をもとに、チェックポイントの抜け漏れを見直す。
- 直前確認のための一覧表を作成する。
- 寝る。または充分休養を取る。
来るべき大作業に備えて、気力／体力／知力のリフレッシュをはかる。
大事なリソースです＞体力。
４.再起動時に行うこと
これまた、基本は「計画していない思いつき作業は絶対に行わない」です。
(1)必要なリソースがそろっていることの直前確認
- 居るべき人が居るか？道具はそろっているか？
事前に作成した一覧表をもとに確認。 - 計画書／チェックリストはあるか？
(2)安定した電源が来ていることの確認
- 再停電の可能性が無いか、発表されている停電予定などとつきあわせて確認。
- 計画が変更になっていないか、一時ソースや信頼できる情報源などで確認する。
- テスターなどで、電源電圧を確認する。
(停電／復電時に限らず、電源電圧の確認は本当は必要。安価なやつでも買っておけ）
ブレーカや配電盤で電源を落としている場合は、そこで測定するべし。
測定の際は、出来れば電工用のゴム手袋などを着用し、感電には充分注意すべし。
(3)手順書に従ったサーバの起動と確認
- 手順に従い、一度に全部のサーバの電源を入れないこと。
突入電流を避けることと、サーバ間の依存関係を満たすように、順に入れること。
尚、電源投入順序だけ満たしてもダメで、依存するプロセス／サービス／インスタンスの
順序性を満たすことが必要。 - 内蔵のRTC(時計)用の電池が切れていたりすると、
時刻が大きくずれることがあります。時刻の確認を行いましょう。ずれていたら設定しましょう。
(ネットワーク上のntpサーバが落ちているかもしれません。まずは自力で正しく動くように設定を)
(4)サービスの確認
- サーバルーム内からの動作確認はもちろん、外部ネットワークからの確認も行う。
- logやプロセスも一定時間確認を継続する。可能なら、エンドユーザにも確認してもらう。
5.正常動作確認後に行うこと
ここでの基本は「如何に有益な教訓を記録するか」です。
本当は、じっくり時間をかけて行うべき話が多いのでしょうけど、
頻繁に計画停電があるのなら、手順／戦術ベースの教訓は迅速に整理し、反映すべき。
(1)反省事項の整理
- 予定外の事象が発生した場合には、何が起きたのか、なぜ起きたのか、次にどうすべきかを議論する。
この際、「誰が悪い」というような犯人探しを行うのではなく、「何が悪い」「次に同じことをするならどうする」という行動の改善観点で行う。 - 人間なのでミスもある。
ミスを防ぐための「しつけ」と「しかけ」は何が必要なのかを議論したい。
＃将来に向けての成長を促す「しつけ（教育）」も必要なのだが、
��直近の次回作業に向けては、失敗事例の関係者による共有と、
��それをふまえた議論による再発防止の「しかけ(ツールやワークシート、体制見直しなど)」検討をサクサク行う。
(2)手順書や道具へのフィードバック
- 反省事項の整理をもとに、手順書／チェックリスト／道具見直しを行う。
(3)飲む
- 安定稼働が確認できて、一息ついたら、ビール一杯ぐらい飲んでもバチは当たらんだろう。
停電でぬるくなったビールもまた一興。
��その昔、フィリピンに行った時は、ぬるいビールに氷を浮かべて飲みましたが、
��なかなか乙なものだった。
まずは、ここでいったんリリース。気がつくと２時間以上かかってた。
途中、他のこともしながらとはいえ、もう少し筆が速いと良いなぁ。自戒。23:25
0 件のコメント:
コメントを投稿