keepalivedベースの高可用性ipvsクラスタ
前言:
前にlvsでクラスタサービスを構築することは,確かにサービスの負荷能力を向上させることができるが,スケジューラの単点,バックエンドサーバの健康状態をリアルタイムで検出できないなど,依然として多くの問題が存在している.そのため、スケジューラにプライマリ・スペアがあり、1台のサーバが別のサーバを切ってすぐに自動的に交換し、バックエンド・サーバの健康状態に応じてRSの削除を増やすことができることを望んでいます.ここでは今回お話ししたkeepalivedについて説明します.もちろんkeepalivedはipvsクラスタの高可用性を実現するだけでなく,今回はipvsに高可用性を追加する.
本文:
keepalivedには主にvrrp stack,ipvs wrapper,checkersの3つの構成があり,それぞれプライマリ・スペアの実現,ipvs規則の管理,健康状態検出に用いられる.
vrrp仮想ルーティング冗長プロトコルは、ローカルエリアネットワークにおける静的ゲートウェイの構成において単一の失効が生じるルーティングプロトコルを解決するためである.ここでは主にVS単一の失効を解決するために、2台のデバイスをスケジューラとして、2つのデバイスを1台のデバイスに仮想化し、仮想ルーティングidという東東でこの仮想デバイスを識別し、この仮想デバイスにipアドレスを与えることができます.2台のデバイスの中で優先度の高いデバイスはプライマリデバイスで、他のデバイスはデバイスから、プライマリデバイスはこの仮想デバイスのipを得ることができます.プライマリ・デバイスが何らかの理由でオフになった場合、デバイスからまたはこの仮想デバイスのipまでサービスを提供するので、簡単なプライマリ・スタンバイ・モードでは、1台のデバイスが動作し、もう1台がスタンバイとして動作します.では、スタンバイデバイスはどのようにしてプライマリデバイスがオンラインかどうかを知っていますか?2人が別々の部屋にいることに相当し、1つが存在するかどうかを確かめるために、ずっと声を出して他の人に存在することを確かめればいいのです~だから、メインスタンバイもそうですが、わずかな範囲で伝播するだけなので、ここでは放送ではなくマルチキャストを使っています.
keepalivedは、プロファイルを使用してlvsを設定し、健康状態検出とともにipvsを動的に管理できます.もし私たちが2台のRSを配置したら、keepalivedはRSの健康状態に基づいてipvsルールを配置します.もしある設備がdownしたら、要求はこの設備に転送されません.もし2台とも切ったらどうしますか.スケジューラにsorry serverを提示して、サービスが利用できないなどのヒントを与えることができます.
私たちは前編のブログの実装にkeepalived機能を追加し続けました.高可用性を実現するために、VSの代替デバイスとして1台のデバイスを追加しました.そのipは172.16.53.104で、2台のRSの配置は変わらないので、以前のipvsの配置を直接クリアすればいいです.keepalivedの構成は、グローバル構成、vrrp関連構成、lvsの構成の3つの部分に分かれています.スケジューラの構成は次のとおりです.
2つのVSの構成はほぼ一致しており、state設定が異なる以外は.httpの負荷分散,健康状態検出および高可用性を実証したが,いずれのサービスもサポートされている~lvsは4層の東東~他のサービスはTCP_CHECKフィールドの設定ができました.ここでは詳しく説明しません.簡単な構成説明を直接出して~
2つのRS同時スケジューリング要求を実現するにはどうすればいいのでしょうか.私たちは2台のデバイスで2つの仮想デバイスを作ることができるので、2つの仮想ipがあります.1つの仮想デバイスの中で、VS 1が主で、VS 2が従で、もう1つの仮想デバイスの中でVS 1が従で、VS 2が主で、それからdnsで1つのドメイン名を2つのipに解析します.dns自体が2つのipをポーリングするので、2つのスケジューラの負荷均衡を実現しました.ここではプレゼンテーションをしないで、上の配置と大同小異です.ここではただ一つの考えを与えるだけだ.
注意:drモードでダブルマスターを設定する場合は、RSは2つのVIPを設定することを忘れないでください.この坑博主は踏んだことがあります...
~keepalivedが出てきてlvsの高可用性を作ることができて、nginxの負荷の均衡の高可用性をすることができて、しかしこの話題は後で話します~
前にlvsでクラスタサービスを構築することは,確かにサービスの負荷能力を向上させることができるが,スケジューラの単点,バックエンドサーバの健康状態をリアルタイムで検出できないなど,依然として多くの問題が存在している.そのため、スケジューラにプライマリ・スペアがあり、1台のサーバが別のサーバを切ってすぐに自動的に交換し、バックエンド・サーバの健康状態に応じてRSの削除を増やすことができることを望んでいます.ここでは今回お話ししたkeepalivedについて説明します.もちろんkeepalivedはipvsクラスタの高可用性を実現するだけでなく,今回はipvsに高可用性を追加する.
本文:
keepalivedには主にvrrp stack,ipvs wrapper,checkersの3つの構成があり,それぞれプライマリ・スペアの実現,ipvs規則の管理,健康状態検出に用いられる.
vrrp仮想ルーティング冗長プロトコルは、ローカルエリアネットワークにおける静的ゲートウェイの構成において単一の失効が生じるルーティングプロトコルを解決するためである.ここでは主にVS単一の失効を解決するために、2台のデバイスをスケジューラとして、2つのデバイスを1台のデバイスに仮想化し、仮想ルーティングidという東東でこの仮想デバイスを識別し、この仮想デバイスにipアドレスを与えることができます.2台のデバイスの中で優先度の高いデバイスはプライマリデバイスで、他のデバイスはデバイスから、プライマリデバイスはこの仮想デバイスのipを得ることができます.プライマリ・デバイスが何らかの理由でオフになった場合、デバイスからまたはこの仮想デバイスのipまでサービスを提供するので、簡単なプライマリ・スタンバイ・モードでは、1台のデバイスが動作し、もう1台がスタンバイとして動作します.では、スタンバイデバイスはどのようにしてプライマリデバイスがオンラインかどうかを知っていますか?2人が別々の部屋にいることに相当し、1つが存在するかどうかを確かめるために、ずっと声を出して他の人に存在することを確かめればいいのです~だから、メインスタンバイもそうですが、わずかな範囲で伝播するだけなので、ここでは放送ではなくマルチキャストを使っています.
keepalivedは、プロファイルを使用してlvsを設定し、健康状態検出とともにipvsを動的に管理できます.もし私たちが2台のRSを配置したら、keepalivedはRSの健康状態に基づいてipvsルールを配置します.もしある設備がdownしたら、要求はこの設備に転送されません.もし2台とも切ったらどうしますか.スケジューラにsorry serverを提示して、サービスが利用できないなどのヒントを与えることができます.
私たちは前編のブログの実装にkeepalived機能を追加し続けました.高可用性を実現するために、VSの代替デバイスとして1台のデバイスを追加しました.そのipは172.16.53.104で、2台のRSの配置は変わらないので、以前のipvsの配置を直接クリアすればいいです.keepalivedの構成は、グローバル構成、vrrp関連構成、lvsの構成の3つの部分に分かれています.スケジューラの構成は次のとおりです.
#172.16.53.100
ipvsadm -C #
ifconfig eno16777736:0 172.16.53.50 netmask 255.255.255.255 broadcast 172.16.53.50 down
VIP down
yum install keepalived -y
cd /etc/keepalived
mv keepalived.conf{,.bak} #
vim keepalived.conf
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.0.100.99 #
}
vrrp_instance VI_1 { #vrrp
state BACKUP # ，104 MASTER
interface eno16777736 # ip
virtual_router_id 99 # ， vrrp
priority 98 # ，
advert_int 1 #vrrp ；
authentication { # ，
auth_type PASS
auth_pass 571f97b2 # 8
}
virtual_ipaddress { # IP
172.16.53.50/16 dev eno16777736 #ip
}
}
virtual_server 172.16.53.50 80 { #lvs ~
delay_loop 3 # ；
lb_algo rr #
lb_kind DR # ，
protocol TCP # ， TCP
sorry_server 127.0.0.1 80 #sorry server ，
real_server 172.16.53.101 80 { # RS
weight 1 # ，
HTTP_GET { # ， http get
url {
path / # url
status_code 200 # 200
}
connect_timeout 1 #
nb_get_retry 3 #
delay_before_retry 1 #
}
}
real_server 172.16.53.102 80 { # RS
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 1
nb_get_retry 3
delay_before_retry 1
}
}
}
systemctl start keepalived #
ipvsadm -Ln # ipvs
yum install httpd -y # sorry server
vim /var/www/html/index.html
sorry,our system is being maintained
systemctl start httpd # sorry server2つのVSの構成はほぼ一致しており、state設定が異なる以外は.httpの負荷分散,健康状態検出および高可用性を実証したが,いずれのサービスもサポートされている~lvsは4層の東東~他のサービスはTCP_CHECKフィールドの設定ができました.ここでは詳しく説明しません.簡単な構成説明を直接出して~
TCP_CHECK {
connect_ip ： RS IP
connect_port ： RS PORT
bindto ： ；
bind_port ： ；
connect_timeout ： ；
} 2つのRS同時スケジューリング要求を実現するにはどうすればいいのでしょうか.私たちは2台のデバイスで2つの仮想デバイスを作ることができるので、2つの仮想ipがあります.1つの仮想デバイスの中で、VS 1が主で、VS 2が従で、もう1つの仮想デバイスの中でVS 1が従で、VS 2が主で、それからdnsで1つのドメイン名を2つのipに解析します.dns自体が2つのipをポーリングするので、2つのスケジューラの負荷均衡を実現しました.ここではプレゼンテーションをしないで、上の配置と大同小異です.ここではただ一つの考えを与えるだけだ.
注意:drモードでダブルマスターを設定する場合は、RSは2つのVIPを設定することを忘れないでください.この坑博主は踏んだことがあります...
~keepalivedが出てきてlvsの高可用性を作ることができて、nginxの負荷の均衡の高可用性をすることができて、しかしこの話題は後で話します~