よくある質問・用語集

  • もっと調べる
  • どうやって使う?

冗長化とは

冗長化とは、システムに何らかの障害が発生した場合に備えて、障害発生後でもシステム全体の機能を維持し続けられるように、予備の設備を平常時からバックアップとして配置し運用しておくことである。一瞬の停止も許されないシステムで採用され、冗長化の手法には、サーバの二重化による「サーバの冗長化」、「ストレージの冗長化」、回線経路の二重化による「ネットワークの冗長化」などの複数の手法がある。

冗長化はなぜ必要か?

一般的に、システムの障害には次のようなものがある。

  • ハードウェアの故障
  • 基本ソフトウェアの停止・誤作動
  • アプリケーションの停止・誤作動
  • ネットワークの故障や混雑
  • リソースの不足

これらの障害を完全に防止しようと思うと、非常に高価なハードウェアを準備したり、故障や誤作動が発生しないソフトウェアを製作するといった対応が必要となり、膨大なコストがかかってしまう。また、リソースの不足については、あらかじめ予測することが難しく、必要以上の能力を準備するには高いコストを払う必要がある。こうした問題に対応するために、冗長化という方法が使われる。

冗長化のメリット

冗長化することには、様々なメリットがある。

  • 障害対応が自動的に行える

    システムが冗長化されていないと、ソフトウェアのバグ、ハードウェアの故障、災害などでシステムが停止したときに、バックアップからシステムを再構築するにはかなりの時間がかかる。復旧までに時間がかかると、サービスを止めることによる損失も大きくなってしまう。また、夜間や休日に緊急の事案が発生した場合には、対応体制を整えることが難しい。しかし、冗長化されたシステムでは、障害対応は自動的に行われる。ダウンタイムが最小化できるとともに、対応コストは大幅に低下する。

  • 負荷を分散することができる

    システムに大きな負荷が掛かった時に、冗長化されていないシステムではシステムのリソースを使い切ってしまいサービスを継続できなくなる事態が発生することがある。しかし、システムが冗長化されている場合には、処理を分散し、サービスを継続することができる。

  • メンテナンスしやすい

    冗長化されていないシステムでは、セキュリティの問題などによるソフトウェアのバージョンアップ、ハードウェアの交換などが必要な場合、システムを停止したり再起動したりする必要がある。このような作業は、利用者の少ない休日や夜間に行われることが多い。しかし、システムが冗長化されていれば、一部の機能を停止させてメンテナンス作業を行うことができる。

  • BCP対策になる

    最近は大規模な災害が多く発生していることもあり、事業継続計画(BCP)を検討する企業が増えている。災害やテロなどが発生した場合に備え、早期復旧または被害を最小限に抑えるための予防措置として冗長化しておくことで、リスクを回避することができる。

  • エンジニアの働き方改革につながる

    冗長化されていないシステムでは、メンテナンスを休日や夜間に行わなければならい場合がある。さらに、障害が発生した場合、その復旧には多大な労力が必要となり、休日や夜間に対応する必要性がより高まる。しかし、システムが冗長化されていれば緊急対応を行う可能性が大幅に減少し、休日や夜間に対応する必要性も低くなる。そのため、エンジニアの業務負担を軽減し、働き方改革にも繋がる。

冗長化のデメリット

冗長化を行うデメリットは、なんといってもコストが掛ることである。一般的には倍以上のコストが必要になる。

冗長化と可用性

冗長化を行うことで、システムの可用性が向上する。可用性とは、簡単に言えば、止まらずに動く性能のことである。コンピュータを使ってシステムを作ると、障害などのためにサービスが停止してしまう可能性がある。この停止時間が少ないシステムのことを、可用性が高いシステムという。

可用性の指標としては、稼働率を用いることが多い。稼働率は、次のように計算することができる。

MTBFとMTTR

稼働率

この式からも分かるように、可用性を高めるには、次のような対処が必要である。

  • システム障害の要因をできるだけ減らし、できるだけ停止しないようにする
  • 停止した場合のダウンタイム(修理時間)を最小限にする

システムの冗長化は、この2つの目標を達成するために用いられる手法である。

冗長化の構成

冗長化する際は、メインとなる設備やシステム、予備となる設備やシステムの稼働の仕方によって、以下のような構成がある。

アクティブ・スタンバイ構成

通常時はアクティブ機(稼働系)で処理を行い、アクティブ機が正常に処理を行う間、スタンバイ機(待機系)は使用せず待機している。アクティブ機とスタンバイ機は、お互いに通信を行い、定期的に相手の状態をチェックする。もし、アクティブ機に何らかの障害が発生し、処理を継続することができなくなると、スタンバイ機がそれを検知し処理を引き継ぐ。

アクティブ・アクティブ構成

主に参加するすべてのノードが同じ処理を行う。故障したノードがあると、該当ノードの処理を別のノードが引き継ぐ。

マスター・スレーブ構成

主にデータベースにおいて、サーバをマスターとスレーブとの2つの役割に分ける方式である。1台のサーバをマスターとして配置し、複数のデータベースの制御・操作を行う。残りのサーバをスレーブとして配置し、マスターの制御に応じて動作させる。

マルチマスタ構成

主にデータベースにおいて、全てのサーバにマスターの役割を持たせる方式である。データの読み込みしかできないスレーブサーバを配置したマスター・スレーブ構成とは違い、全てのサーバでデータの書き込みも可能となる。ただし問題点として、複数台のマスターサーバに同一エントリの追加や削除を行った際、サーバ上のデータが異なる結果になってしまうことがある。同時更新が発生するようなシステムの場合には、マルチマスタであっても、更新は1台のサーバに集中させて対処する必要がある。

冗長化の仕組みの例

冗長化は、ネットワークやサービスなどの様々なポイントで行われる。以下は、代表的な冗長化の仕組みの例である。

STP 〜スイッチ経路の自動切替〜

STPは、スイッチなどで構成されるネットワークを冗長化するためのプロトコルである。通常、ネットワーク上に複数の到達経路を作ると、ネットワーク上でパケットがループしてしまう。STPでは、経路の重複を自動的に検知して、適切な経路のみを使うようにパケットのループをブロックする。もし、何らかの原因で経路が利用できなくなった場合には、それを検出して経路を切り替える。

VRRP 〜サービス用のIPアドレスの切り替え〜

VRRPは、ルーターなどを冗長化する仕組みである。STPが経路を冗長化するのに対して、VRRPはゲートウェイなどのIPアドレスを冗長化すると言い換えることもできる。VRRPに参加する複数の機器(ノード)が協調し、サービスで利用する代表IPアドレスを割り当てるノードを決定する。もし、代表のノードが故障した場合には、自動的に検知し他のノードに切り替えが行われる。

ボンティング 〜NICの多重化〜

ボンディングとは、1台のサーバに複数のNICを搭載し、それらのNICを一つの仮想的なNICとして扱い、障害時の切り替えや負荷分散を行う仕組みである。サーバとスイッチやネットワークの間を冗長化するのに利用する。ボンディングを利用することで、ネットワークインタフェースの物理的故障や、接続するネットワークスイッチの障害に対して冗長性が取られるので、サービスの継続性を向上できる。

プロキシ・ロードバランサ 〜サーバの振り分け〜

サービスを提供するサーバを何台か用意し、ロードバランサー(負荷分散装置)を使って処理を振り分けることによってサービスの冗長化を実現する仕組みである。

QoS 〜サービス品質の確保〜

QoSとは、パケットの種類を判別して遅延やパケットロスが許されないものを優先的に処理することで、ネットワークの混雑を回避する仕組みである。

RAID 〜ハードディスクの冗長化〜

RAIDとは、複数のハードディスクをまとめて一台の装置として管理することで、ハードディスクの耐障害性を高める仕組みである。

RAID 0, RAID 1, RAID 5, RAID 6などが使われているが、冗長化できるのはRAID 1(ミラーリング)、RAID 5(ミラーリング+ストライピング)、RAID 6(ミラーリング+ストライピング+予備ディスク)である。RAID 0は、性能改善のためだけに使われる。

冗長化の対象

冗長化を行う対象のシステムとしては、以下のようなものがある。

仮想サーバやクラウド上のシステムの冗長化

VMWareのような仮想システムは、障害が発生すると自動的に他のノードに処理をマイグレーション(移動)する機能を持っているものがある。これも冗長化の機能の一つである。また、一般的にAWSのようなIaaSやPaaSなどのクラウドシステムも冗長性を考えて設計されていることが多い。

しかし、これらの冗長化は、あくまで仮想ハードウェアレベルでの冗長化である。つまり、アプリケーションの停止までは担保されていないし、担保することも不可能である。そのため、仮想サーバやクラウド上に重要なサービスを配置する場合には、PacemakerやDRBDなどの冗長化を行うソフトウェアを利用して、アプリケーションレベルの冗長化を担保する必要がある。実際に、AWS上でPacemakerを利用して冗長化を行っている事例も多い。

アプリケーションレベルの冗長化

前述した冗長化の方法は、ネットワークや機器のトラブルに対応するためのものである。一方で、OS上で動作するアプリケーションが停止してしまう場合も想定され、アプリケーションレベルでの冗長化も考慮する必要がある。アプリケーションレベルで対策を行うためには、専用のソフトウェアが必要である。代表的なソフトウェアとしては、次のようなものが知られている。

Heartbeat 〜アプリケーションレベルの対策〜

Heartbeatとは、クラスタリングを実現するためのソフトウェアである。クラスタリングは、複数台のシステムを組み合わせて1つのシステムに見せることで、システムの一部の機能に障害が発生しても機能が停止しないようにする仕組みである。メールサーバやWebサーバ、データベースサーバなど、様々なサービスの冗長化に利用できる。

Pacemaker 〜アプリケーションレベルの対策〜

Pacemakerとは、Heartbeatの後継バージョンであり、Heartbeatからリソース制御の機能を独立させたものである。Heartbeatから独立することにより、Pacemakerは対応するサービスが増え、「crmシェル」の実装により簡単に動作するようになった。

DRBD 〜データの同期〜

DRBDとは、HAクラスタを構築するために設計されたブロックデバイスシステムで、ネットワークを介して2台のサーバのハードディスクをミラーリングすることができるソフトウェアである。専用のディスクやインタフェースを必要とせず、Heartbeatと連携する事で、データベース、nfs、sambaなどのHAクラスタを安価(共有ストレージ無し)に実現する事が可能である。

Keepalived 〜IPアドレスの切り替え〜

Keepalivedとは、VRRPを実装するソフトウェアである。LinuxのLVSという機能を利用してロードバランサー(負荷分散装置)として動作させることもできる。また、Keepalivedの設定をGUIで管理するソフトウェアなども公開されている。

冗長化の方法や構築の事例

冗長化の対象になるのは、重要で停止することができないシステムである。例えば、航空管制のシステムや銀行のオンラインシステムなどがある。こうした重要なシステムが停止してしまうと多大なリスクがあるため、サーバーだけでなく、ネットワーク回線、ネットワーク機器など、関係しているすべての要素を冗長化しようとする。

近年は、インターネットのシステムでの冗長化を行う場合が多くなっている。以下の記事では、その例について解説する。

WEB-DBサーバの冗長化の方法

Pacemakerなどのクラスタソフトウェアとデータベースソフトウェアを効果的に組み合わせることで、WEB-DBサーバを冗長化することができる。

WEB-DBサーバの冗長化へ

メールサーバの冗長化の方法

メールサーバは、コミュニケーションツールとしてビジネスになくてはならないものである。クラウドサービスなど、外部のサービスを利用することもできるが、ビジネスの重要な機密情報や顧客情報などを安全に扱うため、自社内にサーバを置くことを検討する組織も多い。

メールサーバの冗長化へ

構築事例:DHCPサーバ冗長化(IPv6対応)

エンドユーザ向けにIPv6のIPアドレスの払い出しをしていくため、IPv6対応のDHCPサーバ構築を行った。重要なサービスのため、冗長化したDHCPサーバとして提供した事例である。

構築事例:DHCPサーバ冗長化(IPv6対応)へ

構築事例:OpenLDAPによるLDAPサーバのマルチマスタ構成

OpenLDAPのミラーモードでLDAPサーバを二重化した事例である。認証システムの冗長構成が求められていたが、冗長化ソフトウェアの導入はコスト面で問題があった。OpenLDAPの柔軟性を活用し、OpenLDAP標準機能であるミラーモードを使う事で、特別な冗長化ソフトウェアを使わずに、認証システムを冗長化した。

構築事例:OpenLDAPによるLDAPサーバのマルチマスタ構成へ

データーベースサーバ(MariaDB MaxScale)

MariaDBは、プロキシサーバを使って、データの整合性を保持したままデータベースの負荷分散や冗長化を行うことができる。

MariaDB MaxScale〜OSSのデータベース向け負荷分散ソフトウェア〜へ

データーベースサーバ(Postgres)

Postgres、pgpoolで冗長構成されたWEB-DBシステムを、DRBD、Heartbeatを使ったシステムに置き換えることで性能向上を実現した事例である。

構築事例:PostgreSQLサーバ冗長化へ

監視サーバ

デージーネットでは、Pacemaker/corosyncを利用して、Zabbixをクラスタ構成で導入することを提案している。Zabbixで利用するデータベースも、2台のサーバで冗長構成を取り、サーバ間でのデータ同期にはDRBDを利用している。

Zabbixシステム構成へ

DNSサーバ

DNSサーバでは、特定のソフトウェアの脆弱性によって外部から攻撃を受けてDNSサービスが停止することがないようにマルチDNS環境を構築する。

構築事例:マルチDNS環境の構築へ

NFSサーバ

NFSの仕組みは、LinuxやUnixのカーネルに完全に統合されている。そのため、オープンソースの各種クラスタソフトウェアとの相性がとても良いのが特徴だ。

NFSサーバの冗長化へ

ファイルサーバ

Windowsファイル共有は、一般的にはWindows Serverを使って行われる。しかし、Windows Serverのクラスタ製品は一般的ではない。Linux上で動作するSambaとPacemakerなどのクラスタソフトウェアを組み合わせることで、ファイルサーバを冗長化することができる。

Windowsファイル共有サーバの冗長化へ

デージーネットの冗長化の軌跡

デージーネットは創業以来、15年以上に渡ってシステムの冗長化に取り組んできた。特に、クラスタサーバの構築では、数多くの実績を持っている。

デージーネットでは、2005年までは、UnixWare Reliant HAなどの商用製品を利用してクラスタサーバを構築してきた。しかし、こうした製品は非常に高コストで、インターネットサーバの構築には見合わなかった。しかし、2005年にオープンソースソフトウェアのHeartbeatとDRBDを使った冗長化に成功し、国内では他社に先駆けて、OSSを使ったクラスタサーバ構築サービスの提供を開始した。その後、RedHat Cluster、Pacemaker、corosyncなどのクラスタソフトウェアでもサービスを開始し、お客様の課題や用途、予算に応じて、様々な冗長構成を提案することができる体制を築いている。現在では、年間100セット以上のクラスタサーバを構築している。また、「クラスタ.jp」というクラスタの情報を集めたサイトを運営している。

【カテゴリ】:クラスタ  システム管理  ネットワーク  

  • もっと調べる
  • どうやって使う?

【Webセミナー】自社でOSSを採用しよう!今更聞けないOSSの基本セミナー

日程: 11月22日(金)Webセミナー「BigBlueButton」を使用します。
内容: OSSを導入したいけど、どこから手をつければいいかわからない方必見!
ご興味のあるかたはぜひご参加ください。

セミナー申込

関連用語

冗長化に関連するページ(事例など)

冗長化とは先頭へ