基于HDP版本的YDB安装部署

第三章 YDB依赖环境准备

一、硬件环境

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

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

       经常遇到很多的企业级客户，他们机器配置非常高，CPU有128 VCore，256G内存，但是只挂载了1块8T的SATA硬盘，千兆网卡。

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

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

2.SAS、SATA与SSD 磁盘的选择与对比

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

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

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

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

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

 

 

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

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

 

SSD颗粒目前主要分三种：SLC、MLC和TLC

       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.磁盘：企业级SSD，600~800G *12个磁盘

3.CPU：32线程（2颗,16核,32线程）

4.万兆网卡

三、延云YDB常规配置 （秒级响应）

1.机器内存：128G

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

3.CPU：24线程（2颗,12核,24线程）

4.千兆网卡

 

 

二、磁盘如何挂载？

     1.逻辑卷的问题

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

     2.关于RAID

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

     3.关于系统盘与数据盘

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

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

 

 

     4.关于磁盘阵列与云

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

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