OpenStack高可用方案及配置

時間 2019-12-05

標籤 openstack 可用方案配置简体版

原文原文鏈接

1 OpenStack高可用介紹

1.1 無狀態和有狀態服務

無狀態服務指的是該服務接收的請求先後之間沒有相關關係，接收並處理完該請求後不保存任何狀態，在OpenStack的服務中常見的無狀態服務有：nova-api、glance-api、keystone-api等服務，大部分都是一些用於接收請求的服務。前端

有狀態服務跟無狀態服務相反，它對後續請求的處理依賴於上一次請求的結果，保存了上一次請求處理的結果。在OpenStack的服務中常見的有狀態服務有：數據庫服務、高級消息隊列服務等服務。node

對於無狀態服務的高可用，只須要在多個節點中都部署該服務，而後使用相似HaProxy的負載均衡軟件來轉發請求便可達到高可用。對於有狀態的服務，可採用A/A（主/主）或A/P（主/從）方式來搭建高可用。mysql

1.2 A/A方式

A/A方式也叫作主/主模式，通常是原生實現的方式，也就是說同時有多個相同的服務在運行，當某個節點上的服務不能提供服務時，其它節點的該服務能夠替代它進行服務，從而達到高可用。linux

上面所說的無狀態服務基本都是採用A/A這種方式，通常使用HaProxy軟件做爲負載均衡。而有狀態的服務採用該方式就是在各節點維護徹底相同的該服務，也就是說一個請求的處理也須要通知到其它節點的該服務，好比數據庫服務，對數據庫的更新須要同步到其它節點的數據庫，保證各數據庫存儲的數據是一致的。git

優勢：多主、零切換、方便的實現負載均衡github

缺點：每一個節點都運行着相同實例，帶來更多的負載。算法

1.3 A/P方式

A/P方式也叫做主/從模式，須要經過第三方軟件好比pacemaker來對備份服務進行激活等管理操做，也就是說有一個服務做爲主服務在運行，另外一個服務做爲備份，並未運行，當主服務不能提供服務時，備份服務就會被激活並替代主服務繼續提供服務。好比數據庫服務，某個節點的數據庫服務進程進行服務，在另一個節點維護一套災備數據庫，當主數據庫服務不能提供服務時，災備數據庫就會被激活並替代主服務進行服務。sql

優勢：兩個節點也能夠組成高可用數據庫

缺點：後端

（1）主備切換時間較長；

（2）只有主服務提供服務，在使用兩個節點的狀況下不能作負載均衡；

（3）DRDB腦裂會致使數據丟失的風險，A/P方式的MariaDB高可用可靠性沒有A/A方式的Galera MariaDB高。

1.4 A/A和A/P的選擇

部署OpenStack組件的高可用通常遵循如下原則：能採用A/A的方式就採用A/A的方式，不能的話就採用A/P的方式。

2 各種節點高可用配置

2.1 各種節點無狀態服務高可用配置

無狀態服務大可能是屬於api服務類型的，也就是進入服務的入口，好比nova-api、keystone-api等基本上都是無狀態的服務，同時也包含一些服務只服務於單個節點上的，好比nova-compute、nova-conductor、nova-scheduler等，這些都只須要在多個節點上都部署相同的服務再加上使用HaProxy軟件做爲負載均衡便可實現高可用。如下以keystone-api爲例列出在HaProxy軟件中的配置信息：

 listen keystone_admin_cluster

  bind <Virtual IP>:35357

  balance  source

  option  tcpka

  option  httpchk

  option  tcplog

  server controller1 10.0.0.12:35357 check inter 2000 rise 2 fall 5

  server controller2 10.0.0.13:35357 check inter 2000 rise 2 fall 5

  server controller3 10.0.0.14:35357 check inter 2000 rise 2 fall 5

 

 listen keystone_public_internal_cluster

  bind <Virtual IP>:5000

  balance  source

  option  tcpka

  option  httpchk

  option  tcplog

  server controller1 10.0.0.12:5000 check inter 2000 rise 2 fall 5

  server controller2 10.0.0.13:5000 check inter 2000 rise 2 fall 5

  server controller3 10.0.0.14:5000 check inter 2000 rise 2 fall 5

這裏的Virtual IP能夠是由Pacemaker提供的虛擬IP。3個控制節點可使用Pacemaker+corosync的方式組成一個集羣，虛擬IP能夠存在於集羣中的其中一個節點上，能夠設置成只有HaProxy進程是存活狀態下的節點，虛擬IP纔有可能會在該節點上，而後該節點的HaProxy進程就會做爲接收點，其它節點的HaProxy做爲備用當，該節點網絡不可用時或HaProxy進程不是存活狀態時，虛擬IP能夠自動轉移到集羣中的其它正常節點上。能夠看到其實HaProxy軟件最大的做用就是起到了一個請求轉發的做用，請求先發到了HaProxy進程中，HaProxy再根據哪一個節點上的相關服務是可用的，再轉發給該節點進行處理。

2.2 控制節點高可用配置

部署在控制節點的服務主要有數據庫服務、高級消息隊列服務、Memcached服務、身份認證服務、鏡像服務、各種api服務等。各種api服務的高可用配置能夠參照2.1。

2.2.1 數據庫服務高可用配置

OpenStack的數據庫選擇能夠有好幾種，好比MySQL、MariaDB（MySQL的一個分支）和PostgreSQL等，但在OpenStack服務中選擇使用最多的是MariaDB。MariaDB高可用既可使用A/A方式也可使用A/P方式，這裏咱們使用業界最廣泛使用的A/A方式，即Galera MariaDB。

如下是Galera MariaDB的配置過程，每一個節點上都需配置（能夠先使用find命令搜索下你的系統裏是否裝有libgalera_smm.so，配置文件的選項中有須要寫明路徑指向它，沒有的話能夠嘗試安裝Galera）：

編輯/etc/hosts文件，加上你各節點的IP和對應的節點名（10.170是虛擬IP），好比：

192.168.10.170 controller

192.168.10.171 controller1

192.168.10.172 controller2

192.168.10.173 controller3

編輯/etc/security/limits.conf文件，加上如下內容：

* soft nofile 65536

* hard nofile 65536

編輯/etc/sysctl.conf文件並加上如下內容：

fs.file-max=655350

net.ipv4.ip_local_port_range = 1025 65000

net.ipv4.tcp_tw_recycle = 1

net.ipv4.ip_nonlocal_bind = 1

而後執行：

sysctl -p

編輯/etc/my.cnf.d/mariadb-server.cnf文件，加上或更新如下配置：

[mysqld]

server_id=128

datadir=/app/galera

user=mysql

skip-external-locking

skip-name-resolve

character-set-server=utf8

max_connections = 4096

 

[galera]

wsrep_causal_reads=ON  #節點應用完事務才返回查詢請求  

wsrep_provider_options="gcache.size=4G" #同步複製緩衝池  

wsrep_certify_nonPK=ON   #爲沒有顯式申明主鍵的表生成一個用於certificationtest的主鍵，默認爲ON  

 

query_cache_size=0           #關閉查詢緩存  

wsrep_on=ON   #開啓全同步複製模式  

wsrep_provider=/usr/lib64/galera/libgalera_smm.so #galera library  

wsrep_cluster_name=MariaDB-Galera-Cluster

wsrep_cluster_address="gcomm://192.168.10.171,192.168.10.172,192.168.10.173"

wsrep_node_name=controller1

wsrep_node_address=192.168.10.171

binlog_format=row

default_storage_engine=InnoDB

innodb_autoinc_lock_mode=2   #主鍵自增模式修改成交叉模式  

wsrep_slave_threads=8  #開啓並行複製線程，根據CPU核數設置  

innodb_flush_log_at_trx_commit=0   #事務提交每隔1秒刷盤  

innodb_buffer_pool_size=2G

wsrep_sst_method=rsync

bind-address=192.168.x.x  #這裏ip改成你當前節點的ip

在MariaDB的各個節點上分別執行：

mysql_install_db --defaults-file=/etc/my.cnf.d/mariadb-server.cnf --user=mysql

在其中一個節點上執行（只要在一個節點上執行便可）：

mysqld_safe --defaults-file=/etc/my.cnf.d/mariadb-server.cnf --user=mysql  --wsrep-new-cluster &

執行完後在其它節點上分別執行：

mysqld_safe --defaults-file=/etc/my.cnf.d/mariadb-server.cnf --user=mysql  &

登陸三個節點查看是否已經配置好：

mysql -uroot -p

MariaDB [(none)]> SHOW STATUS LIKE 'wsrep_cluster_size';

+--------------------+-------+

| Variable_name      | Value |

+--------------------+-------+

| wsrep_cluster_size | 3     |

+--------------------+-------+

驗證是否有打出你的數據庫集羣數量，我這裏是配置了3個MariaDB組成的一個Galera MariaDB集羣，因此打出的數量是3。

若是是使用HaProxy做爲負載均衡軟件來訪問Galera Mariadb集羣，你可使用如下配置來檢查數據庫集羣的健康狀態（如下除了數據庫執行語句能夠只在一個節點上執行，其它好比配置文件、服務啓動都須要在各個節點上執行）：

建立/etc/sysconfig/clustercheck文件並配置如下內容：

MYSQL_USERNAME="clustercheck_user"

MYSQL_PASSWORD="my_clustercheck_password"

MYSQL_HOST="localhost"

MYSQL_PORT="3306"

登陸數據庫集羣中的其中一個節點的數據庫客戶端並執行如下數據庫語句：

GRANT PROCESS ON *.* TO 'clustercheck_user'@'localhost' IDENTIFIED BY 'my_clustercheck_password';

FLUSH PRIVILEGES;

建立/etc/xinetd.d/galera-monitor文件用於haproxy監視器監聽配置：

service galera-monitor

{

   port = 9200

   disable = no

   socket_type = stream

   protocol = tcp

   wait = no

   user = root

   group = root

   groups = yes

   server = /usr/bin/clustercheck

   type = UNLISTED

   per_source = UNLIMITED

   log_on_success =

   log_on_failure = HOST

   flags = REUSE

}

注意從上面配置文件中咱們看到了:

server = /usr/bin/clustercheck

說明咱們的系統中須要有這個clustercheck程序，本身能夠檢查下/usr/bin目錄下是否有該程序，若是沒有則須要下載下來並放到該目錄下，下載連接：https://raw.githubusercontent.com/olafz/percona-clustercheck/master/clustercheck

且賦予執行權限：

wget https://raw.githubusercontent.com/olafz/percona-clustercheck/master/clustercheck /usr/bin/clustercheck

chmod +x /usr/bin/clustercheck

它是經過執行該程序來檢測當前節點的mysql是不是可用的，若是可用通常輸出以下：

[root@abc2 ~]# /usr/bin/clustercheck

HTTP/1.1 200 OK

Content-Type: text/plain

Connection: close

Content-Length: 40

 

Percona XtraDB Cluster Node is synced.

不可用時輸出以下：

[root@abc0 ~]# /usr/bin/clustercheck

HTTP/1.1 503 Service Unavailable

Content-Type: text/plain

Connection: close

Content-Length: 44

 

Percona XtraDB Cluster Node is not synced.

執行如下命令（確保安裝了xinetd服務）

systemctl daemon-reload

systemctl enable xinetd

systemctl start xinetd

最好檢測下9200端口是否是真的被xinetd程序使用着：

[root@abc2 ~]# netstat -tunlp |grep 9200

tcp6      0    0 :::9200               :::*        LISTEN      1078/xinetd

在HaProxy配置文件中能夠以下配置數據庫請求轉發服務：

listen galera_cluster

  bind <Virtual IP>:3306

mode tcp

  balance  source

  option  mysql-check

  server controller1 10.0.0.12:3306 check port 9200 inter 2000 rise 2 fall 5

  server controller2 10.0.0.13:3306 backup check port 9200 inter 2000 rise 2 fall 5

  server controller3 10.0.0.14:3306 backup check port 9200 inter 2000 rise 2 fall 5

在keystone、nova、neutron等配置文件中凡是配置鏈接到數據庫的配置都應該相似以下配置，以nova.conf配置文件中的爲例：

[database]

connection = mysql+pymysql://nova:123456@controller/nova

這裏咱們能夠看到123456是nova用戶的密碼，使用的controller是虛擬IP對應的虛擬主機名，如此它就會在鏈接請求時先鏈接到HaProxy進程，再由HaProxy進程選擇某個節點的數據庫服務進行鏈接發送請求。

2.2.2 高級消息隊列服務高可用配置

高級消息隊列承擔着爲相關服務進程傳遞信息的做用，好比nova-api、nova-conductor、nova-scheduler等服務之間都須要經過高級消息隊列來進行通訊，OpenStack使用的高級消息隊列都是基於AMQP的，常見的應用服務有Rabbitmq、ZeroMQ等，咱們選擇OpenStack支持最好的RabbitMQ來做爲高級消息隊列服務。

RabbitMQ原生就有高可用的實現，咱們這裏使用RabbitMQ集羣+鏡像隊列模式來實現高可用，鏡像隊列的做用就是消息實體會主動在鏡像節點之間實現同步，此模式的一個缺點是RabbitMQ集羣內部的同步通信會佔用大量的網絡帶寬。配置方法以下：

先在各個節點上中止rabbitmq服務：

systemctl stop rabbitmq-server

rabbitmqctl stop

我這裏以3個節點controller一、controller2和controller3爲例，選定controller1節點，將該節點的/var/lib/rabbitmq/.erlang.cookie文件拷貝給其它節點，保證不一樣節點間有同一認證的Erlang Cookie：

scp /var/lib/rabbitmq/.erlang.cookie root@controller2:/var/lib/rabbitmq/

scp /var/lib/rabbitmq/.erlang.cookie root@controller3:/var/lib/rabbitmq/

接着在各節點上執行：

chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie

chmod 400 /var/lib/rabbitmq/.erlang.cookie

rabbitmq-server -detached

在controller1節點上執行

rabbitmqctl start_app

在controller2和controller3節點上分別執行：

rabbitmqctl stop_app

rabbitmqctl join_cluster controller1@rabbitmqCluster

rabbitmqctl start_app

在各節點上分別執行：

systemctl restart rabbitmq-server

在各節點上分別執行rabbitmqctl cluster_status進行驗證，若是相似以下即爲正常：

Cluster status of node rabbit@controller1 ...

[{nodes,[{disc,[rabbit@controller1,rabbit@controller2,rabbit@controller3]}]},

 {running_nodes,[rabbit@controller3,rabbit@controller2,rabbit@controller1]},

 {cluster_name,<<"rabbit@controller1">>},

 {partitions,[]},

 {alarms,[{rabbit@controller3,[]},

          {rabbit@controller2,[]},

          {rabbit@controller1,[]}]}]

partitions裏若是有節點通常非正常，能夠經過重啓rabbitmq-server服務來恢復。

在controller1節點上執行如下語句使其變爲鏡像模式：

rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{"ha-mode": "all"}'

在爲OpenStack的服務配置使用rabbitmq消息隊列服務時，能夠以下配置：

transport_url = rabbit://openstack:123456@controller1,openstack:123456@controller2,openstack:123456@controller3

能夠看到這裏的配置方式是將全部節點的rabbitmq服務以拼接方式拼在一塊兒，當controller1節點上的消息隊列服務不可用時能夠將請求轉發給controller2，再不行能夠再轉發給controller3節點。

同時應該配置以下參數：

rabbit_retry_interval=1

rabbit_retry_backoff=2

rabbit_max_retries=0

rabbit_durable_queues=true

rabbit_ha_queues=true

2.2.3 Memcached服務高可用配置

Memcached服務能夠用來爲OpenStack的多個服務緩存一些臨時的數據，可使得不用每一次都去真實訪問取得數據，使得訪問不至於過於頻繁，減小了資源使用且加快了效率，好比能夠用於緩存keystone的token值。

OpenStack服務在配置文件中配置使用Memcached服務時，能夠以下配置：

memcached_servers = controller1:11211,controller2:11211,controller3:11211

2.3 網絡節點高可用配置

部署在網絡節點上的服務主要有DHCP Agent服務、L3 Agent服務和Metadata Agent服務，Metadata Agent服務的高可用只需各網絡節點都部署該服務便可，如下主要是講DHCP Agent和L3 Agent服務的高可用配置。

2.3.1 DHCP Agent服務高可用配置

因爲DHCP協議自身就支持多個DHCP服務器，所以只須要在各個網絡節點上部署DHCP Agent服務，而且在配置文件中配置相關選項，便可實現租戶網絡的DHCP服務是高可用的。配置方式以下：

在各網絡節點上編輯/etc/neutron/neutron.conf文件，在[default]下加上如下內容：

agent_down_time = 30

report_interval=15

dhcp_agents_per_network = 3

而後重啓網絡服務：systemctl restart neutron-server

可使用neutron客戶端的命令驗證下是否生效：

使用openstack network list查看下你的網絡

而後使用neutron dhcp-agent-list-hosting-net network-id來查看該網絡的DHCP服務是不是HA的。

+--------------------------------------+-------------+----------------+-------+

| id                                   | host        | admin_state_up | alive |

+--------------------------------------+-------------+----------------+-------+

| 4e1ac514-f334-4f53-9765-57df5775fadd | controller3 | True           | :-)   |

| bb89eb4d-e9a8-4fba-8c3f-cd24892c664d | controller2 | True           | :-)   |

| db05682b-dbe1-40e6-8fe1-6205457d6c15 | controller1 | True           | :-)   |

+--------------------------------------+-------------+----------------+-------+

由上面的表能夠看出個人這個租戶網絡是有3個DHCP服務在爲其服務的，各節點上各一個DHCP爲該租戶網絡服務，因此即便某節點關機了，還有其它DHCP服務爲該網絡服務，所以是高可用的。

2.3.2 L3 Agent服務高可用配置

Neutron自己的調度器neutron-scheduler服務是支持在多個網絡節點上部署L3 Agent服務的，但L3 Agent是用來管理虛擬路由器的，因此須要虛擬路由器服務自身須要實現高可用，當前虛擬路由器的高可用實現方式有幾種，最主流的方式有兩種，一種是VRRP（虛擬路由冗餘協議）方案，另一種是DVR（分佈式虛擬路由）方案。

這裏選擇使用VRRP的方案來配置高可用，配置方式以下：

編輯/etc/neutron/plugins/ml2/linuxbridge_agent.ini文件並更新如下內容：

[vxlan]

#l2_population = true

編輯/etc/neutron/neutron.conf文件並更新下列內容：

[default]

l3_ha = True

編輯/etc/neutron/l3_agent.ini文件並更新如下內容：

[default]

external_network_bridge =

這個external_network_bridge是故意設置成沒有值的。

重啓網絡服務：

systemctl restart neutron-server.service neutron-linuxbridge-agent.service neutron-dhcp-agent.service neutron-metadata-agent.service neutron-l3-agent.service

可使用命令neutron l3-agent-list-hosting-router router-id來查看router的master l3-agent是在哪一個節點上。

+--------------------------------------+-------------+----------------+-------+----------+

| id                                   | host        | admin_state_up | alive | ha_state |

+--------------------------------------+-------------+----------------+-------+----------+

| 1f0b2639-cff3-42f6-bb19-b57021646b60 | controller1 | True           | :-)   | standby  |

| 72e65e4b-e568-4279-8e22-aa7e80a62f5c | controller3 | True           | :-)   | standby  |

| af871274-c085-4ba6-8d8f-6a9ee909efbb | controller2 | True           | :-)   | active   |

+--------------------------------------+-------------+----------------+-------+----------+

執行後能夠看到上表的輸出結果，從輸出結果中能夠看到controller2的L3 Agent是master，controler1和controller3都是備用的。

2.4 計算節點高可用配置

部署在計算節點上的服務有L2 Agent服務、nova-compute服務等服務，這些服務都是服務於自身節點的，因此無需加任何配置，只需保證各計算節點上都有該服務便可。

2.4.1 虛擬機HA高可用配置

計算節點是運行虛擬機的節點，因此咱們關心的是當該虛擬機所在的計算節點宕機後虛擬機是否還能繼續正常運行，這就是虛擬機的高可用問題，按照咱們想要的狀況是在該計算節點宕機後該節點上的虛擬機應該可以自動遷移到其它計算節點上繼續正常運行，但這也須要一些前提條件，好比虛擬機的存儲應該都是存放在共享存儲的，而非本地存儲。目前OpenStack對於虛擬機的高可用性還在開發中，業界一些企業已經有本身的實現方案，這裏只列出幾個方案，其實本質就是還缺乏個監控某計算節點是否真的不能再爲虛擬機提供服務了，使用nova evacuate的模塊功能能夠將該虛擬機從共享存儲上將其恢復，並運行在其它正常計算節點上。

業界的幾個解決方案：

（1）利用控制節點去檢查計算節點的管理網、存儲網和租戶網，定製特定的策略當哪些網絡不可用時就斷定該計算節點不可用，接着啓動nova evacuate模塊功能將虛擬機運行在其它可用的計算節點上。

（2）管理、存儲、租戶網上分別部署Gossip Pool，計算節點之間同時經過三個Gossip Pool互相檢查連通性，每一個Gossip Pool裏發現的問題節點上報到控制節點上去。

2.5 存儲節點高可用配置

存儲節點的後端存儲方式能夠採用Ceph集羣的存儲方式，自己是分佈式性質的存儲，保證了存儲數據的高可用性。部署在存儲節點的OpenStack服務有cinder-api、cinder-scheduler、cinder-volume。這裏只需關注cinder-volume的高可用便可。

cinder-volume因爲在目前的代碼中存在資源競爭問題，官方推薦的是使用A/P的方式來實現高可用，也就是說在某時刻，只有主節點上的cinder-volume在提供服務，須要藉助於第三方軟件好比Pacemaker來進行管理。如下是一些配置過程：

在pacemaker集羣的其中一個節點上執行如下命令：

pcs resource create openstack-cinder-api systemd:openstack-cinder-api --clone interleave=true

pcs resource create openstack-cinder-scheduler systemd:openstack-cinder-scheduler --clone interleave=true

pcs resource create openstack-cinder-volume systemd:openstack-cinder-volume

pcs constraint order start openstack-cinder-api-clone then openstack-cinder-scheduler-clone

pcs constraint colocation add openstack-cinder-scheduler-clone with openstack-cinder-api-clone

pcs constraint order start openstack-cinder-scheduler-clone then openstack-cinder-volume

pcs constraint colocation add openstack-cinder-volume with openstack-cinder-scheduler-clone

pcs constraint order start openstack-keystone-clone then openstack-cinder-api-clone

4 高可用部署方案設計

4.1 方案一

其中：

（1）首先該方案至少須要使用3個控制節點，使用Pacemaker+corosync組成一個集羣，使用Pacemaker提供一個虛擬IP，每一個控制節點都包含了有控制節點、計算節點、網絡節點和存儲節點的最基本的服務。

（2）使用HaProxy軟件來作負載均衡，HaProxy的前端接收請求綁定該虛擬IP，HaProxy後端選擇某個可用節點將請求轉發到該節點上去處理。

（3）這三個控制節點也充當着計算節點的功能，可是能夠經過建立一個配置文件，配置文件中記錄該節點最多能夠運行多少臺虛擬機，而後在nova-scheduler調度算法上加上咱們的限制邏輯，若是該控制節點的虛擬機數量超過配置文件配置的數量，則過濾掉該節點。

（4）計算節點做爲可拓展的形式，能夠添加新的節點做爲計算節點，且計算節點也充當着存儲節點的功能，讓整個服務能夠運行更多的虛擬機。

（5）該方案適用於規模較小的私有云，優勢是能夠以較少的硬件成本搭建高可用的OpenStack環境，缺點是控制節點上堆疊了過多的服務，每一個控制節點的負載都偏高，性能上可能會受影響。

4.2 方案二

其中：

（1）從上圖能夠看到方案二實際上是在方案一的基礎上將各類服務分解開來，好比將網絡節點和計算節點的功能都獨立出來，而後3個控制節點組成一個集羣，3個網絡節點組成一個集羣，多個Ceph節點組成Ceph集羣，提供後端存儲，多個計算節點用來爲虛擬機提供運行資源。

（2）該方案適用於規模較大的公有云和私有云，全部服務按照分類都分散到不一樣的集羣，節點的負載都比較少，性能能知足大量虛擬機的建立和使用。缺點是須要的硬件成本比較高。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。