Windows Azure VM（Iaas）意外重启

Question

我在Windows Azure（Iaas）托管网站时有许多虚拟机。有许多负载均衡的前端VM，都通过SQL Express连接到单个VM。效果很好。

然而！

我在所有VM上进行随机重启。对于前端VM（使用IIS），由于它们是负载平衡的，因此站点不受影响，负载均衡器也会相应调整。但是当重新启动托管数据库的VM时，该站点将关闭，直到DB再次启动。它需要＆lt;启动3分钟，但如果频繁发生，这仍然是不可接受的。虽然重启是相对罕见的（每个虚拟机每月2个），但有时我们会得到一个星期，每个虚拟机重启4次，这令人沮丧。并非所有虚拟机都经常重启，我无法弄清楚模式。重启也是意外的（拉动电源线类型的重启，而不是停机）。数据中心是西欧。

Microsoft强调SLA仅涵盖可用性集中的2VM，而我不能将其用于数据库VM（企业SQL版本需要花费三条腿）。此外，SQL Azure不是一个选项，因为应用程序非常繁琐，并且SQL Azure数据库在高峰时段受到限制（尽管它在中型VM上使用SQL Express非常流畅！）。

我的问题： 有这么多重启是否正常？还有其他人有同样的问题吗？您在Azure上使用此类环境的体验如何？我该怎么做才能减少停机时间？

全部谢谢！

Answer 1

重启次数是否正常？

是的，这可能发生在给定的月份，您需要在高可用性模式下站起来SQL Server才能真正实现这一点。

是的，这确实耗费了手臂和腿。 ;（

您在Azure上使用此类环境的体验如何？ 几个月真的很好几个月都很糟糕，取决于你的集群和你所在的数据中心.MS在那里的数据中心混合了我们的硬件。这并不意味着它们在某些数据中心的旧笔记本电脑上运行，但它确实意味着我的经验中新的数据中心往往有更好的套件，因此重启次数更少。我们使用美国东部。

我可以做些什么来减少停机时间？

凭借见证人的高可用性是在VM中为您提供可用性的唯一方式，是成本和手臂和腿。

其他严肃的选择。缓存缓存..您应该使用计算机缓存，天蓝色缓存并尝试最小化您对数据库的调用。这可能会减少您的聊天应用程序并允许您退回SQL Azure，但可能会为您提供足够的故障转移以恢复。

队列队列可以帮助您恢复应用程序，并为用户提供我们正在处理它的消息。

使用SQL Azure作为故障转移。使用来自Premise的SQL Azure Sync进行数据同步（不确定这适用于Express）到SQL Azure并写入应用程序代码以获取连接错误和故障转移。

使用Azure的其他部分来查看部分应用程序，以减少进入SQL的调用量，即可以将内容移动到表存储中吗？

HTHS给你一些想法。

Answer 2

自4月16日起，Windows Azure基础结构服务（IaaS）仅在3周内处于一般可用性（GA或生产）中（参见公告here）。在GA之前，没有SLA，您会看到更频繁的操作系统重启，因为各种补丁仍然应用于主机操作系统。你是说这种模式从4月16日开始以同样的速度继续下去吗？

现在IaaS是GA，我不希望在一周内重启4次。这就是说：有几个原因你会看到重启：

• 主机硬件故障（这会关闭在该主机上运行的所有客户操作系统）
• 主机软件更新（仅在需要重新启动主机操作系统时）。 主机操作系统重新启动不应该以您看到的频率发生。
• 来宾操作系统问题。这就是PaaS（Web /工作者角色云服务）背离的地方。在IaaS中，Azure没有进行客户操作系统维护;这一切都掌握在你手中。如果自动安装Windows更新，则可以重新启动。可能您可能遇到应用程序级别的问题，导致该框在很长一段时间内无响应，导致Azure结构控制器重新启动您的框，因为它认为它不健康。并且...你的应用程序可能以某种方式崩溃了。

如果您排除了应用程序错误，并确保虚拟机在重新启动时运行状况良好，则可能需要与Microsoft一起打开支持服务单，以帮助进一步诊断问题。