数据库负载平衡:分布式与集中式

134 阅读5分钟

数据库负载平衡:分布式设置与集中式设置

Ashraf Sharif 【hudson译】

2020年9月15日

图片

数据库负载平衡器或数据库反向代理将传入的数据库工作负载分布在其后面运行的多个数据库服务器上。拥有数据库负载平衡器的目标是为应用程序提供单个数据库端点以进行连接,提高查询吞吐量,最小化延迟,并最大限度地提高数据库服务器的资源利用率。

数据库负载平衡器拓扑有两种方式:

  • 集中式拓扑
  • 分布式拓扑

在这篇博客文章中,我们将介绍这两种拓扑结构,并了解每种设置的优缺点。此外,是否可以将这两种拓扑混合在一起?

集中式拓扑

在集中式设置中,反向代理位于数据层和表示层之间,如下图所示:

集中式负载平衡器拓扑

为了消除单点故障,必须设置两个或多个负载平衡器节点以实现冗余。如果您的应用程序可以处理多个数据库端点,例如,如果应用程序或数据库驱动程序能够执行健康检查,确定负载平衡器是否正常处理查询,那么您可能可以跳过虚拟IP地址部分。否则,两个负载平衡器节点都应该与一个公共主机名或虚拟IP地址绑定在一起,以便为数据库客户端提供透明性,在这些客户端中,只需使用单个数据库端点即可访问数据层。如果您想跳过使用虚拟IP地址,也可以使用DNS或主机映射。

这种基于层的方法由于其独立的静态主机位置,管理起来要简单得多。负载平衡器层不太可能向外扩展(添加更多节点),因为它在弹性、冗余和对应用层的透明性方面有坚实的基础。您可能需要扩展主机(向主机添加更多资源),这通常会在很长一段时间后发生,因为随着业务的增长,负载平衡器的工作负载变得越来越苛刻。

此拓扑需要额外的层和主机,这在具有物理服务器的裸机基础架构中可能成本高昂。在云或虚拟环境中,此设置更易于管理,您可以灵活地在应用程序层和数据库层之间添加额外的层,而不会在物理基础设施成本(如电力、机架空间和网络成本)上花费太多。

分布式拓扑

在分布式拓扑设置中,负载平衡器位于表示层(应用程序或web服务器)内,如下图所示:

分布式数据库负载平衡器拓扑

对应用程序而言,数据库负载平衡器类似于本地数据库服务器,其中负载平衡器从应用程序的角度成为远程数据库的表示。通常,负载平衡器将侦听本地网络接口,如127.0.0.1或“localhost”,这将为应用程序简化数据库端点数据库主机。

在这种拓扑中运行的优点之一是,您不需要额外的主机来实现负载平衡。通过在表示层中组合负载平衡器层,我们可以节省至少两台主机。在裸机环境中,这种拓扑结构可以在多年内为您节省大量资金。通常,与数据库或应用程序工作负载相比,负载平衡器工作负载的要求要低得多,这使得与应用程序共享相同的硬件资源是合理的。

当与应用程序服务器位于同一位置时,可以使反向代理更接近应用程序,并消除单点故障。当应用程序和数据层在地理位置上分离时,这可以显著提高应用程序性能,特别是对于支持结果集缓存的数据库负载平衡器,如ProxySQLMaxScale. 另一方面,数据库负载平衡器的数量通常等于应用程序节点的数量,这意味着如果应用程序层扩大,数据库负载均衡器的数量将增加,这可能会降低数据库健康检查服务的性能。请注意,负载平衡器健康检查有点过于繁琐,因为它有责任保持数据库节点的正确状态。

在Chef、Puppet和Ansible等IT基础设施自动化工具以及容器编排工具的帮助下,自动部署和管理此拓扑的多个负载平衡器实例已不再是不可能的任务。然而,运营团队还有另一条学习曲线,可以制定经过实践测试的生产级部署和管理策略,以减少处理许多负载平衡器节点时的过度工作。不要错过数据库负载平衡器的所有重要管理方面,如备份/恢复、升级/降级、配置管理、服务控制、故障管理等。

对于某些受支持的数据库负载平衡器(如ProxySQL),分布式拓扑可以与集中式拓扑混合使用 如下图所示:

分布式和集中式反向代理-数据库负载平衡器拓扑

一个ProxySQL实例的后端“服务器”是另一组ProxySQ节点。使用此配置,不需要虚拟IP地址,即可对数据库节点的单端点访问,因为从应用程序的角度来看,应用程序服务器上本地托管的本地ProxySQL实例将是单端点访问。

但是,这需要两个版本的负载平衡器配置–一个位于应用层,另一个位于负载平衡器层。它还需要更多主机,不需要了解虚拟IP地址技术、IP故障转移等。分布式和集中式设置的优点和缺点在这种拓扑结构中融合在一起。

结论

每个拓扑结构都有自己的优缺点,必须从一开始就做好规划。这一早期决策至关重要,从长远来看,它会极大地影响应用程序的性能、可伸缩性、可靠性和可用性。