Pacemakerクラスタ構成のバージョンについて_PHPチュートリアル

Pacemaker クラスター構成のバージョンについて

Pacemaker の CIB は、admin_epoch、epoch、num_updates で構成されるバージョンを持ち、ノードがクラスターに参加するとき、バージョン番号のサイズに基づいて、最大のバージョンが統合として使用されます。クラスター全体の構成のバージョン。

admin_epoch、epoch、num_updatesの3つのうち、admin_epochは通常「設定」が変更されるたびに蓄積され、num_updatesは0に設定されます。num_updatesは「ステータス」が変更されるたびに蓄積されます。 「構成」とは、クラスター属性、ノードの永久属性、リソース属性などを含む、永続 CIB の構成ノードの下にあるコンテンツを指します。 「ステータス」とは、ノードの再起動属性、ノードが生きているか死んでいるか、リソースが開始されているかどうかなどの動的なものを指します。

「ステータス」は通常、(RA スクリプトの設計に問題がない限り) モニターを通じて再取得できますが、「構成」エラーがクラスター障害を引き起こす可能性があるため、エポックの変更とノード後のクラスター構成についてより注意する必要があります。インパクトが追加されます。特に、マスター/スレーブ アーキテクチャをサポートする一部の RA スクリプトは、構成を動的に変更します (mysql の mysql_REPL_INFO
や pgsql の pgsql-data-status など) 構成が矛盾した状態になると、クラスター障害が発生する可能性があります。

1. マニュアルの説明

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html-single/Pacemaker_Explained/index.html#idm140225199219024

3.2. ノード参加時の設定バージョンクラスターでは、以下のフィールドに基づいて誰が最適な構成を持っているかを確認し、最も高い (admin_epoch,epoch,num_updates) タプルを持つノードに、すべてのノードの構成を置き換えるように要求します。これにより、設定が行われます。それらを正しく設定することは非常に重要です。

表3.1. 構成バージョンのプロパティ

フィールド	説明
admin_epoch	これを使用して、非アクティブなノードで構成を行うことはできません。廃止されました。この値をゼロに設定しないでください。そのような場合、クラスターは、設定と、ディスク上に何も見つからないときに使用される「空の」設定との違いを見分けることができません。
エポック	設定が変更されるたびに増分されます更新されました (通常は管理者によって)
num_updates	構成またはステータスが更新されるたびに増加します (通常はクラスターによって)

2. 実際の検証

2.1環境

OS：CentOS 6.3
Pacemaker：1.1.14-1.el6（ビルド：70404b0）
Corosync：1. 4. 1-7.


2.2 基本的な検証

0. Initial epoch="48304", num_updates="4"

[root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
1. 
   

1. クラスターを更新します設定により、エポックが 1 増加され、num_updates が 0 にクリアされます

[root@srdsdevapp69 mysql_ha]# crm_attribute --type crm_config -s set1 --name foo1 -v "1"
1. 
   
[root@srdsdevapp69 mysql_ha]# cibadmin - Q |grep epoch
2. 
   

2. 更新された値が既存の値と同じ場合、エポックは変更されません

[root@srdsdevapp69 mysql_ha]# crm_attribute --type crm_config -s set1 --name foo1 -v " 1.ha] # crm_attribute -N `hostname` -l ever -n foo2 -v 2
1. 
   
[root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
2. 
   

4. ライフサイクルが再起動されるノード属性を更新します。 num_updates が 1 増加します

[root@srdsdevapp69 mysql_ha]# crm_attribute -N `hostname` -l reboot -n foo3 -v 2
1. 
   
[root@ srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
2. 
   

2.3 パーティションの検証
1. srdsdevapp69 と他の 2 つのノード間のネットワーク分離は、前に DC (指定コントローラー) を形成するために引き起こされます。パーティションは srdsdevapp73

1. 
   [root@srdsdevapp69 mysql_ha]# iptables -A INPUT -j DROP -s srdsdevapp71
2. 
   [root@srdsdevapp69 mysql_ha]# iptables -A OUTPUT -j DROP -s srdsdevapp71
3. [root@ srdsdevapp69 mysql_ha]# iptables -A INPUT -j DROP -s srdsdevapp73

[root@ srdsdevapp69 mysql_ha]# iptables -A OUTPUT -j DROP -s srdsdevapp73

2 つのパーティションのエポックは変更されていません48306、ただし、srdsdevapp69 はそれ自体を独自のパーティションの DC として使用します。

パーティション 1(srdsdevapp69): クォーラムが取得できません
1. 
   
[root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
2. 
   
3. 
   
4. パーティション 2(srdsdevapp71,srdsdev) app73): クォーラムを取得

[root @srdsdevapp71 ~]# cibadmin -Q |grep epoch

1. 
   
2. 2. srdsdevapp69 で 2 つの構成を更新して、エポックを 2 つ増やします
1. [root@srdsdevapp69 mysql_ha]# crm_attribute --type crm_config -s set1 --name foo4 -v "1"
   
2. [root@srdsdevapp69 mysql_ha]# crm_attribute --type crm_config -s set1 --name foo5 -v "1"
   
3. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep epoch
   

3.在srdsdevapp71上で1次構成更新、そのepochを追加1

1. [root@srds] devapp71 ~]# crm_attribute --type crm_config -s set1 --name foo6 -v "1"
   
2. [root@srdsdevapp71 ~]# cibadmin -Q |grep epoch
   

4.恢复网络再检查集合群の構成

1. [root@srdsdevapp69 mysql_ha]# iptables -F
   
2. [root@srdsdevapp69 mysql_ha]# cibadmin -Q |grep
   
3. 
   
4. [root@srdsdevapp69 mysql_ha]# crm_attribute --type CRM_CONFIG -S SET1 - NAME FOO5-Q
   
5. 1
   
6. [root@srdsdevapp69 mysql_ha]＃crm_attribute -Type CRM_CONFIG -S SET1 -NAME FOO4 -Q
   
7. 1
   
8. [root@srdsdevapp69 mysql_ha ]# crm_attribute --type crm_config -s set1 --name foo6 -q
   
9. 操作の実行中にエラーが発生しました: そのようなデバイスまたはアドレスはありません
可能発行现集群採用了srdsdevapp69分区の構成、原因它的バージョン更新srdsdevapp71、srdsdevapp73 で行われた更新が失われています。
2.4 セグメントテスト 2

前のテストでは、QUORUM を取得しているパーティション内でパーティション前の DC が生成され、次の再テストで QUORUM を取得していないゾーン内で生成されます。 人は造成DC(srdsdevapp73)と他の2つのポイントのネットワーク隔離离を形成します



[root@srdsdevapp73 ~]# iptables -A INPUT -j DROP -s srdsdevapp69

1. [root@srdsdevapp73 ~]# iptables -A出力-j DROP -s srdsdevapp69
   
2. [root@srdsdevapp73 ~]# iptables -A INPUT -j DROP -s srdsdevapp71
   
3. [root@srdsdevapp73 ~]# iptables -A OUTPUT -j DROP -s srdsdevapp71
   
4. srdsdevapp73上のepoch没有变
[root@srdsdevapp73 ~]# cibadmin -Q |grep epoch

1. 
   
しかし另一分区(srdsdevapp69,srdsdevapp71)上のepoch追加1了

[root@srdsdevapp69 ~]# cibadmin -Q |grep epoch

1. 
   
恢复网络後集群採用了版本号更高的配置，DC 然是分区前的 DC(srdsdevapp73)

[root@srdsdevapp73 ~]# iptables -F

1. [root@srdsdevapp73 ~]# cibadmin -Q |grep epoch
   
2. 
   
通过这个测试可播放：

DC协商会导致epoch加1

分区恢复後，ペースメーカー分区前の DC を新しい DC として使用する予定です

• 3. 概要

  Pacemaker の動作特性
  
  1. CIB 設定の変更によりエポックが 1 増加します
  2. DC ネゴシエーションによりエポックが 1 増加します
  3. パーティションの回復後、Pacemaker はより大きいバージョン番号を採用しますクラスター構成
  4. パーティションの回復後、Pacemakerはパーティション分割前のDCを新しいDCとして使用する傾向があります
  
  
  RA開発時の注意点
  
  1. クラスター構成を動的に変更しないようにしてください
  2. 最初のポイントが実行できない場合は、複数の動的クラスター構成の使用を避けるようにしてください。パラメーター、たとえば、複数のパラメーターを 1 つに結合できます (mysql の mysql_REPL_INFO がこれを行います)
  3. crm_attribute エラーを確認して再試行します (pgsql がこれを行います)
  4. リソース停止処理 (demote、 stop) クォーラムが失われたとき クラスター構成の変更を避ける
  
  
  
  http://www.bkjia.com/PHPjc/1119677.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/1119677.html技術記事 Pacemaker クラスター構成のバージョンに関して、Pacemaker の CIB は、ノードがクラスターに参加すると、バージョン番号のサイズに基づいて、admin_epoch、epoch、num_updates で構成されるバージョンを持ちます...
  。