我们今天的Azure应用程序正在经历非常严重的计划外停机,目前为期9小时.我们向Azure支持报告,操作团队正在积极尝试解决问题,我不怀疑.我们设法让我们的应用程序在我们拥有的另一个"测试"托管服务上运行,并重定向我们的CNAME指向实例,以便我们的客户满意,但"主要"托管服务仍然不可用.
我自己的"空中手指"本能是这个问题在我们的数据中心(西欧)中与网络相关,事实上,在服务仪表板为该区域发出红色的那一天晚些时候发出了相应的消息.(我们的应用程序在门户网站中显示为"健康",但是无法通过我们的cloudapp.net URL访问.此外,我们的应用程序中的线程将sql连接异常记录到我们的存储帐户中,因为它无法联系数据库)
但是,非常奇怪的是,我上面提到的"测试"实例也在同一个数据中心,并且没有问题联系数据库,它的外部端点是完全可用的.
我想问一下社区是否有什么我可以做得更好以避免这种停机时间？我遵守了关于每个角色至少有2个角色实例的指导,但我仍然被烧毁了.我应该转向更可靠的数据中心吗？我应该将应用程序部署到多个数据中心吗？我如何管理我的SQL-Azure数据库位于同一数据中心的事实？
任何建设性的指导都会受到赞赏 - 作为一名技术人员,我从来没有一个更令人沮丧的日子能够无所事事来帮助解决问题.
今天欧洲数据中心在SQL Azure方面出现了中断.我们的一些客户受到了打击,不得不搬到另一个数据中心.
如果您正在运行无法关闭的关键任务应用程序,我会将应用程序部署到多个区域.DNS解析显然是目前在Azure中的一个弱链接,但可以解决(如果你只运行一个网站,它可以非常简单地使用Response.Redirects或类似)
现在,Microsoft提供了一个数据同步服务,可以同步多个SQL Azure数据库.请点击这里.这样,您可以在不同区域中启动镜像站点,并使它们与SQL Azure透视图同步
此外,最好采用第三方监控服务,以便在外部检测部署的实例的问题. 如果您选择,AzureWatch可以通知甚至部署新节点,当某些实例变为"无响应"时
希望这可以帮助
| 归档时间： |
|
| 查看次数： |
2440 次 |
| 最近记录： |