現実的でバランスの良い冗長化について考える：運用管理者のための知恵袋（7）

システムの可用性を向上させるためには、冗長化が必要だ。しかし、ベンダのいう冗長化は、かえって構成が複雑になる場合もある。今回は、現実的でバランスの良い冗長化について考える

　システムの可用性を上げるための冗長化はよく行われる。ただし、ベンダが推奨する冗長化構成は一見技術的にスマートできれいだが、実際に利用現場で携わっている者の立場からすれば、やたらとシステム構成を複雑にするだけで、むしろコストや運用の手間を増大させるものも多いと感じている。そこで今回は、現実的でバランスの良い冗長化について考えてみたい。

　冗長化のポリシーは組織規模によって大きく変わるので、今回は中小企業、もしくは大企業内の部署レベルでの冗長化を一応の前提としたいと思う。

その1 ネットワーク機器の冗長化

　ネットワークインフラが業務上重要なものとなっている現在、ネットワーク機器を冗長化しようと考えるのはよく理解できる話である。しかしネットワーク機器の冗長化では、概してネットワーク構成や関連技術が複雑化する（図1）。冗長化する機器間の生存確認（ハートビート）はどうするのか、デフォルトゲートウェイはどの機器がどのように受け持つのか、トポロジー上発生するループをどのように止めるのかなど、押さえるべき事項は多い。

図1　ネットワーク機器の冗長化では、関連機器の構成が複雑化する

　「設計と導入時にテストをきちんとしておけば、いざというときネットワークが自動的に切り替わってくれるので難しいことではない」と考える人もいるかもしれない。しかし、自動切り替えがうまくいくのは、あくまでも片方のネットワーク機器が想定どおりきれいに壊れてくれればの話であり、機器が中途半端な壊れ方をすると自動切り替えがうまく行われないこともある。このような場合、どうしてもネットワーク管理者が手動でメンテナンスを行う必要が生じる。ということは、やはりネットワーク管理者はシステム全体をよく理解しておく必要がある。

　私がお勧めするのは、コールドスタンバイ構成を取ることである。コールドスタンバイ構成とは、同じ設定をした機器を横に置いておいて、もしハードウェアが故障したらその機器と物理的に交換する方法である。構成がシンプルなだけでなく、ネットワーク構築費用も比較的安く収まるのは大きなメリットである。ネットワーク管理のために専門要員を置ける大企業などでなければ、可用性においてもコストにおいてもコールドスタンバイ構成はお勧めである。

その2　メールサーバの冗長化

　ひとくくりにメールサーバといってもいろいろな構成要素があるので、ここではMTA（SMTPサーバ）、POPサーバ、メールDB（データベース）の3つに分けて考えたいと思う（図2）。まずMTAとPOPサーバの冗長化は比較的容易である。MTAの場合は、複数台並べておいてDNSのMXレコードに追加するだけで対応可能である。POPサーバの場合は、ロードバランサーで振り分けを行うことにより対応可能である。

図2　メール関連の冗長化では、メールDBをどうするかがポイント

　しかし、メールDBについては冗長化に工夫が必要である。どのようなソリューションを導入するかによって対応方法は異なると思われるが、私に経験がある方法は、ハイエンド・ストレージに搭載されているリアルタイム同期機能を使った方法と、Lotus Dominoのレプリカ機構のような仕組みを用いた方法である。いずれの方法も導入はかなり高価である。

　私がお勧めするのは無理して冗長化を行わず、外部業者のASPサービスを利用してメールサービスをアウトソーシングすることである。メールサーバの構築やメンテナンスには技術と経験が必要なため、結果的にすべてを社内で賄うより、安くて安定的なサービスが利用できるようになるはずである。

その3　業務支援系サーバの冗長化

　業務支援系サーバと一口にいっても、グループウェアサーバ、給与管理サーバ、人事支援サーバなどいろいろある。しかし大抵は3階層モデル、すなわちフロントエンド（Webサーバ）、ミッドティア（アプリケーション・サーバ）、バックエンド（データベース・サーバ）構成を取っていると思われるので、ここでは3階層モデルを採用したシステムを前提とする。

　一般的な3階層モデルでは、フロントエンドの冗長化は比較的容易である。同じサーバを複数台並べておいてロードバランサーで振り分けることで対応可能である。ミッドティアについては採用する製品によるが、比較的容易に冗長化できる場合が多い。

　しかしバックエンドの場合は、メールDB同様、冗長化に工夫が必要である。一般的なRDBMS（リレーショナルデータベース管理システム）を採用しているのであれば、冗長化のためのさまざまなソリューションが存在しているので、それらの利用を検討するのが安全かと思われる。しかしそこまでの予算を掛けるほどの業務的なインパクトがないのであれば、予備機を用意しておき、万が一のことが起きたらバックアップを予備機で展開し、代替機として使うのも良い選択である。

　私がお勧めするのは最近普及し始めている仮想化テクノロジを採用することである。十分なハードウェアリソースを用意しておいて、ソフトウェア的に仮想化された環境上でシステムを展開する仕組みである。初期投資はそれなりに掛かるが、うまく構成を組めば、結果的には複数の業務支援系サーバそれぞれを冗長化するよりも、コスト面でも可用性面でもメリットが大きい。

その4　ファイルサーバの冗長化

　ファイルサーバは活用率が比較的高いにもかかわらず、冗長化に関しては意外に軽視されている場合が多い。ファイルサーバを冗長化する場合、同一のディスク容量を持つハードウェアの調達とデータの同期をどのように行うかということが課題となる。

　ハイエンドストレージの場合、同一機器を複数台用意することで各ストレージ間でオンラインもしくは非同期で自動バックアップを取る仕組みが用意されている。NAS（Network Attached Storage）の場合、比較的安価なモデルでも同様の仕組みが用意されている場合があるので、それを利用するのも良い選択である。

　私がお勧めするのは、これは厳密には冗長化ではないのかもしれないが、ファイルサーバ自体はそのまま使い、データ保全に家庭用NASを利用することである。最近の家庭用NASは数Tバイトの物理容量がありながら、価格が10〜20万円程度なのでとても安価である。家庭用NASが1セットで不安であれば、数セット用意しておけば可用性はさらに高まる。

現実的な冗長化計画とは

　冗長化を目的とした企画書や提案書を多数見てきたが、いかに技術的にきれいに冗長化を行うかに焦点が当てられたものがほとんどで、まるで冗長化をすること自体が目的であるかのようなプランばかりである。しかし原点に返ってみると、そもそもの冗長化の目的はいうまでもなくシステムの可用性向上である。

　今回ご紹介した例は、さまざまな冗長化のほんの一例でしかないが、一口に冗長化といっても、事例ごとにいろいろ工夫ができることが分かっていただけたと思う。皆さんも教科書や定石にとらわれないで、現実的でバランスの良い冗長化について考えてみるとよいと思う。