Comments(9)高度な設定リモートマシンからの接続Pacemakerがインストールしてあれば、異なるクラスタのマシンにも接続できます。いくつかの環境変数を設定して通常と同じコマンドを実行することで可能です。デフォルト説明CIB_user$USER接続を行うユーザー。対象ホストのhaclientグループである必要がある。CIB_passwdユーザーのパスワード。設定していない場合にはコマンドラインから読み込む。CIB_serverlocalhost接続するホスト。CIB_port接続を行うポート番号。CIB_encryptedTRUEネットワークトラフィックを暗号化するかどうか。c001n01がアクティブなクラスタノードで、1234ポートで接続をリスンしている、haclientグループのsomeuserとします。以下のコマンドを実行すると、someuserのパスワードを求め、そして現在のクラスタの設定を返します。-Qセキュリティ上の理由から、クラスタはデフォルトではリモート接続をリスンしていません。リモートアクセスを行いたい場合には、remote-tls-port(暗号化)またはremote-clear-port(非暗号化)のCIBプロパティーを設定する必要があります。(これらはnum_updateやepochなどのようにcibタグに保存されます。)リモートアクセスのための特別な最上位CIBプロパティーフィールドデフォルト説明remote-tls-portnoneこのポートで暗号化されたリモート接続をリスンする。remote-clear-portnoneこのポートで平文のリモート接続をリスンする。定期的な処理を実行する時間を指定する定期的なアクションは、デフォルトではそのリソースが開始した時点に応じて決まります。14:32にリソースを開始した場合、バックアップを24時間ごとに取得する設定にしたばあい場合には、バックアップが常に業務時間内に行われることになります。これは適切ではありません。動作の基準とする時間はinterval-originで指定します。クラスタはこの時点で動作するように、起点+(間隔×N)で求められるstart-delayを計算します。動作の間隔が24hで、interval-originが02:00であり、現在14:32だった場合、クラスターは11時間28分のstart-delayで動作を開始します。intervalとinterval-originに指定できる値はISO8601に準じます。2009年の最初の月曜以降の毎月曜に動作させたいのであれば、以下のようになります。interval-origin="2009-W01-1"/>リソース障害に対処するリソースに障害が起きた場合、Pacemakerはデフォルトではリソースを再起動します。この時に行うオペレーションは細かく設定することができます。monitor等)ごと障害回数(フェイルカウント)を記録しています。crm_failcountコマンドを使用することでリソースの全動作のフェイルカウントを確認することができます。以下の例では、node1ノードでmyrscリソースのmonitorが10秒間に何回障害が起きたかを表示します。10sノード名を指定しない場合にはローカルノードの情報が表示されます。動作とインターバルを指定しない場合にはノードで起きたそのリソースのすべてのオペレーションのフェイルカウントが表示されます。–deleteコマンドを使用します。上記のフェイルカウントを消したい場合には以下のコマンドを使用します。10sここでリソース名を省略した場合には、全リソースのフェイルカウントを消去します。ノードを省略した場合には、全ノードが、オペレーションとインターバルを省略した場合にはそのノードの全オペレーションが消去されます。一つのオペレーションのみを消去した場合であっても、すべてのオペレーションのフェイルカウントが消去されます。この際にはリソースの現在の状態の再チェックが行われます。–failcountsコマンドでリソースごとのフェイルカウントを確認することもできます。稼働中のリソースに障害が発生した場合、Pacemakerは一度停止させてから再起動を試みます。Pacemakerは都度適切な場所を選んで起動しようとしますが、また同じノードで起動して再度障害が起きてしまう可能性があります。繰り返しリソースに障害が起きる場合には、そのノードには何かの問題があると考えられるため、別のノードで起動したほうがよく、このような場合にはmigration-thresholdというメタ属性を使用します。リソースにmigration-threshold=Nを設定すると、N回障害が起きると以後そのノードでは起動が禁止されます。フェイルカウントがオペレーションごとに記録されていても、migration-thresholdはリソースごとに扱われます。オペレーションのフェイルカウントはmigration-thresholdに対しては合算して扱われます。-deleteコマンドを使用するまではフェイルカウントはそのまま残っています(フェイルカウントを消去する前に障害原因を解消してください)。failure-timeoutをリソースメタ属性に設定することでフェイルカウントを自動的に期限が来たら消すことができます。オペレーションが成功しても、その過去分のフェイルカウントは消えません。定期的なmonitorオペレーションが一回失敗し、その後問題なく動作していて、後日再度失敗したような場合、フェイルカウントは2です。フェイルカウントは手動でクリアするか、failure-timeoutが過ぎた場合にのみ消去されます。migration-threshold=2とfailure-timeout-60sを設定していた場合には、2回の障害後に別のノードにリソースが移動し、1分後に(resource-stickinessと制約条件にもよりますが)元のノードに戻ることができるようになります。failure-timeoutは一番新しい障害の時点から計測されます。このため古い障害が個別にタイムアウトしてフェイルカウントが減っていくことはありません。タイムアウト時間内に新しい障害が発生しなければ、すべてのフェイルカウントが同時にタイムアウトして、0にリセットされることになります。migration-thresholdに関しては2つの例外があります。それはリソースのstartオペレーションに失敗した場合と、stopオペレーションに失敗した場合です。クラスタプロパティのstart-failure-is-fatalがtrueに設定されていると(デフォルト)、リソースのstartに失敗した場合にはフェイルカウントがINFINITYになり、即座にリソースは別のノードに移動します。stopに失敗した場合には少々異なる動作になります。リソースのstopに失敗した時にSTONITHが有効であれば、リソースを他の場所で起動できるようにそのノードはフェンシングされます。STONITHが無効であれば、クラスタは何もせず、また他の場所で起動も行いません。failure-timeoutの経過後に再度stop処理を行おうとします。リソースの移動リソースを手動で移動するリソースを現在の場所から別のノードに移動させたい場合には基本的には2つのケースがあると思います。ノード全体をメンテナンスする場合と、リソース単独で移動させたい場合です。スタンバイモードリソースをあるノード上で動作させたくない場合はスコアを調節によって可能です。この際、直接スコアを調節するのではなく、crm_standbyコマンドを使う事で楽に操作できます。以下のコマンドでコマンドを実行したノードをスタンバイモードにすることができ、このノード上で全てのリソースが起動できなくなります。onスタンバイモードを解除する場合には以下のコマンドを実行します。offまた、現在ノードがスタンバイ状態であるかはcrm_monコマンドで確認できますが、以下でも確認ができます。-Gcrm_standbyコマンドは、–nodeオプションを付けると他のノードに対しても操作や確認が可能です。リソースを単独で移動するリソースを1つだけ移動させたい場合には、位置制約を用いてこれを行う事ができます。crm_resourceというコマンドを使って行えます。sles-1ノードでEmailというリソースが動作していて、sles-2ノードに移動させたい場合には以下のコマンドを使います。sles-2上記のコマンドを実行すると、背後では以下のような位置制約が設定されています。score="INFINITY"/>ただし、このコマンドは累積的な効果を持たない点に注意してください。以下のコマンドを続けて実行した場合には、最初のコマンドは無視されることになります。sles-3リソースをもとの場所に戻す場合には以下のコマンドを実行します。Emailしかしながら、resource-stickinessの設定によっては戻りません。-Uを実行する前にsles-1に移動させておきます。Emailあるいは、現在のノードでリソースを稼働させたくない場合には以下のコマンドを実行してもよいでしょう。Emailこの場合には以下の位置制約が設定されることになります。score="-INFINITY"/>この位置制約の設定を消したい場合にも、以下のコマンドを実行することで行えます。Email接続状態に応じてリソースを移動するクラスタ外部への接続ができなくなった際にリソースを移動させる設定を行うことも可能です。接続状態をPacemakerに伝えるocf:pacemaker:pingリソースを追加することで、pingdが指定のマシン(DNSホスト名またはIPv4/v6アドレス)にpingが到達するかどうかをチェックし、この結果をノード属性に渡します。通常はpingリソースはすべてのクラスタノードで動作する必要があるため、クローンを作成します。以下にパラメータとあわせてテンプレートとなる例を示します。pingリソースのオプション:フィールド説明dampen状態変化を起こすのを待つ時間。複数のクラスタノードが微妙に異なる時間で接続を失ったことを検知した場合に、クラスタ状態があわただしく動くのを避けるために用いる。multiplier接続できているpingノードが加算される数字。複数のpingノードが設定されている場合に有効。host_list接続状況を確認するために使用するマシン。DNSホスト名かIPv4またはv6のIPアドレスを指定する。</primitive></clone>接続状態による判断をPacemakerに伝える接続状態に関する情報を扱うには様々な方法があります。基本的なものは、接続できないノードでクラスタを動作させないものです。以下の例は1つのping確認先(例:デフォルトゲートウェイ)を設定するものです。</rule></rsc_location>あるいは、最も接続状態がよいノード1つだけを選ぶこともできます。この時、multiplierをresource-stickinessよりも大きくなるように設定します。</rule></rsc_location>リソースのマイグレーション通常リソースを移動する場合にはリソースは再起動されます。Xenの仮想ゲストなどは状態を保ったまま移動させることができます(ライブマイグレーションやホットマイグレーションとも呼ばれます)。Pacemakerではこれをリソースマイグレーションと呼んでおり、再起動なしに移動させる設定を行うことができます。すべてのリソースのマイグレーションができるわけではありません。条件を満たしたもののみです。元のロケーションでリソースが正常な状態でアクティブであること、かつ新旧両方のロケーションでリソースが正常に動作できることクラスタはリソースエージェントに2つの特別なアクションを要求することでpushとpullのマイグレーションモデルに対応しています。migrate_to(現在のロケーションで実行)とmigrate_from(行先で実行)です。ノードの健全性チェッククラスタメンバシップのうえではノードが正常に動作しているように見えても、実際には「不健全な」状態であることがあります。SMARTエラーが出ていたり、CPU負荷が高いような場合です。Pacemakerはそのような不適切なノードからリソースを移動させる手段を提供します。ノード健全性属性Pacemakerは#healthで始まるノード属性をノード健全性の使用として使用します。状態red不健全yellow不健全な状態になろうとしているgreen健全な状態integerノードにあるすべてのリソースに適用する数字(0または正の値は健全、負の値は不健全)ノード健全性ストラテジーPacemakerはすべてのノード健全性属性の値の合計値として、ノード健全性スコアを各ノードに与えます。この値はノードの全リソースに適用される位置制約として使用されます。node-health-strategyクラスタオプションはノード健全性属性の変化への反応やred,yellow,greenのスコアへの換算を制御します。効果noneノード健全性属性を確認しないmigrate-on-redredに-INFINITYを与え、yellowとgreenに0を与える。いずれかのリソースがredの場合にはノードからすべてのリソースが移動する。only-greenredとyellowに-INFINITYを与え、greenに0を与える。いずれかのリソースがredかyellowの場合にノードからリソースが移動するprogressiveredにnode-health-redクラスタオプションの値を与え、yellowにnode-health-yellowの値を与え、greenにnode-health-greenの値を与える。各ノードはnode-health-baseのスコアを追加的に与えられる(そのためもしいくつかの属性がyellowだったとしてもリソースが起動できるようになる)。このストラテジによって各値の重要度をより細かく管理できるようになる。customred,yellow,greenについてprogressiveと同じ値を使用してノード健全性を確認する。管理者はノード健全性属性を参照するruleを定義したポリシーを実装することが求められる。ノード健全性の計測Pacemakerはノード健全性をノード属性から算出するので、ノード属性を設定する操作はノード健全性に影響します。一般的にはリソースエージェントや、個別のデーモンです。Pacemakerはそのまま、あるいはカスタムして使用できる雛型を用意しています。ocf:pacemaker:HealthCPUおよびocf:pacemaker:HealthSMARTリソースエージェントはCPUとディスクパラメータに基づきノード健全性を設定します。ノード健全性属性を設定します(ocf:pacemaker:SystemHealthリソースエージェントは、デーモンをクラスタリソースとして扱うことができます)。設定変更後のサービスのリロードクラスタは管理するサービスの設定変更があると自動的に検知します。通常は(古い設定を使って)停止してから(新しい設定を使って)起動します。再起動をせずに新しいオプションのセットを使うことができます。この機能を使うためにはリソースエージェントは以下の条件を満たしている必要があります。reloadオペレーションに対応し、要求されるアクションを行えること。アクションについてはアプリケーションに依存します。reloadコマンドで、影響のある1つまたは複数のパラメータが通知されること。以下のようにしてuniqueセットが0のすべてのパラメータが対象。default="${OCF_RESKEY_drbdconf_default}"/></parameter>これらの条件を満たしていれば、uniqueでないフィールドの変更があった時にクラスタは自動的にリロードしたリソースを検知します。注記:メタデータはリソースが起動時にしか再読み込みされません。そのためPacemakerでunique=0に変更していたとしても、最初にリソースが再起動されます。注記:同時にuniqueと非uniqueのフィールドが変更された場合には、リソースは再起動します。コメントをキャンセル次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。