容错与高可用性选项

简介

Apache Atlas 使用并与多种系统进行交互，以便为数据管理员提供元数据管理和数据血缘功能。通过适当地选择和配置这些依赖组件，可以实现 Atlas 服务的高可用性。本文档描述了 Atlas 高可用性支持的现状，包括其能力与当前的限制，以及实现这一级别高可用性所需的配置。

架构页面（位于 wiki 中）概述了构成 Atlas 的各个组件。下面针对各组件提到的选项均以上述页面为背景，在继续阅读本页面之前，建议先阅读该页面。

Atlas Web 服务

目前，Atlas Web 服务存在一个限制，即同一时间只能有一个活动实例。在 Atlas 的早期版本中，可以配置一个备用实例并使其保持可用状态，但需要手动进行故障切换才能使该备用实例变为活动状态。

从本版本开始，Atlas 将支持以主动/被动配置方式运行多个 Atlas Web 服务实例，并支持自动故障切换。这意味着用户可以在不同的物理主机上同时部署并启动多个 Atlas Web 服务实例。其中将自动选出一个实例作为"活动"实例来处理用户请求，其余实例则自动被视为"被动"实例。如果"活动"实例由于被主动停止或意外故障而不可用，其他实例中的一个将自动被选为"活动"实例并开始处理用户请求。

"活动"实例是唯一能够正确响应用户请求的实例。它可以创建、删除、修改元数据对象，或响应针对元数据对象的查询。"被动"实例会接收用户请求，但会通过 HTTP 重定向将其转发给当前已知的"活动"实例。具体而言，被动实例自身不会响应任何针对元数据对象的查询。不过，所有实例（包括活动实例和被动实例）都会响应返回该实例相关信息的管理请求。

配置为高可用模式后，用户可以获得以下运维方面的收益：

维护期间服务不中断：如果 Atlas Web 服务的活动实例需要停机维护，另一个实例将自动变为活动状态并能够处理请求。
意外故障时服务不中断：如果 Atlas Web 服务的活动实例因软件或硬件错误而故障，另一个实例将自动变为活动状态并能够处理请求。

在以下小节中，我们将介绍为 Atlas Web 服务设置高可用（High Availability）所需的步骤，并说明如何设计部署方式与客户端以充分利用该能力。最后，我们还会介绍一些底层实现的细节。

在 Atlas 中设置高可用功能

设置高可用功能需要满足以下前提条件。

确保已在一组机器上安装 Apache ZooKeeper（生产环境建议至少 3 台服务器）。
选择 2 台或更多物理机器来运行 Atlas Web 服务实例。这些机器构成了 Atlas 所说的"服务器集合"。

要在 Atlas 中设置高可用，必须在 atlas-application.properties 文件中定义若干配置项。完整的配置项列表见配置页面，本节仅列出其中几个主要选项。

高可用是 Atlas 中的可选功能。因此，必须将配置项 atlas.server.ha.enabled 设置为 true 才能启用。

接下来，为选定的每一台物理机器各定义一个标识符，用于 Atlas Web 服务实例。这些标识符可以是 id1、id2 之类的简单字符串，必须唯一且不能包含逗号。

将这些标识符以逗号分隔的形式作为选项 atlas.server.ids 的值。

对于每台物理机器，将其 IP 地址/主机名和端口作为配置项 atlas.server.address.id 的值，其中 id 指的是该物理机器对应的标识符字符串。
- 例如，如果选择的两台机器的主机名分别为 host1.company.com 和 host2.company.com，则可以按如下方式定义配置项：

atlas.server.ids=id1,id2
atlas.server.address.id1=host1.company.com:21000
atlas.server.address.id2=host2.company.com:21000

定义 Apache Atlas 高可用功能将使用的 ZooKeeper 仲裁集群（quorum）。

atlas.server.ha.zookeeper.connect=zk1.company.com:2181,zk2.company.com:2181,zk3.company.com:2181

你可以查看为高可用性功能定义的其他配置选项，并根据需要在 atlas-application.properties 文件中进行设置。
在生产环境中，Atlas 所依赖的组件也必须以高可用性模式进行部署。下面的章节对此有详细说明。请按照这些说明进行设置和配置。
在选定的物理机器上安装 Atlas 软件。
将使用上述步骤创建的 atlas-application.properties 文件复制到所有机器的配置目录中。
启动依赖组件。
启动 Atlas Web 服务的每个实例。

要验证高可用性是否正常工作，请在安装了 Atlas Web 服务的每个实例上运行以下脚本。

$ATLAS_HOME/bin/atlas_admin.py -status

该脚本可以输出以下任意一个值作为响应：

ACTIVE：该实例处于活动状态，可以响应用户请求。
PASSIVE：该实例处于被动状态。它会将收到的任何用户请求重定向到当前的活动实例。
BECOMING_ACTIVE：当服务器正在向活动实例转换时，会输出该值。在此状态下，服务器无法处理任何元数据用户请求。
BECOMING_PASSIVE：当服务器正在向被动实例转换时，会输出该值。在此状态下，服务器无法处理任何元数据用户请求。

在正常运行情况下，这些实例中应当只有一个将 ACTIVE 作为脚本的响应输出，其余实例则会输出 PASSIVE。

配置客户端以使用高可用功能

Atlas Web 服务可以通过两种方式访问：

使用 Atlas Web UI：这是一个基于浏览器的客户端，可用于查询 Atlas 中存储的元数据。
使用 Atlas REST API：由于 Atlas 提供了 RESTful API，因此可以使用任何标准的 REST 客户端，包括其他应用程序中的类库。事实上，Atlas 附带了一个名为 AtlasClient 的客户端，可以将其作为构建 REST 客户端访问的示例。

为了在客户端中利用高可用功能，有两种可选方案。

使用中间代理

启用对 Atlas 的高可用访问，最简单的方案是安装并配置某种能够根据状态透明切换服务的中间代理。其中一种代理方案是 HAProxy。

以下是可使用的 HAProxy 配置示例。请注意，此示例仅用于演示，并非推荐的生产环境配置。如需生产环境配置，请参阅 HAProxy 文档以获取相应指导。

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend  main *:8080
    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js

    use_backend static          if url_static
    default_backend             app

backend static
    balance     roundrobin
    server      static 127.0.0.1:4331 check

backend app
    balance     roundrobin
    server  app1 127.0.0.1:21000 check
    server  app2 127.0.0.1:21000 check

frontend atlas_fe
  bind *:41000
  default_backend atlas_be
backend atlas_be
  mode http
  option httpchk get /api/atlas/admin/status
  http-check expect string ACTIVE
  balance roundrobin
  server host1_21000 host1:21000 check
  server host2_21000 host2:21000 check backup
listen atlas
  bind localhost:42000

上述配置使 HAProxy 监听 41000 端口以接收客户端连接。随后，它会根据 HTTP 状态检查，将连接路由到 host1 或 host2 其中一台主机。该状态检查通过对 REST URL /api/atlas/admin/status 执行 HTTP GET 来完成，只有当 HTTP 响应中包含字符串 ACTIVE 时，才被视为检查成功。

使用对活动实例的自动检测

如果不想搭建并维护一个独立的代理，那么使用高可用功能的另一种方式是构建一个能够检测状态并重试操作的客户端应用程序。在这种设置下，可以使用构成该集群的所有 Atlas Web 服务实例的 URL 来启动客户端应用程序。然后，客户端应依次对这些实例调用 REST URL /api/atlas/admin/status，以确定哪个是活动实例。来自活动实例的响应形式为 {Status:ACTIVE}。此外，当客户端在操作过程中遇到任何异常时，应再次确定剩余 URL 中哪个处于活动状态，并重试该操作。

Atlas 自带的 AtlasClient 类可用作示例客户端库，其中实现了与集群协同工作以及选择正确活动服务实例的逻辑。

Atlas 中的工具（如 quick_start.py 和 import-hive.sh）可以配置为使用多个服务 URL 运行。以这种模式启动时，AtlasClient 会自动选择当前的活动实例并与之协作。如果中间搭建了代理，则在运行 quick_start.py 或 import-hive.sh 时可以使用该代理的地址。

Atlas 高可用的实现细节

Atlas 高可用相关工作由主 JIRA ATLAS-510 跟踪。其下提交的各个 JIRA 中详细说明了高可用功能的实现方式。总体而言，可以归纳出以下几点：

活动实例的自动选择以及向新的活动实例的自动故障转移，均通过领导者选举算法完成。
对于领导者选举，我们使用 Apache Curator 的 Leader Latch 配方
活动实例是唯一会初始化、修改或读取后端存储中状态的实例，以确保这些状态保持一致。
此外，当某个实例被选为活动实例时，它会刷新从后端存储获取的所有缓存信息，以获取最新数据。
一个 servlet 过滤器确保只有活动实例才处理用户请求。如果被动实例收到这些请求，它会自动将请求重定向到当前的活动实例。

元数据存储

如上所述，Atlas 使用 JanusGraph 存储其管理的元数据。默认情况下，Atlas 使用独立的 HBase 实例作为 JanusGraph 的后备存储。为了为元数据存储提供高可用性（HA），我们建议将 Atlas 配置为使用分布式 HBase 作为 JanusGraph 的后备存储。这样做意味着你可以受益于 HBase 提供的高可用性保证。要将 Atlas 配置为以 HA 模式使用 HBase，请执行以下操作：

选择一个已配置为 HA 模式的现有 HBase 集群用于 Atlas 配置（或者）搭建一个新的 HA 模式的 HBase 集群。
- 如果要为 Atlas 搭建 HBase，请按照安装步骤中列出的 HBase 搭建说明进行操作。
我们建议集群中使用多个 HBase master（至少 2 个），并将其部署在不同的物理主机上，通过 Zookeeper 进行协调，从而提供 HBase 的冗余和高可用性。
- 参考配置页面，了解在 atlas.properties 中配置 Atlas 使用 HBase 所需的选项。

索引存储

如上所述，Atlas 通过 JanusGraph 对元数据建立索引，以支持全文搜索查询。为了为索引存储提供高可用性，我们建议将 Atlas 配置为使用 Solr 或 Elasticsearch 作为 JanusGraph 的后备索引存储。

Solr

要将 Atlas 配置为以 HA 模式使用 Solr，请执行以下操作：

选择一个已配置为 HA 模式的现有 SolrCloud 集群用于 Atlas 配置（或者）搭建一个新的 SolrCloud 集群。
- 确保 Solr 至少在 2 台物理主机上启动以实现冗余，并且每台主机运行一个 Solr 节点。
- 我们建议将副本数设置为至少 2，以实现冗余。
按照安装步骤中的说明创建 Atlas 所需的 SolrCloud collection。
参考配置页面，了解在 atlas.properties 中配置 Atlas 使用 Solr 所需的选项。

Elasticsearch（技术预览版）

要将 Atlas 配置为以 HA 模式使用 Elasticsearch，请执行以下操作：

选择一个现有的 Elasticsearch 集群配置用于 Atlas 配置（或者）搭建一个新的 Elasticsearch 集群。
- 确保 Elasticsearch 至少在五台物理主机上启动以实现冗余。
- 建议将副本数设置为 3。
参考配置页面，了解在 atlas.properties 中配置 Atlas 使用 Elasticsearch 所需的选项。

通知服务器

来自 Hook 的元数据通知事件通过写入名为 ATLAS_HOOK 的 Kafka 主题发送给 Atlas。类似地，Atlas 发送给 Ranger 等其他集成组件的事件会被写入名为 ATLAS_ENTITIES 的 Kafka 主题。由于 Kafka 会持久化这些消息，即使消费者在事件发送期间宕机，事件也不会丢失。此外，我们建议对 Kafka 也进行容错配置，以提供更高的可用性保证。要配置 Atlas 以在高可用模式下使用 Kafka，请执行以下操作：

选择一个已在高可用模式下搭建的现有 Kafka 集群配置到 Atlas 中（或者）搭建一个新的 Kafka 集群。

我们建议集群中包含多个分布在不同物理主机上的 Kafka broker，通过 Zookeeper 进行协调，以提供 Kafka 的冗余和高可用性。
- 至少搭建 2 台物理主机以实现冗余，每台主机上部署一个 Kafka broker。

为 Atlas 使用搭建 Kafka 主题：
- Atlas 主题的分区数量应设置为 1（numPartPartitions）
- 确定 Kafka 主题的副本数量：为实现冗余，至少设置为 2。
- 执行以下命令：

$KAFKA_HOME/bin/kafka-topics.sh --create --zookeeper <list of zookeeper host:port entries> --topic ATLAS_HOOK --replication-factor <numReplicas> --partitions 1
   $KAFKA_HOME/bin/kafka-topics.sh --create --zookeeper <list of zookeeper host:port entries> --topic ATLAS_ENTITIES --replication-factor <numReplicas> --partitions 1
   Here KAFKA_HOME points to the Kafka installation directory.

在 atlas-application.properties 中，设置以下配置：

atlas.notification.embedded=false
   atlas.kafka.zookeeper.connect=<comma separated list of servers forming Zookeeper quorum used by Kafka>
   atlas.kafka.bootstrap.servers=<comma separated list of Kafka broker endpoints in host:port form> - Give at least 2 for redundancy.

已知问题

如果承载 Atlas 表的 HBase Region Server 宕机，在其恢复上线之前，Atlas 将无法从 HBase 存储或检索元数据。

高可用性