Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

基于Fuel的超融合一体机

2,394 views

Published on

介绍Fuel、定制Fuel、定制Fuel实现超融合架构的云计算产品。

Published in: Software

基于Fuel的超融合一体机

  1. 1. 基于 Fuel 的超融合一体机 周征晟 / 2015-06-27
  2. 2. Fuel 简介 定制 Fuel 海云一体机 ● 融合架构 ● 控制服务高可用 ● 计算节点高可用 ● 基于 SSD 的性能型云硬盘 议程
  3. 3. 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  支持括容  支持插件
  4. 4. Fuel 6.0 截屏
  5. 5. Fuel 架构 来源 https://wiki.openstack.org/wiki/Fuel
  6. 6. Fuel 部署流程 准备 ● 计划、插线、 BIOS 开启 KVM 、初始化 RAID 、 配置 PXE 启动 ● 安装 Fuel Master ,接入 PXE 网络 发现节点和配置环境 ● 节点开机, PXE 启动 Boostrap 系统,发现节点 ● 用户新建 OpenStack 环境,添加节点,设定网络 、存储等配置,验证网络 部署 ● 通过 Image 直拷或 PXE 安装各节点操作系统 ● 计算部署任务的依赖关系,分批串行 / 并行部署各个 角色 / 集群 ● mongo -> primary-mongo -> primary-controller -> controller -> ceph-osd -> compute
  7. 7. Fuel 主要组件和扩展点 Nailgun ● 基于 Python 开发的 Web 应用, Fuel Master 的 Web 界面,记录 OpenStack 配置,生成部署 任务、为任务排序,支持 REST API ● 扩展:新的角色、存储类型、选项,脚本和自动化 Astute ● 跟踪任务的执行,与 Cobbler 和 MCollective 交 互 MCollective Agents ● 并发执行远程任务 ● 同步时间、上传 ssh 公钥、上传 Puppet 模块 ● 执行 Shell 命令、执行 Puppet 、上传 Cirros 镜像
  8. 8. Fuel 主要组件和扩展点(续) Cobbler 、 Fuel-agent ● 磁盘分区和安装目标节点操作系统 ● 扩展:支持特殊的存储设备 Fuel-library ● 所有的 Puppet 模块 ● 扩展:发挥你的想像力 OSTF ● OpenStack 健康检查 Fuel-main ● 打包、生成 Fuel Master 镜像和 IBP 镜像 ● 扩展:更换 RPM 仓库和包
  9. 9. 海云捷迅超融合一体机 计算、存储融合;控制、计算融合 OpenStack 基础架构高可用 ● 少数控制节点宕机,不影响 OpenStack 运行 ● 整个集群断电后能自愈,无需人工干预 计算节点高可用 ● 应对计算节点断网、宕机等异常 ● 自动对计算节点进行 Fence 和 Evacuate 堆叠式架构 ● 四节点起,硬件门槛低 ● 易括容,更具弹性 界面友好,图形化操作
  10. 10. 典型部署架构
  11. 11. 控制、计算、存储融合 控制节点 ● Pacemaker 、 MySQL 、 Mongo 、 vIP 、 HAProxy 、 RabbitMQ ● *-API 、 *-Scheduler ● L3 和 DHCP 的 Agent 、 OVS Agent ● Ceph Monitor ● Fuel Master 虚拟机 计算节点: Nova Compute 、 OVS Agent 、 VM 存储节点: Ceph OSD 配置冲突:试错,修改,迭代——体力活 资源争抢:资源隔离和预留
  12. 12. 资源隔离和预留 虚拟机 CPU 、内存满载,导致控制节点集群崩溃 Cgroups ● libvirt 自动创建包含所有虚拟机的组 ● /cgroup/SUBSYSTEM/machine ● swappiness=0 ● 预留若干 CPU 线程,不允许虚拟机调度到上面 ● 调低 vCPU 的调度优先级 ● 控制虚拟机的物理内存占用 ● 留出足够物理内存给 Host 和 OpenStack 用 ● 控制虚拟机的虚拟内存占用 ● 减少换页 Nova ● 调整 reserved_host_memory_mb ● ram_allocation_ratio=1.0
  13. 13. OpenStack 服务高可用 Pacemaker vIP HAProxy 来源 https://docs.miranti s.com/fuel/fuel- master/reference- architecture.html
  14. 14. Pacemaker Cluster Resource ● 单实例资源,在节点之间漂移,相当于主备模式 Clone ● 多个实例,相当于主主或多活模式 Multi-state ● Clone 后组成主从集群 Order 和 Group ● 指定不同种资源实例之间的启动、停止依赖关系 Location ● 资源实例与节点的粘性和排斥性 Colocation ● 不同种资源实例之间的粘性 Resource Agent ● 实现具体的 start/stop/monitor/promote/notify...
  15. 15. 典型 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 起不来的节点上
  16. 16. 典型 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 现象
  17. 17. 典型 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
  18. 18. 后端存储的高可用 Ceph Monitor ● 多主集群,使用 Paxos 实现强一致 Ceph OSD ● 数据多副本复制 Cinder-volume ● 每个 Controller 都运行 Cinder-volume ● 所有 Cinder-volume 都订阅同一个消息队列 ● 谁领到消息谁干活 ● cinder service-list 只能看到一个 cinder- volume ,主机名是 rbd:volumes
  19. 19. 计算节点高可用 计算节点断网、死机、系统盘损坏 ... 形态 1 ● Controller 节点通过管理网 Ping 所有 Compute 节点 ● Controller 节点检查 nova service-list ● 对出问题的节点 Evacuate ● Too young, too simple... ● 容易引起误杀和数据损坏 形态 2 ● Pacemaker-remote ● 突破 Corosync 的集群规模限制 ● 启用多个心跳网时,处理策略单一 ● 引起用户业务不必要的中断
  20. 20. 计算节点高可用(续) 形态 3 ● Controller 节点集群检查每个计算节点 ● 管理网、存储网、租户网 ● Controller 节点之间互相检查三个网 ● 根据异常情况的组合,对计算节点执行 ● 所有网卡不通:报警、重启 ● 存储或租户网不通:报警、关机、 Evacuate ● 管理网不通:只报警 ● 所有网络不通时,无法区分 IPMI 故障还是断电 ● 缺少计算节点自杀机制 ● 在存储网上启用 fence_sanlock ● http://www.ibm.com/developerworks/cn/li nux/1404_zhouzs_sanlock/ ● 扩展性不佳、需要访问 IPMI 网
  21. 21. 计算节点高可用(续) 形态 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
  22. 22. 基于 SSD 的性能型云硬盘
  23. 23. 基于 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 都被加入默认的存储池
  24. 24. 基于 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 类新指向新的后端
  25. 25. 感谢您的批评指正

×