从传统运维到云运维演进历程之软件定义存储(三)下

上回书讲到了运维小哥的调优方法论(上),对于Ceph运维人员来说最头痛的莫过于两件事:一、Ceph调优;二、Ceph运维。调优是件非常头疼的事情,下面来看看运维小哥是如何调优的。

关卡二:部署调优关之调优(二)

难度:五颗星

优化方法论

通过对网上公开资料的分析进行总结,对Ceph的优化离不开以下几点:

硬件层面

  • 硬件规划
  • SSD选择
  • BIOS设置

操作系统层面

  • Linux Kernel
  • 内存
  • Cgroup

网络层面

  • 巨型帧
  • 中断亲和
  • 硬件加速

Ceph层面

  • Ceph Configurations
  • PG Number调整

网络层面优化

这里把网络部分的优化独立出来写,主要原因是网络通信在Ceph的工作流程中被大量使用到。Ceph距今已经有10余年的历史,时至今日,Ceph各个组件间的通信依然使用10年前的设计:基于多线程模型的网络通信,每个终端包含读和写两个线程, 负责消息的接受和发送。在默认三副本的情况下,客户端的每次写请求需要至少6次网络通信。作为Ceph的基石,接下来我们将讨论网络优化在Ceph中的应用。

任何时候通过一个套接字(socket)来读写数据时,都会使用一个系统调用(system call),这个调用将触发内核上下文切换(Context Switch),下面描述了一个典型的系统调用流程:

1)Ceph进程调用send()函数发送消息。

2)触发0x80中断,由用户态切换至内核态。

3)内核调用system_call()函数,进行参数检查,根据系统调用好获得对应的内核函数。

4)执行内核函数,发送数据报文。

5)内核函数执行完毕,切换回内核态。

6)Socket()调用完成。

整个数据发送/接受需要触发两次上下文切换,以及若干次内存拷贝,这些操作会消耗大量的时间,我们优化的思路就是减少这些时间损耗。在处理网络IO时需要CPU消耗大量的计算能力,因此我们希望CPU尽可能少的处理这些琐碎的IO任务,有足够的处理能力运行Ceph集群,我们主要讨论使用巨型帧、中断亲和等技术加速网络IO。

1.巨型帧

以太网诞生以来,其帧结构一直就没有发生过大的改变。默认情况下,以太网的MTU(Maximum Transmission Unit)是1500字节。默认情况下以太网帧是1522 字节,包含1500字节的负载、14字节的以太网头部、4字节的CRC、4字节的VLAN Tag,超过该大小的数据包会在被拆封成更多数据包,巨型帧是长度大于1522字节的以太网帧,通过调整MTU(通常我们会调整到9000)来减少网络中数据包的个数,减轻网络设备处理包头的额外开销。设置MTU需要本地设备和对端设备同时开启,开启巨型帧后,可以极大地提高性能。

2.中断亲和

前面提到了当我们要进行网络IO时,会触发系统中断。默认情况下,所有的网卡中断都交由CPU0处理,当大量网络IO出现时,处理大量网络IO中断会导致CPU0长时间处于满负载状态,以致无法处理更多IO导致网络丢包等并发问题,产生系统瓶颈。Linux 2.4内核之后引入了将特定中断绑定到指定的CPU的技术,称为中断亲和(SMP IRQ affinity)。

Linux中所有的中断情况在文件/proc/interrupt中记录:

中断记录情况

 

3.硬件加速 

在大多数情况下,CPU需要负责服务器中几乎所有的数据处理任务,事实上CPU并不如我们想象中的那样强大,在大量的数据处理中往往显得力不从心,于是便有了硬件加速技术。硬件加速能够将计算量比较大的工作分配给专门的硬件设备处理,比如常见的使用视频硬件解码加速等,在Ceph中,我们主要使用网卡完成对于网络数据处理的加速。

TCP协议处理网络流量,需要占用大量CPU和内存资源,为了节省服务器资源的消耗,众多厂商开始在网卡中内置协处理器,将计算任务移交给协处理器完成,即TCP卸载引擎(TCP offload Engine,TOE)。TOE目前主要能协助完成以下工作:

(1)协议处理

普通网卡处理网络IO的很大一部分压力都来自于对TCP/IP协议的处理,例如对IP数据包的校验处理、对TCP数据流的可靠性和一致性处理。TOE网卡可以将这些计算工作交给网卡上的协处理器完成。

(2)中断处理

上面讲到,在通用网络IO的处理方式上,普通网卡每个数据包都要触发一次中断,TOE网卡则让每个应用程序完成一次完整的数据处理进程后才出发一次中断,显著减轻服务对中断的响应负担。

(3)减少内存拷贝

普通网卡先将接收到的数据在服务器的缓冲区中复制一份,经系统处理后分配给其中一个TCP连接,然后,系统再将这些数据与使用它的应用程序相关联,并将这些数据由系统缓冲区复制到应用程序的缓冲区。TOE网卡在接收数据时,在网卡内进行协议处理,因此,它不必将数据复制到服务器缓冲区,而是直接复制到应用程序的缓冲区,这种数据传输方式减少了部分内存拷贝的消耗。

在Linux中,可以使用ethtool查看网卡状态或设置网卡参数。

使用ethtool查看网卡状态

使用命令ethtool -K em1 tso on打开tcp-segmentation-offload,查看tcp-segmentation-offload已经打开(on)。

使用ethtool打开tcp-segmentation-offload

Ceph层面优化

以上部分主要围绕着硬件、操作系统、网络进行优化,下面围绕Ceph的本身参数进行调优,Ceph将很多运行参数作为配置项保存在配置文件中,Ceph为我们提供了相当详细的配置参数供用户在不同场景下的调整和优化。

1.Ceph Configurations

[global]全局参数以及参数描述,可以通过linux命令sysctl来设定max open files的值fs.file-max。

osd部分filestore参数,调整omap的原因主要是EXT4文件系统默认仅有4K。

filestore queue相关的参数对于性能影响很小,参数调整不会对性能优化有本质上提升

[osd] -journal相关参数,Ceph OSD进程在往数据盘上刷数据的过程中,是停止写操作的。

[osd] – osd config tuning相关参数,增加osd op threads和disk threads会带来额外的CPU开销。


[osd] – recovery tuning相关参数。


[osd] – client tuning相关参数


2.PG Number 
调整

PG和PGP数量一定要根据OSD的数量进行调整,计算公式如下,但是最后算出的结果一定要接近或者等于一个2的指数。

Total PGs = (Total_number_of_OSD * 100) / max_replication_count

例如15个OSD,副本数为3的情况下,根据公式计算的结果应该为500,最接近512,所以需要设定该pool(volumes)的pg_num和pgp_num都为512。

ceph osd pool set volumes pg_num 512

ceph osd pool set volumes pgp_num 512

下面的Ceph参数配置是我们在使用过程中逐渐积累的一个优化后的配置,可以基于下面的配置对Ceph集群进行参数调优。

[global]

fsid = 059f27e8-a23f-4587-9033-3e3679d03b31

mon_host = 10.10.20.102, 10.10.20.101, 10.10.20.100

auth cluster required = cephx

auth service required = cephx

auth client required = cephx

osd pool default size = 3

osd pool default min size = 1

public network = 10.10.20.0/24

cluster network = 10.10.20.0/24

max open files = 131072

[mon]

mon data = /var/lib/ceph/mon/ceph-$id

[osd]

osd data = /var/lib/ceph/osd/ceph-$id

osd journal size = 20000

osd mkfs type = xfs

osd mkfs options xfs = -f

filestore xattr use omap = true

filestore min sync interval = 10

filestore max sync interval = 15

filestore queue max ops = 25000

filestore queue max bytes = 10485760

filestore queue committing max ops = 5000

filestore queue committing max bytes = 10485760000

journal max write bytes = 1073714824

journal max write entries = 10000

journal queue max ops = 50000

journal queue max bytes = 10485760000

osd max write size = 512

osd client message size cap = 2147483648

osd deep scrub stride = 131072

osd op threads = 8

osd disk threads = 4

osd map cache size = 1024

osd map cache bl size = 128

osd mount options xfs = “rw,noexec,nodev,noatime,nodiratime,nobarrier”

osd recovery op priority = 4

osd recovery max active = 10

osd max backfills = 4

[client]

rbd cache = true

rbd cache size = 268435456

rbd cache max dirty = 134217728

rbd cache max dirty age = 5

因为优化部分涉及内容较多,所以分为两篇文章来讲述,至此Ceph部署调优关卡讲述完毕,希望本关卡能够给予Ceph新手参考,请读者见仁见智,预知后事如何,请期待《性能测试关卡》。

时间: 2024-10-28 22:12:55

从传统运维到云运维演进历程之软件定义存储(三)下的相关文章

从传统运维到云运维演进历程之软件定义存储(一)

运维是企业业务系统从规划.设计.实施.交付到运维的最后一个步骤,也是重要的步骤.运维从横向.纵向分可以分为多个维度和层次,本文试图抛开这纷繁复杂的概念,讲述一个传统的企业级运维人员转型到云运维人员,尤其是软件定义存储的运维之间经历的沟沟坎坎. 在传统企业中,业务运维工程师(Operations) 主要负责监控.维护并确保整个业务系统的可靠性,同时提出对系统架构的优化要求.提升部署效率.优化资源利用率并提高整体的ROI. 随着云计算.大数据以及新兴的区块链等技术体系的迅猛发展,数据中心的扩容建设进

从传统运维到云运维演进历程之软件定义存储(六)完结

回到最初的Ceph运维工程师的问题,本系列讲述的是传统运维向新一代云运维转型之软件定义存储部分的转型,运维是企业业务系统从规划.设计.实施.交付到运维的最后一个步骤,也是重要的步骤.运维小哥最初的梦想搭建一个Ceph存储集群,对接云服务,底层存储实现高可用的数据访问架构.其中运维小哥经历了硬件选型.部署.调优.测试.高可用架构设计等的一系列转型的关卡学习,终于就要到最后的应用上线了.但是往往在生产环境中除了无单点.高可用的架构设计之外还需要平时做一些预案演练,比如:服务器断电.拔磁盘等问题,避免

从传统运维到云运维演进历程之软件定义存储(二)

上回书说到一般企业使用Ceph会经历几个关卡:硬件选型 -- 部署调优-- 性能测试  架构灾备设计 -- 部分业务上线测试 -- 运行维护(故障处理.预案演练等). 今天来重点讲下部署调优关卡.许多Ceph新手在测试环节以及预生产的时候会对Ceph集群的部署以及调优产生困扰,A公司运维小哥也遇到了部署和调优问题.下面来看看A公司运维小哥是如何解决这个问题的. 关卡二:部署调优关(部署) 难度:三颗星 上篇文章开头我也说到了,部署Ceph是新手的噩梦,对于传统运维来说部署一套Ceph是很难的事情

从传统运维到云运维演进历程之软件定义存储(四)

前面系列已经讲完了硬件选型.部署.调优,在上线之前呢需要进行性能存储测试,本章主要讲述下测试Ceph的几种常用工具,以及测试方法.   关卡四:性能测试关卡 难度:四颗星 说起存储性能永远是第一重要的问题.关于性能有以下几个指标:带宽(Bandwidth).IOPS.顺序(Sequential)读写.随机(Random)读写.延迟(latency).持续吞吐(Sustained Throughput).突发处理能力(Burst I/O)等等. 1.iops&latency    这是两个衡量存储

从传统运维到云运维演进历程之软件定义存储(五)上

数据资料是整个系统运作的核心,而人为或非人为引起的数据丢失将对的企业造成无法估量的影响.因此系统管理员都会考虑通过数据备份手段对业务数据进行保护.但在现在云数据中心的兴起带来的是海量数据被集中起来.相较于传统备份行业常见的小容量(小于500GB)RTO.RPO敏感型场景,在云数据中心带来的挑战下完全无法作到有效保护. 关卡五:PB级数据中心灾备设计关卡 上 画难度:四颗星 传统的备份方式通常面向应用来做保护,依靠代理来调用应用端的接口.数据一致性能得到完全的保证.但传统备份由于要建立索引表,面对

如何打造一个高逼格的云运维平台?

导读 在标准化实施完以后,由于数目的增加,或者是一些运维场景的增多,我们会逐步的进行一些工具化和自动化,这个阶段我们的运维的效率得到提升.但是众多的工具以及自动化脚本,会让我们的管理过程中比较困难,随着人员的变动或者是一些工具维护过程中的差错,我们的自动化运维工具的受众群体不太稳定. 前言 大家做运维普遍经历这样的过程: 首先我们会把操作做一个标准化,这个阶段是运维质量的提升的阶段. 在标准化实施完以后,由于数目的增加,或者是一些运维场景的增多,我们会逐步的进行一些工具化和自动化,这个阶段我们的

从十年运维看“云”维趋势

又到岁末,就这样默默地在运维行业里已有十年余.总是想找个机会总过去展望未来,并给刚上路或是在路上的运维朋友交流一些观点.虽然现在比前几年轻松,但是惰性也随之有增,所以从未实际提笔.但是因为脑子里一直记着这事儿,所以其实一直在脑子中整理文字和框架,结合工作实际,很多观点也经受了验证,并非侃侃而谈.终于因为圣诞假期开始,趁着回国途中有集中的时间写出来,其实也是为了在万米高空消磨消磨时间. 笔者目前在北美某著名游戏公司从事运维工作,十年间发表过不少文章,著有<Linux系统命令及Shell脚本实践指南

开源还是商用?十大云运维监控工具横评

随着云计算和互联网的高速发展,大量应用需要横跨不同网络终端,并广泛接入第三方服务(如支付.登录.导航等),IT系统架构越来越复杂.快速迭代的产品需求和良好的用户体验,需要IT运维管理者时刻保障核心业务稳定可用,而企业运维中的痛点和难点也急需解决. 1.面向业务的运维,不但关心单点IT资源的运行状态,更关心整个业务系统的健康状态 2.如果企业使用了大量的API和模块化应用,那么关注每个接口的性能变化情况和指标 3.对于运维主管及企业管理层来说,特别需要上墙的监控大屏 4.运维需要每周.每月查看报告

传统运维与互联网运维差异

概述 近一年,关于传统运维与互联网运维的探讨越来越多,在运维体系快速变革地环境下,运维未来的走向,便成为运维行业的关注点. 那么: 到底什么是传统运维体系?什么是互联网运维体系?他们的特点,异同在哪?从哪里来到哪里去? 本文将从以下角度探讨两大运维体系. 商业封闭式系统架构 vs 开源系统架构辨析 传统运维 vs 互联网运维辨析 去IOE运动辨析 运维发展趋势辨析 1.商业封闭式系统架构 vs 开源系统架构辨析 每个单位组织的IT环境,不论大小复杂度,总会有个系统架构层次.有了这个架构体系,那所