长时间以来，为了使Ceph易于安装和管理，社区出现了各种各样的Ceph部署工具。这些工具大多数都利用了Ansible，Puppet和Salt等现有的自动化工具，因为他们带来了现有的用户管理生态，并且与其保持一致。但结果是，Ceph社区的精力被分散在许多额外的工作上。新用户在入门时面临着艰难的工具选择，而且当用户试图简化这些工具并且与Ceph自身集成也是非常困难的。

Cephadm

Cephadm的目标是提供一个功能齐全、健壮且维护良好的安装和管理层，可供不在Kubernetes中运行Ceph的任何环境使用。具体特性如下：

• 将所有组件部署在容器中。 使用容器简化了不同发行版之间的依赖关系和打包复杂度。当然，我们仍在构建RPM和Deb软件包，但是随着越来越多的用户过渡到cephadm（或Rook）并构建容器，我们看到的特定于操作系统的bug就越少。

• 与Orchestrator API紧密集成。 Ceph的Orchestrator界面在cephadm的开发过程中得到了广泛的发展，以匹配实现并清晰地抽象出Rook中存在的（略有不同）功能。最终结果是不管是看起来还是感觉都像Ceph的一部分。

• 不依赖管理工具。 Salt和Ansible之类的工具在大型环境中进行大规模部署时非常出色，但是使Ceph依赖于这种工具意味着用户还需要学习该相关的软件。更重要的是，与专为管理Ceph而专门设计的部署工具相比，依赖这些工具（Salt和Ansible等）的部署最终可能变得更加复杂，难以调试并且（最显着）更慢。

• 最小的操作系统依赖性。 Cephadm需要Python 3，LVM和container runtime（Podman或Docker）。任何当前的Linux发行版都可以。

• 将群集彼此隔离。 支持多个Ceph集群同时存在于同一主机上一直是一个比较小众的场景，但是确实存在，并且以一种健壮，通用的方式将集群彼此隔离，这使得测试和重新部署集群对于开发人员和用户而言都是安全自然的过程。

• 自动升级。 一旦Ceph“拥有”自己的部署方式，它就可以以安全和自动化的方式[升级Ceph。

• 从“传统”部署工具轻松迁移。 我们需要从现有工具（例如ceph-ansible，ceph-deploy和DeepSea）中现有的Ceph部署轻松过渡到cephadm。

所有这一切的目的是将Ceph开发人员和用户社区的注意力集中在仅这两个平台上：cephadm用于“裸机”部署，Rook用于在Kubernetes环境中运行Ceph，并为这两个平台提供类似的管理体验。

Bootstrap

cephadm模型有一个简单的“ Bootstrap ”步骤，该步骤从命令行启动，该命令行在本地主机上启动一个最小的Ceph群集（一个monitor 与 manager 守护程序）。然后，使用orchestrator命令部署集群的其余部分，以添加其他主机，使用存储设备并为集群服务部署守护程序。

引导群集很简单：

curl --silent --remote-name --location https://github.com/ceph/ceph/raw/octopus/src/cephadm/cephadmchmod +x cephadmmkdir -p /etc/ceph./cephadm bootstrap --mon-ip <ip>

30到60秒后，最小的Ceph集群将启动并运行，并且cephadm将打印出命令以访问Ceph CLI（通过容器化shell）和URL来访问dashboard：

INFO:cephadm:Ceph Dashboard is now available at:          URL: https://gnit:8443/         User: admin     Password: 07j394z550INFO:cephadm:You can access the Ceph CLI with:     sudo ./cephadm shell --fsid 2d2fd136-6df1-11ea-ae74-002590e526e8 -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.client.admin.keyringINFO:cephadm:Bootstrap complete.

访问Ceph CLI

由于Ceph已完全容器化（podman ps或docker ps进行验证），因此主机上尚未安装任何软件，通常的ceph命令将不起作用（至少现在还不行）。有几种与新群集进行交互的方法。

一种方法是使用cephadm shell命令。用于引导的cephadm也可以启动装有所有Ceph软件（包括CLI）的容器话Shell。因为bootstrap在默认情况下会将ceph config和admin keyring的副本放在/etc/ceph中，而shell命令在默认情况下会在那里显示，所以您可以通过以下的命令启动一个shell并进入CLI管理端：

./cephadm shellceph status

cephadm命令还使在主机上安装Ceph软件包变得更加容易。如下命令是将Ceph CLI命令和cephadm命令安装在标准位置：

./cephadm add-repo --release octopus./cephadm install cephadm ceph-common

它支持一些常见的Linux发行版（CentOS/RHEL，Debian/Ubuntu，OpenSUSE/SLE），并且可以轻松扩展以支持新发行版。

Ceph集群扩展

任何生产环境的Ceph集群都跨越多个主机。Cephadm通过使用SSH从ceph mgr守护程序连接到集群中的主机来管理集群，从而内省环境、监视ceph守护进程以及部署或删除守护程序。每个Ceph集群生成一个惟一的SSH标识和密钥，用于连接到主机。引导过程会将此密钥添加到本地主机的根用户的authorized_keys中。但是，添加其他主机需要一些手动步骤。

首先，我们需要集群密钥的公钥部分。默认情况下，引导程序会将副本放在/etc/ceph/ceph.pub，或者可以使用ceph cephadm get ssh pub key从集群获取公钥副本。

对于每个主机，我们首先需要在远程系统上添加密钥。使用任何最新版本的ssh附带的ssh copy id命令最容易实现这一点：

ssh-copy-id -f -i /etc/ceph/ceph.pub root@new-host

如果您当前的用户尚未设置免密码的SSH访问，则此命令可能会提示您输入root密码。

接下来，我们需要告诉Ceph有关新主机的信息。在此我们假设所有主机都有一个唯一的主机名，该主机名与主机本身上配置的主机名匹配。如果您的本地环境还没有配置DNS以使我们可以连接到这些主机名，或者您希望避免依赖DNS，则还可以为每个主机提供IP地址：

ceph orch host add <new-host> [<new-host-ip>]

您可以使用以下命令查看群集中的所有主机

ceph orch host ls

管理Ceph monitor, manager和其他守护程序

Cephadm中的每个服务或守护进程集合都有一个相关的 placement 规范，或者描述应该在哪里部署守护程序以及部署多少守护程序。默认情况下，带有cephadm的新Ceph集群知道集群应该在每个主机上部署5个monitor、2个manager和一些其他服务（如crash dump collector）。新的monitor和manager会在向群集添加其他主机后自动部署。您可以使用ceph orch ls和ceph orch ps命令查看新的集群服务和已部署的守护程序：

# ceph orch lsNAME           RUNNING  REFRESHED  AGE  PLACEMENT  IMAGE NAME                           IMAGE ID      alertmanager       1/1  71s ago    22m  count:1    docker.io/prom/alertmanager:latest   0881eb8f169f  crash              1/1  71s ago    23m  *          docker.io/ceph/ceph:v15              204a01f9b0b6  grafana            1/1  71s ago    22m  count:1    docker.io/ceph/ceph-grafana:latest   87a51ecf0b1c  mgr                1/2  71s ago    23m  count:2    docker.io/ceph/ceph:v15              204a01f9b0b6  mon                1/5  71s ago    23m  count:5    docker.io/ceph/ceph:v15              204a01f9b0b6  node-exporter      1/1  71s ago    22m  *          docker.io/prom/node-exporter:latest  e5a616e4b9cf  prometheus         1/1  71s ago    22m  count:1    docker.io/prom/prometheus:latest     e935122ab143  # ceph orch psNAME                HOST  STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                           IMAGE ID      CONTAINER ID  alertmanager.gnit   gnit  running (21m)  96s ago    22m  0.20.0   docker.io/prom/alertmanager:latest   0881eb8f169f  15ceff5ae935  crash.gnit          gnit  running (22m)  96s ago    23m  15.2.0   docker.io/ceph/ceph:v15              204a01f9b0b6  0687711365e4  grafana.gnit        gnit  running (21m)  96s ago    22m  6.6.2    docker.io/ceph/ceph-grafana:latest   87a51ecf0b1c  fa1db4647c4c  mgr.gnit.xmfvjy     gnit  running (24m)  96s ago    24m  15.2.0   docker.io/ceph/ceph:v15              204a01f9b0b6  6a29bc868357  mon.gnit            gnit  running (24m)  96s ago    24m  15.2.0   docker.io/ceph/ceph:v15              204a01f9b0b6  072f5926faa8  node-exporter.gnit  gnit  running (22m)  96s ago    22m  0.18.1   docker.io/prom/node-exporter:latest  e5a616e4b9cf  eb5f715005fc  prometheus.gnit     gnit  running (22m)  96s ago    22m  2.16.0   docker.io/prom/prometheus:latest     e935122ab143  6ee6de1b3cc1  

在上面的示例输出中，您会注意到部署了许多非Ceph守护程序：Prometheus，Grafana，alertmanager和node-exporter。它们提供了一个基本但配置完整且功能齐全的监视堆栈，该堆栈允许Ceph Dashboard的所有指标和图形都可以立即使用。如果您已经希望Ceph使用的现有的Prometheus，则可以通过传递--skip-monitoring-stack给bootstrap命令来告诉cephadm跳过这些。

对于大多数用户来说，这种默认行为就是您所需要的。对于想要精确控制在哪些主机上部署monitor或选择具体IP的高级用户，需要一些附加步骤来定制这些守护程序的位置。甚至可以完全禁用特定服务（如monitor）的自动分布，尽管这样做的理由相对较少。

一旦集群开始运行，一个最小但足够的ceph.conf访问群集的主机的文件可以通过以下方式获取：

# ceph config generate-minimal-conf

添加存储

将OSD添加到Ceph集群通常是部署中最棘手的部分之一。HDD和SSD可以通过多种方式组合以平衡性能和成本，并且告诉Ceph使用哪种设备可能很棘手。

对于大部分用户，我们希望以下命令就足够了：

ceph orch apply osd --all-available-devices

这将消耗Ceph集群中通过所有安全检查的任何主机上的任何设备（HDD或SSD），这意味着没有分区、没有LVM卷、没有文件系统等。每个设备将部署一个OSD，这是适用于大多数用户的最简单情况。

对于我们其他人，我们有几种工具可供使用。我们可以使用以下方法列出所有主机上的所有设备（以及上述安全检查的状态）：

ceph orch device ls

可以使用以下命令在单个设备上显式创建单个OSD：

ceph orch daemon add osd host-foo:/dev/foo

但是，对于更复杂的自动化，orchestrator API引入了DriveGroups的概念，该概念允许按照设备属性（SSD与HDD，型号名称，大小，主机名模式）以及“hybrid” OSD来描述OSD部署。组合多个设备（例如，用于元数据的SSD和用于数据的HDD）以半自动化的方式进行部署。

部署存储服务

其他Ceph守护程序是无状态的，这意味着它们不会在本地存储任何数据，并且可以在任何主机上轻松地重新部署。这些对于cephadm来说很容易……对于CephFS，它们的部署是完全自动化的。例如，创建一个名为的CephFS文件系统foo

ceph fs volume create foo

将创建必要的数据和元数据池，并一步一步部署MDS守护程序。守护程序的数量和位置可以在以后通过ceph orch ls和ceph orch apply mds ...命令进行检查和调整，或者可以将可选的placement参数传递给volume create命令。

对于使用RGW的对象存储，事情还没有完全简化，但是orchestrator和cephadm可以用来管理底层守护进程。对于独立对象存储群集：

radosgw-admin realm create --rgw-realm=myorg --defaultradosgw-admin zonegroup create --rgw-zonegroup=default --master --defaultradosgw-admin zone create --rgw-zonegroup=default --rgw-zone=us-east-1 --master --defaultceph orch apply rgw myorg us-east-1

对于现有（multi-site或standalone）部署，部署守护程序可以像ceph orch apply rgw<realmname><zonename>一样简单，前提是rgw配置选项已存储在群集的配置数据库（ceph config set client.rgw.$realmname.$zonename ...）中而不是ceph.conf文件。

升级

一旦部署了新集群（或升级并转换了现有集群），cephadm的最佳功能之一就是它能够自动执行升级。在大多数情况下，这很简单：

ceph orch upgrade start --ceph-version 15.2.1

可以从ceph status命令监视升级进度，该命令的输出将包含一个进度条，例如：

Upgrade to docker.io/ceph/ceph:v15.2.1 (3m)   [===.........................] (remaining: 21m)

注意点

能够更深入地了解cephadm在后台运行以在远程主机上运行服务是非常有帮助的。首先，您可以使用podman ps或docker ps查看容器。您会注意到所有容器的名称中都有集群fsid UUID，这样多个集群就可以出现在同一个主机上，而不会相互冲突。（除守护进程使用固定端口（如Ceph monitor）或prometheus node-exporter之类的命令外。）

这些文件也都是单独的。在/var/lib/ceph和/var/log/ceph中，您将发现由集群fsid分隔开的内容。并且在每个守护程序目录中，您都会看到一个名为unit.run的文件，该文件具有启动守护程序的docker或podman命令——这就是systemd执行的操作。

尽管您可能还记得Bootstrap步骤将文件写入/etc/ceph，但它这样做只是为了方便，这样在主机上单个集群的常见情况下，只需安装ceph common包就可以让ceph CLI正常工作。传递--output-dir（或类似方式）引导程序会将这些文件写入其他位置。

事实上，主机操作系统唯一的其他变化是：

• /etc/systemd/system为每个集群（ceph-$fsid.target对于ceph-$fsid@.service所有守护程序共享的每个集群）写入的systemd文件

• ceph.target启动/停止所有 Ceph服务

• logrotate文件位于/etc/logrotate.d/ceph-$fsid，以防启用了对文件的日志记录。（默认情况下，cephadm守护进程将日志记录到stderr，并由容器运行时捕获日志。）

同时，在ceph-mgr守护程序中运行的cephadm模块可以更改。通过Orchestrator界面配置服务，可以通过内部Python界面（例如，Dashboard）或CLI进行访问。要查看所有可用命令，请尝试ceph orch -h。 ceph orch ls特别是将描述当前配置的服务。

在后台，cephadm具有“reconciliation loop”，就像Kubernetes一样，该loop将当前状态与所需状态进行比较，这由配置的服务指定。要监视其活动，ceph -W cephadm将实时显示正在输出的最后的日志，或ceph log last cephadm显示最近的消息。这个后台工作可以在任何时候用ceph orch pause暂停，使用ceph orch resume继续。

期待

在最初的Octopus版本中，cephadm对核心Ceph服务提供了可靠的支持：RADOS，CephFS，RBD和RGW。大量辅助服务正在积极开发中，包括NFS和iSCSI网关支持，并且此后有望再提供CIFS支持（通过Samba）。所有这些更改将在完成后被反向移植到Octopus。

同时，我们还期望提高“scheduling”算法的健壮性和智能性，该算法决定在哪里运行服务。现在cephadm只是将服务守护进程分散到主机上，但是（默认情况下）随机选择这些主机。我们希望通过对守护进程容器（例如CPU和内存）设置资源限制，并根据每个主机上的可用资源智能地选择守护进程的位置来改进这一点。

最后，我们希望在下一个开发周期中花费大量时间通过Ceph Dashboard展示更多的编排功能，以简化总体用户体验，尤其是对于初始部署、群集扩展和更换故障存储设备等常见操作。

欢迎反馈！

最后但并非最不重要的一点：Cephadm是全新的，我们正在寻找真实用户的反馈，以便在真实环境中首次部署Cephadm，以了解哪些是有效的，哪些是不起作用的，以及我们可以做些什么来改进！

有关Cephadm的更多信息，请参阅在线文档。

原文: https://ceph.io/ceph-management/introducing-cephadm/

了解新钛云服

当IPFS遇见云服务|新钛云服与冰河分布式实验室达成战略协议

新钛云服正式获批工信部ISP/IDC(含互联网资源协作)牌照

深耕专业，矗立鳌头，新钛云服获千万Pre-A轮融资

新钛云服，打造最专业的Cloud MSP+，做企业业务和云之间的桥梁

新钛云服一周年，完成两轮融资，服务五十多家客户

上海某仓储物流电子商务公司混合云解决方案

新钛云服出品的部分精品技术干货

低代码开发，全民开发，淘汰职业程序员！

国内主流公有云VPC使用对比及总结

万字长文：云架构设计原则|附PDF下载

刚刚，OpenStack 第 19 个版本来了，附28项特性详细解读！

Ceph OSD故障排除|万字经验总结

七个用于Docker和Kubernetes防护的安全工具

运维人的终身成长，从清单管理开始|万字长文！

OpenStack与ZStack深度对比：架构、部署、计算存储与网络、运维监控等

什么是云原生？

IT混合云战略：是什么、为什么，如何构建？