KnowForge/Apache Atlas 2.5.0 简体中文
功能特性

高可用性

qianmoQqianmoQ· 更新于 2026-09-28· 阅读 18 分钟· 0 次阅读
登录后可跨设备保存划线和私人笔记登录

容错与高可用选项

简介

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

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

Atlas Web 服务

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

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

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

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

  • 维护期间服务不中断：如果需要关闭某个 Atlas Web 服务的活动实例进行维护，另一个实例会自动变为活动状态并服务请求。
  • 意外故障时服务不中断：如果 Atlas Web 服务的活动实例因软件或硬件错误而故障，另一个实例会自动变为活动状态并服务请求。

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

在 Atlas 中设置高可用性功能

设置高可用性功能必须满足以下前提条件。

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

要在 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 的 2 台机器，可以如下定义配置项：
atlas.server.ids=id1,id2
atlas.server.address.id1=host1.company.com:21000
atlas.server.address.id2=host2.company.com:21000
  • 定义 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：如果服务器正在向 ACTIVE 实例转换，则会打印此值。在此状态下，服务器无法处理任何元数据用户请求。
  • BECOMING_PASSIVE：如果服务器正在向 PASSIVE 实例转换，则会打印此值。在此状态下，服务器无法处理任何元数据用户请求。

在正常运行情况下，这些实例中应只有一个对脚本的响应打印 ACTIVE，其余实例则打印 PASSIVE。

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

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

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

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

使用中间代理

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

以下是可使用的一个 HAProxy 配置示例。请注意，此示例仅用于说明，并非推荐的生产环境配置。有关生产环境配置，请参阅 HAProxy 文档以获取适当的指导。

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 时，才视为检查成功。

使用活动实例的自动检测

如果不希望搭建和管理单独的代理，那么使用高可用特性的另一种方式是构建一个能够检测状态并重试操作的客户端应用。在这种场景下，可以将构成该集合（ensemble）的所有 Atlas Web Service 实例的 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 集群进行配置，（或者）搭建一个新的 Elasticsearch 集群。

    • 确保 Elasticsearch 在至少五台物理主机上运行以实现冗余。
    • 建议将副本数设置为 3。

  • 参阅配置页面，了解在 atlas.properties 中配置 Atlas 与 Elasticsearch 集成的选项。

通知服务器

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

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

  • 我们建议集群中存在多个位于不同物理主机上的 Kafka broker，通过 Zookeeper 进行协调，以提供 Kafka 的冗余和高可用性。

    • 至少搭建 2 台物理主机以实现冗余，每台主机运行一个 Kafka broker。

  • 为 Atlas 用途设置 Kafka 主题：

    • ATLAS 主题的分区数量应设置为 1（numPartitions）
    • 确定 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 RegionServer 宕机，则在这些 RegionServer 恢复上线之前，Atlas 将无法从 HBase 存取元数据。

评论

登录后参与评论

正在加载评论…