ceph中文文档(官方翻译版)

简介Ceph存储集群至少需要1个CephMonitor和2个OSD守护进程运行Ceph文件系统客户端时，则必须要有元数据服务器（MetadataServer）。CephOSDs:CephOSD守护进程（CephOSD）的功能：存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD守护进程的心跳来向CephMonitors提供一些监控信息。当Ceph存储集群设定为有2个副本时，至少需要2个OSD守护进程，集群才能达到active+clean状态（Ceph默认有3个副本，但你可以调整副本数）。Monitors:CephMonitor维护着展示集群状态的各种图表，包括监视器映射、OSD映射、归置组（PG）映射、和CRUSH映射。Ceph保存着发生在Monitors、OSD和PG上的每一次状态变更的历史信息（称为epoch）。MDSs:Ceph元数据服务器（MDS）为Ceph文件系统存储元数据（也就是说，Ceph块设备和Ceph对象存储不使用MDS）。元数据服务器使得POSIX文件系统的用户们，可以在不对Ceph存储集群造成负担的前提下，执行诸如ls、find等基本命令。Ceph把客户端数据保存为存储池内的对象。通过使用CRUSH算法，Ceph可以计算出哪个归置组（PG）应该持有指定的对象(Object)，然后进一步计算出哪个OSD守护进程持有该归置组。CRUSH算法使得Ceph存储集群能够动态地伸缩、再均衡和修复。硬件推荐Ceph为普通硬件设计，这可使构建、维护PB级数据集群的费用相对低廉。规划集群硬件时，需要均衡几方面的因素，包括区域失效和潜在的性能问题。硬件规划要包含把使用Ceph集群的Ceph守护进程和其他进程恰当分布。通常，我们推荐在一台机器上只运行一种类型的守护进程。我们推荐把使用数据集群的进程（如OpenStack、CloudStack等）安装在别的机器上。Tip关于Ceph的高品质博客文章也值得参考，比如CephWriteThroughput1、CephWriteThroughput2、Argonautv.BobtailPerformancePreview、BobtailPerformance-I/OSchedulerComparison。CPUCeph（MDS）元数据服务器对CPU敏感，它会动态地重分布它们的负载，所以你的元数据服务器应该有足够的处理能力（如4核或更强悍的CPU）。Ceph的OSD运行着RADOS服务、用CRUSH计算数据存放位置、复制数据、维护它自己的集群运行图副本，因此OSD需要一定的处理能力（如双核CPU）。监视器只简单地维护着集群运行图的副本，因此对CPU不敏感；但必须考虑机器以后是否还会运行Ceph监视器以外的CPU密集型任务。例如，如果服务器以后要运行用于计算的虚拟机（如OpenStackNova），你就要确保给Ceph进程保留了足够的处理能力，所以我们推荐在其他机器上运行CPU密集型任务。RAM内存元数据服务器和监视器必须可以尽快地提供它们的数据，所以他们应该有足够的内存，至少每进程1GB。OSD的日常运行不需要那么多内存（如每进程500MB）差不多了；然而在恢复期间它们占用内存比较大（如每进程每TB数据需要约1GB内存）。通常内存越多越好。数据存储要谨慎地规划数据存储配置，因为其间涉及明显的成本和性能折衷。来自操作系统的并行操作和到单个硬盘的多个守护进程并发读、写请求操作会极大地降低性能。文件系统局限性也要考虑：btrfs尚未稳定到可以用于生产环境的程度，但它可以同时记日志并写入数据，而xfs和ext4却不能。Important因为Ceph发送ACK前必须把所有数据写入日志（至少对xfs和ext4来说是），因此均衡日志和OSD性能相当重要。硬盘驱动器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所需内存就越大，特别是在重均衡、回填、恢复期间。根据经验，1TB的存储空间大约需要1GB内存。Tip不顾分区而在单个硬盘上运行多个OSD，这样不明智！Tip不顾分区而在运行了OSD的硬盘上同时运行监视器或元数据服务器也不明智！存储驱动器受限于寻道时间、访问时间、读写时间、还有总吞吐量，这些物理局限性影响着整体系统性能，尤其在系统恢复期间。因此我们推荐独立的驱动器用于安装操作系统和软件，另外每个OSD守护进程占用一个驱动器。大多数“slowOSD”问题的起因都是在相同的硬盘上运行了操作系统、多个OSD、和/或多个日志文件。鉴于解决性能问题的成本差不多会超过另外增加磁盘驱动器，你应该在设计时就避免增加OSD存储驱动器的负担来提升性能。Ceph允许你在每块硬盘驱动器上运行多个OSD，但这会导致资源竞争并降低总体吞吐量；Ceph也允许把日志和对象数据存储在相同驱动器上，但这会增加记录写日志并回应客户端的延时，因为Ceph必须先写入日志才会回应确认了写动作。btrfs文件系统能同时写入日志数据和对象数据，xfs和ext4却不能。Ceph最佳实践指示，你应该分别在单独的硬盘运行操作系统、OSD数据和OSD日志。固态硬盘一种提升性能的方法是使用固态硬盘（SSD）来降低随机访问时间和读延时，同时增加吞吐量。SSD和硬盘相比每GB成本通常要高10倍以上，但访问时间至少比硬盘快100倍。SSD没有可移动机械部件，所以不存在和硬盘一样的局限性。但SSD也有局限性，评估SSD时，顺序读写性能很重要，在为多个OSD存储日志时，有着400MB/s顺序读写吞吐量的SSD其性能远高于120MB/s的。Important我们建议发掘SSD的用法来提升性能。然而在大量投入SSD前，我们强烈建议核实SSD的性能指标，并在测试环境下衡量性能。正因为SSD没有移动机械部件，所以它很适合Ceph里不需要太多存储空间的地方。相对廉价的SSD很诱人，慎用！可接受的IOPS指标对选择用于Ceph的SSD还不够，用于日志和SSD时还有几个重要考量：写密集语义：记日志涉及写密集语义，所以你要确保选用的SSD写入性能和硬盘相当或好于硬盘。廉价SSD可能在加速访问的同时引入写延时，有时候高性能硬盘的写入速度可以和便宜SSD相媲美。顺序写入：在一个SSD上为多个OSD存储多个日志时也必须考虑SSD的顺序写入极限，因为它们要同时处理多个OSD日志的写入请求。分区对齐：采用了SSD的一个常见问题是人们喜欢分区，却常常忽略了分区对齐，这会导致SSD的数据传输速率慢很多，所以请确保分区对齐了。SSD用于对象存储太昂贵了，但是把OSD的日志存到SSD、把对象数据存储到独立的硬盘可以明显提升性能。osdjournal选项的默认值是/var/lib/ceph/osd/$cluster-$id/journal，你可以把它挂载到一个SSD或SSD分区，这样它就不再是和对象数据一样存储在同一个硬盘上的文件了。提升CephFS文件系统性能的一种方法是从CephFS文件内容里分离出元数据。Ceph提供了默认的metadata存储池来存储CephFS元数据，所以你不需要给CephFS元数据创建存储池，但可以给它创建一个仅指向某主机SSD的CRUSH运行图。详见给存储池指定OSD。控制器硬盘控制器对写吞吐量也有显著影响，要谨慎地选择，以免产生性能瓶颈。TipCephblog通常是优秀的Ceph性能问题来源，见CephWriteThroughput1和CephWriteThroughput2。其他注意事项你可以在同一主机上运行多个OSD，但要确保OSD硬盘总吞吐量不超过为客户端提供读写服务所需的网络带宽；还要考虑集群在每台主机上所存储的数据占总体的百分比，如果一台主机所占百分比太大而它挂了，就可能导致诸如超过fullratio的问题，此问题会使Ceph中止运作以防数据丢失。如果每台主机运行多个OSD，也得保证内核是最新的。参阅操作系统推荐里关于glibc和syncfs(2)的部分，确保硬件性能可达期望值。OSD数量较多（如20个以上）的主机会派生出大量线程，尤其是在恢复和重均衡期间。很多Linux内核默认的最大线程数较小（如32k个），如果您遇到了这类问题，可以把kernel.pid_max值调高些。理论最大值是4194303。例如把下列这行加入/etc/sysctl.conf文件：kernel.pid_max=4194303网络建议每台机器最少两个千兆网卡，现在大多数机械硬盘都能达到大概100MB/s的吞吐量，网卡应该能处理所有OSD硬盘总吞吐量，所以推荐最少两个千兆网卡，分别用于公网（前端）和集群网络（后端）。集群网络（最好别连接到国际互联网）用于处理由数据复制产生的额外负载，而且可防止拒绝服务攻击，拒绝服务攻击会干扰数据归置组，使之在OSD数据复制时不能回到active+clean状态。请考虑部署万兆网卡。通过1Gbps网络复制1TB数据耗时3小时，而3TB（典型配置）需要9小时，相比之下，如果使用10Gbps复制时间可分别缩减到20分钟和1小时。在一个PB级集群中，OSD磁盘失败是常态，而非异常；在性价比合理的的前提下，系统管理员想让PG尽快从degraded（降级）状态恢复到active+clean状态。另外，一些部署工具（如Dell的Crowbar）部署了5个不同的网络，但使用了VLAN以提高网络和硬件可管理性。VLAN使用802.1q协议，还需要采用支持VLAN功能的网卡和交换机，增加的硬件成本可用节省的运营（网络安装、维护）成本抵消。使用VLAN来处理集群和计算栈（如OpenStack、CloudStack等等）之间的VM流量时，采用10G网卡仍然值得。每个网络的机架路由器到核心路由器应该有更大的带宽，如40Gbps到100Gbps。服务器应配置底板管理控制器（BaseboardManagementController,BMC），管理和部署工具也应该大规模使用BMC，所以请考虑带外网络管理的成本/效益平衡，此程序管理着SSH访问、VM映像上传、操作系统安装、端口管理、等等，会徒增网络负载。运营3个网络有点过分，但是每条流量路径都指示了部署一个大型数据集群前要仔细考虑的潜能力、吞吐量、性能瓶颈。故障域故障域指任何导致不能访问一个或多个OSD的故障，可以是主机上停止的进程、硬盘故障、操作系统崩溃、有问题的网卡、损坏的电源、断网、断电等等。规划硬件需求时，要在多个需求间寻求平衡点，像付出很多努力减少故障域带来的成本削减、隔离每个潜在故障域增加的成本。最低硬件推荐Ceph可以运行在廉价的普通硬件上，小型生产集群和开发集群可以在一般的硬件上。进程条件最低建议ceph-osdProcessor1x64-bitAMD-641x32-bitARMdual-coreorbetter1xi386dual-coreRAM~1GBfor1TBofstorageperdaemonVolumeStorage1xstoragedriveperdaemonJournal1xSSDpartitionperdaemon(optional)Network2x1GBEthernetNICsceph-monProcessor1x64-bitAMD-64/i3861x32-bitARMdual-coreorbetter1xi386dual-coreRAM1GBperdaemonDiskSpace10GBperdaemonNetwork2x1GBEthernetNICsceph-mdsProcessor1x64-bitAMD-64quad