他ノードリソース制御機能「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用GUI(web)ツール「pcs(pcsd)」

Pacemaker+Corosyncでクラスタ構成を構築する場合に利用できる設定ツール「pcs(pcsd)」について紹介します。

「Pacemaker」とは

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

Pacemakerは多くの異なるリソースタイプを理解し、それらの間の関係を正確にモデル化できます。Dockerなどのテクノロジーを使用して、クラスタによって管理されているリソースを自動的に分離することもできます。

Pacemakerの概要については、こちらも参照ください。
→クラスタ構成ソフトウェア「Pacemaker」と「Heartbeat」「Corosync」の関係性

「pcs(pcsd)」とは

Pacemaker/Corosync構成ツール「pcs」

「PCS(Pacemaker Configuration Tool)」は、Pacemaker/Corosync構成ツールです。

コマンドラインインターフェースによるpacemaker/corosyncの制御や設定が可能で、ユーザーはPacemakerベースのクラスタについて作成/表示/変更などを行えます。

「pcs」は旧来の「crmsh」に代わるPacemakerクラスタ管理ツールであり、RHEL/CentOS7においては「pcs」の使用が推奨されています。

pcsデーモン「pcsd」

pcsには、pcsデーモン「pcsd」が含まれており、pcsのリモートサーバとして動作し、Web UIを提供します。

pcsdはPacemaker/corosyncとは独立したサービスであり、このデーモンが起動していない状態では、クラスタ構成に使用するpcsコマンドが使用できません。

Web UIへのアクセス

Web UIにアクセスするためには、クラスタに接続可能なブラウザで、pcsdが起動中のどちからのノードの2224ポートにhttps接続します。

ログインするとpcsdのGUI(web)画面が表示され、クラスタ構成/操作などを行えます。

「pcs(pcsd)」のインストール方法

インストール手順

pcs(pcsd)のインストールの前に、関連プロダクトのインストールが必要です。

手順については、こちらのドキュメントを参照ください。
→GitHub →ClusterLabs/pcs(Pacemaker command line interface and GUI)

パッケージ

「pcs(pcsd)」は、主要Linuxディストリビューション(Fedora/Red Hat Enterprise Linux/Debianなど)にパッケージとして組み込まれています。

「pcs(pcsd)」の主な機能

主な機能

・pcsバージョン確認
・クラスタノード認証
・クラスタ作成
・クラスタ起動
・クラスタ停止
・クラスタ状態取得
・クラスタ設定取得
・特定ノードをスタンバイモードに移行
・特定ノードをスタンバイモードから復帰
・特定リソースの手動フェールオーバー
・特定リソースのフェールオーバー履歴の削除
・手動でのフェンシング(STONITH機能によるサーバ再起動) など

主なコマンド

cluster

クラスタオプションおよびノードの設定を行います。

resource

クラスタリソースの作成と管理を行います。

stonith

フェンスデバイスを設定します。

constraint

リソース制約を管理します。

property

Pacemakerのプロパティを設定します。

status

現在のクラスタとリソースの状態を表示します。

config

ユーザーが読みやすい形式でクラスターの全設定を表示します。

まとめ

設定ツール類を利用することで、Pacemaker+Corosyncでのクラスタ環境に関する管理工数を低減化できます。

弊社にご連絡をいただければ、実際の運用面までを考慮したHAクラスタ環境構築についてのご提案も行えます。まずは、お気軽にお問い合わせください。

→お問い合わせ

 

参考元サイト