云服务器内容精选
-
解决方法 找到重启前的主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的读写文件注意点 HDFS不支持随机读和写。 HDFS追加文件内容只能在文件末尾添加，不能随机添加。 只有存储在HDFS文件系统中的数据才支持append，edit.log以及数据元文件不支持Append。Append追加文件时，需要将“hdfs-site.xml”中的“dfs.support.append”参数值设置为true。 “dfs.support.append”参数在开源社区版本中默认值是关闭，在FusionInsight版本默认值是开启。 该参数为服务器端参数。建议开启，开启后才能使用Append功能。 不适用HDFS场景可以考虑使用其他方式来存储数据，如HBase。
-
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/。
-
HDFS结构 HDFS包含主、备NameNode和多个DataNode，如图1所示。 HDFS是一个Master/Slave的架构，在Master上运行NameNode，而在每一个Slave上运行DataNode，ZKFC需要和NameNode一起运行。 NameNode和DataNode之间的通信都是建立在TCP/IP的基础之上的。NameNode、DataNode、ZKFC和JournalNode能部署在运行Linux的服务器上。 图1 HA HDFS结构 图1中各模块的功能说明如表1所示。 表1 模块说明 名称 描述 NameNode 用于管理文件系统的命名空间、目录结构、元数据信息以及提供备份机制等，分为： Active NameNode：管理文件系统的命名空间、维护文件系统的目录结构树以及元数据信息；记录写入的每个“数据块”与其归属文件的对应关系。 Standby NameNode：与Active NameNode中的数据保持同步；随时准备在Active NameNode出现异常时接管其服务。 Observer NameNode：与Active NameNode中的数据保持同步，处理来自客户端的读请求。 DataNode 用于存储每个文件的“数据块”数据，并且会周期性地向NameNode报告该DataNode的数据存放情况。 JournalNode HA集群下，用于同步主备NameNode之间的元数据信息。 ZKFC ZKFC是需要和NameNode一一对应的服务，即每个NameNode都需要部署ZKFC。它负责监控NameNode的状态，并及时把状态写入ZooKeeper。ZKFC也有选择谁作为Active NameNode的权利。 ZK Cluster ZooKeeper是一个协调服务，帮助ZKFC执行主NameNode的选举。 HttpFS gateway HttpFS是个单独无状态的gateway进程，对外提供webHDFS接口，对HDFS使用FileSystem接口对接。可用于不同Hadoop版本间的数据传输，及用于访问在防火墙后的HDFS（HttpFS用作gateway）。 HDFS HA架构 HA即为High Availability，用于解决NameNode单点故障问题，该特性通过主备的方式为主NameNode提供一个备用者，一旦主NameNode出现故障，可以迅速切换至备NameNode，从而不间断对外提供服务。 在一个典型HDFS HA场景中，通常由两个NameNode组成，一个处于Active状态，另一个处于Standby状态。 为了能实现Active和Standby两个NameNode的元数据信息同步，需提供一个共享存储系统。本版本提供基于QJM（Quorum Journal Manager）的HA解决方案，如图2所示。主备NameNode之间通过一组JournalNode同步元数据信息。 通常配置奇数个（2N+1个）JournalNode，且最少要运行3个JournalNode。这样，一条元数据更新消息只要有N+1个JournalNode写入成功就认为数据写入成功，此时最多容忍N个JournalNode写入失败。比如，3个JournalNode时，最多允许1个JournalNode写入失败，5个JournalNode时，最多允许2个JournalNode写入失败。 由于JournalNode是一个轻量级的守护进程，可以与Hadoop其它服务共用机器。建议将JournalNode部署在控制节点上，以避免数据节点在进行大数据量传输时引起JournalNode写入失败。 图2 基于QJM的HDFS架构
-
问题背景与现象 shell客户端或者其他客户端操作HDFS失败，报“No common protection layer between client and server”。 在集群外的机器，执行任意hadoop命令，如hadoop fs -ls /均失败，最底层的报错为"No common protection layer between client and server"。 2017-05-13 19:14:19,060 | ERROR | [pool-1-thread-1] | Server startup failure | org.apache.sqoop.core.SqoopServer.initializeServer(SqoopServer.java:69) org.apache.sqoop.common.SqoopException: MAPRED_EXEC_0028:Failed to operate HDFS - Failed to get the file /user/loader/etl_dirty_data_dir status at org.apache.sqoop.job.mr.HDFSClient.fileExist(HDFSClient.java:85) ... at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException: Failed on local exception: java.io.IOException: Couldn't setup connection for loader/hadoop@HADOOP.COM to loader37/10.162.0.37:25000; Host Details : local host is: "loader37/10.162.0.37"; destination host is: "loader37":25000; at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:776) ... ... 10 more Caused by: java.io.IOException: Couldn't setup connection for loader/hadoop@HADOOP.COM to loader37/10.162.0.37:25000 at org.apache.hadoop.ipc.Client$Connection$1.run(Client.java:674 ... 28 more Caused by: javax.security.sasl.SaslException: No common protection layer between client and server at com.sun.security.sasl.gsskerb.GssKrb5Client.doFinalHandshake(GssKrb5Client.java:251) ... at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:720)
-
原因分析 HDFS的客户端和服务端数据传输走的rpc协议，该协议有多种加密方式，由hadoop.rpc.protection参数控制。 如果客户端和服务端的hadoop.rpc.protection参数的配置值不一样，即会报No common protection layer between client and server错误。 hadoop.rpc.protection参数表示数据可通过以下任一方式在节点间进行传输。 privacy：指数据在鉴权及加密后再传输。这种方式会降低性能。 authentication：指数据在鉴权后直接传输，不加密。这种方式能保证性能但存在安全风险。 integrity：指数据直接传输，即不加密也不鉴权。 为保证数据安全，请谨慎使用这种方式。
-
HDFS HA方案背景 在Hadoop 2.0.0之前，HDFS集群中存在单点故障问题。由于每个集群只有一个NameNode，如果NameNode所在机器发生故障，将导致HDFS集群无法使用，除非NameNode重启或者在另一台机器上启动。这在两个方面影响了HDFS的整体可用性： 当异常情况发生时，如机器崩溃，集群将不可用，除非重新启动NameNode。 计划性的维护工作，如软硬件升级等，将导致集群停止工作。 针对以上问题，HDFS高可用性方案通过自动或手动（可配置）的方式，在一个集群中为NameNode启动一个热替换的NameNode备份。当一台机器故障时，可以迅速地自动进行NameNode主备切换。或者当主NameNode节点需要进行维护时，通过MRS集群管理员控制，可以手动进行NameNode主备切换，从而保证集群在维护期间的可用性。 有关HDFS自动故障转移功能，请参阅： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html#Automatic_Failover MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html#Automatic_Failover
-
HDFS HA实现方案 图1 典型的HA部署方式 在一个典型的HA集群中（如图1），需要把两个NameNodes配置在两台独立的机器上。在任何一个时间点，只有一个NameNode处于Active状态，另一个处于Standby状态。Active节点负责处理所有客户端操作，Standby节点时刻保持与Active节点同步的状态以便在必要时进行快速主备切换。 为保持Active和Standby节点的数据一致性，两个节点都要与一组称为JournalNode的节点通信。当Active对文件系统元数据进行修改时，会将其修改日志保存到大多数的JournalNode节点中，例如有3个JournalNode，则日志会保存在至少2个节点中。Standby节点监控JournalNodes的变化，并同步来自Active节点的修改。根据修改日志，Standby节点将变动应用到本地文件系统元数据中。一旦发生故障转移，Standby节点能够确保与Active节点的状态是一致的。这保证了文件系统元数据在故障转移时在Active和Standby之间是完全同步的。 为保证故障转移快速进行，Standby需要时刻保持最新的块信息，为此DataNodes同时向两个NameNodes发送块信息和心跳。 对一个HA集群，保证任何时刻只有一个NameNode是Active状态至关重要。否则，命名空间会分为两部分，有数据丢失和产生其他错误的风险。为保证这个属性，防止“split-brain”问题的产生，JournalNodes在任何时刻都只允许一个NameNode写入。在故障转移时，将变为Active状态的NameNode获得写入JournalNodes的权限，这会有效防止其他NameNode的Active状态，使得切换安全进行。 关于HDFS高可用性方案的更多信息，可参考如下链接： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
更多精彩内容
CDN加速
GaussDB
文字转换成语音
免费的服务器
如何创建网站
域名网站购买
私有云桌面
云主机哪个好
域名怎么备案
手机云电脑
SSL证书申请
云点播服务器
免费OCR是什么
电脑云桌面
域名备案怎么弄
语音转文字
文字图片识别
云桌面是什么
网址安全检测
网站建设搭建
国外CDN加速
SSL免费证书申请
短信批量发送
图片OCR识别
云数据库MySQL
个人域名购买
录音转文字
扫描图片识别文字
OCR图片识别
行驶证识别
虚拟电话号码
电话呼叫中心软件
怎么制作一个网站
Email注册网站
华为VNC
图像文字识别
企业网站制作
个人网站搭建
华为云计算
免费租用云托管
云桌面云服务器
ocr文字识别免费版
HTTPS证书申请
图片文字识别转换
国外域名注册商
使用免费虚拟主机
云电脑主机多少钱
鲲鹏云手机
短信验证码平台
OCR图片文字识别
SSL证书是什么
申请企业邮箱步骤
免费的企业用邮箱
云免流搭建教程
域名价格
