Linuxクラウドコンピューティングアーキテクチャ-維持されたハートビート検出メカニズム（アクティブおよびスタンバイLVS、アクティブおよびアクティブLVS）
1.keepalivedの紹介
keepalived3層検出機構のソフトウェアです。Webサーバーのステータスを検出できます。keepalivedは、Webサーバーが使用できないことを検出すると、サーバーをクラスターから削除します。サーバーの手動修復を待った後、keepalivedはサーバーをクラスターに自動的に追加します。
| レベル | 勤務地 | 効果 |
|---|---|---|
| layer3 | IPネットワーク層 | Keepalivedは、定期的にICMPパケット（pingパケット）をサーバーグループ内のサーバーに送信します。使用できないことが判明した場合、サーバーは無効であると見なされ、サーバーはサーバーグループから削除されます。 |
| layer4 | TCPトランスポートレイヤー | Keepalivedは、サーバーの特定のポートが開始されているかどうかを検出して、サーバーが正常であるかどうかを判別します。たとえば、Webサービスはポート80がアクティブ化されているかどうかを検出し、アクティブ化されていない場合はサーバーが削除されます。 |
| layer5 | アプリケーション層 | ユーザー定義のサーバープログラム操作検出ルール。Keepalivedは、サーバープログラムがユーザー定義のルールに従って正常に実行されているかどうかを確認します。正常でない場合、サーバーは削除されます。 |
keepalivedの役割：
1。VIPの管理：つまり、アクティブディストリビューターとスタンバイディストリビューターがあります。メインディストリビューターが電話を切ると、VIPは自動的にスタンバイディストリビューターに転送され、スタンバイディストリビューターが新しいメインディストリビューターとして機能します。メインディストリビューターが修理されると、メインディストリビューターはバックアップディストリビューターよりも優先度が高いため、VIPはバックアップディストリビューターから元のメインディストリビューターに転送されます。2. LVSディストリビューターの監視：VIPを管理するには、LVSディストリビューターがダウンしているかどうかを監視する必要があります。メインディストリビューターのKeepalivedは、スタンバイディストリビューターに、それが生きていることをマルチキャストの形式で通知します。スタンバイディストリビューターが指定された時間内にメインディストリビューターからメッセージを受信しない場合、メインディストリビューターがダウンしていると見なします。そして、VIPをバックアップディストリビューターに転送し始めました。
3. RSの管理：Keepalivedは定期的にバックエンド実サーバーにアクセス（elink）して、正常かどうかを確認します。正常でない場合は、サーバーを取り外します。つまり、特定のノードがダウンしています。
従来の高可用性Webアーキテクチャ：LVS + keepalived + nginx + apache + php + eaccelerator（+ nfsオプション）
Keepalived公式ウェブサイト：https://www.keepalived.org/
現在の最新バージョンは、2020年7月13日にリリースされたバージョン2.1.5です。
2.Keepalivedデプロイメント
2.1クラスター環境の概要
ネットワークトポロジ図：
本番環境では、すべてのIPアドレスは同じ物理ネットワークセグメントのIPアドレスである必要があります。
アクティブおよびスタンバイLVSディストリビューターは、ディストリビューターの高い可用性を実現します。マスターLVSとして構成して、相互のマスターLVSとバックアップLVSを実現することもできます。
2.2アクティブおよびスタンバイのkeepalived構成
2.2.1アクティブ環境とスタンバイ環境の概要
| CPU名 | IP /サブネットマスク | ゲートウェイ | 効果 |
|---|---|---|---|
| mlvs | DIP：192.168.10.10/24 VIP：192.168.10.30/32 |
192.168.10.1 | メインLVS |
| slvs | DIP：192.168.10.20/24 VIP：192.168.10.30/32 |
192.168.10.1 | LVSを準備する |
| rs1 | 192.168.10.40/24 | 192.168.10.1 | rs1バックエンド実サーバー |
| rs2 | 1921.68.10.50 / 24 | 192.168.10.1 | rs2バックエンド実サーバー |
# 主备lvs上都要安装ipvsadm和keepalived
# 使用命令ipvsadm -L -n 可以看到，两个分发器都是做负载均衡的，毕竟都没有配后端真实服务器。
# 这不是本文的重点，本文是要测试keepalived的心跳检测机制。
[root@mlvs ~]# yum install ipvsadm keepalived -y
[root@slvs ~]# yum install ipvsadm keepalived -y
[root@mlvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
[root@slvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
2.2.2メインLVSを構成する
メインのkeepalived構成ファイルを変更します。
# 可以使用以下命令查看yum安装的软件包的位置
[root@mlvs ~]# rpm -ql keepalived
/etc/keepalived/keepalived.conf
# 在复制进配置文件的时候，要把注释信息去掉。
[root@mlvs ~]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
# 全局配置
notification_email {
root@localhost # 当VIP发生切换时，发送邮件给以下邮箱，一行一个。
}
notification_email_from root@localhost # 发件人
smtp_server localhost # smtp发件服务器地址
smtp_connect_timeout 30 # smtp连接超时时间
router_id mlvs # 标识当前节点的名字，与备lvs不同。
}
vrrp_instance M1 {
#定义一个实例
state MASTER # 主LVS,备LVS应设置为BACKUP
interface ens32 # 指定检测网络的接口
virtual_router_id 51 # vrrp组名，备lvs要与主lvs在同一组。
priority 100 # 优先级(1-254)
advert_int 1 # 组播发送消息时间间隔
authentication {
# 设置验证信息，两个LVS必须一致
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.10.30 # 指定VIP,两个LVS必须一致
}
}
virtual_server 192.168.10.30 80 {
# 添加虚拟服务器VIP
delay_loop 6 # keepalived检测RS的时间间隔
lb_algo rr # 分发算法，rr指轮询
lb_kind DR # lvs模式，这里用DR
nat_mask 255.255.255.0
persistence_timeout 50 # 长连接保持时间，50s内同一IP的请求会发送给同一RS
protocol TCP
real_server 192.168.10.40 80 {
# RS设置
weight 1 # 真实服务器节点的权重，数值越大权重越高
TCP_CHECK {
# 检查TCP的80端口号，即layer4
connect_timeout 3 # 3s RS无响应则超时
nb_get_retry 3 # 超时重试次数
delay_before_retry 3 # 3s重试一次，即重试间隔
connect_port 80 # 检测端口
}
}
real_server 192.168.10.50 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
# 启动主lvs上的keepalived，并设置开机自启。
[root@mlvs ~]# systemctl start keepalived
[root@mlvs ~]# systemctl enable keepalived
virtual_serverインスタンスはLVSクラスターです。ホスト上に複数のLVSクラスターを構成する場合は、複数のインスタンスを構成する必要があります。
# 清空iptables防火墙规则
[root@mlvs ~]# iptables -F
# 使用ipvsadm查看负载均衡的情况
[root@mlvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.10.30:80 rr persistent 50
# 使用ip a命令查看ens32绑定的所有IP地址
[root@mlvs ~]# ip a | grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.8.118/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32
inet 192.168.10.30/32 scope global ens32
2.2.3スタンバイLVSの構成
# 发送主lvs的keepalived配置文件给备lvs主机。
[root@mlvs ~]# scp /etc/keepalived/keepalived.conf [email protected]:/etc/keepalived/
[root@slvs keepalived]# vim keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from root@localhost
smtp_server localhost
smtp_connect_timeout 30
router_id slvs # 从lvs标识
}
vrrp_instance M1 {
state BACKUP # 设置该实例为从LVS
interface ens32
virtual_router_id 51
priority 90 # 优先级调低，主为100，从为90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.10.30
}
}
virtual_server 192.168.10.30 80 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.10.40 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.10.50 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
# 启动从lvs上的keepalived，并设置开机自启。
[root@slvs ~]# systemctl start keepalived.service
[root@slvs ~]# systemctl enable keepalived.service
# 清空iptables防火墙规则
[root@slvs ~]# iptables -F
# 验证下VIP绑定情况，可以看到VIP是没有绑定到从LVS上的。
[root@slvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.10.30:80 rr persistent 50
[root@slvs ~]# ip a | grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.8.120/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32
2.2.4VIPマスター/バックアップスイッチのテスト
マスターLVSのkeepalivedサービスを停止すると、VIPがマスターLVSからスレーブLVSにドリフトしたことがわかります。
メインLVSでkeepalivedサービスを再起動すると、VIPがLVSからメインLVSにドリフトしていることがわかります。
LVSのログから、メインLVSが復元された後、スレーブLVSのアクションは、最初に優先度を確認し、次にバックアップモードに切り替え、最後にVIPを削除することであることがわかります。
2.3マスターマスターのkeepalived構成
2.3.1メイン環境の概要
| CPU名 | IP /サブネットマスク | ゲートウェイ | 効果 |
|---|---|---|---|
| mlvs1 | DIP：192.168.10.10/24 VIP1：192.168.10.30/32 |
192.168.10.1 | メインLVS、スタンバイLVSも |
| mlvs2 | DIP：192.168.10.20/24 VIP2：192.168.10.60/32 |
192.168.10.1 | メインLVS、スタンバイLVSも |
| rs1 | 192.168.10.40/24 | 192.168.10.1 | rs1バックエンド実サーバー |
| rs2 | 1921.68.10.50 / 24 | 192.168.10.1 | rs2バックエンド実サーバー |
2.3.2マスタースレーブ構成の2回
マスタースレーブは一度設定されているので、マスタースレーブを再度設定することができます。
# 配置为M1实例的主，M2实例的从。一个实例可以看作是一个集群。
[root@mlvs2 ~]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from root@localhost
smtp_server localhost
smtp_connect_timeout 30
router_id mlvs
}
vrrp_instance M1 {
state MASTER
interface ens32
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.10.30
}
}
vrrp_instance M2 {
state BACKUP
interface ens32
virtual_router_id 52
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.10.60
}
}
virtual_server 192.168.10.30 80 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.10.40 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.10.50 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
virtual_server 192.168.10.60 80 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.10.40 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.10.50 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
# 检测主1上的VIP情况，可以看到只绑定了一个VIP。因为主1只是实例M1的主LVS。
[root@mlvs1 ~]# systemctl restart keepalived.service
[root@mlvs1 ~]# iptables -F
[root@mlvs1 ~]# ip a |grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.8.118/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32
inet 192.168.10.30/32 scope global ens32
[root@mlvs1 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.10.30:80 rr persistent 50
TCP 192.168.10.60:80 rr persistent 50
# 配置为M2实例的主，M1实例的从。
[root@mlvs2 ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from root@localhost
smtp_server localhost
smtp_connect_timeout 30
router_id slvs
}
vrrp_instance M1 {
state BACKUP
interface ens32
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.10.30
}
}
vrrp_instance M2 {
state MASTER
interface ens32
virtual_router_id 52
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.10.60
}
}
virtual_server 192.168.10.30 80 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.10.40 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.10.50 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
virtual_server 192.168.10.60 80 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.10.40 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.10.50 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
# 检测主2上的VIP情况，可以看到只绑定了一个VIP。因为主2只是实例M2的主LVS。
[root@mlvs2 ~]# systemctl restart keepalived.service
[root@mlvs2 ~]# iptables -F
[root@mlvs2 ~]# ip a | grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.8.120/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32
inet 192.168.10.60/32 scope global ens32
[root@mlvs2 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.10.30:80 rr persistent 50
TCP 192.168.10.60:80 rr persistent 50
2.3.3VIPマスタースイッチのテスト
ご覧のとおり、構成が完了すると、LVSホストがVIPにバインドされます。mlvs1バインディングは192.168.10.30、mlvs2バインディングは192.168.10.60。
mlvs1でkeepalivedサービスを停止すると、VIPがドリフトしていることがわかります。
mlvs1でkeepalivedサービスを開始すると、VIPが戻ってくるのがわかります。
mlvs2でkeepalivedサービスを停止すると、VIPがドリフトしていることがわかります。
mlvs2でkeepalivedサービスを開始すると、VIPが戻ってくるのがわかります。
3.Keepalivedの概要
①keepalivedの動作原理から、IPネットワーク層、TCPトランスポート層、アプリケーション層の3つのレベルでサーバー検出を行うことがわかります。サーバーが利用できない場合は、クラスターから削除されます。サーバーが修復されると、サーバーはクラスターに追加されます。
②Keepalivedには、VIPの管理、LVSディストリビューターの監視、RSの管理の3つの主要な機能があります。
③このクラスタでは、メインLVSとスタンバイLVSが同じvrrpグループに属しており、メインLVSは定期的にスタンバイLVSにマルチキャストで動作していることをアナウンスし、この時点でスタンバイLVSがマスターを圧倒することはありません。ただし、スタンバイLVSがサイクル内にメインLVSのアナウンスを受信しない場合、スタンバイLVSは自動的にメインLVSに昇格し、VIPは自動的にメインLVSからスタンバイLVSにドリフトします。
④Keepalivedは、多くの場合、Webサーバーとmysqlサーバーを使用してクラスターを構築します。この記事はkeepalived + lvs + DR + httpアーキテクチャです。バックエンドreal_serverがポート3306を監視する場合、アーキテクチャはkeepalived + lvs + DR + mysqlに変換されます。
⑤各vrrp_instanceはクラスターであり、プライマリLVSとバックアップLVSの構成は同じクラスターに属しているため、vrrp_instanceインスタンス名は同じである必要があります。プライマリLVSがそれ自体をマルチキャストによって有効であると宣言するには、virtual_route_idVRRPグループIDが同じである必要があります。各keepalivedはそれ自体に属しているため、route_idが異なります。アクティブとスタンバイの区別は状態によって定義できます。メインLVSに障害が発生すると、VIPはクラスター内のノードの状態と優先度に従ってVIPドリフトを実行します。通常、状態がBACKUPで、スタンバイLVSで優先度が最も高いノードにドリフトします。上記の構成により、1つのマスターと複数のバックアップ、および複数のマスターと複数のバックアップに拡張できます。
⑥2台のサーバーでアクティブバックアップとアクティブマスターを実現できます。アクティブとスタンバイは同じクラスターに属し、アクティブとアクティブは2つのアクティブとスタンバイと見なすことができます。3つのサーバーは、1つのマスター、2つのバックアップ、および3つのマスターにすることができます。1つのマスターと2つのバックアップは同じクラスターに属し、3つのマスターは3つの1つのマスターと2つのバックアップと見なすことができます。このように、メインLVSが電話を切ると、VIPを受信するためのスタンバイLVSがあり、スタンバイLVSが電話を切ると、受信する別のスタンバイLVSがあります。実稼働環境でサービスを中断しない、可用性の高いアーキテクチャを実現します。