高可用性は、複数の製品でモジュールとしてまたは拡張機能として使用できます。詳細については、https://documentation.suse.com/sles/html/SLES-all/article-modules.html#art-modules-high-availabilityを参照してください。

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.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項 「保守タスクのためのさまざまなオプション」を参照してください。

運用環境でライブマイグレーションを試す前に、この設定を十分にテストする必要があります。

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ページコンテンツは、クラスタ内の各ノードに接続された、共有ディスクサブシステムに保存されています。次の図は、このクラスタのセットアップを示しています。

図 1.1: 3サーバクラスタ #

 

通常のクラスタ操作では、クラスタ内の各ノードが他のノードと常に交信し、すべての登録済みリソースを定期的にポーリングして、障害を検出します。

Webサーバ1でハードウェアまたはソフトウェアの障害が発生したため、このサーバを利用してインターネットアクセス、電子メール、および情報収集を行っているユーザの接続が切断されたとします。次の図は、Webサーバ1で障害が発生した場合のリソースの移動を表したものです。

図 1.2: 1台のサーバに障害が発生した後の3サーバクラスタ #

 

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サイトの情報へのアクセスを数秒程度で回復できます。通常、再度ログインする必要はありません。

ここで、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サイトのパフォーマンスやアクセスを向上させる場合に有効な機能です。

SUSE Linux Enterprise High Availabilityでのクラスタ設定には、共有ディスクサブシステムが含まれる場合と含まれない場合があります。共有ディスクサブシステムの接続には、高速ファイバチャネルカード、ケーブル、およびスイッチを使用でき、また設定にはiSCSIを使用することができます。ノードの障害時には、クラスタ内の別の指定されたノードが、障害の発生したノードにマウントされていた共有ディスクディレクトリを自動的にマウントします。この機能によって、ネットワークユーザは、共有ディスクサブシステム上のディレクトリに対するアクセスを中断することなく実行できます。

重要: LVMを伴う共有ディスクサブシステム

共有ディスクサブシステムをLVMと使用する場合、クラスタ内の、アクセスが必要なすべてのサーバにそのサブシステムを接続する必要があります。

一般的なリソースの例としては、データ、アプリケーション、およびサービスなどがあります。次の図は、一般的なファイバチャネルクラスタの設定を表したものです。緑色の線は、Ethernet電源スイッチへの接続を示しています。このようなデバイスは、ネットワークを介して制御することが可能であり、ping要求が失敗したときにノードを再起動することができます。

図 1.3: 一般的なファイバチャネルクラスタの設定 #

 

ファイバチャネルは最も高いパフォーマンスを提供しますが、iSCSIを利用するようにクラスタを設定することもできます。iSCSIは低コストなストレージエリアネットワーク(SAN)を作成するための方法として、ファイバチャネルの代わりに使用できます。次の図は、一般的なiSCSIクラスタの設定を表したものです。

図 1.4: 一般的なiSCSIクラスタの設定 #

 

ほとんどのクラスタには共有ディスクサブシステムが含まれていますが、共有ディスクサブシステムなしのクラスタを作成することもできます。次の図は、共有ディスクサブシステムなしのクラスタを表したものです。

図 1.5: 共有ストレージなしの一般的なクラスタ設定 #

 

このセクションでは、SUSE Linux Enterprise High Availabilityのアーキテクチャの概要について簡単に説明します。アーキテクチャコンポーネントと、その相互運用方法について説明します。

1.5.1 アーキテクチャ層 #

 

SUSE Linux Enterprise High Availabilityでは、アーキテクチャが階層化されています。図1.6「アーキテクチャ」に異なる層と関連するコンポーネントを示します。

図 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 (リソースエージェント)とは、これらのクラスタリソースの起動、停止、監視に使用されるスクリプトのことです。

次のリストは、SUSE® Linux Enterprise High Availabilityに基づくクラスタのハードウェア要件を指定しています。これらの要件は、最低のハードウェア設定を表しています。クラスタの使用方法によっては、ハードウェアを追加しなければならないこともあります。

すべてのノードは、少なくとも次のモジュールおよび拡張機能が必要です。

インストール中に選択したシステムの役割に応じて、デフォルトで次のソフトウェアパターンがインストールされます。

注記: 最小インストール

これらのシステムの役割を介してインストールすると、最小限のインストールにのみ抑えられます。必要に応じて、パッケージを手動で追加しなければならない場合があります。

最初に別のシステムの役割が割り当てられていたマシンの場合、sles_haパターンまたはha_geoパターンとその他の必要なパッケージを手動でインストールする必要があります。

一部のサービスでは、共有ストレージが必要です。外部NFS共有を使用する場合は、冗長通信パスを介してすべてのクラスタノードから確実にアクセスできる必要があります。

クラスタでデータの可用性を高めたい場合は、共有ディスクシステム(SAN: Storage Area Network)の利用をお勧めします。共有ディスクシステムを使用する場合は、次の要件を満たしていることを確認してください。

SBDをSTONITHメカニズムとして使用する場合は、共有ストレージに対して追加の要件が適用されます。詳細については、13.3項 「要件と制約」を参照してください。

サポートされていて、役に立つHigh Availabilityセットアップについては、次の推奨事項を検討してください。

高可用性用のパッケージの手動インストールについては、Article “インストールとセットアップクイックスタート”を参照してください。このマニュアルでは、基本的な2ノードクラスタをセットアップする手順を説明しています。

2ノードクラスタをインストールしてセットアップした後で、AutoYaSTを使用して既存のノードのクローンを作成し、クラスタにそのクローンを追加することによりクラスタを拡張できます。

AutoYaSTでは、インストールおよび設定データを含むプロファイルを使用します。このプロファイルによって、インストールする対象と、インストールしたシステムが最終的に使用準備が整ったシステムになるように設定する方法がAutoYaSTに指示されます。そこでこのプロファイルはさまざまな方法による大量配備に使用できます(たとえば、既存のクラスタノードのクローンなど)。

さまざまなシナリオでAutoYaSTを使用する方法の詳細については、 AutoYaST Guide for SUSE Linux Enterprise Server 15 SP6を参照してください 。

重要: 同一のハードウェアを使用している環境

手順3.1「AutoYaSTによるクラスタノードのクローン作成」では、同じハードウェア設定を持つ一群のマシンにSUSE Linux Enterprise High Availability SP6を展開していることを前提としています。

同じではないハードウェア上にクラスタノードを展開する必要がある場合は、『SUSE Linux Enterprise Server 15 SP6展開ガイド』、「Automated Installation」の章の「Rule-Based Autoinstallation」セクションを参照してください。

クローンのインストールに成功したら、次の手順を実行して、クローンノードをクラスタに加えます。

これで、/etc/corosync/corosync.confファイルがCsync2を介してクローンノードに適用されたので、クローンノードがクラスタに加わります。CIBは、クラスタノード間で自動的に同期されます。

YaSTクラスタモジュールおよびこの章で使用されているいくつかの主要な用語を以下に定義します。

YaSTを起動して、高可用性 › クラスタを選択します。または、コマンドラインでモジュールを開始します。

sudo yast2 cluster

次のリストは、YaSTクラスタモジュールで使用可能な画面の概要を示しています。この画面には、クラスタセットアップの成功に必要なパラメータが含まれているかどうか、またはそのパラメータがオプションであるかどうかも説明されています。

初めてクラスタモジュールを起動した場合は、モジュールが、ウィザードのように、基本設定に必要なすべてのステップをガイドします。そうでない場合は、左パネルのカテゴリをクリックして、ステップごとに設定オプションにアクセスします。

注記: YaSTクラスタモジュールの設定

YaSTクラスタモジュール内の特定の設定は、現在のノードにのみ適用されます。他の設定はCsync2を使用してすべてのノードに自動的に転送できます。これについての詳しい情報は次のセクションを参照してください。

クラスタノード間で正常な通信を行うには、少なくとも1つの通信チャネルを定義します。手順 4.1または手順 4.2のそれぞれで説明されるように、転送プロトコルとしてマルチキャスト(UDP)またはユニキャスト(UDPU)のいずれかを使用します。2番目の冗長チャネル(手順 4.3)を定義する場合は、両方の通信チャネルで「同じ」プロトコルを使用する必要があります。

注記: パブリッククラウド: ユニキャストを使用する

SUSE Linux Enterprise High Availabilityをパブリッククラウドプラットフォームに展開する場合は、ユニキャストで通信してください。クラウドプラットフォームでは、一般的にマルチキャストでの通信がサポートされていません。

YaST通信チャネル画面で定義されるすべての設定は、/etc/corosync/corosync.confに書き込まれます。マルチキャストとユニキャストの設定のサンプルファイルは/usr/share/doc/packages/corosync/にあります。

IPv4アドレスを使用する場合、ノードIDはオプションです。IPv6アドレスを使用する場合、ノードIDは必須です。各ノードにIDを手動で指定する代わりに、YaSTクラスタモジュールには、クラスタノードごとに固有のIDを自動的に生成するオプションが含まれています。

図 4.1: YaSTクラスタ - マルチキャスト設定 #

 

クラスタ通信にマルチキャストではなくユニキャストを使用する場合は、次の手順に従います。

図 4.2: YaSTクラスタ - ユニキャスト設定 #

 

ネットワークデバイスボンディングが何らかの理由で使用できない場合、第2の選択は、Corosyncに冗長通信チャネル(2つ目のリング)を定義することです。この方法では、2つの物理的に分かれたネットワークが通信に使用できます。1つのネットワークが失敗しても、クラスタノードは、もう一方のネットワークを介して通信できます。

Corosync内の追加の通信チャネルは2つ目のトークンパスリングを形成します。/etc/corosync/corosync.confでは、設定した最初のチャネルはプライマリリングで、リング番号0を取得します。2つ目のリング(冗長チャネル)はリング番号1を取得します。

Corosyncに定義済みの冗長通信チャネルを持つ場合、RRPを使用してこれらのインタフェースの使用方法をクラスタに伝えます。RRPでは、2つの物理的に別個のネットワークが通信に使用されます。1つのネットワークが失敗しても、クラスタノードは、もう一方のネットワークを介して通信できます。

RRPでは次の3つのモードを使用できます。

手順 4.3: 冗長通信チャネルの定義 #

 

重要: 冗長リングおよび/etc/hosts

Corosync内で複数のリングが設定されている場合、各ノードが複数のIPアドレスを持つことができます。これはすべてのノードの/etc/hostsに反映する必要があります。

1. YaSTクラスタモジュールを起動して、通信チャネルカテゴリに切り替えます。

2. 冗長チャネルを有効にします。冗長チャネルは、定義した最初の通信チャネルと同じプロトコルを使用する必要があります。

3. マルチキャストを使用する場合は冗長チャネル用に次のパラメータを入力します: 使用するバインドネットワークアドレス、マルチキャストアドレス、およびポート。

   ユニキャストを使用する場合は次のパラメータを定義します: 使用するバインドネットワークアドレス、およびポート。クラスタに参加するすべてのノードのIPアドレスを入力します。

4. Corosyncに、異なるチャネルを使用する方法とタイミングを伝えるには、使用するrrp_modeを選択します。

   • 通信チャネルが1つだけ定義されている場合、rrp-modeが自動的に無効化されます(値none)。

   • activeに設定した場合、Corosyncは両方のインタフェースをアクティブに使用します。ただし、このモードは非推奨の機能です。

   • passiveに設定した場合、Corosyncは代わりに使用可能なネットワークを介してメッセージを送信します。

   RRPの使用時に、SUSE Linux Enterprise High Availabilityは現在のリングの状態を監視し、障害発生後に冗長リングを自動的に再度有効化します。

   または、corosync-cfgtoolを使用してリングの状態を手動で確認します。使用可能なオプションは-hで参照できます。

5. 変更内容を確認します。

クラスタの認証設定を定義するには、HMAC/SHA1認証を使用できます。共有シークレットが必要なHMAC/SHA認証を使用して、メッセージを保護し、認証する必要があります。指定した認証キー(パスワード)が、クラスタ中のすべてのノードで使用されます。

図 4.3: YaSTクラスタ - セキュリティ #

 

iptablesに対してステートフルなパケット検査ができるようにするには、conntrackツールを設定して使用します。これには、次の基本手順を必要とします。

図 4.4: YaSTクラスタ — conntrackd #

 

conntrackツールを設定したら、これをLinux Virtual Serverで使用できます(負荷分散を参照してください)。

YaSTクラスタモジュールは、ブート時にノード上で一定のサービスを開始するかどうか定義します。サービスを手動で開始または停止するためにモジュールを使用することもできます。クラスタノードをオンラインにし、クラスタリソースマネージャを起動するには、Pacemakerをサービスとして実行する必要があります。

図 4.5: YaSTクラスタ - サービス #

 

結果として生成された設定ファイルをすべてのノードに手動でコピーする代わりに、csync2ツールを使用して、クラスタ内のすべてのノードにレプリケートします。

これには、次の基本手順を必要とします。

Csync2では、設定変更を追跡して、クラスタノード間でファイルの同期を取ることができます。

Csync2の詳細については、https://oss.linbit.com/csync2/とhttps://oss.linbit.com/csync2/paper.pdfにアクセスしてください。

4.7.1 YaSTによるCsync2の設定 #

 

手順 4.7: YaSTによるCsync2の設定 #

 

1. YaSTクラスタモジュールを起動して、Csync2カテゴリに切り替えます。

2. 同期グループを指定するには、同期ホストグループで追加をクリックし、クラスタ内のすべてのノードのローカルホスト名を入力します。ノードごとに、hostnameコマンドから返された文字列を正確に使用する必要があります。

   

   ヒント: ホスト名解決

   ホスト名解決がネットワークで正しく機能しない場合は、各クラスタノードのホスト名とIPアドレスの組み合わせを指定することもできます。この指定には、HOSTNAME@IP文字列(たとえば、alice@192.168.2.100)を使用します。Csync2は、接続時にIPアドレスを使用します。

3. 事前共有キーの生成をクリックして、同期グループのキーファイルを生成します。キーファイルは、/etc/csync2/key_hagroupに書き込まれます。このファイルは、作成後に、クラスタのすべてのメンバーに手動でコピーする必要があります。

4. すべてのノード間で、通常、同期される必要のあるファイルを同期ファイルリストに入れるには、推奨ファイルの追加をクリックします。

5. 同期するファイルのリストからファイルを編集、追加、または削除するには、該当する各ボタンを使用します。ファイルごとに絶対パス名を入力する必要があります。

6. Csync2をオンにするをクリックして、Csync2をアクティブにします。これによって次のコマンドが実行され、ブート時にCsync2が自動的に起動します。

   # systemctl enable csync2.socket

7. 完了をクリックします。YaSTがCsync2の設定内容を/etc/csync2/csync2.cfgに書き込みます。

図 4.6: YaSTクラスタ - Csync2 #

 

4.7.2 Csync2を使用した変更内容の同期 #

 

Csync2を初めて実行する前に、次の準備をする必要があります。

手順 4.8: Csync2による初期同期の準備 #

 

1. ファイル/etc/csync2/csync2.cfgを、4.7.1項 「YaSTによるCsync2の設定」で説明されるとおりに設定した後、すべてのノードに手動でコピーします。

2. 4.7.1項のステップ 3の1つのノードで作成した/etc/csync2/key_hagroupファイルを、クラスタ内の「すべての」ノードにコピーしてください。このファイルは、Csync2による認証で必要になります。ただし、すべてのノードで同じファイルでなければならないので、他のノードではファイルを再生成しないでください。

3. すべてのノード上で次のコマンドを実行して、Csync2サービスを今すぐ開始します。

   # systemctl start csync2.socket

手順 4.9: Csync2による設定ファイルの同期 #

 

1. 最初にすべてのファイルを一度同期させるには、設定の「コピー元」であるマシン上で次のコマンドを実行します。

   # csync2 -xv

   これによって、すべてのファイルをその他のノードにプッシュすることで、一度に同期を行います。すべてのファイルが正常に同期されると、Csync2がエラーなしで終了します。

   同期対象の1つ以上のファイルが(現在のノードだけでなく)他のノード上で変更されている場合は、Csync2から、以下のものと同様の出力との衝突が報告されます。

   While syncing file /etc/corosync/corosync.conf:
   ERROR from peer hex-14: File is also marked dirty here!
   Finished with 1 errors.

2. 現在のノードのファイルバージョンが「最良」だと確信する場合は、そのファイルを強制して再同期を行い、競合を解決できます。

   # csync2 -f /etc/corosync/corosync.conf
   # csync2 -x

Csync2オプションの詳細については、次のコマンドを実行してください

# csync2 -help

注記: 変更後の同期のプッシュ

Csync2は変更のみをプッシュします。Csync2はマシン間でファイルを絶えず同期しているわけではありません。

同期が必要なファイルを更新する際はいつも、変更を加えたマシン上でcsync2  -xvを実行することで、変更をその他のマシンにプッシュする必要があります。変更されていないファイルが配置された他のマシン上でこのコマンドを実行しても、何も起こりません。

最初のクラスタ設定が完了した後、すべてのクラスタノード上でクラスタサービスを開始し、スタックをオンラインにします。

基本設定を完了し、ノードがオンラインになったら、クラスタリソースの設定を開始できます。crmシェル(crmsh)やHawk2などのクラスタ管理ツールのいずれかを使用します。詳細については、5.5項 「crmshの概要」または5.4項 「Hawk2の概要」を参照してください。

通常、クラスタのカテゴリは次のいずれかです。

異なるトポロジを追加して、異なるユースケースを生成することもできます。次のユースケースは最も一般的です。

1つ以上のノードとその他のクラスタ間で通信が失敗した場合は、常にクラスタパーティションが発生します。ノードは同じパーティション内の他のノードのみと通信可能で、切り離されたノードは認識しません。クラスタパーティションは、ノード(投票)の過半数を保有する場合、クォーラムを持つ(「定足数に達している」)と定義されます。これを実現する方法は「クォーラム計算」によって実行されます。クォーラムはフェンシングの要件です。

クォーラムはPacemakerによって計算または決定されません。Corosyncは、Pacemaker設定を変更することなく、2ノードクラスタのクォーラムを直接処理できます。

クォーラムの計算方法は、次のような要因によって影響されます。

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
}

quorum {
   provider: corosync_votequorum 1
   expected_votes: N 2
   wait_for_all: 1 3
}

グローバルクラスタオプションは、一定の状況下でのクラスタの動作を制御します。それらは、セットにグループ化され、Hawk2やcrmシェルなどのクラスタ管理ツールで表示したり、変更したりできます。

事前に定義されている値は、通常は、そのまま保持できます。ただし、クラスタの主要機能を想定どおりに機能させるには、クラスタの基本的なセットアップ後に、次のパラメータを調整する必要がある場合があります。

5.3.2 グローバルオプションstonith-enabled #

 

このグローバルオプションは、フェンシングを適用して、STONITHデバイスによる、障害ノードや停止できないリソースを持つノードのダウンを許可するかどうか定義します。通常のクラスタ操作には、STONITHデバイスの使用が必要なので、このグローバルオプションは、デフォルトでtrueに設定されています。デフォルト値では、クラスタは、STONITHリソースが定義されていない場合にはリソースの開始を拒否します。

何らかの理由でフェンシングを無効にする必要がある場合は、stonith-enabledをfalseに設定しますが、これはご使用の製品のサポートステータスに影響を及ぼすことに注意してください。また、stonith-enabled="false"を指定すると、Distributed Lock Manager (DLM)のようなリソースやDLMによるすべてのサービス(lvmlockd、GFS2、OCFS2など)は開始できません。

重要: STONITHがない場合はサポートなし

STONITHがないクラスタはサポートされません。

クラスタリソースを設定および管理する場合、Hawk2、またはcrmシェル(crmsh)コマンドラインユーティリティのいずれかを使用します。

Hawk2のユーザフレンドリなWebインタフェースを使用すると、High AvailabilityクラスタをLinuxまたは非Linuxマシンから同様に監視および管理することができます。Hawk2には、(グラフィカルな)Webブラウザを使用して、クラスタの内部または外部の任意のマシンからアクセスできます。

5.4.3 Hawk2の概要: 主な構成要素 #

 

Hawk2にログインすると、左側にはナビゲーションバー、右側には複数のリンクが含まれる最上位の行が表示されます。

注記: Hawk2で利用できる機能

デフォルトでは、rootまたはhaclusterとしてログインしたユーザは、すべてのクラスタ設定作業への、完全な読み込み/書き込みのアクセス権を持ちます。ただし、アクセス制御リスト(ACL)を使用すれば、より詳細なアクセス権限を定義することができます。

CRMでACLが有効になっている場合、Hawk2で利用できる機能は、ユーザ役割と割り当てられたアクセスパーミッションごとに異なります。Hawk2の履歴エクスプローラーは、ユーザhaclusterのみが実行できます。

5.4.3.1 左のナビゲーションバー #

 

監視

• 状態: クラスタの現在の状態の概要が表示されます(crmshのcrm statusと同様です)。詳細については、11.1.1項 「単一クラスタの監視」を参照してください。クラスタにguest nodes (pacemaker_remoteデーモンが実行されているノード)が含まれる場合、それらのノードも表示されます。この画面はほぼリアルタイムで更新され、ノードまたはリソースの状態に変化があった場合、ほとんど瞬時に表示されます。

• ダッシュボード: 複数のクラスタを監視できます(Geoクラスタがセットアップされている場合は、別のサイトにあるクラスタも監視できます)。詳細については、11.1.2項 「複数のクラスタの監視」を参照してください。クラスタにguest nodes (pacemaker_remoteデーモンが実行されているノード)が含まれる場合、それらのノードも表示されます。この画面はほぼリアルタイムで更新され、ノードまたはリソースの状態に変化があった場合、ほとんど瞬時に表示されます。

トラブルシューティング

• 履歴: 履歴エクスプローラーを開いてクラスタレポートを生成できます。詳細については、11.3項 「クラスタ履歴の表示」を参照してください。

• Command Log (コマンドログ): Hawk2によって最近実行されたcrmshコマンドのリストを表示します。

設定

• リソースの追加: リソース設定画を開きます。詳細については、第6章 「クラスタリソースの設定」を参照してください。

• 制約の追加: 制約設定画面を開きます。詳細については、第7章 「リソース制約の設定」を参照してください。

• ウィザード: さまざまなウィザードを選択できます。これにより、DRBDブロックデバイスなどの特定のワークロード用のリソースをウィザードに従って作成できます。詳細については、5.4.6項 「ウィザードを使用したリソースの追加」を参照してください。

• 設定の編集: リソース、制約、ノード名と属性、タグ、alerts、fencing topologiesを編集できます。

• クラスタ設定: グローバルクラスタオプション、およびリソースと操作のデフォルトを変更できます。詳細については、5.4.4項 「グローバルクラスタオプションの設定」を参照してください。

• アクセス制御 › Roles (役割): アクセス制御リスト(CIBへのアクセス権を記述した一連のルール)に対して役割を作成できる画面を開きます。詳細については、手順15.2「Hawk2によるmonitor役割の追加」を参照してください。

• アクセス制御 › Targets (ターゲット): アクセス制御リストのターゲット(システムユーザ)を作成して、そのターゲットに役割を割り当てることができる画面を開きます。詳細については、手順15.3「Hawk2によるターゲットへの役割割り当て」を参照してください。

5.4.3.2 最上位の行 #

 

Hawk2の最上位の行には、次のエントリが表示されます。

• バッチ: クリックすると、バッチモードに切り替わります。これにより、変更をシミュレートしてステージングし、それらの変更を単一のトランザクションとして適用できます。詳細については、5.4.7項 「バッチモードの使用」を参照してください。

• USERNAME: Hawk2用の設定ができます(たとえば、Webインタフェースの言語の設定やSTONITHを無効にした場合に警告を表示するかなどの設定)。

• ヘルプ: SUSE Linux Enterprise High Availabilityドキュメントにアクセスしたり、リリースノートを参照したり、バグを報告したりします。

• ログアウト: クリックするとログアウトします。

5.4.6 ウィザードを使用したリソースの追加 #

 

Hawk2ウィザードは、仮想IPアドレスやSDB STONITHリソースなどの単純なリソースを設定する場合に便利です。また、DRBDブロックデバイスやApache Webサーバのリソース設定などの、複数リソースを含む複雑な設定においても役立ちます。設定手順をウィザードに従って進めることができ、入力が必要なパラメータについては情報が提供されます。

手順 5.4: リソースウィザードの使用 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 左のナビゲーションバーから、環境設定 › ウィザードの順に選択します。

3. ウィザードの横にある下矢印アイコンをクリックして個々のカテゴリを展開し、目的のウィザードを選択します。

4. 画面の指示に従います。最後の設定手順が完了したら、Verify (検証)を選択して、入力した値を検証します。

   Hawk2が実行するアクションと、設定の内容が表示されます。設定によっては、適用を選択して設定を適用する前に、rootパスワードの入力を求めるプロンプトが表示されることがあります。

図 5.2: Hawk2 - Apache Webサーバ用のウィザード #

 

詳細については、第6章 「クラスタリソースの設定」を参照してください。

5.4.7 バッチモードの使用 #

 

Hawk2は、「クラスタシミュレータ」を含むバッチモードを提供します。これは次の操作に使用できます。

• 各変更を直ちに反映させるのではなく、クラスタに変更をステージングして、それらの変更を単一トランザクションとして適用する。

• たとえば、潜在的な障害シナリオを調べるため、変更やクラスタイベントをシミュレートする。

たとえば、互いに依存するリソースのグループを作成する場合にバッチモードを使用できます。バッチモードを使用すると、クラスタに中間的なまたは不完全な設定を適用することを回避できます。

バッチモードが有効な間は、リソースや制約を追加したり編集したり、クラスタ設定を変更できます。ノードのオンラインまたはオフライン化、リソース操作およびチケットの許可または取り消しなど、クラスタのイベントをシミュレートすることもできます。詳細については手順5.6「ノード、リソース、またはチケットイベントの挿入」を参照してください。

「クラスタシミュレータ」は、すべての変更後に自動的に実行され、ユーザインタフェースに予想される結果を表示します。たとえば、次のような場合もあります。バッチモードの最中にリソースを止めると、実際リソースはまだ実行中であるにも関わらず、ユーザインタフェースにはリソースが停止したと表示されます。

重要: ウィザード、およびライブシステムへの変更

一部のウィザードには単なるクラスタ設定を超えるアクションが含まれます。これらのウィザードをバッチモードで使用する場合、クラスタ設定を超えるすべての変更がライブシステムに直ちに適用されます。

したがって、root許可が必要なウィザードはバッチモードでは実行できません。

手順 5.5: バッチモードの使用 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. バッチモードを有効にするには、最上位の行からバッチを選択します。

   最上位の行の下に追加のバーが表示されます。これは、バッチモードがアクティブであることを示し、バッチモードで実行可能なアクションへのリンクが含まれます。

   

   図 5.3: Hawk2バッチモードが有効 #

    

3. バッチモードがアクティブなときに、リソースや制約の追加または編集、あるいはクラスタ設定の編集など、クラスタに対する変更を実行します。

   変更はシミュレートされ、すべての画面に表示されます。

4. 行った変更の詳細を表示するには、バッチモードバーから表示を選択します。バッチモードウィンドウが開きます。

   設定の変更について、ライブ状態とシミュレートされた変更間の相違がcrmsh構文で表示されます。-文字で開始される行は、現在の状態を表し、+で開始される行は、提案される状態を示します。

5. イベントを注入したり、さらに詳細を表示する場合は、手順 5.6を参照してください。または、Close (閉じる)をクリックしてウィンドウを閉じます。

6. シミュレートした変更を破棄または適用するかのいずれかを選択し、選択内容を確認します。これによりバッチモードが無効になり、通常のモードに戻ります。

バッチモードで実行中に、Hawk2ではNode Events (ノードイベント)とResource Events (リソースイベント)を注入することもできます。

ノードイベント

ノードの状態を変更できます。使用可能な状態は、オンライン、オフライン、およびアンクリーンです

リソースイベント

リソースの一部のプロパティを変更できます。たとえば、操作(start、stop、monitorなど)、その操作を適用するノード、およびシミュレートされる予想される結果を設定できます。

チケットイベント

(Geoクラスタにおける)チケットの許可と取り消しの影響をテストできます。

手順 5.6: ノード、リソース、またはチケットイベントの挿入 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. バッチモードがまだアクティブでない場合、最上位の行でバッチをクリックして、バッチモードに切り替えます。

3. バッチモードバーで、表示をクリックして、バッチモードウィンドウを開きます。

4. ノードのステータスの変更をシミュレートするには

   1. 注入 › ノードイベントを順にクリックします。

   2. 操作するノードを選択し、そのターゲット状態を選択します。

   3. 変更内容を確認します。イベントはバッチモードダイアログに一覧表示されるイベントのキューに追加されます。

5. リソースの操作をシミュレートするには

   1. 注入 › リソースイベントを順にクリックします。

   2. 操作するリソースを選択し、シミュレートする操作を選択します。

   3. 必要に応じて、間隔を定義します。

   4. 操作を実行するノードを選択し、ターゲットとする結果を選択します。イベントはバッチモードダイアログに一覧表示されるイベントのキューに追加されます。

   5. 変更内容を確認します。

6. チケットアクションをシミュレートするには

   1. 挿入 › チケットイベントを順にクリックします。

   2. 操作するチケットを選択し、シミュレートするアクションを選択します。

   3. 変更内容を確認します。イベントはバッチモードダイアログに一覧表示されるイベントのキューに追加されます。

7. バッチモードダイアログ(図 5.4)で、注入されたイベントごとに新しい行が表示されます。ここに一覧表示されるイベントは、直ちにシミュレートされ、状態画面に反映されます。

   設定の変更も行った場合は、ライブ状態とシミュレートされた変更の間の相違が注入されたイベントの下に表示されます。

   

   図 5.4: Hawk2のバッチモード—注入されたイベントと設定の変更 #

    

8. 注入されたイベントを削除するには、その隣の削除アイコンをクリックします。Hawk2では、それに従って状態画面が更新されます。

9. 実行されたシミュレーションに関する詳細を表示するには、シミュレータをクリックして、次のいずれかを選択します。

   まとめ

   詳細な概要を表示します。

   CIB (in)/CIB (out)

   CIB (in)では、初期のCIB状態を示します。CIB (out)では、遷移後のCIBの状態を示します。

   遷移グラフ

   遷移のグラフィカルな表現を示します。

   遷移

   遷移のXML表示を示します。

10. シミュレートされた変更を確認したら、バッチモードウィンドウを閉じます。

11. バッチモードを終了するには、シミュレートされた変更を適用するか、破棄するかのいずれかを選択します。

クラスタリソースを設定および管理するには、コマンドラインユーティリティであるcrmシェル(crmsh)またはWebベースのユーザインタフェースであるHawk2のいずれかを使用します。

このセクションでは、コマンドラインツールcrmを紹介します。crmコマンドには、リソース、CIB、ノード、リソースエージェントなどを管理するサブコマンドがあります。このコマンドには、例を組み込んだ詳細なヘルプシステムが用意されています。すべての例は、付録Bで説明される命名規則に従います。

イベントは/var/log/crmsh/crmsh.logにログを記録します。

ヒント: 対話型crmプロンプト

crmを引数なしで(または1つのサブレベルのみを引数として)使用することにより、crmシェルは対話モードになります。このモードは、次のプロンプトで示されます。

crm(live/HOSTNAME)

読みやすくするために、このマニュアルでは対話型crmのプロンプトでホスト名を省略します。次の例のように、aliceなどの特定のノードで対話型シェルを実行する必要がある場合にのみホスト名を含めます。

crm(live/alice)

user@node1 > sudo --preserve-env=SSH_AUTH_SOCK \
crm cluster init ssh --use-ssh-agent

user@node2 > sudo --preserve-env=SSH_AUTH_SOCK \
crm cluster join ssh --use-ssh-agent -c USER@NODE1

5.5.2 ヘルプの表示 #

 

ヘルプには複数の方法でアクセスできます。

• crmとそのコマンドラインオプションの使用方法を出力するには:

  # crm --help

• 使用可能なすべてのコマンドの一覧を表示するには:

  # crm help

• コマンドの参照情報だけでなく、他のヘルプセクションにアクセスするには:

  # crm help topics

• configureサブコマンドの詳細なヘルプテキストを表示するには:

  # crm configure help

• configureのgroupサブコマンドの構文、使用方法、例を出力するには:

  # crm configure help group

  これも同様です:

  # crm help configure group

helpサブコマンド(--helpオプションと混同しないこと)のほとんどすべての出力によって、テキストビューアが開きます。このテキストビューアは上下にスクロール可能で、ヘルプテキストが読みやすくなっています。テキストビューアを閉じるには、Qキーを押します。

ヒント: バッシュおよび対話型シェルでタブ補完機能を使用

crmshは、対話型シェルに対してだけではなく、バッシュでの直接的で完全なタブ補完機能をサポートしています。たとえば、crm help config<Tab>を入力すると、対話型シェルのように単語が補完されます。

5.5.3 crmshのサブコマンドの実行 #

 

crmコマンドそのものは、次のように使用できます。

• 直接: すべてのサブコマンドをcrmに続け、Enterを押すと、直ちにその出力が表示されます。たとえば、crm help raを入力すると、raサブコマンド(リソースエージェント)に関する情報を取得できます。

  サブコマンドは、その短縮形が固有である限り短縮できます。たとえば、statusをstに短縮しても、crmshはこれを認識できます。

  パラメータを短縮する機能もあります。通常、パラメータはparamsキーワードを使用して追加します。paramsセクションが最初のセクションでほかにセクションがない場合、このセクションを省略できます。たとえば、次のような行があるとします。

  # crm primitive ipaddr IPaddr2 params ip=192.168.0.55

  これは次の行と同等です。

  # crm primitive ipaddr IPaddr2 ip=192.168.0.55

• crmシェルスクリプトとして使用: シェルスクリプトにはcrmcrmのサブコマンドが含まれます。詳細については、5.5.5項 「crmshのシェルスクリプトの使用」を参照してください。

• crmshクラスタスクリプトとして使用:これらは、メタデータ、RPMパッケージへの参照、設定ファイル、およびcrmshサブコマンドを1つのわかりやすい名前でバンドルしてまとめたものです。crm scriptコマンドを使用して管理します。

  これらをcrmshシェルスクリプトと混同しないでください。両方に共通する目的はいくつかありますが、crmシェルスクリプトにはサブコマンドのみが含まれるのに対し、クラスタスクリプトにはコマンドの単純なエミュレーション以上の処理が組み込まれています。詳細については、5.5.6項 「crmshのクラスタスクリプトの使用」を参照してください。

• 内部シェルとして対話式に使用: 「crm」とタイプして、内部シェルに入ります。プロンプトがcrm(live)に変化します。helpを使用すると、利用可能なサブコマンドの概要を取得できます。内部シェルにはさまざまなサブコマンドレベルがあり、1つのサブコマンドをタイプしてEnterを押すことで、そのサブコマンドのレベルに「入る」ことができます。

  たとえば、「resource」とタイプすると、リソース管理レベルに入ります。プロンプトはcrm(live)resource##に変わります。内部シェルを終了するには、コマンドquitを使用します。1レベル戻る場合は、back、up、end、またはcdを使用します。

  crm、そしてオプションを付けずにサブコマンドを入力してEnterを押すと、そのレベルに直接入ることができます。

  内部シェルは、サブコマンドとリソースのタブによる完了もサポートします。コマンドの冒頭をタイプして<Tab>を押すと、crmがそのオブジェクトを表示します。

crmshは、同期のコマンドの実行もサポートしています。これを有効にするには、-wオプションを使用します。crmを-wなしで起動した場合でも、後ほどユーザ初期設定のwaitをyes (options wait yes)に設定すれば、有効にすることができます。このオプションが有効化される場合、crmは遷移が終了するまで待機します。処理が開始すると毎回、進行状況を示すための点が印刷されます。同期コマンドの実行はresource startなどのコマンドにのみ適用できます。

注記: 管理サブコマンドと設定サブコマンド間の相違

crmツールには、管理機能(サブコマンドresourceおよびnode)があり、設定(cib、configure)に使用できます。

以降のサブセクションでは、crmツールの重要な側面について、その概要を示します。

5.5.4 OCFリソースエージェントに関する情報の表示 #

 

リソースエージェントはクラスタ設定で常に操作する必要があるため、crmツールには、raコマンドが含まれています。このコマンドを使用して、リソースエージェントの情報を表示し、リソースエージェントを管理します(詳細は6.2項 「サポートされるリソースエージェントクラス」も参照)。

# crm ra
crm(live)ra# 

コマンドclassesは、すべてのクラスとプロバイダを一覧表示します。

crm(live)ra# classes
 lsb
 ocf / heartbeat linbit lvm2 ocfs2 pacemaker
 service
 stonith
 systemd

クラス(およびプロバイダ)に使用できるすべてのリソースエージェントの概要を取得するには、listコマンドを使用します。

crm(live)ra# list ocf
AoEtarget           AudibleAlarm        CTDB                ClusterMon
Delay               Dummy               EvmsSCC             Evmsd
Filesystem          HealthCPU           HealthSMART         ICP
IPaddr              IPaddr2             IPsrcaddr           IPv6addr
LVM                 LinuxSCSI           MailTo              ManageRAID
ManageVE            Pure-FTPd           Raid1               Route
SAPDatabase         SAPInstance         SendArp             ServeRAID
...

リソースエージェントの概要は、infoで表示できます。

crm(live)ra# info ocf:linbit:drbd
This resource agent manages a DRBD* resource
as a master/slave resource. DRBD is a shared-nothing replicated storage
device. (ocf:linbit:drbd)

Master/Slave OCF Resource Agent for DRBD

Parameters (* denotes required, [] the default):

drbd_resource* (string): drbd resource name
    The name of the drbd resource from the drbd.conf file.

drbdconf (string, [/etc/drbd.conf]): Path to drbd.conf
    Full path to the drbd.conf file.

Operations' defaults (advisory minimum):

    start         timeout=240
    promote       timeout=90
    demote        timeout=90
    notify        timeout=90
    stop          timeout=100
    monitor_Slave_0 interval=20 timeout=20 start-delay=1m
    monitor_Master_0 interval=10 timeout=20 start-delay=1m

ビューアは、「Q」を押すと終了できます。

ヒント: crmを直接使用する

前の例では、crmコマンドの内部シェルを使用しました。ただし、必ずしも、それを使用する必要はありません。該当するサブコマンドをcrmに追加すれば、同じ結果が得られます。たとえば、すべてのOCFリソースエージェントを一覧するには、シェルに「crm ra list ocf」を入力すれば済みます。

# A small example file with some crm subcommands
status
node list

# crm -f example.cli
# crm < example.cli

# crm script list

# crm script show mailto
mailto (Basic)
MailTo

 This is a resource agent for MailTo. It sends email to a sysadmin
whenever  a takeover occurs.

1. Notifies recipients by email in the event of resource takeover

  id (required)  (unique)
      Identifier for the cluster resource
  email (required)
      Email address
  subject
      Subject

# crm script verify mailto id=sysadmin email=tux@example.org
1. Ensure mail package is installed

        mailx

2. Configure cluster resources

        primitive sysadmin MailTo
                email="tux@example.org"
                op start timeout="10"
                op stop timeout="10"
                op monitor interval="10" timeout="10"

        clone c-sysadmin sysadmin

# crm script run mailto id=sysadmin email=tux@example.org
INFO: MailTo
INFO: Nodes: alice, bob
OK: Ensure mail package is installed
OK: Configure cluster resources

# crm status
[...]
 Clone Set: c-sysadmin [sysadmin]
     Started: [ alice bob ]

5.5.7 設定テンプレートの使用 #

 

注記: 非推奨に関する注意

設定テンプレートの使用は非推奨で、今後削除される予定です。設定テンプレートはクラスタスクリプトに置き換えられます。5.5.6項 「crmshのクラスタスクリプトの使用」を参照してください。

設定テンプレートは、crmsh用の既成のクラスタ設定です。リソーステンプレート(6.8.2項 「crmshを使用したリソーステンプレートの作成」の説明を参照)と混同しないでください。これらはクラスタ用のテンプレートで、crmシェル用ではありません。

設定テンプレートは、最小限の操作で、特定ユーザのニーズに合わせて調整できます。テンプレートで設定を作成する際には、警告メッセージでヒントが与えられます。これは、後から編集することができ、さらにカスタマイズできます。

次の手順は、簡単ですが機能的なApache設定を作成する方法を示しています。

1. rootとしてログインし、crm対話型シェルを開始します。

   # crm configure

2. 設定テンプレートから新しい設定を作成します。

   1. templateサブコマンドに切り替えます。

      crm(live)configure# template

   2. 使用可能な設定テンプレートを一覧します。

      crm(live)configure template# list templates
      gfs2-base   filesystem  virtual-ip  apache   clvm     ocfs2    gfs2

   3. 必要な設定テンプレートを決めます。Apache設定が必要なので、apacheテンプレートを選択し、g-intranetと名付けます。

      crm(live)configure template# new g-intranet apache
      INFO: pulling in template apache
      INFO: pulling in template virtual-ip

3. パラメータを定義します。

   1. 作成した設定を一覧表示します。

      crm(live)configure template# list
      g-intranet

   2. 入力を必要とする最小限の変更項目を表示します。

      crm(live)configure template# show
      ERROR: 23: required parameter ip not set
      ERROR: 61: required parameter id not set
      ERROR: 65: required parameter configfile not set

   3. 好みのテキストエディタを起動し、ステップ 3.bでエラーとして表示されたすべての行に入力します。

      crm(live)configure template# edit

4. 設定を表示し、設定が有効かどうか確認します(太字のテキストは、ステップ 3.cで入力した設定によって異なります)。

   crm(live)configure template# show
   primitive virtual-ip ocf:heartbeat:IPaddr \
       params ip="192.168.1.101"
   primitive apache apache \
       params configfile="/etc/apache2/httpd.conf"
       monitor apache 120s:60s
   group g-intranet \
       apache virtual-ip

5. 設定を適用します。

   crm(live)configure template# apply
   crm(live)configure# cd ..
   crm(live)configure# show

6. 変更内容をCIBに送信します。

   crm(live)configure# commit

詳細がわかっていれば、コマンドをさらに簡素化できます。次のコマンドをシェルで使用して、上記の手順を要約できます。

# crm configure template \
   new g-intranet apache params \
   configfile="/etc/apache2/httpd.conf" ip="192.168.1.101"

内部crmシェルに入っている場合は、次のコマンドを使用します。

crm(live)configure template# new intranet apache params \
   configfile="/etc/apache2/httpd.conf" ip="192.168.1.101"

ただし、このコマンドは、設定テンプレートから設定を作成するだけです。設定をCIBに適用したり、コミットすることはありません。

# crm configure
crm(live)configure# show fence-bob
primitive fence-bob stonith:apcsmart \
        params hostlist="bob"
crm(live)configure# monitor fence-bob 120m:60s
crm(live)configure# show changed
primitive fence-bob stonith:apcsmart \
        params hostlist="bob" \
        op monitor interval="120m" timeout="60s"
crm(live)configure# ptest
crm(live)configure# commit

# crm configure graph dot config.svg svg

# crm corosync status
Printing ring status.
Local node ID 175704363
RING ID 0
        id      = 10.121.9.43
        status  = ring 0 active with no faults
Quorum information
------------------
Date:             Thu May  8 16:41:56 2014
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          175704363
Ring ID:          4032
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
 175704363          1 alice.example.com (local)
 175704619          1 bob.example.com

# crm corosync diff
--- bob
+++ alice
@@ -46,2 +46,2 @@
-       expected_votes: 2
-       two_node: 1
+       expected_votes: 1
+       two_node: 0

# crm configure show
primitive mydb mysql \
   params replication_user=admin ...

# crm resource secret mydb set passwd linux
INFO: syncing /var/lib/heartbeat/lrm/secrets/mydb/passwd to [your node list]

# crm resource secret mydb show passwd
linux

次のリソースタイプを作成できます。

追加するクラスタリソースごとに、リソースエージェントが準拠する基準を定義する必要があります。リソースエージェントは、提供するサービスを抽象化して正確なステータスをクラスタに渡すので、クラスタは管理するリソースについてコミットする必要がありません。クラスタは、リソースエージェントに依存して、start、stop、またはmonitorのコマンドの発行に適宜対応します。

通常、リソースエージェントはシェルスクリプトの形式で配布されます。SUSE Linux Enterprise High Availabilityは次のリソースエージェントクラスをサポートします。

SUSE Linux Enterprise High Availabilityによって提供されるエージェントは、OCFの仕様に基づいて開発されています。

リソースのタイムアウト値は次の3つのパラメータの影響を受けることがあります。

注記: 値の優先度

リソースに対して「特定の」値が定義される場合、グローバルデフォルトより優先されます。また、リソースに対して定義された特定の値は、リソーステンプレートで定義された値より優先されます。

タイムアウト値を適切に設定することは非常に重要です。これらの値を短くしすぎると、次のような理由で、多数の(不必要な)フェンシング処理が発生します。

操作に対するグローバルデフォルトを調整し、crmshおよびHawk2の両方で特定のタイムアウト値を設定できます。タイムアウト値の決定および設定のベストプラクティスは次のとおりです。

リソースは、クラスタで使用する前にセットアップする必要があります。たとえば、Apacheサーバをクラスタリソースとして使用するには、まず、Apacheサーバをセットアップし、Apacheの環境設定を完了してから、クラスタで個々のリソースを起動します。

リソースに特定の環境要件がある場合は、それらの要件がすべてのクラスタノードに存在し、同一であることを確認してください。SUSE Linux Enterprise High Availabilityはこの種の設定は管理しません。これは、管理者自身が行う必要があります。

Hawk2またはcrmshのいずれかを使用してプリミティブリソースを作成できます。

注記: クラスタによって管理されるサービスには介入しないでください

SUSE Linux Enterprise High Availabilityでリソースを管理しているときに、同じリソースを他の方法(クラスタ外で、たとえば、手動、ブート、再起動など)で開始したり、停止してはいけません。High Availabilityソフトウェアが、すべてのサービスの開始または停止アクションを実行します。

サービスがクラスタ制御下ですでに実行された後にテストまたは保守タスクを実行する必要がある場合は、リソース、ノード、またはクラスタ全体を保守モードに設定してから、これらのいずれかに手動でタッチしてください。詳細については、28.2項 「保守タスクのためのさまざまなオプション」を参照してください。

重要: リソースIDとノード名

クラスタリソースとクラスタノードは異なる名前にする必要があります。同じ名前にするとHawk2で障害が発生します。

クラスタリソースの中には、他のコンポーネントやリソースに依存しているものもあります。それぞれのコンポーネントやリソースが決められた順序で開始され、依存しているリソースと同じサーバ上で同時に実行していなければならない場合があります。この設定を簡素化するには、クラスタリソースグループを使用できます。

Hawk2またはcrmshのいずれかを使用してリソースグループを作成できます。

図 6.2: グループリソース #

 

グループには次のプロパティがあります。

6.5.1 Hawk2を使用したリソースグループの作成 #

 

注記: 空のグループ

グループには1つ以上のリソースを含む必要があります。空の場合は設定は無効になります。グループの作成中に、Hawk2ではさらにプリミティブを作成し、それらをグループに追加できます。

手順 6.4: Hawk2を使用したリソースグループの追加 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 左のナビゲーションバーから、環境設定 ›  Add Resource (リソースの追加) › グループの順に選択します。

3. 固有のグループIDを入力します。

4. グループメンバーを定義するには、子リストで1つまたは複数のエントリを選択します。グループメンバーを再ソートするには、右側の「ハンドル」アイコンを使用して、メンバーを目的の順序にドラッグアンドドロップします。

5. 必要に応じて、メタ属性を変更または追加します。

6. 作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

図 6.3: Hawk2 - リソースグループ #

 

クラスタ内の複数のノードで特定のリソースを同時に実行することができます。このためには、リソースをクローンとして設定する必要があります。クローンとして設定するリソースの一例として、OCFS2などのクラスタファイルシステムが挙げられます。提供されているどのリソースも、クローンとして設定できます。これは、リソースのリソースエージェントによってサポートされます。クローンリソースは、ホスティングされているノードによって異なる設定をすることもできます。

リソースクローンには次の3つのタイプがあります。

クローンは、グループまたは通常リソースを1つだけ含む必要があります。

リソースのモニタリングまたは制約を設定する場合、クローンには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(https://www.clusterlabs.org/pacemaker/doc/から入手可)を参照してください。

Hawk2またはcrmshのいずれかを使用してクローンリソースを作成できます。

6.6.1 Hawk2を使用したクローンリソースの作成 #

 

注記: クローンの子リソース

クローンには、プリミティブまたはグループのいずれかを子リソースとして含めることができます。Hawk2では、クローンの作成中に子リソースを作成したり変更したりすることはできません。クローンを追加する前に、子リソースを作成し、必要に応じて設定しておいてください。

手順 6.6: Hawk2を使用したクローンリソースの追加 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 左のナビゲーションバーから、環境設定 ›  Add Resource (リソースの追加) › クローンの順に選択します。

3. 固有のクローンIDを入力します。

4. 子リソースリストから、クローンのサブリソースとして使用するプリミティブまたはグループを選択します。

5. 必要に応じて、メタ属性を変更または追加します。

6. 作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

図 6.4: Hawk2 - クローンリソース #

 

プロモータブルクローン(以前はマルチステートリソースと呼ばれていました)は、クローンが得意とするところです。これにより、インスタンスを2つの動作モード(プライマリまたはセカンダリ)のいずれかに設定できます。プロモータブルクローンは、グループまたは通常リソースを1つだけ含む必要があります。

リソースのモニタリングまたは制約を設定する場合、プロモータブルクローンには、単純なリソースとは異なる要件があります。詳細については、『Pacemaker Explained』(https://www.clusterlabs.org/pacemaker/doc/から入手可)を参照してください。

Hawk2またはcrmshのいずれかを使用してプロモータブルクローンを作成できます。

6.7.1 Hawk2を使用したプロモータブルクローンの作成 #

 

注記: プロモータブルクローンの子リソース

プロモータブルクローンには、プリミティブまたはグループのいずれかを子リソースとして含めることができます。Hawk2では、プロモータブルクローンの作成中に子リソースを作成したり変更したりすることはできません。プロモータブルクローンを追加する前に、子リソースを作成し、必要に応じて設定します。6.4.1項 「Hawk2を使用したプリミティブリソースの作成」または6.5.1項 「Hawk2を使用したリソースグループの作成」を参照してください。

手順 6.8: Hawk2を使用したプロモータブルクローンの追加 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 左のナビゲーションバーから、環境設定 ›  Add Resource (リソースの追加) › マルチステートの順に選択します。

3. マルチステートIDに固有のIDを入力します。

4. 子リソースリストから、マルチステートリソースのサブリソースとして使用するプリミティブまたはグループを選択します。

5. 必要に応じて、メタ属性を変更または追加します。

6. 作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

類似した設定のリソースを多く作成する最も簡単な方法は、リソーステンプレートを定義することです。定義されたテンプレートは、プリミティブ内で参照したり、7.3項 「リソーステンプレートと制約」で説明するように、特定のタイプの制約内で参照することができます。

プリミティブ内でテンプレートを参照すると、そのテンプレートで定義されている操作、インスタンス属性(パラメータ)、メタ属性、使用属性がすべてプリミティブに継承されます。さらに、プリミティブに対して特定の操作または属性を定義することもできます。これらのいずれかがテンプレートとプリミティブの両方で定義されていた場合、プリミティブで定義した値の方が、テンプレートで定義された値よりも優先されます。

Hawk2またはcrmshのいずれかを使用してリソーステンプレートを作成できます。

# crm configure rsc_template
 usage: rsc_template <name> [<class>:[<provider>:]]<type>
        [params <param>=<value> [<param>=<value>...]]
        [meta <attribute>=<value> [<attribute>=<value>...]]
        [utilization <attribute>=<value> [<attribute>=<value>...]]
        [operations id_spec
            [op op_type [<attribute>=<value>...] ...]]

crm(live)configure# rsc_template BigVM ocf:heartbeat:Xen \
   params allow_mem_management="true" \
   op monitor timeout=60s interval=15s \
   op stop timeout=10m \
   op start timeout=10m

crm(live)configure# primitive MyVM1 @BigVM \
   params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1"

crm(live)configure# primitive MyVM1 Xen \
   params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1" \
   params allow_mem_management="true" \
   op monitor timeout=60s interval=15s \
   op stop timeout=10m \
   op start timeout=10m

crm(live)configure# primitive MyVM2 @BigVM \
   params xmfile="/etc/xen/shared-vm/MyVM2" name="MyVM2" \
   op monitor timeout=120s interval=30s

重要: STONITHがない場合はサポートなし

• クラスタにはノードフェンシングメカニズムが必要です。

• グローバルクラスタオプションstonith-enabledおよびstartup-fencingはtrueに設定する必要があります。これらを変更するとサポートされなくなります。

デフォルトでは、グローバルクラスタオプションのstonith-enabledはtrueに設定されています。STONITHリソースが定義されていない場合、クラスタはどのリソースも開始することを拒否します。STONITHリソースが定義されていない場合、クラスタはどのリソースを開始することも拒否します。1つ以上のSTONITHリソースを設定して、STONITHのセットアップを完了します。STONITHリソースは他のリソースと同様に設定しますが、その動作はいくつかの点で異なっています。詳細については、12.3項 「STONITHのリソースと環境設定」を参照してください。

Hawk2またはcrmshのいずれかを使用してSTONITHリソースを作成できます。

リソースが実行中であるかどうか確認するには、そのリソースにリソースの監視を設定しておく必要があります。Hawk2またはcrmshのいずれかを使用してリソース監視を設定できます。

リソースモニタが障害を検出すると、次の処理が行われます。

リソースの監視を設定しなかった場合、開始成功後のリソース障害は通知されず、クラスタは常にリソース状態を良好として表示してしまいます。

通常、リソースは動作中にのみ、クラスタによって監視されます。しかし、同時実行違反を検出するために、停止されるリソースの監視も設定する必要があります。リソースを監視するには、タイムアウト、開始遅延のいずれか、または両方と、間隔を指定します。間隔の指定によって、CRMにリソースステータスの確認頻度を指示します。timeoutまたはstart操作に対するstopなど、特定のパラメータも設定できます。

監視操作パラメータの詳細については、6.14項 「リソース操作」を参照してください。

6.10.1 Hawk2を使用したリソース監視の設定 #

 

手順 6.13: 操作の追加または変更 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 手順6.2「Hawk2を使用したプリミティブリソースの追加」の説明に従ってリソースを追加するか、既存のプリミティブを選択して編集します。

   Hawk2は、最も重要な操作(start、stop、monitor)を自動的に表示し、デフォルト値を提案します。

   提案された各値に属する属性を参照するには、マウスポインタをそれぞれの値に合わせます。

   

   図 6.6: 操作値 #

    

3. timeoutまたはstart操作に対して提案されたstopの値を変更するには、次の手順に従います。

   1. 操作の隣のペンアイコンをクリックします。

   2. 表示されるダイアログで、timeoutパラメータに別の値(例: 10)を入力し、変更内容を確認します。

4. 操作に対して提案されたintervalmonitorの値を変更するには、次の手順に従います。

   1. 操作の隣のペンアイコンをクリックします。

   2. 表示されるダイアログで、intervalに対して監視間隔の別の値を入力します。

   3. リソースが停止されている場合にリソース監視を設定するには、次の手順に従います。

      1. 下にある空のドロップダウンボックスからroleエントリを選択します。

      2. roleドロップダウンボックスから、Stoppedを選択します。

      3. 適用をクリックし、変更内容を確認して操作のダイアログを閉じます。

5. リソース設定画面で変更内容を確認します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

リソースの障害を表示するには、Hawk2で状態画面に切り替えて、関係するリソースを選択します。操作列で、下矢印アイコンをクリックして最近のイベントを選択します。表示されるダイアログに、リソースに対して実行された最近のアクションが一覧表示されます。障害は赤で表示されます。リソースの詳細を表示するには、操作列で虫眼鏡アイコンをクリックします。

図 6.7: Hawk2 - リソース詳細 #

 

crm(live)configure# primitive apache apache \
  params ... \
  op monitor interval=60s timeout=30s

crm(live)configure# primitive apache apache \
   params ...
 crm(live)configure# monitor apache 60s:30s

設定の一部またはすべてをローカルファイルまたはネットワークURLからロードできます。次の3つの異なる方法を定義できます。

ファイルmycluster-config.txtから新しい設定をロードするには、次の構文を使用します。

# crm configure load push mycluster-config.txt

追加した各リソースについて、オプションを定義できます。クラスタはオプションを使用して、リソースの動作方法を決定します。CRMに特定のリソースの処理方法を通知します。リソースオプションは、crm_resource --metaコマンドまたはHawk2を使用して設定できます。

以下のリストは、一般的なオプションを示しています。

すべてのリソースクラスのスクリプトでは、動作方法および管理するサービスのインスタンスを指定するパラメータを指定できます。リソースエージェントがパラメータをサポートする場合、それらのパラメータをcrm_resourceコマンドまたはHawk2を使用して追加できます。インスタンス属性は、crmコマンドラインユーティリティではparams、Hawk2ではParameterと呼ばれます。OCFスクリプトでサポートされているインスタンス属性のリストは、次のコマンドをrootとして実行すると参照できます。

# crm ra info [class:[provider:]]resource_agent

または(オプション部分なし):

# crm ra info resource_agent

出力には、サポートされているすべての属性、それらの目的、およびデフォルト値が一覧されます。

注記: グループ、クローン、またはプロモータブルクローンのインスタンス属性

グループ、クローン、およびプロモータブルクローンリソースには、インスタンス属性がないので注意してください。ただし、インスタンス属性のセットは、グループ、クローン、またはプロモータブルクローンの子によって継承されます。

デフォルトで、クラスタはリソースが良好な状態であることを保証しません。クラスタにこれを行わせるには、リソースの定義に監視操作を追加する必要があります。監視操作は、すべてのクラスまたはリソースエージェントに追加できます。

監視操作には、次のプロパティがあります。

使用可能な制約には3種類あります。

重要: 制約および特定のタイプのリソースに関する制限

• リソースグループの「メンバー」に対してコロケーション制約を作成しないでください。代わりに、リソースグループ全体を指すリソース制約を作成してください。その他のタイプの制約はすべて、リソースグループのメンバーに対して使用しても問題ありません。

• クローンリソースまたはプロモータブルクローンリソースが適用されているリソースで制約を使用しないでください。制約はクローンまたはプロモータブルクローンリソースに適用する必要があり、その子リソースに適用することはできません。

制約を定義する際は、スコアも扱う必要があります。あらゆる種類のスコアはクラスタの動作方法と密接に関連しています。スコアの操作によって、リソースのマイグレーションから、速度が低下したクラスタで停止するリソースの決定まで、あらゆる作業を実行できます。スコアはリソースごとに計算され、リソースに対して負のスコアが付けられているノードは、そのリソースを実行できません。リソースのスコアを計算した後、クラスタはスコアが最も高いノードを選択します。

INFINITYは現在1,000,000と定義されています。この値の増減は、次の3つの基本ルールに従います。

リソース制約を定義する際は、各制約のスコアを指定します。スコアはこのリソース制約に割り当てる値を示します。スコアの高い制約は、それよりもスコアが低い制約より先に適用されます。1つのリソースに対して場所の制約を複数作成し、それぞれに異なるスコアを指定することで、リソースがフェールオーバーするノードの順序を指定できます。

リソーステンプレートを定義したら(6.8項 「リソーステンプレートの作成」を参照)、次のタイプの制約で参照できます。

ただし、コロケーション制約には、テンプレートへの参照を複数含めることはできません。リソースセットには、テンプレートへの参照を含めることはできません。

制約内で参照されたリソーステンプレートは、そのテンプレートから派生するすべてのプリミティブを表します。これは、そのリソーステンプレートを参照しているすべてのプリミティブリソースに、この制約が適用されることを意味します。制約内でリソーステンプレートを参照すれば、リソースセットの代替となり、クラスタ設定をかなりの程度単純化することができます。リソースセットの詳細については、7.7項 「リソースセットを使用して制約を定義する」を参照してください。

場所制約は、リソースを実行できるノード、実行に適したノード、または実行できないノードを決定します。たとえば、場所制約により、特定のデータベースに関連するすべてのリソースを同じノードに配置します。この種類の制約は、各リソースに複数追加できます。すべてのlocation制約は、所定のリソースに関して評価されます。

Hawk2またはcrmshのいずれかを使用して場所制約を追加できます。

7.4.1 Hawk2を使用した場所制約の追加 #

 

手順 7.1: 場所制約の追加 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 左のナビゲーションバーから、環境設定 ›  Add Constraint (制約の追加) ›  Location (場所)の順に選択します。

3. 固有の制約IDを入力します。

4. Resources (リソース)のリストから、制約を定義するリソースを1つまたは複数選択します。

5. スコアにスコアを入力します。スコアはこのリソース制約に割り当てる値を示します。正の値は、次のステップで指定するノードでリソースを実行できることを示します。負の値は、リソースをそのノードで実行すべきではないことを示します。スコアの高い制約は、それよりもスコアが低い制約より先に適用されます。

   使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。

   • ノードで強制的にリソースを実行するには、矢印アイコンをクリックしてAlwaysを選択します。これにより、スコアはINFINITYに設定されます。

   • ノードでリソースを実行しない場合、矢印アイコンをクリックしてNeverを選択します。これによりスコアは-INFINITYに設定され、リソースはそのノードで実行してはならないことになります。

   • スコアを0に設定するには、矢印アイコンをクリックしてAdvisoryを選択します。これにより制約が無効になります。これは、リソース検出を設定してもリソースを制約したくない場合に便利です。

6. ノードを選択します。

7. 作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

図 7.1: Hawk2 - 場所制約 #

 

crm(live)configure# location loc-fs1 fs1 100: alice

crm(live)configure# primitive ping ping \
    params name=ping dampen=5s multiplier=100 host_list="r1 r2"
crm(live)configure# clone cl-ping ping meta interleave=true
crm(live)configure# location loc-node_pref internal_www \
    rule 50: #uname eq alice \
    rule ping: defined ping

crm(live)configure# primitive vip1 IPaddr2 params ip=192.168.1.5
crm(live)configure# primitive vip2 IPaddr2 params ip=192.168.1.6
crm(live)configure# location loc-alice { vip1 vip2 } inf: alice

crm(live)configure# location loc-alice /vip.*/ inf: alice

コロケーション制約は、ノード上で一緒に実行可能な、または一緒に実行することが禁止されているリソースをクラスタに伝えます。コロケーション制約はリソース間の依存関係を定義するため、コロケーション制約を作成するには、少なくとも2つのリソースが必要です。

Hawk2またはcrmshのいずれかを使用してコロケーション制約を追加できます。

7.5.1 Hawk2を使用したコロケーション制約の追加 #

 

手順 7.2: コロケーション制約の追加 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 左のナビゲーションバーから、環境設定 ›  Add Constraint (制約の追加) › コロケーションの順に選択します。

3. 固有の制約IDを入力します。

4. スコアにスコアを入力します。スコアは複数のリソースの場所の関係を決定します。正の値は、リソースを同じノードで実行しなければならないことを示します。負の値は、リソースを同じノードで実行するべきではないことを示します。スコアと他の要因との組み合わせによって、リソースの配置先が決まります。

   使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。

   • 同じノードで強制的にリソースを実行するには、矢印アイコンをクリックしてAlwaysを選択します。これにより、スコアはINFINITYに設定されます。

   • 同じノードでリソースを実行しない場合、矢印アイコンをクリックしてNeverを選択します。これによりスコアは-INFINITYに設定され、リソースは同じノードで実行してはならないことになります。

5. 制約のリソースを定義するには、次の手順に従います。

   1. リソースカテゴリのドロップダウンボックスから、リソース(またはテンプレート)を選択します。

      リソースが追加され、下に新しい空のドロップダウンボックスが表示されます。

   2. この手順を繰り返してリソースを追加します。

      最上位のリソースは次のリソースなどに依存するため、クラスタはまず最後のリソースを置く場所を決め、次にその決定に基づいて依存するものを配置していきます。制約が満たされないと、クラスタは依存するリソースが実行しないようにすることがあります。

   3. コロケーション制約内のリソースの順序を入れ替えるには、リソースの横にある上矢印アイコンをクリックして、その上のエントリと入れ替えます。

6. 必要に応じて、各リソースに追加のパラメータ(Started、Stopped、Promote、Demoteなど)を指定します。リソースの横にある空のドロップダウンボックスをクリックし、必要なエントリを選択します。

7. 作成をクリックして、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

図 7.2: Hawk2 - コロケーション制約 #

 

crm(live)configure# colocation coloc-2resource inf: resource1 resource2

順序の制約を使用して、開始、停止、プライマリへの昇格など、別のリソースが特殊な条件を満たす直前または直後に、サービスを開始または停止できます。たとえば、デバイスがシステムで利用できるようになるまで、ファイルシステムはマウントできません。順序制約はリソース間の依存関係を定義するため、順序制約を作成するには、少なくとも2つのリソースを作成する必要があります。

Hawk2またはcrmshのいずれかを使用して順序制約を追加できます。

7.6.1 Hawk2を使用した順序制約の追加 #

 

手順 7.3: 順序制約の追加 #

 

1. Hawk2にログインします。

   https://HAWKSERVER:7630/

2. 左のナビゲーションバーから、環境設定 ›  Add Constraint (制約の追加) › 順序の順に選択します。

3. 固有の制約IDを入力します。

4. スコアにスコアを入力します。スコアがゼロより大きい場合、順序制約は必須になりますが、そうでない場合はオプションです。

   使用頻度の高い次の値は、ドロップダウンボックスからも設定できます。

   • 順序制約を必須にするには、矢印アイコンをクリックしてMandatoryを選択します。

   • 順序制約を推奨のみにするには、矢印アイコンをクリックしてOptionalを選択します。

   • Serialize: リソースに対して2つの停止/開始アクションが同時に実行されないようにするには、矢印アイコンをクリックしてSerializeを選択します。これにより、1つのリソースの開始が完了しないと他のリソースを開始できなくなります。通常は、起動時にホストに高い負荷をかけるリソースに使用します。

5. 順序の制約の場合、オプションシンメトリックは常に有効にしていてください。これは、リソースを停止するときには逆順で行うという指定です。

6. 制約のリソースを定義するには、次の手順に従います。

   1. リソースカテゴリのドロップダウンボックスから、リソース(またはテンプレート)を選択します。

      リソースが追加され、下に新しい空のドロップダウンボックスが表示されます。

   2. この手順を繰り返してリソースを追加します。

      一番上のリソースが最初に開始され、次に2番目に開始されます。通常、リソースは逆の順序で停止されます。

   3. 順序制約内のリソースの順序を入れ替えるには、リソースの横にある上矢印アイコンをクリックして、その上のエントリと入れ替えます。

7. 必要に応じて、各リソースに追加のパラメータ(Started、Stopped、Promote、Demoteなど)を指定します。リソースの横にある空のドロップダウンボックスをクリックし、必要なエントリを選択します。

8. 変更を確認して、設定を完了します。画面上部に、アクションが成功したかどうかを示すメッセージが表示されます。

図 7.3: Hawk2 - 順序制約 #

 

crm(live)configure# order res1_before_res2 Mandatory: resource1 resource2

場所、コロケーション、または順序の制約を定義するための別のフォーマットとして、resource setsを使用することができます。リソースセットでは、プリミティブが1つのセットでグループ化されます。以前は、これはリソースグループを定義するか(デザインを正確に表現できない場合もあった)、個々の制約として各関係を定義することでこの操作が可能でした。個々の制約として定義した場合、多数のリソースとの組み合わせが増えるにつれて、制約が飛躍的に増加しました。リソースセットを介した設定で、冗長性が必ず低減されるわけではありませんが、定義内容の把握と管理が容易になります。

Hawk2またはcrmshのいずれかを使用してリソースセットを設定できます。

crm(live)configure# primitive vip1 IPaddr2 params ip=192.168.1.5
crm(live)configure# primitive vip2 IPaddr2 params ip=192.168.1.6
crm(live)configure# location loc-alice { vip1 vip2 } inf: alice