一个关于ceph的可用空间测试

一、环境

节点概述

mon : ceph-node01 ceph-node02 ceph-node03
osd :ceph-node01 ceph-node02 ceph-node03
mds : ceph-node01 ceph-node02

操作系统:Ubuntu 14.10

每个osd主机有一个OSD,每个OSD可用容量15GB。

二、测试过程

1、ceph -s查看概述

[email protected]:~# ceph -s
    cluster 9ae8eb40-4f71-49ec-aa77-eda1cb6edbc3
     health HEALTH_OK
     monmap e1: 3 mons at {ceph-node01=192.168.239.161:6789/0,ceph-node02=192.168.239.162:6789/0,ceph-node03=192.168.239.163:6789/0}, election epoch 50, quorum 0,1,2 ceph-node01,ceph-node02,ceph-node03
     mdsmap e19: 1/1/1 up {0=ceph-node01=up:active}, 1 up:standby
     osdmap e24: 3 osds: 3 up, 3 in
      pgmap v202: 192 pgs, 3 pools, 672 kB data, 21 objects
            3204 MB used, 45917 MB / 49122 MB avail
                 192 active+clean

2、df查看可用空间

[email protected]:~# df -Pm
Filesystem                                        1048576-blocks  Used Available Capacity Mounted on
/dev/sda1                                                  12277  1474     10804      13% /
none                                                           1     0         1       0% /sys/fs/cgroup
udev                                                        1959     1      1959       1% /dev
tmpfs                                                        394     2       393       1% /run
none                                                           5     0         5       0% /run/lock
none                                                        1970     0      1970       0% /run/shm
none                                                         100     0       100       0% /run/user
/dev/sdb                                                   16374  1067     15308       7% /data
192.168.239.161,192.168.239.162,192.168.239.163:/          49120  3208     45912       7% /mnt/cephfs

上述显示的可用空间肯定是错误的,按照ceph一式三份原则,真实可用的空间应该小于15GB,下面用写 16GB文件的方法来验证。

3、dd写文件

把文件系统挂载到/mnt/cephfs下,用脚本生成8个dd文件,每个文件2GB,为的是撑爆OSD。

脚本内容很简单

#!/bin/bash

count=0
max=8

while [ $count -lt $max ];do
    printf "Writing test${count}.dat\n"
    dd if=/dev/zero bs=1M count=2048 of=test${count}.dat
    ((count++))
done

三、测试结果

写到最后一个文件时,三个节点上的ceph-mon进程无法用ps看到,检查日志文件,有如下提示:

2015-01-03 21:13:55.066943 7f0da98ce700  0 [email protected](leader).data_health(48) update_stats avail 5% total 16766976 used 15915768 avail 851208
2015-01-03 21:13:55.067245 7f0da98ce700 -1 [email protected](leader).data_health(48) reached critical levels of available space on local monitor storage -- shutdown!
2015-01-03 21:13:55.067266 7f0da98ce700  0 ** Shutdown via Data Health Service **
2015-01-03 21:13:55.067292 7f0da7ec9700 -1 [email protected](leader) e1 *** Got Signal Interrupt ***
2015-01-03 21:13:55.067300 7f0da7ec9700  1 [email protected](leader) e1 shutdown
2015-01-03 21:13:55.067338 7f0da7ec9700  0 quorum service shutdown
2015-01-03 21:13:55.067339 7f0da7ec9700  0 [email protected](shutdown).health(48) HealthMonitor::service_shutdown 1 services
2015-01-03 21:13:55.067340 7f0da7ec9700  0 quorum service shutdown

看样子,是ceph-mon进程自己退出了,常见的本地文件系统快满时,出错的是应用程序,为什么ceph-mon设计成干掉自己呢?

时间: 2024-07-30 19:06:04

一个关于ceph的可用空间测试的相关文章

SD卡可用空间大小的判断

protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); File path = Environment.getExternalStorageDirectory(); /*StatFs: * Retrieve overall information about the space on a file

alwaysOn+SQL群集+cluster 高可用方案测试

在SQL2012以前,高可用自动切换方案就是SQL群集了,优点就是切换完全自动,缺点也有很多, 然后2012出现了alwaysOn特性,在高可用上有了很大的提升,今天这个测试是将2个特性结合在一起做一个高可用的方案. 这个方案的优点就是数据上,主数据只有一份,而且不受alwaysOn节点数限制,缺点就是切换时间比alwaysOn本身的要长一些. 准备很简单,AD1台 测试足够. 然后先准备2台服务器,做cluster,注意第3台要做alwaysOn副本的机器千万不要现在加入cluster, 然后

更改虚拟内存文件存放位置释放系统盘可用空间2016-01-15

更改虚拟内存文件存放位置释放系统盘可用空间2016-01-15 问题描述: 系统盘可用空间不足,通过将系统盘的虚拟内存文件转移到非系统盘(如D盘),释放虚拟内存文件所占用的系统盘空间,增加系统盘的可用空间. 1.打开"我的电脑"--"工具"--"文件夹选项"--"查看"--"显示所有文件和文件夹",并取消选中"隐藏说保护的操作系统文件(推荐)"选项--"应用"--&q

java梳理-一个汉字占多大空间

面试题:一个汉字占多大空间. 事实上这个问题我了解不深的,知道结论不知道为什么.借此梳理下认识. 先回想下java基本类型 一基本类型 :简称四类八种,声明变量的同一时候分配了空间.举比例如以下: Int a =1;一.4种整型     byte      1字节           -128--127     short     2 字节         -32,768 -- 32,767     int       4 字节          -2,147,483,648 --2,147,4

3. SQL Server数据库状态监控 - 可用空间

数据库用来存放数据,那么肯定需要存储空间,所以对磁盘空间的监视自然就很有必要了. 一. 磁盘可用空间 1. 操作系统命令或脚本.接口或工具 (1) DOS命令: fsutil volume diskfree C:\windows\system32>fsutil volume diskfree C: Total # of free bytes        : 9789493248 Total # of bytes             : 64424505344 Total # of avai

一个sql导致temp表空间爆掉

Buffer sort引发的血案 今天遇到的一个问题,在线系统上,有两张表,test1大概50G,test2大概200G,需要查询出来test1表中部分记录,并且这些记录不存在test2表中.于是就写了一个sql: select t1.* from test1 t1, test2 t2 where t1.col1 = t2.col1(+) and t1.col2 = t2.col2(+) and t1.col3 = t2.col3(+) and t2.col1 is null; 因为是在线系统,

统计一个C类网段可用IP

[需求描述] 统计10.240.210.171-180/24段的可用IP [思路方法] 利用ping命令,如果结果返回为真(即[ $? -eq "0" ]),证明该IP对应的主机或终端是存活的,之后将对应IP追加到host_alive_lan.txt文件中,否则则将其追加到host_dead_lan.txt文件中,host_dead_lan.txt文件中的IP即为可用IP,用于分配给新机器. [code] #!/bin/bash . /etc/init.d/functions >

探秘:磁盘可用空间被谁吃掉了?

可疑: 分区总容量 7.2T,挂载分区后发现只有6.8T的空间可以使用,400G的空间哪里去了?  探究: 1. 文件被删除未释放磁盘空间? 通过命令 lsof |grep delete 查看确认并未有被进程占用的deleted状态的文件句柄. 2.文件系统损坏了? umount 分区后,fsck.ext3 分区 ,挂载后空间依旧显示只有6.8T空间可用. 3.硬件坏了? 先放着硬件的状态,想想还有什么情况会导致这个问题? 到底是谁吃了我的磁盘空间? 在几个小伙伴的一致探寻下,最终谁会是真凶呢?

Android下获取手机和SD卡的总空间和可用空间

获取SD卡的总空间和可用空间 File path = Environment.getExternalStorageDirectory(); StatFs stat = new StatFs(path.getPath()); long blockSize = stat.getBlockSize(); long totalBlocks = stat.getBlockCount(); long availableBlocks = stat.getAvailableBlocks(); long tota