Ceph性能测试（RBD、CephFS、NFS、Cache Tier）

最新推荐文章于 2024-06-13 10:37:11 发布
最新推荐文章于 2024-06-13 10:37:11 发布
阅读量1.5w 收藏 39
点赞数 12
分类专栏： 【打怪升级】存储 文章标签： ceph 分布式存储
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/get_set/article/details/108092302
版权

本文是以下两篇文章的后续：

  1. 探索fio参数如何选择以及全方位对比HDD和SSD性能：部署Ceph前测试磁盘性能，同时基于fio测试参数的变化深入了解fio原理和磁盘IO特点。
  2. CentOS8使用cephadm部署和配置Ceph Octopus：在CentOS8上使用cephadmin进行Ceph Octopus版本的部署，以及RBD、CephFS、NFS、RGW等的配置。

本文测试内容：

  • Ceph集群性能随OSD个数的增加（2个、4个、6个、8个）性能的变化；
  • Ceph存储随IO队列深度提高（1、2、4、8、16、32、64）的性能变化；
  • Ceph存储与HDD单盘性能的对比（numjobs并发任务个数的影响）；
  • Cache Tier的性能（不科学测试）。

测试过程日志：https://github.com/get-set/fio-bench-disks-ceph/tree/master/ceph

准备工作

本文所测试的Ceph集群：

主机IP配置磁盘(除系统盘)服务
ceph-mon1（虚拟机）192.168.7.114C/8GMON、prom+grafana
ceph-mon2（虚拟机）192.168.7.124C/8GMON、MGR
ceph-mon3（虚拟机）192.168.7.134C/8GMON、MGR
ceph-osd1（物理机）192.168.7.1440C/64G1.6T SSD/4T SAS * 4OSD、MDS、NFS、RGW
ceph-osd2（物理机）192.168.7.1540C/64G1.6T SSD/4T SAS * 4OSD、MDS、NFS、RGW

部署和配置的详细过程见CentOS8使用cephadm部署和配置Ceph Octopus。

首先，单独准备一台测试节点，起一个CentOS8的虚拟机，配好地址和万兆网络。

确保网络带宽

使用iperf3工具测试一下与Ceph集群各节点的带宽：

在Ceph集群节点上：

❯ dnf install -y iperf3
❯ firewall-cmd --zone=public --add-port=5201/tcp --permanent
❯ firewall-cmd --reload

// iperf3 -s <节点的IP>
❯ iperf3 -s 192.168.7.11   # 比如ceph-mon1
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

在测试节点上：

❯ dnf install -y iperf3
// iperf3 -c <所要连接的节点的IP>
❯ iperf3 -c 192.168.7.11
网络分离

Ceph支持将对外服务的网络，和OSD间进行数据同步的网络进行物理网卡上的分离，如图：

我要测试的两台OSD主机上各有两个万兆网口，分别在192.168.7.0/24和10.168.7.0/24两个网段上，现在只需要把cluster network进行设置即可。

❯ ceph config set global cluster_network 10.168.7.0/24
❯ ceph orch daemon restart osd

性能测试（HDD池）

rados bench测试

Ceph的rados工具提供了性能测试命令，可以实现三种测试：write（写）、rand（随机读）和seq（顺序读）。

❯ rados bench -p bench.hdd 30 write --no-cleanup | tee 2hdd/rados_bench_write.log
❯ rados bench -p bench.hdd 30 rand | tee 2hdd/rados_bench_rand.log
❯ rados bench -p bench.hdd 30 seq | tee 2hdd/rados_bench_seq.log

测试结果：

IOIOPSBW(MB/s)
write47190.5
rand (read)72289.3
seq (read)65262.5

从以上结果可以看出，所有的IO测试都是基于4M大小的bs进行的，恐怕没太多参考价值，后续我们主要用来做横向对比。

fio测试

注意：目前仅添加了2块HDD作为OSD。

使用fio工具进行测试，fio测试脚本如下：

[global]
ioengine=libaio      # 异步IO
direct=1             # 排除OS的IO缓存机制的影响
size=5g              # 每个fio进程/线程的最大读写
lockmem=1G           # 锁定所使用的内存大小
runtime=30           # 根据前面的结论以后采用30值
group_reporting      # 多个job合并出报告
directory=/mnt/rbd   # 三次测试分别修改/mnt/rbd、/mnt/cephfs、/mnt/nfs
numjobs=1
iodepth=1

[4k_randwrite]
stonewall
rw=randwrite
bs=4k

[4k_randread]
stonewall
rw=randread
bs=4k

[64k_write]
stonewall
rw=write
bs=64k

[64k_read]
stonewall
rw=read
bs=64k

如上，测试的是4k随机写、4k随机读、64k顺序写、64k顺序读的性能。

由于前面没有对Ceph进行过不同参数值的测试，下面针对iodepth的不同的值观察测试结果（numjobs模拟的是多线程并发，就暂时不测试了，一律用1）。

for iodepth in 1 2 4 8 16 32; do 
    sed -i "/^iodepth/c iodepth=${iodepth}" fio.conf && fio fio.conf | tee 2hdd/rbd_i$(printf "%02d" ${iodepth}).log && sleep 20s
done

这里就不搞两层for嵌套了，手动修改directory指定要测试的目录，然后进行三波测试。

最终结果如下：

重置测试环境

上面的测试是2个HDD部署为OSD的情况，下面每次增加2个HDD，然后测试性能的变化情况。

为了尽可能排除干扰：

  • 每次测试一种分布式存储的时候，其他的存储方式都处于umount状态；
  • 增加OSD的时候，所有的存储方式的挂载目录都umount，尤其是RBD的方式，先unmap，而不是用在线xfs_growfs的方式扩容。

当然，也可以直接删除存储池然后重建。

测试节点上：

1.利用rados bench测试性能

rados bench -p bench.hdd 30 write --no-cleanup | tee <n>hdd/rados_bench_write.log
rados bench -p bench.hdd 30 rand | tee <n>hdd/rados_bench_rand.log
rados bench -p bench.hdd 30 seq | tee <n>hdd/rados_bench_seq.log
# 清理
rados rm -p bench.hdd $(rados ls -p bench.hdd)

2.测试RBD性能

rbd create bench.hdd/disk1 --size 100G
rbd map bench.hdd/disk1
mkfs.xfs /dev/rbd0
mount /dev/rbd0 /mnt/rbd

# 用fio测试RBD性能 ...

rm -f /mnt/rbd/*
umount /mnt/rbd
rbd unmap bench.hdd/disk1
rbd rm bench.hdd/disk1

3.测试CephFS性能

mount -t ceph :/ /mnt/cephfs -o name=admin,secret=AQBYSjZfQF+UJBAAC6QJjNACndkw2LcCR2XLFA==

# 用fio测试CephFS性能...

rm -f /mnt/cephfs/*_*
umount /mnt/cephfs

4.测试NFS性能

mount -t nfs 192.168.7.14:/nfs /mnt/nfs

# 用fio测试NFS性能...

rm -f /mnt/nfs/*
umount /mnt/nfs
fio测试结论
  1. 横向来看，三种挂载方式的性能相差并不大，总体表现CephFS似乎来略好一点点。
  2. 纵向来看，相对于单HDD测试，分布式存储是更能够从iodepth的增加中收益的。图中颜色较深的是综合考虑性能和延迟来看相对较优的测试结果。由此，我们后续的测试采用如下iodepth值来进行对比：
    1. 4k随机读：iodepth=16
    2. 4k随机写：iodepth=8
    3. 64k顺序读：iodepth=2
    4. 64k顺序写：iodepth=16

则更新后的测试脚本如下：

[global]
ioengine=libaio      # 异步IO
direct=1             # 排除OS的IO缓存机制的影响
size=5g              # 每个fio进程/线程的最大读写
lockmem=1G           # 锁定所使用的内存大小
runtime=30           # 根据前面的结论以后采用30值
group_reporting      # 多个job合并出报告
directory=/mnt/rbd   # 三次测试分别修改/mnt/rbd、/mnt/cephfs、/mnt/nfs
numjobs=1

[4k_randwrite]
stonewall
rw=randwrite
bs=4k
iodepth=8

[4k_randread]
stonewall
rw=randread
bs=4k
iodepth=16

[64k_write]
stonewall
rw=write
bs=64k
iodepth=16

[64k_read]
stonewall
rw=read
bs=64k
iodepth=2

不同OSD个数性能对比

上面的测试是2个HDD部署为OSD的情况，下面每次增加2个HDD，然后测试性能的变化情况。

为了尽可能排除干扰：

  • 每次测试一种分布式存储的时候，其他的存储方式都处于umount状态；
  • 增加OSD的时候，所有的存储方式的挂载目录都umount，尤其是RBD的方式，先unmap，而不是用在线xfs_growfs的方式扩容。

当然，也可以直接删除存储池然后重建。

测试过程

每次增加两个HDD，Ceph集群上：

ceph orch daemon add osd ceph-osd1:/dev/sd<x>
ceph orch daemon add osd ceph-osd2:/dev/sd<x>

添加后，注意用ceps -s观察pg状态是否全部active+clean。

rados bench的结果：

（第一轮测试结果）

（第二轮测试结果）

fio测试的结果：

（第一轮测试结果）

（第二轮测试结果）

为了结论的准确性，这里进行了两轮测试。第二轮是将OSD进行了out处理又从新in之后测试的结果，可以看出，两轮的测试结果很接近，看来性能还是很稳定的。

测试结论
  1. 随着OSD个数的增加，Ceph集群的整体性能是有提升的，尤其是来自rados bench的数据更加显著。
  2. fio测试的结果可能更接近真实情况：
    • 对4k随机读来说，OSD越多，性能越强，而且似乎是线性提升，而且延迟也是与OSD个数成反比。
    • 对4k随机写来说，OSD越多，RBD和CephFS的性能越强，而且似乎是线性提升，只是NFS并没有这样的”待遇“。
    • 对64k顺序读来说，与4k随机写正相反，RBD和CephFS几乎没有提升，而NFS却有性能提升。
    • 对64k顺序写来说，性能与OSD个数没有太大关系。这不大科学，照理说，多个OSD各自同时承担一些写操作的话，性能应该会随OSD个数提升才对。也许是IO并发数不够（本轮的顺序写的iodepth=16，使得不足以发挥出最高性能。

Ceph存储随iodepth的性能变化

测试过程

考虑到OSD的个数增加，应该对高并发的IO操作带来更强的性能，最后，对于8个HDD作为OSD的情况，再次针对iodepth进行测试，结果如下：

测试结论
  1. 相对于4HDD来说，8HDD话，顺序读写的高并发能力提升了，iodepth从32-128仍然能够带来性能的提升。尤其iodepth=128时，顺序写达到了600-700MiB/s，延迟也并没有增加多少，这才对嘛。
  2. NFS的性能表现差强人意，队列深度达到一定的值之后，性能反而下降；NFS的整体性能与RBD和CephFS相比也略显不足。
  3. 总起来说，Ceph是喜欢高并发IO的。**除了4k随机写，其他的三种IO方式都能够从更高的队列深度中获益。**不过队列深度只是每一个批次中IO的数量，如果直接增加批次个数（numjobs）本身呢？

8HDD与HDD单盘性能对比

测试过程

我的测试环境中，RBD、CephFS（NFS基于CephFS）所在的存储池是size=2的。所以，8个HDD的磁盘性能理论上最高可以达到相当于4个HDD单盘的性能。实际情况如何？下面设置numjobs=4测试一下。

最后把单HDD磁盘、numjobs=1的结果（上一小节）、numjobs=4的结果一起进行对比。

此时，将测试机的虚拟CPU和内存调高4倍。

注：非常抱歉，其实前后应该保持同样的测试环境，不过最初确实忘了，只给了1个CPU和4G内存，这次numjobs=4会同时启动4个测试进程，所以调大资源。

每个fio会锁定1G的测试内存，理论上前面对Ceph的测试是不会把资源跑满的，而且前面的测试主要以纵向对比为主，每次测试的环境是保持一致的，所以不影响前面测试结果和结论的参考价值。

compaire.conf：

[global]
ioengine=libaio      # 异步IO
direct=1             # 排除OS的IO缓存机制的影响
size=5g              # 每个fio进程/线程的最大读写
lockmem=1G           # 锁定所使用的内存大小
runtime=30           # 根据前面的结论以后采用30值
group_reporting      # 多个job合并出报告
directory=/mnt/rbd   # 三次测试分别修改/mnt/rbd、/mnt/cephfs、/mnt/nfs
numjobs=4
iodepth=1

[4k_randwrite]
stonewall
rw=randwrite
bs=4k

[4k_randread]
stonewall
rw=randread
bs=4k

[64k_write]
stonewall
rw=write
bs=64k

[64k_read]
stonewall
rw=read
bs=64k

共三次测试，分别针对/mnt/rbd、/mnt/cephfs、/mnt/nfs，分别挂载不同的存储后端到不同的目录，然后测试不同的iodepth的性能指标，并最终与HDD单盘性能进行比对。

for iodepth in 1 2 4 8 16 32 64; do sed -i "/^iodepth/c iodepth=${iodepth}" compaire.conf && fio compaire.conf | tee compaire/iodepth$(printf "%02d" ${iodepth}).log && rm -f /mnt/rbd/* && sleep 30s; done

测试结果：

  • 性能指标BW(MiB/s)

  • 延迟指标clat(usec)

注：图中第二列中(4)和(1)指的是numjobs值。单盘HDD最初测试的时候由于除4k随机读外随iodepth的增加很快达到性能上限，因此没有对iodepth=32和64进行测试。

测试结论

对比HDD单盘、numjobs=1和numjobs=4的RBD、CephFS、NFS的性能：

  • 【总体性能】多数情况下，性能排序为：numjobs=1时的Ceph < HDD单盘 < numjobs=4时的Ceph，可见分布式存储还是欢迎多任务多队列深度的并发IO操作的，甚至在iodepth比较低的时候，numjobs=4的性能可达numjobs=1的3-4倍，这个比例与本节最初的猜测有些接近。
  • 【并发趋势】除NFS外，性能随着iodepth的增加，更确切说是随着numjobs * iodepth的增加而提升：
    • 写操作比读操作能够更快达到最高性能；
    • 顺序操作比随机操作能够更快达到最高性能；
    • 而NFS的性能大约在numjobs * iodepth达到16/32后不升反降，延迟也会相对更高。
  • 【最高性能】对于读操作，Ceph最高性能大约与单盘HDD相当；对于写操作，Ceph最高性能大约是单盘HDD的3-4倍，这个比例同样与本节最初的猜测接近，相信原因大家都可以猜到。
  • 【延迟对比】HDD单盘 < numjobs=1时的Ceph < numjobs=4时的Ceph，无需解释。

看来，如果Ceph中有更多的存储池，或存储池中有更多的RBD，那么是有希望进一步挖掘**“磁盘利用率尚有空间的”**性能的。

Cache Tier性能

测试过程

准备两个存储池，分别是ssd和hdd，分别位于SSD和HDD上。然后让ssd做hdd的缓存层。

# 创建两个存储池
ceph osd pool create ssd on-ssd
ceph osd pool create hdd on-hdd

# 把SSD挂接到HDD上
ceph osd tier add hdd ssd
# 配置写回模式
ceph osd tier cache-mode ssd writeback
# 将客户端流量指向到缓存存储池
ceph osd tier set-overlay hdd ssd
# 调整配置
# 设置缓存层hit_set_type使用bloom过滤器
ceph osd pool set ssd hit_set_type bloom
# 设置热度数hit_set_count和热度周期hit_set_period，以及最大缓冲数据target_max_bytes
# hit_set_count 和 hit_set_period 选项分别定义了 HitSet 覆盖的时间区间、以及保留多少个这样的 HitSet，保留一段时间以来的访问记录，这样 Ceph 就能判断一客户端在一段时间内访问了某对象一次、还是多次（存活期与热度）
ceph osd pool set ssd hit_set_count 1
ceph osd pool set ssd hit_set_period 3600
ceph osd pool set ssd target_max_bytes 1000000000000
ceph osd pool set ssd min_read_recency_for_promote 1
ceph osd pool set ssd min_write_recency_for_promote 1
# 当缓冲池里被修改的数据达到40%时，则触发刷写动作。
ceph osd pool set ssd cache_target_dirty_ratio 0.4
# 当缓冲池里被修改数据达到60%时候，则高速刷写。
ceph osd pool set ssd cache_target_dirty_high_ratio 0.6
# 当缓冲池里的容量使用达到80%时候，则触发驱逐操作。
ceph osd pool set ssd cache_target_full_ratio 0.8
# 若被修改的对象在缓冲池里超过最短周期（单位分钟），将会被刷写到慢存储池
ceph osd pool set ssd cache_min_flush_age 600

测试节点上：

1.利用rados bench测试性能

rados bench -p hdd 30 write --no-cleanup | tee cache_tier/rados_bench_write.log
rados bench -p hdd 30 rand | tee cache_tier/rados_bench_rand.log
rados bench -p hdd 30 seq | tee cache_tier/rados_bench_seq.log
# 清理
rados rm -p hdd $(rados ls -p hdd)

2.测试RBD性能

rbd create hdd/disk1 --size 100G
rbd map hdd/disk1
mkfs.xfs /dev/rbd0
mount /dev/rbd0 /mnt/rbd

# 用fio测试RBD性能 ...

rm -f /mnt/rbd/*
umount /mnt/rbd
rbd unmap hdd/disk1
rbd rm hdd/disk1

CephFS和NFS不受影响，不做测试。

rados bench的结果：

fio的结果，加在之前的图上进行对比：

2、4、6、8是上一小节的测试结果，也就是没有开启Cache tier的数据，最后一个是开启了cache tier的8个HDD的数据。

测试结论

结合上面的两个图，直接把官方的文档搬过来：

Cacher tiering会导致多数情况下的性能下降，因此应谨慎使用：

  • 性能与workload强相关：由于IO过程中涉及将对象从缓存层拷入拷出，所以性能通常会有下降；如果workload的类型是”大多数的请求命中的是对象中的一小部分“，这种情况下，由于高命中率，相对会有明显的性能提升。
  • 难以进行性能测试：类似上面的fio测试，其实是不满足上一条中的workload类型的，还没等缓存层”warm up“（性能会下降）起来，测试就结束了。
  • librados object enumeration：对于librados层的枚举API，缓存层的表现不如预期。
  • 复杂性：这一特性的复杂性（上面的一系列参数的配置可见一斑）会带来潜在的风险。

总之，除非有确定的理由（比如总是通过RGW读取最近存入的数据），否则不建议开启Cache Tiering。

删除Cache Tiering
# 将cache模式切换回readproxy
ceph osd tier cache-mode ssd readproxy
# 确保缓存池中的对象已经全部落到慢存储的池子里
rados -p ssd ls
rados -p ssd cache-flush-evict-all
# 移除慢存储池的overlay
ceph osd tier remove-overlay hdd
# 取消cache tier
ceph osd tier remove hdd ssd
享学IT
关注
  • 12
    点赞
  • 踩
  • 39
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
专栏目录
为什么都说NFS读写性能差，如何进行优化？
shuningzhang的专栏
10-02 758
如下图是通过Wireshark抓取的网络通信的数据包，可以看出，NFS在访问文件的时候客户端与服务端有的交互除了WRITE之外，还有很多其它的交互，包括ACCESS、LOOKUP和SETATTR等。核心原则是减少客户端与服务端的交互次数，因此我们在访问文件的时候应该尽量保持文件的打开状态，避免重复打开关闭文件，这样NFS全路径的逐级检查。但是，如果是自己开发的应用程序， 在保存数据的时候尽量以大文件的形式，而非小文件的形式，这对性能是有益的。所以，对于一个长路径进行逐级的确认也是必须的。
Ceph性能测试：纠删码 vs. 三副本？.pdf
04-27
Ceph 在今天有多火就不⽤多说了吧。正如许多分布式存储那样，三副本的容量利利 用率始终是个问题，特别是对于海量⾮结构化数据和冷存储这些在意性价比的应用来说。相比之下，纠删码(Erasure Code)能够提供接近于本地 RAID 5/6 的有效磁盘空间，代价是牺牲了性能。纠删码在随机写⼊，特别是改写和重构(Rebuild)时产生的 I/O 惩罚较大，对应的集群网络流量比副本保护模式要大。 那么 Ceph 使⽤用纠删码在各种情况下的性能都⽐比三副本要低吗?答案是否定的。如果您 还⼼心存疑问，请看本⽂文分解。
日志分析里面的max是什么_Ceph性能瓶颈分析与优化(rbd篇)
weixin_39531834的博客
12-20 370
背景希望通过对ceph的性能瓶颈点进行分析，从而找到io路径主要性能瓶颈点，进而对ceph的性能做相应的优化。ceph的性能瓶颈分析与优化一直是一个难点，因为优化性能这个事情本身是没有一成不变的可供参考的例子，比如一些朋友提供了ceph配置优化的建议，但是这种优化是基于特定硬件以及特定环境的，是不可复制的。我个人理解的是如果期望对性能瓶颈进行分析并进行优化，最好的办法便是通过ceph的io日志或者...
第27讲：Ceph存储集群高可用性与性能压测实战
最新发布
江晓龙的博客
06-13 1135
当停掉ceph-node-2节点中的Monitor组件后，集群状态就开始显示WARN了，提示集群中有一个Monitor组件已经宕掉，现在可用的Monitor组件还剩下ceph-node-1和ceph-node-3等节点，并且挂掉的ceph-node-2节点已经不再仲裁节点列表中了，当前在仲裁列表中的节点只剩下了ceph-node-1和ceph-node-3。2）for循环写入数据的同时，停掉ceph-node-2节点的MDS组件，观察MDS主从切换一瞬间，对于数据写入的影响。
分布式存储系统——ceph
x74188的博客
10-15 3841
Ceph使用C++语言开发，是一个开放、自我修复和自我管理的开源分布式存储系统。具有高扩展性、高性能、高可靠性的优点。Ceph目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack，Kubernetes都可与Ceph整合以支持虚拟机镜像的后端存储。粗略估计，我国70%—80%的云平台都将Ceph作为底层的存储平台，由此可见Ceph俨然成为了开源云平台的标配。
linux nfs挂载 测速,CentOS下使用fio测试挂载了CEPH rbd磁盘的读写性能|4k随机/顺序读写...
weixin_28982257的博客
05-15 984
背景简介继续上文的ceph性能调整，有兴趣的可以看看：使用rbd bench/bench-write自带测速工具和fio对ceph image进行性能测试|测速跑分文章目录[隐藏] 前言 集群配置 开始测试 前言 最近在折腾CEPH集群，测试环境是4台ceph物理节点，每台8~12个SATA/SAS机械硬盘，共43个OSD。性能远低于预期，目前正在调整配置中…… 正好实测了一下性能，这里分享出来大...
ceph集群中RBD的性能测试、性能调优
qq_43604376的博客
07-28 1978
RBD性能测试，性能调优
Cephfs & Ceph RBD 在k8s中的适用场景讨论及数据库性能压测
ywq935的博客
09-29 8840
前言 在此前的文章中,已经针对cephfs进行过I/O性能压力测试: cephfs调优 &amp;amp;amp;amp;amp;amp; 性能测试 &amp;amp;amp;amp;amp;amp; 监控 &amp;amp;amp;amp;amp;amp; 常用命令 测试发现cephfs的小文件读写性能一般,且写入延迟偏高,性能不甚满意,但是满足于日常应用环境的读写是没有问题的,但是在面对数据库的应用场景,是否能满足性能要求呢?本篇主要针对数据库场景,来进行cephfs 和
ceph rbd 文件读写测试
Terry Tsang
12-04 847
目的利用 rbd 文件读写, 对 ceph 集群 io 进行测试 通过参数调整, 控制 IO 读写速度 检测 SSD 在日志盘进行读写时候是否会达到瓶颈
ceph中对象读写的顺序性及并发性保证
lvlei19911108的博客
09-23 433
分布式系统中经常需要考虑对象(或者记录、文件、数据块等)的读写的顺序以及并发访问问题。通常来说，如果两个对象没有共享的资源，就可以进行并发的访问，如果有共享的部分，就需要对这部分资源进行加锁；而对于同一个对象的并发读写(尤其是并发写更新时)，就需要注意顺序性以及并发访问的控制，以免数据错乱。本文主要对ceph中对象读写的顺序及并发性保证机制进行介绍。PG的概念ceph中引入PG(Placement...
cephadm部署ceph quincy版本，使用ceph-csi连接
陈海峰的博客
11-25 1224
ceph orch host add node101 或 ceph orch host add node101 192.168.2.101。ceph orch host add node102 或 ceph orch host add node102 192.168.2.102。方式1: 让ceph使用所有可用的存储设备。访问ceph dashboard。配置主机名/etc/hosts。关闭并且禁用selinux。配置时间同步chrony。方式2：手工添加存储设备。安装docker服务。
GlusterFS与Ceph 性能测试报告
09-17
GlusterFS与Ceph是不一样的存贮系统，GlusterFS更加针对分布式...而同时，市场上流传着各类关于GlusterFS与Ceph对比的各类性能数据，实际情况倒底如可，我们不得而知，但我确实想知道真实的情况如何，或者大概的也行
K8s-ceph-csi-rbd连接资源
06-15
RBD（RADOS Block Device）是Ceph中的块存储组件，它允许直接将Ceph存储作为块设备映射到计算节点。CSI（Container Storage Interface）是Kubernetes定义的一个标准接口，旨在使存储提供商能够为Kubernetes提供存储...
ceph rbd所有操作命令汇总
02-20
ceph rbd操作命令汇总
Ceph性能瓶颈分析与优化(混合盘篇)
流年似水的专栏
12-13 2041
ceph性能优化: 混合盘场景
Ceph入门到精通- ceph orch daemon add osd ceph03:/dev/sdb
隔壁老瓦的专栏
04-21 1401
ceph 添加osd 错误
Ceph读写性能估算方法
小鱼菜鸟的博客
07-22 562
前言 最近在做Ceph性能测试相关工作，在测试初期由于没有得到理想的测试结果，因此对Ceph集群进行了优化，但是一直有个问题萦绕在我的脑海：基于当前硬件配置，这个Ceph集群的极限是多少？ 由于这个问题和Ceph的配置息息相关，为了简化问题，在本文中我们只会会讨论3个变量：冗余策略(纠删码、多副本)，读/写，ObjectStore。我们将会基于磁盘、...
ceph性能测试
wanger5354的博客
08-25 1322
微信公众号：运维开发故事，作者：wanger在将Ceph集群用于生产工作之前，应该首先对它进行基准测试。基准测试提供关于群集在读、写、延迟和其他工作负载期间执行情况的大致结果。在进行真正的基准测试之前，最好通过测量连接到群集节点的硬件（如磁盘和网络）的性能，为预期的最大性能建立一个基准。磁盘性能基线测试将分两步完成。首先，我们将测量单个磁盘的性能，在此之后，将同时测量连接到一个Ceph OSD节点的所有磁盘性能。
ceph读写性能测试
05-25
Ceph是一个分布式存储系统，它具有高可用性、高可扩展性和高性能等特点。对于测试Ceph的读写性能，需要考虑以下几个方面： 1. 网络带宽：Ceph的性能很大程度上受限于网络带宽，因此需要保证网络带宽充足。 2. 存储介质：Ceph支持多种存储介质，包括SSD、HDD等，不同的存储介质对性能的影响是不同的。 3. Ceph集群部署：Ceph的性能也与集群部署方式有关，需要根据实际情况选择适当的部署方式。 4. 测试工具：可以使用像fio、dd等工具来测试Ceph的读写性能。 下面是一些简单的测试步骤： 1. 安装fio工具，并创建测试文件。比如，可以创建一个1GB的文件： ``` dd if=/dev/zero of=/mnt/testfile bs=1M count=1024 ``` 2. 编写fio测试脚本，比如： ``` [global] ioengine=rados rados_pool=rbd runtime=60 time_based [test] size=100M rw=randwrite ``` 这个脚本会使用rados引擎进行测试，测试的对象是rbd池，测试时间为60秒，测试操作是随机写入100MB数据。 3. 运行测试脚本： ``` fio test.fio ``` 运行结果会输出测试的吞吐量、IOPS等信息。 需要注意的是，由于Ceph的性能受到多方面因素的影响，测试结果可能不够准确，需要进行多次测试并取平均值来获得更可靠的结果。同时，需要根据实际情况选择适当的测试工具和测试参数。
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值