Ceph集群对象存储上传请求慢的问题分析

【问题描述】

采用s3cmd指令上传60M文件，对于大文件s3cmd默认进行分块上传，在多次测试中发现，在分块上传中有几个分块速度较慢

【问题排查】

1、在RGW节点，s3cmd --configure配置accesskey和secretkey

s3cmd 客户端配置：

执行s3cmd --configure 配置相关信息

AccessID：666SxxxxxxxxCCC

AccessSecretkey：SF6666666666xxxxxxxx6666666666NC

bucket：ceshi

备注：Ceph-RGW基本原理

什么是对象存储？

对象存储(云存储)是面向对象/文件的、海量的互联网存储。对象存储里的对象是经过封装了的文件，在对象存储系统里， 不能直接打开/修改文件，但可以像ftp一样上传文件，下载文件等。另外，对象存储没有像文件系统那样有一个很多层级 的文件结构，而是只有一个“桶”的概念（也就是存储空间），“桶”里面全部都是对象，是一种非常扁平化的存储方式。 其最大的特点就是它的对象名称就是一个域名地址，一旦对象被设置为“公开”，所有网民都可以访问到。对象存储最主 流的使用场景，就是存储网站、移动app等互联网/移动互联网应用的静态内容（视频、图片、文件、软件安装包等等）

什么是RGW？

RGW为Rados Gateway的缩写，Ceph通过RGW为互联网云服务提供商提供对象存储服务。RGW在librados之上向应用提供访问Ceph集群的RestAPI， 支持Amazon S3和OpenStack Swift两种接口。对RGW最直接的理解就是一个协议转换层，把从上层应用符合S3或Swift协议的请求转换成rados的请求， 将数据保存在rados集群中

应用场景

● 频繁IO的网盘

● 有海量数据归档和备份需求的互联网应用企业

云备份的企业用户

情况一

A、yum安装s3cmd

安装命令如下所示：

yum -y install python-pip

pip install s3cmd

B、配置s3cmd。

配置s3cmd有两种方式：

使用s3cmd --configure方式配置。

这种方式更适合使用正式S3用户的方案使用

手动配置s3cmd配置文件。

这种方式更适合准备在本地生成S3用户并且不需要亚马逊服务的方案来使用。

在/root目录下，创建.s3cfg文件：

vi .s3cfg

添加内容如下：    

[default]

access_key =

secret_key =

host_base = ip:port

host_bucket = ip/bucket-name

use_https = False

其中，access_key和secret_key是在本地创建S3用户时获得，host_base是S3服务所使用的ip地址（包括端口号）,host_bucket为S3用户下的一个bucket(可在配置之后再创建，但该字段不能为空)

至此，s3cmd安装及配置完成

情况二

s3cmd download | SourceForge.net

https://sourceforge.net/projects/s3tools/

s3cmd版本>1.5

A、下载s3cmd

wget  http://sourceforge.net/projects/s3tools/files/s3cmd/1.5.2/s3cmd-1.5.2.tar.gz

解压

tar -zxf s3cmd-1.5.2.tar.gz -C /usr/local

B、安装setuptools

tar -xf setuptools-0.6c11.tar.gz

cd setuptools-0.6c11

python setup.py install

C、离线包安装s3cmd

cd /usr/local/s3cmd-1.5.2

python setup.py install

D、配置AK

s3cmd --configure

Enter new values or accept defaults in brackets with Enter.

Refer to user manual for detailed description of all options.

Access key and Secret key are your identifiers for Amazon S3. Leave them empty for using the env variables.

Access Key : 输入AK

Secret Key : 输入SK

Default Region [US]:

Encryption password is used to protect your files from reading

by unauthorized persons while in transfer to S3

Encryption password :

Path to GPG program [/usr/bin/gpg]:

When using secure HTTPS protocol all communication with Amazon S3

servers is protected from 3rd party eavesdropping. This method is

slower than plain HTTP, and can only be proxied with Python 2.7 or newer

Use HTTPS protocol [Yes]:

On some networks all internet access must go through a HTTP proxy.

Try setting it here if you can’t connect to S3 directly

HTTP Proxy server name:

New settings:

Access Key:*********************

Secret Key: ***************************

Encryption password: ****

Path to GPG program: /usr/bin/gpg

Use HTTPS protocol: False

HTTP Proxy server name:

HTTP Proxy server port: 0

…

Test access with supplied credentials? [Y/n]

test access… ? 这块选择no，选用yes会测试失败

save the changes? yes

以上必须填写的是AK和SK,其他信息直接回车即可

E、修改配置文件：（如下以中国宁夏为例，修改如下四行内容）

vi /root/.s3cfg

bucket_location = cn-northwest-1

host_base = s3.cn-northwest-1.amazonaws.com.cn

host_bucket = %(bucket)s.s3.cn-northwest-1.amazonaws.com.cn

website_endpoint =http://%(bucket)s.s3-website-%(location)s.amazonaws.com.cn

默认的S3配置文件是AWS美国地域的，所以不修改的话会出现：Your Access key is not in our record类似这种错误

修改完成后即可使用s3cmd 去测试了

Linux系统上使用s3cmd常用命令如下：

查看存储桶内容

s3cmd ls s3://bucket_name

上传存储桶内容 （如递归上传，需要加上参数-r)

s3cmd put filename s3://bucket_name/filename

删除存储桶内容

s3cmd del s3://bucket_name/filename

更多命令查看

s3cmd --help

2、在osd-node-AA存储节点使用s3cmd命令上传约60M大小的test.mp4文件，观察到其中两个part的上传速度已降至kB/s，上传时间也达到了70s和80s

s3cmd  put  test.mp4  s3://ceshi/test.mp4

3、再次测试上传60M文件，用时4分钟左右，part1上传耗时64s，part2上传耗时109s，part3上传耗时正常，part4上传耗时67s

4、rgw日志如下

Starting new request req=66666===

Req done req=66666 status=0 http_status=200 ====

POST ./ceshi/test.mp4 HTTP/1.1 200

未报错，但后端报osd slow request的日志信息。多次测试发现，报slow request的osd数量较多

5、尝试关闭在osd-node-AA存储节点上的 *** 作日志的记录，再次测试仍然速度慢

rgw_enable_usage_log = False

6、测试同时观察性能监控

对应的性能监控，写时延达80秒

【问题分析】

1、按照【问题排查】同样的方式分别对后端rgw的real server进行s3cmd上传，都出现分块较慢的现象，查看rgw配置信息，均符合要求，rgw这一层正常

2、测试发现，后端报osd slow request的日志信息。多次测试发现，报slow request的osd数量较多。对于这些osd，再次进行ceph tell osd.x bench进行测试，发现均正常。通过这两点，基本断定问题出现在网络上

3、对网络进行测试。采用iperf工具对服务器的三个网段进行全量iperf测试

在 ceph1上运行 iperf -s -p 6900，在 ceph2 上运行 iperf -c ceph1 -p 6900

3.1 在每个服务器上起一个iperf server：命令：/usr/bin/iperf3 -s  -p 6900

3.2 在每个服务器上起一个iperf client，命令：iperf3  -c serverip -p 6900 -P 1 -t 10

3.3 查看每台server端的日志。对于管理网段，带宽值是否接近实际的1000MB/s 千兆网络，对于业务网和存储网带宽值是否接近10000MB/s 万兆网络

4、查看所有节点的iperf值，发现osd-node-AA存储节点存储网带宽出现异常，带宽值明显偏小

【问题解决】

相比之下该节点 osd-node-AA存储网段的网络异常，协调硬件集成人员排查交换机层面的网络

写在最后：

要爱具体的人，不要爱抽象的人；要爱生活，不要爱生活的意义

详情请见，微信公众号：
名称：天有日月星
微信号：tyryx10