Skip to content

Latest commit

 

History

History
283 lines (215 loc) · 17 KB

01硬件需求.md

File metadata and controls

283 lines (215 loc) · 17 KB
Raw

硬件需求

Ceph被设计成在普通硬件上运行，这使得构建和维护pb级数据集群在经济上可行,在规划集群硬件时，需要平衡许多考虑因素，包括故障域和潜在的性能问题。 硬件规划应该包括在多个主机上分布Ceph守护进程和其他使用Ceph的进程。官方建议在为特定类型的守护进程配置的主机上运行特定类型的Ceph守护进程。

即ceph集群与客户端应为不同宿主机，具体硬件需求参考如下：

CPU

Ceph元数据服务器动态地重新分配它们的负载，这是CPU密集型的。因此，元数据服务器应该具有强大的处理能力(例如，四核或更好的cpu)。ceph osds运行RADOS服务，使用CRUSH计算数据位置，复制数据，并维护它们自己的集群映射副本。 因此，OSD应该具有合理的处理能力(例如，双核处理器)。监视器只是维护集群映射的主副本，因此它们不是CPU密集型的。 您还必须考虑主机除了运行Ceph守护进程外，是否还将运行cpu密集型进程。 例如，如果您的主机将运行计算虚拟机(例如OpenStack Nova)，您将需要确保这些其他进程为Ceph守护进程留出足够的处理能力。 建议在不同的主机上运行额外的cpu密集型进程

样例集群CPU配置：

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                72
On-line CPU(s) list:   0-71
Thread(s) per core:    2
Core(s) per socket:    18
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz
Stepping:              7
CPU MHz:               999.914
CPU max MHz:           3900.0000
CPU min MHz:           1000.0000
BogoMIPS:              5200.00
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              25344K
NUMA node0 CPU(s):     0-17,36-53
NUMA node1 CPU(s):     18-35,54-71
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 invpcid_single intel_ppin intel_pt ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke avx512_vnni md_clear spec_ctrl intel_stibp flush_l1d arch_capabilities

内存

内存越多越好

  • CEPH-MON&CEPH-MGR（监控、管理节点）: 监视器和管理器守护进程的内存使用情况通常随集群的大小而变化。对于小型集群， 一般1-2GB就足够了。对于大型集群，您应该提供更多(5-10GB)。 您可能还需要考虑调整mon_OSD_cache_size或rocksdb_cache_size等设置

  • CEPH-MDS元数据节点 : 元数据守护进程的内存利用率取决于它的缓存被配置为消耗多少内存。对于大多数系统，官方建议至少使用1GB。具体大小可调整mds_cache_memory

  • OSDS(CEPH-OSD)存储节点：默认情况下，使用BlueStore后端的OSD需要3-5GB RAM。当使用BlueStore时， 可以通过配置选项OSD_memory_target来调整OSD的内存消耗。当使用遗留的FileStore后端时， 操作系统页面缓存用于缓存数据，所以通常不需要进行调优，并且OSD的内存消耗通常与系统中每个守护进程的PGs数量有关。

样例集群内存配置：

              total        used        free      shared  buff/cache   available
Mem:           187G        8.8G        164G        4.0G         13G        173G
Swap:            0B          0B          0B

存储

请仔细规划您的数据存储配置。在规划数据存储时，需要考虑大量的成本和性能折衷。 同时进行OS操作，以及多个守护进程对单个驱动器同时进行读和写操作的请求会显著降低性能。

注意：

因为Ceph在发送ACK之前必须把所有的数据都写到日志中(至少对于XFS来说是这样)，让日志和OSD的性能平衡是非常重要的!

  • 硬盘驱动器

    OSD应该有足够的硬盘驱动器空间来存放对象数据。官方建议硬盘驱动器的最小大小为1TB。 考虑较大磁盘的每GB成本优势。官方建议将硬盘驱动器的价格除以千兆字节数，得出每千兆字节的成本，因为较大的驱动器可能对每千兆字节的成本有很大的影响。 例如，价格为$75.00的1TB硬盘的成本为每GB$0.07(即$75 / 1024 = 0.0732)。 相比之下，价格为150美元的3TB硬盘的成本为每GB 0.05美元(即150美元/ 3072 = 0.0488)。 在前面的示例中，使用1TB的磁盘通常会使每GB的成本增加40%——从而大大降低集群的成本效率。 此外，存储驱动器容量越大，每个ceph osd守护进程需要的内存就越多，尤其是在重新平衡、回填和恢复期间。 一般的经验法则是1TB的存储空间需要1GB的RAM

    存储驱动器受到寻道时间、访问时间、读和写时间以及总吞吐量的限制。 这些物理限制会影响整个系统的性能——尤其是在恢复过程中。 官方建议为操作系统和软件使用专用的驱动器，为主机上运行的每个ceph osd守护进程使用一个驱动器(物理硬盘)。 大多数慢OSD问题是由于在同一个驱动器上运行一个操作系统、多个OSD和/或多个日志引起的。 由于在小型集群上故障排除性能问题的成本可能会超过额外磁盘驱动器的成本，因此可以通过避免过度使用OSD存储驱动器来加速集群设计规划

    您可以在每个硬盘驱动器上运行多个ceph osd进程，但这可能会导致资源争用，并降低总体吞吐量。 您可以将日志和对象数据存储在同一个驱动器上，但这可能会增加向客户端记录写操作和ACK所需的时间。 Ceph必须先向日志写入数据，然后才能对写入数据进行验证

总结为：Ceph最佳实践规定，您应该在不同的驱动器上运行操作系统、OSD数据和OSD日志

  • 固态硬盘

    提高性能的一个机会是使用固态驱动器(SSD)来减少随机访问时间和读取延迟，同时加速吞吐量。 与硬盘驱动器相比，SSD每GB的成本通常超过10倍，但SSD的访问时间通常至少比硬盘驱动器快100倍

    SSD没有可移动的机械部件，因此它们不必受到与硬盘驱动器相同类型的限制。不过SSD确实有很大的局限性。 在评估SSD时，考虑顺序读写的性能是很重要的。 当存储多个OSD的多个日志时，顺序写吞吐量为400MB/s的SSD可能比顺序写吞吐量为120MB/s的SSD性能更好

    由于SSD没有可移动的机械部件，所以在Ceph中不需要大量存储空间的区域使用SSD是有意义的。 相对便宜的固态硬盘可能会吸引你的经济意识。谨慎使用。 当选择与Ceph一起使用的SSD时，可接受的IOPS是不够的。对于日志和SSD有几个重要的性能考虑因素:

    • 写密集型语义:日志记录涉及写密集型语义，因此您应该确保选择部署的SSD在写入数据时的性能等于或优于硬盘驱动器。 廉价的SSD可能会在加速访问时间的同时引入写延迟，因为有时高性能硬盘驱动器的写速度可以与市场上一些更经济的SSD一样快甚至更快!
    • 顺序写:当您在一个SSD上存储多个日志时，您还必须考虑SSD的顺序写限制，因为它们可能会同时处理多个OSD日志的写请求。
    • 分区对齐:SSD性能的一个常见问题是，人们喜欢将驱动器分区作为最佳实践，但他们常常忽略了使用SSD进行正确的分区对齐，这可能导致SSD传输数据的速度慢得多。确保SSD分区对齐

    虽然SSD存储对象的成本非常高，但是通过将OSD的日志存储在SSD上，将OSD的对象数据存储在单独的硬盘驱动器上，可以显著提高OSD的性能。 OSD日志配置默认为/var/lib/ceph/OSD/$cluster-$id/journal。您可以将此路径挂载到SSD或SSD分区上，使其与对象数据不只是同一个磁盘上的文件

    Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储隔离。 Ceph为cepfs元数据提供了一个默认的元数据池。您永远不必为CephFS元数据创建一个池，但是您可以为仅指向主机的SSD存储介质的CephFS元数据池创建一个CRUSH map层次结构。

重要提示: 官方建议探索SSD的使用以提高性能。但是，在对SSD进行重大投资之前，官方强烈建议检查SSD的性能指标，并在测试配置中测试SSD，以评估性能

  • 控制器

    磁盘控制器对写吞吐量也有很大的影响。仔细考虑磁盘控制器的选择，以确保它们不会造成性能瓶颈。

  • 注意事项

    你可以在每个主机上运行多个OSD，但是你应该确保OSD硬盘的总吞吐量不超过客户端读写数据所需的网络带宽。 您还应该考虑集群在每个主机上存储的总体数据的百分比。如果某个主机上的百分比很大，并且该主机发生故障，那么它可能会导致一些问题，比如超过了完整的比例，这将导致Ceph停止操作，作为防止数据丢失的安全预防措施。

    当您在每个主机上运行多个OSD时，还需要确保内核是最新的。请参阅OS推荐，了解glibc和syncfs(2)方面的注意事项，以确保在每个主机上运行多个OSD时，您的硬件能够像预期的那样执行

    拥有大量OSD的主机(例如> 20)可能会产生大量线程，特别是在恢复和平衡过程中。许多Linux内核默认的最大线程数相对较小(例如，32k)。如果在拥有大量OSD的主机上启动OSD时遇到问题，请考虑设置kernel。将pid_max设置为更高的线程数。理论最大值是4,194,303线程。 例如，您可以将以下内容添加到/etc/sysctl.conf文件中:

kernel.pid_max = 4194303

样例集群存储配置：

Disk /dev/nvme0n1: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme1n1: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme2n1: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme3n1: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdb: 960.2 GB, 960197124096 bytes, 1875385008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sda: 480.1 GB, 480103981056 bytes, 937703088 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: EDC26861-DACE-4831-848D-4FA0C5F642D7


#         Start          End    Size  Type            Name
 1         2048      2099199      1G  EFI System      EFI System Partition
 2      2099200      4196351      1G  Microsoft basic
 3      4196352    937701375  445.1G  Linux LVM

Disk /dev/sde: 960.2 GB, 960197124096 bytes, 1875385008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sdd: 960.2 GB, 960197124096 bytes, 1875385008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sdg: 960.2 GB, 960197124096 bytes, 1875385008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/sdf: 960.2 GB, 960197124096 bytes, 1875385008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sdh: 960.2 GB, 960197124096 bytes, 1875385008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 5F151167-14E6-4826-BBEB-55280AC27EEC


#         Start          End    Size  Type            Name
 1     10487808   1875384974  889.3G  ceph osd        ceph data
 2         2048     10487807      5G  Ceph Journal    ceph journal

Disk /dev/sdc: 960.2 GB, 960197124096 bytes, 1875385008 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/centos-root: 478.0 GB, 477953523712 bytes, 933502976 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

网络

官方说明如下:

  • 每个主机至少有两个1Gbps的网络接口控制器(nic)。由于大多数普通硬盘驱动器的吞吐量大约为100MB/秒，您的网卡应该能够处理主机上OSD磁盘的流量
  • 建议至少使用两个网卡来考虑公共(前端)网络和集群(后端)网络。集群网络(最好不连接到外部网络)处理数据复制的额外负载
  • 通过1Gbps的网络复制1TB的数据需要3个小时，3TB(典型的驱动器配置)需要9个小时。相比之下，在10Gbps的网络中，复制时间将分别为20分钟和1小时。
  • 在pb级集群中，OSD磁盘故障应该是一种预期，而不是异常。系统管理员希望PGs尽可能快地从降级状态恢复到active + clean状态，同时考虑到价格/性能权衡。 此外，一些部署工具(如戴尔的Crowbar)可以部署5个不同的网络，但使用vlan使硬件和网络电缆更易于管理。使用802.1q协议的vlan需要支持vlan的网卡和交换机。增加的硬件费用可能会被网络设置和维护的操作成本节省所抵消
  • 当使用vlan处理集群与计算栈(如OpenStack、CloudStack等)之间的虚拟机流量时，也值得考虑使用10G以太网。 每个网络的机架顶部路由器也需要能够与具有更快吞吐量的脊柱路由器进行通信。40Gbps到100Gbps
  • 您的服务器硬件应该有一个底板管理控制器(BMC)。管理和部署工具也可能广泛地使用bmc， 因此考虑使用带外网络进行管理的成本/收益权衡。管理程序SSH访问、VM镜像上传、操作系统镜像安装、管理套接字等都可能给网络带来巨大的负载。 运行三个网络可能看起来有点小题大做，但每个流量路径都代表一个潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前，您应该仔细考虑这些问题

简言之： 建议三个以上网络接口：

  • ceph集群网络接口
  • 对外网络接口
  • 管理接口

样例集群网口配置：

[root@ceph01 ~]#  ethtool ens4f0
Settings for ens4f0:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: No
        Supported FEC modes: Not reported
        Advertised link modes:  10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes