文章目录：
Ceph高可用部署和主要组件介绍
本教程用官网最近的cephadm来搭建ceph集群。
第一周作业：1.ceph的组件和功能2.ceph的数据读写流程3.使用ceph-deploy安装一个最少三个节点的ceph集群 推荐3个或以上的磁盘作为专用osd 4.测试ceph的rbd使用
1·Ceph组件和功能
组件
Ceph OSDs : ( Ceph OSD ）object storage daemon的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。当 Ceph 存储集群设定为有2个副本时，至少需要2个 OSD 守护进程，集群才能达到 active+clean 状态（ Ceph 默认有3个副本，但你可以调整副本数）。
Monitors : 维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。 Ceph 保存着发生在Monitors 、 OSD 和 PG上的每一次状态变更的历史信息（称为 epoch ）。
MDSs : Ceph 元数据服务器为 Ceph 文件系统存储元数据（也就是说，Ceph 块设备和 Ceph 对象存储不使用MDS ）。元数据服务器使得 POSIX 文件系统的用户们，可以在不对 Ceph 存储集群造成负担的前提下，执行诸如 ls、find 等基本命令。
CephMgr ：在一个主机上的守护进程，负责运行指标，运行状态，性能负载，
其他术语：
RADOS：多个主机组成的存储集群，即可靠，自动化，分布式的对象存储系统。
File: 就是普通文件，ObjectRADOS看到的对象，Object与File的区别是， Object的最大尺寸由RADOS限定(通常为2MB或4MB) ，以便实现底层存储的组织管理。因此，当上层应用向RADOS存入尺寸很大的File时，需要将File切分成统一大小的一系列Objet (最后一个的大小可以不同)进行存储。
librados：RADOS集群的API，支持大部分主流语言。
Pool：存储池，大小取决于底层的存储空间。
PG：placeholder group，一个pool（存储池）内可以有多个PG，pool个pg都是抽象的逻辑概念，可以通过公示计算。PG的用途是对Object的存储进行组织和位置映射的。具体而言，一个PG负责组织若干个Object，但一个Obiect只能被映射到一个PG中，即PG和Object之间是“一对多”的映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即PG和OSD之间是“多对多”的映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG可达到数百个。事实上， PG数量的设置关系到数据分布的均匀性问题。
OSD daemon：默认每2秒发送状态数据给monitor，（同时监控组内其他OSD的状态）（up 可以提供IO，down不能提供，in有数据，out没有数据）
PG和OSD之间的关系通过CRUSH算法得出的。常规这三个 OSD daemon 可以在一台机器上，也可以在不同机器上；那么根据 CRUSH 算法会尽可能的保证一个平衡，就是不在同一个机器上；毕竟Ceph中的数据是一个为平衡的状态，一切都是通过CRUSH 算法来实现的数据平衡，而 PG 本身是个有序列表，位于第一的位置是 master；这个列表的产生是由 monitor 来产生的；
寻址流程
File-Object映射 这次映射的目的是，将用户要操作的File映射为RADOS能够处理的Object，其十分简单，本质上就是按照Object的最大尺寸（默认4M）对File进行切分，相当于磁盘阵列中的条带化过程。这种切分的好处有两个:一是让大小不限的File变成具有一致的最大尺寸、可以被RADOS高效管理的Object;二是让对单一File实施的串行处理变为对多个Object实施的并行化处理。每一个切分后产生的Object将获得唯一的oid,即Object ID,其产生方式也是线性映射,极其简单。 Object →PG映射 在File被映射为1个或多个Object之后,就需要将每个Object独立地映射到1个PG中去。这个映射过程也很简单,如图所示,其计算公式如下:Hash(oid) mask - pgid由此可见,其计算由两步组成。首先,使用Ceph系统指定的一个静态哈希算法计算oid的哈希值,将oid映射为一个近似均匀分布的伪随机值。然后,将这个伪随机值和mask按位相与,得到最终的PG序号(pgid) 。根据RADOS的设计,给定PG的总数为m(m应该为2的整数幂),则mask的值为m-1。因此,哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择1个。基于这一机制,当有大量Object和大量PG时, RADOS能够保证Object和PG之间的近似均匀映射。又因为Object是由File切分而来的,大部分Object的尺寸相同,因此,这一映射最终保证了各个PG中存储的Object的总数据量近似均匀。这里反复强调了“大量” ,意思是只有当Object和PG的数量较多时,这种伪随机关系的近似均匀性才能成立, Ceph的数据存储均匀性才有保证。为保证“大量”的成立,一方面, Object的最大尺寸应该被合理配置,以使得同样数量的File能够被切分成更多的Object;另一方面, Ceph也推荐PG总数应该为OSD总数的数百倍,以保证有足够数量的PG可供映射。 PG→ OSD映射 第3次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD上。RADOS采用一个名为CRUSH的算法,将pgid代入其中,然后得到一组共n个OSD。这n个OSD共同负责存储和维护一个PG中的所有Objecto前面提到过, n的数值可以根据实际应用中对于可靠性的需求而配置,在生产环境下通常为3。具体到每个OSD,则由其上运行的OSD Daemon负责执行映射到本地的Object在本地文件系统中的存储、访问、元数据维护等操作。和“Object →PG"映射中采用的哈希算法不同, CRUSH算法的结果不是绝对不变的,而会受到其他因素的影响。其影响因素主要有两个。一是当前系统状态,也就是在前面有所提及的集群运行图。当系统中的OSD状态、数量发生变化时,集群运行图也可能发生变化,而这种变化将会影响到PG与OSD之间的映射关系。二是存储策略配置。这里的策略主要与安全相关。利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器或机架上,从而进一步改善存储的可靠性。因此,只有在系统状态和存储策略都不发生变化的时候, PG和OSD之间的映射关系才是固定不变的。在实际使用中,策略一经配置通常不会改变。而系统状态的改变或是因为设备损坏,或是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持,因而,即便PG与OSD之间的映射关系发生了变化,也并不会对应用产生影响。事实上, Ceph正是利用了CRUSH算法的动态特性,可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布再平衡等特性。之所以在此次映射中使用CRUSH算法,而不使用其他哈希算法,一方面原因是CRUSH算法具有上述可配置特性,可以根据管理员的配置参数决定OSD的物理位置映射策略;另一方面原因是CRUSH算法具有特殊的“稳定性" ,也即,当系统中加入新的OSD,导致系统规模增大时,大部分PG与OSD之间的映射关系不会发生改变,只有少部分PG的映射关系会发生变化并引发数据迁移。这种可配置性和稳定性都不是普通哈希算法所能提供的。因此, CRUSH算法的设计也是Ceph的核心内容之一。 至此为止, Ceph通过3次映射,完成了从File到Object. Object到PG,PG再到OSD的整个映射过程。从整个过程可以看到,这里没有任何的全局性查表操作需求。至于唯一的全局性数据结构:集群运行图。它的维护和操作都是轻量级的,不会对系统的可扩展性、性能等因素造成影响 。
存储过程总结：
1.计算文件到对象的映射
2.通过哈希算法计算计算出文件对应的pool的PG
3.通过CRUSH把对象映射到PG中的OSD
4.PG种的OSD将对象写入到磁盘
5.主OSD将数据同步到备份OSD，待备份OSD返回确认
6.主OSD的到备份OSD写完操作以后给客户的返回写入成功
2. ceph的读写流程
当某个客户端需要向Ceph集群写入一个File时，首先需要在本地完成寻址流程，将File变为一个Object，然后找出存储该Object的一组共3个OSD，这3个OSD具有各自不同的序号，序号最靠前的那个OSD就是这一组中的Primary OSD，而后两个则依次Secondary OSD和Tertiary OSD。找出3个OSD后，客户端将直接和Primary OSD进行通信，发起写入操作(步骤1)。 Primary OSD收到请求后，分别向Secondary OSD和Tertiary OSD发起写人操作(步骤2和步骤3)。当Secondary OSD和Tertiary OSD各自完成写入操作后，将分别向Primary OSD发送确认信息(步骤4和步骤5)。当Primary OSD确认其他两个OSD的写入完成后，则自己也完成数据写入，并向客户端确认Object写入操作完成(步骤6)。之所以采用这样的写入流程，本质上是为了保证写入过程中的可靠性，尽可能避免出现数据丢失的情况。同时，由于客户端只需要向Primary OSD发送数据，因此在互联网使用场景下的外网带宽和整体访问延迟又得到了一定程度的优化。当然，这种可靠性机制必然导致较长的延迟，特别是，如果等到所有的OSD都将数据写入磁盘后再向客户端发送确认信号，则整体延迟可能难以忍受。因此， Ceph可以分两次向客户端进行确认。当各个OSD都将数据写入内存缓冲区后，就先向客户端发送一次确认，此时客户端即可以向下执行。待各个OSD都将数据写入磁盘后，会向客户端发送一个最终确认信号，此时客户端可以根据需要删除本地数据。分析上述流程可以看出，在正常情况下，客户端可以独立完成OSD寻址操作，而不必依赖于其他系统模块。因此，大量的客户端可以同时和大量的OSD进行并行操作。同时，如果一个File被切分成多个Object，这多个Object也可被并行发送至多个OSD上。从OSD的角度来看，由于同一个OSD在不同的PG中的角色不同，因此，其工作压力也可以被尽可能均匀地分担，从而避免单个OSD变成性能瓶颈。
问：为什么要设计三层映射而不是一层？
答：如果将object直接映射到一组OSD上，如果这种算法是固定的哈希算法，则意味着一个object被固定映射在一组OSD上，当其中一个OSD损坏时，object也无法部署到新的OSD上(因为映射函数不允许)。
如果设计一个动态算法(例如CRUSH算法)来完成这一映射，结果将是各个OSD所处理的本地元数据暴增，由此带来的计算复杂度和维护工作量也是难以承受的。
综上所诉，引入PG的好处至少有二：一方面试下呢object和OSD之间的动态映射，从而为Ceph的可靠性、自动化等特性的实现留下了空间；另一方面也有效简化了数据的存储组织，大大降低了系统的维护管理开销。
1.准备工作
时间同步`
安装ntpdate（时间同步工具）
# apt install ntpate
0* * * * ntpdate time1.aliyun.com
echo'0 * * * * ntpdate time1.aliyun.com' /var/spool/cron/crontabs/root
或者 可以通过
ansible all-mshell-a"echo '0 * * * * ntpdate time1.aliyun.com' /var/spool/cron/crontabs/root"
关闭 selinux 和防火墙
root@node1:~# sudo ufw status ##查看状态
Status: inactive
root@node1:~# sudo ufw disable
Firewall stopped and disabled on system startup##禁用
root@node1:~#
配置域名解析或通过 DNS 解析
root@node1:~# cat /etc/hosts
127.0.0.1 localhost
root@node1:~# hostnamectl set-hostname 对应的名称
## 以下是新增的 可以按照自己的习惯配置
192.168.106.101 node1
192.168.106.102 node2
192.168.106.103 node3
安装python
root@node1:~# apt install python ##python2
源修改成国内源 -- 具体步骤自行百度
阿里云镜像仓库
网易镜像仓库
清华大学镜像源
ceph用到的端口 (防火墙和安全中记得放开)
Ceph Monitor：启用 Ceph MON 服务或端口 6789 (TCP)。
Ceph OSD 或元数据服务器：启用 Ceph OSD/MDS 服务或端口 6800-7300 (TCP)。
iSCSI 网关：打开端口 3260 (TCP)。
对象网关：打开对象网关通讯所用的端口。此端口在 /etc/ceph.conf 内以 rgw frontends = 开头的行中设置。HTTP 的默认端口为 80，HTTPS (TCP) 的默认端口为 443。
NFS Ganesha：默认情况下，NFS Ganesha 使用端口 2049（NFS 服务、TCP）和 875 （rquota 支持、TCP）。
SSH：打开端口 22 (TCP)。
NTP：打开端口 123 (UDP)。
2.搭建ceph集群
安装cephadm
root@node1:~# wget ## node1 管理节点上执行
root@node1:~# chmod +x cephadm
root@node1:~# ./cephadm add-repo --release pacific ##设置要安装的版本
root@node1:~# which cephadm ##确认是否安装成功
初始化集群
root@node1:~# cephadm bootstrap --mon-ip 192.168.106.101 ##ceph集群第一个节点的ip
初始化完了以后就可以访问dashboard了 地址 ： 访问用户密码上一步生成
添加其他节点和其他组件
root@node1:~# ssh-keygen
## 配置免密通信
root@node1:~# ssh-copy-id -f -i /etc/ceph/ceph.pub root@node2
root@node1:~# ssh-copy-id -f -i /etc/ceph/ceph.pub root@node3
## 添加node
root@node1:~# ceph orch host add node2 192.168.106.102
root@node1:~# ceph orch host add node3 192.168.106.103
## 添加osd
root@node1:~# ceph orch daemon add osd node1:/dev/sdb
root@node1:~# ceph orch daemon add osd node1:/dev/sdb
root@node1:~# ceph orch daemon add osd node3:/dev/sdb
测试
root@node1:~# ceph fs volume create testfs ##添加测试fs
root@node1:~# ceph orch apply mds testfs --placement="3" ##设置备份数
root@node1:~# ceph orch daemon add mds testfs node1
root@node1:~# ceph mds stat
## 在集群之外的或者任意机器上操作
root@node4:~# apt install ceph-common -y
node1初始化集群的节点操作
root@node1:~# scp /etc/ceph/ceph.client.admin.keyring user@node4:/etc/ceph
## 集群之外的clinet或者测试节点执行
root@node4:~# mount -t ceph node1:/ /mnt/testfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs
root@node4:~# mount -t ceph node2:/ /mnt/cephfs -o name=admin,secret=AQAoJjBh7OPVNhAAQZyzLhDfgSj+KPmeU5RVlA==,fs=testfs
root@node4:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev1.4G01.4G0% /dev
tmpfs 293M1.2M 292M1% /run
....
192.168.106.101:/ 18G 1000M 17G6% /mnt/testfs
192.168.106.102:/ 18G 1000M 17G6% /mnt/cephfs
root@node4:~# cd /mnt/cephfs
root@node4:/mnt/cephfs# dd if=/dev/zero of=test bs=1M count=100 ##生成文件
这时候文件是直接写在ceph集群上看了， 可以通过dashboard观察👀。
「精心整理」Ceph搭建硬件建议详解
Ceph是专为在商品硬件上运行而设计的，这使得构建和维护超大规模的数据集群在经济上是可行的。当规划出你的集群硬件时，你需要平衡一些考虑因素，包括故障域和潜在的性能问题。硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。一般来说，我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。我们建议使用其他主机来处理使用您的数据集群的进程（例如OpenStack、CloudStack）
Ceph元数据服务器会动态地重新分配负载，这对CPU来说是很有必要的。所以你的元数据处理器应该有相当大的处理能力（四核心或更高的CPU）。Ceph OSDs 运行RADOS服务，用CRUSH计算数据放置、复制数据，并维护自己的集群地图副本。因此，OSD应该有合理的处理能力（例如双核处理器）。监视器只是维护集群映射的主副本，所以监视器不需要CPU密集型的处理能力。
除了Ceph守护进程之外，你还必须考虑主机是否会运行CPU密集型进程，例如，如果您的主机将运行计算虚拟机（例如，OpenStack Nova)，您需要确保这些其他进程为Ceph守护进程留下足够的处理能力。我们建议在单独的主机上运行额外的CPU密集型进程。
一般来说，RAM越多越好
监视器和管理器守护进程的内存使用量一般会随着集群的大小而变化。
对于小型集群，一般来说，1-2GB就足够了。
对于大型集群，你应该提供更多（5-10GB）。
你可能还需要考虑调整设置，如mon_osd_cache_size或 rocksdb_cache_size
Bluestore使用自己的内存来缓存数据，而不是依赖操作系统的页面缓存。在BlueStore中，你可以通过osd_memory_target选项调整OSD_memory_target的内存量
•通常不建议将osd_memory_target设置为2GB以下，可能会将内存保持在2GB以下，同时也可能导致性能极慢。•将内存目标设置在2Gb和4Gb之间通常有效，但可能会导致性能下降，因为元数据可能在IO期间从磁盘读取，除非活动数据集相对较小。•4GB是目前默认的osd_memory_target大小，这样设置的目的是为了平衡内存需求和OSD的性能，以满足典型的使用情况•设置osd_memory_target高于4GB时，当有许多（小的）或大的（256GB/OSD)数据集被处理时，可能会提高性能。
重要：
OSD的内存自动调整是“尽力而为”。虽然OSD可能会解除内存映射，让内核回收内存，但不能保证内核会在任何特定的时间框架内实际回收释放的内存。这在旧版本的Ceph中尤其如此，因为透明的巨页会阻止内核从碎片化的巨页中回收内存。现代版本的Ceph在应用级禁用透明巨页以避免这种情况，但这仍然不能保证内核会立即回收未映射的内存。OSD有时仍然可能会超过它的内存目标。我们建议在系统中保留20%左右的额外内存，以防止OSD在临时高峰期或由于内核延迟回收空闲页而导致的OSD出现OOM。这个值可能会比需要的多或少取决于系统的具体配置。
在使用传统的FileStore后端时，页面缓存是用来缓存数据的，所以一般不需要调优，OSD的内存消耗一般与系统中每个守护进程的PG数量有关
仔细规划你的数据存储配置。在规划数据存储时，需要考虑重大的成本和性能权衡。同时进行操作系统操作，以及多个守护进程对单个驱动器同时请求读取和写入操作，会大大降低性能。
重要
由于Ceph在发送ACK之前必须先将所有数据写入日志（至少对XFS来说），所以日志和OSD的性能平衡真的很重要！在这里，Ceph的日志和OSD的性能是非常重要的。
OSD应该有足够的硬盘空间来存放对象数据。我们建议硬盘驱动器的最小容量为1T。考虑到较大磁盘的每GB的成本优势。我们建议将硬盘驱动器的价格除以千兆字节，得出每千兆字节的成本，因为较大的驱动器可能会对每千兆字节的成本有很大影响。例如，价格为75美元的1T硬盘，每千兆字节的成本为0.07美元。相比之下，价格为150美元的3T硬盘的成本为每千兆字节0.05美元。在上述例子中，使用1T硬盘通常会使每千兆字节的成本增加40%——使集群的成本效益大大降低。
Tips: 在一个磁盘上运行多个OSD，无论分区如何，都不是一个好主意
Tips: 在单一磁盘上运行OSD和显示器或者元数据服务器，无论分区如何，都不是一个好主意
存储驱动器在寻求时间、访问时间、读取和写入时间以及总吞吐量方面受到限制。这些物理限制会影响整体系统性能，特别是在恢复期间。我们建议为操作系统和软件使用一个专门驱动器，并且您在主机上运行的每个Ceph OSD daemon使用一个驱动器。大多数“慢OSD”问题的出现是由于在同一个驱动器上运行一个操作系统，多个OSD，或多个日志。由于在一个小型集群上排除性能问题的成本超过了额外的磁盘驱动器的成本，因此您可以通过避免过度消耗OSD存储驱动器的诱惑来优化您的集群设计规划。
您可以在每个硬盘驱动器上运行多个Ceph OSD Daemons，但这可能会导致资源征用，降低整体吞吐量。你可以在同一硬盘上存储日志和对象数据，但这可能会增加写日志和ACK到客户端所需要的时间。Ceph必须先写入到日志，然后再进行ACK写入。
ack写入：完成此类写入之后，将向客户端发送一个成功写入的ACK，所以称之为ACK写入
Ceph最佳实践规定，你应该在不同的驱动器上运行操作系统、OSD数据和OSD日志
提高性能的一个机会是使用固态硬盘来减少随机访问时间和读取延迟，同时加快吞吐量。与机械硬盘相比，固态硬盘每千兆字节的成本往往超过10倍以上，但固态硬盘的访问时间往往比机械硬盘至少快100倍。
固态硬盘没有活动的机械部件，所以他们不一定会受到与机械硬盘相同的限制。但固态硬盘确实有很大的局限性。在评估固态硬盘时，重要的是考虑顺序读取和写入的性能。当为多个OSD存储多个日志时，具有400MB/S顺序写入吞吐量的SSD可能比具有120MB/s顺序写入吞吐量的SSD性能要好的多。
重要
我们建议探索使用固态硬盘来提高性能。然而，在对SSD进行重大投资之前，我们强烈建议在审查SSD的性能指标和测试配置中测试SSD的性能
由于固态硬盘没有活动的机械部件，所以在Ceph中不需要使用大量存储空间的区域（如日志）使用固态硬盘是很有意义的。相对便宜的SSD可能会吸引你的经济意识。请谨慎使用。在选择使用Ceph的SSD时，仅有可接受的IOPS是不够的。日志和SSD有几个重要的性能注意事项：
•写入密集型语义：日志涉及到写密集型语义，因此您应该确保您选择部署的SSD在写入数据时的性能相当于或优于机械硬盘。廉价的固态硬盘在加速访问时间的同时，可能会引入写入延时，因为有时高性能硬盘的写入速度会比市场上一些更经济的固态硬盘快，因此，您应该确保您选择的固态硬盘在写入数据时的性能与机械硬盘相当或更好。•顺序写入：当您在SSD上存储多个日志时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理对多个OSD日志的写入请求。•分区对齐：SSD性能的一个常见问题是，人们喜欢将硬盘分区作为最佳做法，但往往忽略了对SSD的正确分区对齐，这样会导致SSD的数据传输速度更慢。确保SSD分区正确对齐
虽然固态硬盘对于对象存储的成本较高，但通过将OSD的日志存储在固态硬盘上，并将OSD的对象存储存储在独立的机械硬盘上，可能会看到性能的显著提升。osd journal配置设置默认为/var/lib/ceph/osd/$cluster-id/journal。您可以将此路径挂载到SSD或者SSD分区，使其不只是与对象数据存储在同一硬盘上。
Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储隔离开来。Ceph为CephFS元数据提供了一个默认的元数据池。你永远不必为CephFS元数据创建一个池，但你可以为你的CephFS元数据池创建一个只指向主机的SSD存储介质的CRUSH映射层次结构。详情请参见将池映射到不同类型的OSDs。
•意思是可以将一个池的所有数据都存储到SSD类型的OSD
磁盘控制器对写入吞吐量也有很大影响。在选择磁盘控制器时要慎重考虑，确保不会造成性能瓶颈。
Tips：Ceph博客通常是对Ceph性能问题的一个很好的信息来源。更多详情请参加Ceph写吞吐量1和Ceph写吞吐量2
••
你可以在每台主机上运行多个OSD，但你应该确保你的OSD硬盘的总吞吐量之和不超过服务于客户端读取或写入所需的网络带宽。你还应该考虑集群在每台主机上存储的数据占整体数据的百分比。如果某个特定主机上的百分比很大，而该主机出现故障，可能会导致超过 full ratio 等问题，从而导致Ceph停止工作，作为防止数据丢失的安全规范措施。
当你在每个主机上运行多个OSD时，你还需要确保内核是最新的。请参阅OS建议中关于glibc和syncfs（2）的说明，以确保你的硬件在每个主机上运行多个OSD时，能按照预期的方式执行。
考虑从机架上的10Gbps+网络开始。在1Gbps网络上复制1TB的数据需要3个小时，而10TB需要30个小时！相比之下，使用10Gbps网络，复制时间分别需要20分钟和1小时。在petabyte规模的集群中，OSD磁盘的故障应该是一种预期，而不是例外。在考虑到价格/性能权衡的情况下，系统管理员会很欣赏PG能尽快从降级状态恢复到活动+清洁状态。此外，一些部署工具采用VLANS使硬件和网络布线更易于管理。使用802.1q协议的运营成本节省所抵消。当使用VLAN来处理集群和计算堆栈（例如OpenStack、CloudStack等）之间的VM流量时，也值得考虑10G以太网。每个网络的架上路由器还需要能够与吞吐量更快的骨干路由器进行通信，例如40Gbps到100Gbps。
您的服务器硬件应该有一个底层管理控制器（BMC）。管理和部署工具也可能会大量使用BMC，因此要考虑带外网络的管理成本/收益权衡。Hypervisor SSH访问、VM镜像上传、操作系统镜像安装、管理套接字等都会给网络带来巨大的负载。运行三个网络可能看起来似乎矫枉过正，但每个流量路径都代表了潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前，您应该仔细考虑。
BMC：Baseboard Management Controller，基板管理控制器
带外网络：OOB，全程Out Of Band，一套与任何业务数据网络没有关联的独立网络，在任何时候——即便是业务网络终端的情况下，网络控制中心都可以通过带外网络连接到各个服务器或者网络设备的管理接口或者console.
故障域是指任何阻止一个或多个OSD的故障。这可能是主机上的守护进程停止；硬盘故障、操作系统崩溃、网卡故障、电源故障、网络中断、断电等等。在规划硬件需求的时候，你必须平衡一下，把太多的责任放在太少的故障域中来降低成本，以及隔离每个潜在故障域所带来的额外成本
Ceph可以在廉价的商品硬件上运行。小型生产集群和开发集群可以用适中的硬件成功运行
进程类型硬件类型建议的最低标准
ceph-osd Processor最低一核
200-500MB/s 单核心
1000-3000IOPS 单核心
结果是复制之前的结果
结果可能会因为不同的CPU型号和Ceph功能而不同（纠删码池、压缩等）
ARM处理器可能会需要更多的核心
实际性能取决于许多因素，包括磁盘、网络、客户端吞吐量和延迟。我们强烈建议进行基准测试
RAM每个守护进程4GB以上（越多越好）
2-4GB 可以正常工作（可能会很慢）
低于2GB是不推荐的
Volume Storage每个守护进程对应一块硬盘
DB/WAL每个守护进程对应一个SSD分区（可选）
Network最少一块千兆以上的网卡（万兆网卡是被推荐的） ceph-mon Processor最低一核
RAM每个进程2GB以上的内存
Disk Space每进程10GB以上的硬盘空间
Network最少一块千兆以上的网卡 ceph-mds Processor最低一核
RAM每个进程2GB以上的内存
Disk Space每个进程1MB以上的硬盘空间
Network最少一块千兆以上的网卡
openstack 后端存储ceph分布式搭建为什么不建议和raid搭配使用
如果ceph下用raid来做容错的话，没有意义，因为ceph已经解决了这个问题，
raid来加速的话，意义应该是有的；另外一方面应该可以从运维的角度来考虑；
一些粗浅理解，说不出更多理由；
日志时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理对多个OSD日志的写入请求。•分区对齐：SSD性能的一个常见问题是，人们喜欢将硬盘分区作为最佳做法，但往往忽略了对SSD的正确分区对齐，这样会导致SSD的数据传输速度更慢。确保
解决了这个问题，raid来加速的话，意义应该是有的；另外一方面应该可以从运维的角度来考虑；一些粗浅理解，说不出更多理由；
行而设计的，这使得构建和维护超大规模的数据集群在经济上是可行的。当规划出你的集群硬件时，你需要平衡一些考虑因素，包括故障域和潜在的性能问题。硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。一般来说，我们 建议在为该类型的守护进程配置的主机上运行特
说，我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。我们建议使用其他主机来处理使用您的数据集群的进程（例如OpenStack、CloudStack） Ceph