YDB依赖的硬件环境详解

YDB依赖的硬件环境详解

硬件如何搭配,能做到比较高的性价比,不存在短板。合理的硬件搭配,对系统的稳定性也很关键。

1.CPU不是核数越高越好,性价比才是关键。

      经常遇到很多的企业级客户,他们机器配置非常高,CPU128 VCore256G内存,但是只挂载了18TSATA硬盘,千兆网卡。

      这样的机器配置比较适合计算密集型的业务,但是如果是IO密集型的业务的话,就会发现磁盘成为瓶颈,会发现磁盘利用率100%,网络利用率100%,但是CPU只用了不到5%。存在巨大的资源浪费。

      这种问题在Hadoop系统中尤为突出,如果是这样的配置的话,很可能一个MapReduce程序就会导致全部的磁盘与网络都是使用率100%,这样所有的心跳都发送不出来,而本身Hadoop又没有很好的网络限速机制,就会导致DataNodeTaskManager陆续的因为心跳超时而挂掉。

2.SASSATASSD 磁盘的选择与对比

       IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数),是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量,I/O请求通常为读或写数据操作请求。对于随机读写频繁的应用,如OLTP(Online Transaction Processing)IOPS是关键衡量指标。

       吞吐量(Throughput),指单位时间内可以成功传输的数据数量。对于大量顺序读写的应用,如VOD(Video On Demand),则更关注吞吐量指标。

       一般SSDIOPS是普通磁盘的千倍以上,但是吞吐量只是普通磁盘的2倍左右。所以如果我们的业务是顺序读写偏多的则建议选用普通SAS盘(如存储形业务,以及Hive的文本数据分析),但是如果我们的业务是随机读写偏多,那么选择SSD 更划算(如采用列存储的系统,以及YDB的索引系统)

       如下图所示,普通磁盘的IOPSSSD磁盘的性能相差悬殊,特别是企业级SSD磁盘,能相差千倍以上。

 

 

       吞吐量:连续读写速度,性能提升在2倍左右。


 

 

3.SSD的颗粒请不要选择TLC

TLC的寿命太短,虽然便宜,但是用不了几个月就基本报废,一般个人电脑使用。不适合企业级使用,性价比较好的建议选用MLC颗粒。

 

SSD颗粒目前主要分三种:SLCMLCTLC

      SLC=Single-LevelCell,即1bit/cell,速度快寿命长,价格超贵(约MLC3倍以上的价格),约10万次擦写寿命
       MLC=Multi-LevelCell,即2bit/cell,速度一般寿命一般,价格一般,约3000---10000次擦写寿命
       TLC=Trinary-LevelCell,即3bit/cell,也有Flash厂家叫8LC,速度相对慢寿命相对短,价格便宜,约500次擦写寿命,目前还没有厂家能做到1000次擦写。

      简单地说SLC的性能最优,价格超高。一般用作企业级或高端发烧友。MLC性能够用,价格适中为消费级SSD应用主流,TLC综合性能最低,价格最便宜。但可以通过高性能主控、主控算法来弥补、提高TLC闪存的性能。

 

4.延云YDB建议的硬件配置

一、延云YDB最低配置

1.内存:32G

2.磁盘:

             离线模式:至少2块独立的物理硬盘分别用于HDFS数据盘、系统盘。

             实时模式:至少3块独立的物理磁盘分别用于Kafka数据盘,HDFS数据盘、系统盘

3.CPU:至少8线程(1,4,8线程)

二、如下场景,延云将不再提供安装技术支持

1.低于最低配置要求的用户。

2.32位系统的用户:这类系统最大只有4G内存。

三、延云YDB高性能配置 (毫秒响应)

1.机器内存:128G

2.磁盘:企业级SSD600~800G*12个磁盘

3.CPU32线程(2,16,32线程)

4.万兆网卡

三、延云YDB常规配置 (秒级响应)

1.机器内存:128G

2.磁盘:2T*12的磁盘

3.CPU24线程(2,12,24线程)

4.千兆网卡

 

 

 

二、磁盘如何挂载?

    1.逻辑卷的问题

      一般很多Linux的默认安装,会将磁盘直接以逻辑卷的方式挂载,逻辑卷的优点是后期的扩容以及调整磁盘非常的方便,看着比RAID好用多了,但是默认的逻辑卷配置方式是只有一块盘在工作 ,其他几块盘都闲着,发挥不出来多块盘的性能,也就是说如果在逻辑卷里面挂了10块盘,那么默认的逻辑卷的配置,只能发挥出一块盘的性能。所以对于YDB系统来说,大家不要使用逻辑卷。

    2.关于RAID

      有些客户比较担心数据丢失,将磁盘做了RAID10或者RAID5,其实这样是没有必要的,因为本身默认配置Hadoop是有三份副本的,并不怕磁盘损坏。RAID10RAID5会导致磁盘容量只有原先的一半,由于需要双写,磁盘整体吞吐量降低了一倍。而且RAID5一旦损坏了一块磁盘,就需要通过奇偶校验还原数据,读的吞吐量直接降低到原先了五分之一,而且更换新盘后,通过校验要还原原先盘的数据的时候,经常会发生雪崩现象,IO瞬间增大,导致其他盘陆续的跟着挂掉。所以对于YDB系统来说,不推荐使用RAID 10RAID5.还有一些客户,会将所有的盘都做成一个完整的RAID0RAID0的缺点就是一块盘损坏,整个系统就坏掉,但是RAID0确实会比单块磁盘速度好,所以如果能做raid0我更推荐2个盘组成一起做一个RAID0,而不是整体所有磁盘都做成一个RAID0.

    3.关于系统盘与数据盘

      好多客户,在挂盘的时候,为了节省磁盘空间,更充分的利用资源,会将一个8T的物理磁盘划分成两个逻辑分区,一个逻辑分区作为系统盘,另一个逻辑分区作为数据盘。但是数据盘一般会比较繁忙的,但是由于他们底层都共用的是同一块物理磁盘,就会导致系统盘实际上也会特别繁忙,系统盘繁忙会导致整个系统会变的非常的慢,执行任何Linux命令都很慢,Socket连接建立也缓慢,很多系统会因此而超时断线,所以延云YDB建议操作系统要独立一块磁盘,数据盘不要与操作系统共用同一块盘,否则数据盘很慢的时候,运行在操作系统上的软件都跟着慢,ZooKeeper之类的服务也很容易挂掉。

      另外还有一部分客户,可能因某种习惯,默认会给系统盘的跟目录预留的存储空间特别小,比如说只预留了10~30G的空间,这样其实对大数据系统来说风险较大,以Ambari为例,他的log默认是记录在/var/log下的,这30G的空间会很快的被LOG记满,大家都知道一旦操作系统根目录满了意味着什么? 将是所有服务不可用,这样隐患太大了。所以延云建议系统跟目录尽量留大一点的磁盘空间,如200G,默认CentOS给分配50G空间也太小,如果Hadoop等日志没有及时清理掉,将来隐患较大

 

 

 

    4.关于磁盘阵列与云

      有相当一部分的客户使用云服务器,将机器虚拟化后确实节省了很多的资源,提高了硬件的利用率。目前的云服务器有相当一部分的解决方案是采用外挂存储的方式将磁盘统一的挂载到远程的一个磁盘阵列上去。这个时候磁盘阵列是单点,一旦发生断电或者磁盘阵列出现问题,因为Hadoop的三分副本都存储在这一个磁盘阵列上,一但丢失就会导致整个Hadoop集群不可用。如果有条件,我更建议做多个磁盘阵列而不是一个磁盘阵列单点,这样通过Hadoop的机架策略,可以将 Hadoop 的三份副本分别存储在不同的磁盘阵列上,NameNode以及SNameNode也分别存储在不同的磁盘阵列上,这样即使其中一个磁盘阵列出现了故障,我们的Hadoop也能够恢复服务,而且不丢数据。

      另外由于虚拟化以后,一个真实的物理机上面可能会开多个虚拟机,如果这个物理机硬件发生损坏,这个物理机上的虚拟机也有异常,三个副本都存储在这台机器上的文件的数据会丢失,延云建议虚拟机厂商与Hadoop厂商协同,采用Hadoop机架技术,将位于同一物理机上的虚拟机标记在同一个机架上,以免造成数据丢失。

      虚拟化后也存在系统盘与数据盘的问题,虽然在虚拟机里看到了系统盘与数据盘确实分离了,但是在物理机上有可能是在虚拟机A里面的系统盘,又作为了虚拟机B的数据盘,这样当虚拟机B的数据盘特别繁忙的时候,会造成虚拟机A的响应非常慢。针对这种情况延云YDB建议,将物理机的磁盘分类,一些磁盘专门用于挂系统盘,一些磁盘专门用于挂数据盘,不允许交叉使用,即不允许一个物理盘即挂数据盘又被挂成系统盘

    5.将大磁盘空间的硬盘与小磁盘空间的硬盘混合挂载

      可能是处于历史原因,部分客户的系统上出现了大小盘混合挂载的情况,比如说10块磁盘,有的是300G,有的是8T的磁盘,他们混搭在一起。但是目前的hadoop对这样的盘支持的并不友好,会出现300G的硬盘已经满了,8T的硬盘还没使用到原先的十分之一的情况,针对这种情况,延云建议数据盘尽量大小一样,别出现有的盘很大,有的盘很小的情况。那种300G的磁盘还是留作操作系统盘为好。