search
Home

多可用区（AZ）

hashtag
简介

Alluxio 通过支持多可用区实现高可用性。当本地可用区（ AZ ）内的所有 Worker 都无法处理请求时，Alluxio 客户端可以回退至其他 AZ 中的 Worker。

多可用区支持，加上多副本和底层文件系统回退机制，提供了强大的服务可用性和 I/O 弹性。更多相关信息参见 Alluxio的I/O 弹性功能。

hashtag
启用多可用区支持

在存在多个可用区的典型部署场景中，通常是每个 AZ 部署一个 Alluxio 集群。为了区分各 AZ 中的集群，需要为每个 Alluxio 集群分配唯一的集群名称。

创建一个JSON配置文件，指定所有可用区的Alluxio集群及其对应的etcd集群。以下是一个包含3个集群的示例：

[
   {
      "clusterNames": ["cluster-1"],
      "endpoints": ["http://etcd-1:2379"]
   },
   {
      "clusterNames": ["cluster-2"],
      "endpoints": ["http://etcd-2:2379"]
   },
   {
      "clusterNames": ["cluster-3"],
      "endpoints": ["http://etcd-3:2379"]
   }
]

将此配置文件保存为multi-az-clusters.json，并放置在Alluxio的配置目录中，然后在alluxio-site.properties中指定路径：

如果 Alluxio 已在运行，需重启所有进程以使配置生效。重启后，可使用以下命令检查多 AZ 支持是否配置成功：

如果配置正确，该命令将显示来自各 AZ 中所有 Alluxio 集群的 Worker 节点信息：

hashtag
使用 Operator 部署多个 Alluxio 集群

Alluxio Operator 提供了在 Kubernetes 环境中部署和管理 Alluxio 集群的标准方法。有关安装 Alluxio Operator 的详细说明，请参阅 Alluxio Operator 安装指南.

Operator 通过名为 clusterGroup 的自定义资源支持部署多个 Alluxio 集群。

通过 clusterGroup，用户可以在Kubernetes环境中统一定义和管理多个 Alluxio 集群的配置，从而实现高效编排和维护。

注意：通过 clusterGroup 创建的集群将共享同一套配置（包括属性设置、资源分配和扩缩容策略）。 要区分不同集群，需要使用 Kubernetes 的 nodeSelector 字段，将每个 Alluxio 集群限制部署在对应的 AZ 上，确保集群之间的物理隔离。

hashtag
准备步骤

以下示例将在两个 Kubernetes 命名空间中部署三个 Alluxio 集群：

  • 集群 1: alluxio-a in namespace alx-ns

  • 集群 2: alluxio-b in namespace alx-ns

  • 集群 3: alluxio-c in namespace alx-ns-2

部署前确保已创建所需命名空间 (alx-ns and alx-ns-2)：

hashtag
基于ETCD的多集群部署模式

为了配置多个集群，需要创建一个包含各个集群名称及其 ETCD 信息的 ConfigMap。根据 ETCD 的配置方式不同，每个集群的 ETCD 信息可能有所不同。

在使用 clusterGroup 资源部署多个 Alluxio 集群时，Alluxio 支持以下三种部署模式，这些模式依据 ETCD 的设置方式分类如下：

  • 每个集群使用独立的 ETCD 实例

    • 每个 Alluxio 集群使用其专属的 ETCD 实例。

  • 多个集群共享同一个 ETCD 实例

    • 多个集群共用一个 ETCD 实例，同时通过独立的命名空间实现隔离。

  • 集成外部 ETCD

    • 各集群连接至由外部托管的 ETCD 服务

这些模式为不同的运维需求和基础架构提供了灵活的部署选项，用户可根据实际情况选择合适的模式。

hashtag
独立ETCD 模式

独立 ETCD 部署模式下，每个 Alluxio 集群运行在其专属的 ETCD 实例上。

Independent ETCD topology

在此模式下，配置文件 multi-az-clusters.json 必须进行自定义，从而为每个集群指定独立的 ETCD 端点，示例如下：

必须在每个命名空间中创建 ConfigMap，并使用相同的配置文件：

然后，定义并应用ClusterGroup清单来部署各个集群。要点如下：

  1. 必须在每个集群的properties中指定多集群 JSON 配置文件的路径。

  2. ConfigMap 必须挂载到所有 Alluxio 集群组件中的 /multi-az 目录下。

此外，用户需在 dependencies 中省略 ETCD 依赖项，以禁用 clusterGroup 中的内部 ETCD 配置功能。

在此配置中，每个 Alluxio 集群将在各自的命名空间内独立启动并管理其专属的 ETCD 实例。clusterGroup 本身不会部署任何 ETCD 集群。

可通过list集群组命名空间中的 Pod 来进行验证。

每个 Alluxio 集群将在其对应的命名空间中运行自己的 ETCD 服务。 例如，在命名空间 alx-ns 中，alluxio-a 和 alluxio-b 两个集群将分别部署各自的 ETCD Pod：

同样地，alluxio-c 会在 alx-ns-2 命名空间中启动自己的 ETCD 实例。

要验证所有集群的状态，可使用以下命令：

输出示例:

hashtag
共享 ETCD 模式

共享 ETCD 部署模式下，所有 Alluxio 集群共用同一个 ETCD 集群来进行协调。

Shared ETCD Multi-AZ Diagram

首先创建一个名为 multi-az-clusters.json 的 JSON 配置文件，用于指定参与的 Alluxio 集群及其共享的 ETCD 端点：

必须在每个命名空间中创建 ConfigMap，并使用相同的配置文件：

然后，定义并应用ClusterGroup清单来部署各个集群。要点如下：

  1. 必须在每个集群的properties中指定多集群 JSON 配置文件的路径。

  2. ConfigMap 必须挂载到所有 Alluxio 集群组件中的 /multi-az 目录下。

要启用此模式，需要在 ClusterGroup 资源的 dependencies 中配置 ETCD 依赖项。

示例如下：

使用以下命令来应用此YAML 文件：

应用完成后，将会创建一个共享ETCD 集群，所有 Alluxio 集群都会连接到该集群：

集群 alluxio-a和 alluxio-b 将部署在命名空间 alx-ns中：

位于alx-ns-2命名空间下的集群，例如 alluxio-c，也将启动：

要验证集群状态和 Worker 注册情况，运行以下命令：

输出将显示多个 Alluxio 集群及其各自的 Worker 节点信息：

hashtag
外部 ETCD

外部 ETCD 模式下，所有 Alluxio 集群都会连接到一个共享的、由外部托管的 ETCD 集群。

如果已部署外部 ETCD 集群，可以配置 Alluxio 集群连接到该集群：

创建一个配置文件 multi-az-clusters.json，用于定义所有集群共享的外部 ETCD 端点：

必须在每个命名空间中创建 ConfigMap，并使用相同的配置文件：

然后，定义并应用ClusterGroup清单来部署各个集群。要点如下：

  1. 禁用 ETCD

    • 在 ClusterGroup配置中将 etcd.enabled 设置为 false，以防止 Operator 部署其自身的 ETCD 实例

    • 在 dependencies 中省略 etcd 依赖项。

  2. 在 Alluxio 集群的properties中指定外部 ETCD 端点。

ClusterGroup示例如下:

应用该配置:

外部 ETCD Pod 应在default命名空间中运行：

各个 Alluxio 集群的 Pod 在其对应的命名空间中运行：

检查多集群状态:

hashtag
启用多可用区多副本文件的 I/O优化

Alluxio 支持针对多副本文件的 I/O优化。当文件在多个可用区中存在副本时，这些副本不仅能提供更快的访问速度，还能在某个可用区发生故障导致部分集群不可用时，确保系统的高可用性。

当 Alluxio 客户端读取一个在多可用区中有副本的文件时，首先会检查本地集群中是否有任何本地 worker 缓存了该文件。如果有，客户端会尝试使用本地 worker 读取文件。如果本地没有缓存该文件，或者在本地可用区发生故障导致所有本地 worker 读取失败，客户端将回退到其他可用区中其他集群的 worker。如果所有候选 worker 都无法响应读取请求，客户端将最终回退到UFS，将其作为保底访问方案。

对于不在多个可用区中有副本的文件而言，客户端在本地 worker 读取失败时不会回退到其他可用区，而是直接回退到 UFS。

注意：如果启用了该功能，客户端会优先选择完整缓存的文件副本（即使该副本位于远程 worker）。客户端按照以下优先级顺序选择数据源：

  1. 拥有完整缓存文件的本地 worker。

  2. 拥有完整缓存文件的远程 worker。

  3. 本地或远程worker均没有完整缓存文件时，选择本地 worker。

  4. 本地候选 worker 不可用时，选择远程 worker。

  5. 所有可用区的候选 worker 均不可用时，回退到UFS。

hashtag
启用被动缓存

建议在多可用区多副本部署中启用 被动缓存（Passive Cache）功能。该配置能确保副本不足的文件自动生成更多副本，并且不会因首选 worker 缓存未命中而影响性能。

要启用 I/O 优化和被动缓存，请在 alluxio-site.properties 中添加以下配置：

Last updated