适用于现有 Asp.Net 网站的 Azure 云服务与 VM答案

【问题标题】：Azure Cloud Services vs VMs for Existing Asp.Net website适用于现有 Asp.Net 网站的 Azure 云服务与 VM
【发布时间】：2013-08-27 17:16:04
【问题描述】：

我已经看到了这个问题的变体，但找不到任何与我们的特定场景相关的问题。

我们有一个链接到 SQL Server 数据库的现有 aps.net 网站。该数据库具有 clr 用户定义的类型，因此它只能托管在 Azure VM 中，因为云服务不支持所述类型。

我们最初想为数据库使用虚拟机，为前端使用云服务，但后来出现了一些问题：

我们使用 StateServer 来存储状态，但 Azure 不支持。我们需要配置表存储、SQL 数据库或专用于状态管理的 Worker 角色（新的 Worker 角色是额外的成本）。由于性能，表存储并不理想。其他 2 个选项更可取，但它们会带来成本或应用程序重新配置的缺点。
我们使用 SimpleMembership 进行用户管理。我们需要将成员表从我们的 vm 实例 sql 服务器迁移到 Azure 的 SQL 数据库。这是一个不便，因为我们希望将所有表保存在同一个数据库中，并且拆分 2 个可能需要进行一些代码更改。

我们正在寻找一种快速解决方案，以使该应用尽快上线，并且成本可控。我们正在拼命地避免重构我们的代码，以适应在 Azure 云服务中托管应用程序的一部分。

问题：

我们是否应该使用虚拟机路由来托管所有内容？
利用 VM 实例（用于 sql server）和云服务实例（用于前端）是否有任何成本优势？
在我看来，每个添加到云服务的“后台进程”都需要一个新的辅助角色。例如，如果我们想为电子邮件服务启用 smtp，这将需要一个新角色，因此需要更多成本。这是正确的吗？

【问题讨论】：

标签： asp.net sql-server azure azure-web-roles azure-vm-role

【解决方案1】：

要使用 CLR 等运行 SQL Server，您需要在虚拟机中运行 SQL Server。

对于 Web 层，云服务（Web 角色）具有优势，因为它们是无状态 - 非常容易横向扩展/横向扩展，而无需担心操作系统设置。应用程序设置是在启动时通过启动脚本完成的。如果您可以适当地托管会话内容，那么无状态模型将更易于扩展和维护。但是：如果您有任何类型的复杂安装需要一段时间（或手动干预）来执行，那么虚拟机确实可能是更好的途径，因为您可以构建虚拟机，然后从该虚拟机创建主映像.就像在本地环境中一样，您仍然需要解决操作系统和应用维护问题。

让我更正您关于后台进程的第三个项目符号。云服务的 Web 角色（或工作者角色）实例仅仅是 Windows Server VM 的，带有一些用于启动和进程监控的脚手架代码。您不需要为每个角色设置单独的角色。随意在单个 Web 角色上运行您的整个应用程序并进行横向扩展；您只会在非常粗粒度的级别上进行缩放。

【讨论】：

因为无论如何我们将在 2 个 VM 中托管 SQL Server 以实现高可用性，所以我看不到将 Web 角色用于前端的动机。拥有 2 个虚拟机和 2 个角色实例来确保高可用性将是昂贵的。如果我弄错了，请就这个方向提出建议。非常感谢。

【解决方案2】：

需要考虑的一些事情...

如果您想要便宜，您可以通过添加 RoleEntryPoint 让您的 web/worker 角色在单台机器上共享相同的代码。这是一篇文章，实际上展示了如何发送电子邮件： http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx

SQL Azure DB 中的会话管理速度非常慢，如果可以的话，我会使用 Azure 缓存......它很快。

带有 VM 的 SQL Server 会给你带来麻烦，因为你还需要在它和任何云服务之间创建一个虚拟网络。这真的很愚蠢，但是如果您部署云服务和虚拟机，它们会通过公共负载平衡器进行通信，从而导致潜在的安全问题和网络延迟。因此，首先您需要对它们进行虚拟网络（这是额外费用）。然后您还需要托管 DNS 服务器来寻址 SQL Server VM。是的，这真的很愚蠢，除非您可以通过 Internet 与您的 SQL Server 通信的 web/worker 角色：)

编辑：将“公共互联网”更改为“公共负载平衡器”（并注明延迟）

编辑：与下面大卫的评论相反，上述信息 100% 正确。请在此处阅读 Microsoft 的指南：

http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario

直接来自 MICROSOFT GUIDANCE 谈论跨云服务通信（VM->web/worker 角色）：

“我们建议您实施第一个选项，因为连接过程不需要通过公共 Internet。因此，它会提供更好的网络性能。”

从今天（2013 年 8 月 29 日）起，Azure 虚拟机和工作人员/Web 角色已部署到不同的“云服务”中。因此，它们之间的通信需要通过在实例之间公开私有 IP 地址的虚拟网络来保护。

继续跟进 David 的以下观点，即添加 ACL。您仍在使用 TDS（SQL Server 协议）通过 Internet 发送数据包。这可以加密，但没有理智的架构师/企业治理/安全治理会“允许”这种情况在生产环境中发生。

【讨论】：

您关于云服务和虚拟机通过 Internet 而非 azure 内部网络进行通信的信息：不真实。如果两者都部署在同一个数据中心，流量将停留在数据中心内，即使您使用 xxx.cloudapp.net 名称。
进一步：您不一定需要虚拟网络，因为您可以在 SQL VM 上创建一个 ACL 端点，该端点的 IP 白名单仅用于云服务的 VIP。几行简单的 PowerShell 就搞定了。
@DavidMakogon 哇，你错了 100%。请在此处查找 Microsoft 的指导：msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario 明确说明：“我们建议您实施第一个选项，因为连接过程不需要通过公共 Internet。因此，它会提供更好的网络性能。”
我不知道为什么该指南是这样写的。数据不在同一数据中心的两个服务之间通过公共 Internet 传输。托管在同一个数据中心的存储也是如此：想象一下，如果这是真的，您的数据磁盘内容将在存储和计算之间通过 Internet 流动，因为它们位于 blob 中。此外，所述数据传输没有出站带宽费用，因为它不会离开数据中心 (pricing link)
@DavidMakogon 您正在混淆服务..那些“分布式服务”在内部自动路由。您可能想观看 BUILD 2012 会议上的这段视频（由 IaaS 产品的架构师制作）：channel9.msdn.com/Events/Build/2012/2-011（从 58.5 分钟开始）它是“这样写的”，因为那是指导，它是不太安全（如：指南、Windows Azure 培训工具包和上面链接的视频所反映的那样！）顺便说一句..随时删除反对票！