ウェブサイト検索

Corosync と Pacemaker を使用した高可用性の構成

システムやサービスの可用性を向上させ、耐障害性を高めるために使用されるすべての技術と方法は高可用性と呼ばれます。障害の例としては、ハードウェアの冗長性、クラスタリング、ホット物理的データのレプリケーション (RAID 1 および RAID) などが挙げられます。 5) またはソフトウェア (スナップショット、DRBD)、または危機シナリオ (劣化モード、緊急計画)。大企業では、フルタイムで責任ある立場に就く可能性があります。この記事では、この問題の一面を実装するための図、つまりアプリケーション サービスの可用性を確保するアクティブ/パッシブ クラスターについて説明します。

GNU/Linux に関して、この記事ではクラスター インフラストラクチャを管理できる 2 つのソフトウェアをテストしました。

  • ハートビートにはその証拠がありますが、制限があります。3 つ以上のノードからクラスターを構成することはできず、リソースの管理や、あるノードから別のノードに切り替えるためのルールも管理されません。
  • Corosync と Pacemaker: これは Red Hat ディストリビューションの選択であり、この記事の後半で概要を説明します。

クラスターによって管理される IP アドレスによってアクセスされる Apache サービスを実行する、4 つのネットワーク インターフェイスを備えた 2 つの仮想マシン Debian Wheezy で構成される代表的なモデルをマウントしました。

次の図はネットワーク図を表しています。

eth0 および eth1 インターフェイスは論理リンク アグリゲーションの一部であり、クラスターが他のノードのステータスを確認するのに役立ちます。これらは、ネットワーク 10.20.13.0/255.255.255.252 内の他のノードとともにプライベート ネットワークを構成します。インターフェイス eth2 と eth3 は別の論理集合体の一部であり、192.168.1.0/24 ネットワークの外部でサービスを提供します。

論理集約 (ボンディングとも呼ばれます) により、追加の冗長性が提供されます。ネットワーク アダプタ eth0 が故障しても、トラフィックは引き続き eth1 を通過します。アクティブ/パッシブ モードまたはロード バランシング モードで構成できます。

「/etc/network/interfaces/」にある vm-node1 マシンのインターフェイスの構成は次のとおりです。

auto bond0
iface bond0 inet static
  address 10.20.13.1
  netmask 255.255.255.252
  bond_mode active-backup
  bond_miimon 100
  bond_downdelay 200
  bond_updelay 200
  slaves eth0 eth1
auto bond1
iface bond1 inet static
  address 192.168.1.61
  netmask 255.255.255.0
  gateway 192.168.1.1
  bond_mode active-backup
  bond_miimon 100
  bond_downdelay 200
  bond_updelay 200
  slaves eth2 eth3

そして、「/etc/modprobe.d/bonding」のボンディングの設定:

alias bond0 bonding 
alias bond1 bonding

vm-node2 マシンのネットワーク構成は、10.20.13.2 の Bond0 と 192.168.1.62 の Bond1 と対称です。ネットワーク構成が完了したら、クラスターを処理できるようになります。まず、Debian に Corosync と Pacemaker をインストールする必要があります。次の手順を実行します。

apt-get install corosyncpacemaker

次に、Corosync を設定します。クラスタ インフラストラクチャ、つまりノードの状態とグループ内のノードの機能を管理します。このためには、クラスタ内のすべてのノードで共有される認証用のキーを生成する必要があります。 corosync-keygen ユーティリティは、擬似ランダムなキーストロークからこのキーを生成し、その後、このキーを保護して他のノードにコピーする必要があります。

generation of the key from vm-node1
corosync-keygen
mvauthkey/etc/corosync/authkey
chownroot:root/etc/corosync/authkey
chmod400/etc/corosync/authkey
 
copy of the key to vm-node2
scp/etc/corosync/[email :/etc/corosync/authkey

Corosync は、ノード間の通信を可能にする接続リングの概念を提案しています。モデルの一部として、2 つのリングを定義しました。ring0 はプライベート ネットワークを使用するデフォルトの通信リングで、ring1 は残りのトラフィックでスイッチを通過するバックアップ リングです。 Corosync を使用すると、IP アドレスを定義するのではなく、IP/ネットマスクの観点からリングを定義できます。何も変更せずに同じ構成ファイルをすべてのノードにデプロイできるため、これは重要です。

totem {   
    version:2    
    
    #How long before declaring a token lost(ms)   
    token:3000    

    #How many token retransmits before forming a new configuration   
    token_retransmits_before_loss_const:10    

    #How long to wait for joining messages in the membership protocol(ms)   
    join:60    

    #How long to wait for consensus to be achieved before starting a new round of membership configuration(ms)    consensus:3600    

    #Turn off the virtual synchrony filter   
    vsftype:none    

    #Number of messages that may be sent by one processor on receipt of the token   
    max_messages:20    

    #Limit generated nodeids to 31-bits(positive signed integers)   
    clear_node_high_bit:yes    

    #Disable encryption   
    secauth:off    

    #How many threads to use for encryption/decryption   
    threads:0    

    #Optionally assign a fixed nodeid(integer)   
    #nodeid:1234    

    #This specifies the mode of redundant ring,which may be none,active,or passive.   
    rrp_mode:passive    

    interface {       
        ringnumber:0       
        bindnetaddr:10.20.13.0       
        mcastaddr:226.94.1.1       
        mcastport:5405   
    }   

    interface {       
        ringnumber:1       
        bindnetaddr:192.168.1.0       
        mcastaddr:226.94.1.1       
        mcastport:5407   
     }
} 

amf {   
     mode:disabled
} 

service {   
     #Load the Pacemaker Cluster Resource Manager   
     ver:       0   
     name:     pacemaker
} 

aisexec {   
    user:  root   
    group: root
} 

logging {   
    fileline:off   
    to_stderr:yes   
    to_logfile:no   
    to_syslog:yes   
    syslog_facility:daemon   
    debug:off   
    timestamp:on   
    logger_subsys {       
          subsys:AMF       
          debug:off       
          tags:enter|leave|trace1|trace2|trace3|trace4|trace6   
    }
}

この時点で、クラスター インフラストラクチャは配置されていますが、リソースはまったく管理されません。ペースメーカーの役割です。

次のような運用上の制約があります。

  1. 通常の場合、サーバー vm-node1 上で実行されているリソース (Apache サービスとクラスター IP アドレス)。
  2. サービスが到達できない場合、Apache サービスとクラスター IP アドレスは同じサーバー上で実行する必要があります。
  3. Apache サービスがプライマリ サーバーでクラッシュすると、セカンダリ サーバーに切り替わります。
  4. プライマリ サーバーがインターネット ゲートウェイ経由で接続されている場合は、セカンダリ サーバーに切り替わります。

Pacemaker は、テキスト モードで対話するためのユーティリティを提供します。

  • CRM はあらゆる側面の構成を管理します。
  • crm_mon はクラスターの状態を表示します。

まず、グローバル構成を定義します。 STONITH (Shoot The Other Node In The Head) とクォーラムをクエンチしました。 STONITH は、他のノードがインフラ クラスターに接続できなくなった場合に、そのノードを強制終了する機能です。また、クォーラムは 3 ノット以内のクラスタでは機能しません。

property stonith-enabled=false
property no-quorum-policy=ignore

これで、最初のリソースであるアクティブ ノードに接続されたクラスター IP アドレスを定義できるようになりました。

primitive vip ocf:heartbeat:IPaddr2 params ip=192.168.1.60 cidr_netmask=24nic="bond1"op monitor interval="10s"

次に、このモデルで提供したい重要なサービスである Apache リソース:

primitive httpd ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf"statusurl="http://localhost/server-status"op start timeout="60s"op stop timeout="60s"op monitor timeout="20s"

Apache の起動と停止はクラスターによって管理されるようになりました。したがって、サービスの自動開始を削除する必要があります。

update-rc.d-fremoveapache2

これは Apache リソースの定義を超えていることがわかります。 Pacemaker STATUSURL 属性を使用すると、Apache ステータス ページを使用してロッカーを決定できます。したがって、Apache でこの URL を設定することを忘れないでください。

<Location/server-status>    
    SetHandler server-status    
    Order deny,allow    
    Deny from all    
    Allow from 127.0.0.1
</Location>

構成ステップを構築したときに、 crm_mon が動作していなかったために、特定のリソースにエラーが発生した可能性があります。警告が発生した場合に通知する障害カウンターがあります。次のコマンドを使用して、リソース http のこのタイマーをリセットできます。

crm resource clean up httpd

この段階ではクラスタ アドレスと HTTP リソースがありますが、同じノード上にある必要はありません。ノードがドロップダウンされると、vip リソースが切り替わります。ノードがドロップされるか、Apache サービスが起動すると、httpd リソースが切り替わります（URL/サーバーステータスによる監視）。

さらに進んで、両方のリソースを同じノード上で強制的に実行してみましょう。

colocation httpd-with-vip inf : httpd vip

そして、通常の場合でもこれを実現したいと思います。リソースはプライマリ ノードである vm-node1 で実行されます。

location preferred-node vip 100 : vm-node1

最後に、スケール条件を追加します。ノードがインターネット経由でゲートウェイに到達しない場合は、リソースを他のノードに移動したいと考えます。このために、すべてのノードで実行される ping タイプでリソースを定義します（クローン リソースの概念を通じて）。次に、アクティブ ノードがブリッジを認識しない場合に切り替える休暇ルールが追加されます。

primitive ping-gateway ocf:pacemaker:ping params host_list="192.168.1.1"multiplier="1000"op monitor interval="10s"
clone cloned-ping-gateway ping-gateway
location vip-needs-gateway vip rule-inf:not_defined pingd or pingd lte 0

これが私たちの運用モデルです。私たちがそれをお手伝いできることを願っています。