Flink部署——高可用

概览

JobManager 高可用（HA）模式加强了 Flink 集群防止 JobManager 故障的能力。 此特性确保 Flink 集群将始终持续执行你提交的作业。

JobManager 高可用

JobManager 协调每个 Flink 的部署。它同时负责 调度 和 资源管理。

默认情况下，每个 Flink 集群只有一个 JobManager 实例。这会导致 单点故障（SPOF）：如果 JobManager 崩溃，则不能提交任何新程序，运行中的程序也会失败。

使用 JobManager 高可用模式，你可以从 JobManager 失败中恢复，从而消除单点故障。你可以为每个集群部署配置高可用模式。 有关更多信息，请参阅 高可用服务。

如何启用集群高可用

JobManager 高可用一般概念是指，在任何时候都有 一个领导者 JobManager，如果领导者出现故障，则有多个备用 JobManager 来接管leader。这保证了 不存在单点故障，只要有备用 JobManager 担任leader，程序就可以继续运行。

如下是一个使用三个 JobManager 实例的例子：

Flink 的 高可用服务 封装了所需的服务，使一切可以正常工作：

• 领导者选举：从 n 个候选者中选出一个领导者
• 服务发现：检索当前领导者的地址
• 状态持久化：继承程序恢复作业所需的持久化状态（JobGraphs、用户代码jar、已完成的检查点）

高可用服务

Flink 提供了两种高可用服务实现：

• ZooKeeper：每个 Flink 集群部署都可以使用 ZooKeeper HA 服务。它们需要一个运行的 ZooKeeper 复制组（quorum）。
• Kubernetes：Kubernetes HA 服务只能运行在 Kubernetes 上。

高可用数据生命周期

为了恢复提交的作业，Flink 持久化元数据和 job 组件。高可用数据将一直保存，直到相应的作业执行成功、被取消或最终失败。当这些情况发生时，将删除所有高可用数据，包括存储在高可用服务中的元数据。

JobResultStore

JobResultStore 用于存档达到全局终端状态（即已完成、取消或失败）的作业的最终结果。数据存储在文件系统上（请参见 job-result-store.storage-path）。只要未正确清理相应的作业，此存储中的条目就会被标记为脏（在高可用性.storageDir 的作业子文件夹中可以找到项目）。

脏条目需要清理，即相应的作业要么由 Flink 立即清理，要么作为恢复的一部分进行清理。清理成功后，将立即删除这些条目。检查 HA 配置选项下的 JobResultStore 配置参数，以获取有关如何调整行为的更多详细信息。

ZooKeeper 高可用服务

Flink 的 ZooKeeper 高可用模式使用 ZooKeeper 提供高可用服务。

Flink 利用 ZooKeeper 在所有运行的 JobManager 实例之间进行 分布式协调。ZooKeeper 是一个独立于 Flink 的服务，它通过 leader 选举和轻量级的一致性状态存储来提供高可靠的分布式协调。查看 ZooKeeper入门指南，了解更多关于 ZooKeeper 的信息。Flink 包含 启动一个简单的ZooKeeper 的安装脚本。

配置

为了启用高可用集群（HA-cluster），你必须设置以下配置项:

high-availability (必要的): high-availability 配置项必须设置为 zookeeper。

high-availability: zookeeper

high-availability.storageDir (必要的): JobManager 元数据持久化到文件系统 high-availability.storageDir 配置的路径中，并且在 ZooKeeper 中只能有一个目录指向此位置。

high-availability.storageDir: hdfs:///flink/recovery

storageDir 存储要从 JobManager 失败恢复时所需的所有元数据。

high-availability.zookeeper.quorum (必要的): ZooKeeper quorum 是一个提供分布式协调服务的复制组。

high-availability.zookeeper.quorum: address1:2181[,...],addressX:2181

每个 addressX:port 指的是一个 ZooKeeper 服务器，它可以被 Flink 在给定的地址和端口上访问。

high-availability.zookeeper.path.root (推荐的): ZooKeeper 根节点，集群的所有节点都放在该节点下。

high-availability.zookeeper.path.root: /flink

high-availability.cluster-id (推荐的): ZooKeeper cluster-id 节点，在该节点下放置集群所需的协调数据。

high-availability.cluster-id: /default_ns # important: customize per cluster

重要: 在 YARN、原生 Kubernetes 或其他集群管理器上运行时，不应该手动设置此值。在这些情况下，将自动生成一个集群 ID。如果在未使用集群管理器的机器上运行多个 Flink 高可用集群，则必须为每个集群手动配置单独的集群 ID（cluster-ids）。

配置示例

在 conf/flink-conf.yaml 中配置高可用模式和 ZooKeeper 复制组（quorum）:

high-availability: zookeeper
high-availability.zookeeper.quorum: localhost:2181
high-availability.zookeeper.path.root: /flink
high-availability.cluster-id: /cluster_one # 重要: 每个集群自定义
high-availability.storageDir: hdfs:///flink/recovery

ZooKeeper 安全配置

如果 ZooKeeper 使用 Kerberos 以安全模式运行，必要时可以在 flink-conf.yaml 中覆盖以下配置:

# 默认配置为 "zookeeper". 如果 ZooKeeper quorum 配置了不同的服务名称，
# 那么可以替换到这里。

zookeeper.sasl.service-name: zookeeper 

# 默认配置为 "Client". 该值必须为 "security.kerberos.login.contexts" 项中配置的某一个值。
zookeeper.sasl.login-context-name: Client  

有关用于 Kerberos 安全性的 Flink 配置的更多信息，请参阅 Flink 配置页面的安全性部分。你还可以找到关于 Flink 如何在内部设置基于 kerberos 的安全性 的详细信息。

高级配置

容忍挂起的 ZooKeeper 连接

默认情况下，Flink 的 ZooKeeper 客户端将挂起的 ZooKeeper 连接视为错误。这意味着 Flink 将使其组件的所有领导无效，从而在连接挂起时触发故障转移。

在某些情况下（例如，不稳定的网络环境），这种行为可能具有太大的破坏性。如果您愿意采取更激进的方法，则可以容忍挂起的 ZooKeeper 连接，并且仅通过高可用性将丢失的连接视为错误。zookeeper.client.tolerate-suspended-connections。启用此功能将使 Flink 对临时连接问题更具弹性，但也会增加遇到 ZooKeeper 时序问题的风险。

ZooKeeper 版本

Flink 附带了 3.4 和 3.5 的单独的 ZooKeeper 客户端，其中 3.4 位于发行版的 lib 目录中，为默认使用版本，而 3.5 位于 opt 目录中。

3.5 客户端允许你通过 SSL 保护 ZooKeeper 连接，但 可能 不适用于 3.4 版本的 ZooKeeper 安装。

你可以通过在 lib 目录中放置任意一个 jar 来控制 Flink 使用哪个版本。

启动 ZooKeeper

如果你没有安装 ZooKeeper，可以使用 Flink 附带的帮助脚本。

在 conf/zoo.cfg 文件中有 ZooKeeper 的配置模板。你可以在 server.X 配置项中配置主机来运行 ZooKeeper。其中 X 是每个服务器的唯一 ID:

server.X=addressX:peerPort:leaderPort
[...]
server.Y=addressY:peerPort:leaderPort

脚本 bin/start-zookeeper-quorum.sh 将在每个配置的主机上启动一个 ZooKeeper 服务。该进程是通过 Flink 包装器来启动的，该包装器从 conf/zoo.cfg 读取配置，并确保设置一些必要的配置值以方便使用。

在生产环境中，建议你自行管理 ZooKeeper 的安装与部署。

Kubernetes 高可用服务

官网地址