最大限度地减少Azure中的停机时间

Question

我们今天的Azure应用程序正在经历非常严重的计划外停机，目前正在进行长达9小时的停机。我们向Azure支持报告，操作团队正在积极尝试解决问题，我不怀疑。我们设法让我们的应用程序在我们拥有的另一个“测试”托管服务上运行，并将我们的CNAME重定向到指向该实例，以便我们的客户满意，但“主要”托管服务仍然不可用。

我自己的“空中手指”本能是这个问题与我们的数据中心（西欧）之间的网络相关，事实上，当天晚些时候服务仪表板已经变红，该地区的消息是那种效果。 （我们的应用程序在门户网站中显示为“健康”，但是无法通过我们的cloudapp.net URL访问。此外，我们的应用程序中的线程正在将sql连接异常记录到我们的存储帐户中，因为它无法联系到数据库）

但有一点很奇怪的是，我上面提到的“测试”实例也在同一个数据中心，没有问题联系数据库，它的外部端点是完全可用的。

我想问一下社区是否有什么可以做得更好以避免这种停机时间？我遵守了关于每个角色至少有2个角色实例的指导，但我仍然被烧毁了。我应该转向更可靠的数据中心吗？我应该将应用程序部署到多个数据中心吗？我如何管理我的SQL-Azure数据库位于同一数据中心的事实？

任何建设性的指导都会受到赞赏 - 作为一名技术人员，我从来没有一个更令人沮丧的日子能够没有来帮助解决问题。

Answer 1

今天欧洲数据中心就SQL Azure发生了中断。我们的一些客户受到了打击，不得不搬到另一个数据中心。

如果您正在运行无法关闭的关键任务应用程序，我会将应用程序部署到多个区域。 DNS解析显然是目前在Azure中的一个薄弱环节，但可以解决（如果你只运行一个网站，它可以非常简单地使用Response.Redirects或类似的方式完成）

现在，Microsoft提供了一个数据同步服务，可以同步多个SQL Azure数据库。检查here。这样，您可以在不同区域中启动镜像站点，并使它们与SQL Azure透视图同步

此外，最好采用第三方监控服务，以便在外部检测部署的实例出现问题。如果您选择，AzureWatch可以通知甚至部署新节点，当某些实例变为“无响应”时

希望这有帮助

Answer 2

我可以根据我们的经验提供一些指导：

1. 将您的应用程序托管在多个数据中心，并配有Sql Azure数据库。您可以将每个应用程序连接到其数据中心特定的Sql Server。您还可以在数据中心特定的Windows Azure计算机上缓存任何外部资产（images / JS / CSS）或利用Azure博客存储。注意：将产生额外费用。
2. 在主Sql Azure DB与其他数据中心中的实例之间设置单向SQL复制。如果要进行双向复制，请查看MSDN站点以获取指导。
3. 利用Azure Traffic Manager将流量路由到最靠近用户的数据中心。它具有地理检测功能，还可以改善应用程序的延迟。因此，您可以将地图http://myapp.com重定向到数据中心的内部网址，并且欧洲的用户应自动重定向到欧洲数据中心，反之亦然。注意：在撰写本文时，无法自动检测和故障转移到数据中心。一旦检测到故障转移并且故障转移是完整集（即，您将故障转移Windows Azure和Sql Azure实例），将涉及手动步骤。如果您需要微级故障转移，那么我建议将所有配置放在服务配置文件中并加密值，以便您可以编辑连接字符串以将实例X连接到DB Y.
4. 你们现在都定了。我会创建或安装本地应用程序来检测站点的可用性。更好的解决方案是创建一个页面，通过编写诊断页面或Web服务来检查应用程序特定组件的可用性，然后从本地计算机进行轮询。

HTH

Answer 3

在部署到Azure时，您无法控制SQL Server的设置方式。 MS已经将其设置为高可用性。

话虽如此，MS似乎在过去几天里遇到了一些SQL Azure问题。我们被告知它只影响"a small number of users"。有一次，service dashboard有5个数据中心受到问题的影响。我在其中一个数据中心中有3个数据库每次下载两次大约一个小时，但另一个受影响的数据中心中的一个数据库没有中断。

如果数据库连接对您的应用程序至关重要，那么Azure环境中唯一可以确保不会遇到MS未准备好的问题的方法（这个最新的技术问题，地震，流星撞击）将是共同定位你的SQL数据在另一个数据中心。目前，最实际的方法是使用synch framework。能够copy SQL Azure databases，但这仅适用于数据中心。如果您的数据位于其他位置，则可以将应用指向新数据库（如果主数据库不可用）。

虽然这在纸面上看起来不错，但这可能无法帮助您解决最新问题，因为它影响了多个数据中心。如果您只是定期制作数据库副本，那么这可能足以让您完成。或者不是。

（我会在服务器故障上发布此答案，但我找不到问题）

Answer 4

这只是一个编程/架构问题，但你也想在webmasters.stackexchange.com上提出问题

在得出任何结论之前，你需要找出根本原因。

然而。我猜两件事之一就是问题

• ISP连接因测试系统和生产系统而异。他们要么使用不同的ISP，要么使用同一ISP的不同线路。当我在一家托管公司工作时，我们确保IP连接通过至少两个不同的ISPS，他们没有共享光纤到我们的场所（我们可以，他们有不同的物理路线到建筑物 - 反铲的归巢能力时有一个关键的纤维可以用来挖掘已经过充分证明

• 您的数据中心存在一些共享生产基础架构的问题。这些通常可能是边缘路由器，防火墙，负载平衡器，入侵检测系统，流量整形器等。这些通常也只安装在生产系统上。这里的防御涉及了解架构并确保提供商有一个（经过测试的！）灾难恢复计划，以便在事情成对时恢复某些服务。我在这里看到的最好的黑客是说服IPS（入侵防御系统），它自己的管理服务器是恶意的。所以你根本无法重新配置它。

只是一个想法 - 您的DC不会托管任何维基解密镜像，或Paypal /万事达卡/亚马逊（目前由维基解密支持者获得DDOS）？