Azure Web Apps架构如何？

Question

我有几次中断10到15分钟,因为显然微软对他们的存储有一个"昙花一现".他们告诉我,这是因为实例之间存在共享文件系统(使其成为单点故障？)

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

我会假设下面的情况:

这是他们回答我的问题(我没有包括图纸)

文件共享不一定是您的Web应用程序与其他资源进行通信,但它们位于应用程序内容所在的最终位置.当我们建议在我们的文件服务器上存储不可用时,这就是我们的意思.在两个实例上为您的应用程序触发重新启动的原因是因为资源是共享的,两个实例的底层存储将是相同的.这就是为什么如果它落在一个,另一个也将最终跟随的原因.如果您确实希望改进应用程序的可用性,则可以始终使用流量管理器.但是,即使有流量管理器,也无法保证该应用不会降低,但会提高应用的整体可用性.此外,我们最近推出了一个生产更新,它应该照顾理想的存储blip引起的重启,但是要启动这个功能,你需要确保在需要的情况下需要有足够的内存.这个功能需要启动.我们有几个你可以设置的选项,以避免由于我们端的存储空白导致应用程序意外重启:

• 您可以评估是否要移动到更大的实例,以便我们可以有足够的内存来启动重叠回收功能.

• 如果您不想迁移到更大的实例,则可以始终使用我们之前的电子邮件中概述的本地缓存功能.

由于时间差异,沟通需要很长时间.谁能告诉我我的想法有什么问题？

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

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

Answer 1

我对应用服务计划的假设是它们被自动拆分为可用性集(参见下面的简要说明)主要基于Web Apps销售高手,其中指出

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

继David Ebbo的回答和评论之后,Web应用程序的基础架构似乎是VM本身被分成可用性集.但是,所有实例都使用相同的文件服务器来共享底层磁盘空间.此文件服务器是一个重要的单点故障.

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

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

我也无法想象ASM和ARM之间的这个问题会有什么不同.看起来极不可能的是,后端最初有一个高可用性解决方案,当ARM出现时它们就会报废.因此,云服务很可能会遇到完全相同的问题.

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

我的第一个行动是回复该电子邮件,其中包含指向Web Apps页面的链接(和此问题)以及报价副本,并询问如何在地理区域内启用高可用性.

之后,您可能需要重新构建解决方案!

可用性集

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

Answer 2

Azure Web Apps确实使用了共享文件存储。最好的思考方式是将应用程序的所有实例映射到包含您的文件的同一网络共享。因此，如果您通过任何方式修改文件（例如 FTP、msdeploy、git...），所有实例都会立即获取新文件（因为只有一组文件）。

为了回答您的最后一个问题，每个实例都在单独的虚拟机上运行。