サーバー（データベース）の2重化による冗長化の方法と事例

システムの信頼性の向上の起因

当社が開発したシステムをご利用いただいているお客様から、「当社のシステムは365日動いているので、サーバーが障害を起こしてもストップしないように作ってくれないか？」と問合せがありました。

そのお客様のシステムは、当社が半年ぐらいかけて作ったオーダーメード（スクラッチ）のシステムです。

クライアントサーバーシステムを導入し、親機であるサーバーと子機となるクライントに分かれています。

クライントは20台以上あったのですが、データを管理しているサーバーは1台だけだったので、サーバーが壊れてしまったら、業務がストップする状態でした。

業務では、オペレータがクライアント端末で操作し、サーバーには、クライントから送られてきたデータがすべて集約されています。

そこで、サーバーを2台に増設して、データベースの２重化を導入する事としました。

データベースの安全性の向上（冗長化）

データベースの2重化とは業界用語で「冗長化」といいます。

データベースを2重化すると、クライントから送られてきたデータを２台のサーバーのそれぞれのデータベースに書き込まなければなりません。つまり、クライントからは１台に見えて、実は2個のデータベースに書き込む事をする必要があります。それぞれのデータベースは独立していて、障害が発生した時は単独でも動くように設定します。

このような冗長化は、銀行や証券会社など大手の会社では、当たり前に行われています。

サーバースタンバイによる冗長化の難易度

大手はお金をかけてクラウドサーバーや、Active Directoryを利用して冗長化ができるのですが、中小企業では大手のようにスムーズにいきません。

サーバースタンバイによる冗長化は、実のところ難易度が高いのです。

また、データベースに書き込まれる情報量が多いため、クライアントがLANを使用するときに回線速度の低下が気になることが予想されました。そこで、メインサーバーとサブサーバーは専用のLANで接続し、通常利用されるLANとは切り分けることにしました。

メインサーバーに、LANポートを追加し、そのポートを介して、サブサーバーに接続しました。サブサーバーは、メインサーバーから専用のLAN回線でデータを受け取ることができるので、一般利用されるLAN回線に悪影響を与えなくなります。

いろいろと調べて設定しながらも、サーバースタンバイによる冗長化に成功しました。サーバー2台を運用し、メインサーバーのデータが、スタンバイ状態のサーバーにも書き込まれました。

サーバースタンバイによる冗長化では、メインサーバーがダウンした時に、手動で切り替える必要はありますが、切替を行ったらきちんとスタンバイ状態のサーバーがメインサーバーに昇格して、直前のデータから続けて処理を行う事ができました。

また、メインサーバー復帰後は、メインサーバーがサブサーバーのデータを吸収し、手動切替後は何事もなかったように動作しました。

お客様のシステムはかれこれ4年間ノンストップで動作していますが、いざというときに安心してシステムを利用できるようになりました。

データベースを冗長化するためのポイント

今回の冗長化で分かったこと、初期費用のコストを抑えてデータベースを冗長化できたポイントは、次の3点です。

• 通常のネットワーク利用の場合、サーバーの自動切換え（フェールオーバー）は不可
• サブサーバーのデータベースの設定は、基本的に別のデータベースとなるため書込み許可の設定が必要
• 2台のサーバーを接続するネットワークは、通常利用されるLANと分けた方がよい