用Kolla在阿里云部署10节点高可用OpenStack

为展现 Kolla 的真正实力,我在阿里云使用 Ansible 自动创建 10 台虚机,部署一套多节点高可用 OpenStack 集群!

前言

上次 Kolla 已经表示了要打 10 个的愿望,这次我们就满足它。

通过本期内容,你将看到:

  • 如何使用阿里云云命令行(Cloud Shell)
  • 如何使用 Ansible 创建阿里云资源
  • Kolla 多节点部署配置说明
  • OpenStack 高可用架构

本期内容仍然是干货满满,写文章,调脚本,剪视频,不但花时间,还要在 阿里云 花钱租云服务器,真的费了不少精力,所以如果本文对你有所帮助,请务必点赞支持!谢谢。

操作过程仍可在 B站观看视频

准备工作

使用 Cloud Shell

一次性创建 10 台虚机,从界面一个个的点就太无聊了。所以我们要想办法让这个过程自动化地完成。

第一个念头就是用 Python 去调用 API,于是直奔 开发者工具 页面而去,却发现阿里云提供了网页版的命令行工具:Cloud Shell,使用起来更加方便。

启动 Cloud Shell 会自动为你创建一个虚机,里面不但内置了连接阿里云的 CLI 工具,而且因为是登录后启动,它自动把认证也处理了。也就是说我们直接就可以开始使用了,非常方便。

具体请参考官方文档:什么是云命令行?

不仅如此,为了让大家更好地掌握这些工具的用法,还提供了交互式的 实验教程,花上几分钟,也许再花上几分钱,就能上手实验。

在实验了 使用 Ansible 管理云资源 这个教程之后,决定就采用这个方法了。

CloudShell 的操作内容较多,单独录了一期 视频介绍

准备容器镜像

这次部署多节点,比前几次只部署 All-In-One 节点新增了 Cinder 存储服务,所以把要用到的镜像都提前构建好。

关于 Kolla 构建 Docker 镜像的过程以后再详述。

容器镜像仍然使用阿里云的容器镜像服务,保存在 华东2(上海) 地区。

值得注意的是,上一期内容中我在 华东1(杭州) 地区测试,跨地区从公网地址拉取镜像,速度也还不错。但是本次测试只在部署节点分配了公网 IP,其余节点都不会分配公网 IP,也就没法访问公网资源了。

一个解决办法是只在 华东2(上海) 地区测试,这样可以配置私网地址。这样限制较大。

另一个比较通用的办法是先在部署节点上搭建一个私有的 registry 作为中转,就和使用 davycloud-openstack-stein.iso 安装的 Deploy Node 一样。

最终采取的是把 registry 配置成 PROXY 模式,这样就不用事先把镜像 push 到 registry 中了。

# deploy.yml 中的内容
    - name: Start docker registry
      docker_container:
        name: registry
        restart_policy: always
        image: registry:2
        ports:
          - 4000:5000
        volumes:
          - registry:/var/lib/registry
        env:
          REGISTRY_PROXY_REMOTEURL: "https://registry.cn-shanghai.aliyuncs.com"

编写 Ansible 剧本

参考上面的教程完成。

为方便使用,脚本放在了 阿里云 Code 上:仓库地址

目标说明

Kolla 角色说明

Kolla 在部署 OpenStack 阶段,按职责分为 5 种角色:

  1. control,控制节点
  2. network,网络节点
  3. compute,计算节点
  4. storage,存储节点
  5. monitoring,监控节点(本次未涉及)

实际 1 个节点可以有 1 个或多个角色。比如,All-In-One 安装时,一个节点就充当了所有角色。

实际这里的角色对应的是 Ansible 中的主机分组概念。

节点上最终会安装哪些服务(也就是启动哪些容器),最终由启用的各个功能模块综合决定而成。例如,如果启用了 cinder,则 cinder-api 服务会安装在所有的 control 控制节点上,而 cinder-volume 服务会安装在所有的 storage 存储节点上。

除此之外,还需要:

  • 1 个部署节点,即安装 Kolla-Ansible 的节点
  • 1 个 docker 容器镜像的 registry

在我提供的 ISO 光盘里,系统安装时选择了 Deploy Node 就会自动安装这些。

如果是平常部署,任选一个机器充当部署节点即可,部署节点本身也可以是控制或计算或存储。

这次在阿里云上,我们单独创建一个虚机来当部署节点。

多节点角色分配

10 个节点的角色分配情况:

  • 控制节点的数量需要是奇数,设置为 3 个
  • 网络节点是安装 Neutron agent 的地方,如果启用了 haproxy / keepalived,浮动 IP 也是在这些节点上启动,本次设置为 2 个
  • 存储节点我们本次需要安装 Ceph,默认至少需要 3 个节点
  • 计算节点是最终启动虚机的地方,正常环境下应该是数量最多的,测试只需要 2 个就够了

注意: 阿里云上的虚机不支持 keepalived,所以这次无法启用 haproxy。

创建资源

本节操作在 Cloud Shell 中进行。

下载项目文件

进入云命令行后直接运行:

git clone https://code.aliyun.com/davycloud/kolla-openstack.git
cd kolla-openstack/ansible

配置资源

配置信息都在 kolla-openstack/ansible/group_vars/all 文件中,根据情况修改即可。

默认配置会创建 11 台抢占式实例,对应上面的规划:

  • master: 1 台,用来安装 kolla-ansible,部署环境
  • control: 3 台,用来部署 OpenStack 的控制节点
  • network: 2 台,用来部署 OpenStack 的网络节点
  • storage: 3 台,用来部署 OpenStack 的存储节点
  • compute: 2 台,用来部署 OpenStack 的计算节点

创建资源

执行创建资源的剧本:

cd ~/kolla-openstack/ansible
ansible-playbook create.yml

检查资源创建情况

剧本完成后可以在页面上看到资源的创建情况。

同时 ~/kolla-openstack/ansible 目录下会生成一个 hosts 文件,记录所有创建的实例的私网地址和 hostname.

注意: 我本意是将此 hosts 文件直接复制到部署节点的 /etc/hosts.

但是这里遇到了阿里云 ansible 模块的一个 bug. 其影响就是没有办法在批量创建实例时按序生成 hostname,例如:control01, control02, control03.

所以 hosts 文件中同类型主机名都是一样的,需要在后面手动修改。

配置 Kolla-Ansible 部署节点

在虚机资源创建完成后,首先需要配置的是部署节点。它是这批虚机中唯一默认创建了公有 IP 的,所以可以直接在 Cloud Shell 中操作。其它节点只有私有网络,必须通过它来操作。

动态 inventory

因为每次创建虚机的时候 IP 地址都是不确定的,不可能提前写在 Ansible 的剧本中。而每次如果手动去修改编辑主机信息,又很不方便。

所以 Ansible 中有一个动态 inventory 的功能,通过调用脚本来动态获取主机信息。

阿里云把这个动态 inventory 脚本也为我们写好了。这个脚本所在项目开源托管在 GitHub 中,下载地址 时不时的无法访问,我就一并放在了自己的这个项目中,也就是 ~/kolla-openstack/ansible/alicloud.py 这个脚本,同时运行它需要一个配置文件,就是和它同目录的 alicloud.ini

目前这个动态 Inventory 还在被官方集成的过程中,需要先手动安装依赖:

pip install ansible_alicloud_module_utils

执行 deploy.yml 剧本

这样,我们每次就无需修改代码,直接运行下面的剧本就可以了:

chmod +x ~/kolla-openstack/ansible/alicloud.py
ansible-playbook -i ~/kolla-openstack/ansible/alicloud.py deploy.yml -u root -k

执行命令后提示输入密码: Test12345

密码是在 ~/kolla-openstack/ansible/group_vars/all 中设置

该剧本会完成以下任务:

  • 安装 Ansible 和 Kolla-Ansible
  • 启动 registry 并设置镜像源
  • 生成 SSH 密钥
  • 拷贝 Kolla-Ansible 的配置文件到 /root 目录
  • 执行 kolla-genpwd

执行完此步骤后,我们仍然需要和以前一样通过 SSH 登录到部署节点,完成后续的 OpenStack 安装任务。

虽然我们可以在 Cloud Shell 中远程操作部署节点来执行部署任务,但是基于下面原因:

  1. 整个部署比较耗时,这个临时虚机并不稳定
  2. 多节点部署也是比较灵活的,有些配置不可避免需要根据情况设置,再套一层 ansible 没必要
  3. 即使针对一种场景写 ansible 剧本调试都要花时间,意味着多花租服务器的钱…

因此后面的操作将继续手动执行

执行成功后,在 /root 目录下会有以下文件:

all-in-one       # 本次用不上
bootstrap.yml    # 用来初始化其它节点的 Ansible 剧本
hosts            # 创建资源时生成的 hosts 文件
multinode        # Kolla-Ansible 多节点的 Inventroy 文件

修改 hosts 文件

编辑 hosts 文件,把其中的 hostname 按照主机的角色进行修改:

172.16.1.31  control01
172.16.1.32  control02
172.16.1.33  control03
172.16.1.34  network01
172.16.1.35  network02
...

hosts 内容复制到 /etc/hosts 中:

cat hosts >> /etc/hosts

配置 multinode

编辑 multinode 文件,把其中的 hostname 按照主机的角色分组进行填写:

[control]
control01
control02
control03

[network]
network01
network02

[compute]
compute01
compute02
compute03

[monitoring]
#monitoring01 # 暂不支持

[storage]
storage01
storage02
storage03

# 这下面的所有内容都不要动了!!

使用 Kolla-Ansible 安装多节点环境

以下的操作都是在部署节点上执行

下发 SSH 公钥

为了方便 Ansible 无密码方式连接各个节点,需要先把部署节点的 SSH 公钥下发到各个节点。

因为节点数量不多,而且密码都是固定的,所以这里用 sshpass 手动执行完成:

sshpass -p Test12345 ssh-copy-id control01
sshpass -p Test12345 ssh-copy-id control02
...
sshpass -p Test12345 ssh-copy-id storage03

使用 Ansible 命令测试各节点的连通情况:

ansible -i multinode -m ping  all

所有节点都应该能正常回应。

执行 bootstrap.yml 剧本

通过 ansible-playbook 命令执行 bootstrap.yml 剧本:

ansible-playbook -i multinode  bootstrap.yml

该剧本会初始化各个节点,为它们安装上 docker 等必需软件,详情可以查看剧本的内容。

配置 /etc/kolla/globals.yml

需要修改的配置项如下:

# Valid option is Docker repository tag
#openstack_release: ""
openstack_release: "train"

#kolla_internal_vip_address: "10.10.10.254"
kolla_internal_vip_address: "172.16.1.33"

docker_registry: "172.16.1.30:4000"
docker_namespace: "davycloud"
#docker_registry_insecure: "yes"

# 不启用 HAProxy
enable_haproxy: "no"

# 启用 ceph
enable_ceph: "yes"

# 启用 cinder
enable_cinder: "yes"

需要注意的地方:

  • kolla_internal_vip_address 必须填写部署节点真实的私网地址
  • docker_registry 必须配置为部署节点的 IP:4000
  • 不启用 haproxy,必须要先取消注释,然后修改为 "no"

配置 Ceph-OSD 磁盘

注意!警告! 下面的命令会清除所有数据,请谨慎操作!

参考文档,配置 Ceph-OSD 的存储为 Bluestore

查看存储节点的盘:

# ansible -i multinode "storage*" -a "lsblk"

假设 所有存储节点的盘都是 vdb

# ansible -i multinode "storage*" -a "parted /dev/vdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS 1 -1"

# ansible -i multinode "storage*" -a "parted /dev/vdb print"

绑定弹性网卡

在创建资源的时候为网络节点额外创建了 1 块弹性网卡,不知道何故并没有绑定到实例上。需要在阿里云的页面上把两个弹性网卡绑定到网络节点实例上。

开始部署

整体的部署流程和命令和部署单节点是一样的,唯一需要增加的地方是加一个 -i 选项,指定 inventory 文件,也就是 multinode 这个文件。

拉取镜像

kolla-ansible -i multinode pull

因为这次节点数量比较多,所以镜像拉取耗时会稍微长一点,可以耐心等待。

不同角色的节点拉取的镜像是不一样的,可以在部署节点另开一个 SSH 会话,用下面的命令查看:

ansible -i multinode all -a "docker images"

部署命令 3 连

在部署节点依次执行下面 3 个命令即可:

kolla-ansible -i multinode prechecks
kolla-ansible -i multinode deploy
kolla-ansible -i multinode post-deploy

高可用架构

正常情况下的高可用架构会在网络节点安装 HAProxy 和 Keepalived,这次演示并没有。

API

OpenStack 所有模块的 API 服务都是无状态的,所以横向扩展搭配负载均衡即可实现高可用。

由于 Kolla-Ansible 中启用负载均衡(HAProxy)的前提是要启用 Keepalived,但是阿里云又不支持,所以这次实验其实 API 的负载均衡并没有起效果,API 地址固定访问了指定的第 1 个控制节点地址。

实际上,我们可以另外启动一个外网浮动 IP,把这个浮动 IP 绑定到任意一个控制节点上,然后访问 API,都是可以正常提供服务的。

此外阿里云提供了现成的负载均衡服务,这里应该可以直接对接阿里云的负载均衡产品,不过并无必要,这次就不尝试了。

网络服务

网络节点的高可用实际情况比较复杂,这里不展开讨论了。简单展示一下网络服务:

块存储服务

MariaDB 集群

数据库采用的是 MariaDB Galera Cluster 集群方案,登录后可以查看:

RabbitMQ

RabbitMQ 的集群状态可以通过管理页面查看,不过要正常访问,需要做以下操作:

  • 在阿里云的安全组中把 15672 端口放开
  • 进入 rabbitmq 容器为 openstack 用户授权

访问 http://<控制节点外网IP>:15672 进入 RabbitMQ 管理页面:

Ceph

Ceph 本身就是分布式的,这里就不赘述了。

记得释放实例!

别忘了最重要的事情,测试完成后别忘了去释放实例,以免一直扣费。

抢占式实例是保证实例有一个小时的稳定使用,不代表一个小时之后就会回收。如果供应比较大的情况下,系统可能会长期不回收你的实例,那就要一直扣费了!

记得释放实例!

记得释放实例!

记得释放实例!

在 Cloud Shell 中一键清理本次实验创建的资源:

cd ~/kolla-openstack/ansible
ansible-playbook destroy.yml

清理资源也可以通过网页完成,最后务必检查清理结果,以避免资源没有释放导致扣费。

注意,本次实验还有云盘需要释放!!



如果本文对你有帮助,请 点赞关注分享 来一波。

原文地址:https://www.cnblogs.com/davyyy/p/12238260.html

时间: 2024-10-06 02:31:16

用Kolla在阿里云部署10节点高可用OpenStack的相关文章

阿里云部署oracle 11g数据库

某程序员在阿里云部署了一套oracle 11g,老板说他们搞了好几天,监听一直启动不来,让我给看看.登上去一瞧,原来是主机名设置的问题(把阿里云的弹性ip直接写在/etc/hosts文件,而云主机的网卡地址一般是私有地址).这个事情,我还专门发了一篇文章,地址为http://blog.51cto.com/sery/2084706 .修复完这个问题以后,觉得直接把数据库这样放在公网上很不妥当,通时又发现其它一些问题,比如磁盘空间规划不合理.混装java等.于是建议把此机作为测试环境,另购几台云主机

阿里云部署Java网站和微信开发调试心得技巧(上)

阿里云部署Java网站和微信开发调试心得技巧(上)本篇手记旨在帮助大家从0开始: 申请阿里云服务器 搭建出程序的执行环境 在服务器上发布并运行自己的web project 域名解析 微信测试号的申请与连接以获取微信用户信息全篇文章主要以如何去完成目标为主,因此会以流程的形式来展现,细节方面需要大家多多思考.其中文章的上集实现了1-4,文章的下集实现了5一.申请阿里云服务器(1)PC访问阿里云https://www.aliyun.com/,申请阿里云帐号(可以用您的支付宝帐号登录,因为支付宝帐号已

云计算之路-阿里云上:地域与可用区

昨天有位朋友问购买阿里云服务器时如何选择可用区,之前我们也没搞明白可用区是怎么回事.于是借此机会研究了一下,通过这篇博文分享一下我们的理解,不对之处欢迎指出. 地域(Region)与可用区(Availability Zone)是云服务商划分自己所拥有的物理计算资源(数据中心)的一种方法,就如城市与小区是房地产开发商划分自己房产的一种方法. 地域通常按照数据中心所在的城市进行划分,而同一地域下的多个数据中心又进一步按照可用区进行划分.如果把数据中心比作住宅,那地域就是城市,可用区就是小区.购买服务

kubeadm部署k8s1.9高可用集群--4部署master节点

部署master节点 kubernetes master 节点包含的组件: kube-apiserver kube-scheduler kube-controller-manager 本文档介绍部署一个三节点高可用 master 集群的步骤,分别命名为k8s-host1.k8s-host2.k8s-host3: k8s-host1:172.16.120.154 k8s-host2:172.16.120.155 k8s-host3:172.16.120.156 安装docker 在每台主机安装do

Corosync部署MySQL+DRBD高可用服务

介绍篇 高可用集群主要是有两个或者多个节点进行工作,ha基本组成部分包括四个部分:1.位于最底层的信息和基础架构层(Messaging Layer),主要用于节点之间传递心跳信息,故也称为心跳层.节点之间传递心跳信息可以通过广播,组播,单播等方式.2.第二层为成员关系(Membership)层,这层最重要的作用是主节点通过cluster consensus menbership service(CCM或者CCS)这种服务由第一层提供的信息,来生产一个完整的成员关系.这层主要实现承上启下的作用,承

# IT明星不是梦 #MySQL高可用集群之基于MyCat部署HaProxy实现高可用

基于MyCat部署HaProxy实现高可用 在实际项目中, Mycat 服务也需要考虑高可用性,如果 Mycat 所在服务器出现宕机,或 Mycat 服务故障,需要有备机提供服务,需要考虑 Mycat 集群. 一.高可用方案 可以使用 HAProxy+Keepalived配合两台MyCat搭起MyCat集群,实现高可用性. HAProxy实现了MyCat多节点的集群高可用和负载均衡,而 HAProxy自身的高可用则可以通过Keepalived来实现. 架构图: 于上一个博客的环境部署(MySQL

部署redis主从高可用集群

部署redis主从高可用集群本文部署的redis集群是一主一从,这两台服务器都设置了哨兵进程,另外再加一台哨兵做仲裁,建议哨兵数量为基数172.16.1.187    redis主+哨兵172.16.1.188    redis从+哨兵172.16.1.189    哨兵以上系统均为CentOS6 在187,188,189上部署redis过程如下:(1)redis使用编译安装方式,所以需要安装编译基本组件# yum -y install gcc gcc-c++ make cmake cpp gl

openstack 扩展开发最佳实践之计算节点高可用

前言:注意是扩展开发,这个词是我杜撰的,大概意思是指基于openstack的rest api做的一些开发,用于辅助相关功能,而不是直接改动openstack内的代码,怎么修改添加openstack各个组件的代码不在此文章内容内. 首先,千万,千万,千万不要用Openstack提供的SDK,原因如下. 一,SDK的相关文档并不健全. 二,版本不够统一,即兼容的问题. 所以不要使用openstack的SDK而是自己查阅openstack的API文档,通过requests库发http请求要比SDK灵活

阿里云发布边缘节点服务2.0,建立“融合、开放、联动”的边缘计算新形态

"5G时代,边缘计算将发挥更大价值."阿里云边缘计算技术负责人杨敬宇表示,边缘计算作为5G时代的一项关键技术,未来将成为不可或缺的基础设施之一.那么云的能力是如何深入每个计算场景的?用户如何享受技术红利?阿里云ENS从1.0到2.0时代又完成了怎样的升级蜕变?在刚刚落幕的阿里云峰会北京站-边缘计算专场中,杨敬宇对以上问题做了解答. 一场计算体系架构的巨大革命,需要更多行业玩家进入在5G和边缘计算到来之后,云.端二体协同向着云边端三体协同去发展,毋庸置疑,这是未来架构的新形态,杨敬宇将整