99.99% 可用的 ASP.NET 和 SQL Server SaaS 生产架构

引言

你有一个热门的 ASP.NET+SQL Server 产品，每天用户增长数以千计，并且你已经达到了自家车库托管能力的极限。现在你口袋里有了足够的风投资金，正计划出去找一些真正的托管设施，也许是托管或管理型托管。那么，你正在思考，如何设计一个物理架构，以确保你的产品的性能、可伸缩性、安全性和可用性？如何实现四个九（99.99%）的可用性？如何安全地让你的开发团队连接到生产服务器？如何为 Web 服务器和数据库服务器选择合适的硬件？应该使用存储区域网络 (SAN) 还是只使用 RAID 本地磁盘？如何安全地将你的办公电脑连接到生产环境？

在这里，我将回答所有这些问题。让我首先向你展示我为 Pageflakes 制作的一个图表，我们通过它确保实现了四个九的可用性。由于 Pageflakes 是一个 Level 3 SaaS，因此构建一个高性能、高可用性的产品至关重要，该产品可以全天候从世界任何地方使用，并且最终用户可以快速访问其内容，并对其内容进行完全的个性化和定制，还可以与他人和世界分享。因此，你可以将此生产架构视为 Level 3 SaaS 的一个非常好的选择。

点击此处下载完整图表。

首先快速概述： 

• Web 服务器层包含三台处于负载均衡模式的 Web 服务器。每台 Web 服务器都托管着我们拥有的 ASP.NET Web 应用程序代码和其他工件的完全相同的副本。IIS 6 的配置方式也完全相同。Web 应用程序使用基于 SQL Server 的 Session 和 Forms Authentication。
• Web 服务器与 SQL Server 集群通信。有两个主动/被动集群。一个集群托管主数据库，其中包含用户、页面和小部件；另一个集群托管其他数据库，如报告、日志、地理定位、缓存、RSS 等。我们根据它们的 I/O 负载分离了数据库，以便每个集群的 I/O 负载或多或少相同。 
• 数据库服务器连接到 EMC SAN，我们有几个 SAN 卷。在每个集群中，我们有一个 SCSI RAID 10 卷用于存储 MDF 文件，一个 SCSI RAID 1 卷用于存储 LDF 文件，以及一个 SATA RAID 1 卷用于存储日志。
• 有一个备用集群，它具有所有数据库的 SQL Server 事务日志传送镜像。这是为了数据库的逻辑冗余，这样如果在发布期间我们搞砸了数据库架构，我们有一个备用数据库可以回滚。

我将解释每个层、硬件组件以及选择它们所涉及的决策。

Web 层 

 

公共防火墙

操作： 使用一个连接到互联网（托管服务提供商的公共路由器或其他）并连接到一个名为外部路由器的路由器或交换机的防火墙。我们称此防火墙为公共防火墙（PF）。

原因：没有公共防火墙，你的服务器将赤裸裸地暴露在互联网上。你可能会争辩说，有 Windows 防火墙，这已经足够了。但事实并非如此。Windows 防火墙并非旨在像硬件防火墙那样有效地处理 DDOS 攻击、TCP 洪水、格式错误的包。硬件防火墙中有专门的处理器来处理所有过滤。如果接收到太多格式错误请求，你的 Web 服务器 CPU 将忙于应对这些攻击，而不是执行运行 ASP.NET 代码等实际工作。

操作： 你应该只打开端口 80 和 443。如果你不使用 SSL，则只打开端口 80。不要在公共防火墙上打开远程桌面端口。

原因： 你不应该将服务器暴露在互联网上进行远程桌面访问。如果你在星巴克通过不安全的 Wi-Fi 管理服务器时，有人劫持了你的远程桌面会话，你就完蛋了。远程桌面访问应该只通过 VPN 可用。

操作： 绝不要打开 FTP 端口。

原因： FTP 不安全，它以明文传输用户名和密码。任何具有基本黑客知识的人都可以在你通过 FTP 登录生产服务器时捕获用户名和密码。如果必须使用，则使用不需要用户名和密码的 FTP，并且只允许你将文件写入特定文件夹，绝不能读取任何内容或查看 FTP 服务器上的文件列表。这样，你不会将服务器凭据暴露给任何人，并且可以在需要时至少将文件传输到 Web 服务器。还要确保在你上传文件的卷上强制执行磁盘配额，并且带宽受到严格限制。否则，有人可能会使用全部带宽上传巨型文件并耗尽你的磁盘空间。

操作： 绝不要打开文件共享端口。

原因： 文件共享服务是最脆弱的端口之一。它暴露了 Windows 的关键服务，这些服务可能被入侵，从而在你的服务器上运行任意代码并将其摧毁。

带负载均衡器的外部交换机

操作： 外部交换机具有负载均衡功能，可将流量均匀分配到您的 Web 服务器。这意味着，您放置在负载均衡器后面的每个 Web 服务器都将获得总流量的均匀份额。您的每个 Web 服务器都有一块 NIC 连接到此交换机。这是您的公共连接。如果您的流量在每天 1000 万次点击以内，100Mbit 交换机和相同速度的 NIC 就足够了。您可以选择具有负载均衡器功能并有足够端口连接所有 Web 服务器的防火墙。

原因： 独立的网卡用于通过专用网络连接传输仅限网站的流量，这样它就不会受到任何其他本地流量的影响。交换机为您进行负载均衡。不要使用 Windows 网络负载均衡。再说一次，其目的是让您的 Web 服务器只执行它们的工作——执行 ASP.NET 代码、调用数据库、返回 HTML 页面和静态文件，仅此而已。将所有其他事情交给其他组件。硬件负载均衡器效率很高，容错能力更强。如果您选择软件负载均衡，您将不得不定期重启服务器，以解决诸如服务器无法与其他服务器协同工作，或者服务器流量过大等神秘问题。

操作： 保持负载均衡器简单，只进行基本的轮询流量分配，不要花哨的亲和性，不要请求头解析。

原因： 我们尝试过一些亲和性和 URL 过滤，以便从特定服务器提供特定 URL。那简直是噩梦。我们与思科支持工程师通了无数小时电话，以排除神秘行为。他们提供了无休止的补丁，一个错误解决了，另一个又出现了。亲和性问题表现出神秘行为，将服务器从负载均衡器中移除后仍然向其发送流量等等。我们尝试了 URL 过滤，其中一些特定的 URL 模式，如 www.pageflakes.com/company，由特定的 Web 服务器提供服务。但这要求负载均衡器打开每个请求，解析它，找到 URL，然后与长长的 URL 模式列表进行匹配，并决定将流量发送到何处。这是一个错误的决定。它导致负载均衡器在高流量下堵塞，内部错误缓冲区溢出，频繁自行重置以清除其内部的所有堵塞等等。因此，我们学到了一个非常有价值的教训，这是微软架构师曾告诉我们的，但我们当时太自以为是而忽略了他——“让你的负载均衡器保持简单——使用基本的轮询。”

操作： 每个路由器和防火墙都有一个备用设备。

原因： 当任何这些设备发生故障时，备用设备会启动。如果你没有备用公共防火墙，那么当你的防火墙宕机时，你的网站将完全宕机，直到你获得一个替代防火墙。同样，当外部路由器/交换机宕机时，你的网站也会宕机。因此，拥有一个备用防火墙和交换机/路由器是明智的。为一台 99% 时间闲置的设备花钱很难，但当它挽救局面并防止你的网站宕机数小时时，你会觉得自己很明智。此外，有时你需要升级防火墙或路由器的固件。然后你将不得不重新启动设备。如果你重新启动它，这意味着流量将无法通过它。因此，在这种情况下，你将备用设备联机，然后修补并重新启动主设备，然后将主设备联机，然后修补并重新启动备用设备。

操作： 您的每个 Web 服务器都有另一个 NIC，将 Web 服务器连接到您的数据库所在的私有网络。在图表中，它是内部路由器或内部交换机。

原因： 不要使用同一个 NIC 连接到私有和公共网络。您不希望公共网络流量堵塞您的本地网络流量。通常，公共网络和私有网络上的流量性质完全相反——公共网络进行不频繁的长突发流量传输（向浏览器提供大型 HTML 响应），而私有网络进行高频率的短突发流量传输（进行简短而频繁的数据库调用）。

操作： 获取性能适中的 Web 服务器，并配备足够的存储空间。我们选择 Dell 1950 服务器作为 Web 服务器，该服务器配备 2 个四核处理器，8 GB 内存和 3 块 NIC。有四个 500 GB SATA 硬盘，组成两个 RAID 1。

原因： C: 卷位于一个 RAID 1 上，存储操作系统；D: 卷位于另一个 RAID 1 上，存储 Web 应用程序代码和巨大的 IIS 日志。你可能会觉得为什么 OS 分区需要 500 GB。我们有 MSMQ，并且在 C: 驱动器上有一些非常大的队列。你可能还会觉得为什么 D: 驱动器有这么大的空间。当你在 IIS 上打开 Cookie 日志时，由于 ASP.NET 巨大的表单身份验证 Cookie 在每个请求中发送并被记录，IIS 日志往往会变得非常大。对于中等流量的网站，你每个服务器可能会产生 3 GB 的 IIS 日志。最好在 Web 服务器上保留足够的空间来存储数周的 IIS 日志，以防你的内部系统将这些日志移动到其他地方进行报告的功能出现故障。

操作： 运行 64 位版本的 Windows。

原因： 没有 64 位操作系统，你就无法充分利用 4 GB 或更多的内存。事实上，即使你的 32 位 Windows 上有 4 GB 内存，你也只能使用大约 3.2 GB。32 位处理器存在一些寻址问题，特别是 PCI 控制器会使用 3.2 GB 以上的一些寻址空间来映射设备。因此，Windows 可用的内存低于 3.2 GB。但 64 位操作系统允许你使用数 TB 的内存。64 位版本的 .NET 框架足够稳定，可以运行重型应用程序。你可能在个人电脑上运行 64 位 Windows 有过不好的体验，但现在的 64 位服务器相当稳定。我们过去两年的运行从未出现过故障。

操作： 内部网络完全为 1Gbit。所有网线都是 Gbit 网线，路由器/交换机都支持 Gbit。连接到内部交换机的 Web 服务器上的 NIC 也是 Gbit 的。尽量在这一配置上多花钱，因为它需要最快。

原因： 这是您的 Web 服务器与数据库服务器之间所有通信的必经之路。这些连接上将有非常频繁的数据传输和大量数据传输。您网站上的每个页面都可能进行 10 到 100 次数据库调用。每个页面将有短暂而频繁的传输。因此，您需要整个私有 LAN 连接非常非常快且延迟低。

等等批量工作路由器。我很快就会讲到它。

VPN 连接

图表的右侧显示了 VPN 连接。有一个支持 VPN 的防火墙，可将您的办公室和漫游用户连接到内部路由器。从内部路由器，用户可以进入 Web 服务器和数据库服务器。当您需要在办公室和生产环境之间进行大量文件传输时，这有时需要很快。例如，如果您每天从生产服务器拉取数 GB 的 IIS 日志到办公室，那么您需要在此处获得相当好的连接。尽管瓶颈始终是您办公室的互联网连接。如果您办公室与生产环境之间有 T1 连接，那么 10Mbit 防火墙、交换机和网线就足够了，因为 T1 大约是 1.544Mbps。

原因： 为什么需要 VPN？因为只允许通过加密通道连接到生产环境是绝对重要的。VPN 是确保您的计算机与生产环境之间的连接绝对安全，并且没有人可以窃听或窃取您的会话的唯一方法。此外，拥有 VPN 意味着还需要另一层基于用户名+密码的安全，才能进入生产环境。这意味着，即使您的服务器凭据被盗，也许您将其存储在 USB 钥匙扣中，除非连接到 VPN，否则任何人都无法连接到您的生产服务器。

操作： 从您的办公网络到您的生产环境建立站点到站点的 VPN。使用具有站点到站点 VPN 功能的路由器。

原因： 使用 VPN 客户端软件连接 VPN 是一件痛苦的事。连接会中断，由于是基于软件的加密，速度很慢等等。然后还有 Vista 问题，世界上大多数 VPN 客户端都无法工作。因此，让路由器始终保持与生产环境的安全连接可以节省大量时间。特别是当您在生产环境和办公电脑之间传输大文件时。

操作： 在办公室放置一个路由器，将开发人员和 IT 工作站与其他工作站分开。

原因： 如果您在路由器上配置了站点到站点 VPN，则连接到该路由器的每个人都可以访问生产环境。请相信我，您不希望销售人员的笔记本电脑访问生产环境。因此，您必须隔离高度信任的计算机，如 IT 和开发人员工作站，并将网络中的其他计算机隔离到不同的子网中。然后，您只允许受信任的子网访问生产环境。您可以在一个好的路由器中设置规则，只允许特定子网向生产服务器 IP 发送流量。如果您在办公室本地有暂存服务器，您也应该采取同样的预防措施。只有受信任的子网才能看到它们。这种额外的预防措施有助于避免销售人员通过笔记本电脑带到办公室的所有新病毒和蠕虫的不必要传播。

数据库层

数据库服务器位于内部路由器/交换机后面。您可能希望通过将 Web 服务器隔离在 DMZ（即非军事区）中，将数据库服务器放置在非常安全的网络上。但我们不使用 DMZ 防火墙，因为它会成为 Web 服务器和数据库服务器之间所有流量的最大瓶颈。因此，我们使用路由器，并且只允许 SQL Server 的端口 1433 从 Web 服务器传递到任何数据库服务器。如果您对安全性不是很狂热，也可以使用交换机。我的逻辑是，通过正确打补丁和使用安全最佳实践来保护每台服务器，确保服务器本身始终受到保护。如果有人通过入侵 Web 服务器进入，连接字符串就在一个可读的 web.config 文件中。因此，黑客可以使用它连接到您的数据库并造成足够的损害，例如运行 DELETE * FROM aspnet_users。因此，阻止端口，将 Web 服务器置于 DMZ 中并没有太大帮助。当然，这只是我基于对黑客能力的有限了解的个人看法。

操作： 数据库服务器需要是非常强大的服务器，拥有尽可能多的 CPU 算力、非常快的磁盘控制器和大量的内存。

原因： SQL Server 既进行磁盘密集型工作，也进行 CPU 密集型工作。因此，您投入的 CPU 越多，查询执行得越快。此外，磁盘需要非常快。您绝对应该使用带有 15K RPM 磁盘的 SAS。对于本地磁盘，磁盘控制器上的大量内存会产生很大影响。还要尽可能多地配置 L2 缓存，至少 4 MB。

操作： 将 MDF 和 LDF 文件存储在不同的物理磁盘上。

原因： 大多数读取来自 MDF，写入到 LDF。因此，你需要将它们放在不同的物理磁盘上，以便读取和写入并行执行，互不干扰。此外，事务首先应用于 LDF，然后应用于 MDF。所以 MDF 也有相当多的写入。

操作： 对于 MDF 或高读取场景，使用 RAID 10。

原因： RAID 10 是读取速度最快的 RAID 配置。由于数据分布在多个磁盘上，读取是并行进行的。因此，RAID 控制器不是从一个磁盘顺序读取字节，而是同时从多个磁盘读取字节。这提供了更快的读取性能。

操作： 对于 LDF 或高写入场景，使用 RAID 1。

原因： 由于 RAID 1 只有两个磁盘，写入数据的磁盘较少。因此，写入性能优于其他更高级的 RAID 配置。当然，RAID 0 是最快的，但它没有冗余。因此，在数据损坏会导致严重问题的数据库上使用它是不可能的。

操作： 将 SAS 硬盘用于操作系统分区。

原因： 听起来很昂贵，但当内存不足时，SQL Server 会进行大量的分页操作。由于页面文件驻留在本地磁盘上，因此它需要尽可能快。否则，分页性能会受到磁盘速度的影响。

操作： 始终将备份和日志传送执行到不同的物理磁盘，最好是 RAID 1。

原因： 备份会产生大量的磁盘写入。事务日志也是如此。读取总是来自 MDF。因此，将备份写入不同的物理磁盘至关重要。否则，在备份期间，持续读取以及 MDF 上的常规读写会使 SQL Server 堵塞。我们遇到过这样的问题：每当我们进行完整备份时，在最后时刻，当 SQL Server 锁定整个数据库以写入备份开始以来发生的最新事务时，数据库被锁定的时间太长，导致查询超时，网站抛出 SQL Timeout Exceptions。加速整个最后一刻锁定问题的唯一方法是确保从 MDF 的读取速度非常快，并且备份的写入速度也非常快。因此，我们使用 RAID 10 卷将 MDF 分散到更多的磁盘上，并使用 RAID 1 卷将写入分散到更少的磁盘上。

操作： 使用 Windows 集群实现高可用性。

原因： Windows 集群是一种高可用性解决方案，通常配置为一个活动服务器和一个被动服务器。两台服务器都安装了 SQL Server。但在同一时间，只有一台保持活动状态并连接到共享存储——SAN。当活动服务器发生故障时，集群管理员会自动使被动服务器联机并连接 SAN 卷。这样，您就可以获得最短的停机时间，因为切换到另一台服务器的开销只是在被动服务器上启动 SQL Server 并从恢复中加载数据库所需的时间。通常，被动服务器会在 5 分钟内带着一个 80 GB 的数据库联机。在故障转移期间，它只需回滚 LDF 中未提交的事务。

但 Windows 集群的诀窍是你必须有 SAN。本地磁盘是行不通的。这会将你带到下一个建议。

操作： 使用存储区域网络 (SAN)。

原因： 性能、可伸缩性、可靠性和可扩展性。SAN 是终极存储解决方案。SAN 是一个巨大的盒子，内部运行着数百个磁盘。它有许多磁盘控制器、许多数据通道、许多缓存内存。您在 RAID 配置方面拥有 ultimate 的灵活性，可以在 RAID 中添加任意数量的磁盘，在多个 RAID 配置中共享磁盘等等。SAN 拥有比您安装在服务器内部的常规控制器更快的磁盘控制器、更多的并行处理能力和更多的磁盘缓存内存。因此，与使用本地磁盘相比，使用 SAN 可以获得更好的磁盘吞吐量。您可以在应用程序运行和使用卷时动态增加和减少卷。SAN 可以自动镜像磁盘，并在磁盘故障时自动启动镜像磁盘并重新配置 RAID。

但 SAN 也有一些严重的顾虑。通常你不会选择专用 SAN，因为它太贵了。你从托管服务提供商现有的 SAN 中获取一些磁盘。现在，托管服务提供商从同一个 SAN 为许多客户提供服务。他们给你从可能运行其他客户数据库的磁盘空间。例如，假设 SAN 有 146GB SAS 磁盘。现在你向他们请求了 100 GB SAS 存储。这意味着他们已经从一个磁盘分配给你 100 GB，其余 46 GB 分配给了另一个客户。因此，你和另一个客户正在 SAN 上的同一个磁盘上读写。如果另一个客户在早上 8 点发布了完整备份怎么办？磁盘被大量的写入操作轰击，而你却在努力从那个风险中获得一点点读取。如果另一个客户有一个愚蠢的 DBA，他没有很好地优化数据库，因此产生了太多的磁盘 I/O 怎么办？那么你将为你的磁盘 I/O 份额而挣扎。尽管磁盘控制器会尽力限制读写，并给所有使用同一个磁盘的用户公平的份额，但情况并不总是那么公平。你为别人的愚蠢而受苦。避免这个问题的一种方法是根据物理磁盘大小从 SAN 购买空间。如果 SAN 由 146 GB SAS 磁盘组成，则以 146 GB 的倍数购买空间。你可以要求你的托管服务提供商给你没有与其他人共享的完整磁盘。

操作： 内存，大量的内存。

原因： SQL Server 尽力将索引保留在内存中。它在内存中存储得越多，查询执行得就越快。从磁盘获取一行比从内存中找到该行慢一千多倍。因此，如果您看到 SQL Server 从 MDF 中产生了太多的读取，请增加内存。如果您看到 Windows 正在进行分页，请增加内存。持续增加内存，直到您看到磁盘读取稳定在一个较低的值。然而，这是一种非常不科学的方法。您应该测量 SQL Server 的“缓冲池命中率”性能计数器和“页/秒”计数器以做出更好的决策。但根据经验法则，内存应为 2 GB + MDF 大小的 60%。如果您的 MDF 为 50 GB，则应有 32 GB 内存。这样做的原因是，您不需要将所有 MDF 都加载到内存中，因为并不是所有行都会时不时地被提取。通常 30% 到 40% 的数据是日志、审计或不经常访问的数据。因此，您应该弄清楚有多少数据被频繁访问。然后根据此推导出内存量。再次强调，性能计数器是判断 SQL Server 是否需要更多内存的最佳方法。

操作： 从您的服务器到 SAN 获取双路径光纤通道连接。

原因： 双路径光纤通道是到 SAN 的非常快速可靠的连接。双路径意味着有两条路径，如果其中一条失败，I/O 请求将通过另一条路径。我们手动尝试过。我们要求支持工程师在我们运行 Web 应用程序时手动拔掉一个通道，而应用程序没有显示任何可见问题。由于 SAN 就像一个远离您的服务器的网络设备，因此您必须拥有 100% 可靠的 SAN 连接，并且在连接失败时有备用计划，这一点绝对重要。

报告和备份

操作： 准备一个单独的服务器，用于从 Web 服务器移动 IIS 日志。

原因： 你需要解析 IIS 日志来生成流量报告，除非你使用的是 Google Analytics 或其他不依赖于 IIS 日志的分析解决方案。你绝不应该在 Web 服务器上运行任何报告工具来分析 IIS 日志，因为它们会消耗 CPU 和磁盘负载。最好是有一个批处理作业，将每日 IIS 日志复制到单独的报告服务器上进行分析。

操作： 准备一个大的可拆卸外部存储设备，例如外部 USB 驱动器。

原因： 在开发过程中，经常需要从生产环境向本地办公室传输大量数据，例如数据库备份。有时你需要将大量数据从某个暂存环境移动到生产环境。通过网络传输大量数据既耗时又不可靠。最好直接运送包含数据的外部 USB 驱动器。你可以进行生产数据库备份，将其加密存储在 USB 上，然后将 USB 驱动器运送到你的办公室。

操作： 使用快速 SCSI RAID 1 磁盘。

原因： 报告和备份需要大量的磁盘 I/O。当你从 Web 服务器或数据库服务器移出数据时，你希望任务尽快完成。你不希望它因为报告/备份服务器上的磁盘性能差而延迟。此外，分析大量数据需要时间，尤其是 IIS 日志或恢复数据库备份进行分析。因此，报告服务器上的磁盘也需要非常快。此外，如果你遇到灾难性故障并且数据库丢失，那么你可以使用报告服务器作为临时数据库服务器，直到你的主数据库服务器建立起来。有一次，我们的管理员从主数据库服务器删除了我们的生产数据库。幸运的是，我们在报告服务器上有每日备份。因此，我们在报告服务器上恢复了每日备份，并将其暂时作为主数据库服务器，直到我们准备好带有生产数据库的真实数据库服务器。

独立网卡和交换机用于批量操作 

操作： 所有服务器都应使用独立的网卡，通过独立的交换机连接到独立的私有网络，用于批量操作。

原因： 当您进行大文件复制时，例如从 Web 服务器到报告服务器的 IIS 日志复制，复制操作会占用大量的网络带宽。它不仅给与数据库服务器进行高频通信的私有 NIC 带来压力，还会给私有交换机带来大量负载，而私有交换机已经承载了所有 Web 服务器和数据库服务器的总流量。这就是为什么您需要通过独立的 NIC 和独立的交换机连接到完全独立的私有 LAN 来进行大文件复制操作，例如 IIS 日志复制或数据库备份复制。您应该在独立的网络 IP 上映射每个服务器上的网络驱动器，这样任何传输到这些驱动器的数据都将通过专用于批量操作的 NIC 和交换机。您还应该将此批量操作网络连接到 VPN，这样当您从办公室下载/上传大文件时，它不会影响 Web 服务器和数据库服务器之间的高优先级流量。

结论

上述架构相当昂贵，但保证 99.99% 的可用性。当然，可用性也取决于你的工程师的绩效。如果他们不小心搞垮了网站或删除了数据库，没有任何硬件可以挽救你。但拥有足够的冗余硬件可以确保你快速恢复，并在风投发现你宕机之前恢复业务。这里解释的架构在托管环境中每月可能花费你大约 3 万美元。所以，它并不便宜。你当然可以通过信贷购买所有这些硬件，每月支付大约 2 万美元，为期两年。所以，由你来决定在硬件和可用性之间做出多少妥协。根据你运行的应用程序类型，你可以选择更小的基础设施，但仍然保证 99.99% 的可用性。曾经我们资金非常紧张，只用 4 台服务器运行整个网站，仍然实现了三个月 99.99% 的可用性。所以，这一切都来自于经验，经验可以为你特定的应用程序需求提供最佳的生产环境。