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

前面系列已经讲完了硬件选型、部署、调优,在上线之前呢需要进行性能存储测试,本章主要讲述下测试Ceph的几种常用工具,以及测试方法。

 

关卡四:性能测试关卡

难度:四颗星

说起存储性能永远是第一重要的问题。关于性能有以下几个指标:带宽(Bandwidth)、IOPS、顺序(Sequential)读写、随机(Random)读写、延迟(latency)、持续吞吐(Sustained Throughput)、突发处理能力(Burst I/O)等等。

1、iops&latency   

这是两个衡量存储性能最基本的概念。IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数),是衡量存储性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量,一般以每秒处理的I/O请求数量为单位,I/O请求通常为读或写数据操作请求。另一个重要的性能指标是延迟(等待时间),延迟度量系统运行状况及系统资源可用性,延迟取决于队列。存储系统类似于杂货店收银台排队,每个组件都有确定的性能最大值,系统趋近最大性能会增加延迟延迟小于10毫秒的目标并非偶然,很多应用系统甚至对延迟更敏感。

2、影响性能的因素

传统存储的封闭特性带来的优势是从存储操作系统软件到专用硬件的深度优化,而软件定义存储、Server SAN的目的是软件和硬件的解耦合,它们带来了灵活性,免除了硬件厂商锁定,但很多时候却不能充分发挥硬件的潜力,给客户造成投资浪费。在分布式Server SAN的环境下,用户不能直接的把部件的性能做简单的加法,就得到整个存储的性能,其原因来自于集群和网络带来的复杂性,也来自于通用操作系统内核(如Linux)对NVMe SSD和万兆以上网络的处理机制不够优化,导致超强的硬件部件性能无法“吐出去”,或者“吐出去”对CPU等核心部件的资源消耗太大,要求过高。同时,由于网络交互在分布式存储中的引入,给存储的整体“时延(latency)”特性带来了挑战,很多分布式存储系统因没有恒定的低时延无法满足高实时性数据库等应用的需求。

利用FIO测试Ceph

硬盘的性能是可以估算出来的,但是怎么才能让应用获得这些性能呢?对于测试工具来说,就是如何得到IOPS、吞吐量和延迟。

FIO简介:

fio 是一个 I/O 工具用来对硬件进行压力测试和验证,支持13种不同的I/O引擎,包括:sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等, I/O priorities (for newer Linux kernels), rate I/O, forked or threaded jobs, 等等。它可以对块设备以及文件系统进行性能测试,通过接收一份简单的文本文件来理解工作描述来,结果会显示各种I/O性能信息。该工具在很多地方广泛使用,用来测试性能基准,稳定性验证。它支持Linux,FreeBSD,NetBSD,OS X,OpenSolaris,AIX和Windows。

FIO安装:

1、确保libaio引擎已安装,yum install libaio-devel

2、https://pkgs.org/download/fio  下载fio工具RPM包

3、安装 rpm -ivh fio-2.2.8-2.el7.x86_64.rpm

常用参数说明:

filename: 指定文件(设备)的名称。可以通过冒号分割同时指定多个文件,如filename=/dev/sda:/dev/sdb

directory: 设置filename的路径前缀。在后面的基准测试中,采用这种方式来指定设备。

name: 指定job的名字,在命令行中表示新启动一个job。

direct: bool类型,如果设置成true (1),表示不使用io buffer。

ioengine: I/O引擎,现在fio支持19种ioengine。默认值是sync同步阻塞I/O,libaio是Linux的native异步I/O。关于同步异步,阻塞和非阻塞模型。可以参考文章“使用异步 I/O大大提高应用程序的性能”。http://www.ibm.com/developerworks/cn/linux/l-async/

iodepth: 如果ioengine采用异步方式,该参数表示一批提交保持的io单元数。该参数可参考文章“Fio压测工具和io队列深度理解和误区”。http://blog.yufeng.info/archives/2104

rw: I/O模式,随机读写,顺序读写等等。

bs: I/O block大小,默认是4k。

size: 指定job处理的文件的大小。

numjobs: 指定job的克隆数(线程)。

time_based: 如果在runtime指定的时间还没到时文件就被读写完成,将继续重复知道runtime时间结束。

runtime: 指定在多少秒后停止进程。如果未指定该参数,fio将执行至指定的文件读写完全完成。

group_reporting: 当同时指定了numjobs了时,输出结果按组显示。

测试方式:

有两种测试方式1.配置文件、2.命令行,这里是讲述下命令行操作。

# fio -filename=/dev/sdx -iodepth=1 -numjobs=1 -thread -rw=randwrite -bs=4k -ioengine=libaio -group_reporting -name=mytest -randrepeat=0 -time_based -runtime=300 -direct=1

上面这种是基于挂载块设备进行测试的,下面讲述下如何使用fio直接测试RBD块。

# fio -direct=1 -iodepth=12 -rw=rw – ioengine=rbd -bs=4k -group_reporting -name=test -numjobs=4 -runtime=600 -clientname=admin -pool=pool-f61ba147fd61441ab272ae96b09e4ee0 -rbdname=volume-fd8f04986a33465d9908f3f97500961b

注意:

其中ioengine更换为rbdI/O引擎,需要在pool参数中指定卷设备所在的存储池ID,rbdname参数需要指定rbd设备的ID

以上命令均为举例,现实测试中可以根据实际情况调整iodepth、numjobs、bs大小参数来增加I/O压力,以获得更加性能。

测试指标:

顺序读写(吞吐量,常用单位为MB/s):文件在硬盘上存储位置是连续的。

适用场景:大文件拷贝(比如视频音乐)。速度即使很高,对数据库性能也没有参考价值。

4K随机读写(IOPS,常用单位为次):在硬盘上随机位置读写数据,每次4KB。

适用场景:操作系统运行、软件运行、数据库。

测试结果关注点:

对于一些新手来说不知道FIO测试出来之后应该关注哪些结果是有价值的,最基本的关注是带宽(bw)和iops,其次关注响应时间(clat)和磁盘利用率(util)。详细介绍可参考荣泽的博客。http://way4ever.com/?p=465

利用Cosbench来测试Ceph

Cosbench是Intel的开源云存储性能测试软件,Cosbench目前已经广泛使用与云存储测试,并作为云存储的基准测试工具使用,Cosbench可在windows和linux两种系统中运行,而为了更好的发挥硬件和系统的能力,建议在使用Cosbench进行测试时,选择linux系统。

Cosbench是一个分布式的基准测试工具,测试云对象存储系统,目前为止它支持一些云对象存储系统的测试,Cosbench也允许用户创建额外的存储系统适配器。

1.cosbench安装:

安装Java SDK

# yum install  java-1.7.0-openjdk

# yum install -y nc java-1.7.0-openjdk

安装curl软件

# yum install curl

#yum install nmap-ncat

安装COSBench软件

https://github.com/intel-cloud/cosbench/releases下载安装文件

# cd 0.4.2.c3

给予权限执行权限

# chmod a+x *.sh

启动COSbench

# ./start-all.sh

出现如下证明安装成功

Successfully started cosbench controller!

Listening on port 0.0.0.0/0.0.0.0:19089 …

Persistence bundle starting…

Persistence bundle started.

———————————————-

!!! Service will listen on web port: 19088 !!!

———————————————-

2.使用Cosbench进行测试

注意:该测试说明基于ceph对象存储测试

编辑wokload 文件

可以参照0.4.2.c3/conf目录下的s3-config-sample.xml配置文件,在这里注意将之前在CEPH中分配的RGW用户的AK,SK,已经RGW启用的cvitweb域名端口设置正确:<storage type=”s3″ config=”accesskey=HX1XZCKWT6RDC8GA96AI;secretkey=j0RR17r0yx5jsszstHCTl8bY1usJ4fs1mUJNw8BC;proxyhost=;proxyport=;endpoint=http://192.168.182.128:80” />提交workload执行测试

通过以下链接访问COSBench – Controller Web Console

http://:19088/controller/index.html

界面显示

  1. 点击submit new workloads 提交workloads文件;
  2. 选择文件后,点击提交;
  3. 提交成功后,点击view details ,查看详细信息。

workloads xml文件示例:2个节点的3个网关write.xml

说明:

1、该文件中可以更改<work>:
name:名字  不能重复,重复会产生重复数据
works:进程
totalOps:对象总个数
cprefix:桶名的前缀
oprefix:对象名前缀
containers:桶的个数
objects:每个work写入的对象个数
sizes:写入对象的大小
endpoint:存储网关

2、若read,则需要改operation里的type为read,即可;

3、多个work,size大小同时写的话,压力会大。

注意:1. xml配置文件中网关地址格式为http://<网关IP>:<端口号>
2. 小于64K的文件会往索引池中写
3. 在Cosbench 上换算是按照1000算的。例如:若你写4096KB就是4096X1000=4096000,这个就算小文件。正常4M=4194304B

至此Ceph的硬件选型、部署、调优、性能测试等关卡已经讲述完毕,希望本关卡能够给予Ceph新手参考。想要知道葡萄酸不酸,最好的办法就是亲自尝一尝,俗话说:适合自己的才是最好的。对于存储也一样,只有在用户需要的配置方式下,在实际的生产应用系统中,实实在在的运行之后,用户才能真正清楚的感知存储设备的真实性能表现。请读者见仁见智,预知后事如何,请期待《 架构灾备设计》。

时间: 2024-08-01 13:45:27

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

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

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

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

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

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

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

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

上回书讲到了运维小哥的调优方法论(上),对于Ceph运维人员来说最头痛的莫过于两件事:一.Ceph调优:二.Ceph运维.调优是件非常头疼的事情,下面来看看运维小哥是如何调优的. 关卡二:部署调优关之调优(二) 难度:五颗星 优化方法论 通过对网上公开资料的分析进行总结,对Ceph的优化离不开以下几点: 硬件层面 硬件规划 SSD选择 BIOS设置 操作系统层面 Linux Kernel 内存 Cgroup 网络层面 巨型帧 中断亲和 硬件加速 Ceph层面 Ceph Configuration

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

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

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

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

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

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

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

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

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

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