Windows Azure VM(Iaas)意外重启

Question

我在Windows Azure(Iaas)上有许多托管网站的虚拟机.有许多负载均衡的前端VM,都通过SQL Express连接到单个VM.它运作良好.

然而!

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

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

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

谢谢大家!

Answer 1

这么多次重启正常吗？

是的，这可能会在给定的月份发生，您需要在高可用性模式下启动 SQL Server 才能真正发挥作用。

是的，它确实花费了一条胳膊和一条腿。;(

您对 Azure 上的此类环境有何体验？有些月份确实很好，有些月份很糟糕，这取决于您的集群以及您所在的数据中心。微软在数据中心混合了我们的硬件。这并不意味着它们在某些数据中心的旧笔记本电脑上运行，但这确实意味着根据我的经验，新数据中心往往拥有更好的套件，因此重新启动的次数更少。即我们使用美国东部。

我可以做什么来最大限度地减少停机时间？

具有见证人的高可用性是在虚拟机中提供可用性的唯一方法，是的，它的成本很高。

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

队列 队列将帮助您的应用程序恢复并向您的用户传达我们正在处理该问题的消息。

使用 SQL Azure 作为故障转移。使用 SQL Azure Sync 从 Premise（不确定这是否适用于 Express）将数据同步到 SQL Azure，并写入您的应用程序代码以检测连接错误和故障转移。

考虑将 Azure 的其他部分用于应用程序的某些部分，以减少进入 SQL 的调用量，即可以将内容移至表存储吗？

HTHS 给你一些想法。