クラスタリングカタログ
1．クラスタリングカタログ
クラスタリングとは、複数台のサーバを使用して、負荷分散を行い、可用性や障害性を向上させることです。クライアントからは、１台のサーバに見えるようにすることからクラスタリングと呼ばれます。クラスタリングには大きく分けて4種類あり、以下の2つの項目の組み合わせで目的が決まります。
-
共有ディスクの有無
共有ディスクとは、クラスタリングを構成する各サーバで共有接続しデータを保持するディスクのことです。 - Active型 or Stanby型
「Active」とは、サーバがサービスを提供しているオンライン状態のことをいいます。「Stanby」とは、サーバがサービスを提供していないオフライン状態のことをいいます。サービスは提供していませんが、電源が入った状態でいつでもサービスを開始できる状態になっています。
2．共有ディスクなしのActive-Active型
Webサーバの負荷分散を行う場合によく使用される構成です。
各ノードともActiveとなっており、上位のロードバランサー（※1）が、クライアントアプリケーションの要求を割り振ることにより、負荷分散されます。共有ディスクを使用しないため、ノード間のデータ共有を行う場合、データの同期を行う必要があります。そのため、Webサーバのようにデータを共有する必要がないサービスを負荷分散する場合によく使用されます。DBサーバのようにデータを保持するサービスをこの構成でクラスタリングする場合、データの保持方法と同期方法を見当する必要があります。
※1：ロードバランサー：クライアントアプリケーションの要求を各サーバに振り分けて負荷分散を行う専用のハードウェアです。ロードバランサーを配置するとクライアントアプリケーションからは、サーバが1台であるように扱えるようになります。
- 長所
・ノードの台数を増やすことにより、簡単に負荷分散が可能
- 短所
・データをノード間で同期させる必要がある場合、複雑な同期処理が必要
・ロードバランサが必要
・ロードバランサが壊れた場合、サービスが停止してしまうため、二重化の検討が必要
このように、特定のハードウェアが壊れた場合にサービスが停止する箇所を「シングルポイント障害」と呼びます。
◇DB Replicationでの使用例
DBを共有ディスクなしのActive-Active型でクラスタリングする場合は、下図のように各サーバの役割（マスタ／スレーブ）を決めて構成します。
◇役割
- マスタ
更新可能なデータベースです。データが更新された場合、更新データをスレーブサーバに伝搬させます
※障害対策のためにマスタサーバを後述の「Active-Stanby構成」にする場合もあります - スレーブ
読み取り専用のデータベースです。負荷に応じて台数を増やします。
マスタとスレーブに役割を分けるのは、更新可能なサーバが複数存在すると、データの更新が競合しないようにするためのロックや同期処理が複雑となり、負荷分散の役割を果たさなくなるためです。
※詳細は、後述の「共有ディスクありのActive-Active型」を参照。
◇チューニングポイント
読み取り専用のスレーブは、負荷に応じて台数を増やせますが、効果は以下のようなサービスの特徴に依存します。参照が多いサービスの場合は、参照負荷が高いため、スレーブを増やせばよいですが、更新が多いサービスの場合、スレーブを増やすとマスタからスレーブへの更新伝搬に負荷が掛かり過ぎ逆にパフォーマンスが低下する場合があります。
マスタとスレーブの参照先の判断は、クライアントアプリケーションで行います。更新処理を行う場合にマスタサーバに接続する形となります。そのため、クライアントとサーバの間には、ロードバランサではなく、HUBを配置する形となります。スレーブの台数を増やす場合は、クライアントアプリケーションで接続するスレーブを決めるか、スレーブの上位にロードバランサーを配置します。
◇安物買いの銭失い（銭で済めばいいけどね）
|
間違っても、”うっかり”安いロードバランサを買ってはいけません。負荷がかかると不安定になる物や、リブートするとなぜか設定が消える（忘れる？）ものもあります（なぜだ？ っていうか、負荷分散するためのロードバランサが負荷に弱いってどういうこと？）。 また、高価なロードバランサが買えない貧乏人は、安いサーバにLinux等のフリー（無料！）なUNIX系OSを入れて、リバースプロキシ機能があるソフトウェアをインストールし、ロードバランサにしたてあげる方法もあります。しかし、設定をミスったり、あまりにも安いハードウェアを使用すると痛い目を見ます！！このコースは、富豪コースなので、そんなお方はいらっしゃらないとは思いますが……。 |
3. 共有ディスクなしのActive-Stanby型
ノードAがActiveでサービスを行い、ノードBはStanbyとなり待機している構成です。ノードAに障害が発生した場合、ノードBにサービスを切り替えます。この切り替え作業のことをフェールオーバといいます。
この構成は、障害対策のためによく使用されます。
共有ディスクを使用しないため、ActiveのノードAでデータが更新された場合、更新データをノードBに同期させる必要があります。また、ノードAからノードBに切り替わった際にクライアントアプリケーションは、ノードBに接続する必要ありますが、仮装IPという仕組みを使い、Activeになっているサーバが仮装IPという代表IPアドレスで、クライアントアプリケーションからの接続を待ち受けます。この構成の場合、データの同期と仮装IPの仕組みを提供するためのクラスタリングソフトウェアを使用する必要があります。
- 長所
・他の構成に比べて、ハードウェアが安価
・データの同期と障害発生時の切り替えは、クラスタソフトが自動的に行うため、運用管理が楽 - 短所
・負荷分散の効果がない
・データ同期中に障害が発生するとデータが失われる可能性がある
・データの同期処理にサーバの負荷がかかる
◇使用例（スタンバイデータベース）
この構成の使用例として、Oracle DataGurdを使用したスタンバイデータベースを説明します。
スタンバイデータベースは、障害対策のために使用します。基本的には、Activeのサーバとは、別の場所でStanbyのサーバを動作させ、地震や火災などの物理的かつ根本的、致命的な障害に対応するために使用します。データベースの場合、更新ログ（REDOログ）をStanby状態のノードに送ることにより、データの同期を取ります。
4. 共有ディスクありのActive-Stanby型
「共有ディスクなしのActive-Stanby型」を共有ディスクを有りにした形です。Activeになっているノードが、共有ディスクをマウント（※）します。Stanbyになっているノードは、共有ディスクを使用しません。ActiveとなっているノードAに障害が発生すると、共有ディスクを切り離し（アンマウント）、ノードBにフェールオーバします。そして、ノードBが共有ディスクをマウントします。ノードの障害を検知し、共有ディスクのアンマウントとマウントを管理するためにクラスタリングソフトを使用します。
障害検知のためにお互いを監視することをハートビート（死活監視）といいます。フェールオーバした際に、サーバが切り替わるため、クライアントアプリケーションの接続先も切り替える必要がでてきます。しかし、フェールオーバが発生する度に、切り替えていると運用が大変ですので、仮想IPという仕組みを使い、クライアントアプリケーションからは、同じIPアドレス（仮想IP）で、サーバを参照できるようにします。仮想IPは、クラスタリングソフトによって管理され、Activeとなっているサーバに割り当てられます。
※マウント：共有ディスクをOSレベルで外付けハードディスクとして認識させること。複数ノードで同時に共有ディスクをマウントすることはできません。データの不整合が発生するためです。
- 長所
・障害発生時に自動でフェールオーバするため運用管理が楽
・データの同期を行う必要がない - 短所
・負荷分散の効果がない
・共有ディスクが高価
・共有ディスクが単一障害点（※）となる
※単一障害点（Single Point of Failure）とは、その箇所に障害が発生すると、サービス全体が停止してしまう障害となる箇所を指します。
5. 共有ディスクありのActive-Active型
クラスタを構成するすべてのノードがActiveとなり、並列してサービスを行うため、負荷分散と障害対策の両方の効果が期待される構成です。しかし、データの更新が複数ノードで同時に発生する可能性があるため、ロックと同期処理を行いデータの競合を防ぐ必要があります。そのため、アプリケーションの特性を生かした物理配置を検討する必要があります。下手にチューニングをした場合、もしくはチューニングしない場合、１台のサーバよりも性能がでないことがあります。データのロックと同期のオーバーヘッドがかかるためです。
共有ディスクありのActive-Active型の詳細は、
を参照してください。
- 長所
・負荷分散が可能
・フェールオーバのオーバーヘッドが少ない - 短所
・管理が複雑
・効率的な負荷分散を行うためには、アプリケーションの特性を活かした物理設計が必要