Azure Web Apps 架构是什么样的? [英] What does the Azure Web Apps architecture look like?

问题描述

我遇到过几次 10 到 15 分钟的中断，因为显然 Microsoft 的存储出现了昙花一现".他们告诉我这是因为实例之间共享文件系统(使其成为单点故障?)

I've had a few outages of 10 to 15 minutes, because apparently Microsoft had a 'blip' on their storages. They told me that it is because of a shared file system between the instances (making it a single point of failure?)

我不明白它并询问文件共享如何涉及，因为我假设一个非常愚蠢的无状态 IIS 应用程序与 SQL Azure 通信以获取其数据.

I didn't understand it and asked how file share is involved, because I would assume a really dumb stateless IIS app that communicates with SQL Azure for its data.

我会假设以下情况:

这是他们对我问题的回答(我没有附上图纸)

This is their reply to my question (I didn't include the drawing)

文件共享不一定要让您的网络应用程序与之通信另一个资源，但它们在我们的应用程序内容中驻留在.这就是我们提出有关存储的建议时的意思在我们的文件服务器上不可用.重启的原因为两个实例上的应用程序触发是因为资源是共享的，底层存储将是相同的两个实例.这就是如果它下降到一个的原因，其他人最终也会跟进.如果你真的想要该应用程序的可用性有待提高，您可以随时使用流量经理.但是，即使使用流量管理器，也不能保证到位，应用程序不会停机，但会提高整体可用性你的应用程序.此外，我们最近推出了生产更新理想情况下应该处理由存储光点引起的重启，但是要启动此功能，您需要确保有在这种情况下需要有足够的内存可用功能需要启动.我们有几个选项可供您选择设置以避免应用程序的任何意外重启，因为我们这边的一个存储点:

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.

由于时差，沟通需要很长时间.谁能告诉我我的想法出了什么问题?

Because of the time differences the communication takes ages. Can anyone tell me what is wrong in my thinking?

我唯一想到的是，当您启用两个实例时，它们会在同一台物理服务器上运行.但这对我来说真的没什么意义.

The only thing that I think of is that when you've enabled two instances, they run on the same physical server. But that makes really little sense to me.

我有两个实例一个核心，1.75 GB 内存.

推荐答案

我对应用服务计划的假设是它们会自动拆分为可用性集(请参阅下面的简要说明)主要基于 Web 应用程序 销售说明

My presumption for App Service Plans was that they were automatically split into availability sets (see below for a brief description) Largely based on Web Apps sales spiel which states

应用服务在全球数据中心基础架构上提供可用性和自动扩展.轻松按需扩展或缩减应用程序，并在不同地理区域内和跨地理区域获得高可用性.

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 本身被分成可用性集.但是，所有实例都使用相同的文件服务器来共享底层磁盘空间.该文件服务器是一个重要的单点故障.

Following on from David Ebbo's answer and comments, the underlying architecture of Web apps appears to be that the VM's themselves are separated into availability sets. However all of the instances use the same fileserver to share the underlying disk space. This file server being a significant single point of failure.

为了缓解这种情况，Azure 创建了 WEBSITE_LOCAL_CACHE_OPTION，它将文件服务器的内容缓存到各个 Web 应用程序实例上.使用缓存代替可靠的高可用性工程原则.

To mitigate this Azure have created the WEBSITE_LOCAL_CACHE_OPTION which will cache the contents of the file server onto the individual Web App instances. Using caching in lieu of solid, high availability engineering principles.

这里的问题是，作为客户，我们对这个问题一无所知，我们不知道是否有修复它的计划，或者是否或何时修复它，因为 Azure 似乎不太可能发布一份文件，承认它的设计有多糟糕，即使它是固定的.

The problem here is that as a customer we have no visibility into this issue, we've no idea if there is a plan to fix it, or if or when it will ever be fixed since it seems unlikely that Azure is going to issue a document that admits to how badly this has been engineered, even if it is to say that it is fixed.

我也无法想象这个问题在 ASM 和 ARM 之间会有什么不同.当 ARM 出现时，他们在后端放弃了最初的高可用性解决方案，这似乎非常不可能.因此，云服务很可能会遇到完全相同的问题.

I also can't imagine that this issue would be any different between ASM and ARM. It seems exceptionally unlikely that there was originally a high availability solution at the backend that they scrapped when ARM came along. So it is very likely that cloud services would suffer the exact same issue.

一个小的好处是，现在我们知道这是一个问题，一个可能的解决方案是部署多个网络应用程序并在它们之间设置一个流量管理器.即使它们在同一地区，不同的应用应该有不同的后端文件服务器.

The small upside is that now that we know this is an issue, one possible solution would be to deploy multiple web apps and have a traffic manager between them. Even if they are in the same region, different apps should have different backend file servers.

我的第一个动作是回复那封电子邮件，并附上指向 Web Apps 页面的链接(以及这个问题)，并附上引用的副本，并询问如何在内启用高可用性地理区域.

My first action would be to reply to that email, with a link to the Web Apps page, (and this question) with a copy of the quote and ask how to enable high availability within a geographic region.

在那之后，您可能需要重新构建您的解决方案！

After that you'll likely need to rearchitect your solution!

可用性集

对于虚拟机，Azure 会让你指定一个 可用性集.可用性集将自动将 VM 拆分为单独的更新域和故障域.这意味着服务器最终将位于不同的服务器机架中，并且这些服务器机架不会同时获得更新.(它比那更复杂一点，但这是基础！)

For virtual machines Azure will let you specify an availability set. An availability set will automatically split VMs into separate update and fault domains. Meaning that servers will end up in different server racks, and those server racks won't get updates at the same time. (it is a little more complex than that, but that's the basics!)

这篇关于Azure Web Apps 架构是什么样的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！