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）该方案适用于规模较大的公有云和私有云，全部服务按照分类都分散到不一样的集群，节点的负载都比较少，性能能知足大量虚拟机的建立和使用。缺点是须要的硬件成本比较高。