+0 - 0  by

HAクラスタとは

HAクラスタの概要やストレージ構成について紹介します。

目次

HAクラスタ概要

  • HAクラスタ」基本説明
  • 「フェイルオーバー」と「フェイルバック」
  • HAクラスタ構成ソフトウェア
  • HAクラスタ構成方式

HAクラスタのストレージ構成「共有ストレージ」と「レプリケーション」

  • 「共有ストレージ」構成
  • 「レプリケーション」構成

③DRBDによるPostgreSQL用HAクラスタ構築

  • DRBD+PacemakerでのPostgreSQL高可用性構成構築方法
  • DRBDとPostgreSQLレプリケーション—PacemakerのMaster/Slave構成の基本と事例紹介

①HAクラスタ概要

「HAクラスタ」基本説明

「HA(High Availability)クラスタ」とは、複数台のサーバを相互接続し連携構成(クラスタ)化することで、システムを冗長化させ、コンピュータシステム全体の可用性(アベイラビリティ)を高めることを目的としています。また、システム障害によるシステム停止時間を最短にする迅速復旧機能も含みます。

HAクラスタは、「ミッションクリティカルなデータベースシステム」「基幹業務システム」「商用Webサイト」など、高い信頼性が求められ、システム停止を避けなければならない環境で多く利用されます。

「フェイルオーバー」と「フェイルバック」

フェイルオーバー

HAクラスタでは、稼動中のアクティブサーバに障害が発生し、サービスを継続できなくなった場合に、自動的にスタンバイサーバへ処理を引き継ぐことで、システム全体としてのサービス提供機能を維持します。

この切り替え処理のことを「フェイルオーバー」と呼びます。

フェイルバック

フェイルオーバー後、現アクティブサーバ(元スタンバイサーバ)から、現スタンバイサーバ(元アクティブサーバ)へ処理を引き継ぐことを「フェイルバック」と呼びます。

HAクラスタ構成ソフトウェア

HAクラスタを構成するためのソフトウェアは、「HAクラスタソフトウェア」や「HAクラスタリングソフトウェア」などと呼ばれます。

HAクラスタソフトは、関連サーバ群を常に監視し、アクティブサーバに障害が発生した場合、スタンバイサーバへ切り替える処理を実行します。

HAクラスタ構成方式

(1)アクティブ/スタンバイ構成

「アクティブ/スタンバイ構成」は、HAクラスタ構成の中で、最もスタンダードな構成です。平常時は、サービスはアクティブサーバ上で動いていて、スタンバイサーバは待機状態になっています。

アクティブサーバに障害が発生した場合、アクティブサーバからスタンバイサーバへ処理を切り替えることで、サービスを継続する方式です。

(2)アクティブ/アクティブ構成

「アクティブ/アクティブ構成」は、2台のサーバが両方ともアクティブになっている状態です。平常時は、「サーバAでサービスAが稼働」「サーバBでサービスBが稼働」のように、それぞれ別のサービスを提供しています。

サーバAに障害が発生した場合、サーバAで稼働していたサービスAを、サーバBに引き継ぎます。この場合、サーバBがサービスAとサービスBの両方のサービスを提供します。

「(1)アクティブ/スタンバイ構成」でのスタンバイサーバを平常時にも稼働させることができるため、サーバリソースを有効に活用できるメリットがあります。

(3)N対1スタンバイ構成

「N対1スタンバイ構成」とは、平常時、N台のサーバでそれぞれサービスを稼働させて、その中のどれかのサーバに障害が発生した場合に、スタンバイサーバに引き継ぐ構成です。

ただし、「フェイルオーバー時にパフォーマンス劣化が生じやすい」というデメリットがあります。

参考元サイト

②HAクラスタのストレージ構成「共有ストレージ」と「レプリケーション」

HAクラスタにおけるストレージ構成には、「共有ストレージ」と「レプリケーション」の2種類に大別されます。クラスタソリューションの選択時において、どちらを選択するかについては考慮すべき重要な点となります。

それぞれのメリットとデメリットなどについて紹介します。

「共有ストレージ」構成

「共有ストレージ」構成とは

「共有ストレージ」構成とは、アクティブサーバとスタンバイサーバで同一ストレージを共有する構成です。

サーバA(アクティブ)に障害が発生した場合、サーバB(スタンバイ)に処理が切り替わりますが、サーバBもサーバAがアクセスしていた共有ストレージにアクセスを行います。

「共有ストレージ」構成のメリット

レプリケーション未対応アプリケーションへ対応可能

共有ストレージ構成にすることで、独自にレプリケーション機能を持たないアプリケーション(データベースなど)に対して、処理性能に影響を与えずに冗長化し、可用性を向上できます。

信頼性の高いフェイルオーバー

ストレージが1つのみであるため、フェイルオーバーの信頼性が高まります。

フェイルオーバー時のデータ不整合発生を軽減

ストレージが分散しているレプリケーション構成と比較した場合、共有ストレージ構成では、実データは1つの共有ストレージにのみ存在しているため、フェイルオーバー時のデータ不整合が発生するリスクを低減できます。

また、データ復旧のための時間が発生しません。

ネットワークスペックに影響されない

レプリケーションを行う必要がないため、ネットワークパフォーマンスに影響されません。

「共有ストレージ」構成のデメリット

高コスト

共有ストレージとして、高額なストレージハードウェアを用意する必要があるため、導入時コストが高額になる傾向があります。

クラウド(仮想環境)展開は不可

共有ストレージは、クラウドや仮想環境において使用できないため、オンプレミスからクラウドへの展開を行う場合などに制約が発生します。

アプリケーションデータ構成に影響

アプリケーションのデータ構成について、共有ストレージを利用するように設定(改修)する必要があります。

共有ストレージが単一障害点に

ストレージが1つであるため、共有ストレージが単一障害点とならないように、ハードウェア構成を適切に構成する必要があります。

「レプリケーション」構成

「レプリケーション」構成とは

「レプリケーション」構成とは、サーバA(アクティブ)とサーバB(スタンバイ)で、それぞれのローカルストレージを利用し、レプリケーションによりデータ同期を行う構成です。

それぞれのローカルディスクをレプリケーションすることで、ミラーボリュームを作成し、仮想的な共有ディスクとして扱います。

サーバA(アクティブ)に障害が発生して、サーバB(スタンバイ)に処理が切り替わった場合、サーバBはサーバAからレプリケーション同期されている、サーバBのローカルストレージにアクセスします。

「レプリケーション」構成のメリット

低コスト

ローカルストレージを使用し、高額な外部ストレージを用意する必要はないため、安価にHAクラスタを構築できます。

シンプルに導入可能

共有ストレージ構成とは異なり、ハードウェア構成がシンプルであるため、導入しやすいメリットがあります。

ディザスタリカバリ対応

共有ストレージではないため、遠隔地へのレプリケーション(フェイルオーバー)が可能です。

クラウド内や遠隔地サーバに対してレプリケーションを行うことで、ディザスタリカバリサイトを構築できます。

参考元サイト

③DRBDによるPostgreSQL用HAクラスタ構築

DRBDを利用して、オープンソースDB「PostgreSQL」をHAクラスタ化する方法についてまとめられているサイトを紹介します。

DRBD+PacemakerでのPostgreSQL高可用性構成構築方法

ポイント

「オープンソースカンファレンス2014」で発表されたスライド資料です。

「DRBD」と「Pacemaker」を利用して、PostgreSQLのHAクラスタを構築するための手順について細かくまとめられています。

「Pacemaker」とは、オープンソースソフトウェアとして開発されている、HAクラスタソフトウェアです。ネットワークで接続された複数のサーバコンピュータを連携させ、アクティブサーバに故障を検知したら、スタンバイサーバにフェイルオーバーさせるクラスタ管理機能を提供します。

テーマ

■高可用性とは
■PostgreSQLのHA構成
■Pacemakerとは
■DRBDとは
■構成例(PostgreSQL+Pacemaker+DRBD)
■インストール
→PostgreSQLのインストール
→Linux-HA Japanリポジトリのダウンロード
→Linux-HA Japanリポジトリの設定
→PacemakerとHeartbeatパッケージのインストール
→ELRepoリポジトリの設定
→DRBDパッケージのインストール
■OSの設定
■Heartbeatの設定
■DRBDの設定
→DRBD用パーティションの準備
→DRBDリソースの設定
→DRBDリソースの起動とデータの初期同期
→ファイルシステムの作成とマウント
■PostgreSQLの設定
■Pacemakerの設定
■デモ

ページリンク

→オープンソースカンファレンス2014 Nagoya →【入門】PostgreSQL+Pacemaker+DRBDで高可用性構成を構築してみよう

DRBDとPostgreSQLレプリケーション—PacemakerのMaster/Slave構成の基本と事例紹介

ポイント

2014年3月に開催された「Open Source Conference 2014」での発表スライドにて、Pacemaker側からの視点を中心として、「DRBDによるPostgreSQLレプリケーション」について解説されています。

「DRBD+PostgreSQLレプリケーション構成」についてのメリットとデメリットを踏まえて、「PostgreSQLレプリケーション構成」と「フェイルオーバー時の昇格の仕組み」について紹介されています。

また、レプリケーションLANに障害が発生した事例と対策方法についても参照できます。

テーマ

■各アプリケーションの概要
→Pacemakerとは
→共有ディスクを使用した構成について
→DRBD、PostgreSQLレプリケーションを使用した構成
→DRBD概要
→PostgreSQL レプリケーション概要
→Pacemaker+DRBD / PostgreSQLレプリケーション構成
■Master Slave リソースと従来のリソースとの違い
→リソースの種類
→Primitiveリソースとcloneリソース(共有ディスク構成での例)
→MSリソース(Pacemaker+DRBDの例)
→MSリソース(Pacemaker+ PostgreSQLレプリケーション)
■Masterに昇格するノードの選定方法
■障害事例
→レプリケーションLAN障害(DRBD)
→レプリケーションLAN障害(PostgreSQLレプリケーション)
→インターコネクトLANとレプリケーションLAN障害(DRBD)
■まとめ

ページリンク

→OSC2014 Tokyo →PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション)