1 製品の概要 #
SUSE® Linux Enterprise High Availability Extensionは、オープンソースクラスタリング技術の統合スイートです。これにより、高可用性の物理および仮想Linuxクラスタを実装し、シングルポイント障害を排除することができます。データ、アプリケーション、サービスなどの重要なネットワークリソースの高度な可用性と管理のしやすさを実現します。その結果、ミッションクリティカルなLinuxワークロードに対してビジネスの継続性維持、データ整合性の保護、予期せぬダウンタイムの削減を行います。
基本的な監視、メッセージング、およびクラスタリソース管理の機能を標準装備し、個々の管理対象クラスタリソースのフェールオーバー、フェールバック、およびマイグレーション(負荷分散)をサポートします。
この章では、High Availability Extensionの主な製品機能と利点を紹介します。ここには、いくつかのクラスタ例が記載されており、クラスタを設定するコンポーネントについて学ぶことができます。最後のセクションでは、アーキテクチャの概要を示し、クラスタ内の個々のアーキテクチャ層とプロセスについて説明します。
High Availabilityクラスタのコンテキストでよく使用される用語については、用語集を参照してください。
1.1 拡張としての提供 #
High Availability Extensionは、SUSE Linux Enterprise Server 15 SP4の拡張として入手できます。
1.2 主な特長 #
SUSE® Linux Enterprise High Availability Extensionでは、ネットワークリソースの可用性を確保し、管理することができます。以降のセクションでは、いくつかの主要機能に焦点を合わせて説明します。
1.2.1 広範なクラスタリングシナリオ #
High Availability Extensionは次のシナリオをサポートしています。
アクティブ/アクティブ設定
アクティブ/パッシブ設定: N+1、N+M、Nから1、NからM
ハイブリッド物理仮想クラスタ。仮想サーバを物理サーバとともにクラスタ化できます。これによって、サービスの可用性とリソースの使用状況が向上します。
ローカルクラスタ
メトロクラスタ(「ストレッチされた」ローカルクラスタ)
Geoクラスタ(地理的に離れたクラスタ)
クラスタに属するすべてのノードは、同じプロセッサプラットフォーム(x86、IBM Z、またはPOWER)を備えている必要があります。混在アーキテクチャのクラスタはサポートされて「いません」。
クラスタには、最大32のLinuxサーバを含めることができます。pacemaker_remoteを使用すると、この制限を超えて追加のLinuxサーバを含めるようにクラスタを拡張できます。クラスタ内のどのサーバも、クラスタ内の障害が発生したサーバのリソース(アプリケーション、サービス、IPアドレス、およびファイルシステム)を再起動することができます。
1.2.2 柔軟性 #
High Availability Extensionには、Corosyncメッセージングおよびメンバーシップ層のほか、Pacemakerクラスタリソースマネージャが標準装備されています。管理者は、Pacemakerを使用して、リソースのヘルスと状態を継続的に監視し、依存関係を管理することができます。高度に設定可能なルールとポリシーに基づいて、サービスを自動的に停止および開始することができます。High Availability Extensionでは、ユーザの組織に適した特定のアプリケーションおよびハードウェアインフラストラクチャに合わせて、クラスタのカスタマイズが可能です。時間依存設定を使用して、サービスを特定の時刻に修復済みのノードに自動的にフェールバック(マイグレート)させることができます。
1.2.3 ストレージとデータレプリケーション #
High Availability Extensionでは必要に応じてサーバストレージを自動的に割り当て、再割り当てすることができます。ファイバチャネルまたはiSCSIストレージエリアネットワーク(SAN)をサポートしています。共有ディスクもサポートされていますが、必要要件ではありません。SUSE Linux Enterprise High Availability Extensionには、クラスタ対応のファイルシステム(OCFS2)とCluster Logical Volume Manager (Cluster LVM2)も含まれています。データをレプリケーションする場合は、DRBD*を使用して、High Availabilityサービスのデータをクラスタのアクティブノードからスタンバイノードへミラーリングします。さらに、SUSE Linux Enterprise High Availability Extensionでは、Sambaクラスタリング技術であるCTDB (Cluster Trivial Database)もサポートしています。
1.2.4 仮想化環境のサポート #
SUSE Linux Enterprise High Availability Extensionは、物理Linuxサーバと仮想Linuxサーバの混合クラスタリングをサポートしています。SUSE Linux Enterprise Server 15 SP4には、オープンソースの仮想化ハイパーバイザであるXenと、KVM (カーネルベースの仮想マシン)が付属しています。KVMは、ハードウェア仮想化の拡張機能に基づいた、Linux用の仮想化ソフトウェアです。High Availability Extension内のクラスタリソースマネージャは、仮想サーバで実行中のサービスと物理サーバで実行中のサービスを認識、監視、および管理できます。ゲストシステムは、クラスタにサービスとして管理されます。
1.2.5 ローカル、メトロ、およびGeoクラスタのサポート #
SUSE Linux Enterprise High Availability Extensionは、地理的に分散したクラスタ(Geoクラスタ)を含むさまざまな地理的シナリオをサポートします。
- ローカルクラスタ
1つのロケーション内の単一のクラスタ(たとえば、すべてのノードが1つのデータセンターにある)。クラスタはノード間の通信にマルチキャストまたはユニキャストを使用し、フェールオーバーを内部で管理します。ネットワークの遅延時間は無視できます。ストレージは通常、すべてのノードに同時にアクセスされます。
- メトロクラスタ
すべてのサイトがファイバチャネルで接続された、複数の建物またはデータセンターにわたってストレッチできる単一のクラスタ。クラスタはノード間の通信にマルチキャストまたはユニキャストを使用し、フェールオーバーを内部で管理します。ネットワークの遅延時間は通常は短くなります(約20マイルの距離で5ms未満)。ネットワークのレイテンシは通常は短くなります(約20マイルの距離で<5ms)。ストレージは頻繁にレプリケートされます(ミラーリングまたは同期レプリケーション)
- Geoクラスタ(マルチサイトクラスタ)
それぞれにローカルクラスタを持つ、複数の地理的に離れたサイト。サイトはIPによって交信します。サイト全体のフェールオーバーはより高いレベルのエンティティによって調整されます。Geoクラスタは限られたネットワーク帯域幅および高レイテンシに対応する必要があります。ストレージは同期的にレプリケートされます。
注記: GeoクラスタリングとSAPワークロード現在、Geoクラスタは、SAP HANAシステムレプリケーションも、SAP S/4HANAおよびSAP NetWeaverエンキューレプリケーションセットアップもサポートしていません。
個々のクラスタノード間の地理的距離が大きいほど、クラスタが提供するサービスの高可用性を妨げる可能性のある要因が多くなります。ネットワークの遅延時間、限られた帯域幅およびストレージへのアクセス が長距離クラスタの課題として残ります。
1.2.6 リソースエージェント #
SUSE Linux Enterprise High Availability Extensionには、Apache、IPv4、IPv6、その他多数のリソースを管理するための膨大な数のリソースエージェントが含まれています。またIBM WebSphere Application Serverなどの一般的なサードパーティアプリケーション用のリソースエージェントも含まれています。ご利用の製品に含まれているOpen Cluster Framework (OCF)リソースエージェントの概要は、8.1.3項 「OCFリソースエージェントに関する情報の表示」で説明されるcrm raコマンドを使用してください。
1.2.7 ユーザフレンドリな管理ツール #
High Availability Extensionには、一連の強力なツールが付属しています。クラスタの基本的なインストールとセットアップ、および効果的な設定と管理のためにこれらのツールを使用してください。
- YaST
一般的なシステムインストールおよび管理用グラフィカルユーザインタフェース。『インストールおよびセットアップクイックスタート』で説明されているように、YaSTを使用して、High Availability ExtensionをSUSE Linux Enterprise Server上にインストールします。YaSTでは、クラスタまたは個々のコンポーネントの設定に役立つように、High Availabilityカテゴリ内の次のモジュールも提供しています。
クラスタ: 基本的なクラスタセットアップ。詳細については、第4章 「YaSTクラスタモジュールの使用」を参照してください。
DRBD: Distributed Replicated Block Deviceの設定。
IP負荷分散: Linux仮想サーバまたはHAProxyによる負荷分散の設定。詳細については、第15章 「負荷分散」を参照してください。
- Hawk2
High AvailabilityクラスタをLinuxまたは非Linuxマシンから同様に監視および管理することができる、ユーザフレンドリなWebベースのインタフェース。Hawk2には、(グラフィカルな)Webブラウザを使用して、クラスタの内部または外部の任意のマシンからアクセスできます。したがって、使用しているシステムが最小限のグラフィカルユーザインタフェースしか提供していない場合でも、理想的なソリューションとなります。詳細については、第7章 「Hawk2を使用したクラスタリソースの設定と管理」を参照してください。
crmシェルリソースを設定し、すべての監視または管理作業を実行する、統合されたパワフルなコマンドラインインタフェースです。詳細については、第8章 「クラスタリソースの設定と管理(コマンドライン)」を参照してください。
1.3 利点 #
High Availability Extensionを使用すると、最大32台のLinuxサーバを高可用性クラスタ(HAクラスタ)に設定できます。リソースを動的に切り替えたり、クラスタ内の任意のノードに移動することができます。ノード障害発生時のリソースの自動マイグレーションの設定ができます。また、ハードウェアのトラブルシューティングやワークロードのバランスをとるために、リソースを手動で移動することもできます。
High Availability Extensionは、コモディティコンポーネントによる高可用性を提供しています。アプリケーションと操作をクラスタに統合することによって、運用コストを削減できます。High Availability Extensionを使用すると、クラスタ全体を一元的に管理することもできます。変化するワークロード要件に合わせてリソースを調整する(つまり、手動でクラスタを「負荷分散」する)ことができます。3ノード以上でクラスタを設定すると、複数のノードが「ホットスペア」を共用できて無駄がありません。
その他にも重要な利点として、予測できないサービス停止を削減したり、ソフトウェアおよびハードウェアの保守やアップグレードのための計画的なサービス停止を削減できる点が挙げられます。
次に、クラスタによるメリットについて説明します。
可用性の向上
パフォーマンスの改善
運用コストの低減
拡張性
障害回復
データの保護
サーバの集約
ストレージの集約
共有ディスクサブシステムにRAID を導入することによって、共有ディスクの耐障害性を強化できます。
次のシナリオは、High Availability Extensionの利点を紹介するものです。
クラスタシナリオ例#
ノード3台でクラスタが設定され、それぞれのノードにWebサーバをインストールしたと仮定します。クラスタ内の各ノードが、2つのWebサイトをホストしています。各Webサイトのすべてのデータ、グラフィックス、Webページコンテンツは、クラスタ内の各ノードに接続された、共有ディスクサブシステムに保存されています。次の図は、このクラスタのセットアップを示しています。
通常のクラスタ操作では、クラスタ内の各ノードが他のノードと常に交信し、すべての登録済みリソースを定期的にポーリングして、障害を検出します。
Webサーバ1でハードウェアまたはソフトウェアの障害が発生したため、このサーバを利用してインターネットアクセス、電子メール、および情報収集を行っているユーザの接続が切断されたとします。次の図は、Webサーバ1で障害が発生した場合のリソースの移動を表したものです。
WebサイトAがWebサーバ2に、WebサイトBがWebサーバ3に移動します。IPアドレスと証明書もWebサーバ2とWebサーバ3に移動します。
クラスタを設定するときに、それぞれのWebサーバがホストしているWebサイトについて、障害発生時の移動先を指定します。先に説明した例では、WebサイトAの移動先としてWebサーバ2が、WebサイトBの移動先としてWebサーバ3が指定されています。このようにして、Webサーバ 1によって処理されていたワークロードが、残りのクラスタメンバーに均等に分散され、可用性を維持できます。
Webサーバ1で障害が発生すると、High Availability Extensionソフトウェアは次の処理を実行します。
障害を検出し、Webサーバ 1が本当に機能しなくなっていることをSTONITHを使用して検証。STONITHは「Shoot The Other Node In The Head」の略です。これは、動作異常のノードを停止することでクラスタに問題を発生させないようにする手段です。
Webサーバ1にマウントされていた共有データディレクトリを、Webサーバ2およびWebサーバ3に再マウント。
Webサーバ1で動作していたアプリケーションを、Webサーバ2およびWebサーバ3で再起動。.
IPアドレスをWebサーバ2およびWebサーバ3に移動。
この例では、フェールオーバープロセスが迅速に実行され、ユーザはWebサイトの情報へのアクセスを数秒程度で回復できます。通常、再度ログインする必要はありません。
ここで、Webサーバ1で発生した問題が解決し、通常に操作できる状態に戻ったと仮定します。WebサイトAおよびWebサイトBは、Webサーバ1に自動的にフェールバック(復帰)することも、そのままの状態を維持することもできます。これは、リソースの設定方法によって決まります。サービスをWebサーバ1に戻すと、ある程度のダウンタイムが生じます。このため、High Availability Extensionでは、サービスの中断がほとんどまたはまったく発生しなくなるまで、マイグレーションを延期することもできます。いずれの場合でも利点と欠点があります。
High Availability Extensionは、リソースマイグレーション機能も提供します。システム管理の必要に応じて、アプリケーション、Webサイトなどをクラスタ内の他のサーバに移動できます。
たとえば、WebサイトAまたはWebサイトBをWebサーバ1からクラスタ内の他のサーバに手動で移動することができます。これは、Webサーバ1のアップグレードや定期メンテナンスを実施する場合、また、Webサイトのパフォーマンスやアクセスを向上させる場合に有効な機能です。
1.4 クラスタ設定: ストレージ #
High Availability Extensionでのクラスタ構成には、共有ディスクサブシステムが含まれる場合と含まれない場合があります。共有ディスクサブシステムの接続には、高速ファイバチャネルカード、ケーブル、およびスイッチを使用でき、また設定にはiSCSIを使用することができます。ノードの障害時には、クラスタ内の別の指定されたノードが、障害の発生したノードにマウントされていた共有ディスクディレクトリを自動的にマウントします。この機能によって、ネットワークユーザは、共有ディスクサブシステム上のディレクトリに対するアクセスを中断することなく実行できます。
共有ディスクサブシステムをLVM2と使用する場合、クラスタ内の、アクセスが必要なすべてのサーバにそのサブシステムを接続する必要があります。
一般的なリソースの例としては、データ、アプリケーション、およびサービスなどがあります。次の図は、一般的なファイバチャネルクラスタの設定を表したものです。緑色の線は、Ethernet電源スイッチへの接続を示しています。このようなデバイスは、ネットワークを介して制御することが可能であり、ping要求が失敗したときにノードを再起動することができます。
ファイバチャネルは最も高いパフォーマンスを提供しますが、iSCSIを利用するようにクラスタを設定することもできます。iSCSIは低コストなストレージエリアネットワーク(SAN)を作成するための方法として、ファイバチャネルの代わりに使用できます。次の図は、一般的なiSCSIクラスタの設定を表したものです。
ほとんどのクラスタには共有ディスクサブシステムが含まれていますが、共有ディスクサブシステムなしのクラスタを作成することもできます。次の図は、共有ディスクサブシステムなしのクラスタを表したものです。
1.5 アーキテクチャ #
このセクションでは、High Availability Extensionアーキテクチャの概要を説明します。アーキテクチャコンポーネントと、その相互運用方法について説明します。
1.5.1 アーキテクチャ層 #
High Availability Extensionのアーキテクチャは層化されています。図1.6「アーキテクチャ」に異なる層と関連するコンポーネントを示します。
1.5.1.1 メンバーシップとメッセージング層(Corosync) #
このコンポーネントは、クラスタのメッセージング、メンバーシップ、クォーラムに関する信頼性の高い情報を提供します。具体的には、グループ通信システムであるCorosyncクラスタエンジンがその処理を担っています。
1.5.1.2 クラスタリソースマネージャ(Pacemaker) #
クラスタリソースマネージャであるPacemakerは、クラスタ内で発生したイベントへの対応を司る「頭脳」です。これは、あらゆるアクションを統括するpacemaker-controldクラスタコントローラとして実装されます。イベントとは、クラスタにおけるノードの加入と離脱、リソースでの障害発生、保守などの計画的なアクティビティのことを指します。
- ローカルリソースマネージャ
ローカルリソースマネージャは、各ノードのPacemaker層とリソース層の間に存在し、
pacemaker-execdデーモンとして実装されます。このデーモンにより、Pacemakerでのリソースの起動、停止、監視が可能になります。- CIB (クラスタ情報データベース)
Pacemakerは、ノードごとにCIBを保持しています。CIBとは、クラスタ設定のXML表現のことで、クラスタの各オプション、ノード、リソース、制約、個々の要素間の関係性などが記述されています。CIBには、現在のクラスタのステータスも反映されます。各クラスタノードにはCIBレプリカが配置され、クラスタ全体との同期がとられます。クラスタの設定とステータスの読み書きは、
pacemaker-basedデーモンが行います。- DC (指定コーディネータ)
DCは、クラスタ内にあるすべてのノードの中から選択されます。この操作は、DCがまだ指定されていない場合や、現在のDCがなんらかの理由でクラスタを離脱した場合に行われます。DCは、ノードのフェンシングやリソースの移動など、クラスタ全体におよぶ変更が必要かどうかを判断できる、クラスタ内で唯一のエンティティです。その他すべてのノードは、現在のDCから設定とリソース割り当て情報を取得します。
- ポリシーエンジン
ポリシーエンジンはすべてのノードで実行できますが、DC上にあるものだけがアクティブになります。このエンジンは
pacemaker-schedulerdデーモンとして実装されます。クラスタ遷移が必要になると、pacemaker-schedulerdはクラスタの現在の状態と設定を基に、クラスタの次の状態を計算します。また、次の状態を達成するためにどんなアクションを行う必要があるかも決定します。
1.5.1.3 リソースおよびリソースエージェント #
高可用性を備えたクラスタでは、高い可用性を維持し続ける必要があるサービスのことを「リソース」と呼びます。RA (リソースエージェント)とは、これらのクラスタリソースの起動、停止、監視に使用されるスクリプトのことです。
1.5.2 プロセスフロー #
pacemakerdデーモンは、その他のあらゆる関連デーモンの起動と監視を行います。pacemaker-controldデーモンはすべてのアクションを統括し、自身のインスタンスを各クラスタノードに配置します。Pacemakerは、プライマリとして動作するインスタンスを1つ選択することにより、クラスタのすべての意思決定を一元化します。選択したpacemaker-controldデーモンで障害が発生する場合は、新たなプライマリがマスタになります。
クラスタ内で実行するアクションの多くは、クラスタ全体におよぶ変更を伴います。これらのアクションにはクラスタリソースの追加や削除、リソース制約の変更などがあります。このようなアクションを実行する場合は、クラスタ内でどのような変化が発生するのかを理解することが重要です。
たとえば、クラスタIPアドレスリソースを追加するとします。そのためには、crmシェルかWebインタフェースを使用してCIBを変更できます。DCでアクションを実行する必要はありません。クラスタの任意のノードでいずれかのツールを使用して、DCにリレーされます。そして、DCがすべてのクラスタノードにCIBの変更を複製します。
このときは、CIBの情報に基づいて、pacemaker-schedulerdがクラスタの理想的な状態とその達成方法を計算し、命令のリストをDCにフィードします。DCはメッセージング/インフラストラクチャ層を介してコマンドを送信し、他のノードのpacemaker-controldピアがこれらのコマンドを受信します。それぞれのピアは、ローカルでリソースエージェントエグゼキュータ(pacemaker-execd)を使用してリソースに変更を加えます。pacemaker-execdはクラスタに対応しておらず、リソースエージェントと直接通信します。
すべてのピアノードは操作結果をDCに返送します。DCが、すべての必要な操作がクラスタ内で成功したことを確認すると、クラスタはアイドル状態に戻り、次のイベントを待機します。予定通り実行されなかった操作があれば、CIBに記録された新しい情報を基に、pacemaker-schedulerdを再度呼び出します。
場合によっては、共有データの保護や完全なリソース復旧のためにノードの電源を切らなければならないことがあります。Pacemakerクラスタにおけるノードレベルフェンシングの実装は、STONITHです。このPacemakerにはフェンシングサブシステムpacemaker-fencedが内蔵されています。STONITHデバイスは、(特定のフェンシングエージェントを使用する)クラスタリソースとして設定する必要があります。これにより、フェンシングデバイスの監視が可能になるからです。クライアントは障害を検出すると、pacemaker-fencedへ要求を送信します。このデーモンはフェンシングエージェントを実行することにより、ノードを停止します。