Linuxサーバ運用マニュアル
前回までで，ゲートウェイとサーバによる2台構成のシステムを構築しました。しかし，実際にこれを運用していくとなると，障害は避けて通れないものです。そこで，今回は実際に障害が発生したときにサービス停止やデータ消失の期間をいかにして短縮するかについて説明していきたいと思います。
障害とは，サーバが何らかの原因で機能を停止し，サービスの停止をしている状態のことを指します。その原因は，ハードウェアの故障，ソフトウェアのバグ，クラッキングなど外部からの攻撃，内部の人為的ミスなどさまざまです。
ハードウェアの故障はいつか必ず起こり，新たなセキュリティ・ホールはいつか必ず発見されます。人為的ミスは，ゼロに近づけることはできても完全にゼロにはならないでしょう。サーバを運用していくうえで大切なことは，障害は必ず起こるものという認識を持つことと，障害への対策を立てておくことです。
たとえば，1台のサーバで運用している場合に障害が発生したとします。すると，障害発生から発見までの時間，予備マシン用意の時間，システムのインストールの時間という具合に，すべてをあわせると約1〜3日の間サービスは停止することも十分予測されます。さらにデータの消失期間は，最後にバックアップをとったところまでになります。
障害時の対策として重要なのは，サービス停止やデータ消失の期間をいかに短くするかということです。これをふまえて，障害が発生した場合にはまず縮退環境で運用を継続できるようにします。縮退環境とは，サービスを停止しないで，本来の運用時より少ない機器構成で，性能や機能を落として運用する環境のことです。そのうえで，障害により機能停止した機器の復旧にあたります。
また，サービスを継続させるには「それぞれのクライアントが設定を変更することなくサービスを利用できる」ということが必要です。なぜなら，障害は突然に起こるもので，クライアントに設定変更の事前連絡は不可能だからです。よって，通常時と同様にアクセスできるような設定を考えたものを，縮退環境の設定として用意することが必要になります。
以下にいろいろな障害対策の例を紹介します。サーバは，ファイアウォールを構築しているゲートウェイ（GW），WWWサーバ，メールサーバなどの各種サービスを提供しているサーバ（SV），予備機としてバックアップなどを実施しているバックアップサーバ（BK）に分けて説明します。図の中の白色のマシンは稼動中のマシン，グレーのマシンは予備マシン，×印のマシンは障害により機能停止したマシンです。
障害の範囲としては「単体のマシンが障害により機能停止する」ということを想定しています。もちろん，複数台のマシンが同時に機能停止する場合も，その場合の対策もないわけではありません。しかし，その事態が起こる確率と，対策にかかるコストとを考えると，必要ないでしょう。
通常時はゲートウェイとサーバは独立して稼動し，障害発生時は1台でゲートウェイとサーバの両方を兼ねる縮退環境となる構成です。
まず，両方のマシンにゲートウェイ用設定，サーバ用設定，ゲートウェイ兼サーバの障害時用設定の3つをインストールしておきます。通常時は，ゲートウェイはゲートウェイ用設定のみをアクティブに，サーバはサーバ用設定のみをアクティブにして，他の2つの設定はスリープ状態にしておきます。また，ゲートウェイとサーバの間で，データの2重化を行ないます。
障害発生時には，稼動しているほうのマシンの障害時用設定をアクティブにし，ネットワークの物理的接続を切り替えて縮退環境で運用します。
縮退環境ではサーバがインターネットに直接接続されるため，セキュリティ的に甘くなりますが，サービス停止期間は1台運用の時に比べてはるかに短くなります。
設定切り替え用のシェル・スクリプトを組んでおけば，設定切り替えのシェル・スクリプト実行とネットワークの物理的接続の切り替え，マシンの再起動の3つを行なうだけで通常時同様のサービスが提供できます。
2台運用の場合に加え，バックアップサーバが加わります。
通常時は，ゲートウェイとサーバは2台運用の場合と同じく独立して稼動します。バックアップサーバは，他の2台から定期的にデータと設定ファイルをバックアップするという役割になります。
障害発生時は，バックアップサーバが障害によって機能停止したマシンになりかわるという縮退環境で運用します。この縮退環境は，2台運用の例の通常時と同じ構成となります。
まず，ゲートウェイにはゲートウェイ用設定のみ，サーバにはサーバ用設定のみ，バックアップサーバにはバックアップサーバ用設定のみをインストールします。また，ゲートウェイとバックアップサーバの間，サーバとバックアップサーバの間でそれぞれデータの2重化とバックアップを行ないます。
障害発生時には，バックアップサーバにバックアップしておいたゲートウェイとサーバの設定を利用して，バックアップサーバがゲートウェイもしくはサーバの代理となって稼動します。
この構成では，障害時でもセキュリティ的に通常時と同じだけのレベルが保てます。また，予備サーバにcronで他の2台のマシンの状態を監視させておけば，障害が発生すると同時に管理者にメールを送ったり，自動で設定を変更して再起動させたりして，管理者の負担を減らすことができるでしょう。
この構成では，予備サーバに必要なデータがすべて保存されるので，MOやストリーマなど外部メディアへの一括バックアップも楽に行なえます。さらに，予備サーバについては，通常時の負荷はバックアップのみなので，安価な486程度のマシンで十分でしょう。
ゲートウェイ，サーバの完全2重化による無停止システムという構成です。
通常時は，ゲートウェイ，サーバともに1台がメイン，1台が予備機として稼動します。ゲートウェイとゲートウェイの間，サーバとサーバの間でデータの2重化を行ないます。
障害発生時は，ゲートウェイ，もしくはサーバの予備機が障害により機能停止したマシンになりかわるという縮退環境で運用します。
この構成では，ゲートウェイ，サーバともに予備機が常に待機しています。障害によりメインのマシンが機能停止しても，ただちにもう1台が通常時と同様に稼動を開始するので，サービス停止期間はほとんどなくなります。
しかし，ゲートウェイ，サーバの完全2重化ということは，同一スペックのマシン4台分のコストがかかるという欠点もあります。
また，この4台構成では，通常時も予備機を利用して，負荷の分散をおこなうとが可能です。負荷の分散により，単純な障害の発生自体を防ぐことにもなるでしょう。
負荷分散の手段として，ラウンドロビンDNS機能があります。ラウンドロビンDNS機能とは，1つのドメイン名に対し複数のIPアドレスを割り当てておき，ドメイン名が検索される度に異なるアドレスを返す機能のことです。
ここまでにあげた例の特徴を表にまとめたものを，以下に示します。
| 構成 | サービス 停止期間 | データ 消失期間 | 障害時の セキュリティ | コスト | 備考 |
|---|---|---|---|---|---|
| 1台 | 約1日〜約3日 | 最大1週間 | --- | 低 | セキュリティ，運用とも効率悪い |
| 2台 | 数分〜約1日 | 最大30分 | 低下 | やや低 | ネットワークの物理的接続は手動切り替え |
| 3台 | 数分〜数時間 | 最大30分 | 変化なし | やや高 | 常時監視による障害通報など 外部バックアップが簡単 |
| 4台 | なし | 最大30分 | 変化なし | 高 | 無停止 負荷分散により障害自体を予防 |
※外部メディアへのバックアップを毎週1回，データの2重化を30分毎に行なうものとする。
以上の4つの例を紹介したわけですが，この他にも障害対策にはさまざまな方法があります。コストと耐障害性，管理の容易さによって選択肢は変わってきます。
今回紹介した4台構成の無停止システムなどは，耐障害性は高いですが非常にコストがかかり，SOHOなどに導入するのはあまり現実的ではないかもしれません。
現在の環境と導入コストを考えて，自分の環境に合った障害対策を色々考えてみましょう。
今回で第1部『サーバ構築編』は終了し，次回からは第2部『定常運用編』となります。
次回は，「データを2重化しよう！」です。
データの2重化や自動バックアップのツールと設定などについて説明していきたいと思います。
（ＡＳＨマルチメディア研究会／ｊｏｅ，高柳）