如何在Azure Web应用程序的架构是什么样子？ [英] How does the Azure Web Apps architecture look like?

问题描述

我已经有10到15分钟，几个中断，因为很明显微软对他们的货仓一个标志。他们告诉我，这是因为实例之间共享文件系统（使之成为单故障点？）

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 it's data.

我会假设下面的情况：

这是他们对我的答覆（我没有包括图）

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

该文件共享不一定是你的Web应用程序进行通信
  另一种资源，但他们对我们到底哪里应用内容
  驻留在。这就是我们的意思，当我们认为，关于存储
  成为我们的文件服务器上不可用。究其原因，将重新启动
  触发您的应用程序，是在两个实例是因为
  资源是共享的，底层存储将是相同的
  两个实例。这就是，如果它出现故障的之一，其原因
  另外也将遵循最终。如果你真的想要的
  应用程序可用性得到改善，可以随时使用交通
  经理。但是，没有保证，即使使用业务管理器
  到位，应用程序不下去，但它提高了整体可用性
  你的应用程序。此外，我们最近推出了一个更新的生产
  应该照顾由存储引起的光点重新启动的理想，但
  此功能被踢它，你需要确保有
  的内存中有足够量的需要是在例提供，其中本
  功能需要踢，我们有两个选择，你可以有
  成立以避免由于应用程序的任何意外重启
  我们最终的存储昙花一现：

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内存

推荐答案

Azure的Web应用程序都使用一个共享的文件存储。想一想，最好的办法是，您的应用程序映射到有你的文件的同一网络共享的所有实例。所以，如果你的任何修改均值的文件（例如FTP，msdeploy，git的，...），所有实例立即得到新的文件（因为只有一组文件）。

Azure Web Apps do used a shared file storage. The best way to think about it is that all the instances of your app map to the same network share that have your files. So if you modify the files by any mean (e.g. FTP, msdeploy, git, ...), all the instances instantly get the new files (since there is only one set of files).

和回答你的最后一个问题，每个实例并在一个单独的虚拟机上运行。

And to answer your final question, each instance does run on a separate VM.

这篇关于如何在Azure Web应用程序的架构是什么样子？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！