云服务器内容精选

  • 块副本位置选择 Nodelabel支持对各个副本的摆放采用不同的策略,如表达式“label-1,label-2,label-3”,表示3个副本分别放到含有label-1、label-2、label-3的DataNode中,不同的副本策略用逗号分隔。 如果label-1,希望放2个副本,可以这样设置表达式:“label-1[replica=2],label-2,label-3”。这种情况下,如果默认副本数是3,则会选择2个带有label-1和一个label-2的节点;如果默认副本数是4,会选择2个带有label-1、一个label-2以及一个label-3的节点。可以注意到,副本数是从左到右依次满足各个副本策略的,但也有副本数超过表达式表述的情况,当默认副本数为5时,多出来的一个副本会放到最后一个节点中,也就是label-3的节点里。 当启用ACLs功能并且用户无权访问表达式中使用的标签时,将不会为副本选择属于该标签的DataNode。
  • 多余块副本删除选择 如果块副本数超过参数“dfs.replication”值(即用户指定的文件副本数),hdfs会删除多余块副本来保证集群资源利用率。 删除规则如下: 优先删除不满足任何表达式的副本。 示例:文件默认副本数为3 /test标签表达式为“LA[replica=1],LB[replica=1],LC[replica=1]”, /test文件副本分布的四个节点(D1~D4)以及对应标签(LA~LD): D1:LA D2:LB D3:LC D4:LD 则选择删除D4节点上的副本块。 如果所有副本都满足表达式,删除多于表达式指定的数量的副本。 示例:文件默认副本数为3 /test标签表达式为“LA[replica=1],LB[replica=1],LC[replica=1]”, /test文件副本分布的四个节点以及对应标签: D1:LA D2:LA D3:LB D4:LC 则选择删除D1或者D2上的副本块。 如果文件所有者或文件所有者的组不能访问某个标签,则优先删除映射到该标签的DataNode中的副本。
  • 基于标签的数据块摆放策略样例 假如有一套集群,有六个DataNode:dn-1,dn-2,dn-3,dn-4,dn-5以及dn-6,对应的IP为10.1.120.[1-6]。有六个目录需要配置标签表达式,Block默认备份数为3。 下面给出3种DataNode标签信息在“host2labels”文件中的表示方式,其作用是一样的。 主机名正则表达式 /dn-[1456]/ = label-1,label-2 /dn-[26]/ = label-1,label-3 /dn-[3456]/ = label-1,label-4 /dn-5/ = label-5 IP地址范围表示方式 10.1.120.[1-6] = label-1 10.1.120.1 = label-2 10.1.120.2 = label-3 10.1.120.[3-6] = label-4 10.1.120.[4-6] = label-2 10.1.120.5 = label-5 10.1.120.6 = label-3 普通的主机名表达式 /dn-1/ = label-1, label-2 /dn-2/ = label-1, label-3 /dn-3/ = label-1, label-4 /dn-4/ = label-1, label-2, label-4 /dn-5/ = label-1, label-2, label-4, label-5 /dn-6/ = label-1, label-2, label-3, label-4 目录的标签表达式设置结果如下: /dir1 = label-1 /dir2 = label-1 && label-3 /dir3 = label-2 || label-4[replica=2] /dir4 = (label-2 || label-3) && label-4 /dir5 = !label-1 /sdir2.txt = label-1 && label-3[replica=3,fallback=NONE] /dir6 = label-4[replica=2],label-2 标签表达式设置方式请参考hdfs nodelabel -setLabelExpression命令。 文件的数据块存放结果如下: “/dir1”目录下文件的数据块可存放在dn-1,dn-2,dn-3,dn-4,dn-5和dn-6六个节点中的任意一个。 “/dir2”目录下文件的数据块可存放在dn-2和dn-6节点上。Block默认备份数为3,表达式只匹配了两个DataNode节点,第三个副本会在集群上剩余的节点中选择一个DataNode节点存放。 “/dir3”目录下文件的数据块可存放在dn-1,dn-3,dn-4,dn-5和dn-6中的任意三个节点上。 “/dir4”目录下文件的数据块可存放在dn-4,dn-5和dn-6。 “/dir5”目录下文件的数据块没有匹配到任何一个DataNode,会从整个集群中任意选择三个节点存放(和默认选块策略行为一致)。 “/sdir2.txt”文件的数据块,两个副本存放在dn-2和dn-6节点上,虽然还缺失一个备份节点,但由于使用了fallback=NONE参数,所以只存放两个备份。 “/dir6”目录下文件的数据块在具备label-4的节点中选择2个节点(dn-3 -- dn-6),然后在label-2中选择一个节点,如果用户指定“/dir6”下文件副本数大于3,则多出来的副本均在label-2。
  • 配置描述 Datanode节点标签配置 请参考修改集群服务配置参数,进入HDFS的“全部配置”页面,在搜索框中输入参数名称。 表1 参数说明 参数 描述 默认值 dfs.block.replicator.classname 配置HDFS的DataNode原则策略。 如果需要开启NodeLabeNodel功能,需要将该值设置为org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicyWithNodeLabel。 org.apache.hadoop.hdfs.server.blockmanagement.AvailableSpaceBlockPlacementPolicy host2tags 配置DataNode主机与标签的对应关系。 主机名称支持配置IP扩展表达式(如192.168.1.[1-128]或者192.168.[2-3].[1-128],且IP必须为业务IP),或者为前后加上 / 的主机名的正则表达式(如/datanode-[123]/或者/datanode-\d{2}/)。标签配置名称不允许包含 = / \ 字符。【注意】配置IP时必须是业务IP。 - host2tags配置项内容详细说明: 假如有一套集群,有20个Datanode:dn-1到dn-20,对应的IP地址为10.1.120.1到10.1.120.20,host2tags配置文件内容可以使用如下的表示方式。 主机名正则表达式 “/dn-\d/ = label-1”表示dn-1到dn-9对应的标签为label-1,即dn-1 = label-1,dn-2 = label-1,...dn-9 = label-1。 “/dn-((1[0-9]$)|(20$))/ = label-2”表示dn-10到dn-20对应的标签为label-2,即dn-10 = label-2,dn-11 = label-2,...dn-20 = label-2。 IP地址范围表示方式 “10.1.120.[1-9] = label-1”表示10.1.120.1到10.1.120.9对应的标签为label-1,即10.1.120.1 = label-1,10.1.120.2 = label-1,...10.1.120.9 = label-1。 “10.1.120.[10-20] = label-2”表示10.1.120.10到10.1.120.20对应的标签为label-2,即10.1.120.10 = label-2,10.1.120.11 = label-2,...10.1.120.20 = label-2。 基于标签的数据块摆放策略支持扩容减容场景: 当集群中新增加DataNode节点时,如果该DataNode对应的IP匹配host2tags配置项中的IP地址范围,或者该DataNode的主机名匹配host2tags配置项中的主机名正则表达式,则该DataNode节点会被设置成对应的标签。 例如“host2tags”配置值为10.1.120.[1-9] = label-1,而当前集群只有10.1.120.1到10.1.120.3三个数据节点。进行扩容后,又添加了10.1.120.4这个数据节点,则该数据节点会被设置成label-1的标签;如果10.1.120.3这个数据节点被删除或者退出服务后,数据块不会再被分配到该节点上。 设置目录/文件的标签表达式 在HDFS参数配置页面配置“path2expression”,配置HDFS目录与标签的对应关系。当配置的HDFS目录不存在时,也可以配置成功,新建不存在的同名目录,已设置的标签对应关系将在30分钟之内被继承。设置了标签的目录被删除后,新增一个同名目录,原有的对应关系也将在30分钟之内被继承。 命令行设置方式请参考hdfs nodelabel -setLabelExpression命令。 Java API设置方式通过NodeLabelFileSystem实例化对象调用setLabelExpression(String src, String labelExpression)方法。src为HDFS上的目录或文件路径,“labelExpression”为标签表达式。 开启NodeLabel特性后,可以通过命令hdfs nodelabel -listNodeLabels查看每个Datanode的标签信息。
  • 配置场景 用户需要通过数据特征灵活配置HDFS文件数据块的存储节点。通过设置HDFS目录/文件对应一个标签表达式,同时设置每个DataNode对应一个或多个标签,从而给文件的数据块存储指定了特定范围的DataNode。 当使用基于标签的数据块摆放策略,为指定的文件选择DataNode节点进行存放时,会根据文件的标签表达式选择出DataNode节点范围,然后在这些DataNode节点范围内,选择出合适的存放节点。 场景1 DataNodes分区场景。 场景说明: 用户需要让不同的应用数据运行在不同的节点,分开管理,就可以通过标签表达式,来实现不同业务的分离,指定业务存放到对应的节点上。 通过配置NodeLabel特性使得: /HBase下的数据存储在DN1、DN2、DN3、DN4节点上。 /Spark下的数据存储在DN5、DN6、DN7、DN8节点上。 图1 DataNode分区场景 通过hdfs nodelabel -setLabelExpression -expression 'LabelA[fallback=NONE]' -path /Hbase命令,给Hbase目录设置表达式。从图1中可知,“/Hbase”文件的数据块副本会被放置在有LabelA标签的节点上,即DN1、DN2、DN3、DN4。同理,通过hdfs nodelabel -setLabelExpression -expression 'LabelB[fallback=NONE]' -path /Spark命令,给Spark目录设置表达式。在“/Spark”目录下文件对应的数据块副本只能放置到LabelB标签上的节点,如DN5、DN6、DN7、DN8。 设置数据节点的标签参考配置描述。 如果同一个集群上存在多个机架,每个标签下需要有多个机架的datanodes,以确保数据块摆放的可靠性。 场景2 多机架下指定副本位置场景 场景说明: 在异构集群中,客户需要分配一些特定的具有高可靠性的节点用以存放重要的商业数据,可以通过标签表达式指定副本位置,指定文件数据块的其中一个副本存放到高可靠性的节点上。 “/data”目录下的数据块,默认三副本情况下,其中至少有一个副本会被存放到RACK1或RACK2机架的节点上(RACK1和RACK2机架的节点为高可靠性节点),另外两个副本会被分别存放到RACK3和RACK4机架的节点上。 图2 场景样例 通过 hdfs nodelabel -setLabelExpression -expression 'LabelA||LabelB[fallback=NONE],LabelC,LabelD' -path /data命令给“/data”目录设置表达式。 当向“/data”目录下写数据时,至少有一个数据块副本存放在LabelA或者LabelB标签的节点中,剩余的两个数据块副本会被存放在有LabelC和LabelD标签的节点上。
  • HDFS的读写文件注意点 HDFS不支持随机读和写。 HDFS追加文件内容只能在文件末尾添加,不能随机添加。 只有存储在HDFS文件系统中的数据才支持append,edit.log以及数据元文件不支持Append。Append追加文件时,需要将“hdfs-site.xml”中的“dfs.support.append”参数值设置为true。 “dfs.support.append”参数在开源社区版本中默认值是关闭,在FusionInsight版本默认值是开启。 该参数为服务器端参数。建议开启,开启后才能使用Append功能。 不适用HDFS场景可以考虑使用其他方式来存储数据,如HBase。
  • 解决方法 找到重启前的主NameNode,进入其数据目录(查看配置项“dfs.namenode.name.dir”可获取,例如/srv/BigData/namenode/current),得到最新的FSImage文件的序号。一般如下: 查看各JournalNode的数据目录(查看配置项“dfs.journalnode.edits.dir”可获取,例如/srv/BigData/journalnode/hacluster/current),查看序号从第一部获取到的序号开始的edits文件,看是否有不连续的情况(即前一个edits文件的最后一个序号 和 后一个edits文件的第一个序号 不是连续的,如下图中的edits_0000000000013259231-0000000000013259237就和后一个edits_0000000000013259239-0000000000013259246就是不连续的)。 如果有这种不连续的edits文件,则需要查看其它的JournalNode的数据目录或NameNode数据目录中,有没有连续的该序号相关的连续的edits文件。如果可以找到,复制一个连续的片段到该JournalNode。 如此把所有的不连续的edits文件全部都修复。 重启NameNode,观察是否成功。如还是失败,请联系技术支持。
  • 配置场景 数个成品Hadoop集群由于NameNode超负荷运行并失去响应而发生故障。 这种阻塞现象是由于Hadoop的初始设计造成的。在Hadoop中,NameNode作为单独的机器,在其namespace内协调HDFS的各种操作。这些操作包括获取数据块位置,列出目录及创建文件。NameNode接受HDFS的操作,将其视作RPC调用并置入FIFO调用队列,供读取线程处理。虽然FIFO在先到先服务的情况下足够公平,但如果用户执行的I/O操作较多,相比I/O操作较少的用户,将获得更多的服务。在这种情况下,FIFO有失公平并且会导致延迟增加。 图1 基于FIFO调用队列的NameNode请求处理 如果将FIFO队列替换为一种被称作FairCallQueue的新型队列,这种情况就能够得到改善。按照这种方法,FAIR队列会根据调用者的调用规模将传入的RPC调用分配至多个队列中。调度模块会跟踪最新的调用,并为调用量较小的用户分配更高的优先级。 图2 基于FAIRCallQueue的NameNode请求处理
  • 问题 为什么在往HDFS写数据时报"java.net.SocketException: No buffer space available"异常? 这个问题发生在往HDFS写文件时。查看客户端和DataNode的错误日志。 客户端日志如下: 图1 客户端日志 DataNode日志如下: 2017-07-24 20:43:39,269 | ERROR | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | DataNode{data=FSDataset{dirpath='[/srv/BigData/hadoop/data1/dn/current, /srv/BigData/hadoop/data2/dn/current, /srv/BigData/hadoop/data3/dn/current, /srv/BigData/hadoop/data4/dn/current, /srv/BigData/hadoop/data5/dn/current, /srv/BigData/hadoop/data6/dn/current, /srv/BigData/hadoop/data7/dn/current]'}, localName='192-168-164-155:9866', datanodeUuid='a013e29c-4e72-400c-bc7b-bbbf0799604c', xmitsInProgress=0}:Exception transfering block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 to mirror 192.168.202.99:9866: java.net.SocketException: No buffer space available | DataXceiver.java:870 2017-07-24 20:43:39,269 | INFO | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | opWriteBlock BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 received exception java.net.SocketException: No buffer space available | DataXceiver.java:933 2017-07-24 20:43:39,270 | ERROR | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | 192-168-164-155:9866:DataXceiver error processing WRITE_BLOCK operation src: /192.168.164.155:40214 dst: /192.168.164.155:9866 | DataXceiver.java:304 java.net.SocketException: No buffer space available at sun.nio.ch.Net.connect0(Native Method) at sun.nio.ch.Net.connect(Net.java:454) at sun.nio.ch.Net.connect(Net.java:446) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:192) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:495) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:800) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.opWriteBlock(Receiver.java:138) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.java:74) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:265) at java.lang.Thread.run(Thread.java:748)
  • 回答 目前出现上述问题时使用的是默认配置,如表1所示,HDFS客户端到NameNode的RPC连接存在keep alive机制,保持连接不会超时,尽力等待服务器的响应,因此导致已经连接的HDFS客户端的操作会卡住。 对于已经卡住的HDFS客户端,可以进行如下操作: 等待NameNode响应,一旦NameNode所在节点的CPU利用率回落,NameNode可以重新获得CPU资源时,HDFS客户端即可得到响应。 如果无法等待更长时间,需要重启HDFS客户端所在的应用程序进程,使得HDFS客户端重新连接空闲的NameNode。 解决措施: 为了避免该问题出现,可以在“客户端安装路径/HDFS/hadoop/etc/hadoop/core-site.xml”中做如下配置。 表1 参数说明 参数 描述 默认值 ipc.client.ping 当配置为true时,客户端会尽力等待服务端响应,定期发送ping消息,使得连接不会因为tcp timeout而断开。 当配置为false时,客户端会使用配置项“ipc.ping.interval”对应的值,作为timeout时间,在该时间内没有得到响应,即会超时。 在上述问题场景下,建议配置为false。 true ipc.ping.interval 当“ipc.client.ping”配置为true时,表示发送ping消息的周期。 当“ipc.client.ping”设置为false时,表示连接的超时时间。 在上述问题场景下,建议配置一个较大的超时时间,避免服务繁忙时的超时,建议配置为900000,单位为ms。 60000
  • 配置描述 请参考修改集群服务配置参数,进入HDFS的“全部配置”页面,在搜索框中输入参数名称。 表1 参数说明 参数 描述 默认值 ha.health-monitor.rpc-timeout.ms zkfc对namenode健康状态检查的超时时间。增大该参数值,可以防止出现双Active NameNode,降低客户端应用运行异常的概率。 单位:毫秒。取值范围:30000~3600000 180000 ipc.client.connect.max.retries.on.timeouts 客户端与服务端建立Socket连接超时时,客户端的重试次数。 取值范围:1~256 45 ipc.client.connect.timeout 客户端与服务端建立socket连接的超时时间。增大该参数值,可以增加建立连接的超时时间。 单位:毫秒。取值范围:1~3600000 20000
  • 回答 “dfs.datanode.data.dir”配置项用于指定数据块在DataNode上的存储目录,在系统安装时需要指定根目录,并且可以指定多个根目录。 请谨慎修改该配置项,可以添加新的数据根目录。 禁止删除原有存储目录,否则会造成数据块丢失,导致文件无法正常读写。 禁止手动删除或修改存储目录下的数据块,否则可能会造成数据块丢失。 NameNode和JournalNode存在类似的配置项,也同样禁止删除原有存储目录,禁止手动删除或修改存储目录下的数据块。 dfs.namenode.edits.dir dfs.namenode.name.dir dfs.journalnode.edits.dir
  • 操作步骤 登录安装客户端的节点。 执行以下命令,切换到客户端安装目录。 cd /opt/client 执行以下命令配置环境变量。 source bigdata_env 如果集群为安全模式,执行distcp命令的用户所属的用户组必须为supergroup组,且执行以下命令进行用户认证。普通模式集群无需执行用户认证。 kinit 组件业务用户 直接执行distcp命令。例如: hadoop distcp hdfs://hacluster/source hdfs://hacluster/target
  • 操作场景 HDFS部署在具有多个NameNode实例的HA(High Availability)模式中,HDFS客户端需要依次连接到每个NameNode,以确定当前活动的NameNode是什么,并将其用于客户端操作。 一旦识别出来,当前活动的NameNode的详细信息就可以被缓存并共享给在客户端机器中运行的所有客户端。这样,每个新客户端可以首先尝试从缓存加载活动的Name Node的详细信息,并将RPC调用保存到备用的NameNode。在异常情况下有很多优势,例如当备用的NameNode连接长时间不响应时。 当发生故障,将另一个NameNode切换为活动状态时,缓存的详细信息将被更新为当前活动的NameNode的信息。
  • HDFS可靠性 MRS使用HDFS的副本机制来保证数据的可靠性,HDFS中每保存一个文件则自动生成1个备份文件,即共2个副本。HDFS副本数可通过“dfs.replication”参数查询。 当MRS集群中Core节点规格选择为非本地盘(hdd)时,若集群中只有一个Core节点,则HDFS默认副本数为1。若集群中Core节点数大于等于2,则HDFS默认副本数为2。 当MRS集群中Core节点规格选择为本地盘(hdd)时,若集群中只有一个Core节点,则HDFS默认副本数为1。若集群中有两个Core节点,则HDFS默认副本数为2。若集群中Core节点数大于等于3,则HDFS默认副本数为3。 图3 HDFS架构 MRS支持HDFS组件上节点均衡调度和单节点内的磁盘均衡调度,有助于扩容节点或扩容磁盘后的HDFS存储性能提升。 关于Hadoop的架构和详细原理介绍,请参见:http://hadoop.apache.org/。