[Linux35] Pacemaker高可用性クラスター+ HAProxy + fence-virtd + nginx

1.ペースメーカーの紹介


1.1ペースメーカーの紹介


Pacemakerは、Linux環境で最も広く使用されているオープンソースのクラスターリソースマネージャーです。Pacemakerは、クラスターインフラストラクチャ(CorosyncまたはHeartbeat)が提供するメッセージおよびクラスターメンバー管理機能を使用して、ノードおよびリソースレベルの障害検出とリソース回復を実現し、最大限の保証を保証します。クラスターサービスの高可用性。論理機能に関しては、ペースメーカーは、クラスター管理者によって定義されたリソースルールに基づいて、クラスター内のソフトウェアサービスのライフサイクル全体の管理を担当します。この管理には、ソフトウェアシステム全体およびソフトウェアシステム間の相互作用も含まれます。Pacemakerは、実際のアプリケーションで任意のサイズのクラスターを管理できます。強力なリソース依存モデルにより、クラスター管理者はクラスターリソース間の関係(リソースの順序と場所を含む)を正確に記述および表現できます。同時に、あらゆる形式のソフトウェアリソースについて、リソースの起動および管理スクリプト(リソースエージェント)をカスタマイズすることにより、それらのほとんどすべてをリソースオブジェクトとしてPacemakerで管理できます。また、Pacemakerは単なるリソースマネージャーであり、クラスターのハートビート情報を提供しないことを指摘しておく必要があります。可用性の高いクラスターにはハートビート監視メカニズムが必要であるため、多くの初心者は、Pacemaker自体にハートビート検出機能があると常に誤解します。 Pacemakerのハートビートメカニズムは、主にCorosyncまたはHeartbeatに基づいています。

  • pcsd.service:サービス名

1.2PCの紹介


pcs:ペースメーカークラスター管理ツール

  • Pacemakerコミュニティは、2つの一般的に使用されるクラスター管理コマンドラインツール、つまりクラスター管理者によって最も一般的に使用されるpcsコマンドとcrmshコマンドを導入しました。
  • さらに、pcsコマンドラインの使用には、システムにインストールされているペースメーカーおよびcorosyncソフトウェアバージョンに対して特定の要件があることに注意してください。つまり、Pacemaker 1.1.8以降、Corosync2.0以降ではクラスター管理にpcsコマンドラインツールを使用できます。

1.3個の一般的に使用される管理コマンド


cluster:配置集群选项和节点
status:查看当前集群资源和节点以及进程状态
resource:创建和管理集群资源
constraint:管理集群资源约束和限制
property:管理集群节点和资源属性
config:以用户可读格式显示完整集群配置信息

2.インストールと構成


実験環境:1。ファイアウォールがオフになっている2.selinuxが無効になっている


2つのサーバー(それらの間のパスワードを回避するため):
server1:192.168.17.1
server4:192.168.17.4


  • ソフトウェアウェアハウスの構成

vim /etc/yum.repos.d/westos.repo

[dvd]
name=rhel7.6 BaseOS
baseurl=http://192.168.17.1/rhel7.6/
gpgcheck=0
[HighAvailability]
name=rhel7.6
baseurl=http://192.168.17.1/rhel7.6/addons/HighAvailability
gpgcheck=0

  • ペースメーカーとPC、psmiscとpolicycoreutils-pythonをインストールします
yum install -y pacemaker pcs psmisc policycoreutils-python 
ssh server4 yum install -y pacemaker pcs psmisc policycoreutils-python

  • サービスを完全に開く
systemctl enable --now pcsd.service
ssh server4 systemctl enable --now pcsd.service

  • パスワードを設定してください
echo westos | passwd --stdin hacluster 
ssh server4 'echo westos | passwd --stdin hacluster'

  • クラスターノード認証を構成する

pcs cluster auth server1 server4

ここに写真の説明を挿入

  • 2ノードクラスターを作成する

pcs cluster setup --name mycluster server1 server4

  • クラスターを開始します

pcs cluster start --all

pcs cluster enable --all


  • STONITHコンポーネント機能を無効にする

pcs property set stonith-enabled=false

若是不禁用
pcs status 查看状态时会有警告
crm_verify -LV 验证群集配置信息会有错误

ここに写真の説明を挿入

  • VIPを作成する
pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.17.100 op monitor interval=30s
#参数都可以通过pcs resource create --help查看

3.テスト


  • ノードserver1を確認すると、ノードserver1がオンになっていて、VIPが自動的に追加されていることがわかります。

ここに写真の説明を挿入

  • ノードserver1のサービスが停止すると、別のノードserver4が自動的に引き継ぎ、VIPを自動的に追加します

pcs cluster stop server1

ここに写真の説明を挿入
ここに写真の説明を挿入

  • ノードserver1を再起動し、リソースはスイッチバックされず、server4は変更されず、引き継ぎを継続します

pcs cluster start server1

ここに写真の説明を挿入

4.ペースメーカーとHAProxy


4.1構成


  • 両方のサーバーノードにhaproxyがインストールされており、haproxyサービスが閉じられており、構成も同じです。
yum install -y haproxy
systemctl disable --now haproxy.service


  • リソースを作成する

pcs resource create haproxy systemd:haproxy op monitor interval=30s

ここに写真の説明を挿入

  • グループを作成します(2つのリソースを同じノードで管理します)

pcs resource group add hagroup vip haproxy:コマンドの順序に従って、最初にvipを管理し、次にhaproxyを管理します。


  • 訪問:http://172.25.17.100/status

ここに写真の説明を挿入

4.2テスト1:ノードのpcsサービスをオフにします


  • ノードserver4がシャットダウンされ、アイドル状態のノードserver1に自動的に引き継がれます。server4がサービスを再起動した後、元に戻ることはありません。

pcs node standby

pcs node unstandby

ここに写真の説明を挿入
ここに写真の説明を挿入
ここに写真の説明を挿入

4.3テスト2:haproxyサービスを閉じます


  • haproxyサービスをオフにした後、検出されるとシステムは自動的に再びオンにします。ステータスが表示されると、ログにhaproxyが閉じられたことが示されます。

ここに写真の説明を挿入

4.4テスト3:VIPを削除する


  • 削除後、VIPが削除されたことが検出され、自動的に追加されます

ここに写真の説明を挿入
ここに写真の説明を挿入

4.5テスト4:ハードウェアデバイスを無効にする


ip link set down 网卡接口

  • リソースは自動的に別のアイドルノードserver4に引き継がれていることがわかりますが、server1はそれ自体が引き継いでいると見なし、server1の再起動後に表示されます。

ここに写真の説明を挿入
ここに写真の説明を挿入

5.フェンス(クラスターサーバーがアニメーションを中断しないようにする)


フェンス機能:HAクラスター環境では、バックアップサーバーBがハートビートラインを介してデータパケットを送信し、メインサーバーAがまだ稼働しているかどうか、メインサーバーAが多数のクライアントアクセス要求を受信し、サーバーAのCPU負荷が100%の応答に達しているかどうかを確認します。ただし、リソースが使い果たされてサーバーBのデータパケットに応答する方法がない場合(応答データパケットは遅延します)、サーバーBはサーバーAがダウンしていると見なすため、バックアップサーバーBがリソースを取得し、それ自体がメインサーバーになります。サーバーAはしばらく応答しました。サーバーAは自分が上司であり、サーバーBも自分が上司であると感じました。2人はリソースを取得するのに苦労していました。クラスターリソースは複数のノードによって占有されていました。2つのサーバーが同時にリソースにデータを書き込んだため、リソースが破壊されました。リソースのセキュリティと一貫性、この状況の発生は「スプリットブレイン」と呼ばれます。サーバーAが過負荷になり、応答できません。フェンスメカニズムを使用すると、フェンスはサーバーAを自動的に強制終了して、「スプリットブレイン」の発生を防ぎます。

原理:予期しない理由でホストが異常またはダウンした場合、バックアップマシンは最初にFENCEデバイスを呼び出し、次に異常なホストを再起動するか、FENCEデバイスを介してネットワークから分離します。FENCE操作が正常に実行されると、情報がバックアップマシンに返され、バックアップマシンが接続されます。 FENCEのメッセージが成功した後、FENCEはホストのサービスとリソースを引き継ぎ始めました。このようにして、FENCEデバイスは、異常なノードによって占有されているリソースを解放し、リソースとサービスが常に1つのノードで実行されるようにします。

タイプ:ハードウェアフェンス:電源フェンス、電源をオフにして壊れたサーバーソフトウェアを起動しますフェンス:フェンスカード(スマートカード)、ケーブルとソフトウェアで壊れたサーバーを起動します


5.1ホストのインストールと構成をテストする


フェンスホスト:192.168.17.250


  • フェンス-virtd、fence-virtd-libvirt、fence-virtd-multicast、ネットワークモニター、電源マネージャー、カーネルレベル制御仮想マシンをインストールします

yum install -y fence-virtd

yum install -y fence-virtd-libvirt

yum install -y fence-virtd-multicast

  • フェンス情報を書く

fence_virtd -c

ここに写真の説明を挿入
ここに写真の説明を挿入
ここに写真の説明を挿入

  • ディレクトリ/ etc / clusterを作成し、そのディレクトリにカットして、キーファイルを生成します

mkdir /etc/cluster

cd /etc/cluster

dd if=/dev/urandom of=fence_xvm.key bs=128 count=1:キーファイルを生成する

  • フェンス_virtdサービスを再起動します。ポート1229を表示できます

systemctl restart fence_virtd

  • キーファイルを監視対象ノードに転送します(すべてのノードで事前に/ etc / clusterディレクトリを作成します)

scp fence_xvm.key [email protected]:/etc/cluster/

scp fence_xvm.key [email protected]:/etc/cluster/

ここに写真の説明を挿入

5.2検出されたノード構成(クラスターサーバー)


  • すべてのクラスターサーバーにfence-virtをインストールします

yum install fence-virt.x86_64 -y

ssh server4 yum install fence-virt.x86_64 -y

  • フェンスエージェントを見る

stonith_admin -I

ここに写真の説明を挿入

  • フェンスを追加する

pcs stonith create vmfence fence_xvm pcmk_host_map="server1:vm1;server4:vm4" op monitor interval=60s
选项在pcs stonith describe fence_xvm都可以查看到
#pcmk_host_map的值以键值对书写,如下:
#hostname:虚拟机名称

ここに写真の説明を挿入
ここに写真の説明を挿入

  • STONITHコンポーネント機能を有効にする

pcs property set stonith-enabled=true

  • クラスター構成情報を確認する

crm_verify -LV

ここに写真の説明を挿入

5.3テスト1:カーネルを損傷する


  • ノードserver4でテスト:カーネルを損傷し、server4が自動的にシャットダウンされ、再びオンになって監視機能を実現していることを確認します。

echo c > /proc/sysrq-trigger

5.4テスト2:ハードウェアデバイスを無効にする


  • server4ハードウェアデバイスを無効にし、server4が自動的にシャットダウンされ、再びオンになって、監視機能を実現していることを確認してください。

ip link set down eth0

6.lvsとnginx


  • ピースを閉じる

pcs cluster stop --all

pcs cluster disable --all

  • ソースnginxをインストールします

tar zxf nginx-1.18.0.tar.gz

cd nginx-1.18.0

yum install -y gcc pcre-devel openssl-devel:安装gcc、pcre-devel、openssl-devel

vim auto/cc/gcc`
#CFLAGS="$CFLAGS -g"
#注释此行(127行)可以使安装后的二进制文件更小

./configure --prefix=/usr/local/nginx --with-http_ssl_module:スクリプトを構成し、インストールパスとその他のパラメーターを指定します

make && make install

  • 環境変数を構成し、サービスを開始します

cd /usr/local/nginx/sbin/:このディレクトリの可変構成

vim .bash_profile:変数の記述

PATH=$PATH:$HOME/bin:/usr/local/nginx/sbin

source .bash_profile:ファイルを再読み込みして、変数を有効にします

nginx:サービス開始

ここに写真の説明を挿入
ここに写真の説明を挿入

  • 構成ファイル

vim /usr/local/nginx/conf/nginx.conf

117     upstream westos {
    
    
118     server 172.25.17.2:80;
119     server 172.25.17.3:80;
120     }
121 
122 server {
    
    
123     listen 80;
124     server_name demo.westos.org;
125     location / {
    
    
126         proxy_pass http://westos;
127     }
128 }

nginx -t:構文エラーをチェックします

nginx -s reload:構成ファイルを再読み込みします

ここに写真の説明を挿入
ここに写真の説明を挿入

  • テスト:テストホスト構成が解決された後にアクセスします

vim /etc/hosts

192.168.17.1     demo.westos.org

ここに写真の説明を挿入

おすすめ

転載: blog.csdn.net/weixin_46069582/article/details/112645366