Azure Web Apps架构如何？

概述我有几次10到15分钟的中断,因为显然微软的存储空间有点“昙花一现”.他们告诉我,这是因为实例之间存在共享文件系统(使其成为单点故障？) 我不理解它,并询问文件共享是如何涉及的,因为我会假设一个非常愚蠢的无状态IIS应用程序,它与SQL Azure进行通信以获取数据. 我会假设下面的情况： 这是他们回答我的问题(我没有包括图纸) The file shares are not necessaril 我有几次10到15分钟的中断,因为显然微软的存储空间有点“昙花一现”.他们告诉我,这是因为实例之间存在共享文件系统(使其成为单点故障？)

我不理解它,并询问文件共享是如何涉及的,因为我会假设一个非常愚蠢的无状态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 App实例上.使用缓存代替可靠的高可用性工程原理.

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

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

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

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

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

可用性集

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

总结

以上是内存溢出为你收集整理的Azure Web Apps架构如何？全部内容，希望文章能够帮你解决Azure Web Apps架构如何？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。