YDB依赖的软件环境详解

YDB依赖的软件环境详解

一、Hadoop服务-注意事项

1)    NameNode:HDFS的主节点,是Hadoop最至关重要的服务,一旦出问题,整个集群都不可用,NameNodeeditlogimage目录,一定要配置多盘,设置冗余,如果有必要,配置RAID 10
2)    SNameNode:是Namenode的备份节点,一旦NameNode机器损坏,可以通过SNameNode恢复数据,故YDB要求一定要启动SNameNode服务,并且SNameNode不可与NameNode位于同一个物理机上 。
3)    NameNode HA:为了高可用,有些客户会启用HA,延云不建议启用HA,如果必须启用一定要确保首节点为Active状态,而不是Stand by状态,否则整个集群的NameNode响应会比较慢,从而影响整个集群的响应速度。
4)    一定要确保dfs.datanode.data.diryarn.nodemanager.local-dirs的目录配置的是所有的数据盘,而不是配给了系统盘,特别多的用户在初次安装Hadoop的时候忘记配置这个,导致默认将数据都存储在了/tmp目录。另外系统盘一定要与数据盘分离,否则磁盘特别繁忙的时候会造成操作系统很繁忙,ZooKeeper之类的容易挂掉。
5)    规划好Hadooplogs目录,尽量分给一个大点磁盘存储空间的目录,否则经常会出现导入几十亿数据后,logs目录将系统/var/log给撑满,占用率100%
6)    确保将来准备分配给YDBHDFS目录有读写权限,建议第一次新手安装,取消HDFS的权限验证,配置dfs.permissions.enabled false,并重启集群。
7)    Hadooplogs目录要配置上定期清理,以免时间久了,硬盘被撑爆。
8)    确保HDFS安装成功,一定要手工通过hadoop  -put命令,上传一个文件试一试。
9)    打开8088,检查Yarn是否启动成功, VCores Total \Memory Total 分配的是否正确。经常有朋友忘记更改Yarn的默认配置导致一台128G内存的机器最多只能启动2个进程,只能使用8G内存。
10)    yarn.nodemanager.resource.memory-mb用于配置Yarn当前机器的可用内存,通常配置当前机器剩余可用内存的80%.
11)    yarn.scheduler.minimum-allocation-mb为一个Yarn container申请内存的最小计费单位,建议调小一些,如128,让计费更精准.
12)    yarn.scheduler.maximum-allocation-mb为一个Yarn container可以申请最大的内存,建议调整为32768 (不一定真用到这些)
13)    不建议启用CGROUPS,进行CPU隔离,对于即席系统来说,尽量充分利用资源。
14)    yarn.nodemanager.resource.cpu-vcores 当前机器可以启动的Yarn container的数量,建议配置为当前机器的cpu的线程数的80%
15)    yarn.scheduler.maximum-allocation-vcores配置的稍微大一些,以便单个container能够多启动一些线程。
16)    yarn.nodemanager.pmem-check-enabledyarn.nodemanager.vmem-check-enabled一定要都配置成false,因为1.6版本的sparkBUG,会使用较多的堆外内存,Yarnkill掉相关container,造成服务的不稳定。
17)    检查mapreduce.application.classpath 里面的值是否有配置的jar包并不存在,典型的情况下是找不到lzo的包(许多厂商的安装部署会配置该参数)。如果有的jar包找不到,建议注释掉相关依赖,否则可能会造成YDB启动失败,如默认的HDP集群就要将其中的lzo的配置给注释掉/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jar;如果是红象云腾Power版本在最后加上这个 /usr/crh/4.1.5/hadoop/share/hadoop/tools/lib/*
18)    为了便于查找问题,我们一般保留7天的Hadoop日志,可以配置Yarn日志清理yarn.nodemanager.delete.debug-delay-sec       604800 7天)
19)    调整dfs.datanode.max.transfer.threads的值,默认4096太小,建议调整为10240
20)    调整ipc.server.listen.queue.size32768
21)    调整yarn.resourcemanager.am.max-attempts的值为10000000,默认的2次太小,客户测试过程反复的kill就会导致整个任务失败。
22)    yarn.resourcemanager.recovery.enabled 建议设置成false,以免yarn重启,由于任务recover导致的yarn没有内存,YDB启动不起来的情况发生.
23)    dfs.datanode.failed.volumes.tolerated 要配置上至少1块盘,以免磁盘损坏的时候整个机器被摘除掉

二、Spark 需要使用延云提供的spark版本

1)无需配置,只需要解压开放到指定目录即可,我们一般解压到/opt/ydbsoftware/spark

2)请大家不要启动spark服务,YDB本身会自己调用Spark启动服务,无须我们额外为Spark启动服务。

三、ZooKeeper服务注意事项

第一:要探测ZooKeeper2181端口是否启动 可以通过netstat –npl|grep 2181来查看

第二:ZooKeeper的数据目录别与HDFS的数据盘放在一起,尽量独立一个磁盘,或者放在系统盘,否则数据盘特别繁忙的时候ZooKeeper本身非常容易挂掉。如果机器富余,建议将ZK单独部署一个集群,不要混搭,如果因机制资源有限,必须混搭,请将zookeeper部署在通常来说负载不很很高的Master节点。

第三:ZooKeeper的日志清理要打开,否则会出现系统运行几个月后,ZooKeeper所在的磁盘硬盘变满的情况,将zoo.cfg里的这两个配置项注释开即可:

autopurge.purgeInterval=24

autopurge.snapRetainCount=30

第四:YDB使用的ZK的版本一定要与ZK的版本一致,如果不一致请更换ya100/lib下的zookeeper相关jar包。

 

 

 

四、Kafka注意事项

如果kafka配置的不好, 会发生比较严重的数据倾斜,而且在压力较大的情况会导致数据丢失。所以跟Kafka有关的如下配置,请一定要认真阅读

注意kafka server num.partitions一定要大于总分片数的两倍,否则有的进程消费不到数据,导致数据倾斜。YDB的总分片数为YA100_EXECUTORS*spark.executor.max.usedcores);

注:spark.executor.max.usedcores默认(没有配置)为2个,表示每个进程会启动2个分片。

l数据丢失根本问题在于磁盘与网络是否繁忙!!!!!!

如果磁盘长时间使用率100%,必出现丢数据,会出现如下异常,配置的kafka retry机制无效

 

l如果我们先前采用的send方法没使用callback,一旦消息发送失败,我们没有处理异常的话,这个消息就丢了。

这个问题如何解决?

1)如果有条件,Kafka尽量独立集群,最低要求也一定要独立磁盘,并且写入限速

独立磁盘是解决问题的根本,磁盘很繁忙的情况下,broker出错的概率很大。

2)send 里面的callback,如果是异常一定要自己做容错处理

发现send函数里的callback,一定要对Exception exception不是null的情况做重试处理,一定要处理,根据判断重试几次。

 

3)调整kafka的参数

a)建议在Producter端增加如下参数

       props.put("compression.type", "gzip");
       props.put("linger.ms", "50");
       props.put("acks", "all");
       props.put("retries ", 30);
       props.put("reconnect.backoff.ms ", 20000);
       props.put("retry.backoff.ms", 20000);

b)Server端的broker增加如下配置