Keepalivedベースの高可用性クラスタ構成インスタンスの構築
クラスタとは
簡単に言えば、クラスタ(cluster)は、ネットワークリソースのセットを全体としてユーザーに提供するコンピュータのセットです.これらの単一のコンピュータシステムはクラスタのノード(node)である.理想的なクラスタは、ユーザがクラスタシステムの最下位のノードを意識したことがないことであり、彼/彼女たちから見れば、クラスタは複数のコンピュータシステムではなく、システムである.また、クラスタシステムの管理者は、クラスタシステムのノードを任意に追加および削除することができる.より詳細な高可用性クラスタについては後述するが,まずKeepalivedについて述べる
Keepalivedって何?
Keepalivedはクラスタ管理においてクラスタの高可用性を保証するサービスソフトウェアであり、heartbeatと同様の機能を有し、単一の障害を防止する.高可用性クラスタのために生まれたと言える...
keepalived動作原理
KeepalivedはVRRPプロトコルに基づいており、VRRPフルネームVirtual Router Redundancy Protocol、すなわち仮想ルーティング冗長プロトコルである.仮想ルーティング冗長プロトコルは、ルータの高可用性を実現するプロトコルと考えられ、N台が同じ機能を提供するルータから1つのルータグループを構成する.このグループには1つのmasterと複数のbackupがあり、masterの上には対外的にサービスを提供するVIP(このルータがあるローカルエリアネットワーク内の他の機器のデフォルトルーティングはこのVIP)があり、Masterはマルチキャストを送信し、BackupがVRRPパッケージを受け取れない場合、Masterがダウンしたと考えられる.この場合、VRRPの優先度に基づいてMasterとしてBackupを選択する必要があります.これでルータの高可用性が保証されます.Keepalivedには主にcore,check,vrrpの3つのモジュールがある.coreモジュールはkeepalivedの核心であり、メインプロセスの起動、メンテナンス、グローバルプロファイルのロードと解析を担当します.checkは健康診断を担当し、よく見られる様々な検査方法を含む.VRRPモジュールは、VRRPプロトコルを実装するために使用される.
keepalived拡張VRRPプロトコル原理
1、一つのVRRPルータには唯一の識別がある:VRID範囲が0-255はこのルータが対外的に唯一の仮想MACアドレスとして表現され、アドレスのフォーマットが00-00-5 E-00-01-[VRID]のマスタルータはARP要求に対してこのMACアドレスで応答することを担当する.2、VRRP制御メッセージは一つだけ:VRRP通知(advertisement)IPマルチキャストパケットを使用してカプセル化され、グループアドレスは224.0.0.0.18である.公開範囲は同じローカルエリアネットワーク内に限定され、VRIDが異なるネットワークで再利用できることを保証します.ネットワーク帯域幅の消費を減らすためにマスタルータのみが周期的に送信できるVRRP通知メッセージバックアップルータは、連続した3つの通知間隔でVRRPを受信できないか、または優先レベル0の通知を受信した後、新しいVRRP選挙を開始します.3、上述したVRRPルータグループの中で、優先度によってマスタールータを選出し、VRRPプロトコルの優先度範囲は0-255 VRRPルータのIPアドレスと仮想ルータのインタフェースIPアドレスが同じであれば、この仮想ルータをVRRPグループのIPアドレス所有者と呼ぶ.IPアドレス所有者は自動的に最高優先度を持つ:255優先度0一般的にIPアドレス所有者が自主的にマスターロールを放棄する際に使用可能な優先度範囲が1-254優先度の構成原則を使用すると、リンクの速度とコストルータの性能と信頼性、その他の管理戦略に基づいてマスタールータを設定する選挙で、高優先度の仮想ルータが勝つため、VRRPグループにIPアドレス所有者がいる場合、これは、常にマスタルーティングの役割として同じ優先度の候補ルータとして現れ、IPアドレスサイズ順にVRRPを選択することで優先度プリエンプトポリシーも提供され、このポリシーが構成されている場合、高優先度のバックアップルータは現在の低優先度のマスタルータを剥奪して新しいマスタルータとなる.4、VRRPプロトコルの安全性を保証するために、2種類の安全認証措置を提供した:明文認証とIPヘッダ認証.明文認証方式の要求:一つのVRRPルータグループに加入する時、同じVRIDと明文パスワードを同時に提供しなければならないのはローカルエリアネットワーク内の配置ミスを避けるのに適しているが、ネットワーク傍受方式でパスワードIPヘッダ認証を獲得する方式がより高い安全性を提供することを防止できない.我々はKeepalivedがVRRPプロトコルに基づいてどのように高可用性クラスタを実現するかを概念的に理解しているが,以下では簡単に一例を構成して印象を深める
keepalivedコアコンポーネント
vrrp stack ipvs wrapper checkers制御コンポーネント:プロファイルアナライザIOマルチプレクサメモリ管理コンポーネント
テスト環境
実験プラットフォーム:Windows 10_64仮想環境:Winシステムに基づいて構築されたVMware仮想ホストの実現に必要な仮想ホスト:2台、CentOS 7.2またはCentOS 6.8、オフセットCentOS 7.2仮想ホストのIPアドレスは:node 1アドレス、10.1.15.43、node 2アドレス、10.1.15.44
Keepalived HA Clusterベースの構成の前提条件
(1)各ノード時間は同期しなければならない.ntp、またはchrony同期ホスト時間(2)を使用して、iptablesおよびselinuxが障害にならないようにします.(3)各ノード間でホスト名による相互通信が可能(KAオプション)各ノード間のrootユーザが鍵認証のsshサービスに基づいて相互通信を完了できることを/etc/hostsファイルを用いて提案する(4)(オプション)
Keepalivedの構成
KeepalivedはCentos 6以降base倉庫に収集されているので、yumに直接インストールすることができます.
Keepalivedプログラム環境:プロファイルは:/etc/keepalived/keepalived.confメインプログラムファイル:/usr/sbin/keepalived Unit Fileサービスファイル:keepalived.service
Keepalivedプロファイルコンポーネント
keepalivedプロファイルcp/etc/keepalived/keepalivedをバックアップする.conf{,.back}
シングルマスターモデルの構成(マスターノードIP:10.1.15.43)
シングルマスターモデルの構成(スタンバイノードIP:10.1.15.44)
デュアルプライマリ・モデルの構成(プライマリ・スタンバイ、プライマリ・モデルの準備)
3つのステータス検出(master,backup,faultステータス)をトリガーするスクリプトを書きます.
以上のテストが完了しました.次にKeepalivedベースの高可用性クラスタを構成します.
httpサービスをテストターゲットとする
テストの環境とホスト私達はすべて上のLVSのDR模型を使ってKeepalivedと結合して高利用可能なクラスタを配置して、サービスのスケジューリングの配置のトポロジーの再細分化を実現します:2台のDirector serverはVIPになって、2台のReal serverは検出機になって、各ノードはスイッチに接続されたIPアドレス:10.1.15.43,10.1.15.44 Real server 1とReal server 2の2台のReal serverの80ポートとしてそれぞれサービスIPアドレスを提供する:10.1.15.45,10.1.15.46 Director serverとしてVIP VIP serverの回転アドレスが10.1.15.50ポートでwebサービスを提供する
vipのカーネルパラメータを構成してlo:0にポーリングのipアドレスを加える
Real server 1および2ホストでkeepalivedを使用して10.1.15.50アドレスをポーリング
任意のクライアントで障害をシミュレートし、単一の障害があるかどうかをテストします.もう1つは正常に動作します.
keepalivedは外部の補助スクリプトを呼び出して資源監視を行い、監視の結果状態に基づいて優先的な動的調整を実現して健康検査を実行することができる.ステップ2:(1)スクリプトを定義します.(2)このスクリプトを呼び出す.keepalivedディレクトリにdownファイルアドレスを作成すると、Real Server 1を参照するプロファイルが自動的にポーリングされ、スクリプトが定義されます.
高可用性nginxクラスタ逆エージェントの構成
Real Server 1と2のホストにnginxをインストールする
nginxの世代交代機能の構成
足りないことがあれば教えてくださいずっと勉强しています.他の机能もゆっくり练习しています.上の3つの状态のスクリプトを通じてsystemdに参加します.
次に、このスクリプトで定義されたトリガメカニズムにより、nginxサービス障害の自動再起動を監視します.
簡単に言えば、クラスタ(cluster)は、ネットワークリソースのセットを全体としてユーザーに提供するコンピュータのセットです.これらの単一のコンピュータシステムはクラスタのノード(node)である.理想的なクラスタは、ユーザがクラスタシステムの最下位のノードを意識したことがないことであり、彼/彼女たちから見れば、クラスタは複数のコンピュータシステムではなく、システムである.また、クラスタシステムの管理者は、クラスタシステムのノードを任意に追加および削除することができる.より詳細な高可用性クラスタについては後述するが,まずKeepalivedについて述べる
Keepalivedって何?
Keepalivedはクラスタ管理においてクラスタの高可用性を保証するサービスソフトウェアであり、heartbeatと同様の機能を有し、単一の障害を防止する.高可用性クラスタのために生まれたと言える...
keepalived動作原理
KeepalivedはVRRPプロトコルに基づいており、VRRPフルネームVirtual Router Redundancy Protocol、すなわち仮想ルーティング冗長プロトコルである.仮想ルーティング冗長プロトコルは、ルータの高可用性を実現するプロトコルと考えられ、N台が同じ機能を提供するルータから1つのルータグループを構成する.このグループには1つのmasterと複数のbackupがあり、masterの上には対外的にサービスを提供するVIP(このルータがあるローカルエリアネットワーク内の他の機器のデフォルトルーティングはこのVIP)があり、Masterはマルチキャストを送信し、BackupがVRRPパッケージを受け取れない場合、Masterがダウンしたと考えられる.この場合、VRRPの優先度に基づいてMasterとしてBackupを選択する必要があります.これでルータの高可用性が保証されます.Keepalivedには主にcore,check,vrrpの3つのモジュールがある.coreモジュールはkeepalivedの核心であり、メインプロセスの起動、メンテナンス、グローバルプロファイルのロードと解析を担当します.checkは健康診断を担当し、よく見られる様々な検査方法を含む.VRRPモジュールは、VRRPプロトコルを実装するために使用される.
keepalived拡張VRRPプロトコル原理
1、一つのVRRPルータには唯一の識別がある:VRID範囲が0-255はこのルータが対外的に唯一の仮想MACアドレスとして表現され、アドレスのフォーマットが00-00-5 E-00-01-[VRID]のマスタルータはARP要求に対してこのMACアドレスで応答することを担当する.2、VRRP制御メッセージは一つだけ:VRRP通知(advertisement)IPマルチキャストパケットを使用してカプセル化され、グループアドレスは224.0.0.0.18である.公開範囲は同じローカルエリアネットワーク内に限定され、VRIDが異なるネットワークで再利用できることを保証します.ネットワーク帯域幅の消費を減らすためにマスタルータのみが周期的に送信できるVRRP通知メッセージバックアップルータは、連続した3つの通知間隔でVRRPを受信できないか、または優先レベル0の通知を受信した後、新しいVRRP選挙を開始します.3、上述したVRRPルータグループの中で、優先度によってマスタールータを選出し、VRRPプロトコルの優先度範囲は0-255 VRRPルータのIPアドレスと仮想ルータのインタフェースIPアドレスが同じであれば、この仮想ルータをVRRPグループのIPアドレス所有者と呼ぶ.IPアドレス所有者は自動的に最高優先度を持つ:255優先度0一般的にIPアドレス所有者が自主的にマスターロールを放棄する際に使用可能な優先度範囲が1-254優先度の構成原則を使用すると、リンクの速度とコストルータの性能と信頼性、その他の管理戦略に基づいてマスタールータを設定する選挙で、高優先度の仮想ルータが勝つため、VRRPグループにIPアドレス所有者がいる場合、これは、常にマスタルーティングの役割として同じ優先度の候補ルータとして現れ、IPアドレスサイズ順にVRRPを選択することで優先度プリエンプトポリシーも提供され、このポリシーが構成されている場合、高優先度のバックアップルータは現在の低優先度のマスタルータを剥奪して新しいマスタルータとなる.4、VRRPプロトコルの安全性を保証するために、2種類の安全認証措置を提供した:明文認証とIPヘッダ認証.明文認証方式の要求:一つのVRRPルータグループに加入する時、同じVRIDと明文パスワードを同時に提供しなければならないのはローカルエリアネットワーク内の配置ミスを避けるのに適しているが、ネットワーク傍受方式でパスワードIPヘッダ認証を獲得する方式がより高い安全性を提供することを防止できない.我々はKeepalivedがVRRPプロトコルに基づいてどのように高可用性クラスタを実現するかを概念的に理解しているが,以下では簡単に一例を構成して印象を深める
keepalivedコアコンポーネント
vrrp stack ipvs wrapper checkers制御コンポーネント:プロファイルアナライザIOマルチプレクサメモリ管理コンポーネント
テスト環境
実験プラットフォーム:Windows 10_64仮想環境:Winシステムに基づいて構築されたVMware仮想ホストの実現に必要な仮想ホスト:2台、CentOS 7.2またはCentOS 6.8、オフセットCentOS 7.2仮想ホストのIPアドレスは:node 1アドレス、10.1.15.43、node 2アドレス、10.1.15.44
Keepalived HA Clusterベースの構成の前提条件
(1)各ノード時間は同期しなければならない.ntp、またはchrony同期ホスト時間(2)を使用して、iptablesおよびselinuxが障害にならないようにします.(3)各ノード間でホスト名による相互通信が可能(KAオプション)各ノード間のrootユーザが鍵認証のsshサービスに基づいて相互通信を完了できることを/etc/hostsファイルを用いて提案する(4)(オプション)
ntp ，
ntpdate 10.1.0.1
server chrony
vim /etc/chrony.conf
server 10.1.0.1 iburst
chronyc sources//
date
date XXXXXX// date
[root@localhost ~]# getenforce
Enforcing
[root@localhost ~]# setenforce 0
[root@localhost ~]# getenforce
Permissive
[root@localhost ~]# iptables -F
[root@localhost ~]#
ip， （ ）
： ， ，
node1 10.1.253.43
[root@localhost ~]# ssh-keygen -t rsa -P '' //
ssh-copy-id -i .ssh/id_rsa.pub [email protected]
[root@localhost ~]# ssh [email protected]
Last login: Mon Oct 31 13:34:38 2016 from 10.1.15.85
[root@localhost ~]#
......Keepalivedの構成
KeepalivedはCentos 6以降base倉庫に収集されているので、yumに直接インストールすることができます.
yum install keepalivedKeepalivedプログラム環境:プロファイルは:/etc/keepalived/keepalived.confメインプログラムファイル:/usr/sbin/keepalived Unit Fileサービスファイル:keepalived.service
Keepalivedプロファイルコンポーネント
keepalivedプロファイルcp/etc/keepalived/keepalivedをバックアップする.conf{,.back}
GLOBAL CONFIGURATION //
Global definitions //
Static routes/addresses //
VRRPD CONFIGURATION //VRRP ，
VRRP synchronization group(s)// VRRP
VRRP instance(s) //VRRP
LVS CONFIGURATION//
Virtual server group(s)//
Virtual server(s)//シングルマスターモデルの構成(マスターノードIP:10.1.15.43)
， ， vip
etc keepalived keepalived.conf
vim /etc/keepalived/keepalived.conf
virtual_ipaddress :.,$d，
! Configuration File for keepalived //keepalived
global_defs {
notification_email { // ，
root@localhost //
}
notification_email_from keepalived@localhost // ，
smtp_server 127.0.0.1// ，
smtp_connect_timeout 30 //smtp ，30
router_id node1 // ，
vrrp_mcast_group4 224.15.15.15 //
} // MULTICAST ,
vrrp_instance VI_1 { //VI_1 VRRP ，
state MASTER // ,
interface eno16777736 //
virtual_router_id 20 // ， 0-255
priority 100 // ； 1-254
advert_int 1 //vrrp
authentication { //
auth_type PASS //
auth_pass 6b8a916c //
} // ：openssl rand -hex 4
virtual_ipaddress { // ip ， ， ， ，
10.1.15.50/16
}
}
scp ， priority state 。
scp keepalived.conf [email protected]:/etc/keepalived/シングルマスターモデルの構成(スタンバイノードIP:10.1.15.44)
etc keepalived keepalived.conf
vim /etc/keepalived/keepalived.conf
virtual_ipaddress :.,$d，
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.15.15.15
}
vrrp_instance VI_1 {
state BACKUP
interface eno16777736
virtual_router_id 20
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass 6b8a916c
}
virtual_ipaddress {
10.1.15.50/16
}
}
：
43,44 keepalived ， ， ， master ， 。
[root@node1 ~]# systemctl start|stop| keepalived.service
[root@node1 ~]# tail -f /var/log/messagesデュアルプライマリ・モデルの構成(プライマリ・スタンバイ、プライマリ・モデルの準備)
ip：10.1.15.43 ：10.1.15.44
etc keepalived keepalived.conf
vim keepalived.conf vrrp_instance VI_2 {
scp ， priority state 。
scp keepalived.conf [email protected]:/etc/keepalived/
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.15.15.15
}
vrrp_instance VI_1 {
state MASTER
interface eno16777736
virtual_router_id 20
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 6b8a916c
}
virtual_ipaddress {
10.1.15.50/16
}
}
vrrp_instance VI_2 {
state BACKUP
interface eno16777736
virtual_router_id 30
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass 6b9a916c
}
virtual_ipaddress {
10.1.15.60/16
}
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
，
[root@node1 ~]# systemctl start|stop| keepalived.service
[root@node1 ~]# tail -f /var/log/messages
， ， 3つのステータス検出(master,backup,faultステータス)をトリガーするスクリプトを書きます.
notify.sh etc/keepalived/ ， ， ：./notify.sh master/BACKUP/fault, ip
#!/bin/bash
#
# ，
contact='root@localhost'
# notify，
notify()
{
# local ， ， ， vip
mailsubject="$(hostname) to be $1, vip floating"
# ， ， ， vrrp ，
mailbody="$(date +'%F %T'): vrrp transition, $(hostname) changed to be $1"
# ，mailbody ， ，
echo "$mailbody" | mail -s "$mailsubject" $contact
}
#
case $1 in
# master
master)
notify master
# notify ，
;;
backup)
notify backup
;;
fault)
notify fault
;;
# ， ，
*)
echo "Usage: $(basename $0) {master|backup|fault}"
exit 1
;;
esac
bash chmod +x notify.sh，
：
./notify.sh master BACKUP fault
， mail 以上のテストが完了しました.次にKeepalivedベースの高可用性クラスタを構成します.
httpサービスをテストターゲットとする
テストの環境とホスト私達はすべて上のLVSのDR模型を使ってKeepalivedと結合して高利用可能なクラスタを配置して、サービスのスケジューリングの配置のトポロジーの再細分化を実現します:2台のDirector serverはVIPになって、2台のReal serverは検出機になって、各ノードはスイッチに接続されたIPアドレス:10.1.15.43,10.1.15.44 Real server 1とReal server 2の2台のReal serverの80ポートとしてそれぞれサービスIPアドレスを提供する:10.1.15.45,10.1.15.46 Director serverとしてVIP VIP serverの回転アドレスが10.1.15.50ポートでwebサービスを提供する
vipのカーネルパラメータを構成してlo:0にポーリングのipアドレスを加える
!#/bin/bash
#
vip='10.1.15.50'
vport='80'
netmask='255.255.255.255'
iface='lo:0'
case $1 in
start)
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
ifconfig $iface $vip netmask $netmask broadcast $vip up
route add -host $vip dev $iface
esac
Real server 1および2ホストでkeepalivedを使用して10.1.15.50アドレスをポーリング
keepalived.conf ， ，Real server1 2 ，
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.15.15.15
}
vrrp_instance VI_1 {
state BACKUP
interface eno16777736
virtual_router_id 20
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass 6b8a916c
}
virtual_ipaddress {
10.1.15.50/16 //
}
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
#### 50 Director server web
> real server ipvsadm ， 10.1.15.50 Director server web ，
> real server ，real server1 2 ， ， web 。
[root@node1 keepalived]# ipvsadm -A -t 10.1.15.50:80 -s rr
[root@node1 keepalived]# ipvsadm -a -t 10.1.15.50:80 -r 10.1.15.45 -g -w 1
[root@node1 keepalived]# ipvsadm -a -t 10.1.15.50:80 -r 10.1.15.46 -g -w 1
> curl real server Director server web
> ： real server keepalived 50 ，
curl http://10.1.15.50
[root@Centos6 ~]# curl 10.1.15.50
RS 1
[root@Centos6 ~]# curl 10.1.15.50
RS 2
[root@Centos6 ~]#
， Director server web
#### Real server 1 keepalived.con
Real server 1 Real server 2
scp keepalived.conf [email protected]:/etc/keepalived/
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.15.15.15
}
vrrp_script chk_down { //keepalived
script "[[ -f /etc/keepalived/down ]] && exit 1 || exit 0"
interval 1
weight -5
}
vrrp_instance VI_1 {
state BACKUP
interface eno16777736
virtual_router_id 20
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass 6b8a916c
}
virtual_ipaddress {
10.1.15.50/16 dev eno16777736
}
track_script { // ， down
chk_down
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"
}
virtual_server 10.1.15.50 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80
real_server 10.1.15.45 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 1
nb_get_retry 3
delay_before_retry 1
}
}
real_server 10.1.15.46 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 1
nb_get_retry 3
delay_before_retry 1
}
}
}
任意のクライアントで障害をシミュレートし、単一の障害があるかどうかをテストします.もう1つは正常に動作します.
， Real server LVS
[root@node1 ~]# systemctl start|stop| keepalived.service
[root@node1 ~]# ipvsadm -L -n
[root@node2 keepalived]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.1.15.50:80 rr
-> 10.1.15.45:80 Route 1 0 0
-> 10.1.15.46:80 Route 1 0 0
curl
[root@Centos6 ~]# curl http://10.1.15.50
Sorry Server 2
[root@Centos6 ~]# curl http://10.1.15.50
RS 2
[root@Centos6 ~]# curl http://10.1.15.50
RS 1
[root@Centos6 ~]#
： keepalived web ， 80 ， Director server web 80 ，
， keepalived
keepalivedは外部の補助スクリプトを呼び出して資源監視を行い、監視の結果状態に基づいて優先的な動的調整を実現して健康検査を実行することができる.ステップ2:(1)スクリプトを定義します.(2)このスクリプトを呼び出す.keepalivedディレクトリにdownファイルアドレスを作成すると、Real Server 1を参照するプロファイルが自動的にポーリングされ、スクリプトが定義されます.
高可用性nginxクラスタ逆エージェントの構成
Real Server 1と2のホストにnginxをインストールする
[root@node1 ~]# rpm -ivh nginx-1.10.0-1.el7.ngx.x86_64.rpmnginxの世代交代機能の構成
nginx.conf
vim /etc/nginx/nginx.conf ，
access_log /var/log/nginx/access.log main; //
upstream websrvs { //
server 10.1.15.45;
server 10.1.15.46;
}
conf.d default.conf ，
vim /etc/nginx/conf.d/default.conf
location / {
root /usr/share/nginx/html;
index index.html index.htm;
proxy_pass http://websrvs; // web
}
systemctl start nginx.service
systemctl start keepalived.service
curl 10.1.15.50， ！！！ 足りないことがあれば教えてくださいずっと勉强しています.他の机能もゆっくり练习しています.上の3つの状态のスクリプトを通じてsystemdに参加します.
次に、このスクリプトで定義されたトリガメカニズムにより、nginxサービス障害の自動再起動を監視します.