HAクラスタの主な目的はユーザサービスの管理です。ユーザサービスの典型的な例は、Apache Webサーバまたはデータベースです。サービスとは、ユーザの観点からすると、指示に基づいて特別な何かを行うことを意味していますが、クラスタにとっては開始や停止できるリソースにすぎません。サービスの性質はクラスタには無関係なのです。
この章では、リソースを設定しクラスタを管理する場合に知っておく必要のある基本概念を紹介します。後続の章では、High Availability Extensionが提供する各管理ツールを使用して、主要な設定および管理タスクを行う方法を説明します。
一般的に、クラスタは次の2つのカテゴリのいずれかに分類されます。
2ノードクラスタ
2ノードより多いクラスタ。これは通常、奇数のノード数を意味します。
異なるトポロジを追加して、異なるユースケースを生成することもできます。次のユースケースは最も一般的です。
設定: FC SANまたは同様の共有ストレージ、レイヤ2ネットワーク。
使用シナリオ: サービスの高可用性、およびデータレプリケーションのデータ冗長性なしに焦点を当てた埋め込みクラスタ。このようなセットアップは無線ステーションや組立てラインコントローラなどに使用されます。
設定: 対称的なストレッチクラスタ、FC SAN、およびレイヤ2ネットワークのすべてが2つの場所に及ぶ。
使用シナリオ: サービスの高可用性、およびローカルデータの冗長性に焦点を当てた従来のストレッチクラスタ。データベースおよびエンタープライズリソース計画に適しており、ここ数年間で最も人気のあるセットアップの1つです。
設定: 2×N+1ノード、FC SANが2つの主な場所に及ぶ。FC SANを使用しない補助的な3番目のサイト、過半数メーカーとして機能する。レイヤ2ネットワーク、少なくとも2つの主な場所に及ぶ。
使用シナリオ: サービスの高可用性、およびデータの冗長性に焦点を当てた従来のストレッチクラスタ。たとえば、データベース、エンタープライズリソースプランニング。
1つ以上のノードとその他のクラスタ間で通信が失敗した場合は、常にクラスタパーティションが発生します。ノードは同じパーティション内の他のノードのみと通信可能で、切り離されたノードは認識しません。クラスタパーティションは、ノード(投票)の過半数を保有する場合、クォーラムを持つ(「定足数に達している」)と定義されます。これを実現する方法は「クォーラム計算」によって実行されます。クォーラムはフェンシングの要件です。
クォーラム計算はSUSE Linux Enterprise High Availability Extension 11とSUSE Linux Enterprise High Availability Extension 12の間で変更されました。SUSE Linux Enterprise High Availability Extension 11では、クォーラムはPacemakerによって計算されました。SUSE Linux Enterprise High Availability Extension 12以降では、CorosyncがPacemakerの設定を変更せずに直接2ノードクラスタのクォーラムを処理できます。
クォーラムの計算方法は、次のような要因によって影響されます。
実行中のサービスを継続させるため、2ノードを超えるクラスタはクラスタパーティションの解決においてクォーラム(過半数)に依存します。次の数式に基づき、クラスタが機能するために必要な動作ノードの最少数を計算できます。
N ≥ C/2 + 1 N = minimum number of operational nodes C = number of cluster nodes
たとえば、5ノードクラスタでは、最低3つの動作ノード(または障害が発生する可能性のある2ノード)が必要です。
2ノードクラスタまたは奇数のクラスタノードのいずれかを使用することを強くお勧めします。2ノードクラスタは、2サイト間のストレッチセットアップで重要です。奇数のノード数を持つクラスタは、1つのシングルサイトで構築するか、または3つのサイト間で分散させることができます。
Corosyncはメッセージングおよびメンバーシップ層です。6.2.4項 「2ノードクラスタのCorosync設定」および6.2.5項 「NノードクラスタのCorosync設定」を参照してください。
グローバルクラスタオプションは、一定の状況下でのクラスタの動作を制御します。それらは、セットにグループ化され、Hawk2やcrm
シェルなどのクラスタ管理ツールで表示したり、変更することができます。
事前に定義されている値は、通常は、そのまま保持できます。ただし、クラスタの主要機能を正しく機能させるには、クラスタの基本的なセットアップ後に、次のパラメータを調整する必要があります。
no-quorum-policy
#このグローバルオプションは、クラスタパーティションにクォーラムがない(ノードの過半数がパーティションに含まれない)場合どうするかを定義します。
許容値は、次のとおりです。
ignore
no-quorum-policy
をignore
に設定するとクラスタがクォーラムを持つように動作します。リソース管理は続行されます。
SLES 11では、この値が2ノードのクラスタ用の推奨設定でした。SLES 12以降、このオプションは廃止されました。設定と条件に基づいて、Corosyncはクラスタノードまたは単一ノードに「クォーラム」を与えます。または与えません。
2ノードのクラスタの場合、クォーラムが失われた場合の唯一の意味のある動作は、常に反応することです。最初のステップとして、クォーラムを失ったノードのフェンシングを試行してください。
freeze
クォーラムが失われた場合は、クラスタパーティションがフリーズします。リソース管理は続行されます。実行中のリソースは停止されません(ただし、イベントの監視に対応して再起動される可能性があります)。ただし、影響を受けたパーティション内では、以後のリソースが開始されません。
一定のリソースが他のノードとの通信に依存しているクラスタの場合(たとえば、OCFS2マウントなど)は、この設定が推奨されます。この場合、デフォルト設定no-quorum-policy=stop
は、次のようなシナリオになるので有効でありません。つまり、ピアノードが到達不能な間はそれらのリソースを停止できなくなります。その代わり、停止の試行は最終的にタイムアウトし、stop failure
になり、エスカレートされた復元とフェンシングを引き起こします。
stop
(デフォルト値)クォーラムが失われると、影響を受けるクラスタパーティション内のすべてのリソースが整然と停止します。
suicide
クォーラムが失われると、影響を受けるクラスタパーティション内のすべてのノードがフェンシングされます。このオプションは、SBDと組み合わせる場合にのみ機能します。第11章 「ストレージ保護とSBD」を参照してください。
stonith-enabled
#
このグローバルオプションは、フェンシングを適用して、STONITHデバイスによる、障害ノードや停止できないリソースを持つノードのダウンを許可するかどうか定義します。通常のクラスタ操作には、STONITHデバイスの使用が必要なので、このグローバルオプションは、デフォルトでtrue
に設定されています。デフォルト値では、クラスタは、STONITHリソースが定義されていない場合にはリソースの開始を拒否します。
何らかの理由でフェンシングを無効にする必要がある場合は、stonith-enabled
をfalse
に設定しますが、これはご使用の製品のサポートステータスに影響を及ぼすことに注意してください。また、stonith-enabled="false"
を指定すると、Distributed Lock Manager (DLM)のようなリソースやDLMによるすべてのサービス(cLVM、GFS2、OCFS2など)は開始できません。
STONITHがないクラスタはサポートされません。
ブートストラップスクリプトを使用する場合、Corosyn設定には次のオプションを持つquorum
セクションがあります。
quorum { # Enable and configure quorum subsystem (default: off) # see also corosync.conf.5 and votequorum.5 provider: corosync_votequorum expected_votes: 2 two_node: 1 }
SUSE Linux Enterprise 11とは反対に、SUSE Linux Enterprise 12のvotequorumサブシステムは、Corosyncバージョン2.xで機能します。つまり、no-quorum-policy=ignore
オプションは使用してはならないことを意味します。
デフォルトで、two_node: 1
が設定されている場合、wait_for_all
オプションが自動的に有効になります。wait_for_all
が有効でない場合、クラスタは両方のノードでパラレルに開始される必要があります。または、最初のノードが、見つからない2番目のノードで起動フェンシングを実行します。
2ノードクラスタを使用しない場合、Nノードクラスタに奇数のノードを使用することを強くお勧めします。クォーラム設定に関して、次のオプションがあります。
ha-cluster-join
コマンドを使用したノードの追加、または
Corosync設定の手動調整。
/etc/corosync/corosync.conf
を手動で調整する場合、次の設定を使用します。
quorum { provider: corosync_votequorum 1 expected_votes: N 2 wait_for_all: 1 3 }
Corosyncからのクォーラムサービスの使用 | |
予想される投票数。このパラメータは | |
wait for all (WFA)機能を有効にします。WFAが有効な場合、クラスタはすべてのノードが認識可能になった後でのみ定足数に達します。一部の起動時の競合状態を回避するために、 |
クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実行する各アプリケーションに対してクラスタリソースを作成する必要があります。クラスタリソースには、Webサイト、電子メールサーバ、データベース、ファイルシステム、仮想マシン、およびユーザが常時使用できるようにする他のサーバベースのアプリケーションまたはサービスなどが含まれます。
リソースは、クラスタで使用する前にセットアップする必要があります。たとえば、Apacheサーバをクラスタリソースとして使用するには、まず、Apacheサーバをセットアップし、Apacheの環境設定を完了してから、クラスタで個々のリソースを起動します。
リソースに特定の環境要件がある場合は、それらの要件がすべてのクラスタノードに存在し、同一であることを確認してください。この種の設定は、High Availability Extensionでは管理されません。これは、管理者自身が行う必要があります。
High Availability Extensionでリソースを管理しているときに、同じリソースを他の方法(クラスタ外で、たとえば、手動、ブート、再起動など)で開始したり、停止してはなりません。High Availability Extensionソフトウェアが、すべてのサービスの開始または停止アクションを実行します。
サービスがクラスタ制御下ですでに実行された後にテストまたは保守タスクを実行する必要がある場合は、リソース、ノード、またはクラスタ全体を保守モードに設定してから、これらのいずれかに手動でタッチしてください。詳細については、16.2項 「保守タスクのためのさまざまなオプション」を参照してください。
クラスタ内でリソースを設定したら、クラスタ管理ツールを使用して、すべてのリソースを手動で起動、停止、クリーンアップ、削除、または移行します。これらの操作の詳細については、使用しているクラスタ管理ツールに応じて次のいずれかを参照してください。
追加するクラスタリソースごとに、リソースエージェントが準拠する基準を定義する必要があります。リソースエージェントは、提供するサービスを抽象化して正確なステータスをクラスタに渡すので、クラスタは管理するリソースについてコミットする必要がありません。クラスタは、リソースエージェントに依存して、start、stop、またはmonitorのコマンドの発行に適宜対応します。
通常、リソースエージェントはシェルスクリプトの形式で配布されます。High Availability Extensionは、次のクラスのリソースエージェントをサポートしています。
OCF RAエージェントは、High Availabilityでの使用に最適であり、特に、マルチステートリソースまたは特殊なモニタリング機能を必要とする場合に適しています。それらのエージェントは、通常、/usr/lib/ocf/resource.d/provider
にあります。この機能はLSBスクリプトの機能と同様です。ただし、環境設定では、常に、パラメータの受け入れと処理を容易にする環境変数が使用されます。OCF仕様はhttps://github.com/ClusterLabs/OCF-spec/blob/master/ra/1.0/resource-agent-api.mdで参照できます(リソースエージェントに関連するため)。OCF仕様には、アクション終了コードの厳密な定義があります。9.3項 「OCF戻りコードと障害回復」を参照してください。クラスタは、それらの仕様に正確に準拠します。
すべてのOCFリソースエージェントは少なくともstart
、stop
、status
、monitor
、meta-data
のアクションを持つ必要があります。meta-data
アクションは、エージェントの設定方法についての情報を取得します。たとえば、プロバイダheartbeat
でIPaddr
エージェントの詳細を知りたい場合は、次のコマンドを使用します。
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/IPaddr meta-data
出力は、XML形式の情報であり、いくつかのセクションを含みます(一般説明、利用可能なパラメータ、エージェント用の利用可能なアクション)。
または、crmshを使用して、OCFリソースエージェントに関する情報を表示します。詳細については、8.1.3項 「OCFリソースエージェントに関する情報の表示」を参照してください。
LSBリソースエージェントは一般にオペレーティングシステム/配布パッケージによって提供され、/etc/init.d
にあります。リソースエージェントをクラスタで使用するには、それらのエージェントがLSB iniスクリプトの仕様に準拠している必要があります。たとえば、リソースエージェントには、いくつかのアクションが実装されている必要があります。それらのアクションとして、少なくともstart
、stop
、restart
、reload
、force-reload
、status
があります。詳細については、http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.htmlを参照してください。
これらのサービスの構成は標準化されていません。High AvailabilityでLSBスクリプトを使用する場合は、該当のスクリプトの設定方法を理解する必要があります。これに関する情報は、多くの場合、/usr/share/doc/packages/PACKAGENAME
内の該当パッケージのマニュアルに記載されています。
SUSE Linux Enterprise 12から、一般的なSystem V initデーモンがsystemdに置き代わりました。Pacemakerは、systemdサービスが存在する場合は、それを管理できます。initスクリプトの代わりに、systemdはユニットファイルを持ちます。一般的に、サービス(またはユニットファイル)は、オペレーティングシステムによって提供されます。既存のinitスクリプトを変換する場合は、http://0pointer.de/blog/projects/systemd-for-admins-3.htmlで詳細情報を検索してください。
現在、並列に存在する「通常」タイプのシステムサービスが多数あります: LSB
(System V initに属する)、systemd
、および(一部のディストリビューションでは) upstart
。そのため、Pacemakerは、どれが指定のクラスタノードに適用されるのかをインテリジェントに理解する特殊なエイリアスをサポートします。これは、クラスタにsystemd、upstart、およびLSBサービスが混在する場合には特に役立ちます。Pacemakerは、次の順番で指定されたサービスを検索しようとします: LSB (SYS-V) initスクリプト、systemdユニットファイル、またはUpstartジョブ。
モニタリングプラグイン(かつてはNagiosプラグインと呼ばれていた)により、リモートホスト上のサービスを監視できます。Pacemakerは、モニタリングプラグインが存在する場合は、これを使用してリモートモニタリングを実行できます。詳細については、6.6.1項 「監視プラグインを使用したリモートホストでのサービスの監視」を参照してください。
このクラスは、フェンシング関係のリソース専用に使用されます。詳細については、第10章 「フェンシングとSTONITH」を参照してください。
High Availability Extensionで提供されるエージェントは、OCF仕様に従って作成されています。
次のリソースタイプを作成できます。
プリミティブリソースは、リソースの中で最も基本的なタイプです。
選択したクラスタ管理ツールでプリミティブリソースを作成する方法については、次を参照してください。
Hawk2: 手順7.5「プリミティブリソースの追加」
crmsh: 8.4.2項 「クラスタリソースの作成」
グループには、一緒の場所で見つけ、連続して開始し、逆の順序で停止する必要のあるリソースセットが含まれます。詳細については、6.3.5.1項 「グループ」を参照してください。
クローンは、複数のホスト上でアクティブにできるリソースです。対応するリソースエージェントがサポートしていれば、どのようなリソースもクローン化できます。詳細については、6.3.5.2項 「クローン」を参照してください。
マルチステートリソースは、クローンリソースの特殊なタイプで、複数のモードを持つことができます。詳細については、6.3.5.3項 「マルチステートリソース」を参照してください。
類似した設定のリソースを多く作成する最も簡単な方法は、リソーステンプレートを定義することです。定義された後でテンプレートは、プリミティブ内で参照したり、6.5.3項 「リソーステンプレートと制約」で説明するように、特定のタイプの制約内で参照することができます。
プリミティブ内でテンプレートを参照すると、そのテンプレートで定義されている操作、インスタンス属性(パラメータ)、メタ属性、使用属性がすべてプリミティブに継承されます。さらに、プリミティブに対して特定の操作または属性を定義することもできます。これらのいずれかがテンプレートとプリミティブの両方で定義されていた場合、プリミティブで定義した値の方が、テンプレートで定義された値よりも優先されます。
選択したクラスタ管理ツールでリソーステンプレートを定義する方法については、次を参照してください。
Hawk2: 手順7.6「リソーステンプレートの追加」
crmsh: 8.4.3項 「リソーステンプレートの作成」
プリミティブは、最も単純なタイプのリソースなので、設定が容易ですが、クラスタ設定には、より高度なリソースタイプ(グループ、クローン、マルチステートリソースなど)が必要になることがあります。
クラスタリソースの中には、他のコンポーネントやリソースに依存しているものもあります。それぞれのコンポーネントやリソースが決められた順序で開始され、依存しているリソースと同じサーバ上で同時に実行していなければならない場合があります。この設定を簡素化するには、クラスタリソースグループを使用できます。
リソースグループの1例として、IPアドレスとファイルシステムを必要とするWebサーバがあります。この場合、各コンポーネントは、個々のリソースであり、それらが組み合わされてクラスタリソースグループを構成します。リソースグループは、1つ以上のサーバで実行されます。ソフトウェアまたはハードウェアが機能しない場合には、個々のクラスタリソースと同様に、グループはクラスタ内の別のサーバにフェールオーバーします。
グループには次のプロパティがあります。
リソースは認識される順序で開始し、逆の順番で停止します。
グループ内のリソースがどこかで開始できない場合は、グループ内のその後の全リソースは実行することができません。
グループにはプリミティブクラスタリソースしか含むことができません。グループには1つ以上のリソースを含む必要があります。空の場合は設定は無効になります。グループリソースの子を参照するには、グループのIDではなく子のIDを使用します。
制約でグループの子を参照することはできますが、通常はグループ名を使用することをお勧めします。
固着性はグループ内で統合可能なプロパティです。グループ内のアクティブな各メンバーは、グループの合計値に対して固着性を追加します。したがって、デフォルトのresource-stickiness
が100
で、グループに7つのメンバーがあり、そのうち5つがアクティブな場合は、グループが全体として、スコア500
で、現在の場所を優先します。
グループのリソース監視を有効にするには、グループ内で監視の必要な各リソースに対して監視を設定する必要があります。
選択したクラスタ管理ツールでグループを作成する方法については、次を参照してください。
Hawk2: 手順7.9「リソースグループを追加する」
crmsh: 8.4.10項 「クラスタリソースグループの構成」
クラスタ内の複数のノードで特定のリソースを同時に実行することができます。このためには、リソースをクローンとして設定する必要があります。クローンとして設定するリソースの一例として、OCFS2などのクラスタファイルシステムが挙げられます。提供されているどのリソースも、クローンとして設定できます。これは、リソースのリソースエージェントによってサポートされます。クローンリソースは、ホスティングされているノードによって異なる設定をすることもできます。
リソースクローンには次の3つのタイプがあります。
最も簡単なクローンタイプです。実行場所にかかわらず、同じ動作をします。このため、マシンごとにアクティブな匿名クローンのインスタンスは1つだけ存在できます。
このリソースは独自のエントリです。1つのノードで実行しているクローンのインスタンスは、別なノードの別なインスタンスとは異なり、同じノードの2つのインスタンスが同一になることもありません。
このリソースのアクティブインスタンスは、アクティブとパッシブという2つの状態に分けられます。プライマリとセカンダリ、またはマスタとスレーブと呼ばれることもあります。ステートフルなクローンが、匿名またはグローバルに固有の場合もあります。6.3.5.3項 「マルチステートリソース」も参照してください。
クローンは、グループまたは通常リソースを1つだけ含む必要があります。
リソースのモニタリングまたは制約を設定する場合、クローンには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(http://www.clusterlabs.org/doc/から入手可)を参照してください。特に、「Clones - Resources That Get Active on Multiple Hosts」のセクションを参照してください。
選択したクラスタ管理ツールでクローンを作成する方法については、次を参照してください。
Hawk2: 手順7.10「クローンリソースの追加」
crmsh: 8.4.11項 「クローンリソースの設定」。
マルチステートリソースは、クローンが得意とするところです。これにより、インスタンスを2つの動作モード(master
またはslave
と呼ばれているが、任意の名前を割り当てることができる)のいずれかに設定できます。マルチステートリソースは、グループまたは通常リソースを1つだけ含む必要があります。
リソースの監視または制約を設定する場合、マルチステートリソースには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(http://www.clusterlabs.org/doc/から入手可)を参照してください。特に、「Multi-state - Resources That Have Multiple Modes」のセクションを参照してください。
追加した各リソースについて、オプションを定義できます。クラスタはオプションを使用して、リソースの動作方法を決定します。CRMに特定のリソースの処理方法を通知します。リソースオプションは、crm_resource --meta
コマンドまたはHawk2を使用して設定できます(手順7.5「プリミティブリソースの追加」を参照)。
オプション |
説明 |
デフォルト |
---|---|---|
|
一部のリソースをアクティブにできない場合、クラスタは優先度の低いリソースを停止して、優先度の高いリソースをアクティブに維持します。 |
|
|
クラスタが維持しようとするこのリソースの状態。使用できる値: |
|
|
クラスタがリソースを開始して停止できるかどうか。使用できる値: |
|
|
リソースは手動でタッチできるかどうか。使用できる値: |
|
|
リソースが現在の状態をどの程度維持したいか。 |
計算済み |
|
ノードがこのリソースをホストできなくなるまで、このリソースについてノード上で発生する失敗の回数。 |
|
|
複数のノードでアクティブなリソースを検出した場合のクラスタの動作。使用できる値: |
|
|
失敗が発生していないように動作する(リソースを失敗したノードに戻す)前に、待機する秒数 |
|
|
|
|
|
このリソースが定義するリモートノードの名前。これにより、リモートノードのリソースが有効化されるだけでなく、リモートノードの識別に使用される固有の名前が定義されます。他のパラメータが設定されていない場合、この値はremote-portの接続先の
警告: 固有のIDの使用この値は、既存のリソースやノードIDとは重複させないでください。 |
なし(無効) |
|
pacemaker_remoteへのゲスト接続用のカスタムポート。 |
|
|
リモートノードの名前がゲストのホスト名ではない場合に接続するIPアドレスまたはホスト名。 |
|
|
中断したゲスト接続がタイムアウトするまでの時間。 |
|
すべてのリソースクラスのスクリプトでは、動作方法および管理するサービスのインスタンスを指定するパラメータを指定できます。リソースエージェントがパラメータをサポートする場合、それらのパラメータをcrm_resource
コマンドまたはHawk2を使用して追加できます(手順7.5「プリミティブリソースの追加」を参照)。インスタンス属性は、crm
コマンドラインユーティリティではparams
、Hawk2ではParameter
と呼ばれます。OCFスクリプトでサポートされているインスタンス属性のリストは、次のコマンドをroot
として実行すると参照できます。
root #
crm
ra info [class:[provider:]]resource_agent
または(オプション部分なし):
root #
crm
ra info resource_agent
出力には、サポートされているすべての属性、それらの目的、およびデフォルト値が一覧されます。
たとえば、次のコマンドを使用します。
root #
crm
ra info IPaddr
次の出力が返されます。
Manages virtual IPv4 addresses (portable version) (ocf:heartbeat:IPaddr) This script manages IP alias IP addresses It can add an IP alias, or remove one. Parameters (* denotes required, [] the default): ip* (string): IPv4 address The IPv4 address to be configured in dotted quad notation, for example "192.168.1.1". nic (string, [eth0]): Network interface The base network interface on which the IP address will be brought online. If left empty, the script will try and determine this from the routing table. Do NOT specify an alias interface in the form eth0:1 or anything here; rather, specify the base interface only. cidr_netmask (string): Netmask The netmask for the interface in CIDR format. (ie, 24), or in dotted quad notation 255.255.255.0). If unspecified, the script will also try to determine this from the routing table. broadcast (string): Broadcast address Broadcast address associated with the IP. If left empty, the script will determine this from the netmask. iflabel (string): Interface label You can specify an additional label for your IP address here. lvs_support (boolean, [false]): Enable support for LVS DR Enable support for LVS Direct Routing configurations. In case a IP address is stopped, only move it to the loopback device to allow the local node to continue to service requests, but no longer advertise it on the network. local_stop_script (string): Script called when the IP is released local_start_script (string): Script called when the IP is added ARP_INTERVAL_MS (integer, [500]): milliseconds between gratuitous ARPs milliseconds between ARPs ARP_REPEAT (integer, [10]): repeat count How many gratuitous ARPs to send out when bringing up a new address ARP_BACKGROUND (boolean, [yes]): run in background run in background (no longer any reason to do this) ARP_NETMASK (string, [ffffffffffff]): netmask for ARP netmask for ARP - in nonstandard hexadecimal format. Operations' defaults (advisory minimum): start timeout=90 stop timeout=100 monitor_0 interval=5s timeout=20s
グループ、クローン、およびマルチステートリソースには、インスタンス属性がないので注意してください。ただし、インスタンス属性のセットは、グループ、クローン、またはマルチステートリソースの子によって継承されます。
デフォルトで、クラスタはリソースが良好な状態であることを保証しません。クラスタにこれを行わせるには、リソースの定義に監視操作を追加する必要があります。監視操作は、すべてのクラスまたはリソースエージェントに追加できます。詳細については、6.4項 「リソース監視」を参照してください。
操作 |
説明 |
---|---|
|
アクションに指定する名前。一意にする必要があります。(IDは表示されません) |
|
実行するアクション。共通の値: |
|
操作を実行する頻度。単位: 秒 |
|
アクションが失敗したと宣言する前に待機する長さ。 |
|
このアクションが発生する前に満たす必要のある条件。使用できる値: |
|
このアクションが失敗した場合に実行するアクション。使用できる値:
|
|
|
|
リソースにこの役割がある場合のみ操作を実行します。 |
|
グローバルに設定したり、個々のリソースに対して設定できます。リソース上の「in-flight」操作の状態をCIBに反映させます。 |
|
操作について説明します。 |
リソースのタイムアウト値は次の3つのパラメータの影響を受けることがあります。
op_defaults
(操作用のグローバルタイムアウト)
リソーステンプレートに対して定義された特定のタイムアウト値
リソースに対して定義された特定のタイムアウト値
リソースに対して「特定の」値が定義される場合、グローバルデフォルトより優先されます。また、リソースに対して定義された特定の値は、リソーステンプレートで定義された値より優先されます。
タイムアウト値を適切に設定することは非常に重要です。これらの値を短くしすぎると、次のような理由で、多数の(不必要な)フェンシング処理が発生します。
リソースでタイムアウトが発生すると、リソースは失敗し、クラスタはリソースを停止しようとします。
リソースの停止も失敗した場合(たとえば、停止のタイムアウト設定が短すぎる場合)、クラスタはノードをフェンシングします。クラスタは、このノードが制御できなくなっていると見なすからです。
操作に対するグローバルデフォルトを調整し、crmshおよびHawk2の両方で特定のタイムアウト値を設定できます。タイムアウト値の決定および設定のベストプラクティスは次のとおりです。
負荷の下でリソースが開始および停止するためにかかる時間を確認します。
必要に応じて op_defaults
パラメータを追加し、それに応じて(デフォルト)タイムアウト値を設定します。
たとえば、op_defaults
を60
秒に設定します。
crm(live)configure#
op_defaults timeout=60
さらに長い時間を必要とするリソースについては、個別の値を定義します。
あるリソースに対して操作を設定する場合には、個別のstart
およびstop
操作を追加します。Hawk2を使用して設定する場合、これらの操作に適したタイムアウト値候補が表示されます。
リソースが実行中であるかどうか確認するには、そのリソースにリソースの監視を設定しておく必要があります。
リソースモニタが障害を検出すると、次の処理が行われます。
/etc/corosync/corosync.conf
のlogging
セクションで指定された設定に従って、ログファイルメッセージが生成されます。
障害がクラスタ管理ツール(Hawk2、crm status
)と、CIBステータスセクションに反映されます。
クラスタが明瞭な復旧アクションを開始します。これらのアクションには、リソースを停止して障害状態を修復する、ローカルまたは別のノードでリソースを再起動するなどが含まれる場合があります。設定やクラスタの状態によっては、リソースが再起動されないこともあります。
リソースの監視を設定しなかった場合、開始成功後のリソース障害は通知されず、クラスタは常にリソース状態を良好として表示してしまいます。
通常、リソースは動作している限り、クラスタのみによって監視されます。しかし、同時実行違反を検出するために、停止されるリソースの監視も設定する必要があります。次の例をご覧ください。
primitive dummy1 ocf:heartbeat:Dummy \ op monitor interval="300s" role="Stopped" timeout="10s" \ op monitor interval="30s" timeout="10s"
この設定は、300
秒ごとに、リソースdummy1
に対する監視操作をトリガします。これは、リソースがrole="Stopped"
に入ると有効になります。実行中には、リソースは30
秒ごとに監視されます。
CRMはすべてのノードの各リソースに対して、probe
と呼ばれる初期監視を実行します。probeはリソースのクリーンアップ後にも実行されます。1つのリソースに対して複数の監視操作が定義されている場合、CRMは最も時間間隔の短い監視を1つ選択し、そのタイムアウト値をプローブのデフォルトタイムアウトとして使用します。監視操作が何も設定されていない場合は、クラスタ規模のデフォルトが適用されます。デフォルトは、20
秒です( op_defaults
パラメータの設定で別途指定されない場合)。自動計算やop_defaults
の値に依存したくない場合は、このリソースの「プローブ」に対して特定の監視操作を定義します。interval
を0
に設定した監視操作を追加することで、この操作を行います。たとえば次のようになります。
crm(live)configure#
primitive
rsc1 ocf:pacemaker:Dummy \ op monitor interval="0" timeout="60"
rsc1
のプローブは60
秒でタイムアウトになります。この値は、
op_defaults
で定義されているグローバルタイムアウトや、その他の操作で設定されているタイムアウトとは無関係です。それぞれのリソースのプローブを指定するためにinterval="0"
を設定していない場合、CRMは、そのリソースに定義されている監視操作がほかにないかどうかを自動的に確認し、上で説明されているようにプローブのタイムアウト値を計算します。
選択したクラスタ管理ツールでリソースに対して監視操作を追加する方法については、次を参照してください。
Hawk2: 手順7.13「操作の追加または変更」
crmsh: 8.4.9項 「リソース監視の設定」
すべてのリソースを設定する以外にも、多くの作業が必要です。クラスタが必要なすべてのリソースを認識しても、正しく処理できるとは限りません。リソースの制約を指定して、リソースを実行可能なクラスタノード、リソースのロード順序、特定のリソースが依存している他のリソースを指定することができます。
使用可能な制約には3種類あります。
場所の制約はリソースを実行できるノード、できないノード、または実行に適したノードを定義するものです。
コロケーション制約は、ノード上で一緒に実行可能な、または一緒に実行することが禁止されているリソースをクラスタに伝えます。
アクションの順序を定義する、順序の制約です。
リソースグループの「メンバー」に対してコロケーション制約を作成しないでください。代わりに、リソースグループ全体を指すリソース制約を作成してください。その他のタイプの制約はすべて、リソースグループのメンバーに対して使用しても問題ありません。
クローンリソースまたはマルチステートリソースが適用されているリソースで制約を使用しないでください。制約はクローンまたはマルチステートリソースに適用する必要があり、その子リソースに適用することはできません。
場所、コロケーション、または順序の制約を定義するための別のフォーマットとして、resource sets
を使用することができます。リソースセットでは、プリミティブが1つのセットでグループ化されます。以前は、これはリソースグループを定義するか(デザインを正確に表現できない場合もあった)、個々の制約として各関係を定義することでこの操作が可能でした。個々の制約として定義した場合、多数のリソースとの組み合わせが増えるにつれて、制約が飛躍的に増加しました。リソースセットを介した設定で、冗長性が常に低減されるわけではありませんが、次の例が示すように、定義内容の把握と管理がより容易になります。
たとえば、crmshでリソースセット(loc-alice
)の次の設定を使用して、2つの仮想IP (vip1
および vip2
)を同じノード、 aliceに配置できます
。
crm(live)configure#
primitive
vip1 ocf:heartbeat:IPaddr2 params ip=192.168.1.5crm(live)configure#
primitive
vip1 ocf:heartbeat:IPaddr2 params ip=192.168.1.6crm(live)configure#
location
loc-alice { vip1 vip2 } inf: alice
リソースセットを使用してコロケーション制約の設定を置き換える場合は、次の2つの例を検討します。
<constraints> <rsc_colocation id="coloc-1" rsc="B" with-rsc="A" score="INFINITY"/> <rsc_colocation id="coloc-2" rsc="C" with-rsc="B" score="INFINITY"/> <rsc_colocation id="coloc-3" rsc="D" with-rsc="C" score="INFINITY"/> </constraints>
リソースセットで表される同一の設定:
<constraints> <rsc_colocation id="coloc-1" score="INFINITY" > <resource_set id="colocated-set-example" sequential="true"> <resource_ref id="A"/> <resource_ref id="B"/> <resource_ref id="C"/> <resource_ref id="D"/> </resource_set> </rsc_colocation> </constraints>
リソースセットを使用して順序の制約の設定を置き換える場合は、次の2つの例を検討します。
<constraints> <rsc_order id="order-1" first="A" then="B" /> <rsc_order id="order-2" first="B" then="C" /> <rsc_order id="order-3" first="C" then="D" /> </constraints>
順序付けされたリソースを持つリソースセットを使用して、同様な目的を達成できます。
<constraints> <rsc_order id="order-1"> <resource_set id="ordered-set-example" sequential="true"> <resource_ref id="A"/> <resource_ref id="B"/> <resource_ref id="C"/> <resource_ref id="D"/> </resource_set> </rsc_order> </constraints>
これらのセットは、順序付けされている(sequential=true
)場合もあれば、順序付けされていない場合(sequential=false
)場合もあります。また、require-all
属性を使用して、AND
およびOR
ロジック間を切り替えることができます。
同じノード上にリソースのグループを配置する方が役立つ場合がありますが(コロケーション制約を定義)、リソース間に困難な依存関係を持つことはありません。たとえば、同じノード上に2つのリソースを配置したいが、それらの一方で障害が発生した場合に他方をクラスタで再起動したくない場合があります。これは、weak bond
コマンドを使用して、crmシェルで実行できます。
選択したクラスタ管理ツールでこれらの「弱い結合」を設定する方法については、次を参照してください。
様々な種類の制約を追加する方法については、選択したクラスタ管理ツールに応じて次のいずれかを参照してください。
Hawk2: 7.6項 「制約の設定」
crmsh: 8.4.5項 「リソース制約の設定」
制約の設定の詳細や、順序付けおよびコロケーションの基本的な概念についての詳しいバックグラウンド情報は次のドキュメントを参照してください。これらのドキュメントは、http://www.clusterlabs.org/doc/で入手できます。
『Pacemaker Explained』の「Resource Constraints」の章
『Colocation Explained』
『オーダーの概要』
制約を定義する際は、スコアも扱う必要があります。あらゆる種類のスコアはクラスタの動作方法と密接に関連しています。スコアの操作によって、リソースのマイグレーションから、速度が低下したクラスタで停止するリソースの決定まで、あらゆる作業を実行できます。スコアはリソースごとに計算され、リソースに対して負のスコアが付けられているノードは、そのリソースを実行できません。リソースのスコアを計算した後、クラスタはスコアが最も高いノードを選択します。
INFINITY
は現在1,000,000
と定義されています。この値の増減は、次の3つの基本ルールに従います。
任意の値+ INFINITY = INFINITY
任意の値- INFINITY = -INFINITY
INFINITY - INFINITY = -INFINITY
リソース制約を定義する際は、各制約のスコアを指定します。スコアはこのリソース制約に割り当てる値を示します。スコアの高い制約は、それよりもスコアが低い制約より先に適用されます。1つのリソースに対して場所の制約を複数作成し、それぞれに異なるスコアを指定することで、リソースがフェールオーバーするノードの順序を指定できます。
リソーステンプレートを定義したら(6.3.4項 「リソーステンプレート」を参照)、次のタイプの制約で参照できます。
順序の制約
コロケーション制約
rsc_ticket制約(Geoクラスタの場合)
ただし、コロケーション制約には、テンプレートへの参照を複数含めることはできません。リソースセットには、テンプレートへの参照を含めることはできません。
制約内で参照されたリソーステンプレートは、そのテンプレートから派生するすべてのプリミティブを表します。これは、そのリソーステンプレートを参照しているすべてのプリミティブリソースに、この制約が適用されることを意味します。制約内でリソーステンプレートを参照すれば、リソースセットの代替となり、クラスタ設定をかなりの程度単純化することができます。リソースセットの詳細については、手順7.17「制約のためにリソースセットを使用する」を参照してください。
リソースに障害が発生すると、自動的に再起動されます。現在のノードで再起動できない場合、または現在のノードでN
回失敗した場合は、別のノードへのフェールオーバーが試行されます。リソースが失敗するたびに、その失敗回数が増加します。新しいノードへのマイグレートを行う基準(migration-threshold
)となるリソースの失敗数を定義できます。クラスタ内に3つ以上ノードがある場合、特定のリソースのフェールオーバー先のノードはHigh Availabilityソフトウェアが選択します。
ただし、リソースに1つ以上の場所の制約とmigration-threshold
を設定することで、そのリソースのフェールオーバー先にするノードを指定できます。
選択したクラスタ管理ツールでフェールオーバーノードを指定する方法については、次を参照してください。
Hawk2: 7.6.6項 「リソースフェールオーバーノードの指定」
crmsh: 8.4.6項 「リソースフェールオーバーノードの指定」
たとえば、リソース「rsc1
」に場所の制約を設定し、このリソースを「alice
」で優先的に実行するように指定したと仮定します。そのノードで実行できなかった場合は、「migration-threshold
」を確認して失敗回数と比較します。失敗回数 >= マイグレーションしきい値の場合は、リソースは次の優先実行先として指定されているノードにマイグレートされます。
デフォルトでは、いったんしきい値に達すると、そのノードでは、リソースの失敗回数がリセットされるまで、失敗したリソースを実行できなくなります。これは、手動でクラスタ管理者が行うか、リソースにfailure-timeout
オプションを設定することで実行できます。
たとえば、migration-threshold=2
とfailure-timeout=60s
を設定すると、リソースは、2回の失敗の後に新しいノードに移行します。そして、1分後に復帰できます(固着性と制約のスコアによる)。
移行しきい値の概念には2つの例外があり、これらの例外は、リソースの開始失敗か、停止失敗のどちらかで発生します。
起動の失敗では、失敗回数がINFINITY
に設定されるので、常に、即時に移行が行われます。
停止時の失敗ではフェンシングが発生します([stonith-enabled
]がデフォルトである「true
」に設定されている場合)。
STONITHリソースが定義されていない場合は(またはstonith-enabled
がfalse
に設定されている場合)、リソースの移行は行われません。
選択したクラスタ管理ツールでマイグレーションしきい値を使用し、失敗回数をリセットする方法については、次を参照してください。
Hawk2: 7.6.6項 「リソースフェールオーバーノードの指定」
crmsh: 8.4.6項 「リソースフェールオーバーノードの指定」
ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元のノードにフェールバックすることがあります。リソースを実行していたノードにリソースをフェールバックさせたくない場合や、リソースのフェールバック先として別のノードを指定する場合は、リソースの固着性の値を変更します。リソースの固着性は、リソースの作成時でも、その後でも指定できます。
リソース固着性値の指定時には、次の予想される結果について考慮してください。
0
の値:デフォルトです。リソースはシステム内で最適な場所に配置されます。現在よりも「状態のよい」、または負荷の少ないノードが使用可能になると、移動することを意味しています。このオプションは自動フェールバックとほとんど同じですが、以前アクティブだったノード以外でもリソースをフェールバックできるという点が異なります。
0
より大きい値:リソースは現在の場所に留まることを望んでいますが、状態がよいノードが使用可能になると移動される可能性があります。値が大きくなるほど、リソースが現在の場所に留まることを強く望んでいることを示します。
0
より小さい値:リソースは現在の場所から別な場所に移動することを望んでいます。絶対値が大きくなるほど、リソースが移動を強く望んでいることを示します。
INFINITY
の値:
ノードがリソースの実行権利がなくなったために強制終了される場合(ノードのシャットダウン、ノードのスタンバイ、migration-threshold
に到達、または設定変更)以外は、リソースは常に現在の場所に留まります。このオプションは自動フェールバックを完全に無効にする場合とほとんど同じです。
-INFINITY
の値:リソースは現在の場所から常に移動されます。
すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースでは、そのホストであるノードがリソースの容量要件を満たす必要があります。リソースの組み合わされたニーズが提供された容量より大きくなるようにリソースが配置されると、リソースのパフォーマンスが低下します(あるいは失敗することさえあります)。
これを考慮に入れて、High Availability Extensionでは、次のパラメータを指定できます。
一定のノードが提供する容量
一定のリソースが要求する容量
リソースの配置に関する全体的なストラテジ
選択したクラスタ管理ツールでこれらの設定を設定する方法については、次を参照してください。
ノードは、リソースの要件を満たすだけの空き容量があれば、そのリソースに対して資格があるとみなされます。High Availability Extensionにとって、容量の性質は重要ではありません。High Availability Extensionは、リソースをノードに移動する前に、リソースのすべての容量要件が満たされているかどうかを確認するだけです。
リソースの要件とノードが提供する容量を手動で設定するには、使用属性を使用します。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義します。ただし、属性値は、整数にする必要があります。
使用属性を持つ複数のリソースがグループ化されていたり、これらにコロケーション制約がある場合、High Availability Extensionではそのことを考慮に入れます。可能な場合、これらのリソースは、すべての容量要件を満たすことができるノードに配置されます。
リソースグループに対して使用属性を直接設定することはできません。ただし、グループの設定を簡素化するために、グループ内のすべてのリソースに必要な合計容量を含む使用属性を追加することができます。
High Availability Extensionには、ノードの容量とリソースの要件を自動的に検出し、設定する手段も用意されています。
NodeUtilization
リソースエージェントは、ノードの容量をチェックします(CPUとRAMについて)。 自動検出を設定するには、クラス、プロバイダ、タイプがocf:pacemaker:NodeUtilization
のクローンリソースを作成します。このクローンのインスタンスが各ノードに1つずつ実行している必要があります。インスタンスが開始すると、CIBでそのノードの設定にutilizationセクションが追加されます。
リソースの最小要件の自動検出(RAMとCPU)に配慮し、Xen
リソースエージェントが改良されました。Xen
リソースは、開始時点でRAMとCPUの消費状況を反映します。リソース設定には、使用属性が自動的に追加されます。
ocf:heartbeat:Xen
リソースエージェントは、libvirt
に使用するべきではありません。libvirt
ではマシン記述ファイルの変更が想定されているためです。
libvirt
には、ocf:heartbeat:VirtualDomain
リソースエージェントを使用します。
最小要件を検出することに加え、High Availability Extensionは、VirtualDomain
リソースエージェントを通して現在の利用状況を監視することができ、仮想マシンでのCPUとRAMの使用状況を検出します。この機能を使用するには、クラス、プロバイダ、およびタイプがocf:heartbeat:VirtualDomain
のリソースを設定します。次のインスタンス属性を使用できます: autoset_utilization_cpu
および
autoset_utilization_hv_memory
。両方ともデフォルトはtrue
です。これにより、監視サイクルのたびにCIBで使用値が更新されます。
容量と要件を手動と自動のどちらで設定する場合でも、placement-strategy
プロパティ(グローバルクラスタオプション内)で、配置ストラテジを指定する必要があります。次の値を使用できます。
default
(デフォルト値)使用値は考慮しません。リソースは、場所のスコアに従って割り当てられます。スコアが同じであれば、リソースはノード間で均等に分散されます。
utilization
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。ただし、負荷分散は、まだ、ノードに割り当てられたリソースの数に基づいて行われます。
minimal
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。できるだけ少ない数のノードにリソースを集中しようとします(残りのノードの電力節約のため)。
balanced
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する際に、利用率を確認します。リソースを均等に分散して、リソースのパフォーマンスを最適化しようとします。
使用できる配置ストラテジは、最善策であり、まだ、複雑なヒューリスティックソルバで、常に最適な割り当て結果を得るには至っていません。リソースの優先度を正しく設定して、最重要なリソースが最初にスケジュールされるようにしてください。
次の例は、同等のノードから成る3ノードクラスタと4つの仮想マシンを示しています。
node alice utilization memory="4000" node bob utilization memory="4000" node charlie utilization memory="4000" primitive xenA ocf:heartbeat:Xen utilization hv_memory="3500" \ params xmfile="/etc/xen/shared-vm/vm1" meta priority="10" primitive xenB ocf:heartbeat:Xen utilization hv_memory="2000" \ params xmfile="/etc/xen/shared-vm/vm2" meta priority="1" primitive xenC ocf:heartbeat:Xen utilization hv_memory="2000" \ params xmfile="/etc/xen/shared-vm/vm3" meta priority="1" primitive xenD ocf:heartbeat:Xen utilization hv_memory="1000" \ params xmfile="/etc/xen/shared-vm/vm4" meta priority="5" property placement-strategy="minimal"
3ノードはすべてアクティブであり、まず、リソースxenA
がノードに配置され、次に、xenD
が配置されます。xenB
とxenC
は、一緒に割り当てられるか、またはどちらか1つがxenD
とともに割り当てられます。
1つのノードに障害が発生した場合、残りのノード上で利用できるメモリ合計が少なすぎて、これらのリソースすべてはホストできません。xenA
は確実に割り当てられ、xenD
も同様です。ただし、残りのリソースxenB
とxenC
は、そのどちらかしか割り当てられません。xenBとxenCの優先度は同等なので、結果はまだ決められません。これを解決するためにも、どちらかに高い優先度を設定する必要があります。
タグは最近Pacemakerに追加された新機能です。タグは、コロケーションの作成や関係の順序付けを行わずに、複数のリソースをただちに参照する方法です。これは、概念的に関連するリソースをグループ化するのに役立つ場合があります。たとえば、データベースに関連するいくつかのリソースがある場合、databases
というタグを作成し、データベースに関連するすべてのリソースをこのタグに追加します。これにより、1つのコマンドでそれらすべてのリソースを停止または起動できます。
タグは制約でも使用できます。たとえば、次の場所制約loc-db-prefer
は、databases
でタグ付けしたリソースのセットに適用されます。
location loc-db-prefer databases 100: alice
選択したクラスタ管理ツールでタグを作成する方法については、次を参照してください。
Hawk2: 手順7.12「タグの追加」
crmsh: 8.5.6項 「リソースのグループ化/タグ付け」
リモートホストでサービスを監視および管理できることが、ここ数年の間にますます重要になってきています。SUSE Linux Enterprise High Availability Extension 11 SP3では、監視プラグインを介したリモートホスト上のサービスの詳細な監視機能を提供してきました。SUSE Linux Enterprise High Availability Extension
12 SP5では、最近追加された
pacemaker_remoteサービスを使用すると、リモートマシンにクラスタスタックをインストールしていなくても、実際のクラスタノードと同様にリモートホスト上のリソースを全面的に管理および監視できます。
仮想マシンの監視はVMエージェント(ハイパーバイザにゲストが出現する場合のみチェックを行う)を使用して行うか、VirtualDomainまたはXenエージェントから呼び出される外部スクリプトによって行うことができます。これまでは、精度の高い監視を行うには、仮想マシン内にHigh Availabilityスタックを完全にセットアップするしか方法がありませんでした。
今回、High Availability Extensionでは、監視プラグイン(旧称はNagiosプラグイン)に対するサポートを提供することで、リモートホスト上のサービスを監視できるようになりました。ゲストイメージを変更することなく、ゲストの外部ステータスを収集できます。たとえば、VMゲストはWebサービスまたは単純なネットワークリソースを実行している可能性があり、これらはアクセス可能である必要があります。Nagiosリソースエージェントによって、ゲスト上のWebサービスまたはネットワークリソースを監視できるようになりました。これらのサービスにアクセスできなくなった場合は、High Availability Extensionがそれぞれのゲストの再起動またはマイグレーションをトリガします。
ゲストがサービス(そのゲストによって使用されるNFSサーバなど)に依存している場合、そのサービスは、クラスタによって管理される通常のリソースか、Nagiosリソースによって監視される外部サービスのどちらかにすることができます。
Nagiosリソースを設定するには、ホスト上に次のパッケージをインストールする必要があります:
monitoring-plugins
monitoring-plugins-metadata
必要に応じて、YaSTまたはZypperが、これ以上のパッケージに対する依存性を解決します。
一般的な使用例としては、1つのリソースコンテナに属するリソースとして監視プラグインを設定します。このリソースコンテナは通常はVMです。いずれかのリソースに障害が発生したら、このコンテナが再起動されます。設定例については、例6.10「監視プラグインのリソースの設定」を参照してください。または、Nagiosリソースエージェントを使用してネットワーク経由でホストまたはサービスを監視する場合、このエージェントを通常のリソースとして設定することもできます。
primitive vm1 ocf:heartbeat:VirtualDomain \ params hypervisor="qemu:///system" config="/etc/libvirt/qemu/vm1.xml" \ op start interval="0" timeout="90" \ op stop interval="0" timeout="90" \ op monitor interval="10" timeout="30" primitive vm1-sshd nagios:check_tcp \ params hostname="vm1" port="22" \ 1 op start interval="0" timeout="120" \ 2 op monitor interval="10" group g-vm1-and-services vm1 vm1-sshd \ meta container="vm1" 3
サポートされるパラメータは、監視プラグインの長いオプションと同じです。プラグインは、パラメータ | |
ゲストオペレーティングシステムが起動してサービスが実行されるまでには少し時間がかかるので、監視リソースの起動タイムアウトは十分な長さに設定する必要があります。 | |
タイプが |
上の例には、check_tcp
プラグイン用の1つのリソースしか含まれていませんが、様々なプラグインタイプ(たとえば、check_http
やcheck_udp
など)用に複数のリソースを設定することもできます。
複数のサービスのホスト名が同じである場合、hostname
パラメータを個別のプリミティブに追加するのではなく、グループに対して指定することもできます。次に例を示します。
group g-vm1-and-services vm1 vm1-sshd vm1-httpd \ meta container="vm1" \ params hostname="vm1"
監視プラグインによって監視されているいずれかのサービスに、VM内で障害が発生した場合は、クラスタがこれを検出し、コンテナリソース(VM)を再起動します。この場合に実行される操作は、サービスの監視操作に関するon-fail
属性を指定することで設定できます。デフォルトでは、restart-container
に設定されています。
VMのマイグレーションしきい値を検討する場合は、サービスの障害発生回数が考慮されます。
pacemaker_remote
を使用したリモートノードでのサービスの管理 #
pacemaker_remote
サービスを使用すると、High Availabilityクラスタを仮想ノードまたはリモートベアメタルマシンに拡張することができます。クラスタスタックを実行して、クラスタのメンバーになる必要はありません。
High Availability Extensionでは現在、仮想環境(KVMおよびLXC)、およびこれらの仮想環境内に存在するリソースを起動できるようになりました(PacemakerまたはCorosyncの実行に仮想環境は必要としません)。
クラスタリソースとしての仮想マシンおよびVM内に存在するリソースの両方を管理する使用例では、次の設定を使用できるようになりました。
「通常」(ベアメタル)クラスタノードは、High Availability Extensionを実行します。
仮想マシンは、pacemaker_remote
サービスを実行します(VM側で必要な設定はほとんどありません)。
「通常」クラスタノード上のクラスタスタックはVMを起動し、VM上で実行されているpacemaker_remote
サービスに接続して、それらをリモートノードとしてクラスタに統合します。
リモートノードでクラスタスタックがインストールされていないときは、これには次の意味があります。
リモートノードはクォーラムに参加しません。
リモートノードはDCになることはできません。
リモートノードは、スケーラビリティの制約に制限されません(Corosyncには32ノードのメンバー制限があります)。
remote_pacemaker
サービスに関する詳細については(詳細な設定手順からなる複数の使用例を含む)、『Pacemaker Remote—Extending High Availability into Virtual Nodes』を参照してください(http://www.clusterlabs.org/doc/から入手可能)。
ノードがディスク容量が使い尽くしたために、そこに割り当てられたリソースを管理できなくなることを避けるため、High Availability Extensionでは、ocf:pacemaker:SysInfo
というリソースエージェントが提供されています。これを使用して、ディスクパーティションに関してノードのヘルスを監視します。SysInfo RAは、#health_disk
という名前のノード属性を作成します。この属性は、監視対象のディスク空き容量が指定された制限を下回るとred
に設定されます。
ノードのヘルスがクリティカルな状態に達した場合のCRMの対応方法を定義するには、グローバルなクラスタオプションであるnode-health-strategy
を使用します。
ノードがディスク容量を使い尽くした場合に、リソースを自動的にノードから移動させるには、次の手順に従います。
ocf:pacemaker:SysInfo
リソースを設定します。
primitive sysinfo ocf:pacemaker:SysInfo \ params disks="/tmp /var"1 min_disk_free="100M"2 disk_unit="M"3 \ op monitor interval="15s"
監視対象のディスクパーティション。たとえば、 注記: | |
これらのパーティションの必要最小限の空きディスク容量。オプションで、計測に使用する単位を指定できます(上記の例では、メガバイトを表す | |
ディスク容量をレポートする場合の単位。 |
リソース設定を完了するには、ocf:pacemaker:SysInfo
のクローンを作成し、各クラスタノードでそれを起動します。
node-health-strategy
をmigrate-on-red
に設定します。
property node-health-strategy="migrate-on-red"
#health_disk
属性がred
に設定されている場合、ポリシーエンジンによって、そのノードのリソースのスコアに-INF
が追加されます。これにより、このノードからすべてのリソースが移動します。この処理はSTONITHリソースのところで停止しますが、STONITHリソースが実行されていない場合でも、ノードをフェンスすることができます。フェンスでCIBに直接アクセスすることで、動作を続行できるからです。
ノードのヘルス状態がred
になったら、原因となる問題を解決します。次にred
ステータスをクリアして、ノードを再びリソースの実行に適した状態にします。クラスタノードにログインして、次のいずれかの方法を使用します。
次のコマンドを実行します:
root #
crm
node status-attr NODE delete #health_disk
該当するノードでPacemakerを再起動します。
ノードを再起動します。
ノードがサービスに復帰し、再びリソースを実行できるようになります。
crmシェル(crmsh)、High Availabilityクラスタ管理用の高度なコマンドラインインタフェースのホームページ。
crmshを使用した基本的なクラスタ設定の『Getting Started』チュートリアルとcrmシェルの包括的なマニュアルを含む、crmシェルに関するいくつかのドキュメント。マニュアルはhttp://crmsh.github.io/man-2.0/で入手できます。チュートリアルはhttp://crmsh.github.io/start-guide/に用意されています。
High Availability Extensionに含まれているクラスタリソースマネージャであるPacemakerのホームページ。
いくつかの包括的なマニュアルと一般的な概念を説明するより簡潔なドキュメント。次に例を示します。
『Pacemaker Explained』: 参考として包括的で詳細な情報が記載されています。
『Configuring Fencing with crmsh』: STONITHデバイスの設定方法および使用方法。
『Colocation Explained』
『オーダーの概要』
High Availability Linuxプロジェクトのホームページ。