Ceph中国社区9.19 Some Ceph Story-朱荣泽03

Copyright © 2015 Mirantis, Inc. All rights reservedwww.mirantis.com

Ceph 一千零一夜

@朱荣泽 [email protected]

2015-09-19

Copyright © 2015 Mirantis, Inc. All rights reserved Page 2

个人简介:

目前是Mirantis云存储架构师，之前在UnitedStack和SINA。2012年初接触Ceph、OpenStack。

做过Ceph的调研、选型、与OpenStack整合、自动化部署、架构设计、优化、监控与运维、故障排查、扩容等工作，同时管理过十几个Ceph生产集群。


Agenda

● Ceph基本介绍

● Ceph的发展

● Ceph的优缺点

● Ceph架构设计

○ 云硬盘架构设计

○ 集群性能规划

● Ceph的产品化

○ 自动化部署

○ 优化

○ 监控

○ 诊断

● Ceph的运维

○ 扩容

○ 故障排查

○ 日常问题

● Ceph总结

● 提问与回答


Ceph的基本介绍


Ceph基本介绍

Ceph = 提供Block、File、Object接口的统一存储系统


Ceph基本介绍


Ceph基本介绍


Ceph基本介绍


Ceph的发展


Ceph的发展

● 2004年06月：第一个commit 48cdbbf011f840ba4ce2f925f7aff2dcb1bcd6c4● 2006年11月：CRUSH 论文● 2008年01月: v0.1版本● 2010年12月：Qemu Block Device Driver for RBD● 2012年02月：v0.42版本● 2012年05月：Inktank成立● 2012年12月：支持RBD Clone (format v2)● 2013年03月：v0.58版本，Ceph Monitor的架构被重写● 2013年05月：v0.61版本● 2014年04月：Inktank被RedHat收购● 2014年05月：v0.80版本


Ceph的发展

● AWS● OpenStack● Key Features

○ Scalability○ Cloning


Ceph的优缺点


Ceph的优缺点

特性优点缺点避免

开源免费不是产品

多功能统一复杂，性能不高

扩展性通过堆硬件，线性提高容量和性能

故障域扩大

可靠性高可用，数据安全牺牲性能、容量


Ceph的架构设计


云硬盘架构设计

• 架构设计原则

• 物理架构设计

• 硬件选型


架构设计原则

原则

扩展性• Scale-Out，无缝扩容，减少前期公有云/托管云的硬件投入• 方便运维

可用性• 三副本分布在三个机架上，提高可用性。• 提高osd-domain中osd的个数，加快recovery速度。• 可停机运维。

可靠性 • 通过设置replica-domain和osd-domain上，减少故障域。

高性能 • 性能线性扩展。


物理架构设计


物理架构设计

底层存储基础架构(统一存储)物理和逻辑网络拓扑


硬件选型

• 存储网络10Gb• Public network 和 Cluster network• 企业级SSD硬盘 & 消费级SSD硬盘• SSD和SATA的配比• RAID卡设置• OSD个数与网卡的关系


集群规模规划 -> 容量规划

假设在三副本情况下，使用率75%的情

况下，我们需要200TB用户可用空间，假设每个硬盘大小是

4TB，我们需要多少块硬盘

(200/0.75)*3/4 = 200

每个存储服务器上可以插多少块硬盘？

假设在三副本情况下，使用率 75%的情况下，我们需要200TB用户可用空间，假设每

个硬盘大小是4TB，我们需要多少块硬盘？

(200/0.75)*3/4 = 200



集群规模规划 -> 性能规划

假设在三副本情况下，使用率75%的情

况下，我们需要200TB用户可用空间，假设每个硬盘大小是

4TB，我们需要多少块硬盘

(200/0.75)*3/4 = 200


每个HDD的IOPS和吞吐率？

每个SSD的IOPS和吞吐率？

在Ceph三个副本的情况下，每个 HDD的性能贡献？每个SSD的性能贡献？

假设我们要跑N个虚拟机，每个虚拟机需要IOPS是M，我们需要多少块HDD？多少块

SSD？


Ceph的产品化


自动化部署

• 软件打包

• 自动化部署工具

• 硬盘初始化

• OSD部署

• MON部署

• 测试


软件打包

• 假如需要自己维护Ceph版本，需要自己打包


自动化部署工具

• ceph-deploy• puppet• chef• ansible


硬盘初始化

• 单SSD: 如何分区• 单HDD: 如何分区• SSD Journal + HDD: SSD与HDD的配比关系


OSD部署

• 自动对硬盘分区• 自动格式化XFS，格式化参数设置• 自动挂载，挂载参数的设置• 使用WWN号作为唯一标识• 用FS UUID注册OSD ID• 设置osd_crush_update_on_start = False，防止遇到BUG，导致数据迁移


MON部署

•


测试

https://github.com/Mirantis/disk_perf_test_tool


优化

• 性能优化

• 可用性调优

• 持久性调优(CRUSH设计)


性能调优

• 硬件调优• 操作系统调优• 参数调优• 代码调优


性能调优

• 检查负载类型• 检查ceph.conf• 检查网络• 检查硬盘• 检查CPU• 检查Cache Tier参数• 检查Perf Dump

CheckList


性能调优


性能调优

• 直接阻塞• 相关性阻塞• 延迟

• 网络msg cap• journal• WBThrottle• Cache• CPU

• IOPS• queue• op threads• 网络msg


可用性调优

• 设置recovery参数• ceph osd set noout• ceph osd set nodeep-scrub


持久性调优

• CRUSHMAP的设计• 持久性算法• 提高持久性• 在可用性和持久性中做权衡

• CRUSHMAP初始化• 物理拓扑CRUSHMAP• 逻辑拓扑CRUSHMAP• 计算好osd weight，保证bucket的weight一样，保证不会变化• 手动触发数据迁移，可控


Ceph的运维


监控

• 基本指标

• 详细指标

• 报警


扩容

• Scale-out & Scale-up

• 扩容的方式

• 增加OSD

• 增加存储服务器节点

• 增加failure-domain

• 原则

• 计划

• 可用性

• 可控性

• recovery速度

• 流程

• 增加monitor节点


故障排查

• 问题类型• SSD GC• 网络故障• 网络配置错误• Ceph BUG• XFS BUG• 硬盘故障• XFS故障• 硬盘性能下降• PG inconsistent• Ceph Recovery缓慢• Ceph Recovery占满网络• Ceph软件包版本不一致• NTP时间漂移• 网络包流量过大影响OSD性能• Monitor无法正确协商• Cgroup设置过小影响OSD性能• Pool被写满

•

• 故障历史

• 呵呵


日常运维

• 停机维护• 升级OSD• 升级MON• 重启所有OSD• 硬盘换盘• 硬盘下线• monitor迁移


Ceph总结


Ceph总结

• 存储性能靠硬件堆出来，但是要合理的规划• 能够用SSD就不要用SATA/SAS，SSD提供的不仅是性能• 敬畏运维工作，保证数据的安全和可用性• 尽量购买产品和服务，开源可以免费使用，但是技术和服务不是免费，降低时间成本和风险


问题解答

Software

Ceph中国社区9.19 Some Ceph Story-朱荣泽03