6

我在托管网站的 Windows Azure (Iaas) 上有许多虚拟机。有许多负载平衡的前端虚拟机，都使用 SQL Express 连接到单个虚拟机。它运作良好。

然而！

我在所有虚拟机上随机重启。至于前端虚拟机（带有 IIS），由于它们是负载平衡的，因此站点不受影响，负载平衡器会相应调整。但是，当托管数据库的 VM 重新启动时，站点会关闭，直到数据库再次启动。启动需要 < 3 分钟，但如果它发生得足够频繁，这仍然是不可接受的。尽管重新启动相对较少（每个 VM 每月 2 次），但有时我们会在一周内每个 VM 重新启动 4 次，这令人沮丧地烦人。并非所有虚拟机都频繁重启，我无法找出模式。重启也是意外的（拉电源线类型的重启，而不是关机）。数据中心位于西欧。

Microsoft 强调 SLA 仅涵盖可用性集中的 2 个 VM，而对于数据库 VM，我不能拥有这些 VM（而且企业 SQL 版本需要一个手臂和三个腿）。此外，SQL Azure 不是一个选项，因为该应用程序非常健谈，并且 SQL Azure 数据库在高峰时间受到限制（尽管它在中型 VM 上与 SQL Express 一起运行非常流畅！）。

我的问题：有这么多重启是正常的吗？还有其他人有同样的问题吗？您对 Azure 上的这种环境有何体验？我可以做些什么来最大程度地减少停机时间？

谢谢大家！

4

2 回答 2

3

重启这么多正常吗？

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

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

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

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

见证人的高可用性是在 VM 中为您提供可用性的唯一方法，是的，它成本高昂。

其他严肃的选择。缓存 缓存 ..您应该使用计算机缓存、天蓝色缓存并尽量减少对数据库的调用。这可能会减少您的繁琐应用程序并允许您退回 SQL Azure，但可能会给您足够的时间让故障转移恢复。

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

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

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

HTHS 给你一些想法。

于 2013-05-09T09:59:19.280 回答
1

自 4 月 16 日以来，Windows Azure 基础设施服务 (IaaS) 仅在大约 3 周后才推出通用可用性（GA，或生产）（请参阅此处的公告）。在 GA 之前，没有 SLA，您会看到更频繁的操作系统重启，因为各种补丁仍在应用于主机操作系统。你是说这种模式自 4 月 16 日以来一直以同样的速度持续下去？

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

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

如果您已排除应用程序错误并确定 VM 在重新启动时运行状况良好，您可能需要向 Microsoft 开具支持票以帮助进一步诊断问题。

于 2013-05-09T11:01:03.573 回答