HAWQ 作为一个传统数仓在 Hadoop 上的替代品,其高可用性至关重要。通常硬件容错、HAWQ HA、HDFS HA 是保持系统高可用时需要考虑并实施的三个层次。另外实时监控和定期维护,也是保证集群所有组件健康的必不可少的工作。 总的来说,HAWQ 容错高可用的实现方式包括:
硬件组件的正常磨损或意外情况最终会导致损坏,因此有必要提供备用的冗余硬件,当一个组件发生损坏时,不中断服务。某些情况下,冗余的成本高于用户所能容忍的服务中断。此时,目标是保证所有服务能够在一个预期的时间范围内被还原。 虽然 Hadoop 集群本身是硬件容错的,但 HAWQ 有其特殊性。HAWQ master 的数据是存储在主机本地硬盘上的,是一个单点。作为最佳实践,HAWQ 建议在部署时,master 节点应该使用 RAID,而 segment 节点应该使用 JBOD。这些硬件级别的系统为单一磁盘损坏提供高性能冗余,而不必进入到数据库级别的容错。RAID 和 JBOD 在磁盘级别提供了低层次的冗余。
高可用集群中的 master 节点有两个,一个主一个从。和 master 节点与 segment 节点分开部署类似,master 的主和从也应该部署到不同的主机,以容忍单一主机失效。客户端连接到主 master 节点并且查询只能在主 master 节点上执行。从 master 节点保持与主 master 节点的实时同步,这是通过将预写日志从主复制到从实现的。
可以通过部署两套 HAWQ 集群,存储相同的数据,从而增加另一级别的冗余。有两个主要方法用于保持双集群的数据同步,分别是双 ETL 和备份 / 还原。 双 ETL 提供一个与主集群数据完全相同的备用集群。ETL(抽取、装换与装载)指的是一个数据清洗、转换、验证和装载进数据仓库的过程。通过双 ETL,将此过程并行执行两次,每次在一个集群中执行。应该在两个集群上都进行验证,以确保双 ETL 执行成功。这种做法是最彻底的冗余,需要部署两套 HAWQ 集群与 ETL 程序。该方法带来的一个附加好处是应用利用双集群,能够同时在两个集群上查询数据,将查询吞吐量增加一倍。 用备份 / 还原方法维护一个双集群,需要创建一个主集群的备份,并在备用集群上还原。这种方法与双 ETL 策略相比,备用节点数据同步的时间要长的多,但优点是只需要开发更少的应用逻辑。如果数据修改和 ETL 执行的频率是每天或更低的频率,同时备份 / 还原时间又在可接受的范围内,那么用备份生成数据是比较理想的方式。注意,备份 / 还原方法不适用于要求数据实时同步的情况。
在 HAWQ 中配置一主一从两个 master 节点,客户端连接点主 master 节点,并只能在主 master 节点上执行查询。从 master 是一个纯粹的容错节点,只作为主 master 出现问题时的备用。如果主 master 节点不可用,从 master 节点作为热备。可以在主 master 节点联机时,从它创建一个从 master 节点。 当主 master 节点持续为用户提供服务时,HAWQ 可以生成主 master 节点实例的事务快照。除了生成事务快照并部署到从 master 节点外,HAWQ 还记录主 master 节点的变化。在 HAWQ 在从 master 节点部署了快照后,HAWQ 会应用更新以将从 master 节点与主 master 节点数据同步。 主从 master 节点初始同步后,HAWQ 分别在主、从节点上启动 WAL Send 和 WAL Redo 服务器进程,保持主从实时同步。它们是基于预写日志(Write-Ahead Logging,WAL)的复制进程。WAL Redo 是一个从 master 节点进程,WAL Send 是主 master 节点进程。这两个进程使用基于 WAL 的流复制保持主从同步。 因为 master 节点不保存用户数据,只有系统目录表在主从 master 节点间被同步。当这些系统表被更新时(如 DDL 所引起),改变自动拷贝到从 master 节点保持它与当前的主 master 节点数据一致。 HAWQ 中的 master 节点镜像架构如图 1 所示。
图 1 如果主 master 节点失效,复制进程停止。此时管理员需要使用命令行工具或者 Ambari,手工执行 master 切换,指示从 master 节点成为新的主 master 节点。在激活从 master 节点后,复制的日志重构主 master 节点在最后成功提交事务时的状态。当从 master 节点初始化后,被激活的从作为 HAWQ 的主节点,在指定端口接收连接请求。 可以为主、从配置同一个虚 IP 地址,这样在主从切换时,客户端程序就不需要连接到两个不同的网络地址。如果主机失效,虚 IP 可以自动交换到实际活动的主节点。虚 IP 可能需要额外的软件支持,如 Keepalived 等。
hdp2 为现有的主 master 节点,下面过程将 hdp3 配置为 hdp2 的从 master 节点。(1)前提配置 确保 hdp3 上已经安装了 HAWQ 并进行了以下配置:
(2)初始化从 master 节点 登录 hdp3,清空 master 数据目录。
- [root@hdp3~]#rm - rf / data / hawq / master
- /**/
登录 hdp2,初始化从 master 节点
- [gpadmin@hdp2 ~]$ . /usr/local/hawq/greenplum_path.sh
- [gpadmin@hdp2 ~]$ hawq init standby -s hdp3
(3)检查 HAWQ 集群状态
- [gpadmin@hdp2 ~]$ hawq state
图 2
- [gpadmin@hdp2 ~]$ psql -c 'SELECT * FROM gp_segment_configuration;'
图 3
- [gpadmin@hdp2 ~]$ psql -c 'SELECT * FROM gp_master_mirroring;'
图 4
当主 master 不可用时,需要手工执行切换,将从 master 激活为主 master。(1)保证系统中已经配置从 master 节点主机。(2)激活从 master 节点。 登录到 HAWQ 从 master 节点并激活它,之后从 master 成为了 HAWQ 的主 master。
- [gpadmin@hdp3 ~]$ hawq activate standby
手工切换 master 后,最好配置一个新的从 master 节点,继续保持 master 的高可用性,配置过程参考 "1. 配置从 master 节点"。
如果主、从之间的日志同步进程停止或者落后,从 master 可能变成过时状态。如果遇到这种情况,查询 gp_master_mirroring 视图时,会看到 summary_state 字段输出中显示 Not Synchronized。为了将从与主重新进行同步,在主 master 节点上执行下面的命令:
- [gpadmin@hdp3 ~]$ hawq init standby -n
该命令停止并重启主 master 节点,然后同步从 master 节点。
如果在初始化 HAWQ 时没有启用 HDFS 的高可用性,可以使用下面的过程启用它。
(1)HDFS HA 概述 HDFS 中的 NameNode 非常重要,其中保存了 DataNode 上数据块存储位置的相关关系。它主要维护两个映射,一个是文件到块的对应关系,一个是块到节点的对应关系。如果 NameNode 停止工作,就无法知道数据所在的位置,整个 HDFS 将陷入瘫痪,因此保证 NameNode 的高可用性是非常重要的。 在 Hadoop 1 时代,只有一个 NameNode。如果该 NameNode 数据丢失或者不能工作,那么整个集群就不能恢复了。这是 hadoop 1 中的单点故障问题,也是 hadoop 1 不可靠的表现。图 5 是 hadoop 1 的架构图。
图 5
为了解决 hadoop 1 中的单点问题,hadoop 2 中支持两个 NameNode,每一个都有相同的职能。一个是 active 状态的,一个是 standby 状态的。当集群运行时,只有 active 状态的 NameNode 是正常工作的,standby 状态的 NameNode 处于待命状态,时刻同步 active 状态 NameNode 的数据。一旦 active 状态的 NameNode 不能工作,通过手工或者自动切换,将 standby 状态的 NameNode 转变为 active 状态,就可以继续工作了。 Hadoop 2 中,两个 NameNode 的数据是实时共享的。新 HDFS 采用了一种共享机制,通过 Quorum Journal Node(JournalNode)集群或者 Network File System(NFS)进行共享。NFS 是操作系统层面的,JournalNode 是 hadoop 层面的(主流做法)。图 6 为 JournalNode 的架构图。
图 6
两个 NameNode 为了数据同步,会通过一组称作 JournalNodes 的独立进程进行相互通信。当 active 状态的 NameNode 的命名空间有任何修改时,会告知 JournalNodes 进程。standby 状态的 NameNode 有能力读取 JNs 中的变更信息,并且一直监控 edit log 的变化,把变化应用于自己的命名空间。standby 可以确保在集群出错时,命名空间状态已经完全同步。 对于 HA 集群而言,确保同一时刻只有一个 NameNode 处于 active 状态是至关重要的。否则,两个 NameNode 的数据状态就可能产生分歧,或造成数据丢失,或产生错误的结果。为了保证这点,需要利用 ZooKeeper。首先 HDFS 集群中的两个 NameNode 都在 ZooKeeper 中注册,当 active 状态的 NameNode 出故障时,ZooKeeper 能检测到这种情况,然后它就会自动把 standby 状态的 NameNode 切换为 active 状态。(2)使用 Ambari 启用 HDP 的高可用性(参考 How To Configure NameNode High Availability)。
图 7
图 8
图 9
图 11
图 12
图 13
图 14
至此已经配置好 HDP HDFS 的高可用性。从 NameNode UI 可以看到,hdp1 和 hdp2 分别显示为 active 和 standby。如图 15、16 所示。
图 15
图 16
此时在 hdp1 上执行如下命令关闭 hdp1 上的 NameNode:
- [hdfs@hdp1 ~]$ /usr/hdp/2.5.0.0-1245/hadoop/sbin/hadoop-daemon.sh stop namenode
- stopping namenode
- [hdfs@hdp1 ~]$
再次查看 hdp2 上的 NameNode,发现已自动切换为 active,如图 17 所示。
图 17
此时在 hdp1 上执行如下命令启动 hdp1 上的 NameNode:
- [hdfs@hdp1 ~]$ /usr/hdp/2.5.0.0-1245/hadoop/sbin/hadoop-daemon.sh start namenode
- stopping namenode
- [hdfs@hdp1 ~]$
再次查看 hdp1 上的 NameNode,发现已自动切换为 standby,如图 18 所示。
图 18
缺省的文件空间名为 dfs_system,存在于 pg_filespace 目录,其参数 pg_filespace_entry 包含每个文件空间的细节信息。为了将文件空间位置迁移到 HDFS HA 的位置,必须将数据迁移到集群中新的 HDFS HA 路径。 使用下面的 SQL 查询收集关于 HDFS 上的文件空间位置信息。
- SELECT
- fsname, fsedbid, fselocation
- FROM
- pg_filespace AS sp, pg_filespace_entry AS entry, pg_filesystem AS fs
- WHERE
- sp.fsfsys = fs.oid AND fs.fsysname = 'hdfs' AND sp.oid = entry.fsefsoid
- ORDER BY
- entry.fsedbid;
输出包含信息中包含 HDFS 路径共享相同的前缀,以及当前文件空间的位置,如图 19 所示。
图 19
为了在 HAWQ 中使用 HDFS HA,需要文件空间名和 HDFS 路径的通用前缀信息。文件空间位置的格式类似一个 URL。如果无 HA 的文件空间位置是'hdfs://test5:9000/hawq/hawq-1459499690',并且 HDFS HA 的通用前缀是'hdfs://hdfs-cluster',那么新的文件空间位置应该是'hdfs://hdfs-cluster/hawq/hawq-1459499690'。
注意:Ambari 用户必须手工执行这个步骤。 在 HAWQ 中启用 HDFS HA 时会修改 HAWQ 的目录和永久表。因此迁移文件空间位置前,先要备份目录,以确保不会因为硬件失效或在一个操作期间(如杀掉 HAWQ 进程)丢失数据。(1)如果 HAWQ 主节点使用了一个定制端口,输出 PGPORT 环境变量。例如:
- export PGPORT=8020
(2)保存 HAWQ master 节点目录,在 hawq-site.xml 文件中找到 hawq_master_directory 属性,赋给一个环境变量。
- export MDATA_DIR=/data/hawq/master
(3)断掉所有连接。使用以下查询检查活动连接:
- [gpadmin@hdp3 ~]$ psql -c "SELECT * FROM pg_catalog.pg_stat_activity"
(4)执行检查点
- [gpadmin@hdp3 ~]$ psql -c "CHECKPOINT"
(5)停止 HAWQ 集群
- [gpadmin@hdp3 ~]$ hawq stop cluster -a -M fast
(6)拷贝主节点数据目录到备份的位置:
- $ cp - r $ {
- MDATA_DIR
- }
- /catalog/backup / location
主节点数据目录包含子目录,一定要备份此目录。
注意:Ambari 用户必须手工执行这个步骤。HAWQ 提供了命令行工具 hawq filespace,迁移文件空间的位置。(1)如果 HAWQ 主节点使用了一个定制端口,输出 PGPORT 环境变量。例如:
- export PGPORT=9000
(2)运行下面的命令迁移文件空间的位置:
- [gpadmin@hdp3 master] $ hawq filespace--movefilespace
- default--location = hdfs: //mycluster/hawq_data
迁移文件空间时可能出现的以下潜在错误:
如果使用命令行应用安装和管理 HAWQ 集群,参考 http://hawq.incubator.apache.org/docs/userguide/2.1.0.0-incubating/admin/HAWQFilespacesandHighAvailabilityEnabledHDFS.html#configuregphomeetchdfsclientxml,修改 HAWQ 配置以使用 NameNode HA 服务。 如果使用 Ambari 管理 HDFS 和 HAWQ,不需要执行这些步骤,因为 Ambari 在启用了 NameNode HA 后会自动做这些修改。
(1)重启 HAWQ 集群
- [gpadmin@hdp3 master]$ hawq start cluster -a
(2)迁移文件空间到新位置会使从 master 节点无效,因此需要重新同步从 master 节点。在主 master 节点上,运行下面的命令保证从 master 节点的目录与主 master 节点重新同步。
- [gpadmin@hdp3 master]$ hawq init standby -n -M fast
至此已经在 HAWQ 的文件空间中使用了 HDFS HA,再次查询文件空间的信息,输出结果如图 20 所示。
图 20
HAWQ 的容错服务(fault tolerance service,FTS)使得 HAWQ 可以在 segment 节点失效时持续操作。容错服务自动运行,并且不需要额外的配置。 每个 segment 运行一个资源管理进程,定期(缺省每 30 秒)向主节点的资源管理进程发送 segment 状态。这个时间间隔由 hawq_rm_segment_heartbeat_interval 服务器配置参数所控制。当一个 segment 碰到严重错误,例如,由于硬件问题,segment 上的一个临时目录损坏,segment 通过心跳报告向 master 节点报告有一个临时目录损坏。master 节点接收到报告后,在 gp_segment_configuration 表中将该 segment 标记为 DOWN。所有 segment 状态的变化都被记录到 gp_configuration_history 目录表,包括 segment 被标记为 DOWN 的原因。当这个 segment 被置为 DOWN,master 节点不会在该 segment 上运行查询执行器。失效的 segment 与集群剩下的节点相隔离。 包括磁盘故障的其它原因会导致一个 segment 被标记为 DOWN。举例来说,HAWQ 运行在 YARN 模式中,每个 segment 应该有一个运行的 NodeManager(Hadoop 的 YARN 服务),因此 segment 可以被看做 HAWQ 的一个资源。但如果 segment 上的 NodeManager 不能正常操作,那么该 segment 会在 gp_segment_configuration 表中被标记为 DOWN。失效对应的原因被记录进 gp_configuration_history。 注意:如果一个特定段上的磁盘故障,可能造成 HDFS 错误或 HAWQ 中的临时目录错误。HDFS 的错误由 Hadoop HDFS 服务所处理。
为了查看当前 segment 的状态,查询 gp_segment_configuration 表。如果 segment 的状态是 DOWN,"description" 列显示原因。原因可能包括下面的任何原因,可能是单一原因,也可能是以分号(";")分割的几个原因。 原因:heartbeat timeout 主节点没有接收到来自段的心跳。如果看到这个原因,确认该 segment 上的 HAWQ 是否运行。如果 segment 在以后的时间报告心跳,segment 被自动标记为 UP。 原因:failed probing segment master 节点探测 segment 以验证它是否能被正常操作,段的响应为 NO。在一个 HAWQ 实例运行时,查询分发器发现某些 segment 上的查询执行器不能正常工作。master 节点上的资源管理器进程向这个 segment 发送一个消息。当 segment 的资源管理器接收到来自 master 节点的消息,它检查其 PostgreSQL 的 postmaster 进程是否工作正常,并且向 master 节点发送一个响应消息。当 master 节点收到的响应消息表示该 segment 的 postmaster 进程没有正常工作,那么 master 节点标记段为 DOWN,原因记为 "failed probing segment."。检查失败 segment 的日志并且尝试重启 HAWQ 实例。 原因:communication error master 节点不能连接到 segment。检查 master 节点和 segment 之间的网络连接。 原因: resource manager process was reset 如果 segment 资源管理器进程的时间戳与先前的时间戳不匹配,意味着 segment 上的资源管理器进程被重启过。在这种情况下,HAWQ master 节点需要回收该 segment 上的资源并将其标记为 DOWN。如果 master 节点从该 segment 接收到一个新的心跳,它会自动标记为 UP。 原因:no global node report HAWQ 使用 YARN 管理资源,但没有为该 segment 接收到集群报告。检查该 segment 上的 NodeManager 是否可以正常操作。如果不能,尝试启动该 segment 上的 NodeManager。在 NodeManager 启动后,运行 yarn node --list 查看该节点是否在列表中。如过存在,该段被自动置为 UP。
来源: http://blog.csdn.net/wzy0623/article/details/70599534