障害復旧時間を短くするために
最近では、物理サーバを削減し、サーバの仮想化やクラウドへの移行が盛んに行われるようになっています。特に東日本大震災の影響で、災害時に業務が停止してしまわないよう事業継続性（ディザスタリカバリ*1）を重要視する動きもあるのではないでしょうか？日頃動かしているメインのサーバから離れたところに、バックアップサーバを設置しておいたり、非常時に代替稼動できるサーバを準備したりしておくと、復旧に必要な時間を短縮することができます。今回はそんなバックアップや代替運転に使える安価なサーバを作ってみました。（他に開発用・検証用としても使えます）
*1ディザスタリカバリとは？
災害などによる被害からの回復措置、あるいは被害を最小限の抑えるための予防措置のこと。主にコンピュータシステムやネットワークなどIT関連で用いられる
（Wikipediaより）
ベンダー製のサーバと同じモノをつくれないか…
組織の情報セキュリティ基準やIT機器の調達要件として、一定水準の保守サポートが保証されていることや、ハードウェアが大手ベンダー製であることが定めれていることもしばしばあると思います。バックアップ機や開発機全てを同じベンダーの製品で揃えることができれば、保守性や移植性（移し替えやすさ）の面から見ても最も望ましいと言えるでしょう。しかし様々な制約下では必ずしもそれを達成できないこともありえます。
メインのサーバとの保守性や移植性を落とすことなくほぼ同一のハードウェアを調達できれば、非常用に安定なシステムを構築できます。今回は構築事例として、HP ProLiant ML310e Gen8サーバー シリーズとの互換性を持ったカスタムハードウェアをご紹介します。
目指すもの
- ベンダー製サーバとのアーキテクチャ互換性があること
- バックアップや開発用に使える最低限のスペックに抑え、低価格を実現すること
- ラックマウント型、タワー型どちらでも対応できること
- 緊急時にベンダーの復旧時間に依存しないシステムにすること
今回使ったもの
実際にHP ProLiant ML310e Gen8サーバー シリーズとの互換性を想定し、以下の構成でセットアップしました。
仕組みとして必要な要件とは
理想としては、メインのサーバが何らかの障害でダウンしてしまった場合に、ケーブルを差し替えただけで代替サービスがスタートすることです。そのために、コンピュータのアーキテクチャを揃えました。Intel C204チップサーバボードを採用し、ベンダー製ハードウェアとの互換性を確保しました。
参考として、サーバの障害とその対策について、以下の３つを総合して復旧に要する時間を想定してみました。
- ネットワークの状態
- ハードウェア／ソフトウェアの状態
- データの状態
バックアップ機を用意しておくと、いざという時に復旧時間を短くできると考えています。
サーバの障害とその対策（PDF）
ラックマウント型でもOK
上の例では一般的なデスクトップ機と同じタワー型の筐体を採用していますが、下の写真のように中身は全く同じ構成で、ラックマウント型の筐体で作ることもできます。
バックアップの方法
Linuxのバックアップツールとしては、rsyncが有名ですが、今回はrdiff-backupを紹介します。
rdiff-backupとは？
履歴機能を備えたバックアップツールです。バックアップは元データの完全な複製のため、最新のバックアップからデータを復元するにはコピーするだけでよく、特殊なコマンドは必要ありません。さらに履歴機能によって、過去に失われてしまったデータ（削除されたデータや変更が加えられたデータ）を復元することもできます。
Linux システムの管理を行なう場合では、バックアップの他に、ログのローテートなど定期的に自動実行したいジョブが数多くあります。通常はcron というスクリプトを自動実行するためのデーモンプロセスを使うことが多いです。バックアップは、システムへの負荷が大きいため、ユーザからのアクセスが少ない深夜や早朝に行なわれます。
ここでは日次で行うバックアップを想定してみましょう。
【バックアップ方針】
- バックアップは毎日定時に実行する
- バックアップスクリプトが実行されると、差分データのみがローカルディスクおよびバックアップ先に転送される
- バックアップは/var/www以下に対して実行する
- バックアップに失敗すると管理者（XXXXX@XXXXX.co.jp）宛に警告メールが送信される。
以下はサンプルスクリプトです（仮にbackup.shとします）。スクリプトはPATHが通っている/usr/local/bin/などに配置することが多いです。
#!/bin/sh
# rdiffバックアップを使った単純なスクリプト例 (Centos 5.xで動作確認済）
#
# 本スクリプトを使用したことにより生じたいかなる損害も当方は一切責任を持ちません。
# 自己責任の上での利用をお願いします。
# アミュレット株式会社 2013/7
#
## script start ##
# 対象ホスト名
host="XXXX.XXXXX.XXXXX.co.jp"
# 障害発生時のメール送信先
mailto="XXXXX.XXXXX@XXXXX.co.jp"
# ログの保存先
logpath=/var/log/backup.log
# 一時的にログを保存するファイル
temp=/tmp/rdiff-backup.temp1
# 運用中の機器のIPアドレスと取得したいディレクトリ
from1="XXX.XXX.XXX.::/var/www"
# バックアップ先のディレクトリ
to1="/backup/var/www"
# バックアップから除外したいディレクトリ
exclude1=""
#exclude1="--exclude /var/www/
if
rdiff-backup --force --exclude $exclude1 $from1 $to1 >> $temp
then
echo "`date -I` `date +%T` rdiff-backup succeeded From $from1 To $to1 " >> $logpath
else
echo -e "`LANG=C date` rdiff-backup failed From $from1 To $to1 `cat $ temp`" | \
mail -s "rdiff-backup failed on $host ." $mailto
echo -e "`date -I` `date +%T` rdiff-backup failed From $from1 To $to1 `cat $temp`" >> $logpath
fi
## script end ##
これに実行権限を付与して、cronで毎日午前２時半に実行するようにします。
# chmod +x /usr/local/bin/backup.sh
# crontab -e
30 02 * * * /usr/local/bin/backup.sh
バックアップの準備は以上で完了です。
【リカバリについて】
リカバリコマンドの実行例は以下の通りです。
ex. バックアップサーバから今まで動かしていたサーバの/var/wwwの10日前の状態を、/tmp以下に復元
# rdiff-backup –restore-as-of 10D バックアップサーバ(IP or FQDN)::/backup/var/www /tmp/var/www
ここで、–resotre-as-of（短縮は-r）オプションはrdiff-backup コマンドにバックアップではなく復元することを指定しています。時間の指定は、10D（10 日）の他にも2006-07-28（2006年7 月28 日）といった指定が可能です。なお、履歴機能により復元可能なデータの保存期間は1 年間となっています。
システムのメリット
停止が許されないサーバは日頃バックアップを取って置くと、バックアップや代替機がない場合に比べて、障害時の復旧時間を短くすることができます。たとえ低速でも、業務を停止することなく同じシステムが使えるという状況は非常に重要なことだと思います。
社内で使う業務システムのほか、クラウドのバックアップとしても有効です。
弊社では特に３台構成（稼動系、待機系、開発/テスト系）をオススメしています。
まとめ
今回作ったシステムなら、以下の３つを実現できます！
①信頼性の向上：メインのサーバがダウンしてしまった場合でも、バックアップ機から復旧することができます。
②障害時の復旧時間の短縮：メインのサーバがダウンしてしまった場合に、復旧にかかる時間を短縮することができます。
③低価格：メーカー製のサーバと比べて、低予算で、より障害に強いシステムにすることができます。
弊社ではマニュアルの作成等も承っております。業務システムやクラウドのバックアップをお考えの際はお気軽にお問い合わせ下さい。
solutions@amulet.co.jp
来週7/16（火）〜8/2（金）まで、この記事でご紹介したハードウェアを店頭で展示します。どうぞお気軽にお越しください。