1 製品の概要 #
SUSE® Linux Enterprise High Availabilityは、オープンソースクラスタリング技術の統合スイートです。これにより、高可用性の物理および仮想Linuxクラスタを実装し、シングルポイント障害を排除することができます。データ、アプリケーション、サービスなどの重要なネットワークリソースの高度な可用性と管理のしやすさを実現します。その結果、ミッションクリティカルなLinuxワークロードに対してビジネスの継続性維持、データ整合性の保護、予期せぬダウンタイムの削減を行います。
基本的な監視、メッセージング、およびクラスタリソース管理の機能を標準装備し、個々の管理対象クラスタリソースのフェールオーバー、フェールバック、およびマイグレーション(負荷分散)をサポートします。
この章では、製品の主な機能およびSUSE Linux Enterprise High Availabilityの利点を紹介します。ここには、いくつかのクラスタ例が記載されており、クラスタを設定するコンポーネントについて学ぶことができます。最後のセクションでは、アーキテクチャの概要を示し、クラスタ内の個々のアーキテクチャ層とプロセスについて説明します。
High Availabilityクラスタのコンテキストでよく使用される用語については、用語集を参照してください。
1.1 モジュールとしてまたは拡張機能として使用可能 #
高可用性は、複数の製品でモジュールとしてまたは拡張機能として使用できます。詳細については、https://documentation.suse.com/sles/html/SLES-all/article-modules.html#art-modules-high-availabilityを参照してください。
1.2 主な特長 #
SUSE® Linux Enterprise High Availabilityでは、ネットワークリソースの可用性を確保し、管理することができます。以降のセクションでは、いくつかの主要機能に焦点を合わせて説明します。
1.2.1 広範なクラスタリングシナリオ #
SUSE Linux Enterprise High Availabilityは次のシナリオをサポートします。
アクティブ/アクティブ設定
アクティブ/パッシブ設定: N+1、N+M、Nから1、NからM
ハイブリッド物理仮想クラスタ。仮想サーバを物理サーバとともにクラスタ化できます。これによって、サービスの可用性とリソースの使用状況が向上します。
ローカルクラスタ
メトロクラスタ(「ストレッチされた」ローカルクラスタ)
Geoクラスタ(地理的に離れたクラスタ)
クラスタに属するすべてのノードは、同じプロセッサプラットフォーム(x86、IBM Z、またはPOWER)を備えている必要があります。混在アーキテクチャのクラスタはサポートされて「いません」。
クラスタには、最大32のLinuxサーバを含めることができます。pacemaker_remoteを使用すると、この制限を超えて追加のLinuxサーバを含めるようにクラスタを拡張できます。クラスタ内のどのサーバも、クラスタ内の障害が発生したサーバのリソース(アプリケーション、サービス、IPアドレス、およびファイルシステム)を再起動することができます。
1.2.2 柔軟性 #
SUSE Linux Enterprise High Availabilityには、Corosyncメッセージングおよびメンバーシップ層のほか、Pacemakerクラスタリソースマネージャが標準装備されています。管理者は、Pacemakerを使用して、リソースのヘルスと状態を継続的に監視し、依存関係を管理することができます。高度に設定可能なルールとポリシーに基づいて、サービスを自動的に停止および開始することができます。SUSE Linux Enterprise High Availabilityでは、ユーザの組織に適した特定のアプリケーションおよびハードウェアインフラストラクチャに合わせて、クラスタのカスタマイズが可能です。時間依存設定を使用して、サービスを特定の時刻に修復済みのノードに自動的にフェールバック(マイグレート)させることができます。
1.2.3 ストレージとデータレプリケーション #
SUSE Linux Enterprise High Availabilityでは必要に応じてサーバストレージを動的に割り当ておよび再割り当てできます。ファイバチャネルまたはiSCSIストレージエリアネットワーク(SAN)をサポートしています。共有ディスクもサポートされていますが、必要要件ではありません。SUSE Linux Enterprise High Availabilityには、クラスタ対応のファイルシステム(OCFS2)とCluster Logical Volume Manager (Cluster LVM)も含まれています。データをレプリケーションする場合は、DRBD*を使用して、High Availabilityサービスのデータをクラスタのアクティブノードからスタンバイノードへミラーリングします。さらに、SUSE Linux Enterprise High Availabilityでは、Sambaクラスタリング技術であるCTDB (Cluster Trivial Database)もサポートしています。
1.2.4 仮想化環境のサポート #
SUSE Linux Enterprise High Availabilityは、物理Linuxサーバと仮想Linuxサーバの混合クラスタリングをサポートしています。SUSE Linux Enterprise Server 15 SP6には、オープンソースの仮想化ハイパーバイザであるXenと、KVM (カーネルベースの仮想マシン)が付属しています。KVMは、ハードウェア仮想化の拡張機能に基づいた、Linux用の仮想化ソフトウェアです。SUSE Linux Enterprise High Availability内のクラスタリソースマネージャは、仮想サーバ内で実行中のサービスと物理サーバ内で実行中のサービスを認識、監視、および管理できます。ゲストシステムは、クラスタにサービスとして管理されます。
アクティブクラスタでノードのライブマイグレーションを実行するときには注意してください。クラスタスタックは、ライブマイグレーションプロセスに起因するオペレーティングシステムのフリーズに耐えることができない場合があり、結果として、ノードがフェンシングされる可能性があります。
次のいずれかのアクションを実行してライブマイグレーション中のノードのフェンシングを回避することをお勧めします。
CorosyncトークンのタイムアウトおよびSBDウォッチドッグのタイムアウトを増やし、その他の関連設定を調整します。適切な値は個別の設定によって異なります。詳細については、13.5項 「タイムアウトの計算」を参照してください。
ライブマイグレーションを実行する前に、ノードまたはクラスタ全体のいずれかでクラスタサービスを停止します。詳細については、28.2項 「保守タスクのためのさまざまなオプション」を参照してください。
運用環境でライブマイグレーションを試す前に、この設定を十分にテストする必要があります。
1.2.5 ローカル、メトロ、およびGeoクラスタのサポート #
SUSE Linux Enterprise High Availabilityは、地理的に分散したクラスタ(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には、Apache、IPv4、IPv6、その他多数のリソースを管理するための多数のリソースエージェントが含まれています。またIBM WebSphere Application Serverなどの一般的なサードパーティアプリケーション用のリソースエージェントも含まれています。ご利用の製品に含まれているOpen Cluster Framework (OCF)リソースエージェントの概要は、crm
raで説明される5.5.4項 「OCFリソースエージェントに関する情報の表示」コマンドを使用してください。
1.2.7 ユーザフレンドリな管理ツール #
SUSE Linux Enterprise High Availabilityには、強力なツールセットが付属しています。クラスタの基本的なインストールとセットアップ、および効果的な設定と管理のためにこれらのツールを使用してください。
- YaST
一般的なシステムインストールおよび管理用グラフィカルユーザインタフェース。『インストールとセットアップクイックスタート』で説明されているように、YaSTを使用して、SUSE Linux Enterprise High AvailabilityをSUSE Linux Enterprise Server上にインストールします。YaSTでは、クラスタまたは個々のコンポーネントの設定に役立つように、High Availabilityカテゴリ内の次のモジュールも提供しています。
クラスタ: 基本的なクラスタセットアップ。詳細については、第4章 「YaSTクラスタモジュールの使用」を参照してください。
DRBD: Distributed Replicated Block Deviceの設定。
IP負荷分散: Linux仮想サーバまたはHAProxyによる負荷分散の設定。詳細については、第17章 「負荷分散」を参照してください。
- Hawk2
High AvailabilityクラスタをLinuxまたは非Linuxマシンから同様に監視および管理することができる、ユーザフレンドリなWebベースのインタフェース。Hawk2には、(グラフィカルな)Webブラウザを使用して、クラスタの内部または外部の任意のマシンからアクセスできます。したがって、使用しているシステムが最小限のグラフィカルユーザインタフェースしか提供していない場合でも、理想的なソリューションとなります。詳細については、5.4項 「Hawk2の概要」を参照してください。
crmシェルリソースを設定し、すべての監視または管理作業を実行する、統合されたパワフルなコマンドラインインタフェースです。詳細については、5.5項 「crmshの概要」を参照してください。
1.3 利点 #
SUSE Linux Enterprise High Availabilityを使用すると、最大32台のLinuxサーバを高可用性クラスタ(HAクラスタ)に設定できます。リソースを動的に切り替えたり、クラスタ内の任意のノードに移動することができます。ノード障害発生時のリソースの自動マイグレーションの設定ができます。また、ハードウェアのトラブルシューティングやワークロードのバランスをとるために、リソースを手動で移動することもできます。
SUSE Linux Enterprise High Availabilityは、一般的なコンポーネントを利用して高可用性を提供します。アプリケーションと操作をクラスタに統合することによって、運用コストを削減できます。SUSE Linux Enterprise High Availabilityを使用すると、クラスタ全体を一元的に管理することも可能です。変化するワークロード要件に合わせてリソースを調整する(つまり、手動でクラスタを「負荷分散」する)ことができます。3ノード以上でクラスタを設定すると、複数のノードが「ホットスペア」を共用できて無駄がありません。
その他にも重要な利点として、予測できないサービス停止を削減したり、ソフトウェアおよびハードウェアの保守やアップグレードのための計画的なサービス停止を削減できる点が挙げられます。
次に、クラスタによるメリットについて説明します。
可用性の向上
パフォーマンスの改善
運用コストの低減
拡張性
障害回復
データの保護
サーバの集約
ストレージの集約
共有ディスクサブシステムにRAID を導入することによって、共有ディスクの耐障害性を強化できます。
次のシナリオは、SUSE Linux Enterprise High Availabilityが提供可能な利点を示しています。
クラスタシナリオ例#
ノード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ソフトウェアは次の処理を実行しました。
障害を検出し、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に戻すと、ある程度のダウンタイムが生じます。このため、SUSE Linux Enterprise High Availabilityでは、サービスの中断がほとんどまたはまったく発生しなくなるまで、マイグレーションを延期することもできます。いずれの場合でも利点と欠点があります。
SUSE Linux Enterprise High Availabilityには、リソースマイグレーション機能も用意されています。システム管理の必要に応じて、アプリケーション、Webサイトなどをクラスタ内の他のサーバに移動できます。
たとえば、WebサイトAまたはWebサイトBをWebサーバ1からクラスタ内の他のサーバに手動で移動することができます。これは、Webサーバ1のアップグレードや定期メンテナンスを実施する場合、また、Webサイトのパフォーマンスやアクセスを向上させる場合に有効な機能です。
1.4 クラスタ設定: ストレージ #
SUSE Linux Enterprise High Availabilityでのクラスタ設定には、共有ディスクサブシステムが含まれる場合と含まれない場合があります。共有ディスクサブシステムの接続には、高速ファイバチャネルカード、ケーブル、およびスイッチを使用でき、また設定にはiSCSIを使用することができます。ノードの障害時には、クラスタ内の別の指定されたノードが、障害の発生したノードにマウントされていた共有ディスクディレクトリを自動的にマウントします。この機能によって、ネットワークユーザは、共有ディスクサブシステム上のディレクトリに対するアクセスを中断することなく実行できます。
共有ディスクサブシステムをLVMと使用する場合、クラスタ内の、アクセスが必要なすべてのサーバにそのサブシステムを接続する必要があります。
一般的なリソースの例としては、データ、アプリケーション、およびサービスなどがあります。次の図は、一般的なファイバチャネルクラスタの設定を表したものです。緑色の線は、Ethernet電源スイッチへの接続を示しています。このようなデバイスは、ネットワークを介して制御することが可能であり、ping要求が失敗したときにノードを再起動することができます。
ファイバチャネルは最も高いパフォーマンスを提供しますが、iSCSIを利用するようにクラスタを設定することもできます。iSCSIは低コストなストレージエリアネットワーク(SAN)を作成するための方法として、ファイバチャネルの代わりに使用できます。次の図は、一般的なiSCSIクラスタの設定を表したものです。
ほとんどのクラスタには共有ディスクサブシステムが含まれていますが、共有ディスクサブシステムなしのクラスタを作成することもできます。次の図は、共有ディスクサブシステムなしのクラスタを表したものです。
1.5 アーキテクチャ #
このセクションでは、SUSE Linux Enterprise High Availabilityのアーキテクチャの概要について簡単に説明します。アーキテクチャコンポーネントと、その相互運用方法について説明します。
1.5.1 アーキテクチャ層 #
SUSE Linux Enterprise High Availabilityでは、アーキテクチャが階層化されています。図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の変更を複製します。
pacemaker-schedulerdは、CIBの情報に基づいて、クラスタの理想的な状態とその達成方法を計算します。命令のリストをDCにフィードします。DCはメッセージング/インフラストラクチャ層を介してコマンドを送信し、他のノードのpacemaker-controldピアがこれらのコマンドを受信します。それぞれのピアは、ローカルでリソースエージェントエグゼキュータ(pacemaker-execd)を使用してリソースに変更を加えます。pacemaker-execdはクラスタに対応しておらず、リソースエージェントと直接通信します。
すべてのピアノードは操作結果をDCに返送します。DCが、すべての必要な操作がクラスタ内で成功したことを確認すると、クラスタはアイドル状態に戻り、次のイベントを待機します。予定どおり実行されなかった操作があれば、CIBに記録された新しい情報を基に、pacemaker-schedulerdを再度呼び出します。
場合によっては、共有データの保護や完全なリソース復旧のためにノードの電源を切らなければならないことがあります。Pacemakerクラスタにおけるノードレベルフェンシングの実装は、STONITHです。このPacemakerにはフェンシングサブシステムpacemaker-fencedが内蔵されています。STONITHデバイスは、(特定のフェンシングエージェントを使用する)クラスタリソースとして設定する必要があります。これにより、フェンシングデバイスの監視が可能になるからです。クライアントは障害を検出すると、pacemaker-fencedへ要求を送信します。このデーモンはフェンシングエージェントを実行することにより、ノードを停止します。