10pcm
https://blog.51cto.com/superpcm/2095395
1. keepalivedの高可用性ソフトウェア
keepalivedのソフトウェアは、もともと管理し、LVSクラスタシステムの各サービスノードの状態を監視するために設計されたLVS負荷分散ソフトウェア用に設計された、と後でVRRPは、高可用性機能を実現することができ加わりました。そのため、管理にkeepalivedのほかには、ソフトウェアをLVS、だけでなく、他のサービスの高可用性ソフトウェアソリューションとして使用することができます。
keepalivedのソフトウェアは、VRRPプロトコルを介して高可用性機能を実現することです。VRRPは仮想ルータ冗長プロトコル（仮想ルータ冗長プロトコル）の頭文字で、目的は、個々のノードがダウンしたときに、ネットワーク全体が中断されずに実行できるようにすることができVRRPは障害スタティックルーティングの単一のポイントを見える解決することです。だから、一方ではLVS構成管理機能をkeepalivedの、だけでなく、LVSノードのヘルスチェックのために以下の機能があり、一方で、システムのネットワーク・サービスの高可用性機能を実現することができます。
転送の2 keepalivedの高可用性フェールオーバーの原則
高可用性サービスのサポートとの間にkeepalivedのフェールオーバーの移行は、VRRPによって達成されます。サービス作業をkeepalivedの場合は、メインのマスターノードが生きているバックアップバックアップノードを伝えるために使用されるスタンバイノードに（マルチキャストモード）ハートビートメッセージを送信し続けます。プライマリノードに障害が発生した場合、ハートビート・メッセージを送信することができない、スタンバイノードは、マスタノードのハートビートの到着を検出し、したがって続けることができません。彼らは自分自身を呼び出すように、マスターノードのIPリソースとサービスを引き継ぐために、プログラムを引き継ぎます。ときにマスターノードの回復、スタンバイ・ノードは、プライマリノードに障害が発生したときに引き継ぐために、元のスタンバイの役割に戻すに独自のIPリソースとサービスをリリースします。
3. keepalivedの可用性実験環境の説明
以下に示すように、2つのフロントエンドnginxのロードバランサは、クライアントから受信した要求を分配します。前のテキストが設定されているNginx01、Nginx02は同じ構成です。今Nginx02スタンバイノードとして、マスタノードとして2つのロード・バランサnginxの高可用性構成、Nginx01で行います。
keepalivedのをインストールし、有効化4
keepalivedのインストールでは、インストールするには、非常に単純な、直接使用YUMです。
yum install keepalived -y
インストール後、keepalivedのサービスを開始し、スクリプトの起動を書くための方法は、外出先の内部をkeepalivedの。。
/etc/init.d/keepalived star
echo "/etc/init.d/keepalived start" >>/etc/rc.local
プロセスを開始した後3があるだろう、何の問題は、次の設定ファイルを変更するためにkeepalivedの、keepalivedのソフトウェアの後にオフにすることはできません。
5.変更は、設定ファイルをkeepalivedのサービスを再起動しますkeepalivedの
/etc/init.d/keepalived stop #关闭keepalived服务
vim /etc/keepalived/keepalived.conf #用vim打开编辑
マスターノード構成ファイル
! Configuration File for keepalived
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id lb01
}
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 55
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.31.5/24 dev eth1 label eth1:1
}
}
......
ノード構成ファイルの準備
! Configuration File for keepalived
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id lb02
}
vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 55
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.31.5 dev eth1 label eth1:1
}
}
......
注：いくつかのパラメータの意味を説明するために、以下、主に太字上記のいくつかの場所で設定ファイルを変更します。
- ROUTER_ID経路は一意である必要があり、ローカル・エリア・ネットワーク内で識別されます。
- VI_1 vrrp_instance {...}これは、スタンバイ状態keepalivedの、インターフェース、優先度、およびIP認証情報を定義するVRRPの例です。
- VRRP状態がvirtual_router_id IDを識別し、インターフェースの定義が私のサーバーのネットワークカードを使って、ここで使用されるインターフェイスの役割は、実際の塗りつぶしによると、eth1のある仮想ルーティングを定義し、keepalivedの設定し、マスタとスレーブのセットは同じ、優先順位を設定しています優先順位は、より多数、高い優先順位は、AUTH_TYPEは、認証され、auth_passパスワード認証です
- virtual_ipaddress仮想IPアドレスを定義する{...}、あなたは私が192.168.31.5のように定義された複数のIPアドレスを設定することができ、バインドされたネットワークインターフェイスeth1の、仮想インターフェイスeth1の：1
マスターノードを変更した後に良い、保存して終了され、その後、keepalivedの開始、数分以内に仮想IPを生成します：192.168.31.5
次に、仮想IPを生成しない、keepalivedの終了の保存を開始し、設定ファイルのバックアップノードを変更し、生成された場合は、設定ファイルにエラーが発生しました。スタンバイ・ノードとマスターノードのIPリソースの競合は、このような現象は、「スプリットブレイン」と呼ばれています。
スタンバイは、高可用性サーバー6.実験を切り替えます
keepalivedのは、VIPが生成されますバックアップノードを表示するには、マスターノードにサービスを提供停止：192.168.31.5
keepalivedのマスターノードのサービスを開始し、その後、マスタノードとバックアップノードのVIPを表示し、マスターノードは、バックVIPを奪う必要があります。
テストにnginxので均衡7.ロード
修改windows的hosts文件，把域名指向到VIP上
然后用浏览器打开www.pcm.com的页面，在web01上查看access.log日志记录到的客户端IP地址
可以看到日志记录到的客户端的IP地址是192.168.31.1，反向代理服务器是主服务器192.168.31.3.下面我们停止keepalived服务，看备节点会不会接替主节点的VIP和服务。
可以看到，备节点确实接替了主节点的工作。重新启用主节点，实验的结果就不验证了。
8.编写Nginx Web服务的守护脚本
上面的实验测试有一个问题就是，我们是用Nginx做负载均衡分发请求的数据包的。如果主节点的Keepalived服务正常运行，而Nginx运行异常，那么将会出现Nginx负载均衡服务失灵，无法切换到Nginx负载均衡器02上，后端的Web服务器无法收到请求。所以，我们应该要检测Nginx的服务是否正常运行，如果不是正常运行，应该停掉Keepalived的服务，这样才能自动切换到备节点上。
我们可以通过检测80端口是否开启来判定Nginx的运行情况，2秒钟检测一次，脚本如下
#!/bin/bash
while true
do
if [ $(netstat -tlnp|grep nginx|wc -l) -ne 1 ]
then
/etc/init.d/keepalived stop
fi
sleep 2
done
实验的结果可以后台执行命令之后然后停止Nginx服务检验
