Hardware Recommendations【硬件推荐】

最新推荐文章于 2024-09-16 13:36:19 发布

weixin_33894992

最新推荐文章于 2024-09-16 13:36:19 发布

阅读量102

点赞数

文章标签：操作系统 python 运维

原文链接：https://my.oschina.net/skyrain/blog/390889

版权

2019独角兽企业重金招聘Python工程师标准>>>

‍‍

硬件推荐（内容提要）

1.CPU
2.RAM
3.Data Storage（数据存储）
3.1 Hard Disk Drives（硬盘驱动器）
3.2 Solid State Drives（固态硬盘）
3.3 Controllers（控制器）
3.4 Additional Considerations（其他注意事项）
4.Networks（网络）
5.Failure Domains（故障域）
6.Minimum Hardware Recommendations（最低硬件建议）
7.Production Cluster Example（生产集群示例）

硬件推荐‍‍

Ceph的目的是要在标准硬件上运行，这使得PB级数据集群的建设和维护从经济上来说是可行的。规划集群硬件时，需要平衡多方面的因素，包括故障域和潜在的性能问题。硬件规划应包括分布在许多主机上使用的Ceph的Ceph守护进程和其他进程。一般来说，我们建议某一特定类型，这种类型的守护进程配置为一台机器上只运行一种类型的守护进程。我们建议利用你的数据集群的进程时使用其他的主机（如OpenStack里面的CloudStack，等等）。

建议:也需要检查ceph日志。类似于Ceph Write Throughput 1, Ceph Write Throughput 2, Argonaut v. Bobtail Performance Preview, Bobtail Performance - I/O Scheduler Comparison的文章和其他的文章是一个很好的信息来源。

1.CPU

Ceph的元数据服务器动态地重新分配他们的负荷，这是CPU密集型。因此你的元数据服务器应该有足够的处理能力（如4核或更强悍）。的处理器Ceph的OSDs运行着RADOS服务、用CRUSH计算数据存放位置、复制数据、维护它自己的集群运行图副本。因此OSDs应该有一定的处理能力（如双核处理器）。监视器只是简单地维护着集群主副本，因此它们不是CPU密集型。除了运行Ceph的守护进程，你还必须考虑主机是否运行CPU密集型进程。例如，如果你的主机将运行用于计算的虚拟机（如OpenStack Nova）,你将要确保其他的进程为Ceph进程留下了足够的处理能力，我们建议在不同的主机上运行额外的CPU密集型进程。

2.RAM

元数据服务器和监视器必须能够快速的提供他们的数据，因此他们应该有足够的内存（例如，以每个守护进程为例需要1GB内存）。OSDs进行常规操作不需要太多的内存（例如，以每个守护进程为例需要500MB内存）；然而，在恢复过程期间很明显的它们需要更多的内存（例如，一个守护进程每存储1TB数据需要~1GB内存）。一般来说，更大的内存更好。

3.数据存储

谨慎规划你的数据存储配置。有显着的成本和性能折衷的考虑时可以规划数据存储。同步操作系统的操作，同时要求多个守护进程对单个驱动器的读取和写入操作会在很大程度上降低计算机性能。也要考虑文件系统限制：BTRFS对于生产是不太稳定的，但它有日志的功能，并同时写入数据，而XFS和ext4则没有。

重要提示：当Ceph的所有数据写入到日志，才可以发送一个ACK（至少XFS和EXT4），因此日志和OSDs平衡的表现真的很重要！

3.1硬盘驱动器

OSDs对象数据应该有足够的硬盘容量。我们推荐的最小的硬盘驱动器大小为1TB。考虑到较大的硬盘每GB的成本优势，我们建议硬盘驱动器的价格除以吉字节数得到每GB的成本，因为较大的磁盘驱动器在每GB的花费上可以具有显着的影响。例如，1TB的硬盘售价为$75.00 ，其成本为每GB0.07美元（即$ 75/1024 = 0.0732）。相比之下；3TB的硬盘售价为$150.00，其成本为每GB0.05美元（即$ 150/3072 = 0.0488）。在上述的例子中，使用1TB的磁盘，一般每GB的成本增加40％，构建集群远低于成本效益。此外，存储驱动器的容量更大，则你将需要更多的内存提供给每个OSD守护进程，尤其是在平衡、回填、恢复期间。一般经验法则是~1GB 内存，1TB的存储空间。

提示:在单个磁盘的分区上运行多个OSD不是一个好主意。

提示:在单个磁盘的分区上运行一个OSD和一个监视器或元数据服务不是一个好主意。

存储驱动器受寻道时间，访问时间，读取和写入时间，以及总吞吐量的限制。这些物理限制会影响整个系统的性能，尤其是在恢复过程中。我们建议为操作系统和软件使用专用的驱动器，并且为你在主机上运行每个OSD守护分配一个驱动器。大多数“慢OSD”的问题的产生是由于在一个操作系统同一驱动器上运行多个OSDs和/或多个日志。由于解决性能问题的一小部分的成本可能超过额外的磁盘驱动器的成本，因此你可以加快你的的集群设计规划，为了避免OSD存储驱动器负荷过重。

您可能在每个硬盘驱动器上同时运行多个Ceph的OSD守护程序，但是这可能会导致资源争用，并降低整体吞吐量。你可能把日志和对象数据存储在相同的驱动器上，但这样可能会增加所花费在记录写入操作和发送ACK给客户端的时间。在CEPH可以ACK对于写入操作前,Ceph必须把操作写入到日志。BTRFS文件系统的日志数据和对象数据的同时可以写，而XFS和ext4的不能。

Ceph的最佳做法决定，你应该分开在单独的驱动器上运行操作系统，OSD数据和OSD日志。

3.2固态硬盘

性能改进的机会之一是使用固态硬盘（SSD），以减少随机访问时间，读取等待时间，同时吞吐量加速。固态硬盘每GB的费用与硬盘驱动器相比往往超过10倍之多，但固态硬盘往往表现至少比硬盘驱动器快100倍的访问时间。

固态硬盘没有移动机械部件，所以他们不需要受同类型硬盘驱动器的限制。尽管固态硬盘有明显的局限性。重要的是考虑其连续读取和写入的性能。当存储多个OSDs的多个日志时，有400MB/s的顺序写入吞吐量的SSD的性能可能比120MB/s的顺序写入吞吐量的SSD更好。

重要提示:我们建议探索利用固态硬盘来提升性能。然而，在作出重大投资固态硬盘之前，我们强烈建议审查一个SSD的性能指标和在测试配置时测试SSD来衡量性能。

由于固态硬盘没有移动机械部件，在Ceph的领域使用它们而不使用大量的存储空间是有道理的（例如，日志）。相对便宜的固态硬盘可能会吸引到你的经济头脑。谨慎使用。当SSD和Ceph一起用时，仅仅可以运行的IOPS是不够的。日志和SSD有几个重要的性能方面的考虑：

•写入密集型的语义：日志涉及写入密集型的语义，因此你应该确保当你写入数据时，你选择的SSD部署将等于或优于硬盘驱动器。廉价的固态硬盘，甚至可能会为了加快访问时间而引入写入延迟，因为有时高性能硬盘驱动器在写入上可以和一些市场上现有的更经济的固态硬盘一样快，甚至更快！

•连续写入：当你在SSD上储存多个日志时，你也必须考虑SSD连续写入的限制太多，因为它们可能在处理请求的同时会写入多个OSD日志。

•分区对齐： SSD性能的一个常见问题，因为人们喜欢为驱动器分区作为最佳实践，但他们往往忽略了适当的固态硬盘分区对齐，这可能会导致固态硬盘的数据传输速度要慢得多。确保SSD分区正确对齐。

虽然固态硬盘的OSD对象存储成本高昂，通过存储一个OSD的日志在一个单独的硬盘驱动器SSD和OSD的对象数据上时，OSDs上可能会看到一个显着的性能提升。OSD日志配置默认在/var/lib/ceph/osd/$cluster-$id/journal里。你可以挂载这个路径到SSD或SSD的分区上，以至于它不只是在同一磁盘上的一个文件对象数据。

Ceph使CephFS的文件系统性能加速的一个方法是在CephFS文件内容的存储中分开存储CephFS元数据。Ceph为CephFS元数据提供了一个默认的元数据池。你永远不能为CephFS元数据创建一个元数据池，但是你可以为仅指向一台主机的SSD存储介质的CephFS元数据池创建一个CRUSH的映射层。见池映射到不同类型的OSD获取更多细节。

3.3控制器

磁盘控制器对于写入吞吐量也有显着的影响。谨慎考虑你选择的磁盘控制器，以确保他们不会创建一个性能瓶颈。

建议:Ceph的日志往往是Ceph的性能问题一个很好的信息来源。为了获取更多详细信息，请参阅 Ceph Write Throughput 1 和 Ceph Write Throughput 2

3.4其他注意事项

您可以在每台主机上运行多个OSD，但你应该确保你的OSD硬盘总吞吐量的总和不超过所需的用来服务客户端需要来读取或写入数据的网络带宽。您还应该考虑在每个主机上的集群存储的整体数据百分比。如果特定主机上的比例大并且主机发生故障，它可能会导致问题，比如超负荷，这会导致CEPH因为防止数据丢失的安全警告而停止操作。

当你在每台主机运行多个OSDs时，你还需要保证内核是最新的。请参阅推荐操作系统的glibc和 syncfs（2）以确保您的硬件当在每台主机上运行多个OSD时的执行像先前预计的那样。

4.网络

建议每台机器最少两个千兆网卡，现在大多数普通硬盘吞的吐量都能达到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等等）时，采用10G网卡值得考虑使用。每个网络的顶级机架路由器到核心路由器通信应该有更快的吞吐量，例如，40Gbps~100Gbps。

你的服务器硬件上应该配置底板管理控制器（Baseboard Management Controller，BMC），管理和部署工具也应该大规模使用BMC，所以考虑一个带外网络管理成本/本效益平衡。Hypervisor的SSH访问，VM图像上传，操作系统的映像安装，套接字管理等，会使网络上的负载增加很明显。运行三个网络看起来有些浪费，但没个通信路径代表一个潜在的容量，在部署大规模数据集群之前，你应该谨慎考虑吞吐量和/或性能瓶颈。

5.故障域

故障域指任何导致不能访问一个或多个OSD的故障，这可能是停止了主机上的守护程序、硬盘故障，操作系统崩溃，网卡发生故障、电源供应器故障、网络中断、停电等等。规划出你的硬件需求时，你必须权衡付出很多努力来减少故障域带来的成本削减、隔离每个潜在故障域增加的成本的诱惑。

6.最低硬件建议

Ceph可以运行在廉价的普通硬件上，小型生产集群和开发集群可以在一般的硬件上。

过程标准最低配置推荐

ceph OSD处理器1X 64位AMD-64/i386的双核

RAM每个守护500 MB

存储卷每个守护1X磁盘

网络2个1GB以太网网卡

ceph mon处理器1X 64位AMD-64/i386

RAM1 GB的守护

磁盘空间10 GB每守护