過去の記事でLPIC304の体験記を書いたのですが、当時学習した内容を少しずつアップしていこうと思います。
※アップ順番はアルファベット順を予定。
今回は、「Pacemaker」についてです。
※過去の投稿は、一番下にリンクのみ記載しております。
↓LPIC304の体験記はこちら↓
↓使用した参考書はこちら↓
 |
徹底攻略LPIC-Level3-304教科書＋問題集［Version-2-0］対応-徹底攻略シリーズ 
【Pacemakerについて】
■別名
Cluster Resource Manager（CRM）
よって、設定ファイルが.crmであったり、crmコマンドだったりする。
■概要
HAクラスタリソース管理ツール。
マシン間での「サービス起動」「サービス復旧」をコントロールするためのクラスタソフトウェア。
また、クラスタリソースの管理を行う。
クラスタエンジンにはCorosyncを使用する。
■Pacemaker＋Corosync
Corosyncがノード死活監視を行い、
ノードダウンが発生した際には「Pacemaker」でリソース制御（ノード切り離し＋待機系ノードへのリソース引継ぎ）を行う。
「稼働ノード優先順位」「リソース起動順」などの設定に基づいて、どのリソースをどのノード上で動作させるのかを動的に管理。
また、リソースエージェントを実行して監視を行うことで、フェイルカウントにより「リソース停止」→「リソース切替」→「リソース再起動」を行う。
■設定ファイル
/var/lib/pacemaker/cib/cib.xml
■リソースエージェント
クラスタリソースを管理する実行ファイル。
Pacemakerが「リソース起動」「リソース停止」「リソース稼働監視」を行うために使用する。
■クラスタリソース
クラスタが管理するすべてのもの。
代表的なリソースとして、以下のように、さまざまな項目が該当する。
・仮想IPアドレス
・ファイルシステム—ハードディスク上のファイルシステム領域
・Webサーバ—Apache HTTP Server、Nginx
・メールサーバ—Sendmail、Postfix
・アプリケーションサーバ—JBoss、Tomcat
・データベースサービス—MySQL、PostgreSQL
・ディレクトリサービス—OpenLDAP
・仮想マシン全体 など
■排他制御機構
３つ存在する。
①STONITH(ストニス)
ネットワーク越しに相手ノードの電源を強制的に落とす。
停止失敗への対応可能
①STONITH(ストニス)
ネットワーク越しに相手ノードの電源を強制的に落とす。
停止失敗への対応可能
②SFEX(エスエフイーエックス)
共有ディスク上にロック情報を書き込む
停止失敗への対応不可
共有ディスク上にロック情報を書き込む
停止失敗への対応不可
③VIPcheck(ビップチェック)
仮想IPアドレスへpingを行い相手ノードの状態を確認する
停止失敗への対応不可
停止失敗への対応不可
排他制御機構のうちSTONITHは、リソースの停止が失敗してしまった場合にも有効。
通常、フェイルオーバ発生時等のリソース停止はリソースエージェントによって行われるが、
これが何らかの理由で失敗してしまう場合がある。(ex. プロセスが完全に無応答 等)
リソースはクラスタ内に１つのみに保たなければならないため、きちんと停止したことが確認できないとフェイルオーバを継続することはできず、この場合フェイルオーバは失敗となる。
しかし、この場合でも、STONITHを有効にしていれば、停止失敗したノードの電源を強制的に落とすことで、フェイルオーバを継続し、サービスを維持することができる。
■リソースの制約
リソースにおいては、以下の制約を設定することができる。
・location
リソースをどのノードで実行するか、しないのかを定義する。
# pcs constraint location <リソース> <アクション> <ノード[=スコア値]>
リソースRSS1をノードn1で優先実行（スコア値を50）
# pcs constraint location RSC1 prefers n1=50
リソースRCS1をノードn2では実行しない
# pcs constraint location RSC1 avoids n2
・order
リソースを実行する順番を定義。
・colocation
同一リソース上で一緒に実行すべきリソースを定義。
RSC1をRSC2のノードで一緒に実行
# pcs constraint colocation add RSC1 with RSC2
■STONITHプラグイン（Shoot The Other Node In The Head）
監視対象ノードに異常が発生した場合に強制的に停止/再起動させることができ、スプリットブレイン回避につながる。
crmコマンドで確認可能。
Pacemakerに同梱されているSTONITHには、以下のものがある。
・apcmaster
・external/xen0
・ibmhmc
・ssh
よって、scsiは含まれていない。
■クォーラムによる動作制御を解除
２台構成のPacemakerによるクラスタの場合、１台に障害が発生するとクラスタ構成が１台となってしまうため、
正常に動作することができなくなる。
そのため、１台でも動作し続けるように
# pcs property set no-quorum-policy=ignore
パラメータを使用する必要がある。
■リソースの種類について
Primitive, Clone, Master/Slave という大きく分けて3つの種類のリソースが存在する。
また、および、PrimitiveをまとめたGroupというリソースを定義することができる。
■crmコマンド（非推奨）
Pacemakerにおける基本的なコマンドだが、cibadmin,crm,pcsを使用する機会が多い。
cibadmin同様、cib.xmlファイルへの修正反映が可能。
※cibadmin,pcsは後述
crm_shadow
「シャドウ」コピーを作成し、それに対してコマンドを実行してどのような動作になるのか確認することができる。
※実際の環境には何も起こらない。
シャドウの最中は、コマンドのプロンプトが「shadow」となっている。
crm_simulate
クラスタ上で発生したリソース停止や障害などの細かなイベントへの反応をシミュレートし、確認することができる。
crm configure primitive rsc1
crmコマンドで設定を変更する場合はconfigureサブコマンドを利用する。
新しいリソースを追加設定するには、primitiveを指定する。この場合はrsc1というリソースを追加。
■pcsコマンド（推奨）
Pacemakerが管理するサービスでは、起動順序の設定が可能。
Pacemaker/Corosync Configuration Systemの略。
ServiceAはServiceBの後に起動する
# pcs constraint order Service B then ServiceA
2台のノードで構成されたPacemakerクラスタにおいてアクティブサーバが異常停止した場合、no-quorum-policy=freeze を設定しているとフェイルオーバーができない。
そのため、ignoreを設定する必要がある。
# pcs property set no-quorum-policy=ignore
■cibadminコマンド
CIBの情報に基づきクラスタリソースを管理。
CIBの情報（cib.xml）を直接編集することでも管理が可能だが、cibadminコマンドによる編集も可能。
ローカルノードの設定内容を全て表示
# cibadmin -Q --local
■試験料について
15,000円です。
※前は30,000円だったので半額になった。
（2020/1/10更新）
LPIC304関連のブログは下記の通りです。
興味ある方は一度目を通してもらえると、（何かしらの）役に立つ・・・？？
↓LPIC304関連記事はこちら（アルファベット順）↓
