他ノードリソース制御機能「pacemaker_remote」とは

Pacemakerの他ノードリソース制御機能「pacemaker_remote」について紹介します。

Pacemakerとは

Pacemakerは、一連のマシン間で関連する「サービス起動」と「サービス復旧」をコントロールするためのクラスタソフトウェアです。

Pacemakerの概要については、こちらも参照ください。

→クラスタ構成ソフトウェア「Pacemaker」と「Heartbeat」「Corosync」の関係性

他ノードリソース制御機能「pacemaker_remote」とは

概要

pacemaker_remoteとは、Pacemaker本体で他ノード(実マシン/仮想マシン/コンテナ)上のリソースを制御する機能です。

pacemaker_remoteを使用すると、他ノードのリソースを実際のクラスタと同様に管理することが可能となり、高可用性スタックの従来のビューを拡張して、新しいレイヤーを含めることができます。

ユースケース

pacemaker_remoteサービスは、次のようなケースに対応できます。
・Pacemakerクラスタで仮想マシンリソースを管理したいが、Pacemakerがそれらの仮想マシン内に存在するリソースも管理できるようにしたい
・Corosyncの16ノード制限を超えて拡張したい

動作要件

pacemaker_remoteは、Pacemakerからの接続ホストの形で動作し、Pacemakerから接続を行います。

他ノード側には、Pacemaker本体は必要なく「pacemaker_remoteプロセス」と「リソースエージェント」が動作できる環境が必要です。

構成

クラスタノード

クラスタノードとは「CorosyncとすべてのPacemakerコンポーネントの高可用性スタックを実行しているノード」が該当します。

クラスタノードは以下の機能を提供します。
・クラスタリソース実行
・Pacemakerコマンドラインツールの実行(crm_mon/crm_resource)
・フェンシングアクション実行
・クラスタクォーラムカウント
・クラスタ指定コントローラ(DC)機能 など

pacemaker_remote

pacemaker_remoteは「ホストが完全なクラスタスタックを実行せずにPacemakerノードとして使用できるようにするためのサービスデーモン」です。Pacemakerのローカルリソース管理デーモン(LRMD:Local Resource Management Daemon)の拡張バージョンとして機能します。

pacemaker_remoteを実行しているノードでは、クラスタリソースと同様のコマンドラインツールを実行できます。しかし、「フェンシング実行」「定足数投票」「DC適格性」などの機能は実行できません。

リモートノード

リモートノードは「pacemaker_remoteを実行している物理ホスト」を指します。

リモートノードには、クラスタとの通信を管理する特別なリソースがあります。

ゲストノード

ゲストノードとは「pacemaker_remoteを実行している仮想ホスト」を指します。

Pacemakerバージョンサポート

pacemaker_remoteを使用する場合は、「Pacemaker 1.1.12以降」を利用することが推奨されています。

最後に

Pacemakerの拡張機能として利用できる「pacemaker_remote」を活用することで、より効率的なクラスタ環境を構築できるケースもあります。

弊社にご連絡をいただければ、「pacemaker_remoteを適用できるのか?」「適用すべきではないのか?」についてのご提案も行えます。

まずは、お気軽にお問い合わせください。

 

参考元サイト

Pacemakerでのスプリットブレイン復旧手順

DRBD+Pacemaker+Corosyncを用いた冗長化構成における「スプリットブレイン問題の概要」と「基本的な復旧手順」について紹介します。

Pacemakerとは

Pacemakerは、一連のマシン間で関連する「サービス起動」と「サービス復旧」をコントロールするためのクラスタソフトウェアです。

Pacemakerの概要については、こちらも参照ください。

→クラスタ構成ソフトウェア「Pacemaker」と「Heartbeat」「Corosync」の関係性

スプリットブレインとは

プライマリサーバが複数存在

スプリットブレインとは、プライマリ+スタンバイ型クラスタで、ネットワークが分断されてしまい2台のサーバ間の調整が上手くいかず、「両サーバがプライマリサーバとなってしまう状態」を意味します。

発生原因

サーバ1号機(プライマリ)+サーバ2号機(スタンバイ)構成の場合、ネットワーク障害が発生してサーバ同士で通信できなくなると、2号機(スタンバイ)は「1号機(プライマリ)がダウンした」と判定を行いプライマリに昇格します。

この結果、サーバ1号機と2号機の両方がプライマリとして動作してしまうことになります。

スプリットブレインにより引き起こされる問題

スプリットブレインが発生するとさまざまな深刻な問題が発生します。
・2台のサーバが同一IPアドレスを名乗る
・データ更新が行われるとデータ不整合が発生する可能性
・共有ハードディスクのファイルシステム破壊の可能性
・ログ混乱 など

基本的なスプリットブレイン復旧手順

DRBD+Pacemaker+Corosyncによる「プライマリ+スタンバイ」クラスタ構成における基本的なスプリットブレイン復旧手順は次の通りです。

①実アクセスサーバを確認

サーバ1号機とサーバ2号機のどちらに実際にアクセスが行われているかを確認します。

②ネットワークの復旧

ネットワーク障害の原因として「ルーティング異常」「LANケーブル断線」「サーバのネットワークインターフェースカード損壊」などがあります。

問題に対処してネットワーク復旧を行い、サーバ1号機/2号機のそれぞれからネットワーク接続を確認します。

③DRBDの復旧を確認

ネットワーク復旧後、DRBD復旧も確認します。

④同期される側のサーバデータを破棄

サーバ1号機/2号機について「どちらのデータが最新なのか?」について厳重に確認を行い、同期される側のサーバデータ破棄を実行します。

このデータ破棄対象サーバの確認作業は非常に重要であるため、慎重な確認作業が必要です。

⑤DRBDでの同期

DRBD同期を再実行して同期完了により正常状態に復旧します。

最後に

PacemakerでのHA環境構築におけるスプリットブレイン対策として、設計時から、「ネットワーク多重化」「スプリットブレイン発生時の対応手順策定」「運用マニュアル整備によるヒューマンエラー削減」など、さまざまな要因と対策について考慮しておく必要があります。特に、さまざまなネットワークが関わるような環境では、さらに手順が複雑になります。

弊社にご連絡をいただければ、運用開始後のスプリットブレイン発生対策までを含めたトータルでのご提案も行えます。まずは、お気軽にお問い合わせください。

 

参考元サイト

Pacemakerクラスタのアップデート

Pacemakerで構築したクラスタ環境について、「クラスタ環境アップデート」と「ローリングアップデート」の概要について紹介します。

Pacemakerとは

Pacemakerは、一連のマシン間で関連する「サービス起動」と「サービス復旧」をコントロールするためのクラスタソフトウェアです。

Pacemakerの概要については、こちらも参照ください。

→クラスタ構成ソフトウェア「Pacemaker」と「Heartbeat」「Corosync」の関係性

Pacemakerクラスタのアップデート

Pacemakerで構築したHAクラスタシステムの運用開始後に、「Pacemaker自体」や「動作している一部アプリケーション」についてアップデートしなければならない状況が発生することがあります。

アップデートが必要となる主な理由として以下のようなケースがあります。
・アプリケーション脆弱性修正(セキュリティフィックス)
・アプリケーションの重大不具合修正(緊急ホットフィックス)
・アプリケーションの対象バージョンサポート期間終了 など

シングルで動作しているアプリケーションの場合は、「アプリケーション停止」→「アプリケションアップデート」→「アプリケーション再起動」のようなシンプルな手順でアプリケーションアップデート作業を完了できます。

しかし、Pacemakerなどのクラスタソフトウェアでクラスタ構成に組まれたアプリケーションをアップデートする場合には、入念な計画を立てて実施する必要性があります。

Pacemakerクラスタの「ローリングアップデート」

「ローリングアップデート」とは

クラスタ環境でのアップデート手法として「ローリングアップデート」があります。

ローリングアップデートは、各サーバを順番にアップデートしていくことでクラスタ全体をアップデートしていく手法で、サービス継続を維持したままクラスタシステム全体に渡ってアップデートできるというメリットがあります。

主な手順

「サーバ(A):プライマリ」と「サーバ(B):スタンバイ」というシンプルなクラスタ構成の場合、以下のような手順で2台のサーバに対してアップデートを実施します。
①「サーバ(B):スタンバイ」に対してアップデートを実施
②「サーバ(B):スタンバイ」を「サーバ(B):プライマリ」に昇格させる
※「サーバ(A):プライマリ」は「サーバ(A):スタンバイ」に降格
③「サーバ(A):スタンバイ」に対してアップデートを実施
④「サーバ(A):スタンバイ」を「サーバ(A):プライマリ」に昇格させる
※「サーバ(B):プライマリ」は「サーバ(B):スタンバイ」に降格

課題・懸念点

ローリングアップデートには、課題や懸念点が存在します。

アプリケーション互換性が崩れる場合は不可

ローリングアップデート前後の状態として、アプリケーション互換性が維持されている必要があります。

アップデート内容としてプロトコルやデータ形式に変更が加えられる場合は、この手法の採用は困難となります。

複雑なクラスタ構成の場合

複雑なクラスタ構成の場合は、多くのさまざまな要因が絡み合うこととなるため、非常に慎重にアップデート計画を策定する必要があります。

最後に

PacemakerでHA構成を構築した後でも、Pacemaker自体や対象アプリケーションのアップデートは必要になります。

一般的に、クラスタ構成のアップデートは複雑な手順が必要となるため、多くの経験に裏打ちされた高い技術力が必要となるケースが多々あります。

弊社にご連絡をいただければ、運用開始後のアップデートまで考慮したご提案も行えます。

まずは、お気軽にお問い合わせください。

 

参考元サイト

Pacemakerでの「リソースエージェント」とは

クラスタソフトウェア「Pacemaker」で利用される「リソースエージェント」の概要について紹介します。

Pacemakerとは

Pacemakerは、一連のマシン間で関連する「サービス起動」と「サービス復旧」をコントロールするためのクラスタソフトウェアです。

Pacemakerの概要については、こちらも参照ください。

→クラスタ構成ソフトウェア「Pacemaker」と「Heartbeat」「Corosync」の関係性

「リソースエージェント」とは

リソースエージェント(Resource Agent)とは、クラスタリソースを管理する実行ファイルです。クラスタ管理ソフト(Pacemakerなど)が「リソース起動」「リソース停止」「リソース稼働監視」などに使用するプログラムです。

「クラスタリソース」とは

クラスタリソースは「クラスタが管理するすべてのもの」が対象になります。

代表的なリソース例

代表的なリソースとして、以下のように、さまざまな項目が該当します。
・仮想IPアドレス
・ファイルシステム—ハードディスク上のファイルシステム領域
・Webサーバ—Apache HTTP Server、Nginx
・メールサーバ—Sendmail、Postfix
・アプリケーションサーバ—JBoss、Tomcat
・データベースサービス—MySQL、PostgreSQL
・ディレクトリサービス—OpenLDAP
・仮想マシン全体 など

リソース管理標準「OCF(Open Cluster Framework)」

OCF(Open Cluster Framework)とは、リソース管理に関する業界標準です。OCF標準は、基本的にinitスクリプトのLinux Standard Base規則を拡張して作成されています。

Open Cluster Frameworkに準拠するクラスタ管理アプリケーションは、OCF準拠のリソースエージェントを使用してリソースを管理できます。

OCFクラスは「柔軟性が高い」「自己記述型」などの特徴があり、独自で任意のプログラミング言語での実装も可能です。

Pacemakerのリソースエージェント

Pacemakerは、Open Cluster Framework仕様に準拠したリソースエージェントを使用してクラスタリソースの管理を行います。

Pacemakerは、「稼働ノード優先順位」「リソース起動順」などの設定に基づいて、どのリソースをどのノード上で動作させるのかを動的に管理します。

また、リソースエージェントを実行して監視を行うことで、フェイルカウントにより「リソース停止」→「リソース切替」→「リソース再起動」を行います。

リソース設定

リソース設定では主に以下の4つを設定します。
①リソース定義・パラメータ設定
②リソース種類選択—プリミティブリソース、リソースグループ、クローンリソース、マスタ/スレーブリソース
③リソース制約—各リソースが起動するノードや順序のルールを設定
④クラスタ設定—スプリットブレイン時の動作設定

最後に

Pacemakerの構成においてリソースエージェントの設定は重要なポイントです。

弊社にご連絡をいただければ、Pacemakerを使用したHAクラスタ環境構築において、ユーザー様の環境に最適なリソースエージェント設定についてのご提案も行えます。

まずは、お気軽にお問い合わせください。

 

参考元サイト

Pacemaker​用​ログ解析支援ツール​「​pm_logconv-cs​」紹介​

Pacemaker​用​ログ解析支援ツール​「​pm_logconv-cs​」について紹介​します。

「​Pacemaker」とは

Pacemakerは、一連のマシン間で関連する「サービス起動」と「サービス復旧」をコントロールするためのクラスタソフトウェアです。

Pacemakerの概要については、こちらも参照ください。

→クラスタ構成ソフトウェア「Pacemaker」と「Heartbeat」「Corosync」の関係性

​​​​「​pm_logconv-cs​」​とは

概要​​

Pacemaker​用​ログ解析支援ツール「pm_logconv-CS」は、Pacemakerが出力するログ(HAログ)の中から、特に運用面に関係するものについて抽出を行い、分かりやすい内容へ変換して出力するツールです。

Pacemakerログは詳細に出力されるため出力量が多くなります。特に、運用段階においては、大量ログが状況把握の障害となってしまうパターンもあります。

Pacemaker​用​ログ解析支援ツール「pm_logconv-CS」を利用することで、Pacemakerの故障状態などについて、より適切に、より明確に、把握できるようになります。

GitHubページ

→GitHub →linux-ha-japan / pm_logconv-cs

ユースケース

Pacemaker​用​ログ解析支援ツール「pm_logconv-CS」は、次のような状況で効果的に利用できます。

サービス系リソースの故障によるフェイルオーバー発生時

PostgreSQL(prmPgリソース)で故障が発生した場合の状況調査に利用できます。

故障発生ノードのSTONITHを含むフェイルオーバー発生時

ネットワーク経路の故障が発生した場合の状況調査に利用できます。

特徴​

簡易化ログメッセージ出力

Pacemaker​用​ログ解析支援ツール「pm_logconv-CS」は、Pacemakerデフォルトログを分かりやすいログメッセージに変換して出力します。

簡易化ログメッセージは、次のように全体を網羅しています。
・Pacemakerサービス起動時/終了時
・ノート状態変更時
・リソース監視/制御/移行時
・ネットワーク監視障害発見時
・ディスク監視故障検知時
・STONITHリソース監視/制御時
・フェイルオーバーの開始時/終了時 など

→GitHub →linux-ha-japan/pm_logconv-cs →Pacemakerログ解析支援ツール(変換後ログメッセージ一覧)

Pacemakerリポジトリに同梱

Pacemaker​用​ログ解析支援ツール「pm_logconv-CS」は、Pacemakerと共に、Pacemakerリポジトリパッケージに含まれています。別途インストールする必要はなく、Pacemaker導入後に設定をすることで、すぐに利用開始できます。

ただし、Pacemakerのバージョンと、「pm_logconv-CS」バージョンは一致している必要があります。例えば、Pac​​emaker-1.1.15リポジトリパッケージのpm_logconv-csでは、Pacemaker-1.1.16リポジトリパッケージのPacemakerのログを正常に変換できません。

最後に

Pacemaker​用​ログ解析支援ツール​​​「​pm_logconv-cs​」を利用することで、Pacemakerログを抽出して、故障情報などについて適切に取得できるようになります。

弊社にご連絡をいただければ、「実際の運用面までを考慮したPacemakerを使用したHAクラスタ環境構築」についてのご提案も行えます。

まずは、お気軽にお問い合わせください。​

 

参考元サイト