在 EC2 与 Windows Azure 上部署项目
我已经使用 Windows Azure 和 Amazon Web Services EC2 好几个月了（几乎已经到了几年的范围），而且我一遍又一遍地看到一些看起来令人不安的事情。
当我将 .NET 版本部署到 Windows Azure 中的 Web 角色（或服务角色）中时，它通常需要 6-15 分钟才能启动。在 AWS 的 EC2 中，启动映像所需的时间大约相同，然后需要一两分钟将应用程序部署到 IIS（当然有待其设置）。
但是，当我使用 SUSE Linux 启动 AWS 实例时， Mono 来运行 .NET，我启动了其中之一，并在大约 2-3 分钟内将代码部署到其中（同样，等待设置）。
Windows 操作系统映像出了什么问题导致它们需要很长时间才能在云中启动？我不想 FUD，我很好奇导致这种情况的具体细节。任何有关此的具体技术信息将不胜感激！谢谢。
I've been working with Windows Azure and Amazon Web Services EC2 for a good many months now (almost getting to the years range) and I've seen something over and over that seems troubling.
When I deploy a .NET build into Windows Azure into a web role (or service role) it takes usually 6-15 minute for it to startup. In AWS's EC2 it takes about the same to startup the image and then a minute or two to deploy the app to IIS (pending of course its setup).
However when I boot up an AWS instance with SUSE Linux & Mono to run .NET, I get one of these booted and deploy code to it in about 2-3 minutes (again, pending it is setup).
What is going on with Windows OS images that cause them to take soooo long to boot up in the cloud? I don't want FUD, I'm curious about the specific details of what goes on that causes this. Any specific technical information regarding this would be greatly appreciated! Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如在 PDC 上宣布的那样，Azure 将很快开始在 Azure Web 角色上提供完整的 IIS。在 Don Box 的主题演示中，他展示了这允许您使用 Visual Studio 中的标准“发布”选项非常快速地部署到云。
如果我没记错的话，启动新的 Azure 角色时发生的部分事情是配置网络组件，我记得会议上的一些发言者曾提到这非常耗时。这也许可以解释为什么向已运行的角色添加其他实例通常会更快（但并非总是如此：我有时也看到这需要超过 15 分钟）。
编辑：另请参阅 此 PDC 会话。
As announced at PDC, Azure will soon start to offer full IIS on Azure web roles. Somewhere in the keynote demo by Don Box, he showed that this allows you to use the standard "publish" options in Visual Studio to deploy to the cloud very quickly.
If I recall correctly, part of what happens when starting a new Azure role is configuring the network components, and I remember some speaker at a conference mentioning once that that was very time consuming. This might explain why adding additional instances to an already running role is usually faster (but not always: I have seen this take much more than 15 minutes as well on ocassion).
Edit: also see this PDC session.
我不认为 EC2 行为特定于云。只需比较本地系统上 Windows 和 Linux 的启动时间即可 - 根据我的经验，Linux 启动速度更快。通常，这是因为启动的服务/恶魔的数量较少，每个服务/恶魔在启动期间需要进行的磁盘访问次数也较少。
至于Azure的启动时间：很难说，并且不能与机器启动（IMO）相比较。没有人知道 Azure 在启动应用程序时会做什么。他们可能需要首先组装虚拟机映像，或者发生大量日志记录/报告，从而减慢速度。
I don't think the EC2 behavior is specific to the cloud. Just compare boot times of Windows and Linux on a local system - in my experience, Linux just boots faster. Typically, this is because the number of services/demons launched is smaller, as is the number of disk accesses that each of them needs to make during startup.
As for Azure launch times: it's difficult to tell, and not comparable to machine boots (IMO). Nobody knows what Azure does when launching an application. It might be that they need to assemble the VM image first, or that a lot of logging/reporting happens that slows down things.
不要忘记，有一个 Fabric 控制器需要检查故障区域并跨多个故障区域部署虚拟机（以提供高可用性，至少在有两个以上实例时）。我不能肯定地说，但这个逻辑本身可能需要一些额外的时间。这也可以解释为什么网络设置可能有点复杂。
这当然可以解释云中启动时间与本地或亚马逊 Windows 启动时间之间的差异（如果有）。操作系统中的任何差异完全取决于操作系统的构建方式！
Don't forget, there is a Fabric controller that needs to check for fault zones and deploy your VMs across multiple fault zones (to give you high availability, at least when there are more than two instances). I can't say for sure, but that logic itself might take some extra time. This might also explain why network setup could be a little complicated.
This will of course explain the difference (if any) between boot times in the cloud and boot times for windows locally or in Amazon. Any difference in operating systems is completely dependent on the way the OS is built!