cloudera产品高可用性配置说明

简 了解高可用性架 高可用性设计概 处理HDFS命名空间的更 SharedEdits 的机 为共享使用 为共享使用QuorumJournal QuorumJournalManager的功 QuorumJournalManager设计概 发送块位置信息到 和NameNode的客户端通 NameNode故障恢 人工故障恢 自动故障恢 通过防止脑裂现 FencingoftheSharedEditDirectoryona FencingoftheSharedEditDirectoryin 设置高可用性的要 设置高可用 使用QuorumJournalManager进行共享.....................................................................................配置CDH其他组件使用HDFS高可用 配置HiveMetastore使用HDFS高可用 配置Hue使用HDFS高可用 配置Impala使用HDFS高可用 参 简介ApacheHadoop*集群中通常有多个用户长时间地运行多个作业。这些作业生成的数据分析PrimaryNameNode的单点故障。如果其中一个服务失败，本文将介绍如何为Cloudera产品设置高可用性。了解高可用性架构高可用性功能支持PrimaryNameNodeactive-standby配置。这表示Primary会被激活。PrimaryNameNode的冗余对象被称为StandbyNameNode。PrimaryNameNode负责集群中的HDFS操作，比如从HDFS文件并写入文件到HDFS。StandbyNamenode的作用是HDFS集群的状态，以便提供热备份。热备份是指高可用性设计概述PrimaryNameNode编辑日志到一个名为SharedEdits的特定 NameNode对此 构。这意味着对PrimaryNameNode命名空间做出的任何更改都将被到StandbyNameNode名空间。HDFS命名空间的更改旦编辑日志更改成功，PrimaryNameNode的文件系统结构的内存中信息将被更新。StandbyNameNode文件系统结构必须和PrimaryNameNode的文件系统结构完全相同。这意味着StandbyNamenode必须对PrimaryNameNode的编辑日志有读的权限。高可用性设计使用sharededits 是PrimaryNameNode ，也是StandbyNameNode编辑日志的 NameNode使用编辑日志中的信息来更新HDFS命名空间的内存中信息。此外，StandbyNameNode不可改动编辑日志，只能。通过这些操作，StandbyNameNode确保了HDFS文件结构会一直和Primary NameNode保持一致。如果发生故障切换，StandbyNameNode将确认在激活前它已所有编辑日志中的信息并更新了命名空间。因此，StandbyNameNode在成为PrimaryNameNode之前，它名空间将保持和PrimaryNameNode同步。Edits 的机制SharedEdits 必须可被二个NameNode，且都对此 外，NameNode必须能不间断地读／写此 ，且二个NameNode都能一直同样的数据。高可用性HDFS支持以下二种NameNodeSharedEdits 网络文件共享QuorumJournal为共享使用SharedEdits ，即NFS挂载NameNode的服务器。你可能只有一个SharedEdits 则HDFS客户端将不能写入数据到HDFS。因此，SharedEdits 高可用、高质量的NAS设备。为共享使用QuorumJournalSharedEditsNFS上是可被接受的方式，这通常也符合公司现存的整体架构。但是，对有些组织来说，NFS挂载选项可能造成以下问题。SharedEditsNAS设备上。NAS设备通常很昂贵，而且要求特别的设备用于和操作。操作、实施和管理—除了部署HDFS外，NFS挂载还要求额外的配置、和。这致HDFS不能工作。最后，存放SharedEdits 的服务器或NAS设备将增加机构对外部设备的依赖性，这一点对管理和NameNode影响重大。NFS客户端有很多缺陷—在Linux操作系统中，NFS客户端尚有很多缺陷，且难以配置。而且，每个客户端的具体实施可能不尽相同，也就是说，预测客户端的行为将很，而且每个客户端的行为都不相同。因此，将NFS客户端挂载在SharedEdits 致错误，这将使得NameNode不能读或写该 要解决这一问题，ApacheHadoop*QuorumJournalManager（QJM）NFS选日志在集群的多个节点上。编辑日志的备份将在集群中的另一个节点上变为可用。QJM集群中允许失败且失败后可继续提供服务的节点数量根据以下算法计算：(N-1)/2无需特殊硬件或外部依赖—NFS通常要求有NAS设备，这一选项对硬件或服务无特殊要求。QuorumJournalManager可部署在部署了饢的同一标准硬件上。实际操作中，推荐将QuorumJournalManager安装在已安装饢软件的同一节点上。QuorumJournalManager可定义集群中的故障恢复节点数。网络延迟将影响所有节点—QuorumJournalManager集群点的编辑日志数据的不会影响对编辑日志数据的读／写速度。而且，增加要编辑日志数据的节点数会在NameNode数据时造成网络延迟。QuorumJournalManager应用程序包含由数个节点组成的集群，HDFS编辑日志在每个节点上。在QuorumJournalManagerJournalNode。QuorumJournalManager使用分编辑HDFS编辑日志。NameNode是消耗QuorumJournalManager资源的客户端。每个NameNode上都运行进行写入编辑操作。QJM在多数节点返回成功消息后，将认为写入编辑已成功。一旦集群确认编辑完成，编辑日志的某一部分可能只能从QuorumJournalManager集群。因此，StandbyNameNode可使用QJM来集群中任何节点上的编辑日志数据，并确保该数据和集群中其他的数据完全一致。发送块位置信息到块位置信息。在HDFS中，DataNode负责向NameNode周期性报告在其中的快信息。NameNode不负责也不编辑日志的块位置信息。因此，高可用性设计中将通过改变DataNode报告块信息的方式来完成这一点。在高可用性配置中，PrimaryNameNodeStandbyNameNode的网络地址在每个节点的NameNode。但是，DataNodePrimaryNameNode发出NameNode的客户端通信HDFSNameNodeactive-active配置模式。这表示在任何时候，只能有和active状态的NameNode通讯，客户端将会：NameNode，客户端需要尝试和另一个NameNode通信。一个NameNode建立通信。NameNode人工故障恢复HDFS集群中，管理员可使用以下新命令：hdfshaadmin-failover的子命令。failover子命令有二个额外的参数。第一个参数是当前active状态的复尝试从PrimaryNameNode切换到StandbyNameNode。自动故障恢复HDFSactive状态ZooKeeperApacheZooKeeper(ZK)*是一个高可用性协调服务，用于分布式应用程序的状态、进程和配置数据。ZooKeeperquorum是ZooKeeper集群中的一组节点，用来单个应用程序的数据。在高可用性自动故障恢复中，ZooKeeperquorum提供以下功能：探测NameNode—每个NameNode的状态在ZKquorum都作为持续进程进行。如果有NameNode进入无法提供服务的状态，则ZK进程将失效，并通知另一NameNode此状态。如果无法提供服务的NameNode之前为active状态，则其他NameNode将触发故障恢复，使自己成为active状态的节点。NameNode—NameNodeactive状态的，当前activeNameNodeZKquorumNameNode中哪非active或active。activeNameNode进入非服务状态（OOS），NameNode触发故activeNameNodeStandbyNameNodeZK锁然后成为状态—定期发送心跳到NameNode，以检查NameNode是否运行状态良好。如果NameNode没有在一定的时间内返回信息或返回的状态为非良好状态，则ZKFC将认为NameNode状态错误。ZooKeeper—ZKFCNameNodeZKFC将在ZKquorum中对此一个持续进程。此进程表示NameNode状态良好且可用。如果NameNodeactiveactiveZK锁将被释放。ActiveNameNode—ZKFCNameNode运行状态良好，且其他ZKFC必须触发一个故障恢复以使得NameNodeactiveNameNode。通过防止脑裂现高可用性HDFS不支持双机热配置，也就是说，同一时间内只有一个NameNode可成为对方快速分离。如果HDFS结构分离，则很有可能HDFS上的数据会丢失或损坏。而且，HDFSNameNodeNameNode返回的结果可能和另一个NameNode返回的结果明显不同。HDFS为例，这意味这二个NameNode都认为自己是active状态的节点，其他节点是StandbyNameNodeHDFS中没有数据丢失、损坏或不一致，防止脑裂现象在集群中，进程用于将工作不正常的服务孤立起来，以防止该服务共享资源。在高HDFS中，进程发生在NameNodeactiveNameNode会验证之前为activeNameNode将不能编辑HDFS命名空间。FencingoftheSharedEditDirectoryonaactiveNameNodeactiveNameNodeactive操作将尝试找到并终止之前为active状态的NameNode服务，从而防止之前为active状态的NameNodeSharedEdits FencingoftheSharedEditDirectoryinQJM上的，它不需要额外的或特别的硬件和软件。在QJM中，NameNode更改编辑日志，当NameNode成为active时，QJM将会被分配一个号（epochnumber）。号同时在QJM和所有的JournalNode上要生成号，NameNode的QJM从所有的JournalNode上获取号。QJM将找出最高的号，加上1，结果即为新的号。QJMJN可决定写入者比之前的写入者新还是旧。如对于另一个NameNode，被认为是新的写入者。QJM通过以下方式使用号在NameNode被允许更改编辑日志前，QJM必须已被成功分配号间第一次被格式化后，第一个active状态的NameNode将被分配号1。任何故障恢复都将导致号的增加。在号被成功分配给QJM前，QJM必须发送号到集群中的所有JournalNode上。多数JournalNode必须返回一个消息，标明号已成功收到，否则QJM将不能使用该如果QJM回应号的消息请求，它将这一号以便日后参考。无论何时行对比。如果请求中的号低于JN的号，JN将写请求。如果请求中