网站升级 – 避免停机

我被要求调查如何减less我们网站升级的停机时间。

我们维护DNN网站,既有面向公众的页面,也有仅有会员的页面。 只有成员页面直接链接到我们的核心应用程序数据库,而公共页面则不是。

我们目前的stream程是在升级过程开始后立即redirect网站用户,其中包括

  • Prod DB的备份
  • 更新Prod数据库
  • 更新可执行文件(应用程序)
  • 升级网站应用程序(如果需要更新)
  • 安装依赖关系
  • 升级通信引擎和支付代理等子系统
  • 更新各种configuration文件
  • 执行系统testing
  • 重新启动所有服务
  • 允许访问网站

此过程可能需要2到8小时,具体取决于所需的升级,要运行的脚本,数据库大小和数量或门户。

我最初的想法是限制用户只读页面,任何更新页面将不可用。

任何人都可以提供一些关于我认为是一个常见问题的最佳实践方面的build议,这样我们可以减less这个停机时间,如果我们需要改变基础设施,我可以把这个提交给我们的技术部门。

你是否练习敏捷的部署方法? 我的第一个build议是测量什么部分的部署需要超过预期的时间,并优化它。 尝试从代码部署计划中分离数据库部署。

由于您每晚备份您的数据库(正确?),如果必须的话,不应该有太多的数据回滚。 不是一个数据库专家,但我相信你可以简单地更新数据库模式,它需要用脚本更新,而不需要太多的时间。

您可以通过脚本轻松地将dll和资源部署到站点,而无需中断现有会话。

在部署到生产之前,您应该在登台服务器上执行大部分testing。 所以,一旦你部署了,你不需要在生产上做太多的testing。

我鼓励你看看持续集成或持续部署( http://continuousdelivery.com/ )。

我会build议:

a)设定网站RO

b)做数据库备份//应该很快。 如果不是的话,可以使用redgate或其他的东西来加快速度

c)数据库更新://应该很快。 如果不是这样,那么你的更改太频繁了。

d)代码应该全部在分段上进行预testing。 你应该能够把这个网站带上去,然后在网站正式运行的时候进行testing(因为你对testing的信心非常高)

我们有一个非常大的.net应用程序,在一个500GB的SQL服务器数据库的顶部,我们的步骤是一样的,但我们只有几分钟的停机时间进行升级(我们每周做几次)。