ご利用は計画的に

このブログで折に触れ言ってきたことだが、システムは「処理が正常に行えるように」ではなく「 壊れたときにMTTRをいかに短くするか 」を考えて設計する必要がある。
それを考えずに作るシステムは社内外のユーザに胸を張って提供して良いシステムではない。

また「冗長化」＝「復元可能」と思っている方も多い。
全く間違いではないのだが、冗長化したものの一部が障害を起こしたときに「どのように復元すれば復元可能か」を理解していないと当然、戻るものも戻らない。

その間違いを比較的起こしやすいのがRAID1/RAID5による冗長化だ。

RAID1は言わずと知れたミラーのことだが、
HDD２本を使って同じデータを書き込むのだから、物理的障害の起こる可能性は単純計算で２倍になるはずである。
ただ、２本が同時に壊れる可能性はかなり低いので、物理的障害に対するHDDの復旧可能性が高いというだけである。

RAID5に至っては当然物理的障害可能性はHDDの本数分の倍数になる。
その上、何も知らないシステム管理者はRAID5構成のマシンがHDD障害で停止した際に、すぐにマシンを立ち上げようとするがこれは大変危険である。
RAID5のHDD障害によりマシンが停止するということは障害HDDは２本以上である可能性が高い。
この場合は、どの順序でHDDが停止したかを確定することが先になります。
これを確定せず、万が一、最初に停止したHDDを除去せずに再起動し、このHDDが認識されると、このHDDが停止した日以降のデータは初期化もしくは破壊される可能性が非常に高くなりますので、、まかり間違っても安易にマシンの電源を入れなおすのはやめましょう。

また、確信が持てない上でのRAIDパラメータの再設定、OS再インストールも大変危険ですし、何より間違ってはいけないのは、いかにRAIDといえども論理的異常によるデータ上書きによる障害はどうしようもないです。

なので、RAIDを採用する際は、

1. 異常発生時のログが管理者に通知できるようにする
2. HDDのスペアは常時準備しておく
3. 障害時のオペレーションを確認し、手順化する（停止・交換手順、ログファイルの保管場所、再起動手順など）

を考えた上で適切なバックアップを取得する計画も合わせて立てる必要があります。
（バックアップに関しては当然リストア手順も明確にする必要があります）

予算があれば何処まででも頑強にすることはできますが、最低限上記の項目は本番システムには必要な準備ですので、上司と喧嘩してでも整えることが自分の身を守ることになります。
まぁ、言っても分からない上司というものは往々にして昨日の太郎が言ったとおり、「なってみないと分からない」方が多いものですが。。。

（朔如）