1- 硬件选型
- 原则:根据存储需求和企业的使用场景
- 企业选择:TCO低,高性能,高可靠
- ceph上线历程:
- 硬件选型
- 部署调优
- 性能测试
- 架构灾备设计
- 部分业务上线测试
- 运行维护(故障处理、预案演练等)
1.1- 企业场景
- 高性能:在低TCO下每秒拥有最高的IOPS。 一般使用更快的SSD硬盘,PCIe SSD, NVMe作数据存储的高性能节点。用于快存储,或者高IOPS的工作负载上。
- 通用场景:高吞吐量和单位吞吐量的低功耗。一般使用一个高带宽、物理隔离的双重网络、使用SSD和PCIe SSD作OSD的日志盘。用于快存储。也可以用于高性能的对象存储和文件存储。
- 大容量场景:数据中心每TB存储的低成本,以及机架单元物理空间的低成本。也称为经济存储、廉价存储、存档/长期存储。一般上使用插满机械硬盘的密集服务器,一个机架8-14台服务器,每台服务器24-72TB的物理硬盘空间。用于低功耗,大存储容量的对象存储和文件存储。
1.2- 依赖因素
-
CPU:
Ceph OSD运行RADOS服务,需要通过CRUSH来计算数据的存放位置,复制数据,以及维护Cluster Map的拷贝。建议每个OSD进程至少用一个CPU核。Metadata和Monitors也用计算资源。
-
内存
OSD在日常操作时不需要过多的内存(每进程500MB);但在执行恢复操作时,就需要大量的内存(每进程每TB数据需要约1GB内存)。通常内存越多越好。
-
数据存储
规划数据存储时要考虑成本和性能的权衡。进行系统操作时,同时多个后台程序对单个驱动器进行读写操作会显著降低性能,也有文件系统的限制考虑。例如:BTRFS对于生产环境来说不是很稳定,但有能力记录journal和并行的写入操作。 XFS和EXT4会更好。
-
网络
网卡能处理所有OSD硬盘总吞吐量,推荐最少安装两个千兆网卡,最好时万兆网卡。
-
硬盘
Ceph集群性能很大程度取决于存储介质的有效选择。应该在选择存储介质之前了解集群的工作负载和性能需求。
-
ceph OSD日志盘
-
建议SSD做日志盘。好处时减少访问使劲,降低写延迟,大幅提升吞吐量。
-
对每个物理SSD创建多个逻辑分区,每个逻辑分区映射到一个OSD数据盘。一般10-20G逻辑分区对应一个OSD.
-
使用更大的SSD时,为OSD增加filestore最大和最小的同步时间间隔。
-
SSD和OSD的比例: SATA/SAS SSD --- 1:4 PCIE/NVME -- 1:12或1:18
-
-
ceph OSD数据盘
- 接口: SATA和SAS. NL-SAS HDD 拥有双重SAS 12G/S端口,比但端口的SATA 6GB/S 的HDD具有更高性能。同时提供冗余,允许并行读写。
- 稳定:SAS比SATA具有更低的URE,PG修复操作更少
- OSD节点密集度:大量的小容量节点比少亮的大容量节点好。建议单个节点的容量小于总集群容量的10%
其他注意:在存储集群和底层基础设施上,企业拥有完全控制权
场景驱动
2- 性能调优
2.1- 硬件参数
- BIOS设置:超线程,关闭节能
- NUMA设置:建议关闭。或者通过cgroup将ceph-osd进程与某一个CPU core和内存进行绑定
2.2- 系统
- linux kernel
- IO调度: 使用Noop调度器替代内核默认的CFQ
- 预读:read_aheah_kb建议更大值
- 进程:pid_max设更大值
- 调整CPU频率,使其运行在更高性能下。
- 内存:
- SMP, NUMA
- SWAP: vm.swappiness=0
- 全闪存支持:增加TCmalloc的cache大小伙子jemalloc替换TCmalloc
- Cgroup:
- 对程序做CPU绑定或者使用Cgroups进行隔离时,不要跨CPU,已便更好地命中内存和缓存。
- ceph进程和其他进程会相互抢占资源,使用cgroups做好隔离措施。
- 将ceph进程预留足够多的cpu和内存资源,防止影响性能
2.3- 网络
-
巨型帧
调整MTU=9000开启巨型帧,可以极大提高性能
-
中断亲和: 2.4内核后引入将特定中断绑定到指定到CPU。慎用irqbalance服务,根据系统规划,通过手动设置中断亲和,隔离部分CPU处理网卡中断
-
硬件加速
- TOE网卡:将计算工作交给网卡上的协处理器完成
- RDMA:将应用程序在用户态直接将buffer(缓冲区)中的数据写入网卡的内存中,以网络为载体,发送到远程网卡,直接写入应用缓存中。
- DPDK:抛弃传统使用CPU中断处理数据包的方式,采用轮询方式实现数据处理过程,零拷贝存入用户态内存中,类似RDMA,避免内存拷贝和上下文切换的时间。
3- ceph层面
3.1- ceph参数:filestore
参数 | 描述 | 默认值 | 建议值 |
---|---|---|---|
filestore xattr use omap | 为xattrs使用object map,ext4 文件系统时时有,xfs或者btrfs | false | true |
filestore max sync interval | 日志到数据盘最大同步间隔 | 5 | 15 |
filestore min sync interval | 日志到数据盘最小同步间隔 | 0.1 | 10 |
filestore queue max ops | 数据盘最大接受操作数 | 500 | 25000 |
filestore queue max bytes | 数据盘一次操作最大字节数 | 100<<20 | 10485760 |
filestore queue committing max ops | 数据盘能过commit的操作数 | 500 | 5000 |
filestore queue committing max bytes | 数据盘能过commit的最大字节数 | 100<<20 | 10 485 760 000 |
filestore op threads | 并发文件系统操作数 | 2 | 32 |
3.2- ceph参数:OSD优化
参数 | 描述 | 默认值 | 建议值 |
---|---|---|---|
osd max write size | OSD 一次可写入的最大值(MB) | 90 | 512 |
osd client message size cap | 客户端允许在内存中的最大数据(bytes) | 524 288 000 | 2147 483 648 |
osd deep scrub stride | 在deep scrub时允许读取字节数(bytes) | 524288 | 131072 |
osd op threads | OSD进程操作的线程数 | 2 | 8 |
osd disk threads | OSD 密集型操作例如恢复和scrubbing时的线程 | 1 | 4 |
osd map cache size | 保留OSD map的缓存(MB) | 500 | 1024 |
osd map cache bi size | OSD 进程在内存中的OSD Map 缓存(MB) | 50 | 128 |
其他参数:
osd_enable_op_tracker=false #默认开启,可以跟踪OP执行时间
throttler_perf_counter=false #默认开启,可以观察阀值是否是瓶颈,在特定环境调整到最佳性能后,建议关闭,
3.3- PG number 调整
-
PG和PGP数量一定要根据OSD的数量进行调整,计算公式:
Total PGs = (Total_number_of_OSD *100)/max_replication_count
例如:OSD 15个,副本数:3. PG数目= 15*100/3 = 500 ~= 512
最后的结果要接近或者等于2的指数。增加一个集群的PG数都会导致集群重新平衡OSD负载,建议每个OSD对于的PG数目在50-100之间,减少资源消耗。tracker对性能影响较大
cephx_sign_messages=false #默认开启,对安全要求不高时建议关闭
filestore_fd_cache_size=4096 #默认256
filestore_fd_cache_shards=256 #默认16
3.4- 其他问题
- 持续大量写SSD到其容量95%时,既不能写也不能读
- 集群脑裂问题
- 监控与预警
- 写悬崖问题
4- 高级特性
4.1- 缓存
- cache partition manager(高速缓存分区功能) 是传统高端存储系统中的一个关键特性,可确保不同应用的服务质量。将Cache分为最多16个分区。每个分区的资源访问独立进行,不会互相串扰。根据应用的I/O特性不同,可以用多种不同方法优化每个分区的分段大小。分段尺寸可设置为4KB,8KB,16KB,64KB,256KB,512KB等等。可调的分段尺寸将大大提高缓存访问的命中率。
- 根据应用的可靠性要求不同,对cache的使用率要求不同,可将每个分区的缓存设为镜像模式、无镜像模式;每个分区对应的磁盘LUN可选择不同的条带大小,尺寸可由16KB,64KB,一致增长到128KB,最终实现分区缓存数据写入磁盘的优化操作。
- QOS的控制,一般从优先级,I/O,带宽甚至专门的缓存分区4个方面来控制。
4.2- 去重和压缩
- 实现重复数据删除以及压缩,对存储来说则是很大的挑战
- 对应数据的备份与归档,使用重复数据删除技术是非常必要的。重复数据删除的实现,有很多种方式。例如可以后台处理方式,也可以是在线处理
- 提高来压缩功能,就意味者后续访问时需要解压缩,而压缩会带来很多的资源开销。
4.3- 双活与容灾
- 双活场景下,部分主备角色,而是对称的,两边会相互影响。就很可能导致两边一损俱损,会增加运维难度,还有脑裂问题。
- 异地容灾:通过互联网TCP/IP协议,将本地的数据实时备份到异地服务器中,可以通过异地备份数据的进行远程恢复,也可以在异地进行数据回退。
- 传统存储的双活机制利用虚拟化网关的实现起来是多一层运维比较复杂。现在的趋势趋向存储阵列的双活。
5- ceph测试
- 测试对象:区分硬盘,ssd.raid,san,云硬盘等
- 测试指标:IOPS和MBPS(吞吐率)
- 测试工具:Linux下用Fio,dd, rados bench, windows iometer
- 测试参数: IO大小,寻址空间,队列深度,读写模式和随机/顺序模式
6- 补充
6.1- 存储挑选
- 底层协议
- 兼容性
- 产品定位,功能取舍
- 针对特定市场的应用存储
- 市场认可
- 稳定性>性能
6.2- ceph运维
-
多写故障记录手册
-
预案手册,部署手册,扩容手册,演练手册
-
进行常规故障演练