我们使用WAWS和WA SQL Azure。今天早上，北欧数据中心中断了1小时50分钟。基本上我们无法访问我们的网站或数据库。现在回来了，虽然仍然轰动一时。
我不得不承认我感到有些无助。
我感觉原因与网络有关。可能是负载均衡器？
那么，当这种情况发生时我们能做什么，因为通常MS工程师都知道这些＆＃34;事件＆＃34;很快就会采取行动。
我的一些想法是：
1）如果域超时，请放置一个礼貌的错误页面。不知道该怎么做。在诸如pingdom之类的自动服务上或在定义CNames的域服务上。我们重新路由到Azure。此通信是向客户保证正在对问题进行排序以及防止出现空白Azure 503页面的关键。
2）来自Azure团队的更好信息，当服务恢复时，减少信任行为。
3）当这个＆＃34;事件＆＃34;发生的情况。
我确信这会影响其他Azure客户，甚至其他云客户。我怀疑有些是北欧用户，今天早上像我一样受到影响。那么您采取了哪些措施来管理这个问题，特别是在自动出现的客户通知网页周围。
EDIT1
从MS更新。
++++++++++++++++++++++++++++++++++++++++++++
SQL数据库 - 北欧 - 部分性能下降
49分钟前
从8/6/2014 6:56 UTC开始，SQL客户的一部分可能在访问其资源时遇到困难。这些SQL客户中有相当多的人已经看到了改进。我们已经确定了潜在的根本原因，并正在努力恢复服务。下一次更新将在两小时内提供。
+++++++++++++++++++++++++++++++++++++++++++++
部分性能下降=没有网站，没有我们的数据库！
答案 0 :(得分：4)
我仍然遭受SQL Azure中断。
任何外部资源都无法连接到SQL Azure服务，但我们帐户上的内部资源（例如WorkerRoles，WCFRoles等）不受影响。
我不知道解决方案是什么;这取决于你的解决方案。我还在Azure上托管了几个Wordpress自托管网站，有些网站受到影响，有些则不受影响。受影响的将不会加载并显示HTTP 502错误。
我所能建议的是为Azure上托管的网站提供的自定义HTTP 502页面，可以优雅地捕获和处理任何通信级别的异常（例如.NET的System.Data.SqlClient.SqlException）。在远程访问SQL Azure数据库的混合应用程序中。 耸肩
答案 1 :(得分：3)
这不是一个好的情况，我也总是担心。有一个解决方案，但它不是特别便宜，但我想这是你支付的正常运行时间。
a）确保将Traffic Manager与故障转移网站一起用于完全不同的区域。例如，如果您的主要网站是北欧，那么在西欧拥有另一个网站。两个数据中心的可能性都很低。您可以根据预算添加更多故障转移。
b）对于您的数据库，您需要启用地理复制。如果您使用的是Premium，那么您可以将其设置为只读的在线数据库。故障转移网站应指向此数据库。这意味着您的网站在中断期间是只读的，但至少您没有死。如果需要，您可以将此故障转移数据库作为主要数据库，因此它不再是只读的。如果您只有标准数据库，就像我们大多数贫困人士一样，它的工作方式类似，但备份数据库是“离线”的。不确定这意味着什么，但我认为这意味着你必须等待MS确定什么时候有足够的东西让你连接到辅助数据库而不是一直打开它。
一些信息：http://azure.microsoft.com/blog/2014/07/12/spotlight-on-sql-database-active-geo-replication/