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