基于 Fuel 的超融合一体机
周征晟 / 2015-06-27

Fuel 简介
定制 Fuel
海云一体机
●
融合架构
●
控制服务高可用
●
计算节点高可用
●
基于 SSD 的性能型云硬盘
议程

Fuel 简介
OpenStack 自动化部署工具
 Apache License Version 2.0
Web UI + PXE + Puppet
操作界面友好、支持 REST API
配置较灵活、可扩展
 Host OS ： Ubuntu 、 CentOS
 Hypervisor ： KVM 、 QEMU 、 vCenter
 Neutron ： VLAN 、 GRE 、 NSX ； Nova
Network
 Cinder ： LVM 、 Ceph 、 vCenter
 Glance ： Swift 、 Ceph 、 vCenter
 灵活指定节点角色、逻辑网络、 Bond 、 VLAN
 支持括容
 支持插件

Fuel 6.0 截屏

Fuel 架构
来源 https://wiki.openstack.org/wiki/Fuel

Fuel 部署流程
准备
●
计划、插线、 BIOS 开启 KVM 、初始化 RAID 、
配置 PXE 启动
●
安装 Fuel Master ，接入 PXE 网络
发现节点和配置环境
●
节点开机， PXE 启动 Boostrap 系统，发现节点
●
用户新建 OpenStack 环境，添加节点，设定网络
、存储等配置，验证网络
部署
●
通过 Image 直拷或 PXE 安装各节点操作系统
●
计算部署任务的依赖关系，分批串行 / 并行部署各个
角色 / 集群
●
mongo -> primary-mongo ->
primary-controller -> controller ->
ceph-osd -> compute

Fuel 主要组件和扩展点
Nailgun
●
基于 Python 开发的 Web 应用， Fuel Master
的 Web 界面，记录 OpenStack 配置，生成部署
任务、为任务排序，支持 REST API
●
扩展：新的角色、存储类型、选项，脚本和自动化
Astute
●
跟踪任务的执行，与 Cobbler 和 MCollective 交
互
MCollective Agents
●
并发执行远程任务
●
同步时间、上传 ssh 公钥、上传 Puppet 模块
●
执行 Shell 命令、执行 Puppet 、上传 Cirros
镜像

Fuel 主要组件和扩展点（续）
Cobbler 、 Fuel-agent
●
磁盘分区和安装目标节点操作系统
●
扩展：支持特殊的存储设备
Fuel-library
●
所有的 Puppet 模块
●
扩展：发挥你的想像力
OSTF
●
OpenStack 健康检查
Fuel-main
●
打包、生成 Fuel Master 镜像和 IBP 镜像
●
扩展：更换 RPM 仓库和包

海云捷迅超融合一体机
计算、存储融合；控制、计算融合
OpenStack 基础架构高可用
●
少数控制节点宕机，不影响 OpenStack 运行
●
整个集群断电后能自愈，无需人工干预
计算节点高可用
●
应对计算节点断网、宕机等异常
●
自动对计算节点进行 Fence 和 Evacuate
堆叠式架构
●
四节点起，硬件门槛低
●
易括容，更具弹性
界面友好，图形化操作

典型部署架构

控制、计算、存储融合
控制节点
●
Pacemaker 、 MySQL 、 Mongo 、 vIP 、
HAProxy 、 RabbitMQ
●
*-API 、 *-Scheduler
●
L3 和 DHCP 的 Agent 、 OVS Agent
●
Ceph Monitor
●
Fuel Master 虚拟机
计算节点： Nova Compute 、 OVS Agent 、 VM
存储节点： Ceph OSD
配置冲突：试错，修改，迭代——体力活
资源争抢：资源隔离和预留

资源隔离和预留
虚拟机 CPU 、内存满载，导致控制节点集群崩溃
Cgroups
●
libvirt 自动创建包含所有虚拟机的组
●
/cgroup/SUBSYSTEM/machine
●
swappiness=0
●
预留若干 CPU 线程，不允许虚拟机调度到上面
●
调低 vCPU 的调度优先级
●
控制虚拟机的物理内存占用
●
留出足够物理内存给 Host 和 OpenStack 用
●
控制虚拟机的虚拟内存占用
●
减少换页
Nova
●
调整 reserved_host_memory_mb
●
ram_allocation_ratio=1.0

OpenStack 服务高可用
Pacemaker
vIP
HAProxy
来源
https://docs.miranti
s.com/fuel/fuel-
master/reference-
architecture.html

Pacemaker
Cluster Resource
●
单实例资源，在节点之间漂移，相当于主备模式
Clone
●
多个实例，相当于主主或多活模式
Multi-state
●
Clone 后组成主从集群
Order 和 Group
●
指定不同种资源实例之间的启动、停止依赖关系
Location
●
资源实例与节点的粘性和排斥性
Colocation
●
不同种资源实例之间的粘性
Resource Agent
●
实现具体的
start/stop/monitor/promote/notify...

典型 Cluster Resource
vip__public 、 vip__management
●
在 Controller 节点之间漂移
clone_ping_vip__public
●
loc_ping_vip__public
●
不要把外网虚 IP 飘到 Ping 不通网关的节点上
clone_p_haproxy
●
多活的 HAProxy 实例，无状态
●
vip_public-with-haproxy
●
vip_management-with-haproxy
●
不要把虚 IP 飘到 HAProxy 起不来的节点上

典型 Cluster Resource （续）
clone_p_mysql
●
Galera 集群
master_p_rabbitmq-server
●
RabbitMQ 主从集群（伪）
●
每个队列的都有自己的 Master ，实际为多活集群
force_load 加速 RabbitMQ 集群恢复
●
http://www.mail-archive.com/openstack-
dev@lists.openstack.org/msg51625.html
处理悬空 Consumer 现象

典型 Cluster Resource （续）
p_neutron-dhcp-agent
p_neutron-l3-agent [ 可选 clone 模式 ]
●
q-agent-cleanup 脚本负责迁移 qdhcp 和
qrouter
●
l3-keepaway-dhcp
●
L3 和 DHCP Agent 不要飘到同一个节点上
●
loc_ping_p_neutron-l3-agent
●
L3 Agent 不要飘到 Ping 不通网关的节点上
clone_p_neutron-openvswitch-agent
●
DHCP 和 L3 Agent 与 OVS Agent 之间设置了
Colocation 和 Order

后端存储的高可用
Ceph Monitor
●
多主集群，使用 Paxos 实现强一致
Ceph OSD
●
数据多副本复制
Cinder-volume
●
每个 Controller 都运行 Cinder-volume
●
所有 Cinder-volume 都订阅同一个消息队列
●
谁领到消息谁干活
●
cinder service-list 只能看到一个 cinder-
volume ，主机名是 rbd:volumes

计算节点高可用
计算节点断网、死机、系统盘损坏 ...
形态 1
●
Controller 节点通过管理网 Ping 所有 Compute
节点
●
Controller 节点检查 nova service-list
●
对出问题的节点 Evacuate
●
Too young, too simple...
●
容易引起误杀和数据损坏
形态 2
●
Pacemaker-remote
●
突破 Corosync 的集群规模限制
●
启用多个心跳网时，处理策略单一
●
引起用户业务不必要的中断

计算节点高可用（续）
形态 3
●
Controller 节点集群检查每个计算节点
●
管理网、存储网、租户网
●
Controller 节点之间互相检查三个网
●
根据异常情况的组合，对计算节点执行
●
所有网卡不通：报警、重启
●
存储或租户网不通：报警、关机、 Evacuate
●
管理网不通：只报警
●
所有网络不通时，无法区分 IPMI 故障还是断电
●
缺少计算节点自杀机制
●
在存储网上启用 fence_sanlock
●
http://www.ibm.com/developerworks/cn/li
nux/1404_zhouzs_sanlock/
●
扩展性不佳、需要访问 IPMI 网

计算节点高可用（续）
形态 4 ：分布式健康检查
●
管理、存储、租户网上分别部署 Gossip Pool
●
计算节点之间同时通过三个 Gossip Pool 互相检查
连通性
●
每个 Gossip Pool 里发现的问题节点上报到
Controller
●
Controller 追踪计算节点在三个 Pool 里的情况，
决定是否需要关机和 Evacuate
●
Fence
●
通过存储网 Gossip 发布关机指令
●
节点发现存储网 Gossip 不通时自杀
●
可能的实现方式：基于 serf 或 consul
●
https://www.serfdom.io/docs/internals/si
mulator.html

基于 SSD 的性能型云硬盘

基于 SSD 的性能型云硬盘（续）
使用 SSD 作为 Ceph Journal 盘
●
OSD 平分 SSD Journal 盘空间
●
每个 OSD 的 Journal 最多使用 10GB
●
SSD 盘比较多时，空间被浪费
自动化部署 OSD 节点
●
安装系统时：将指定的磁盘上划出指定的空间，分区
类型的 GUID 设为 OSD 专门的类型
●
部署 OpenStack 时：扫描所有的分区，过滤出
Ceph OSD 类型的分区，格式化成 XFS ，启动
OSD 进程，加入 Ceph 集群
●
系统重启时， ceph-disk activate-all
●
所有 OSD 都被加入默认的存储池

基于 SSD 的性能型云硬盘（续）
部署基于 SSD 的 Pool = 自动调整 Crushmap
●
安装系统时：将指定的磁盘上划出指定的空间，分区
类型的 GUID 设为 SSD OSD 专门的类型
●
部署 Ceph Monitor 时
●
创建一个新的名为 ssd 的根 bucket 及对应 rule
●
创建一个新的名为 volumes_ssd 的 pool ，并关
联到刚才的 rule
●
部署 OSD 节点时
●
创建名为 ssd_host-X 的 bucket ，并加入 ssd
根 bucket
●
扫描所有的分区，凡符合 SSD OSD 类型的，其
OSD 移动到 root=ssd host=ssd_host-X
●
部署 Cinder 时
●
配置新后端指向 volumes_ssd
●
配置新的 Volume 类新指向新的后端

感谢您的批评指正