使用NGINX Plus对AWS Auto Scaling组进行负载均衡

NGINX | 2017年3月06日

云的一项重要优势是能够自动扩缩计算实例数量。借助AWS Auto Scaling，可以根据计划或需求，手动或自动更改Auto Scaling组中的EC2实例数量。Auto Scaling可根据当前工作负载将实例数量调整到适当水平，从而帮助降低成本。此外，Auto Scaling还会重启发生故障的实例，增强应用的韧性。

使用Auto Scaling时，负载均衡至关重要。AWS通过将其内置负载均衡器（Elastic Load Balancer (ELB)，现正式称为Classic Load Balancer，以及Application Load Balancer (ALB)）与Auto Scaling集成，为Auto Scaling组中的实例提供负载均衡。NGINX Plus可为包括AWS在内的任何云环境提供高级云负载均衡，并支持AWS Auto Scaling组。

选择NGINX Plus来替代或补充AWS内置云负载均衡器，主要有以下三个原因：

NGINX Plus提供了ELB和ALB所不具备的多项高级功能。
AWS负载均衡器（尤其是ALB）的定价模式较为复杂，因此难以预测成本。无论是直接向我们购买NGINX Plus订阅，还是运行AWS Marketplace中按固定小时费率计费的预构建NGINX Plus实例，NGINX Plus的定价都简单明了。
NGINX Plus不会将您绑定到特定于平台的API，因此可以在多个云平台上复用负载均衡配置。

要了解NGINX Plus与AWS内置解决方案的对比及协同工作方式，请阅读我们关于ELB和ALB的博客文章。

本文介绍了配置NGINX Plus以对Auto Scaling组进行负载均衡的两种方法，并说明了各自适用的场景：

在ELB前端使用NGINX Plus
将NGINX Plus与NGINX, Inc.提供的集成软件配合使用

阅读本篇博文后，您将能够在AWS上部署NGINX Plus，为Auto Scaling组提供高级负载均衡。

AWS Auto Scaling示例环境

我们使用一个示例应用环境来说明通过NGINX Plus对Auto Scaling组进行负载均衡的两种方法。后端Web应用由Backend One和Backend Two两项服务组成，均通过端口80对外提供服务。每项服务都有一个由多个应用实例组成的Auto Scaling组。负载均衡器根据请求URI将客户端请求路由到相应的后端：

对/backend‑one的请求将转发到Backend One。
对/backend‑two的请求将转发到Backend Two。

为使AWS Auto Scaling组充分发挥作用，需要在其前端部署NGINX Plus等云负载均衡器。

扩展应用程序的Auto Scaling组时（无论是自动扩展还是手动扩展），都必须更新负载均衡器配置，以反映应用程序实例数量的变化。AWS内置负载均衡器会自动完成此更新。对于NGINX Plus，需要使用上述方法之一将扩展事件传递到配置中（在ELB前部署NGINX Plus，或将NGINX Plus与集成软件配合使用）。

还可以使用外部服务注册中心，根据扩缩容事件更新NGINX Plus配置。NGINX Plus支持与提供DNS接口的服务发现系统集成，例如Consul。本篇博文重点介绍不依赖外部系统且易于设置和使用的解决方案。

在ELB前端使用NGINX Plus

如果已在使用 Auto Scaling 组和 ELB，要让应用使用 NGINX Plus 的部分高级功能，最简单的方法是将 NGINX Plus 部署在 ELB 云负载均衡器前端，如图所示：

将NGINX Plus用作AWS Auto Scaling组的云负载均衡器时，一种方式是将其部署在ELB前端，由ELB为这些组执行负载均衡。

在这种情况下，NGINX Plus充当一个或多个ELB的代理和负载均衡器。NGINX Plus利用其高级路由功能，根据请求URI将请求转发到相应的ELB。随后，ELB将请求传递给Auto Scaling组中的某个实例。在此配置中，ELB为扩展提供支持。

以下是NGINX Plus配置。

resolver 169.254.169.253 valid=10s;
upstream backend-one {
    zone backend-one 64k;
    server DNS-name-of-ELB-for-Backend-One resolve;
}

upstream backend-two {
    zone backend-two 64k;
    server DNS-name-of-ELB-for-Backend-Two resolve;
}

server {
    listen 80;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

The resolver指令定义了NGINX Plus用于解析内部ELB实例DNS名称的DNS服务器。此处为AWS DNS服务器的IP地址。
我们创建两个upstream块，分别用于与服务 Backend One 和 Backend Two 对应的两个 Auto Scaling 组。我们通过为 Auto Scaling 组提供流量负载均衡的 ELB 的 DNS 名称来标识该组。使用resolve参数可让 NGINX Plus 定期重新解析该名称；解析频率由上一项所述resolver指令的valid参数设置。由于 ELB 的 IP 地址可能频繁变化，此处将解析频率设置为 10 秒。zone指令分配内存（此处最多为 64 KB），用于存储解析出的 IP 地址。
我们定义一个虚拟server，用于侦听端口 80。location块指示NGINX Plus将针对/backend‑one的请求传递到Backend One Auto Scaling组的ELB，并将针对/backend‑two的请求传递到Backend Two Auto Scaling组的ELB。

可以看出，这种方法易于设置和使用，尤其是在已经使用ELB的情况下。不过，它也存在一些缺点：

负载均衡选项有限。由于NGINX Plus将请求传递给ELB，而不是直接传递给后端实例，因此负载均衡由ELB执行。这样便无法利用NGINX Plus更高级的负载均衡算法和会话持久性选项。
功能冗余。NGINX Plus可以执行负载均衡，因此ELB的功能是冗余的；我们之所以使用ELB，只是因为它与Auto Scaling原生集成。
协议支持有限。与NGINX Plus不同，ELB不支持WebSocket和UDP。

下一种方法不依赖ELB，因此不存在上述缺点。

将NGINX Plus与集成软件配合使用

使用此方法时，需要在安装NGINX Plus的同时安装额外的集成软件。该软件（nginx-asg-sync）会持续监控Auto Scaling组。检测到扩缩事件后，它会在NGINX Plus配置中添加或移除后端实例。如图所示，nginx-asg-sync通过AWS Auto Scaling API获知Auto Scaling组的变化。

要将NGINX Plus用作AWS Auto Scaling组的云负载均衡器，请安装nginx-asg-sync集成软件，以便通过AWS Auto Scaling API自动获知组变更。

要使用该集成软件，请执行以下步骤：

设置AWS API访问权限
安装集成软件
配置NGINX Plus
配置集成软件

这些说明假定后端的 Auto Scaling 组已存在，并且 NGINX Plus 正在 Amazon Linux AMI 上运行。

第 1 步：设置 AWS API 访问权限

与Auto Scaling API的通信需要进行身份验证，因此必须为nginx-asg-sync提供凭据。AWS使用IAM角色管理凭据，因此需要在启动NGINX Plus实例之前为其创建角色。有关分步说明，请参阅AWS文档中的《Amazon EC2的IAM角色》。

创建IAM角色，并为其附加预定义的AmazonEC2ReadOnlyAccess策略。此策略允许对EC2 API进行只读访问。
启动NGINX Plus实例时，将此IAM角色添加到该实例。

第 2 步：安装集成软件

要安装集成软件，请从nginx-asg-sync GitHub存储库下载适用于您操作系统的软件包，并将其安装在运行NGINX Plus的实例上。

对于Amazon Linux、CentOS和RHEL：

$ sudo rpm -i package-name.rpm

对于Ubuntu：

$ sudo dpkg -i package-name.deb

有关完整的安装说明，请参阅GitHub上的文档。

第3步：配置NGINX Plus

集成软件使用动态重新配置和实时活动监控API更新NGINX Plus配置。为确保软件正常运行，必须配置这些API，并声明必要的上游组：

配置用于动态重新配置和实时活动监控的API端点。集成软件使用这些端点在上游组中添加和移除后端实例。
为每个Auto Scaling组创建一个upstream块。不要在该块中定义任何服务器，因为nginx-asg-sync会根据扩缩容事件自动添加和移除服务器。

以下示例展示了简单Web应用的配置：

upstream backend-one {    zone backend-one 64k;
    state /var/lib/nginx/state/backend-one.conf;
}

upstream backend-two {
    zone backend-two 64k;
    state /var/lib/nginx/state/backend-two.conf;
}

server {
    listen 80;

    status_zone backend;

    location /backend-one {
        proxy_set_header Host $host;
        proxy_pass http://backend-one;
    }

    location /backend-two {
        proxy_set_header Host $host;
        proxy_pass http://backend-two;
    }
}

server {
    listen 8080;

    root /usr/share/nginx/html;

    location = / {
        return 302 /status.html;
    }

    location = /status.html {}

    location /status {
        access_log off;
        status;
    }

    location /upstream_conf {
        upstream_conf;
    }
}

与ELB示例一样，我们声明了两个上游组，即backend‑one和backend‑two，它们分别对应我们的Auto Scaling组。但在这里，我们没有向上游组添加任何服务器，因为服务器将由nginx‑aws‑sync添加。state指令用于指定存储可动态配置服务器列表的文件，使该列表在NGINX Plus重启后仍能保留。
我们定义了一个虚拟server，用于侦听端口80。与ELB示例不同，NGINX Plus将针对/backend‑one的请求直接传递给Backend One组中的实例，并将针对/backend‑two的请求直接传递给Backend Two组中的实例。
我们定义了另一个侦听端口 8080 的虚拟服务器，并在该服务器上配置 NGINX Plus API：
- 动态配置API可通过以下地址访问：127.0.0.1:8080/upstream_conf
- 状态API的访问地址为127.0.0.1:8080/status

第4步：配置集成软件

集成软件在文件“aws.yaml”中配置，该文件位于“/etc/nginx”文件夹中。针对本应用，我们定义以下配置：

region: us-west-2upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
status_endpoint: http://127.0.0.1:8080/status
sync_interval_in_seconds: 5
upstreams:
 - name: backend-one
   autoscaling_group: backend-one-group
   port: 80
   kind: http
 - name: backend-two
   autoscaling_group: backend-two-group
   port: 80
   kind: http

The region键用于定义部署应用程序的AWS区域。
The upstream_conf_endpoint 和 status_endpoint 键定义了NGINX Plus API端点，这些端点已在第3步中配置。
The sync_interval_in_seconds键用于定义同步间隔：nginx-asg-sync每5秒检查一次扩缩容更新。
The upstreams键定义上游组列表。对于每个上游组，需要指定：
- name：在步骤 3 中为upstream块指定的名称。
- autoscaling_group，对应的 Auto Scaling 组名称。
- port：后端服务对外开放的端口。
- kind：NGINX Plus向后端应用进行负载均衡的流量协议，此处为http。如果应用使用TCP/UDP，请改为指定stream。

编辑aws.yaml文件后，重启软件：

$ sudo restart nginx-asg-sync

测试负载均衡和扩缩容

在上述步骤中，我们已配置NGINX Plus，为应用的Auto Scaling组提供负载均衡。现在可以进行测试。NGINX Plus会将URI为/backend‑one的请求分发到Backend One组中的实例，并将URI为/backend‑two的请求分发到Backend Two组中的实例。

扩展Auto Scaling组时，可以查看NGINX Plus如何发现新实例。首先，访问NGINX Plus实例的8080端口上通过实时活动监控仪表板，该仪表板可通过/status.html访问。在Upstream选项卡中，可以看到Auto Scaling组中的实例：

使用NGINX Plus作为云负载均衡器时，实时活动监控仪表板上的“Upstreams”选项卡会显示每个AWS Auto Scaling组中的应用实例。

现在，我们通过更改Auto Scaling组的容量，将Backend One组从3个实例扩展到5个。新实例启动后，nginx-asg-sync会将其添加到NGINX Plus配置中。很快，新实例就会显示在仪表板上：

当AWS Auto Scaling组中的应用实例数量发生变化时，NGINX Plus实时活动监控仪表板会立即显示新的组成员。

实现NGINX Plus高可用

到目前为止，我们只启动了一个NGINX Plus实例。不过，为实现高可用性，建议为NGINX Plus本身创建一个Auto Scaling组，并在NGINX Plus实例前使用ELB。除了ELB，也可以使用Route 53将流量路由到NGINX Plus实例。使用ELB的部署架构如下图所示：

要将NGINX Plus配置为AWS Auto Scaling组的高可用云负载均衡器，请将NGINX Plus部署在ELB或Route 53之后。

选择合适的方法

那么，哪种配置NGINX Plus为Auto Scaling组提供负载均衡的方法更适合您？下表简要比较了这两种方法：

ELB前端部署NGINX Plus 使用集成软件的NGINX Plus优势配置简单，无需安装其他软件。可充分利用NGINX Plus的所有功能，不受ELB方法的任何限制。劣势可使用的NGINX Plus功能（包括支持的协议）受到限制。会增加部署成本和延迟。需要安装和配置集成软件。总结如果可以接受其劣势，请使用此方法。如需充分利用NGINX Plus的功能，请使用此方法。