Ceph 安装与配置

1. Ceph介绍
   1.1. 文件系统概述
   Ceph 最初是一项关于存储系统的 PhD 研究项目，由 Sage Weil 在 University of California, Santa Cruz（UCSC）实施。Ceph 是开源分布式存储，也是主线 Linux 内核（2.6.34）的一部分。
   1.1.1. Ceph架构
   Ceph 生态系统可以大致划分为四部分（见图 1）：客户端（数据用户），元数据服务器（缓存和同步分布式元数据），一个对象存储集群（将数据和元数据作为对象存储，执行其他关键职能），以及最后的集群监视器（执行监视功能）。

如图 1 所示，客户使用元数据服务器，执行元数据操作（来确定数据位置）。元数据服务器管理数据位置，以及在何处存储新数据。值得注意的是，元数据存储在一个存储 集群（标为 “元数据 I/O”）。实际的文件 I/O 发生在客户和对象存储集群之间。这样一来，更高层次的 POSIX 功能（例如，打开、关闭、重命名）就由元数据服务器管理，不过 POSIX 功能（例如读和写）则直接由对象存储集群管理。
另一个架构视图由图 2 提供。一系列服务器通过一个客户界面访问 Ceph 生态系统，这就明白了元数据服务器和对象级存储器之间的关系。分布式存储系统可以在一些层中查看，包括一个存储设备的格式（Extent and B-tree-based Object File System [EBOFS] 或者一个备选），还有一个设计用于管理数据复制，故障检测，恢复，以及随后的数据迁移的覆盖管理层，叫做 Reliable Autonomic Distributed Object Storage（RADOS）。最后，监视器用于识别组件故障，包括随后的通知。

1.1.2. Ceph组件
了解了 Ceph 的概念架构之后，您可以挖掘到另一个层次，了解在 Ceph 中实现的主要组件。Ceph 和传统的文件系统之间的重要差异之一就是，它将智能都用在了生态环境而不是文件系统本身。
图 3 显示了一个简单的 Ceph 生态系统。Ceph Client 是 Ceph 文件系统的用户。Ceph Metadata Daemon 提供了元数据服务器，而 Ceph Object Storage Daemon 提供了实际存储（对数据和元数据两者）。最后，Ceph Monitor 提供了集群管理。要注意的是，Ceph 客户，对象存储端点，元数据服务器（根据文件系统的容量）可以有许多，而且至少有一对冗余的监视器。那么，这个文件系统是如何分布的呢？

图 1-3 简单的Ceph生态系统
1.2. Ceph客户端
因为 Linux 显示文件系统的一个公共界面（通过虚拟文件系统交换机 [VFS]），Ceph 的用户透视图就是透明的。管理员的透视图肯定是不同的，考虑到很多服务器会包含存储系统这一潜在因素（要查看更多创建 Ceph 集群的信息，见 参考资料 部分）。从用户的角度看，他们访问大容量的存储系统，却不知道下面聚合成一个大容量的存储池的元数据服务器，监视器，还有独立的对象存储设备。用户只是简 单地看到一个安装点，在这点上可以执行标准文件 I/O。
Ceph 文件系统 — 或者至少是客户端接口 — 在 Linux 内核中实现。值得注意的是，在大多数文件系统中，所有的控制和智能在内核的文件系统源本身中执行。但是，在 Ceph 中，文件系统的智能分布在节点上，这简化了客户端接口，并为 Ceph 提供了大规模（甚至动态）扩展能力。
Ceph 使用一个有趣的备选，而不是依赖分配列表（将磁盘上的块映射到指定文件的元数据）。Linux 透视图中的一个文件会分配到一个来自元数据服务器的 inode number（INO），对于文件这是一个唯一的标识符。然后文件被推入一些对象中（根据文件的大小）。使用 INO 和 object number（ONO），每个对象都分配到一个对象 ID（OID）。在 OID 上使用一个简单的哈希，每个对象都被分配到一个放置组。放置组（标识为 PGID）是一个对象的概念容器。最后，放置组到对象存储设备的映射是一个伪随机映射，使用一个叫做 Controlled Replication Under Scalable Hashing（CRUSH）的算法。这样一来，放置组（以及副本）到存储设备的映射就不用依赖任何元数据，而是依赖一个伪随机的映射函数。这种操作是理 想的，因为它把存储的开销最小化，简化了分配和数据查询。
分配的最后组件是集群映射。集群映射 是设备的有效表示，显示了存储集群。有了 PGID 和集群映射，您就可以定位任何对象。

1.3. Ceph元数据服务器
元数据服务器（cmds）的工作就是管理文件系统的名称空间。虽然元数据和数据两者都存储在对象存储集群，但两者分别管理，支持可扩展性。事实上， 元数据在一个元数据服务器集群上被进一步拆分，元数据服务器能够自适应地复制和分配名称空间，避免出现热点。如图 4 所示，元数据服务器管理名称空间部分，可以（为冗余和性能）进行重叠。元数据服务器到名称空间的映射在 Ceph 中使用动态子树逻辑分区执行，它允许 Ceph 对变化的工作负载进行调整（在元数据服务器之间迁移名称空间）同时保留性能的位置。

但是因为每个元数据服务器只是简单地管理客户端人口的名称空间，它的主要应用就是一个智能元数据缓存（因为实际的元数据最终存储在对象存储集群 中）。进行写操作的元数据被缓存在一个短期的日志中，它最终还是被推入物理存储器中。这个动作允许元数据服务器将最近的元数据回馈给客户（这在元数据操作 中很常见）。这个日志对故障恢复也很有用：如果元数据服务器发生故障，它的日志就会被重放，保证元数据安全存储在磁盘上。
元数据服务器管理 inode 空间，将文件名转变为元数据。元数据服务器将文件名转变为索引节点，文件大小，和 Ceph 客户端用于文件 I/O 的分段数据（布局）。
1.4. Ceph 监视器
Ceph 包含实施集群映射管理的监视器，但是故障管理的一些要素是在对象存储本身中执行的。当对象存储设备发生故障或者新设备添加时，监视器就检测和维护一个有效 的集群映射。这个功能按一种分布的方式执行，这种方式中映射升级可以和当前的流量通信。Ceph 使用 Paxos，它是一系列分布式共识算法。
1.5. Ceph 对象存储
和传统的对象存储类似，Ceph 存储节点不仅包括存储，还包括智能。传统的驱动是只响应来自启动者的命令的简单目标。但是对象存储设备是智能设备，它能作为目标和启动者，支持与其他对象存储设备的通信和合作。
从存储角度来看，Ceph 对象存储设备执行从对象到块的映射（在客户端的文件系统层中常常执行的任务）。这个动作允许本地实体以最佳方式决定怎样存储一个对象。Ceph 的早期版本在一个名为 EBOFS 的本地存储器上实现一个自定义低级文件系统。这个系统实现一个到底层存储的非标准接口，这个底层存储已针对对象语义和其他特性（例如对磁盘提交的异步通 知）调优。今天，B-tree 文件系统（BTRFS）可以被用于存储节点，它已经实现了部分必要功能（例如嵌入式完整性）。
因为 Ceph 客户实现 CRUSH，而且对磁盘上的文件映射块一无所知，下面的存储设备就能安全地管理对象到块的映射。这允许存储节点复制数据（当发现一个设备出现故障时）。分 配故障恢复也允许存储系统扩展，因为故障检测和恢复跨生态系统分配。Ceph 称其为 RADOS。
1.6 Ceph 特点
Object：有原生的API，而且也兼容Swift和S3的API
Block：支持精简配置、快照、克隆
File：Posix接口，支持快照
Ceph也是分布式存储系统，它的特点是：

高扩展性：使用普通x86服务器，支持10~1000台服务器，支持TB到PB级的扩展。
高可靠性：没有单点故障，多数据副本，自动管理，自动修复。
高性能：数据分布均衡，并行化度高。对于objects storage和block storage,不需要元数据服务器。

1. 部署与配置

系统环境：Ubuntu 12.04.2
hostname:s1 osd.0/mon.a/mds.a ip:192.168.242.128
hostname:s2 osd.1/mon.b/mds.b ip:192.168.242.129
hostname:s3 osd.2/mon.c/mds.c ip:192.168.242.130
hostname:s4 client ip:192.168.242.131

免密钥：
s1/s2/s3 启用root，相互之间配置免密钥。
cat id_rsa.pub_s* >> authorized_keys

安装：
apt-get install ceph ceph-common ceph-fs-common （ceph-mds）
更新到新版本：
wget -q -O- ‘https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc’| sudo apt-key add -
echo deb http://ceph.com/debian/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list
apt-get update
apt-get install ceph

分区及挂载(使用btrfs)：
root@s1:/data/osd.0# df -h|grep osd
/dev/sdb1 20G 180M 19G 1% /data/osd.0
root@s2:/data/osd.1# df -h|grep osd
/dev/sdb1 20G 173M 19G 1% /data/osd.1
root@s3:/data/osd.2# df -h|grep osd
/dev/sdb1 20G 180M 19G 1% /data/osd.2
root@s1:~/.ssh# mkdir -p /tmp/ceph/（每个server上执行）

配置：
root@s1:/data/osd.0# vim /etc/ceph/ceph.conf
[global]
auth cluster required = none
auth service required = none
auth client required = none
[osd]
osd data = /data/$name [mon] mon data = /data/$name

[mon.a]
host = s1
mon addr = 192.168.242.128:6789
[mon.b]
host = s2
mon addr = 192.168.242.129:6789
[mon.c]
host = s3
mon addr = 192.168.242.130:6789

[osd.0]
host = s1
brtfs devs = /dev/sdb1
[osd.1]
host = s2
brtfs devs = /dev/sdb1
[osd.2]
host = s3
brtfs devs = /dev/sdb1

[mds.a]
host = s1
[mds.b]
host = s2
[mds.c]
host = s3

同步配置：
root@s1:~/.ssh# scp /etc/ceph/ceph.conf s2:/etc/ceph/
ceph.conf 100% 555 0.5KB/s 00:00
root@s1:~/.ssh# scp /etc/ceph/ceph.conf s3:/etc/ceph/
ceph.conf 100% 555 0.5KB/s 00:00

所有server上执行：
rm -rf /data/$name/* /data/mon/*（初始化前保持没有任何数据）
root@s1:~/.ssh# mkcephfs -a -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.keyring
temp dir is /tmp/mkcephfs.qLmwP4Nd0G
preparing monmap in /tmp/mkcephfs.qLmwP4Nd0G/monmap
/usr/bin/monmaptool –create –clobber –add a 192.168.242.128:6789 –add b 192.168.242.129:6789 –add c 192.168.242.130:6789 –print /tmp/mkcephfs.qLmwP4Nd0G/monmap
/usr/bin/monmaptool: monmap file /tmp/mkcephfs.qLmwP4Nd0G/monmap
/usr/bin/monmaptool: generated fsid c26fac57-4941-411f-a6ac-3dcd024f2073
epoch 0
fsid c26fac57-4941-411f-a6ac-3dcd024f2073
last_changed 2014-05-08 16:08:06.102237
created 2014-05-08 16:08:06.102237
0: 192.168.242.128:6789/0 mon.a
1: 192.168.242.129:6789/0 mon.b
2: 192.168.242.130:6789/0 mon.c
/usr/bin/monmaptool: writing epoch 0 to /tmp/mkcephfs.qLmwP4Nd0G/monmap (3 monitors)
=== osd.0 ===
** WARNING: No osd journal is configured: write latency may be high.
If you will not be using an osd journal, write latency may be
relatively high. It can be reduced somewhat by lowering
filestore_max_sync_interval, but lower values mean lower write
throughput, especially with spinning disks.
2014-05-08 16:08:11.279610 b72cc740 created object store /data/osd.0 for osd.0 fsid c26fac57-4941-411f-a6ac-3dcd024f2073
creating private key for osd.0 keyring /tmp/mkcephfs.qLmwP4Nd0G/keyring.osd.0
creating /tmp/mkcephfs.qLmwP4Nd0G/keyring.osd.0
=== osd.1 ===
pushing conf and monmap to s2:/tmp/mkfs.ceph.5884
** WARNING: No osd journal is configured: write latency may be high.
If you will not be using an osd journal, write latency may be
relatively high. It can be reduced somewhat by lowering
filestore_max_sync_interval, but lower values mean lower write
throughput, especially with spinning disks.
2014-05-08 16:08:21.146302 b7234740 created object store /data/osd.1 for osd.1 fsid c26fac57-4941-411f-a6ac-3dcd024f2073
creating private key for osd.1 keyring /tmp/mkfs.ceph.5884/keyring.osd.1
creating /tmp/mkfs.ceph.5884/keyring.osd.1
collecting osd.1 key
=== osd.2 ===
pushing conf and monmap to s3:/tmp/mkfs.ceph.5884
** WARNING: No osd journal is configured: write latency may be high.
If you will not be using an osd journal, write latency may be
relatively high. It can be reduced somewhat by lowering
filestore_max_sync_interval, but lower values mean lower write
throughput, especially with spinning disks.
2014-05-08 16:08:27.264484 b72b3740 created object store /data/osd.2 for osd.2 fsid c26fac57-4941-411f-a6ac-3dcd024f2073
creating private key for osd.2 keyring /tmp/mkfs.ceph.5884/keyring.osd.2
creating /tmp/mkfs.ceph.5884/keyring.osd.2
collecting osd.2 key
=== mds.a ===
creating private key for mds.a keyring /tmp/mkcephfs.qLmwP4Nd0G/keyring.mds.a
creating /tmp/mkcephfs.qLmwP4Nd0G/keyring.mds.a
=== mds.b ===
pushing conf and monmap to s2:/tmp/mkfs.ceph.5884
creating private key for mds.b keyring /tmp/mkfs.ceph.5884/keyring.mds.b
creating /tmp/mkfs.ceph.5884/keyring.mds.b
collecting mds.b key
=== mds.c ===
pushing conf and monmap to s3:/tmp/mkfs.ceph.5884
creating private key for mds.c keyring /tmp/mkfs.ceph.5884/keyring.mds.c
creating /tmp/mkfs.ceph.5884/keyring.mds.c
collecting mds.c key
Building generic osdmap from /tmp/mkcephfs.qLmwP4Nd0G/conf
/usr/bin/osdmaptool: osdmap file ‘/tmp/mkcephfs.qLmwP4Nd0G/osdmap’
2014-05-08 16:08:26.100746 b731e740 adding osd.0 at {host=s1,pool=default,rack=unknownrack}
2014-05-08 16:08:26.101413 b731e740 adding osd.1 at {host=s2,pool=default,rack=unknownrack}
2014-05-08 16:08:26.101902 b731e740 adding osd.2 at {host=s3,pool=default,rack=unknownrack}
/usr/bin/osdmaptool: writing epoch 1 to /tmp/mkcephfs.qLmwP4Nd0G/osdmap
Generating admin key at /tmp/mkcephfs.qLmwP4Nd0G/keyring.admin
creating /tmp/mkcephfs.qLmwP4Nd0G/keyring.admin
Building initial monitor keyring
added entity mds.a auth auth(auid = 18446744073709551615 key=AQB3O2tTwDNwLRAAofpkrOMqtHCPTFX36EKAMA== with 0 caps)
added entity mds.b auth auth(auid = 18446744073709551615 key=AQB8O2tT8H8nIhAAq1O2lh4IV/cQ73FUUTOUug== with 0 caps)
added entity mds.c auth auth(auid = 18446744073709551615 key=AQB9O2tTWIfsKRAAVYeueMToC85tRSvlslV/jQ== with 0 caps)
added entity osd.0 auth auth(auid = 18446744073709551615 key=AQBrO2tTOLQpEhAA4MS83CnJRYAkoxrFSvC3aQ== with 0 caps)
added entity osd.1 auth auth(auid = 18446744073709551615 key=AQB1O2tTME0eChAA7U4xSrv7MJUZ8vxcEkILbw== with 0 caps)
added entity osd.2 auth auth(auid = 18446744073709551615 key=AQB7O2tT0FUKERAAQ/EJT5TclI2XSCLAWAZZOw== with 0 caps)
=== mon.a ===
/usr/bin/ceph-mon: created monfs at /data/mon for mon.a
=== mon.b ===
pushing everything to s2
/usr/bin/ceph-mon: created monfs at /data/mon for mon.b
=== mon.c ===
pushing everything to s3
/usr/bin/ceph-mon: created monfs at /data/mon for mon.c
placing client.admin keyring in /etc/ceph/ceph.keyring

上面提示了没有配置journal。

root@s1:~# /etc/init.d/ceph -a start
=== mon.a ===
Starting Ceph mon.a on s1…already running
=== mds.a ===
Starting Ceph mds.a on s1…already running
=== osd.0 ===
Starting Ceph osd.0 on s1…
* WARNING: Ceph is still under development. Any feedback can be directed *
* at ceph-devel@vger.kernel.org or http://ceph.newdream.net/. *
starting osd.0 at 0.0.0.0:6801/2264 osd_data /data/osd.0 (no journal)

查看状态：
root@s1:~# ceph -s
2014-05-09 09:37:40.477978 pg v444: 594 pgs: 594 active+clean; 38199 bytes data, 531 MB used, 56869 MB / 60472 MB avail
2014-05-09 09:37:40.485092 mds e23: 1/1/1 up {0=a=up:active}, 2 up:standby
2014-05-09 09:37:40.485601 osd e34: 3 osds: 3 up, 3 in
2014-05-09 09:37:40.486276 log 2014-05-09 09:36:25.843782 mds.0 192.168.242.128:6800/1053 1 : [INF] closing stale session client.4104 192.168.242.131:0/2123448720 after 302.954724
2014-05-09 09:37:40.486577 mon e1: 3 mons at {a=192.168.242.128:6789/0,b=192.168.242.129:6789/0,c=192.168.242.130:6789/0}

root@s1:~# for i in 1 2 3 ;do ceph health;done
2014-05-09 10:05:30.306575 mon <- [health]
2014-05-09 10:05:30.309366 mon.1 -> ‘HEALTH_OK’ (0)
2014-05-09 10:05:30.330317 mon <- [health]
2014-05-09 10:05:30.333608 mon.2 -> ‘HEALTH_OK’ (0)
2014-05-09 10:05:30.352617 mon <- [health]
2014-05-09 10:05:30.353984 mon.0 -> ‘HEALTH_OK’ (0)
并同时查看 s1、s2、s3 log可以看到，证明3个节点都正常：
2014-05-09 09:39:32.316795 b4bfeb40 mon.a@0(leader) e1 handle_command mon_command(health v 0) v1
2014-05-09 09:39:40.789748 b4bfeb40 mon.a@0(leader).osd e35 e35: 3 osds: 3 up, 3 in
2014-05-09 09:40:00.796979 b4bfeb40 mon.a@0(leader).osd e36 e36: 3 osds: 3 up, 3 in
2014-05-09 09:40:41.781141 b4bfeb40 mon.a@0(leader) e1 handle_command mon_command(health v 0) v1
2014-05-09 09:40:42.409235 b4bfeb40 mon.a@0(leader) e1 handle_command mon_command(health v 0) v1
log 里面会看到如下时间未同步信息：
2014-05-09 09:43:13.485212 b49fcb40 log [WRN] : message from mon.0 was stamped 6.050738s in the future, clocks not synchronized
2014-05-09 09:43:13.861985 b49fcb40 log [WRN] : message from mon.0 was stamped 6.050886s in the future, clocks not synchronized
2014-05-09 09:43:14.012633 b49fcb40 log [WRN] : message from mon.0 was stamped 6.050681s in the future, clocks not synchronized
2014-05-09 09:43:15.809439 b49fcb40 log [WRN] : message from mon.0 was stamped 6.050781s in the future, clocks not synchronized
所以我们在做集群之前最好能在集群内部做好ntp服务器，确保各节点之前时间一致。

1. 接下来在客户机s4上进行验证操作：
   root@s4:/mnt# mount -t ceph s1:6789:/ /mnt/s1fs/
   root@s4:/mnt# mount -t ceph s2:6789:/ /mnt/s2fs/
   root@s4:/mnt# mount -t ceph s3:6789:/ /mnt/s3fs/
   root@s4:~# df -h
   Filesystem Size Used Avail Use% Mounted on
   /dev/sda1 79G 1.3G 74G 2% /
   udev 241M 4.0K 241M 1% /dev
   tmpfs 100M 304K 99M 1% /run
   none 5.0M 0 5.0M 0% /run/lock
   none 248M 0 248M 0% /run/shm
   192.168.242.130:6789:/ 60G 3.6G 56G 6% /mnt/s3fs
   192.168.242.129:6789:/ 60G 3.6G 56G 6% /mnt/s2fs
   192.168.242.128:6789:/ 60G 3.6G 56G 6% /mnt/s1fs

root@s4:/mnt/s2fs# touch aa
root@s4:/mnt/s2fs# ls -al /mnt/s1fs
total 4
drwxr-xr-x 1 root root 0 May 8 18:08 ./
drwxr-xr-x 7 root root 4096 May 8 17:28 ../
-rw-r–r– 1 root root 0 May 8 18:08 aa
root@s4:/mnt/s2fs# ls -al /mnt/s3fs
total 4
drwxr-xr-x 1 root root 0 May 8 18:08 ./
drwxr-xr-x 7 root root 4096 May 8 17:28 ../
-rw-r–r– 1 root root 0 May 8 18:08 aa

root@s4:/mnt/s2fs# rm -f aa
root@s4:/mnt/s2fs# ls -al /mnt/s1fs/
total 4
drwxr-xr-x 1 root root 0 May 8 2014 ./
drwxr-xr-x 7 root root 4096 May 8 17:28 ../
root@s4:/mnt/s2fs# ls -al /mnt/s3fs/
total 4
drwxr-xr-x 1 root root 0 May 8 18:07 ./
drwxr-xr-x 7 root root 4096 May 8 17:28 ../

接下来我们验证单点故障：
将s1服务停掉，
root@s1:~# /etc/init.d/ceph stop
=== mon.a ===
Stopping Ceph mon.a on s1…kill 965…done
=== mds.a ===
Stopping Ceph mds.a on s1…kill 1314…done
=== osd.0 ===
Stopping Ceph osd.0 on s1…kill 2265…done
s2上log 立马显示：
省掉了很多，基本的意思就是mon监控中心发现，剔除故障节点，进行自动切换，集群恢复。
2014-05-09 10:16:44.906370 a5af0b40 — 192.168.242.129:6802/1495 >> 192.168.242.128:6802/1466 pipe(0xb1e1b1a8 sd=19 pgs=3 cs=3 l=0).fault with nothing to send, going to standby
2014-05-09 10:16:44.906982 a68feb40 — 192.168.242.129:6803/1495 >> 192.168.242.128:0/1467 pipe(0xa6e00d50 sd=17 pgs=1 cs=1 l=0).fault with nothing to send, going to standby
2014-05-09 10:16:44.907415 a63f9b40 — 192.168.242.129:0/1506 >> 192.168.242.128:6803/1466 pipe(0xb1e26d50 sd=20 pgs=1 cs=1 l=0).fault with nothing to send, going to standby
2014-05-09 10:16:49.028640 b5199b40 mds.0.6 handle_mds_map i am now mds.0.6
2014-05-09 10:16:49.029018 b5199b40 mds.0.6 handle_mds_map state change up:reconnect –> up:rejoin
2014-05-09 10:16:49.029260 b5199b40 mds.0.6 rejoin_joint_start
2014-05-09 10:16:49.032134 b5199b40 mds.0.6 rejoin_done
==> /var/log/ceph/mon.b.log <==
2014-05-09 10:16:49.060870 b5198b40 log [INF] : mds.0 192.168.242.129:6804/1341 up:active
==> /var/log/ceph/mds.b.log <==
2014-05-09 10:16:49.073135 b5199b40 mds.0.6 handle_mds_map i am now mds.0.6
2014-05-09 10:16:49.073237 b5199b40 mds.0.6 handle_mds_map state change up:rejoin –> up:active
2014-05-09 10:16:49.073252 b5199b40 mds.0.6 recovery_done — successful recovery!
2014-05-09 10:16:49.073871 b5199b40 mds.0.6 active_start
2014-05-09 10:16:49.073934 b5199b40 mds.0.6 cluster recovered.
==> /var/log/ceph/mds.b.log <==
2014-05-09 10:16:49.073135 b5199b40 mds.0.6 handle_mds_map i am now mds.0.6
2014-05-09 10:16:49.073237 b5199b40 mds.0.6 handle_mds_map state change up:rejoin –> up:active
2014-05-09 10:16:49.073252 b5199b40 mds.0.6 recovery_done — successful recovery!
2014-05-09 10:16:49.073871 b5199b40 mds.0.6 active_start
2014-05-09 10:16:49.073934 b5199b40 mds.0.6 cluster recovered.
==> /var/log/ceph/mon.b.log <==
2014-05-09 10:18:24.366217 b5198b40 mon.b@1(leader) e1 handle_command mon_command(health v 0) v1
2014-05-09 10:18:25.717589 b5198b40 mon.b@1(leader) e1 handle_command mon_command(health v 0) v1
2014-05-09 10:18:29.481811 b5198b40 mon.b@1(leader) e1 handle_command mon_command(health v 0) v1
2014-05-09 10:21:39.184889 b4997b40 log [INF] : osd.0 out (down for 303.572445)
2014-05-09 10:21:39.195596 b5198b40 mon.b@1(leader).osd e42 e42: 3 osds: 2 up, 2 in
2014-05-09 10:21:40.199772 b5198b40 mon.b@1(leader).osd e43 e43: 3 osds: 2 up, 2 in
root@s2:~# ceph -s
2014-05-09 10:24:18.075291 pg v501: 594 pgs: 594 active+clean; 47294 bytes data, 359 MB used, 37907 MB / 40315 MB avail
2014-05-09 10:24:18.093637 mds e27: 1/1/1 up {0=b=up:active}, 1 up:standby
2014-05-09 10:24:18.094047 osd e43: 3 osds: 2 up, 2 in
2014-05-09 10:24:18.094833 log 2014-05-09 10:21:39.185547 mon.1 192.168.242.129:6789/0 40 : [INF] osd.0 out (down for 303.572445)
2014-05-09 10:24:18.095606 mon e1: 3 mons at {a=192.168.242.128:6789/0,b=192.168.242.129:6789/0,c=192.168.242.130:6789/0}
root@s1:~# ceph health
2014-05-09 10:18:43.185714 mon <- [health]
2014-05-09 10:18:43.189028 mon.2 -> ‘HEALTH_WARN 1/3 in osds are down; 1 mons down, quorum 1,2′ (0)
root@s2:~# ceph health
2014-05-09 10:23:40.655548 mon <- [health]
2014-05-09 10:23:40.658293 mon.2 -> ‘HEALTH_WARN 1 mons down, quorum 1,2′ (0)
root@s3:~# ceph health
2014-05-09 10:23:28.058080 mon <- [health]
2014-05-09 10:23:28.061126 mon.1 -> ‘HEALTH_WARN 1 mons down, quorum 1,2′ (0)

再接下来，关闭s2，只开启s3：
s3上log显示大量
==> /var/log/ceph/mds.c.log <==
2014-05-09 10:33:04.274503 b5180b40 mds.-1.0 ms_handle_connect on 192.168.242.130:6789/0

==> /var/log/ceph/osd.2.log <==
2014-05-09 10:33:04.832597 b4178b40 osd.2 43 heartbeat_check: no heartbeat from osd.1 since 2014-05-09 10:29:54.607954 (cutoff 2014-05-09 10:32:44.832568)
2014-05-09 10:33:05.084620 a7be9b40 osd.2 43 heartbeat_check: no heartbeat from osd.1 since 2014-05-09 10:29:54.607954 (cutoff 2014-05-09 10:32:45.084592)
2014-05-09 10:33:05.585583 a7be9b40 osd.2 43 heartbeat_check: no heartbeat from osd.1 since 2014-05-09 10:29:54.607954 (cutoff 2014-05-09 10:32:45.585553)
2014-05-09 10:33:05.834589 b4178b40 osd.2 43 heartbeat_check: no heartbeat from osd.1 since 2014-05-09 10:29:54.607954 (cutoff 2014-05-09 10:32:45.834559)
2014-05-09 10:33:06.086562 a7be9b40 osd.2 43 heartbeat_check: no heartbeat from osd.1 since 2014-05-09 10:29:54.607954 (cutoff 2014-05-09 10:32:46.086533)
2014-05-09 10:33:06.835683 b4178b40 osd.2 43 heartbeat_check: no heartbeat from osd.1 since 2014-05-09 10:29:54.607954 (cutoff 2014-05-09 10:32:46.835641)
2014-05-09 10:33:07.287766 a7be9b40 osd.2 43 heartbeat_check: no heartbeat from osd.1 since 2014-05-09 10:29:54.607954 (cutoff 2014-05-09 10:32:47.287737)
健康检测不能从s2上的osd.1 获取no heartbeat 。
s1、s2、s3上都有mon、mds、osd。但是总个集群中只有一个节点，所以不能提供服务。