我们有4个应用程序服务器和一个运行我们的Python应用程序的负载平衡。 每个应用程序服务器都有32个超线程核心，因此Tornado部署指南build议我们每个运行64个线程。 我们也使用supervisord来pipe理所有的线程。 这工作正常，我们遇到的问题是，当我们必须部署更新，目前部署新应用程序的过程是一个shell脚本，它执行以下操作;
这是非常低效的，总共需要大约20秒。 重启单独的龙卷风线程需要一秒左右的时间，但问题是，如果我们做出任何重大更改，负载平衡器将根据重新启动的哪个阶段，它select的线程在旧的和新的应用程序之间切换（总共有256个负载平衡器可以连接到的可能的实例），所以我们必须把站点closures30秒，有时更长，以获得正确版本的应用程序。
有没有更好的方法呢？ 我听说过Fabric和其他一些可以使用的工具，但是它们比我们现在做的更有效吗？ 理想情况下，我们需要在5秒钟之内将所有线程重新启动到新版本，即使涉及临时占用站点。
信息（如果它是有用的）;
所有的服务器都是RHEL 5.5，负载均衡器是Barracuda 640。
如果您可以在您的部署脚本中使用负载平衡器的API ，那么以下顺序应该做你想做的事情：
这样，只有一个版本的代码在任何时候都处于活动状态，并且在池更改生效时，停机时间应该限制在一秒或两秒钟。
免责声明：这假设梭子鱼负载平衡器有一个体面的API。 我无法用Google快速find文档。 该模式应该工作。 我在与思科负载平衡器类似的情况下完成了它。
为什么不这样做
在2个块中进行部署。连接到2个节点会closuresWeb服务器。 负载平衡器将停止在那里发送stream量。部署应用程序。 调出Web服务器，同时closures其他2 ..部署应用程序..启动服务器。
该方法并不能很好地扩展。
选项2
你的LB做粘性会议吗？ 如果是这样，请在部署前一小时打开它们。 一次抽出1台服务器进行部署。 当某些用户看到新网站时，其他用户会看到旧网站。
所以你一次做一个..然后从LB删除粘性会话。