Redis在与主/从服务器相同的服务器中哨兵？

Question

我一直在阅读有关如何使用Redis Sentinel的一些内容,我知道可以有2个或更多的标记,并在从客户端调用时在它们之间实现负载平衡.

将这两个哨兵与我的主人+奴隶放在同一个服务器上是一种好习惯吗？换句话说,在与主服务器相同的物理服务器中有1个标记,而在从服务器的同一个物理服务器中有另一个标识符吗？

在我看来,如果主服务器死机,从机中的标记将简单地将从机升级为主机.如果从服务器死了,那没关系,因为主服务器仍在运行.

我错过了什么吗？有什么缺点？

我宁愿让哨兵与主/从属于同一物理服务器,以减少延迟.

Answer 1

首先,Sentinel不是负载均衡器或Redis的代理.

其次,并非所有失败都是主人的死亡.有时服务器会短暂挂起,有时网络电缆会被拔掉,等等.因此,在与Redis实例相同的主机上运行Sentinel并不是一个好习惯.如果您使用Sentinel来管理故障转移,那么在Redis主服务器和从服务器以外的节点上运行的任何少于3个标记就会出现问题.

Sentinel使用仲裁机制对故障转移和从属进行投票.如果只有不到两个哨兵,你就会面临分裂大脑的风险,而两个或更多Redis服务器认为它们是高手.

想象一下你运行两个服务器并在每个服务器上运行sentinel的场景.如果丢失了一个,则会失去可靠的故障转移功能.

客户端仅连接到Sentinel以了解当前的主连接信息.无论何时客户端失去连接,他们都会重复此过程.Sentinel不是Redis的代理 - Redis的命令直接转到Redis.

运行少于三个标记的Sentinel的唯一可靠原因是服务发现,这意味着不使用它进行故障转移管理.

考虑两个主机场景:

Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2  (Quorum 1)

如果主机B在此方案中暂时失去与主机A的网络连接,则HostB将自我升级为主站.现在你有:

Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2  (Quorum 1)

连接到Sentinel 2的任何客户端都将被告知主机B是主服务器,而连接到Sentinel 1的客户端将被告知主机A主服务器(如果您的负载平衡器后面有Sentinels,则意味着一半客户端).

因此,您需要运行以获得最低可接受的可靠故障转移管理:

Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2

您的客户端连接到标记并获取Redis实例的当前主服务器(按名称),然后连接到它.如果主服务器死亡,客户端将丢弃连接,客户端将/应该再次连接到Sentinel并获取新信息.

每个客户端库处理此问题的程度取决于库.

理想情况下,主机C,D和E位于您连接到Redis的相同主机上(即客户端主机).或代表一个良好的抽样得到它们.这里的主要目的是确保您从需要连接到Redis的位置进行检查.如果没有将它们放在与客户端相同的DC /机架/区域中.

如果您希望让客户与负载均衡器通信,请尽可能在这些LB节点上安装Sentinels,根据需要添加额外的非LB主机以获得奇数个标记> 2.例外情况是客户端主机是动态的,因为它们的数量不一致(例如,它们会针对流量进行扩展,而针对缓慢的时段进行缩减).在这种情况下,您几乎必须在非客户端和非Redis服务器主机上运行Sentinels.

请注意,如果执行此操作,则需要编写一个守护程序,监视Sentinel PUBSUB通道以获取主交换机事件以更新LB,您必须将其配置为仅与当前主服务器通信(从不尝试与两者通信).这样做还需要做更多工作,但确实使用Sentinel对客户端透明 - 它只知道与LB IP /端口通信.

Answer 2

这一切都取决于您想要实现的灾难恢复级别,让我们假设您拥有以下组件,与托管位置无关:

• 2哨兵
• 1硕士
• 1奴隶

1 Master 1+ Slaves

一个主机场景

主机失败:您丢失了所有内容,大多数用例的错误复制方案.

两个主机场景

主持人1:

• (当选)硕士
• 1哨兵

主持人2:

• 奴隶
• 1哨兵

确实,在这种情况下,您可以让主机一次失败,从而为您提供一定程度的安全性.试着了解不同的服务器是否意味着物理上不同的主机.如果这些只是同一主机上的VM,则不会获得相同级别的DR(灾难恢复).

关于你的问题:

我宁愿让哨兵与主/从服务器在同一服务器上以减少延迟.

请注意,Sentinels会跟踪当前的主站和从站,但是Redis客户端没有连接到Master VIA Sentinels,它们只是通过Sentinels获取当前主站的位置,例如,在读取和写入方面你不是调查任何可观的*延迟增益.

配置提供商.Sentinel充当客户端服务发现的权限来源:客户端连接到Sentinels,以便询问负责给定服务的当前Redis主服务器的地址.如果发生故障转移,Sentinels将报告新地址.

(见:http://redis.io/topics/sentinel)

我看到它在延迟方面唯一获得的收益是从主站和从站发送到哨兵的心跳.只要你没有在全世界传播你的服务器应该没问题.

这一切都取决于用例,但如果所有其他条件相同(成本,与客户的距离等),您似乎最好尽可能保持独立.