使用Atlas进行元数据管理之容错和高可用

1. 介绍

Apache Atlas使用各类系统并与之交互，为数据管理员提供元数据管理和数据血缘信息。经过适当地选择和配置这些依赖关系，可使用Atlas实现高度的服务可用性。本文档介绍了Atlas中的高可用性支持状态，包括其功能和当前限制，以及实现此高级别可用性所需的配置。

在高级架构章节(请参阅我翻译的《Atlas开发指南(中文版)》)概述了构成Atlas的各类组件。下面提到的各类组件的选项从上面的页面中获取上下文，在继续阅读本页以前值得一看。

2. Atlas Web Service

目前，Atlas Web Service有一个限制，即它一次只能有一个活动实例。在早期版本的Atlas中，能够配置备份实例并使其可用。可是，须要手动故障转移才能使此备份实例处于活动状态。

今后版本开始，Atlas将经过自动故障转移支持活动(active)/被动(passive)配置中的多个Atlas Web服务实例。这意味着用户能够同时在不一样的物理主机上部署和启动Atlas Web Service的多个实例。其中一个实例将自动选为“active”实例以服务用户请求。其余人将自动被视为“passive”。若是“active”实例因故意中止或因为意外故障而变得不可用，则其余实例之一将自动被选为“active”实例并开始为用户请求提供服务。

“active”实例是惟一能够正确响应用户请求的实例。它能够建立，删除，修改或响应元数据对象上的查询。 “passive”实例将接受用户请求，但会使用HTTP重定向将其重定向到当前已知的“active”实例。具体而言，passive实例自己不会响应对元数据对象的任何查询。可是，全部实例（active和passive）都将响应返回有关该实例的信息的管理请求。

在高可用性模式下配置时，用户能够得到如下操做收益：

• 维护间隔期间不间断的服务：若是须要关闭Atlas Web Service的活动实例以进行维护，则另外一个实例将自动变为活动状态并能够为请求提供服务。
• 意外故障时的不间断服务：若是Atlas Web Service的活动实例因软件或硬件错误而失败，则另外一个实例将自动变为活动状态并能够为请求提供服务。

在如下小节中，咱们将介绍为Atlas Web Service设置高可用性所需的步骤。咱们还描述了如何设计部署和客户端以利用此功能。最后，咱们描述了底层实现的一些细节。

2.1 在Atlas中设置高可用性功能

设置高可用性功能必须知足如下先决条件。

• 确保在一组计算机上安装Apache Zookeeper（建议至少使用3台服务器进行生产）。
• 选择2个或更多物理计算机以运行Atlas Web Service实例。这些机器定义了咱们称之为Atlas的“服务器集合”。

要在Atlas中设置高可用性，必须在atlas-application.properties文件中定义一些配置选项。虽然在配置页面中定义了完整的配置项列表，但本节列出了一些主要选项。

• 高可用性是Atlas中的可选功能。所以，必须经过将配置选项atlas.server.ha.enabled设置为true来启用它。
• 接下来，定义标识符列表，每一个物理机一个用于Atlas Web Service实例。这些标识符能够是简单的字符串，如id1，id2等。它们应该是惟一的，不该包含逗号。
• 将这些标识符的逗号分隔列表定义为选项atlas.server.ids的值。
• 对于每台物理计算机，将IP地址/主机名和端口列为配置atlas.server.address.id的值，其中id表示此物理计算机的标识符字符串。
  • 例如，若是您选择了2台主机名为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

• 定义将由Atlas高可用性功能使用的Zookeeper集群。

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 Service的每一个实例。

要验证高可用性是否正常，请在安装了Atlas Web Service的每一个实例上运行如下脚本。

$ATLAS_HOME/bin/atlas_admin.py -status

此脚本能够打印如下值之一做为响应：

• ACTIVE：此实例处于活动状态，能够响应用户请求。
• PASSIVE：这个实例是被动的。它会将收到的任何用户请求重定向到当前活动实例。
• BECOMING_ACTIVE：若是服务器正在转换为ACTIVE实例，则会打印出来。服务器没法在此状态下为任何元数据用户请求提供服务。
• BECOMING_PASSIVE：若是服务器正在转换为PASSIVE实例，则会打印出来。服务器没法在此状态下为任何元数据用户请求提供服务。

在正常操做状况下，这些实例中只有一个应该打印值ACTIVE做为对脚本的响应，而其余实例将打印PASSIVE。

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

能够经过两种方式访问​​Atlas Web Service：

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

为了利用客户端中的高可用性功能，有两种选择。

(1)使用中间代理

实现对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时才被视为成功。

(2)使用活动实例自动检测

若是不想设置和管理单独的代理，则使用高可用性功能的另外一个选项，是构建可以检测状态和重试操做的客户端应用程序。在这样的设置中，可使用造成总体的全部Atlas Web Service实例的URL启动客户端应用程序。而后，客户端应在每一个上面调用REST URL/api/atlas/admin/status以肯定哪一个是活动实例。 Active实例的响应形式为{Status：ACTIVE}。此外，当客户端在操做过程当中面临任何异常时，它应该再次肯定哪些剩余URL处于活动状态并重试该操做。

Atlas附带的AtlasClient类可用做示例客户端库，该库实现处理集合并选择正确的Active Server实例的逻辑。

Atlas中的实用程序（如quick_start.py和import-hive.sh）能够配置为与多个服务器URL一块儿运行。在此模式下启动时，AtlasClient会自动选择并使用当前活动实例。若是在二者之间设置了代理，则在运行quick_start.py或import-hive.sh时可使用其地址。

2.3 Atlas高可用性的实现细节

Atlas高可用性工做在主JIRA ATLAS-510下进行跟踪。在其下提交的JIRA提供了有关如何实施高可用性功能的详细信息。在高层次上，能够调出如下几点：

• 自动选择Active实例，以及经过领导者选举算法自动故障转移到新的Active实例。
• 对于领导者选举，咱们使用Leader Latch Recipe of Apache Curator。
• Active实例是惟一一个在后端存储中初始化，修改或读取状态以保持一致的实例。
• 此外，当实例被选为活动时，它会刷新来自后端存储的任何缓存信息以获取最新信息。
• servlet过滤器确保只有活动实例服务用户请求。若是被动实例接收到这些请求，它会自动将它们重定向到当前活动实例。

3. 元数据存储

Atlas使用JanusGraph存储和管理元数据。默认状况下，Atlas使用独立的HBase实例做为JanusGraph的底层存储。为了为元数据存储提供HA，咱们建议将Atlas配置为使用分布式HBase做为JanusGraph的底层存储。要将Atlas配置为在HA模式下使用HBase，请执行如下操做：

• 选择在HA模式下设置的现有HBase群集，以在Atlas（OR）中进行配置在HA模式下设置新的HBase群集。
  • 若是为Atlas设置HBase，请按照Atlas官网“Installation Steps”，列出的HBase的相关设置说明进行操做。
• 建议在使用Zookeeper进行协调的不一样物理主机上的群集中使用多个HBase主服务器（至少2个），以提供HBase的冗余和高可用性。
• 有关在atlas.properties中配置以使用HBase设置Atlas的选项，请参阅我翻译的《Atlas开发指南(中文版)》中“配置”章节。

4. 索引存储

如上所述，Atlas经过JanusGraph索引元数据以支持全文搜索查询。为了给索引存储提供HA，咱们建议将Atlas配置为使用Solr或Elasticsearch做为JanusGraph的索引存储支撑。

4.1 Solr

要将Atlas配置为在HA模式下使用Solr，请执行如下操做：

• 选择HA模式下的现有SolrCloud群集设置以在Atlas中配置（OR）设置新的SolrCloud群集。
  • 确保Solr在至少2个物理主机上启用以实现冗余，而且每一个主机都运行Solr节点。
  • 建议将冗余数量设置为至少2个副本。
• 建立Atlas所需的SolrCloud集合，详见Atlas官网“Installation Steps”。
• 有关在atlas.properties中配置以使用Solr设置Atlas的选项，请参阅我翻译的《Atlas开发指南(中文版)》的文档中“配置”章节。

4.2 Elasticsearch

要将Atlas配置为在HA模式下使用Elasticsearch，请执行如下操做：

• 选择现有的Elasticsearch集群设置，（或）设置新的集群Elasticsearch集群。
• 确保Elasticsearch在至少五个物理主机上启用以实现冗余。
• 建议设置分片数量为3
• 有关在atlas.properties中配置以使用Elasticsearch设置Atlas的选项，请参阅我翻译的《Atlas开发指南(中文版)》的文档中“配置”章节。

5. 通知服务

来自Hook的元数据通知事件经过写入名为ATLAS_HOOK的Kafka Topic发送到Atlas。一样，从Atlas到其余集成组件（如Ranger）的事件也会写入名为ATLAS_ENTITIES的Kafka Topic。因为Kafka持久化这些消息，即便消费者因发送事件而关闭，事件也不会丢失。此外，咱们建议Kafka也设置容错，以便它具备更高的可用性保证。要将Atlas配置为在HA模式下使用Kafka，请执行如下操做：

• 选择在HA模式下设置的现有Kafka群集，以在Atlas（OR）中配置设置新的Kafka群集。
• 建议群集中不一样的Kafka代理在不一样的物理主机上使用Zookeeper进行协调，以提供Kafka的冗余和高可用性。
  • 设置至少2个物理主机以实现冗余，每一个主机托管一个Kafka代理。
• 为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.

6. 问题

若是托管Atlas表的HBase region servers挂掉，Atlas将没法存储或检索HBase中的元数据，直到它们从新联机。