HA(ご利用可能)高可用性クラスタ - フェンスデバイスを介してクラスタノード間でリソースの競合の現象に対処します
A、HAプロフィール
HA(ご利用可能)、高可用性クラスタでは、サーバーのクラスタリング技術の目的のために、サービスの中断時間を短縮することです。これは、効果的なビジネス継続性ソリューションを確保することです。クラスタは、単にコンピュータの基を意味します。一般に二つ又はコンピュータの複数の構成要素、これらのクラスタは、ノードと呼ばれるコンピュータ構成要素があります。
クラスタは、2つのノードで構成され呼ばれている場合は、ホットスタンバイサーバの問題の一つ、別のサーバーがすぐに外国中断のないユーザーを保護するために、サービスを引き継ぐ際に使用2台のサーバーは、お互いをバックアップすることを操作する手順提供されるサービスは、当然のことながら、より多くのクラスタシステムは、最小限に起因するソフトウェア/ハードウェア/ヒトに起因するビジネスを、障害の影響を低減するために、より多くのホットスタンバイよりも、より高度な機能を提供つ以上のノードをサポートすることができます。
第二に、クラスタのスプリットブレイン
スプリットブレインは何1.
脳の分割(スプリットブレイン)は、我々はすべて知っている、もともと「頭脳」であるスプリット二つ以上の「頭脳」である「スプリットブレイン」であり、その人は、複数の脳を持っている場合そして互いに独立して、それは、「失うコントロールを。」身体「ダンス」を引き起こし
スプリットブレインは、通常、クラスタ環境で発生したクラスタ環境では、均一な特徴は、彼らが脳そのクラスタマスター/リーダーノードを持っていることである持っています。
2、クラスタのスプリットブレインのシナリオ
クラスタのは、二つの部屋に配備6台ので構成されるサーバのクラスタは、存在するようになりました、クラスタ、通常、マルチルーム展開の可用性を向上させたいです。
ないより多くの半数以上が、各部屋の中にお互いにそこに通信する、メカニズムを考慮すれば、通常の状況下では、このクラスタは、休憩後にエンジンルームとの間のネットワーク、二つの部屋にあるサーバーまたはすることができそうだとすれば、唯一のリーダーされているだろう私たちは、リーダーを選出します。
これは、元の1クラスタに相当し、2つのクラスタに分割され、スプリットブレインである二つの「頭脳」、ありました。
この場合、我々はまた見ることができる、今同時に2つのクラスタになって、統一された外部サービスプロバイダのクラスタになるはずだった、リソースの競合をサービスを提供しています。しかし、また、問題の出現は:しばらく後に、突然、中国聯通のネットワーク壊れた場合には、2つのマスターの出現をどのように行うには?その後、時間が問題になり、二つのクラスタだけでサービスを提供する必要があり、どのようにマージするデータを、ので、どのようにデータ衝突の問題を解決します。
図3に示すように、溶液
サーバクラスタ現象「スプリットブレイン」を防止するために、クラスタは一般フェンス設備を追加する他は、外部電源供給装置は、外部フェンスと呼ばれているが、いくつかの使用は、独自のサーバ・ハードウェア・インターフェースは、内部フェンスと呼ばれます、ときに、サービスの問題応答タイムアウト、フェンスサーバ装置は、サーバダウン、直接ハードウェア管理コマンド、再起動やシャットダウンを送信し、他のノードのサービスを引き継ぐために信号を送ります。
Red Hatのシステムでは、我々はルーシーとリッチ管理のluciだけ速いのクラスタ構成管理を介してウェブにアクセスするために使用することがルーシーは、スタンドアロンコンピュータまたはノードにインストールされているクラスタ、、、及びその存在または不在により構成されましたこれは、クラスタには影響を与えません。リッチは、クラスタ通信ルーシーにブリッジノードである各ノード上にインストールされています。
ルーシークラスター効果:
ルーシーを設定するために使用してクラスタを管理、8084でリッスンしています
リッチクラスター効果:
リッチは後端の各々について各ノードにインストールされ、クラスタ内の各ノードは、ルーシーによって管理され11111にリッチ、リッチ聴取上のノードと通信します
原理と機能のクラスタフェンス:
事故は、異常なまたはホストを引き起こしダウンし、バックアップ・マシンは、最初の呼び出しフェンスデバイス、そしてFENCE異常なホストデバイスの再起動やネットワークから分離は、FENCEのアクションが正常に発生したときに情報を返します。情報FENCEの成功を受けた後、バックアップサーバー、バックアップ・マシンは、ホストのサービスやリソースを引き継ぐようになりました。FENCEこのような機器では、異常なノードがリソースおよびサービスは、常にノード上で実行されていることを保証するために、リソースの解放によって占められます。そして効果的の「スプリットブレイン」の発生を防ぎます。
第二に、ビルドへの基本的な環境
下面的实验使用的是rhel6系列(rhel6.5)的虚拟机
1、ビルドの説明への基本的な環境
(1)オペレーティングシステムを使用:rhel6.5あります
(2)3つのホストを準備します。
ホスト:フェンスデバイスとして172.25.58.250、前ではないという
SERVER1:172.25.58.1ダウンロードリッチ、ルーシー(コンガは、ユーザインターフェースを提供するように構成された)、マスタノード
サーバ2:172.25.58.2ダウンロードリッチ、スタンバイノードとして
(3)近いserver1とserver2の仮想マシンがfirewalldとSELinux
[root@server1 ~]# service iptables stop
[root@server1 ~]# chkconfig iptables off
[root@server1 ~]# service iptables status
iptables: Firewall is not running.
[root@server1 ~]# getenforce
Disabled
2、FENCEのビルドプロセスを詳細に説明します
最も基本的なRHCSクラスタ環境を構築するには、あること、クラスタを作成します
为设备配置yum源
(1)は、サーバ1サーバ2とソースのrhel6.5 YUM可用性に構成されています。
続き、サーバー1サーバー2上に配置され、共有ディレクトリrhel6.5にミラーをマウントするには
実機:
[root@foundation58 ~]# mount /home/kiosk/rhel-server-6.5-x86_64-dvd.iso /var/www/html/rhel6.5/
mount: /dev/loop2 is write-protected, mounting read-only
[root@foundation58 ~]# cd /var/www/html/rhel6.5/
[root@foundation58 rhel6.5]# ls
EFI Packages RELEASE-NOTES-pa-IN.html
EULA README RELEASE-NOTES-pt-BR.html
EULA_de RELEASE-NOTES-as-IN.html RELEASE-NOTES-ru-RU.html
EULA_en RELEASE-NOTES-bn-IN.html RELEASE-NOTES-si-LK.html
EULA_es RELEASE-NOTES-de-DE.html RELEASE-NOTES-ta-IN.html
EULA_fr RELEASE-NOTES-en-US.html RELEASE-NOTES-te-IN.html
EULA_it RELEASE-NOTES-es-ES.html RELEASE-NOTES-zh-CN.html
EULA_ja RELEASE-NOTES-fr-FR.html RELEASE-NOTES-zh-TW.html
EULA_ko RELEASE-NOTES-gu-IN.html repodata
EULA_pt RELEASE-NOTES-hi-IN.html ResilientStorage
EULA_zh RELEASE-NOTES-it-IT.html RPM-GPG-KEY-redhat-beta
GPL RELEASE-NOTES-ja-JP.html RPM-GPG-KEY-redhat-release
HighAvailability RELEASE-NOTES-kn-IN.html ScalableFileSystem
images RELEASE-NOTES-ko-KR.html Server
isolinux RELEASE-NOTES-ml-IN.html TRANS.TBL
LoadBalancer RELEASE-NOTES-mr-IN.html
media.repo RELEASE-NOTES-or-IN.html
ハイアベイラビリティロードバランサResilientStorage ScalableFileSystem:にここで使用
SERVER1:
[root@server1 yum.repos.d]# ls
rhel-source.repo
[root@server1 yum.repos.d]# cat rhel-source.repo
[HighAvailability]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=http://172.25.58.250/rhel6.5/HighAvailability
enabled=1
gpgcheck=0
[LoadBalancer]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=http://172.25.58.250/rhel6.5/LoadBalancer
enabled=1
gpgcheck=0
[ResilientStorage]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=http://172.25.58.250/rhel6.5/ResilientStorage
enabled=1
gpgcheck=0
[ScalableFileSystem]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=http://172.25.58.250/rhel6.5/ScalableFileSystem
enabled=1
gpgcheck=0
[rhel6.5]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=http://172.25.58.250/rhel6.5
enabled=1
gpgcheck=0
そして、あなたができる、ファイルサーバー2をコピーします。
(2)、ソフトウェアをインストールします
SERVER1インストールされたクラスタノードの管理サービス・リッチ、グラフィカルなクラスタ管理ツールサービスのluci
server1安装ricci和luci图形管理器,启动服务,设置开机自启
yum install -y ricci luci
passwd ricci ##为ricci用户用户设置密码
/etc/init.d/ricci start
/etc/init.d/luci start
chkconfig ricci on 开机自启
chkconfig luci on
从红帽企业版 Linux 6.1 开始,在任意节点中使用 ricci 推广更新的集群配置时要求输入密码
所以在安装完成ricci后需要修改ricci用户的密码,这个是后面节点设置的密码
安装完之后可以看到/etc/passwd文件中自动生成了一个ricci用户
ビューポートの2つのサービス:
[root@server1 yum.repos.d]# netstat -antlp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8084 0.0.0.0:* LISTEN 1384/python
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 894/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 970/master
tcp 0 0 172.25.58.1:22 172.25.58.250:54438 ESTABLISHED 1071/sshd
tcp 0 0 :::22 :::* LISTEN 894/sshd
tcp 0 0 ::1:25 :::* LISTEN 970/master
tcp 0 0 :::11111 :::* LISTEN 1303/ricci
クラスタ管理サービスノードをインストールするには、サーバー2
server2上安装ricci,启动服务,设置开机自启,修改ricci用户密码
yum install ricci -y
passwd ricci
/etc/init.d/ricci start
chkconfig ricci on
(3)、ブラウザで試験した場合:
(4)、この時点でクラスタを作成します。
点击集群管理(manage cluster),选择create,创建集群
设置集群的基本信息,添加节点:
创建时两台虚拟机都会重启,如果之前没有设置服务开机启动这个时候就会报错,重启后要在虚拟机中手动打开服务创建的过程才会继续:
可以看到集群创建完成,节点添加成功:
(5)、在server1上面和server2上面查看
到此为止,基本的实验环境搭建完毕,接下来说明RHCS的高可用体现在哪里
可以看到ricci运行的端口是11111
注意:删除集群时要先删除节点,节点删除后集群会自动消失
如何通过fence设备解决集群节点之间争抢资源的现象?
目前的RHCS高可用集群比之前学的lvs调度器性能更好,功能也会更多,前端后端均有
在这里我们可以把每个集群节点当作一个调度器,实际上功能不止调度器一个
一般情况下集群节点中有主有备,正常情况下会有一个正常工作(调度器正常),但是当调度器坏了就完蛋了
因此要做到:
一台调度器坏了,调度器1就去通知调度器2接管它的工作,正常情况下调度器1和调度器2会一直通信
当2收不到1的消息的时候,就说明1坏了,2马上接替1的工作
但是当1和2之间的心跳检测出现问题的时候,也就是有一个卡死了,其实两个都能正常工作,这个时候两个集群都能工作
因此1和2都会去为客户端服务,会去争抢资源,因此需要fence这样一个物理设备抑制争抢资源
当争抢资源的时候,1会去通过fence设备强制重启2(或者2重启1)
两个集群可以互相强制重启,但是实际当中集群也是有主有备的
现在server1是一个集群,server2是一个集群,真机是一个fence设备(保安)
通过fence这个物理设备将集群连接在一起,保证时刻只有一个集群正常工作
一旦出现争抢资源的现象,主的集群就会通过fence强制重启备的集群,从而使主集群正常工作
2、配置fence设备:
(1)、在集群1上面:
/etc/init.d/ricci status查看集群节点管理工具
/etc/init.d/luci status查看集群图形化管理工具(开启这个浏览器里面才能管理集群)
(一般情况下这两个服务是分开做的)
clustat查看集群状态
cat /etc/cluster/cluster.conf查看集群的配置文件
(2)在集群2上面:
/etc/init.d/ricci status查看集群节点的服务是否开启
clustat
cat /etc/cluster/cluster.conf查看集群是否建立
(3)、在浏览器中添加:fence设备
登录集群管理系统,查看创建的两个集群server1和server2
添加fence设备(fence virt)--->vmfence(名字随便起)
fence只是中间一个通道,server1和server2都是连接在fence这个物理设备上,通过一个集群去拔另外一个集群的电,防止争抢资源
选择fence的类型,起名字,见名知意及可
选择多播模式,设置fence设备的名字为vmfence
3、在物理机配置fence服务:
- yum search fence
- yum install 三个东西 -y
- fence_virtd -c初始化fence设备管理 -全回车,注意网卡是br0(因为两个集群是在虚拟机上面做的,虚拟网卡是通过真实的网卡br0来工作)
- mkdir /etc/cluster 在这个目录下生成fence管理的key,然后传给集群
- 生成fence管理的key:cd /etc/cluster
- dd if=/dev/urandom of=/etc/cluster/fence_xvm.key bs=128(密码太小不安全) count=1(只生成一个key)
- 注意先不要开启fence设备,将key给两个集群各传一个key,保证两个集群得到的key一样,这样fence才能同时管理两个集群
- scp /etc/cluster/fence_xvm.key [email protected]:/etc/cluster
- scp /etc/cluster/fence_xvm.key [email protected]:/etc/cluster
在指定目录下面生成fence的key,并且给两个集群各发送过去一个
注意发送key的时候fence不能开启,否则server1和server2接收到的key不一样
创建一个目录/etc/cluster,生成的key将会保存在这个目录中
编辑完之后如果没有生成密钥文件,可以手动生成一个
4、在server1和2上进行查看是否传输过来:
cd /etc/cluster
ls查看key文件是否过来
cat cluster.conf可以看到集群的配置文件当中添加了fence
在集群2上面查看
cd /etc/cluster
cat cluster.conf 可以看到集群的配置文件当中添加了fence
5、绑定节点——
在浏览器的控制台里面设置
给server1和server2集群添加fence,vmfence_1(名字) uuid(server1主机的),vmfence_2(名字) uuid(server2主机的)
因为两个集群的ip可能会一样,有可能会一次关闭两个集群,不安全
应该把每个集群唯一的uuid写在fence设备上面
在真机里面virt-manager把两个uuid查看出来
在真机里面查看server1虚拟机的uuid:
server2进行同样的操作~~
绑定完成后,可以看到fence配置文件内容如下(查看两个集群节点是否关联在fence设备上,在两个集群节点的集群配置文件里面看):
6、测试:
在server1和server2上添加解析后
然后在物理机上打开fence设备:
systemctl status fence_virtd.service查看fence服务是否开启
systemctl start fence_virtd.servcie开启fence服务
netstat -antlupe | grep 1229(fence服务使用的端口)
此时假若两个机房中的通信出现问题,要将:fence干掉server2,可以看到server2重启:
例:打开server2集群 在server1上面输入:fence_node server2
可以看到集群1把集群2强制重启了
此时server的状态是:offline挂掉的,此时server就开始接手master的工作
[root@server1 ~]# clustat
Cluster Status for cluster @ Sat Feb 15 19:58:47 2020
Member Status: Quorate
Member Name ID Status
------ ---- ---- ------
server1 1 Online, Local
server2 2 Offline
总结:通过fence我们就可以解决争抢资源的问题了,保证客户端有条不紊的访问服务端