我们有 4 个应用服务器和一个运行 Python 应用程序的负载平衡器。每个应用服务器都有 32 个超线程核心,因此 Tornado 部署指南建议我们在每个服务器上运行 64 个线程。我们还使用 Supervisord 来管理所有线程。这很好用,我们遇到的问题是当我们必须部署更新时,部署新应用程序的当前流程是一个 shell 脚本,它执行以下操作;
- 检出我们的 GIT 仓库的 /deploy 分支
- (一些与 CDN 无关的内容)
- 将文件通过 SCP 传输到 4 台服务器中
- 重新启动supervisord(以便应用程序加载新代码)
这非常低效,总共需要大约 20 秒。重新启动单个 Tornado 线程大约需要一秒钟,但问题是,如果我们进行任何重大更改,负载平衡器将根据其选择的线程的重新启动阶段在旧应用程序和新应用程序之间切换(负载平衡器总共可以连接到 256 个可能的实例),因此我们必须关闭网站 30 秒,有时甚至更长时间,才能获得应用程序的正确版本。
有没有更好的方法?我听说过 Fabric 和其他一些可以使用的工具,但它们比我们目前的方法更有效吗?理想情况下,我们需要在 5 秒内将所有线程重新启动到新版本,即使这需要暂时关闭网站。
信息(如果它有用的话);
所有服务器都是 RHEL 5.5,负载平衡器是 Barracuda 640。
答案1
如果你可以使用以下序列,那么你应该可以实现你想要的功能负载均衡器的 API在您的部署脚本中:
- 从负载均衡器中删除部分线程
- 升级这些线程
- 从负载均衡器中删除活动线程
- 将升级后的线程重新添加到负载均衡器中
- 升级剩余线程
- 将剩余线程重新添加到负载均衡器中
这样,您在任何时刻都只有一个版本的代码有效,并且当池更改生效时,停机时间应该限制在一两秒内。
免责声明: 这假设 Barracuda 负载均衡器具有不错的 API。我使用 Google 快速搜索找不到文档。该模式应该可行。我曾在类似情况下使用 Cisco 负载均衡器完成此操作。
答案2
为什么不这样做呢?
以 2 个部分进行部署。您连接到 2 个节点,关闭 Web 服务器。负载平衡器将停止向那里发送流量。部署应用程序。启动 Web 服务器,同时关闭其他 2 个服务器。部署应用程序。启动服务器。
这种方法的扩展性确实不强。
选项 2
您的 LB 是否执行粘性会话?如果是,请在部署前一小时启用它们。每次关闭一台服务器以进行部署。当服务器启动时,某些用户将看到新站点,而其他用户将看到旧站点。
因此,您一次只执行一项操作,然后从 LB 中删除粘性会话。