nginxの - keepalivedの
高可用性の基本的な概要を1.keepalived
高可用性とは何ですか
まったく認識されない一般的には、2台のマシンにまったく同じ業務システムで始まる指しマシンダウンマシンがある場合には、別のサーバーはすぐにユーザアクセスのために引き継ぐことができます。
どのような通常の高可用性ソフトウェアを使用します
ハードウェアの使用F5
ソフトウェアkeepalivedの
高可用性を実現する方法keepalilved
keepalivedのソフトウェアが計算され、主に単一障害点に対処するために使用される仮想ルーティング冗長プロトコルVRRP VRRPプロトコル実装
だから、VRRPが生まれたか、原理は何ですか？
たとえば、会社のネットワークにゲートウェイを介してインターネットで、実行する方法、そしてルータに障害が発生した場合、ゲートウェイはパケットを転送することができない、とこの時間誰もがオンラインで入手することはできませんか？
一般的な慣行は、ルータ台北ストリート店を追加することですが、私たちのプライマリゲートウェイのマスターに障害が発生した場合、問題はそれらを修正するためにあまりにも多くのユーザーが非常に面倒になる場合、ユーザーは、手動でバックアップ時点に必要とされる、です。
一つの問題：ユーザーが変更する必要がありますと仮定は、マスタルータが行う方法を修理し、バックアップポイントとは？
第二の問題：あなたができる場合と仮定マスターゲートウェイに障害が発生し、我々はバックアップゲートウェイは、マスタゲートウェイIPとして設定されているのだろうか？
PCがキャッシュテーブルに接続された情報を介して接続された後にARPブロードキャストMACアドレスとIPアドレスを使用して、マスターのゲートウェイを見つけるために初めてPCは、情報は、ARPキャッシュテーブルに書き込まれますので、実際には、それは、動作しません。その後、パケットを転送するが、我々はIPアドレスが一意マックで変化した場合でも、PCのパケットがまだマスターに送信されます。（ARPは、新しい対応するバックアップMACアドレスとIPアドレスを取得するために再び放送するときに開始PC ARPキャッシュテーブルの有効期限を除きます）
我々は自動的に転送失敗する可能性がありますどのように、VRRPが登場し、この時、私たちは実際には、その後、ソフトウェアやハードウェアの形でVRRPの仮想MACアドレス（VMAC）と仮想IPアドレス（VIP）中と外のマスターのバックアップを高めますPCは、VIP、マスターまたはバックアップ処理プロセスを要求すると、この場合には、PCだけでARPキャッシュテーブルに情報VMACとVIPを記録します。
keepalivedのは、高可用性シナリオを使用します
ビジネス・システムは、通常DOWNマシン、このような内部OAシステムなしの7×24時間を確保する必要があり、同社の担当者は、常に利用可能なビジネス・システムとして、ダウンマシンが許可されていない、毎日の使用を必要としています
バックノード（選挙、優先）であるマスタノードが誰であるかを判断する方法1、
マスターの障害が、バックアップを自動的に引き継ぐ場合は2、そしてマスターは、それが（非プリエンプティブをつかむしようとする）権力を掌握して返信されます
両方のサーバーが、彼らは問題が何であるかをマスターしていると思われる場合3は、（スプリットブレイン）が表示されます
keepalivedの高可用性インストール構成
2.1練習環境の設定
| 効果 | IP | 役割 |
|---|---|---|
| ノード1 | 10.0.0.5 | マスター |
| ノード2 | 10.0.0.6 | バックアップ |
| VIP | 10.0.0.3 |
マスタとバックアップ2.2が搭載されているkeepalivedの
[root@lb01 ~]# yum install -y keepalived
[root@lb02 ~]# yum install -y keepalived2.3構成ノード1、マスター
#找到配置文件
[root@lb02 ~]# rpm -qc keepalived
/etc/keepalived/keepalived.conf
/etc/sysconfig/keepalived
#编辑配置文件
[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs { #全局配置
router_id lb01 #标识身份->名称
}
vrrp_instance VI_1 {
state MASTER #标识角色状态
interface eth0 #网卡绑定接口
virtual_router_id 50 #虚拟路由id
priority 150 #优先级
advert_int 1 #监测间隔时间
authentication { #认证
auth_type PASS #认证方式
auth_pass 1111 #认证密码
}
virtual_ipaddress {
10.0.0.3 #虚拟的VIP地址
}
}2.4構成ノード2、バックアップ
[root@lb02 ~]# cat /etc/keepalived/keepalived.conf
global_defs {
router_id lb02
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.3
}
}マスターとバックアップの設定をkeepalivedの2.5の比較差
| keepalivedの設定の違い | マスターノードの設定 | バックアップノードの構成 |
|---|---|---|
| route_id（固有の識別） | ROUTER_ID LB01 | ROUTER_ID LB02 |
| 状態（状態の役割） | 状態MASTER | 状態のバックアップ |
| 優先順位（優先度の選挙） | 優先順位150 | 優先順位100 |
2.6 keepalivedのマスターとバックアップノードを開始
#Master节点
[root@lb01 ~]# systemctl start keepalived
[root@lb01 ~]# systemctl enable keepalived
#Backup节点
[root@lb02 ~]# systemctl start keepalived
[root@lb02 ~]# systemctl enable keepalived3.可用性が先制し、ノンプリエンプティブkeepalivedの
3.1両方のノードが開始します
#由于节点1的优先级高于节点2，所以VIP在节点1上面
[root@lb01 ~]# ip addr | grep 10.0.0.3
inet 10.0.0.3/32 scope global eth03.2閉じるkeepalivedのノード1
[root@lb01 ~]# systemctl stop keepalived
#节点2联系不上节点1，主动接管VIP
[root@lb02 ~]# ip addr | grep 10.0.0.3
inet 10.0.0.3/32 scope global eth0マスター上でこの時点で3.3 keepalivedの再起動は、VIPの検索をつかむために強制されます
[root@lb01 ~]# systemctl start keepalived
[root@lb01 ~]# ip addr | grep 10.0.0.3
inet 10.0.0.3/32 scope global eth03.4コンフィギュレーションノンプリエンプティブ
1、两个节点的state都必须配置为BACKUP
2、两个节点都必须加上配置 nopreempt
3、其中一个节点的优先级必须要高于另外一个节点的优先级。
两台服务器都角色状态启用nopreempt后，必须修改角色状态统一为BACKUP，唯一的区分就是优先级。
Master配置
vrrp_instance VI_1 {
state BACKUP
priority 150
nopreempt
}
Backup配置
vrrp_instance VI_1 {
state BACKUP
priority 100
nopreempt
}MACアドレスが切り替わっているかどうか、WindowsのARPによって検証する3.5、
#查看VIP在节点1上面
[root@lb01 ~]# ip addr | grep 10.0.0.3
inet 10.0.0.3/32 scope global eth0
#windows查看Mac地址
#将节点1的keepalived停掉
[root@lb01 ~]# systemctl stop keepalived
#节点2接管VIP
[root@lb02 ~]# ip addr | grep 10.0.0.3
inet 10.0.0.3/32 scope global eth0
#再次查看mac地址
arp -a
keepalivedの4.障害のスプリットブレインの可用性
何らかの理由で、指定された時間内に2台のkeepalivedの高可用性サーバーで、その結果、私たちはお互いのハートビート、言葉へのリソースやサービスの所有権が、この時間を検出することができない二つの高可用性サーバは、まだ両方生きています。
誤動作の4.1スプリットブレイン原因
図1に示すように、サーバネットワーク障害や緩みケーブル
2、サーバーのハードウェア障害クラッシュ損傷現象
3は、スタンバイファイアウォールfirewalldオンします
4.2スプリットブレイン症状
#将节点1和节点2的防火墙都打开
[root@lb01 ~]# systemctl start firewalld
[root@lb02 ~]# systemctl start firewalld
#fireshark抓包查看
4.3障害シナリオは、スプリットブレインを解決します
#如果发生闹裂，则随机kill掉一台即可
#在备上编写检测脚本, 测试如果能ping通主并且备节点还有VIP的话则认为产生了列脑
[root@lb02 ~]# cat check_split_brain.sh
#!/bin/sh
vip=10.0.0.3
lb01_ip=10.0.0.5
while true;do
ping -c 2 $lb01_ip &>/dev/null
if [ $? -eq 0 -a `ip add|grep "$vip"|wc -l` -eq 1 ];then
echo "ha is split brain.warning."
else
echo "ha is ok"
fi
sleep 5
done可用性とnginxのkeepalivedの
5.1なぜドメイン名はnginxのにアクセスするためにVIPに解決しますか？
nginxのデフォルトはすべてのIPアドレスをリッスンし、VIPは単一ノード、台湾は、VIPカードでのnginxよりも相当に吹き付けされますので、あなたはnginxのマシンにアクセスすることができます
5.2 nginxのダウンタイム、ユーザーの要求につながるが、keepalivedのをハングしない障害が切り替わりません、そうではない生存を殺す場合は、スクリプトを記述する必要が、nginxのに実行可能な状態を検出した場合keepalivedの
[root@lb01 ~]# mkdir /server/scripts
[root@lb01 ~]# vim /server/scripts/check_web.sh
#!/bin/sh
nginxpid=$(ps -C nginx --no-header|wc -l)
#1.判断Nginx是否存活,如果不存活则尝试启动Nginx
if [ $nginxpid -eq 0 ];then
systemctl start nginx
sleep 3
#2.等待3秒后再次获取一次Nginx状态
nginxpid=$(ps -C nginx --no-header|wc -l)
#3.再次进行判断, 如Nginx还不存活则停止Keepalived,让地址进行漂移,并退出脚本
if [ $nginxpid -eq 0 ];then
systemctl stop keepalived
fi
fi
#给脚本增加执行权限
[root@lb01 ~]# chmod +x /server/scripts/check_web.sh5.3このスクリプトは、ホストのLB01 keepalivedのプロファイルと呼ばれています
[root@lb01 ~]# cat /etc/keepalived/keepalived.conf
global_defs {
router_id lb01
}
#每5秒执行一次脚本，脚本执行内容不能超过5秒，否则会中断再次重新执行脚本
vrrp_script check_web {
script "/server/scripts/check_web.sh"
interval 5
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 50
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.0.0.3
}
#调用并运行脚本
track_script {
check_web
}
}
#在Master的keepalived中调用脚本，抢占式，仅需在master配置即可。（注意，如果配置为非抢占式，那么需要两台服务器都使用该脚本）