前回の記事では、ハートビートデーモンに基づいた高可用性ソリューションの作成について簡単に触れました。 ただし、判明したように、2ノードクラスタよりも複雑なものはそれほど便利ではありません。 問題を研究することで、
Pacemakerプロジェクトの軌跡を
たどりました。 ここで簡単に確認します。
ペースメーカー
公式文書によると、Pacemakerは次の主な機能を備えたクラスターリソースマネージャーです。
- ノードおよびサービスのレベルでの障害の検出と回復。
- ストレージサブシステムの独立性：共有ディスクは必要ありません。
- リソースタイプの独立性：スクリプト化できるすべてのものをクラスター化できます。
- STONITH（Shoot-The-Other-Node-In-The-Head）のサポート-Split-Brainの薬;）;
- あらゆるサイズのクラスターのサポート。
- クォーラムとリソース依存の両方のクラスターのサポート。
- ほぼすべての冗長構成のサポート。
- クラスターのすべてのノードへの構成の自動複製。
- リソースの起動順序と、1つのノードでのそれらの互換性を指定する機能。
- 拡張タイプのリソースのサポート：クローン（多くのノードで実行）および追加の状態（マスター/スレーブなど）;
- 単一のクラスターシェル（crm）、統合された、スクリプト可能。
プロジェクトは、独自のデーモンに加えて、クラスター設定と上記のシェルをサポートし、同じハートビートとcorosyncのサードパーティのものも使用します。 個人的に（著者自身も）corosyncの使用をお勧めします。 一般に、ハートビートスクリプトをサポートしているため、問題はありません。
設置
RHEL / CentOSでは、これ以上簡単なことはありません。
cd /etc/yum.repos.d wget http://www.clusterlabs.org/rpm/epel-5/clusterlabs.repo yum install pacemaker
次に、/ etc / corosync / corosync.conf（corosync.conf.sampleがあります）をやり直して開始します。
/etc/init.d/corosync start
はい。すべてのノードが双方向で解決されるように、DNSを適切に構成することが不可欠です。
ノードを追加するには？ Pacemakerをインストールし、/ etc / corosync / corosync.confと/ etc / ais / authkeys（設定されている場合）をコピーして実行します。 ノードは自動的にクラスターに含まれます。 クラスター構成も自動的にコピーされます。
ノードに障害が発生し、アイロンを交換した場合は？ 同じこと、新しいノードに同じ名前を付け、構成をコピーして開始します。 レポタ。
構成
クラスター構成は単純なXMLです。 ただし、手動で編集することはできません。 構成に対するすべての変更は自動的にバージョン管理され、ノードは構成全体を一度に受信するのではなく、知っているものからの差分のみを受信します。 つまり ノードに障害が発生し、この時点で構成を変更した場合、ノードが戻ると、ノードはすべての変更を受け取ります。
cibadminまたはcrmシェル自体を使用して、構成を操作できます。 たとえば、次のような構成を確認できます。
実際のクラスターオプションに加えて、以下も構成の対象となります。
結び目
ノードを追加する方法はすでにわかっています。 ノードの削除はそれほど難しくありません。ノードでcorosyncを停止してから、構成からノードを削除します。
ノードの半分以上が稼働しているときに定足数が達成されることを忘れないでください。 したがって、クラスターが2つしかない場合は、このオプションを無効にする必要があります。そうでない場合、クラスターのいずれかが落ちた場合、クラスター自体が崩壊したと見なされます。
資源
corosyncに関するリソースは何ですか？ スクリプト化できるものすべて！ 通常、スクリプトはbashで作成されますが、Perl、Python、またはCで作成することを妨げるものは何もありません。スクリプトに必要なのは、開始、停止、監視の3つのアクションを実行することだけです。 一般に、スクリプトはLSB（Linux Standard Base）またはOCF（Open Cluster Framework）に準拠する必要があります-後者はLSBをいくらか拡張し、特別な名前の環境変数を介してパラメーターを転送する必要があります。
ご覧のとおり、かなりの数の既製のエージェント（リソースエージェント）です。 ただし、新しいものを自分で書くことも非常に難しいことはほとんどありません。
リソースを作成するとき、クラス、タイプ、プロバイダー、および名前自体を追加のパラメーターで設定する必要があります。 上記のリスト：ocf-クラス、heartbeat-プロバイダー、IPaddr-エージェントタイプ。
crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 \ params ip=192.168.9.101 cidr_netmask=32 \ op monitor interval=30s
リソースは、ノードへのバインド（リソーススティッキネス）、デフォルトロール（開始、停止、マスター）など、多くの追加パラメーターをサポートします。 リソースグループ、クローン（複数のノードで実行）などを作成する機会があります。
コミュニケーションズ
そもそも、すべての接続には、-INFINITYから+ INFINITYまでの整数の重みがあります。 さらに、結合重量が±INFINITYの場合、それは剛体と見なされます。 他の結合の重みが大きい場合、無視できます。
関係は、リソースのノードへのバインド（場所）、リソースが開始される順序（順序）、およびノード上での共同居住（コロケーション）を決定します。
# crm configure primitive WebSite ocf:heartbeat:apache \ params configfile=/etc/httpd/conf/httpd.conf \ op monitor interval=1min # crm configure colocation website-with-ip INFINITY: WebSite ClusterIP # crm configure order apache-after-ip mandatory: ClusterIP WebSite # crm configure location prefer-pcmk-1 WebSite rule 50: pcmk-1
ここで別のリソース-WebSiteを作成し、ClusterIPと共存するように設定します（ちなみに、-INFINITYはリソースが同じノード上にないことを意味します）。起動順序を決定します。重みを50にしてpcmk-1ノードに配置することをお勧めします。順序を設定するときに、リソースを並列で起動するか、直列で起動するかを指定することもできます。
一般的に、この方法でリソースの依存関係の非常に複雑なチェーンを構築できます。 たとえば、1日の特定の時間にのみ、またはクラスターコンポーネントの状態に応じて、より複雑なルールを設定できると考えると、すべてがさらに興味深いものになります。
ところで、理解を容易にするために、著者はPacemakerにGraphviz形式でグラフを作成する機能を与えました-ptestユーティリティを参照してください。
おわりに
Pacemakerはシンプルで便利ですが、非常に強力で機能が豊富です。 IBM HA MSの後、私はこのプロジェクトを十分に得ることができません:)。 不必要な詳細で投稿を詰まらせないために、そしてさらなる研究のために、あなたは以下の文献を必要とします：
ご清聴ありがとうございました。