我遇到过几次 10 到 15 分钟的中断，因为显然 Microsoft 的存储出现了“故障”。他们告诉我，这是因为实例之间共享文件系统(使其成为单点故障？)
我不明白它并询问如何涉及文件共享，因为我会假设一个非常愚蠢的无状态 IIS 应用程序与 SQL Azure 通信以获取其数据。
我会假设以下情况:
这是他们对我问题的答复(我没有附上图纸)
The file shares are not necessarily for your web app to communicate to another resources but they are on our end where the app content resides on. That is what we meant when we suggested that about storage being unavailable on our file servers. The reason the restarts would be triggered for your app that is on both the instances is because the resources are shared, the underlying storage would be the same for both the instances. That’s the reason if it goes down on one, the other would also follow eventually. If you really want the availability of the app to be improved, you can always use a traffic manager. However, there is no guarantee that even with traffic manager in place, the app doesn’t go down but it improves overall availability of your app. Also we have recently rolled out an update to production that should take care of restarts caused by storage blips ideally, but for this feature to be kicked it you need to make sure that there is ample amount of memory needs to be available in the cases where this feature needs to kick in. We have couple of options that you can have set up in order to avoid any unexpected restarts of the app because of a storage blip on our end:
You can evaluate if you want to move to a bigger instance so that we might have enough memory for the overlap recycling feature to be kicked in.
If you don’t want to move to a bigger instance, you can always use local cache feature as outlined by us in our earlier email.
由于时差，沟通需要很长时间。谁能告诉我我的想法有什么问题吗？
我唯一想到的是，当您启用两个实例时，它们将在同一台物理服务器上运行。但这对我来说真的没什么意义。
我有两个实例一个核心，1.75 GB 内存。
最佳答案
我对应用服务计划的假设是它们会自动分为可用性集(请参阅下面的简要说明)主要基于 Web Apps销售演讲指出
App Service provides availability and automatic scale on a global data centre infrastructure. Easily scale applications up or down on demand, and get high availability within and across different geographical regions.
根据 David Ebbo 的回答和评论，Web 应用程序的底层架构似乎是 VM 本身被分为可用性集。然而，所有实例都使用相同的文件服务器来共享底层磁盘空间。该文件服务器是一个重要的单点故障。
为了缓解这种情况，Azure 创建了 WEBSITE_LOCAL_CACHE_OPTION ，它将文件服务器的内容缓存到各个 Web 应用实例上。使用缓存代替可靠的高可用性工程原理。
这里的问题是，作为客户，我们无法了解这个问题，我们不知道是否有修复它的计划，或者是否或何时会修复它，因为 Azure 似乎不太可能会修复它发布一份文件，承认这个问题的设计有多糟糕，即使它已经得到修复。
我也无法想象这个问题在 ASM 和 ARM 之间会有什么不同。最初在后端有一个高可用性解决方案，当 ARM 出现时，他们就放弃了，这似乎是极不可能的。因此，云服务很可能会遇到完全相同的问题。
小的好处是，现在我们知道这是一个问题，一种可能的解决方案是部署多个 Web 应用程序并在它们之间设置流量管理器。即使它们位于同一区域，不同的应用也应该有不同的后端文件服务器。
我的第一个行动是回复该电子邮件，其中包含 Web 应用程序页面的链接(以及此问题)和报价副本，并询问如何在内实现高可用性。地理区域。
之后您可能需要重新构建您的解决方案!
可用性集
对于虚拟机，Azure 将允许您指定 availability set 。可用性集会自动将虚拟机拆分为单独的更新域和故障域。这意味着服务器最终将位于不同的服务器机架中，并且这些服务器机架不会同时获得更新。 (它比这更复杂一些，但这就是基础!)
关于azure - Azure Web Apps 架构是什么样的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35253899/