切换BackendAddressPools时停机时间短 [英] Short downtime when switching BackendAddressPools

问题描述

我有一个ApplicationGateway，其中一个规则连接到了BackendAddressPool#1.当我修改此规则以使用BackendAddressPool#2时，我注意到停机时间很短.

我该如何在零停机时间内实现?甚至有可能吗?

这是一个测试，以循环方式对端点进行采样.您可以在发生切换时看到停机时间.

2018-12-03 14:54:00.765262:服务器1
2018-12-03 14:54:00.846175:服务器1
2018-12-03 14:54:00.936428:服务器1
2018-12-03 14:54:01.018184:服务器1
2018-12-03 14:54:01.036002:('连接被中止.'，RemoteDisconnected('远端封闭的连接无响应'，))
2018-12-03 14:54:01.176808:服务器2
2018-12-03 14:54:01.253491:服务器2
2018-12-03 14:54:01.328864:服务器2
2018-12-03 14:54:01.404836:服务器2

解决方案

不幸的是，切换池时不可避免地会导致一些停机.

根据您的日志，停机时间少于0.16秒(即160ms)，这非常快.在流量减少时切换池可以帮助避免客户出错. 

Hi,

I have an ApplicationGateway with one rule connected to a BackendAddressPool#1. When I modify this rule to use BackendAddressPool#2, I notice a short downtime. 

How can I do this with zero downtime? Is it even possible?

Here is a test, sampling the endpoint in a loop. You can see the downtime when the switch is happening.

2018-12-03 14:54:00.765262: Server 1
2018-12-03 14:54:00.846175: Server 1
2018-12-03 14:54:00.936428: Server 1
2018-12-03 14:54:01.018184: Server 1
2018-12-03 14:54:01.036002: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
2018-12-03 14:54:01.176808: Server 2
2018-12-03 14:54:01.253491: Server 2
2018-12-03 14:54:01.328864: Server 2
2018-12-03 14:54:01.404836: Server 2

解决方案

Unfortunately some downtime is unavoidable when switching pools. 

According to your logs, the downtime is less than 0.16 seconds, or 160ms, which is pretty fast. switching pools during low traffic times can help avoid customers getting an error. 

这篇关于切换BackendAddressPools时停机时间短的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！