为了更好地了解我们当前的用户如何使用 Ceph，我们从 2018 年 5 月 1 日到 5 月 25 日进行了一项公开社区调查。 Ceph 用户调查 2018 幻灯片 包含来自 Survey Monkey 的图表。 我们还将（略微清理过的）回复作为 社区数据许可协议 - 分享，版本 1.0 在这里提供：Ceph 用户调查 2018 - 用于分发。

让我们深入探讨并讨论结果 - 如果您有任何进一步的评论或问题，请通过我们的 邮件列表 与我们联系！

人口统计

收到的回复数量非常令人鼓舞，表明了极大的兴趣以及多元化、活跃的社区 - 我们收到了 342 个已完成的回复，来自 52 个不同国家，分布在 4 个大洲。

大部分回复来自欧洲、中东和非洲地区，紧随其后的是北美、亚太地区和拉丁美洲。

调查参与者的组织背景主要是商业性质，还有一些学术机构和个人用户。政府采用 - 或者至少，参与调查 - 还有提升空间。

主要发现

选择 Ceph 的原因 ¶

有两个原因胜过其他所有原因：我们的用户想要一个开源解决方案，并且它需要具有可扩展性。成本仅排在第三位，这表明成本不是开源采用的主要驱动因素，而是一个受欢迎的好处。

遗憾的是，只有 2% 的人表示他们选择 Ceph 是因为性能原因，这与后续关于未来关注方向的反馈相符。

Ceph 经验和用户满意度 ¶

我们的用户群显示出大量的长期 Ceph 使用者：超过 50% 的用户使用 Ceph 超过两年（包括 10% 的用户使用超过 5 年）。与此同时，大约五分之一的用户使用 Ceph 不到一年，另外四分之一的用户使用 Ceph 1 到 2 年。

如果按部署容量加权（见下文），89% 的用户使用 Ceph 超过 2 年，包括 21% 的用户使用超过五年。

这表明了一种健康的平衡 - Ceph 既被长期采用，又因其成熟度和功能而持续存在于组织中，并且长期集群不断增长 - 但我们也看到了健康的部署数量。

我们的用户对 Ceph 的满意度如何？超过 83% 的用户表示他们对这项技术（非常）满意！

Ceph 部署规模 ¶

容量 ¶

受访者选择 Ceph 的第二个原因是其可扩展性。这是 Ceph 最伟大的架构优势之一，无与伦比。

因此，Ceph 部署规模巨大并不令人惊讶：总的来说，我们的调查受访者报告了至少 880 PB 的已部署容量。（在 342 个回复中，322 个有效，实际数字可能更高。）

平均容量为 2.7 PB，超过 25% 的安装大于 1 PB，其中 5% 甚至超过 10 PB 的原始容量！有了 Ceph，这些站点已经为进一步增长做好了准备。

我们还看到一小部分系统仅使用高达 10 TB 的容量；这表明如果您只想尝试一下并熟悉该技术，即使一台服务器也足够了。

由于需要复制或纠删编码来实现所需的耐久性级别，可用容量较低。由于可以在单个集群内混合使用不同类型的冗余，因此本次调查中原始容量和可用容量之间没有简单的直接关系。这也反映在对该字段回复数量略少（309/342）。

尽管如此，309 名受访者提供的答案估计他们部署的总可用容量为 360 PB（总原始容量为 862 PB）。

按节点和设备数量 ¶

与 Ceph 的巨大可扩展性相呼应，世界上至少有 46200 个 OSD 节点（318 个回复中的 342 个）。

虽然 Ceph 集群的中位数由 10 个节点组成，但大约三分之一的集群在 10 到 100 个节点之间，几乎 10% 的集群超过 100 个节点。

超过一半的集群拥有超过 50 个存储设备；超过三分之一的集群超过 100 个，超过 5% 的集群超过 1000 个。我们有三位受访者在其集群中拥有超过 10000 个 OSD。哇。

Ceph 版本 ¶

Ceph 是一个非常活跃的项目，具有频繁的发布。我们的调查显示，超过 80% 的用户已经运行最新的稳定版本（Luminous），这是一项杰出的成就。正如预期的那样，我们也有很大一部分用户使用上一个稳定版本（Jewel，41%），还有一小部分用户仍在 Hammer 上（13%），以及极少数用户使用旧版本。

按总容量加权，这些数字会发生变化：68% 的用户报告使用 Luminous，70% 使用 Jewel，38% 使用 Hammer。大型部署升级速度较慢，过渡期较长，但这仍然是一个令人鼓舞的采用率。

这些数字对于未加权和加权数字加起来达到 146% 和 200%，这表明许多用户并行运行至少两个版本。

我们还可以看到之前在稳定版本和更具侵略性的版本之间交替的方法造成了显著差异。该模型已在 Ceph Mimic 版本中放弃，但调查在 Mimic 发布之前结束。

用户从哪里获取 Ceph？ ¶

大多数受访者表示他们正在使用直接来自 Ceph 上游项目的软件包构建，其次是其发行版或 Ceph 供应商提供的软件包。少数人会自行构建，甚至自定义构建。

这是对 Ceph 上游项目质量保证和发布流程的极大信任。

运行 Ceph 的 Linux 发行版 ¶

免费的 Linux 发行版 - Ubuntu (65.9%)、Debian (8.6%)、CentOS (28%)、openSUSE (0.34%) - 组合起来构成了最大比例的部署。Red Hat Enterprise Linux 被 8.9% 的用户使用，SUSE Linux Enterprise 被 2.3% 的用户使用。

按部署容量加权，Debian 上升到 31%，SUSE Linux Enterprise 增加到 6.14%。CentOS 保持稳定在 29%，Red Hat Enterprise Linux 保持稳定在 8.5%。Ubuntu 下降到 36%。

还有两位用户表示他们正在 BSD 操作系统上运行 Ceph。恭喜 - 我们感谢您的努力！

已部署的硬件 ¶

我们的调查受访者列出了非常多样化的硬件供应商；由于 Ceph 是一种软件定义存储解决方案，能够在任何稳定的硬件平台上运行，您可以放心地选择最适合您环境的供应商。

几乎所有人都 (98.8%) 报告使用 x86-64 硬件。

存储设备 ¶

由于 Ceph 因其可扩展性和大容量而受到选择，因此毫不奇怪的是，89% 的用户使用硬盘驱动器，因为它们仍然提供最佳的每容量成本。但有整整三分之二的用户使用 SSD，并且已经有三分之一的用户部署了基于 NVMe 的存储，以加速 HDD 集群或作为纯闪存部署。

按容量加权，我们看到 HDD 使用率显著增加（达到 98%）（正如预期的那样，对于大型、经济高效的存档），而 NVMe 增加到 58%，翻了一番。

网络带宽 ¶

几乎四分之三的部署利用了 10 GbE 广泛的可用性和每端口的低成本。（这包括 40 GbE 设置，它是四个聚合的 10 GbE 链路。）

我们仍然有三分之一的用户利用 1 GbE 网络 - 虽然这可能令人惊讶，但在扩展解决方案中，一千个 1 GbE 端口仍然可以为客户端提供显着的带宽和吞吐量。

然而，大约 13% 的用户已经部署了新的 25/50/100 GbE 选项，这些选项结合了更高的带宽和显著改进的延迟。

按容量加权，1 GbE 的使用率下降到 13%，而 25/50/100 GbE 的采用率增加到 22%；特别是 25 和 50 GbE 的使用率增加了一倍多。

总结网络，三分之二的用户使用专用的 OSD 集群网络，三分之一的用户将公共网络和专用网络结合起来。

OSD 功能采用 ¶

BlueStore 和 FileStore ¶

Ceph Luminous 引入的主要新功能之一是我们的新改进的默认 OSD 后端 BlueStore。再次证明了 Ceph 项目的信任和质量，超过三分之二的用户已经部署了它！

当然，这种过渡需要一些时间，用户需要使用 Luminous 或更高版本才能利用 - 60% 的用户也仍在 FileStore，该 FileStore 仍然完全受支持。

镜像安装的 Ceph 版本较大的集群，按容量加权显示 56% 使用 BlueStore，90% 使用 FileStore。

首选数据冗余模式 ¶

95% 的用户在其 Ceph 集群中部署了复制。有 25% 的用户也利用了改进的数据密度和空间利用率以及灵活的耐久性，即纠删编码。

再次按容量加权，报告使用复制的站点百分比保持不变，但纠删编码的采用率增加到 52%；大型部署显然希望利用较低的容量开销。

最常见的 EC 配置文件是 8+3 和 4+2，但这里的数字确实反映了耐久性与容量权衡的需求的多样性。

用例

收集的关于 Ceph 整体用例以及各自协议前端的数据非常广泛；鼓励您自行查看数据。

从高层来看，所有形式的云原生部署 - 虚拟化、公共/私有云使用、容器化 - 都是 Ceph 使用的主要驱动因素。如果按容量加权，则情况会更加明显。这反映了 Ceph 早期专注于与主要平台（如 OpenStack、Kubernetes/OpenShift、Proxmox）的集成。

作为大规模、容量导向的存储平台，Ceph 也被大量采用（总计 42.9%，加权后为 65%）作为存档。

其他重要的用例包括 HPC、大数据和视频/CDN。

作为家庭目录或 HPC 的通用用途相对较低。凭借 Ceph 和 CephFS 已经可用且即将改进的性能，我们预计这将是一个增长机会。

协议 ¶

Ceph 历史中的功能成熟度也体现在访问 Ceph 集群所使用的协议中 - 84% 使用块（74% 使用 RBD 启动虚拟机），44% 使用文件，42% 使用 S3 或 Swift，表明所有协议都相关且被广泛采用。有整整 15% 的用户在 librados 之上实现了原生解决方案。

这些数字在 Ceph 集群的不同生命周期阶段相对一致；但是，可能表明 S3/Swift 和 librados 将在当前正在开发中的未来解决方案中看到越来越多的采用。

块和互操作性 ¶

大约 15% 的用户表示他们会将 RBD 重新导出到 iSCSI。这表明使用非 Linux 客户端、过旧的 Linux 发行版，或者需要在客户端和集群之间引入额外的隔离层。

有相当一部分用户（总数的 13%）使用 iSCSI 重新导出连接到他们的 VMware 工作负载。（不幸的是，一些细节已经进入了下面的 未来工作 部分。）

RadosGW - S3 和 Swift ¶

主要用于归档和备份，也有三分之一的用户报告了“其他”用途，以及相当一部分用于大数据和分析，反映了多样化的使用场景。

在访问方法方面，四分之三（74%）选择广泛采用的 S3 API，三分之一的用户使用 Swift 来满足他们的对象存储需求。（数据还进一步细分了报告的客户端库。）

大多数用户使用 Ceph 原生的 RGW 身份验证，但 30% 将其与 OpenStack Keystone 集成，15% 与 LDAP 环境集成。

超过 90% 的用户表示他们正在使用负载均衡器与 RGW 配合使用，haproxy 和 nginx 是首选。

RGW 多站点 ¶

超过四分之一的用户（26%）表示他们运营着多个站点并使用 RGW 多站点联合，甚至有些用户报告部署了超过 5 个站点。这使他们能够解决数据本地性和灾难恢复问题。

CephFS ¶

CephFS 的工作负载确实过于多样化，无法选出明确的赢家。这是一个好迹象，因为它表明 CephFS 实现了其成为通用、可扩展集群文件系统的目标。

大多数客户端从 Linux 系统原生访问 CephFS，并且更喜欢内核客户端而不是 ceph-fuse。

有 35% 的用户将 CephFS 提供给基于 NFS 的客户端，另有 21% 通过 CIFS/Samba 连接客户端。这比 RBD 生态系统多样得多。

我们还看到大约 10% 的用户通过 libcephfs 在他们的堆栈中构建了 CephFS 访问的本机支持。

监控和管理工具

管理框架 ¶

本节反映了 Ceph 用户可用的巨大多样性和选择数量；然而，我们已经看到 ceph-mgr 仪表板（这是 Ceph 上游的一部分）正在成为最广泛命名的框架。随着 Luminous、Mimic 及更高版本的发布，这现在是 Ceph 社区管理的主要焦点。

监控和仪表板 ¶

Grafana 是迄今为止最受欢迎的选择——不仅作为一个定制平台，而且也是与其他指标收集器（如 Prometheus）常用的框架。

这里的多样性表明了 Ceph 的挑战；用户具有非常多样化的监控和指标收集需求。我们的路线图必须优先考虑并仍然允许与不同堆栈集成。

部署框架 ¶

大量用户仍然使用 ceph-deploy，其次是 Ansible、Puppet 和 Salt。然而，Chef 和 Juju 仍然在使用，11% 的用户表示他们使用完全不同的东西；之前解释的相同困境同样适用。

帮助我们的用户

我们还想了解如何更好地与我们的用户互动。因此，调查的一个部分侧重于他们与 Ceph 社区提供的各种沟通渠道之间的互动，从文档到商业供应商的支持。

商业供应商 ¶

虽然大约四分之三的受访者表示他们没有与任何商业供应商签订支持协议，但另外四分之一的用户确实签订了协议——从小型公司和个人承包商（加起来占该市场的 7%！），其次是 SUSE、Red Hat 和 Canonical。

用户在哪里寻求帮助 ¶

三分之二 的用户表示他们首先阅读了出色的手册，这是个好消息，并验证了该项目这部分的工作成果。（如果您想在社区中产生积极影响，这表明优秀的作者至少和开发者一样出色！）

另外 19% 使用我们的公共邮件列表，还有 7% 首先向他们的商业供应商求助。

用户接下来希望 Ceph 实现什么

作为项目，我们的一个关键问题是了解对我们的用户来说什么重要，以及我们应该将精力集中在哪些方面。在这里，我们有两个明确的投票

首先，性能。呼应了“选择 Ceph 的原因”排名的垫底位置，用户显然希望我们改进 Ceph 的性能。

其次，易用性。如各自部分所示，Ceph 周围的管理、监控和部署生态系统非常多样化，以至于出现了碎片化。这正在通过 ceph-mgr 和仪表板计划以及部署和编排的整合来解决。Mimic 中有一个很好的基础，Nautilus 将会大力推进。

我们的用户也继续重视可扩展性。对于大型部署，第一和第二优先级变得尤为关键。

随着 Ceph 的采用增长，互操作性——在不同的 Ceph 版本之间以及非本机客户端之间——变得至关重要。

我们还收到了大量的文本形式的反馈。我们对此非常感谢，并将认真对待您的建议！

勘误和未来调查

由于这是我们首次进行的调查，我们也学到了许多关于如何进一步改进我们的问卷的经验教训。了解这些局限性对于解释结果非常重要；我们希望在未来的调查中解决这些问题。

选择偏差 ¶

本次调查主要通过社交媒体、Ceph 项目渠道和邮件列表以及一些供应商的推广进行宣传。这肯定会引入选择偏差；我们显然偏向于更活跃和以社区为导向的 Ceph 成员。

数据质量问题 ¶

在某些情况下，我们的问题不够明确。

VMware 访问方法响应（我们 13% 的受访者正在积极使用的一个用例）不幸地将当前使用与期望模式混淆了。我们需要更深入地研究这些数据，并在未来澄清这一点。

在其他地方，我们不幸没有提供完整的选项列表——对于 RGW 联合多站点，用户可以指示 不适用 、 2 、 3 、 4 和 超过 5 ，而不能指示 5 或更多 ，如预期那样。

有些问题应该使用多项选择或排名，而不是单项选择。

有些字段应该使用数字而不是自由文本——向回答他们拥有的节点数量为“fuckton”的受访者致敬，这是一种我们不熟悉的 SI 单位。此外，这促使人们给出范围（“40-100”）而不是选择确切的答案。

存在一些明显的矛盾——例如，2 到 5 个集群的平均 200 个 OSD 节点，但总容量只有 12 TB。

虽然可以手动清理这些数据（对于范围，我们选择了中间点；如果有人回答“10+”，我们选择最低的整数），这足以满足我们的目标。在某些情况下，我们不得不由于明显的矛盾而丢弃特定的答案，但不知道哪种解释是预期的。

单数与复数 ¶

在某些情况下，我们询问了多个集群部署，而在另一些情况下，询问了单个集群实例。这并不理想，应该在未来的调查中澄清——最好是为每个集群重复一个部分，但我们需要注意不要过度增加调查的长度。

事实，而不是原因 ¶

我们也不总是知道人们为什么以某种方式回答或做出某种选择。请在解释数据时注意这一点。

向应该以编程方式回答的人类提出问题 ¶

我们也不应该询问用户 Ceph 实例知道答案或可以自动推断答案的问题——我们人类在记住细节和正确转录它们方面非常糟糕，尤其是在冗长而繁琐的表格中。

Ceph Mimic 获得了第一个（并且，当然是选择加入的）报告此类遥测数据的功能；在此基础上构建将提高未来研究的准确性和样本量。

结论

我们再次感谢所有参与我们首次 Ceph 社区调查的受访者。在您的帮助和见解下，我们将能够使 Ceph 变得更好、更成功。我们希望在未来的调查中再次收到您的反馈！

在此期间，如果您愿意分享并加入我们的邮件列表、社交媒体或即将举行的会议或 Ceph Day 上的对话，我们将不胜感激。

您的结论和想法是什么？