《OpenStack HA》第四章 集羣、隔離以及主備服務

整體來講，OpenStack服務提供無狀態服務而且經過提供冗餘實例、使其負載均衡將其管理成爲有狀態的服務。可是，因爲涉及到服務需求的複雜動做管理這些服務是困難的。本章中咱們將基於主備配置使有狀態服務高可用。
主備配置意味着當其餘資源失敗時須要啓動額外的資源上線。無論任什麼時候候必要時，Pacemaker或者是Corosync應用被用來啓動備份資源從新上線。經過一系列譬如Pacemaker和Corosync的組件將會得到高可用特性。
除了Pacemaker集羣的配置、集羣資源以及他們的代理，咱們將一樣會涵蓋啓動順序、故障切換與恢復、以及隔離機制。
本章中，咱們將會涵蓋如下主題：

• 安裝Corosync和Pacemaker
• 高可用MySQL負載均衡
• 依託AMQP的高可用RabbitMQ

安裝Corosync和Pacemaker 在安裝以前，咱們應當瞭解這種實驗性安裝的前提條件。

• 實驗性安裝的要求

在這個實驗當中，咱們將會創建兩個都安裝有Ubuntu 12.04 LTS操做系統節點集羣。建立完成這兩個節點後，分別以controller_1和controller_2命名並分別給他們分配IP地址192.168.56.101和192.168.56.102。接着分配第三個IP地址192.168.1.32做爲虛擬IP地址。

• SSH的安裝

咱們能夠安裝SSH經過祕鑰交換來訪問其餘全部節點，使得節點上的主機文件看起來以下所示。

 |sudo nano /etc/hosts

 

打開host文件後，按照下面的終端截圖作出修改。

• 安裝Corosync包文件

爲了使任意一個主機節點成爲pacemaker集羣的一部分，咱們須要經過Corossync創建集羣通訊，涉及如下包文件的安裝： 

|sudo apt-get install pacemaker corosync crmsh -y
下圖代表Pacemaker的安裝是成功的。

• 共用和生成Corosync祕鑰

做爲初始的安裝步驟，Corosync祕鑰必需要生成而且在集羣中其餘全部的節點上共用。有必要登錄每個Corosync節點，而後安全的集羣通訊就以一種加密的方式完成了。接着這個祕鑰就會被分發到集羣當中的各個節點。

 |corosync –keygen

 

如今將祕鑰共享至node2(controller_2):
rsync -a /etc/corosync/authkey controller_2:/etc/corosync/

• 建立配置文件

如今咱們須要爲Corosync建立配置文件，該文件位於/etc/corosync/corosync.cong。使用Ubuntu操做系統中的任意一個編輯器(vi,nano或者是gedit等等)來編輯該配置文件。
sudo nano /etc/corosync/corosync.conf

根據咱們的安裝步驟按照下圖對集羣的名稱和IP地址進行修改。

• 啓動Corosync

爲了確保corosync的可鏈接性，咱們有一對工具corosycn-ctgtool和corosync-objctl。corosycn-ctgtool工具能夠用來檢查集羣的健康，像啓動一個普通的系統服務來啓動corosync服務，以下所示：
|sudo /etc/init.d/corosync start

corosync-objctl工具將會按以下所示，列出成員列表
corosync-objctl runtime.totem.pg.mrp.srp.members

• 啓動Pacemaker

Corosync啓動後，必須創建通訊來檢查集羣通訊是否正常，添加Pacemaker到Corosync的目的是處理集羣中節點的故障切換。用下面的命令啓動Pacemaker：
sudo nano /etc/init.d/pacemaker start

Pacemaker服務成功啓動後，它將會默認地建立一個空的集羣配置。這個集羣沒有任何資源，咱們在終端上使用crm工具來檢查這個集羣的狀態：
|crm_mon

• 設置集羣屬性

藉助crm shell須要爲pacemaker集羣設置基礎的集羣屬性，使用配置命令來更改配置文件。如如下是一些集羣屬性：
·no-quorum-policy=」ignore」:當咱們正在使用一個兩節點的集羣時，這個屬性值設置爲忽略，若是咱們設置這個值，兩個節點都會保持在線並且二者之間會失去通訊。當咱們在集羣中使用三個及以上的節點時這個值將會被設置。
·pe-warn-series-max=」1000″,pe-input-series-max=」1000″和pe-error-series-max=」1000″：設置這些值成1000向Pacemaker發送請求維持一長段由集羣處理過的輸入歷史。
·cluster-recheck-interval=」5min」:設置這個值來處理集羣狀態須要一種事件驅動的方法，它用來使Pacemaker動做在自定義的間隔發生。咱們能夠根據集羣需求改變這個值或者間隔，就像下面的截圖那樣：
|crm-configure

• 高可用MySQL負載均衡

許多OpenStack服務使用MySQL做爲默認的數據庫服務器，當任何一個節點負荷過載或者由於某些緣由失敗時，負載均衡是必要的。爲了管理這種故障切換，咱們須要部署一種以下所述被稱爲高可用的解決方案。爲了使得這種MySQL數據庫服務器高可用，它須要配置DRB服務（分佈式複製塊服務）如在接下來章節解釋的那樣。

• DRBD複製存儲

經過DRDB完成磁盤間的數據複製，在咱們的案列中，磁盤/dev/sdb存在於controller_1和controller_2上。咱們須要使用如下命令編輯DRDB配置文件。
sudo gedit /etc/drbd.conf

配置文件看起來像下面所示：

C協議用來在設備間建立鏈接，而且它被用做爲是複製協議。此後，咱們要爲複製初始化輸入一些DRBD命令裏，列舉以下：
drbdam create-md mysql

一旦執行了前面的命令，咱們將會獲得初始設備建立。

而後，咱們須要用下面的命令開始任一節點上的複製，在controller_1或者controller_2上：
drbdam- –force primary mysql

如今複製已經開始了。而後，咱們須要以下命令來檢查複製的狀態
cat /proc/drbd

• 安裝MySQL

用如下命令兩個節點（controller_1和controller_2）上完成安裝：
sudo apt-get install mysql-server

接着，咱們將會把虛擬IP添加到my.cnf中，示例以下：
sudo gedit /etc/my.cnf

bind-address = 192.168.1.32
上面的更改須要在mysql bind-address中完成來監聽Pacemaker.因此它可以明白MySQL用來和Pacemaker通訊的IP地址是什麼。
所以,MySQL的地址將會被綁定到提到的地址。
添加MySQL資源到Pacemaker。
此後，咱們將會爲MySQL資源添加Pacemaker配置到集羣中。使用crm配置，鏈接Pacemaker集羣並添加如下集羣資源。
primitive p_ip_mysql ocf:heartbeat:IPaddr2 \
params ip=」192.168.1.32″ cidr_netmask=」24″ \
op monitor interval=」30s」
primitive p_drbd_mysql ocf:linbit:drbd \
params drbd_resource=」mysql」 \
op start timeout=」90s」 \
op stop timeout=」180s」 \
op promote timeout=」180s」 \
op demote timeout=」180s」 \
op monitor interval=」30s」 role=」Slave」 \
op monitor interval=」29s」 role=」Master」
primitive p_fs_mysql ocf:heartbeat:Filesystem \
params device=」/dev/drbd/by-res/mysql」 \
directory=」/var/lib/mysql」 \
fstype=」xfs」 \
options=」relatime」 \
op start timeout=」60s」 \
op stop timeout=」180s」 \
op monitor interval=」60s」 timeout=」60s」
primitive p_mysql ocf:heartbeat:mysql \
params additional_parameters=」–bind-address=192.168.42.101″ \
config=」/etc/mysql/my.cnf」 \
pid=」/var/run/mysqld/mysqld.pid」 \
socket=」/var/run/mysqld/mysqld.sock」 \
log=」/var/log/mysql/mysqld.log」 \
op monitor interval=」20s」 timeout=」10s」 \
op start timeout=」120s」 \
op stop timeout=」120s」
group g_mysql p_ip_mysql p_fs_mysql p_mysql
ms ms_drbd_mysql p_drbd_mysql \
meta notify=」true」 clone-max=」2″
colocation c_mysql_on_drbd inf: g_mysql ms_drbd_mysql:Master
order o_drbd_before_mysql inf: ms_drbd_mysql:promote g_mysql:start
添加集羣細節到mysql中以後，咱們將會獲得以下所示的狀態。

一旦配置已經被執行，集羣將會啓動資源，若是正常運行，你應該會有MySQL運行在其中一個節點上，能夠用過虛擬IP地址來訪問。若是集羣中任何一個激活的節點的通訊丟失發生，那個節點將會被從集羣中移除或者隔離開。經過隔離機制，被隔離開的節點將會徹底從集羣孤立出來。
爲了檢查集羣的狀態，輸入如下命令：
|crm_mon -1

• 依託AMQP的高可用RabbitMQ

AMQP服務器經過RabbitMQ被用做許多的OpenStack服務的默認的服務器。經過配置DRDB設備，使得服務高可用。

• 配置DRDB

DRDB的配置包括如下幾點：

• RabbitMQ可使用已配置的DRDB設備
• 屬於本RabbitMQ設備的數據路徑能夠被這種配置所使用
• 在集羣節點間虛擬IP以自由的方式選擇和分配浮動IP

使用如下命令來完成RabbitMQ DRDB資源配置
sado nano /etc/drbd.d/rabbit.res

rabbitmq路徑爲基於Pacemaker的rabbirmq服務器從DRDB資源加載，rabbirmq服務器資源的配置示例以下：

前文提到的在集羣節點controller_1和controller_2的資源使用一個叫作/dev/data/rabbitmq的備份設備。咱們將會在以前指定的目錄下使用下列命令建立一個初始化設備，將初始元數據集寫入rabiimq設備：
drbdadm create-ms rabbitmq

• 建立文件系統

一旦成功運行DRDB資源就須要文件系統就緒，須要爲在RabbitMQ中可獲取的數據建立文件系統。將這個步驟當作是文件系統建立過程的一個基礎步驟：
mkfs -t xfs /dev/drbd1

既然資源的名稱是自解釋的，咱們能夠經過如下命令爲一個初始化的DRDB使用備選的設備路徑：
mkfs -t xfs /dev/drbd/by-res/rabbitmq

爲了使設備返回集羣中第二個正在運行的進程，使用如下命令：
drbdadm secondary rabbitmq

• 爲Pacemaker的高可用特性準備RabbitMQ

爲確保Pacemaker的監聽功能，咱們須要檢查controller_1和controller_2上的erlang.cookie文件是一致的。因此，erlang.cookie文件從controller_1節點拷貝到controller_2節點、拷貝到RabbitMQ數據目錄和DRDB文件系統，示例以下：
erlang.cookie文件須要從一個節點拷貝到另外一個節點：
scp -p /var/lib/rabbitmq/.erlang.cookie controller_2:/var/lib/rabbitmq

使用如下命令來加載一個rabbitmq目錄：
mount /dev/drbd/by-res/rabbitmq /mnt

拷貝erlang.cookie使它可以在一個新的設備上被加載，使用如下命令：
sudo cp -a /var/lib/rabbitmq/.erlang.cookie /mnt

最後，卸載一個添加了的目錄，示例以下：
sudo unmount /mnt

• 添加RabbitMQ資源到Pacemaker

如今咱們添加Pacemaker配置到RabbitMQ資源，使用crm工具來配置和添加如下幾行到集羣資源，示例以下：
|crm configure
在這些代碼以後，在終端輸入以前的命令：
primitive p_ip_rabbitmq ocf:heartbeat:IPaddr2 \
params ip=」192.168.1.32″ cidr_netmask=」24″ \
op monitor interval=」10s」
primitive p_drbd_rabbitmq ocf:linbit:drbd \
params drbd_resource=」rabbitmq」 \
op start timeout=」90s」 \
op stop timeout=」180s」 \
op promote timeout=」180s」 \
op demote timeout=」180s」 \
op monitor interval=」30s」 role=」Slave」 \
op monitor interval=」29s」 role=」Master」
primitive p_fs_rabbitmq ocf:heartbeat:Filesystem \
params device=」/dev/drbd/by-res/rabbitmq」 \
directory=」/var/lib/rabbitmq」 \
fstype=」xfs」 options=」relatime」 \
op start timeout=」60s」 \
op stop timeout=」180s」 \
op monitor interval=」60s」 timeout=」60s」
primitive p_rabbitmq ocf:rabbitmq:rabbitmq-server \
params nodename=」rabbit@localhost」 \
mnesia_base=」/var/lib/rabbitmq」 \
op monitor interval=」20s」 timeout=」10s」
group g_rabbitmq p_ip_rabbitmq p_fs_rabbitmq p_rabbitmq
ms ms_drbd_rabbitmq p_drbd_rabbitmq \
meta notify=」true」 master-max=」1″ clone-max=」2″
colocation c_rabbitmq_on_drbd inf: g_rabbitmq ms_drbd_rabbitmq:Master
order o_drbd_before_rabbitmq inf: ms_drbd_rabbitmq:promote g_rabbitmq:start

前述的配置文件在集羣中產生了如下重要的更改：

• p_ip_rabbitmq:經過這個參數，RabbitMQ將會使用虛擬IP地址
• p_fs_rabbitmq:經過這個參數，RabbitMQ當前正在運行的節點文件系統將會被加載
• ms_drbd_rabbitmq:經過這個參數，rabbitmq DRDB服務會被主/從集所管理。

使用其餘的限制好比服務組、順序和排列來保證每一個節點上的全部的資源以正常的序列正常啓動。
|crm configure
在使用crm配置工具作出全部的修改，咱們經過輸入提交命令來提交配置：
|commit

• 爲高可用RabbitMQ配置OpenStack服務

如今OpenStack提供的全部服務指向RabbitMQ配置，其高可用性是藉助於虛擬IP地址取代了物理IP地址而實現的，。 例如，OpenStack image服務指向虛擬IP地址（在glance-api文件中更改rabbit_host指向虛擬IP）。OpenStack配置服務再也不須要其餘更改。因此，若是任何做爲RabbitMQ的主機節點，由於一些網絡問題遇到任何服務故障切換問題，服務能夠沒有任何中斷繼續運行。總結本章中，咱們學到了OpenStack中的一些服務仍然不是徹底無狀態的，所以它們須要典型的集羣方法，好比Pacemaker。咱們深刻分析了一個服務集羣的構建，它們的資源代理以及依賴。 咱們一樣學會了高可用MySQL和藉助於AMQP的RabbitMQ高可用的負載均衡的一步步設置和配置。 在下一章，咱們將會對OpenStack服務在無狀態模式下如何互相協同工做來提供一個可伸縮性的雲架構有個更加深刻的理解。