![AWS ELB 作为 Varnish Accelerator 的后端](https://linux22.com/image/591549/AWS%20ELB%20%E4%BD%9C%E4%B8%BA%20Varnish%20Accelerator%20%E7%9A%84%E5%90%8E%E7%AB%AF.png)
我正在 AWS 上进行大规模部署,该部署对正常运行时间要求很高,并且全天负载变化很大。显然,这是 ELB(弹性负载均衡器)和自动扩展的完美用例。
但是,我们也依赖 varnish 来缓存 API 调用。我最初的直觉是构建堆栈,以便 varnish 使用 ELB 作为后端,进而访问 appGroup。
Varnish -> ELB -> AppServers
然而,根据A 很少 来源这是不可能的,因为 ELB 不断改变其 DNS 主机名的 IP 地址,而 Varnish 在启动时会缓存该地址,这意味着 Varnish 不会获取对 IP 的更改。
然而,读了周围的资料后,我发现似乎有人在这么做,所以我想知道有什么解决方法?也许是一个定期重新加载 vcl 的脚本?
如果这真的不是一个好主意,还有其他解决方案吗?
答案1
这绝对是可能的,但需要几个步骤才能让它正常工作!当我们需要这种配置时,我们这样做的方式是:
创建 VPC。您需要在 VPC 中执行此操作,因为您需要在其中创建子网。
在每个可用区中创建一个子网,您将在其中注册 ELB 的实例。您应该划分子网,以便每个子网中都有少量 IP 地址,因为每个 IP 地址都会成为开销。(我们目前使用的子网是 /26)
开始在您的 varnish VCL 中创建 DNS Director 后端。添加您上面创建的 3 个子网。(https://www.varnish-cache.org/docs/3.0/reference/vcl.html#the-dns-director)
将 DNS Director 后端中的主机设置设为 varnish 期望看到的主机名。(例如,如果您的前端服务名为 front-end-service.subdomain.example.com,则将 front-end-service.example.com 作为 VCL 中的主机设置。)
将 DNS Director 中的后缀设置设置为您可以解析的内容。继续上面的示例,您可以轻松地使用“-varnish.example.com”作为后缀。当请求到达 varnish 时,varnish 将查看 HTTP Host 标头,如果名称与 varnish 在 VCL 的 DNS Director Backend 中为 Host 标头设置的名称匹配,varnish 将附加后缀并对主机名执行 DNS 查找,这是将 Host 标头的内容与后缀连接起来的结果。因此,在此示例中,varnish 将对名为“front-end-service.subdomain.example.com-varnish.example.com”的主机执行 DNS 查找
创建负载均衡器后端并将其附加到您创建的每个子网。
将连接结果的 DNS 记录设置为 Amazon 为您的负载均衡器提供的 DNS 名称的 CNAME。
启动 varnish,可选择查看 varnishstat 来验证后端的数量。
通过发出
curl -H“主机:front-end-service.subdomain.example.com”http://varnish-server-hostname.example.com/whatever-path
使用 varnishlog 观察请求,以验证一切是否正常。
值得注意的是,如果您要将负载均衡器放置在该子网中,AWS 建议您的子网中至少包含 20 个未使用的 IP 地址。(请参阅http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html)
我们最近在一个项目中完成了这项工作,该项目需要 ELB 来满足需求规范,但我们担心如何在管理方面进行扩展,并正在研究基于服务发现的方法以及诸如自动 VCL 更新之类的方法,以及通过 Varnish Agent 之类的工具进行自动 VCL 部署(https://github.com/varnish/vagent2)
但是,如果您不介意管理您的 VPC 子网,上述描述非常有效。
干杯!
答案2
ELB 的部分目的是应对主机中断。即使使用自动扩展和 CloudWatch,如果需要更换死机实例,您也可能需要几分钟的停机时间。
我建议:
[Front End ELB] -> [Varnish] -> [Back End ELB] -> [AppServers]
我知道你想尽可能地利用缓存,但是你真的应将负载分散到所有可用区域。这意味着您的堆栈所在的区域 A、B 和 C 中的实例数量相等(因此是 3x Varnish)。这当然会花费更多,但它使您能够在整个可用区中断的情况下生存下来*。削减这笔费用意味着在某个时候您可能需要承担停机时间。这是您要做出的决定,但至少您可以做出明智的决定。
有两个安全组,一个用于 Varnish,一个用于 AppServers。配置每个安全组,以便只有关联的 ELB 才能在适当的端口上访问它。
对于 Varnish 配置,请将 DNS 控制器设置为较低的 TTL。将其设置为 Amazon 为后端 ELB 提供的 CNAME 的 TTL 的相等值(或一半)。这足以让 Varnish 保持最新状态。
* 如果您想要获得极致的可用性,请使用具有多区域、多可用区冗余的 Route53。
答案3
Varnish 实际上可以充当负载均衡器。你应该尝试一下Varnish -> AppServers
。
只需将每个应用服务器定义为 Varnish 配置中的控制器的后端即可。
您甚至可以添加探测器来检查后端可用性,当请求过程中一个服务器失败时重试切换到另一个服务器等。
您的 Varnish 实例托管在哪里?ASW 也是吗?您可以尝试 Varnish 哈希管理器,并将 Varnish 托管在与应用程序相同的服务器上。每个实例将处理它应该处理的请求,并将其他请求转发到正确的后端。每个唯一 URL 只会缓存在 1 个(可用)服务器上,并且您的缓存内存将乘以 Varnish 实例的数量,同时缓存未命中将受到限制。