1、简介 Ceph 存储集群至少需要 1 个 Ceph Monitor 和 2 个 OSD 守护进程 运行 Ceph 文件系统客户端时，则必须要有元数据服务器（ Metadata Server ）。 Ceph OSDs: Ceph OSD 守护进程 （ Ceph OSD ）的功能：存储数据，处理数据的复 制、恢复、回填、再均衡，并通过检查其他 OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有 2 个副本时，至少需要 2 个 OSD 守 护进程，集群才能达到 active+clean 状态（ Ceph 默认有 3 个副本，但你可以调 整副本数）
2、。 Monitors: Ceph Monitor 维护着展示集群状态的各种图表，包括监视器映射、 OSD 映射、归置组（ PG ）映射、和 CRUSH 映射。 Ceph 保存着发生在 Monitors 、 OSD 和 PG 上的每一次状态变更的历史信息（称为 epoch ）。 MDSs: Ceph 元数据服务器 （ MDS ）为 Ceph 文件系统 存储元数据（也就是说， Ceph 块设备和 Ceph 对象存储不使用 MDS ）。元数据服务器使得 POSIX 文件系统 的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基 本命令。 Ceph 把客户端数据保存
3、为存储池内的对象。通过使用 CRUSH 算法， Ceph 可以计算出哪个 归置组（PG ）应该持有指定的对象(Object)，然后进一步计算出哪个 OSD 守护进程持有该归 置组。 CRUSH 算法使得 Ceph 存储集群能够动态地伸缩、再均衡和修复。 硬件推荐 Ceph 为普通硬件设计，这可使构建、维护 PB 级数据集群的费用相对低廉。规划集群硬件时， 需要均衡几方面的因素，包括区域失效和潜在的性能问题。硬件规划要包含把使用 Ceph 集群 的 Ceph 守护进程和其他进程恰当分布。通常，我们推荐在一台机器上只运行一种类型的守护 进程。我们推荐把使用数据集群的进程（如 OpenStack 、
4、 CloudStack 等）安装在别的机器 上。 Tip 关于 Ceph 的高品质博客文章也值得参考，比如 Ceph Write Throughput 1 、 Ceph Write Throughput 2 、 Argonaut v. Bobtail Performance Preview 、 Bobtail Performance - I/O Scheduler Comparison 。 CPU Ceph （MDS）元数据服务器对 CPU 敏感，它会动态地重分布它们的负载，所以你的元数据服 务器应该有足够的处理能力（如 4 核或更强悍的 CPU ）。 Ceph 的 OSD 运行着 RADOS
5、 服 务、用 CRUSH 计算数据存放位置、复制数据、维护它自己的集群运行图副本，因此 OSD 需 要一定的处理能力（如双核 CPU ）。监视器只简单地维护着集群运行图的副本，因此对 CPU 不敏感；但必须考虑机器以后是否还会运行 Ceph 监视器以外的 CPU 密集型任务。例如，如 果服务器以后要运行用于计算的虚拟机（如 OpenStack Nova ），你就要确保给 Ceph 进程保 留了足够的处理能力，所以我们推荐在其他机器上运行 CPU 密集型任务。 RAM 内存 元数据服务器和监视器必须可以尽快地提供它们的数据，所以他们应该有足够的内存，至少每 进程 1GB 。 OSD 的日常运行不
6、需要那么多内存（如每进程 500MB ）差不多了；然而在恢复 期间它们占用内存比较大（如每进程每 TB 数据需要约 1GB 内存）。通常内存越多越好。 数据存储 要谨慎地规划数据存储配置，因为其间涉及明显的成本和性能折衷。来自操作系统的并行操作 和到单个硬盘的多个守护进程并发读、写请求操作会极大地降低性能。文件系统局限性也要考 虑： btrfs 尚未稳定到可以用于生产环境的程度，但它可以同时记日志并写入数据，而 xfs 和 ext4 却不能。 Important 因为 Ceph 发送 ACK 前必须把所有数据写入日志（至少对 xfs 和 ext4 来说是），因此均衡日 志和 OSD 性能相当重
7、要。 硬 盘驱动 器 OSD 应该有足够的空间用于存储对象数据。考虑到大硬盘的每 GB 成本，我们建议用容量大 于 1TB 的硬盘。建议用 GB 数除以硬盘价格来计算每 GB 成本，因为较大的硬盘通常会对每 GB 成本有较大影响，例如，单价为 $75 的 1TB 硬盘其每 GB 价格为 $0.07 （ $75/1024=0.0732 ），又如单价为 $150 的 3TB 硬盘其每 GB 价格为 $0.05 （ $150/3072=0.0488 ），这样使用 1TB 硬盘会增加 40% 的每 GB 价格，它将表现为较低的经 济性。另外，单个驱动器容量越大，其对应的 OSD 所需内存就越大，特别是
8、在重均衡、回填、 恢复期间。根据经验， 1TB 的存储空间大约需要 1GB 内存。 Tip 不顾分区而在单个硬盘上运行多个 OSD，这样不明智！ Tip 不顾分区而在运行了 OSD 的硬盘上同时运行监视器或元数据服务器也 不明智！ 存储驱动器受限于寻道时间、访问时间、读写时间、还有总吞吐量，这些物理局限性影响着整 体系统性能，尤其在系统恢复期间。因此我们推荐独立的驱动器用于安装操作系统和软件，另 外每个 OSD 守护进程占用一个驱动器。大多数 “slow OSD”问题的起因都是在相同的硬盘上运 行了操作系统、多个 OSD 、和/ 或多个日志文件。鉴于解决性能问题的成本差不多会超过另外 增加磁盘
9、驱动器，你应该在设计时就避免增加 OSD 存储驱动器的负担来提升性能。 Ceph 允许你在每块硬盘驱动器上运行多个 OSD ，但这会导致资源竞争并降低总体吞吐量； Ceph 也允许把日志和对象数据存储在相同驱动器上，但这会增加记录写日志并回应客户端的 延时，因为 Ceph 必须先写入日志才会回应确认了写动作。 btrfs 文件系统能同时写入日志数 据和对象数据， xfs 和 ext4 却不能。 Ceph 最佳实践指示，你应该分别在单独的硬盘运行操作系统、 OSD 数据和 OSD 日志。 固 态 硬 盘 一种提升性能的方法是使用固态硬盘（ SSD ）来降低随机访问时间和读延时，同时增加吞吐 量。
10、 SSD 和硬盘相比每 GB 成本通常要高 10 倍以上，但访问时间至少比硬盘快 100 倍。 SSD 没有可移动机械部件，所以不存在和硬盘一样的局限性。但 SSD 也有局限性，评估 SSD 时，顺序读写性能很重要，在为多个 OSD 存储日志时，有着 400MB/s 顺序读写吞吐量 的 SSD 其性能远高于 120MB/s 的。 Important 我们建议发掘 SSD 的用法来提升性能。然而在大量投入 SSD 前，我们强烈建议核实 SSD 的 性能指标，并在测试环境下衡量性能。 正因为 SSD 没有移动机械部件，所以它很适合 Ceph 里不需要太多存储空间的地方。相对廉 价的 SSD 很诱人
11、，慎用！可接受的 IOPS 指标对选择用于 Ceph 的 SSD 还不够，用于日志和 SSD 时还有几个重要考量： 写密集语义： 记日志涉及写密集 语义，所以你要确保 选用的 SSD 写入性能和硬盘相当 或好于硬盘。廉价 SSD 可能在加速访问的同时引入写延时，有时候高性能硬盘的写入 速度可以和便宜 SSD 相媲美 。 顺序写入： 在一个 SSD 上为多个 OSD 存储多个日志 时也必须考虑 SSD 的顺序写入 极限，因为它们要同时处理多个 OSD 日志的写入请求。 分区对齐： 采用了 SSD 的一个常见问题是人们喜欢分区，却常常忽略了分区对齐，这 会导致 SSD 的数据 传输速率慢很多，所以
12、请确保分区对齐了。 SSD 用于对象存储太昂贵了，但是把 OSD 的日志存到 SSD 、把对象数据存储到独立的硬盘 可以明显提升性能。 osd journal 选项的默认值是/var/lib/ceph/osd/$cluster-$id/journal ，你 可以把它挂载到一个 SSD 或 SSD 分区，这样它就不再是和对象数据一样存储在同一个硬盘 上的文件了。 提升 CephFS 文件系统性能的一种方法是从 CephFS 文件内容里分离出元数据。 Ceph 提供 了默认的 metadata 存储池来存储 CephFS 元数据，所以你不需要给 CephFS 元数据创建存储 池，但可以给它创建一个
13、仅指向某主机 SSD 的 CRUSH 运行图。详见 给存储池指定 OSD 。 控制 器 硬盘控制器对写吞吐量也有显著影响，要谨慎地选择，以免产生性能瓶颈。 Tip Ceph blog 通常是优秀的 Ceph 性能问题来源，见 Ceph Write Throughput 1 和 Ceph Write Throughput 2 。 其他注意事 项 你可以在同一主机上运行多个 OSD ，但要确保 OSD 硬盘总吞吐量不超过为客户端提供读写 服务所需的网络带宽；还要考虑集群在每台主机上所存储的数据占总体的百分比，如果一台主 机所占百分比太大而它挂了，就可能导致诸如超过 full ratio 的问题，此
14、问题会使 Ceph 中止 运作以防数据丢失。 如果每台主机运行多个 OSD ，也得保证内核是最新的。参阅操作系统推荐里关于 glibc 和 syncfs(2) 的部分，确保硬件性能可达期望值。 OSD 数量较多（如 20 个以上）的主机会派生出大量线程，尤其是在恢复和重均衡期间。很多 Linux 内核默认的最大线程数较小（如 32k 个），如果您遇到了这类问题，可以把 kernel.pid_max 值调高些。理论最大值是 4194303 。例如把下列这行加入 /etc/sysctl.conf 文 件： kernel.pid_max = 4194303 网络 建议每台机器最少两个千兆网卡，现在大
15、多数机械硬盘都能达到大概 100MB/s 的吞吐量，网 卡应该能处理所有 OSD 硬盘总吞吐量，所以推荐最少两个千兆网卡，分别用于公网（前端） 和集群网络（后端）。集群网络（最好别连接到国际互联网）用于处理由数据复制产生的额外 负载，而且可防止拒绝服务攻击，拒绝服务攻击会干扰数据归置组，使之在 OSD 数据复制时 不能回到 active + clean 状态。 请考虑部署万兆网卡。通过 1Gbps 网络复制 1TB 数据耗时 3 小时，而 3TB （典型配置）需要 9 小时，相比之下，如果使用 10Gbps 复制时间可分别缩减 到 20 分钟和 1 小时。在一个 PB 级集群中， OSD 磁盘
16、失败是常态，而非异常；在性价比合 理的的前提下，系统管理员想让 PG 尽快从 degraded （降级）状态恢复到 active + clean 状 态。另外，一些部署工具（如 Dell 的 Crowbar ）部署了 5 个不同的网络，但使用了 VLAN 以 提高网络和硬件可管理性。 VLAN 使用 802.1q 协议，还需要采用支持 VLAN 功能的网卡和交 换机，增加的硬件成本可用节省的运营（网络安装、维护）成本抵消。使用 VLAN 来处理集 群和计算栈（如 OpenStack 、 CloudStack 等等）之间的 VM 流量时，采用 10G 网卡仍然值 得。每个网络的机架路由器到核心路
17、由器应该有更大的带宽，如 40Gbps 到 100Gbps 。 服务器应配置底板管理控制器（ Baseboard Management Controller, BMC ），管理和部署工 具也应该大规模使用 BMC ， 所以请考虑带外网络管理的成本/ 效益平衡，此程序管理着 SSH 访问、 VM 映像上传、操作系统安装、端口管理、等等，会徒增网络负载。运营 3 个网络有 点过分，但是每条流量路径都指示了部署一个大型数据集群前要仔细考虑的潜能力、吞吐量、 性能瓶颈。 故障域 故障域指任何导致不能访问一个或多个 OSD 的故障，可以是主机上停止的进程、硬盘故障、 操作系统崩溃、有问题的网卡、损坏的电
18、源、断网、断电等等。规划硬件需求时，要在多个需 求间寻求平衡点，像付出很多努力减少故障域带来的成本削减、隔离每个潜在故障域增加的成 本。 最低硬件推荐 Ceph 可以运行在廉价的普通硬件上，小型生产集群和开发集群可以在一般的硬件上。 进程 条件 最低建议 Processor 1x 64-bit AMD-64 1x 32-bit ARM dual-core or better 1x i386 dual-core RAM 1GB for 1TB of storage per daemon Volume Storage 1x storage drive per daemon Journal 1x S
19、SD partition per daemon (optional) ceph-osd Network 2x 1GB Ethernet NICs Processor 1x 64-bit AMD-64/i386 1x 32-bit ARM dual-core or better 1x i386 dual-core RAM 1 GB per daemon Disk Space 10 GB per daemon ceph-mon Network 2x 1GB Ethernet NICs Processor 1x 64-bit AMD-64 quad-core 1x 32-bit ARM quad-c
20、ore 1x i386 quad-core RAM 1 GB minimum per daemon Disk Space 1 MB per daemon ceph-mds Network 2x 1GB Ethernet NICs Tip 如果在只有一块硬盘的机器上运行 OSD ，要把数据和操作系统分别放到不同分区；一般来说， 我们推荐操作系统和数据分别使用不同的硬盘。 生产集群实例 PB 级生产集群也可以使用普通硬件，但应该配备更多内存、 CPU 和数据存储空间来解决流 量压力。 DELL 实 例 一个最新（ 2012 ）的 Ceph 集群项目使用了 2 个相当强悍的 OSD 硬件配置，和稍逊
21、的监视 器配置。 Configuration Criteria Minimum Recommended Processor 2x 64-bit quad-core Xeon CPUs RAM 16 GB Volume Storage 8x 2TB drives. 1 OS, 7 Storage Client Network 2x 1GB Ethernet NICs OSD Network 2x 1GB Ethernet NICs Dell PE R510 Mgmt. Network 2x 1GB Ethernet NICs Processor 1x hex-core Opteron CPU D
22、ell PE R515 RAM 16 GB Configuration Criteria Minimum Recommended Volume Storage 12x 3TB drives. Storage OS Storage 1x 500GB drive. Operating System. Client Network 2x 1GB Ethernet NICs OSD Network 2x 1GB Ethernet NICs Mgmt. Network 2x 1GB Ethernet NICs 推荐操作系统 CEPH 依 赖 按常规来说，我们建议在较新的 Linux 发行版上部署 Cep
23、h ；同样，要选择长期支持的版本。 LINUX 内 核 Ceph 内核态客户端 当前我们推荐： o 4.1.4 or later o 3.16.3 or later (rbd deadlock regression in 3.16.0-2) o NOT v3.15.* (rbd deadlock regression) o 3.14.* 如果您坚持用很旧的，可以考虑这些： o 3.10.* firefly (CRUSH_TUNABLES3) 这个版本的可调选项到 3.15 版才开始支持。详情见 CRUSH 可调值 。 B-tree 文件系 统（Btrfs） 如果您想在 btrfs 上运行 Ce
24、ph ，我们推荐使用一个最新的 Linux 内核（ 3.14 或更 新）。 系统平台 下面的表格展示了 Ceph 需求和各种 Linux 发行版的对应关系。一般来说， Ceph 对内核和系 统初始化阶段的依赖很少（如 sysvinit 、 upstart 、 systemd ）。 INFERNALIS (9.1.0) Distro Release Code Name Kernel Notes Testing CentOS 7 N/A linux-3.10.0 B, I, C Debian 8.0 Jessie linux-3.16.0 1, 2 B, I Fedora 22 N/A linux
25、-3.14.0 B, I RHEL 7 Maipo linux-3.10.0 B, I Ubuntu 14.04 Trusty Tahr linux-3.13.0 B, I, C HAMMER (0.94) Distro Release Code Name Kernel Notes Testing Distro Release Code Name Kernel Notes Testing CentOS 6 N/A linux-2.6.32 1, 2 CentOS 7 N/A linux-3.10.0 B, I, C Debian 7.0 Wheezy linux-3.2.0 1, 2 Ubun
26、tu 12.04 Precise Pangolin linux-3.2.0 1, 2 Ubuntu 14.04 Trusty Tahr linux-3.13.0 B, I, C FIREFLY (0.80) Distro Release Code Name Kernel Notes Testing CentOS 6 N/A linux-2.6.32 1, 2 B, I CentOS 7 N/A linux-3.10.0 B Debian 6.0 Squeeze linux-2.6.32 1, 2, 3 B Debian 7.0 Wheezy linux-3.2.0 1, 2 B Fedora
27、19 Schrdingers Cat linux-3.10.0 B Distro Release Code Name Kernel Notes Testing Fedora 20 Heisenbug linux-3.14.0 B RHEL 6 Santiago linux-2.6.32 1, 2 B, I, C RHEL 7 Maipo linux-3.10.0 B, I, C Ubuntu 12.04 Precise Pangolin linux-3.2.0 1, 2 B, I, C Ubuntu 14.04 Trusty Tahr linux-3.13.0 B, I, C 附 注 1: 默
28、认内核 btrfs 版本较老，不推荐用于 ceph-osd 存储节点；要升级到推荐的内 核，或者改用 xfs 、 ext4 。 2: 默认内核 带的 Ceph 客户端较老，不推荐做内核空间客户端（内核 RBD 或 Ceph 文 件系统），请升级到推荐内核。 3: 默认内核或已安装的 glibc 版本若不支持 syncfs(2) 系统调用，同一台机器上 使用 xfs 或 ext4 的 ceph-osd 守护进程性能不会如愿。 测试 版 B: 我们会为此平台构建发 布包。 对其中的某些平台，可能也会持续地编译所有分支、做 基本单元测试。 I: 我们在这个平台上做基本的安装和功能测试。 C: 我们在
29、这个平台上持续 地做全面的功能、退化、压力测试，包括开发分支、 预发布版 本、正式发布版本。 安装（快速） 预检 New in version 0.60. 我们建议安装一个 ceph-deploy 管理 节点 和一个三节点的 Ceph 存储集群 来研究 Ceph 的 基本特性。这篇预检会帮你准备一个 ceph-deploy 管理节点、以及三个 Ceph 节点（或虚 拟机），以此构成 Ceph 存储集群。在进行下一步之前，请参见操作系统推荐以确认你安装了 合适的 Linux 发行版。如果你在整个生产集群中只部署了单一 Linux 发行版的同一版本，那么 在排查生产环境中遇到的问题时就会容易一点。
30、 在下面的描述中 节点 代表一台机器。 安装 CEPH 部署工具 把 Ceph 仓库添加到 ceph-deploy 管理节点，然后安装 ceph-deploy 。 高 级 包管理工具（ APT） 在 Debian 和 Ubuntu 发行版上，执行下列步骤： 1. 添加 release key ： wget -q -O- | sudo apt-key add - 2. 添加 Ceph 软件包源，用 Ceph 稳定版（如 cuttlefish 、 dumpling 、 emperor 、 firefly 等等）替换掉 ceph- stable-release 。例如： echo deb stabl
31、e-release/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list 3. 更新你的仓库，并安装 ceph-deploy ： sudo apt-get update make install 安装 LIBVIRT To use libvirt with Ceph, you must have a running Ceph Storage Cluster, and you must have installed and configured QEMU. See Using libvirt with Ceph
32、 Block Device for usage. DEBIAN 软件包 libvirt 软件包从 Ubuntu 12.04 Precise Pangolin 起就被并入了 Ubuntu 官方库。要在这些 发行版上安装 libvirt ，可用下面的命令： sudo apt-get update 192 pgs stuck unclean; no osds monmap e1: 1 mons at node1=192.168.0.1:6789/0, election epoch 1, quorum 0 node1 osdmap e1: 0 osds: 0 up, 0 in pgmap v2: 19
33、2 pgs, 3 pools, 0 bytes data, 0 objects 0 kB used, 0 kB / 0 kB avail 192 creating 注意： 一旦你添加了 OSD 并启动，归置组健康错误应该消失，详情见下一节。 添加 OSD 你的初始监视器可以正常运行后就可以添加 OSD 了。要想让集群达到 active + clean 状态，必须安装足够多的 OSD 来处理对象副本（如 osd pooldefault size = 2 需 要至少 2 个 OSD ）。在完成监视器自举引导后，集群就有了默认的 CRUSH 图，但现在此图 还是空的，里面没有任何 OSD 映射到 C
34、eph 节点。 精简型 Ceph 软件包提供了 ceph-disk 工具，用于准备硬盘：可以是分区或用于 Ceph 的目录。 ceph-disk 可通过递增索引来创建 OSD ID ；还能把 OSD 加入 CRUSH 图。 ceph- disk 的详细用法可参考 ceph-disk -h ，此工具把后面将提到的精简型里面的步骤都自 动化了。为按照精简型创建前两个 OSD ，在 node2 和 node3 上执行下列命令： 1. 准备 OSD。 2. ssh node-name sudo ceph-disk prepare -cluster cluster-name - cluster-uuid
35、 uuid -fs-type ext4|xfs|btrfs data-path journal-path 例如： ssh node1 sudo ceph-disk prepare -cluster ceph -cluster-uuid a7f64266-0894-4f1e-a635-d0aeaca0e993 -fs-type ext4 /dev/hdd1 3. 激活 OSD： sudo ceph-disk activate data-path -activate-key path 例如： sudo ceph-disk activate /dev/hdd1 注： 如果你的 Ceph 节点上没有
36、/var/lib/ceph/bootstrap- osd/cluster.keyring ，那么应该外加 -activate-key 参数。 细致型 要是不想借助任何辅助工具，可按下列步骤创建 OSD 、将之加入集群和 CRUSH 图。按下列 详细步骤可在 node2 和 node3 上增加前 2 个 OSD ： 1. 登录到 OSD 主机。 ssh node-name 2. 给 OSD 分配 UUID 。 3. uuidgen 4. 创建 OSD 。如果没有指定 UUID ，将会在 OSD 首次启动时分配一个。下列命令执行 完成后将输出 OSD 号，在后续步骤里还会用到这个号。 ceph o
37、sd create uuid id 5. 在新 OSD 主机上创建默认目录。 6. ssh new-osd-host sudo mkdir /var/lib/ceph/osd/cluster-name-osd- number 7. 如果要把 OSD 装到非系统盘的独立硬盘上，先创建文件系统、然后挂载到刚创建的 目录下： 8. ssh new-osd-host 9. sudo mkfs -t fstype /dev/hdd sudo mount -o user_xattr /dev/hdd /var/lib/ceph/osd/cluster-name-osd-number 10. 初始化 OSD
38、 数据目录： 11. ssh new-osd-host sudo ceph-osd -i osd-num -mkfs -mkkey -osd-uuid uuid 加 -mkkey 选项运行 ceph-osd 之前，此目录必须是空的；另外，如果集群名字 不是默认值，还要给 ceph-osd 指定 -cluster 选项。 12. 注册此 OSD 的密钥。路径内 ceph-osd-num 里的 ceph 其含义为 $cluster-$id ，如果你的集群名字不是 ceph ，请指定自己的集群名： sudo ceph auth add osd.osd-num osd allow * mon allo
39、w profile osd -i /var/lib/ceph/osd/cluster- name-osd-num/keyring 13. 把此节点加入 CRUSH 图。 ceph -cluster cluster-name osd crush add-bucket hostname host 例如： ceph osd crush add-bucket node1 host 14. 把此 Ceph 节点放入 default 根下。 ceph osd crush move node1 root=default 15. 把此 OSD 加入 CRUSH 图之后，它就能接收数据了。你也可以反编译 CRU
40、SH 图、 把此 OSD 加入设备列表、对应主机作为桶加入（如果它还不在 CRUSH 图里）、然 后此设备作为主机的一个条目、分配权重、重新编译、注入集群。 ceph -cluster cluster-name osd crush add id- or-name weight bucket-type=bucket-name . 例如： ceph osd crush add osd.0 1.0 host=node1 16. 把 OSD 加入 Ceph 后， OSD 已经在配置里了。但它还没开始运行，这时处于 down 且 in 状态，要启动进程才能收数据。 在 Ubuntu 系统上用 Upsta
41、rt 启动： sudo start ceph-osd id=osd-num cluster=cluster- name 例如： sudo start ceph-osd id=0 sudo start ceph-osd id=1 在 Debian/CentOS/RHEL 上用 sysvinit 启动： sudo /etc/init.d/ceph start osd.osd-num -cluster cluster-name 例如： sudo /etc/init.d/ceph start osd.0 sudo /etc/init.d/ceph start osd.1 要让守护进程开机自启，必须创建
42、一个空文件： sudo touch /var/lib/ceph/osd/cluster-name-osd- num/sysvinit 例如： sudo touch /var/lib/ceph/osd/ceph-0/sysvinit sudo touch /var/lib/ceph/osd/ceph-1/sysvinit OSD 启动后，它应该处于 up 且 in 状态。 总 结 监视器和两个 OSD 开始正常运行后，你就可以通过下列命令观察归置组互联过程了： ceph -w 执行下列命令查看 OSD 树： ceph osd tree 你应该会看到类似如下的输出： # id weight typ
43、e name up/down reweight -1 2 root default -2 2 host node1 0 1 osd.0 up 1 -3 1 host node2 1 1 osd.1 up 1 要增加（或删除）额外监视器，参见 增加/删除监视器。要增加（或删除）额外 OSD ，参见增 加/删除 OSD 。 升级软件 随着新版 Ceph 的发布，你也许想升级集群以使用新功能，升级集群前请参考升级文档。有时 候，升级 Ceph 需要严格按照升级顺序进行。 升级 Ceph o 概述 o ceph-deploy 工具 o Argonaut 到 Bobtail o Argonaut 到 C
44、uttlefish o Bobtail 到 Cuttlefish o Cuttlefish 到 Dumpling o Dumpling 到 Emperor o Dumpling 到 Firefly o Emperor 到 Firefly o 升级过程 o 迁移到 ceph-deploy 升级 CEPH Ceph 的各个版本都可能有特定的步骤，升级前请参考与此版本相关的章节和发布说明文档， 以确定有哪些特定于此版本的步骤。 概 述 你可以在 Ceph 集群在线且提供服务时升级守护进程！某些类型的守护进程依赖其他的，如 Ceph 元数据服务器和 Ceph 对象网关依赖于 Ceph 监视器和 OSD
45、 守护进程，所以我们建议 按以下顺序升级： 1. ceph-deploy 工具 2. Ceph 监视器 3. Ceph OSD 守护进程 4. Ceph 元数据服务器 5. Ceph 对象网关 作为普适规则，我们建议一次升级一类的所有守护进程（如所有 ceph-osd 、所有 ceph- mon 等），这样才能确保它们属于同一版本。 升级过程相对简单，只要参照此版本特定的章节即可。基本过程有三个： 1. 用 ceph-deploy 为各主机升级软件包（用 ceph-deploy install 命令）， 或者分别登录各主机手动升级。例如，升级监视器时， ceph-deploy 语法大致如 此：
46、 2. ceph-deploy install -release release-name ceph- node1 ceph-node2 ceph-deploy install -release firefly mon1 mon2 mon3 注： ceph-deploy install 命令会把指定节点上的旧版本升级为你所指定的版 本，没有 ceph-deploy upgrade 这样的升级命令。 3. 登录各节点并重启各相关 Ceph 守护进程，详情参见操纵集群 。 4. 确认集群健康状况，详情见监控集群。 Important 一旦升级完，就不能降级了。 CEPH-DEPLOY 工 具 升级
47、 Ceph 守护进程前，应该先升级 ceph-deploy 工具。 sudo pip install -U ceph-deploy 或者： sudo apt-get install ceph-deploy 或者： sudo yum install ceph-deploy python-pushy ARGONAUT 到 BOBTAIL 从 Argonaut 升级到 Bobtail 时，你得注意几件事： 1. 现在认证默认是启用的，而以前是 禁用的； 2. 监视器间使用新的通讯协议； 3. 通过 RBD 使用 format2 格式的映像前要完成所有 OSD 的升级。 确保你先更新软件库路径，如：
48、sudo rm /etc/apt/sources.list.d/ceph.list echo deb $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list 详情见如下几段。 认证 Bobtail 版默认启用了认证，而且预置了粒度更细的认证配置选项。在先前的版本（即 v0.55 和更早的）中你可以简单地写： auth supported = cephx | none 此选项仍然能被识别，但已经过时。新版支持 cluster 、 service 、和 client 认证选 项，如下： auth cluster re
49、quired = cephx | none # default cephx auth service required = cephx | none # default cephx auth client required = cephx | none # default cephx,none Important 如果你现在的集群没有用 auth supported 这一行启用认证，那你升级到 Bobtail 时必须 显式地关闭： auth cluster required = none auth service required = none 这样集群认证将被关闭，但客户端默认行为未更改，它仍可以与启用了认证、但不强求的集群 通讯。 Importan
