使用 Microsoft Windows DNA 平台构建 Web 站点的蓝图

http://www.microsoft.com/china/MSDN/library/archives/technic/voiCEs/DNAblueprint.asp
 

使用 Microsoft Windows DNA 平台构建 Web 站点的蓝图

草图，.9 版
Microsoft Corporation

2000 年 1 月

用自解压缩的可执行文件下载本文档的 Microsoft Word 版本。(177K)

摘要： 关于用 Microsoft Windows DNA 技术构建复杂的 Web 站点的培训技术资料，对象为工程师和决策者。

目录

执行摘要
体系结构概述
示例站点
可伸缩性
可用性
安全性
管理与运作
摘要

执行摘要

商务正迅速发展为标准的、基于 Web 的计算模型，其特征为重复且针对任务的系统的松散连接层。很大比例的商务 Web 站点 — 提供联机服务的服务器、应用程序和数据的集合 — 都是用当今的 Microsoft Windows DNA 平台构建的，成为该计算模型的基础。本文档定义了构建 Windows DNA 站点的体系结构。读者可以借用这些信息，设计和构建当今基于 Windows DNA 的站点。

本文档集中讨论如何使用 Microsoft 技术，特别是 Windows DNA 平台，以尽可能有效利用财力和时间的方法，构建可伸缩、可用、安全和可管理的站点的基础结构。强调保持 Web 站点简便灵活的运作和应用程序设计，以及“.com”如何能够成功地以必要而有效的可伸缩性、可用性、安全性和可管理性来部署和运作站点。其次强调当前文档齐全的工具和构建 Web 应用程序组件的方法。另外还从宏观层次检查 Microsoft Windows DNA 解决方案（使用 Microsoft(R) Windows NT(R) 4.0 和/或 Windows 2000）的优点，并逐级进入，以定义如何使用 Microsoft 产品建立站点体系结构中的每一层次。最后，将讨论使用 Microsoft 工具和技术管理 Web 站点。

尽管只是个概述，本文档还是检查了一个成功使用部署的体系结构的示例 Web 站点，它可作为使用 Windows DNA 平台构建的站点的模型。本文档不涉及（除了与可伸缩性、可用性、安全性和可管理性相关时）诸如应用程序设计、开发工具或数据库设计等主题；但是提供涵盖这些领域的相应文档的指针。

“体系结构概述”介绍一些对于大型 Web 站点很重要的体系结构概念。在“示例站点”描述了一个具有代表性的站点并解释了它使用的基础结构和各层。其余章节讨论了站点的四个关键属性 — “可伸缩性”、“可用性”、“安全性”和“可管理性” — 并使用示例站点来说明这些问题。对相关文档的引用贯穿整个文档。

体系结构概述

简介

大型商务站点为动态变化的模型：它们通常一开始很小，但随着需求的增长而指数增长。不仅在支持的独特用户的数量上不断增加，这种增长非常迅速，而且在提供的用户服务的复杂性和集成性方面也不断增长。经投资者的检查，许多站点启动的商务计划的可伸缩性为 10-100 倍，这个数据是可信的。成功的商务站点，通过不断增加向客户机提供逻辑服务的服务器数量（即通过服务器提供其自身的多个实例（克隆）或通过在自身之间均衡工作负荷），以及创建与已有计算机系统相集成的服务来管理这种增长和变化。这种增长的基础为支持高度可用性的坚实的体系结构、安全基础结构和管理基础结构。

体系结构目标

本文档描述的体系结构力图达到四个目标：

• 线性可伸缩性 — 可持续增长以满足用户需求和业务复杂性。
  
  
• 持续的服务可用性 — 使用冗余和功能专业化来提高容错能力。
  
  
• 数据和基础结构的安全性 — 保护数据和基础结构免受恶意攻击或盗用。
  
  
• 管理的简便性和完整性 — 确保运作能够满足增长的需求。

可伸缩性

为了可以扩展，商务 Web 站点将其体系结构分为两部分：前端（客户机可访问的）系统和存储长期永久数据的或商务处理系统所在的后端系统。负荷平衡系统用于将工作分配到每一层的系统中。前端系统通常不保留长期状态。也就是说，前端系统中每次请求的环境通常是暂时的。这种体系结构，通过克隆或复制与无状态负荷平衡系统（使负荷在可用的克隆体之间分配）相耦合的前端系统，扩展其支持的独特用户的数量。我们将克隆体集合中的 IIS 服务器集合称为 Web 群集。在多个后端系统之间分区联机内容同样可以扩展。带状态的或内容敏感的负荷平衡系统则将请求路由到正确的后端系统。通过功能专业化，业务逻辑复杂性以可管理的方式增长。专用的服务器负责专门的服务，包括与遗留或脱机系统的集成。克隆与分区，和功能专业化服务一起，通过单独增长每个服务而使得这些系统具有极大的可伸缩性。

可用性

通过使用多个克隆服务器（所有服务器均为其客户机提供唯一的地址）使得前端系统具有高度可用性和可伸缩性。负荷平衡用于在克隆体之间分配负荷。将故障检测功能置入负荷平衡系统提高了服务的可用性。不再提供服务的克隆体将自动从负荷平衡集合中删除，而剩下的克隆体将继续提供服务。使后端系统具有高度可用性更具挑战性，主要是因为它们维护着数据或状态。它们通过对每个分区使用故障转移群集 (failover clustering) 来实现高度可用。故障转移群集假定应用程序能够在可以访问故障系统的磁盘子系统的其他计算机上继续运行。分割故障转移发生在支持分区请求的主节点故障时，此时分区请求自动切换到二级节点。二级节点必须有权访问与故障节点同样的数据存储，该数据存储也应该是复制的。复制品还可通过在远程位置上成为可用，来提高站点的可用性。可用性在很大程度上还取决于企业级 IT 规则，包括更改控制、严格测试和快速升级以及反馈机制。

安全性

安全性 — 通过为信息的机密性、保密性、完整性和可用性提供充分的保护来管理风险 — 是任何商务站点成功的基本要素。商务站点使用多个安全域，其中包括具有不同安全性需求的系统，每个域均受到网络过滤器或防火墙保护。有三种主要的域，互相用防火墙隔离，它们是：公共网络；DMZ（由军事术语“非军事区域”派生而来），是前端和内容服务器所在之处；以及安全网络，是创建或使用内容的地方，也是管理和存储安全数据的地方。

管理

管理和运作广泛涉及维护商务站点及其服务正常工作所需的基础结构、工具以及管理员和技术人员。许多站点均位于常称作宿主环境的地方。也就是说，这些系统配置有“Internet 服务提供商 (ISP)”或专家宿主服务，这里可提供丰富的 Internet 连通性。因此，系统的管理和监控必须远程完成。在这种体系结构中，我们将描述这种管理网络和网络必须支持的管理功能类型。

体系结构元素

本节要突出的商务 Web 站点的关键体系结构元素包括：客户机系统；负荷平衡的、克隆的前端系统（客户机系统可用访问的）；负荷平衡的、分区的后端系统（前端系统可用访问这里的永久存储）；以及三种拱形体系结构考虑：灾难承受能力、安全域及管理和运作。

大型商务 Web 站点的原理

图 1 展示了商务 Web 站点的概念和基本原理，这些内容将在本节的以下部分详细说明。

图 1. 体系结构的原理

图 1 显示了前端、后端和负荷平衡层的划分，正如本文档所述。防火墙和网段分区为安全原理的关键。

客户机

在这种站点体系结构中，客户机向某服务名称发送请求，该服务名称代表提供给客户机的应用程序。最终用户和客户机软件不知道提供服务的系统的内部运作方式。通常，最终用户键入第一个 URL，例如，http://www.thebiz.com/，然后单击超级链接或完成 Web 页上的表单以便向站点深处导航。

对于范围广泛的 Web 站点，一个重要的决定就是是否在浏览器中支持功能的最低公共集，或是否为不同的浏览器版本提供不同的内容。目前，尽管还有更旧的浏览器在使用，但 HTML 3.2 通常为所支持的最低版本。例如，浏览器可如此分类：支持 HTML 3.2 的，如 Microsoft Internet Explorer 3.0；支持动态 HTML (DHTML) 的，如 Internet Explorer 4.0；以及支持 Extensible Markup Language (XML) 的，如 Internet Explorer 5.0。然后为每个类提供不同的内容。IIS 和工具，能够创建可动态呈现给不同浏览器的页面。

前端系统

前端系统由向 Web 客户机提供核心 Web 服务（如 HTTP/HTTPS、LDAP 和 FTP）的服务器组成。开发人员通常将这些前端系统分为一系列称作克隆体的相同系统的集。它们运行相同的软件，并通过内容复制或高度可用的文件共享访问相同的 Web 内容、HTML 文件、ASP、脚本等。通过克隆体之间的负荷平衡请求，以及通过检测故障克隆体并将其从工作的克隆体中删除，可实现高度可伸缩性和可用性。

克隆体（无状态前端）

克隆是为 Web 站点增加处理能力、网络带宽和存储带宽的良好手段。由于每个克隆体在本地复制存储，因此，所有更新必须应用到所有克隆体上。但是，由于与负荷平衡、故障检测和消除客户机状态的耦合，克隆的确是扩展站点和提高可用性的良好方法。

无状态负荷平衡

负荷平衡层向用户提供一个服务名称并将客户机负荷分配给多个 Web 服务器。这将为服务器集提供可用性、可伸缩性和某种程度的可管理性。负荷平衡手段有多种，包括“Round Robin 域名服务器 (RRDNS)”及各种基于网络的和基于主机的负荷平衡技术。

维护客户机状态

我们不希望在克隆前端系统中维护客户机状态，因为这与透明客户机故障转移和负荷平衡相抵触。在会话间维护客户机状态的基本方法有两种。一种是将客户机状态存储在分区的后端服务器中。（由于客户机状态可以完全分区，因此也易于扩展。但是，需要对每个客户机请求检索该状态）。在会话间维护客户机状态的另一种方法是使用 cookie 和/或 URL。Cookie 是由客户机 Web 浏览器管理的小文件。它们无益于减小带状态服务器的负荷和增加无状态前端系统的实用性。数据还可以存储在 URL 中，并在用户单击显示的 Web 页上的链接时返回。

前端可用性

当在这些前端服务器上运行应用程序代码时，无论是用 Microsoft Visual Basic(R) 或 C++ 等高级语言还是用脚本编写，从不同的 Web 应用程序隔离编程错误是非常重要的。使应用程序代码在 Web 服务器的进程外运行，是相互隔离编程错误和避免 Web 服务器故障的最佳方法。

后端系统

后端系统是维护应用程序数据的数据存储，也是启用与其他维护数据资源的系统的连通性的数据存储。数据可以存储在普通文件、数据库系统（如 Microsoft SQL Server(TM)）或其他应用程序中，如下表所示。

表 1. 数据存储的不同类型

	文件系统	数据库	其他 应用程序
示例	文件共享	SQL	Ad insertion、SAP、Siebel
数据	HTML、图像、可执行文件、脚本、COM 对象	类别、用户信息、日志、帐单信息、价格表	库存目录/库存、标语广告、帐目信息

使后端系统扩展和具有高度可用性更具挑战性，主要因为它们必须维护数据和状态。一旦单一系统的可伸缩性已经达到，就必须分区数据并使用多台服务器。因此，持续的可伸缩性是通过数据分区和将逻辑数据映射到正确的物理分区的数据相关路由层或带状态负荷平衡系统来实现的。

对于提高的可用性，群集 — 通常由两个访问公共的、复制的或 RAID （独立盘的冗余数组）保护的存储器的节点组成 — 将支持每个分区。当一个节点上的服务失败时，另一个节点将接管分区并提供服务。

分区（带状态的后端系统）

通过复制硬件和软件及在各节点之间划分数据，分区增强了服务能力。通常，数据是按对象分区的，如邮箱、用户帐户或生产线等。在某些应用程序中分区是按时间进行的，例如按天或按季度。也可能用随机分区的方法分布对象。拆分和合并分区需要工具，最好是联机的（不用中断服务），符合系统变化的需要。增加宿主分区的服务器数量，提高了服务的可伸缩性。不过，分区的选择将决定访问模式及其产生的负荷。甚至在分布请求时也要避免出现热点（一个分区接收的请求数量不成比例），这对设计数据分区也很重要。有时这很难避免，而且必须有大型多处理器系统宿主分区。分区故障转移，即服务自动切换到二级节点（退回未完成的事务），可提供持续的分区可用性。

带状态负荷平衡

如果数据按多个数据服务器分区，或开发提供专用功能的服务器来处理特定类型的 Web 请求，必须编写相应的软件将请求路由到相应的数据分区或专用服务器。通常，该应用程序逻辑是由 Web 服务器运行的。其编制目的是确定相关数据的位置，并且根据客户机请求的内容、客户机 ID 或客户机提供的 cookie 将请求路由到数据分区所在的相应服务器。它还知道提供专用功能的服务器位置并将请求发送到那里进行处理。该应用程序软件完成带状态负荷平衡。称其为带状态的原因是，根据客户机状态或请求中的状态才能决定将请求路由至何方。

后端服务的可用性

除了使用故障转移和群集提高可用性外，整个系统体系结构的一个重要因素，就是站点提供某些有限程度服务的能力，甚至在多种服务失效的情况下。例如，用户应该总能通过用户凭据的复制登录至联机邮件服务，然后使用克隆的“简单邮件传输协议 (SMTP)”路由器发送邮件，即使用户的邮件文件是无效的。相类似，在商务站点中用户应该可以浏览目录，即使暂时不能处理事务。这要求系统体系结构设计者要设计出“当个别部件发生故障时工作可靠但性能下降”的服务，以避免由于局部故障而使终端用户感觉为整个站点故障。

灾难承受能力

某些商务 Web 站点需要持续的服务可用性，即使在灾难发生时：他们的全球商务活动依赖于可用的服务。灾难可能是自然灾害（地震、火灾或洪水），也可能是恶意操作（如恐怖活动或心怀不满的员工）的结果。灾难承受系统要求将站点的副本或部分副本放在离主站点足够远的地方，这样，在整个灾难中失去多个站点的概率会小到可承受的程度。在最高级别有两种复制的站点类型。主动站点分担部分负荷。被动站点在发生灾难后才提供服务。在需要快速故障转移的场合通常使用主动站点。被动站点可能只是由租用服务器和远程的、位于备份磁带所在地的连接组成，这些连接可在需要时应用于上述服务器。像这种最小限度的规划应该为任何商务考虑之列。

更新复制的站点，使它们的内容保持一致是很具挑战性的。此处的基本方法是：将内容从中央升级服务器复制到远程站点的升级服务器，更新每个站点的内容。对于只读内容该方法已足够。但是，对于更多的执行事务的高级站点，还需要保持数据库为最新。数据库复制和日志转移通常用于将对数据库的事务性更新转移到远程站点的地方。典型情况下，数据库将出现几分钟不同步。但是，这比站点完全失效要好。

安全域

安全性机制用于保护敏感信息的保密性和机密性，使其免受未经许可的访问；通过防止未经许可的修改或破坏，保护系统和数据的完整性；并通过防止拒绝服务攻击和提供意外或灾难计划，来帮助确保可用性。

安全域是一致的安全性区域，区域之间有定义明确的保护接口。这一概念的应用程序有助于确保在正确的场合应用正确的保护级别。复杂系统（如大型商务站点及其环境）可划分为多个安全域。区域表示任何所希望的划分 — 例如，按地域、按组织、按物理网络或者服务器或按数据类型。对于商务站点，主要的划分方式可适当按照 Internet、站点的 DMZ、安全性、企业和管理网络。域还可能相互交叉或重叠。例如数据库中的信用卡号码可能需要附加保护。附加的安全性控制，如卡号的加密，可提供这种保护。

下面的比喻有助于形象说明安全域。Internet 好象中世纪的城堡及其周边环境：在其城墙之外，很少有法律约束并有各种不拘一格的个性。根据这个城堡模型，用于保护 Web 站点的关键结构元素是在其周围构筑城墙，有重兵把守的主城门禁止闲杂的人进入。需要构建的城墙及城门等效于维护给定安全级的标准。当然，不会有没有保护的后门！对于大型商务站点，城墙称为站点的边界。在网络术语中，表示站点的内部通信设备是专用的并与 Internet 隔离，指定的入口除外。站点的主城门称作防火墙。防火墙将检测每一通信包，确保只允许希望的信息进入。继续这个比喻，城堡中的要塞保护着皇冠宝石。附加的围墙和加锁的门或墙中墙，提供了附加保护。与此类似，商务站点通过提供附加的防火墙和内部网络，保护着非常敏感的数据。

图 2. 防火墙/DMZ

防火墙是一种控制网络中处于不同可信级别的两部分之间的数据流的机制。防火墙的范围可以从数据包过滤器（只允许指定 IP 端口和/或一系列 IP 地址之间的数据通信）到应用程序级防火墙（实际检查数据的内容并决定是否让其通过）。站点通常将过滤数据包的外向防火墙和过滤协议和端口层数据的内向防火墙结合使用。

保护站点的安全性很复杂，但防火墙/DMZ 是关键结构组件（实际上是网段中的子网）。对于保证期望的站点保护级别，它是必要但绝不充分的安全性机制。本文档的“安全性”章节专门叙述如何保护站点的安全。

管理基础结构

站点管理系统通常构建在单独的网络上，以确保高度可用。管理系统使用单独网络，还可以减轻管理通信量的后端网络的负荷，从而提高整体性能和响应时间。管理和运作有时也使用后端网络，但对于大型的、高可用度的站点，不建议这样做。

管理系统的核心结构组件为管理控制台、管理服务器和管理代理。所有核心组件均可独立扩展。管理控制台是管理员访问和操纵被管理系统的入口。管理服务器时刻监控着所管理的系统、接收报警和通知、记录事件和性能数据，并作为响应预定事件的第一防线。管理代理为在其驻留的设备内部执行主要管理功能的程序。管理代理与管理服务器使用标准的或专用的协议相互通信。

当系统达到一定的规模和变化率时，Web 站点的管理和运作成为关键因素。管理的简便性、易于配置、持续的健康监控和故障检测可能比添加应用程序功能或新服务更为重要。因此，应用程序工程师必须十分熟悉部署和运行应用程序的操作环境。另外，操作人员还必须十分熟悉克隆和分区方案、管理工具和安全机制，以维持持续可用的、基于 Internet 的服务。

示例站点

简介

本示例站点力求通用，以说明核心结构组件和基础结构。但是，它是我们曾讨论过的许多运行站点的关键结构特性的代表。出于竞争和安全原因，站点所有者通常不愿展示其站点的实际详细内幕。

我们的示例以一个大型站点为例，并展示了拓扑结构和组件冗余。它是一个高度可用系统：紧急服务可拯救大部分故障模式，减轻重大灾难。从 ISP 1 到 ISP N 的每个分组中的服务器均支持所有站点紧急处理功能，因此，即使失去一个 ISP 也不会使站点瘫痪。在大部分灾难情况下，提供不间断的服务需要在多个地理位置 (geoplex) 上复制整个站点。Cisco 的“分布式控制器”通常用于支持 geoplex。遗憾的是，站点复制的成本将超出构建站点的两倍，并且可能导致 Web 应用程序的数据一致性问题。

从该示例可派生出较小的和大得多的站点。较小站点可能不需要在每个群集中有如此多的服务器。不需要很高可用性的站点只要删除冗余的元素，特别是图中从 Internet ISP 1 开始的整个上半部分。没有很高数据库安全性的站点可以在安全网络中删除安全 SQL 群集。另一方面，非常大的站点可以添加下列内容充分地扩展：

• 每个 IIS Web 群集的克隆体。
  
  
• Web 群集数量。
  
  
• Internet 连接访问点。
  
  
• 前端组件，如防火墙。

更进一步，随着网络通信量和要管理的设备数量的增加，管理网络也必须增加规模和复杂性。

图 3 展示了示例站点的体系结构。

图 3. 大型 Web 站点网络拓扑结构示例

在图 3 中，不同的线形、粗细和注释显示了网络不同部分的 IP 地址和连接。特别是：

• 外部（面向 Internet）网络（细）。
  
  
• DMZ 网络（中）。
  
  
• 安全（内部）网络（粗）。
  
  
• 管理网络（细虚线）。
  
  
• 群集核心专用网络（细 — 每个群集本地专用）。
  
  
• 与企业网的连接（闪电状）。

本节的其他内容将提供示例站点的教程，从 Internet 开始经 DMZ 直到安全网络，包括企业网和管理网络。

Internet

教程从连接一个或多个“Internet 服务提供商 (ISP)”开始。我们的示例列举了多个标记为 ISP 1 - ISP N 的冗余连接。这些连接应该来自不同（物理上独立）的网络。域名服务器（DNS，图 3 中没有展示）提供了域名与一个或多个 TCP/IP 地址之间的正向和反向映射。例如，http://www.microsoft.com/ 当前映射下列地址，每组地址均为一个群集。

207.46.130.14      207.46.131.28

207.46.130.149    207.46.131.30

207.46.130.150    207.46.131.137

如果有多个 IP 地址，DNS 将浏览地址列表来处理对 www.microsoft.com IP 地址的不断查询 — 因此，得名为“Round Robin DNS (RRDNS)”。RRDNS 的缺点是不能检测出 ISP 连接的消失而继续为不再工作的 IP 地址提供服务。但是这并不非常严重，因为用户只需请求重载 Web 页。第三方解决方案，如 Cisco 的 Local Director或 F5 Networks 的 BigIP 提供了动态路由连接的更好解决方案。

DMZ

前端网络上的服务器是面向 Internet 的。防火墙是基本的安全性组件，通过按数据包类型、源和目的地址过滤数据通信量，来提供网络隔离。它们形成了由双向箭头描述的 DMZ（非军事区）边界。

防火墙

路径中的第一个组件就是路由器/防火墙，它们的功能是截然不同的或组合在一个设备中。面向 Internet 的路由器支持“边界网关协议”(http://www.ietf.org/rfc/rfc1654.txt)。高速前端交换机支持到前端 Web 群集中的每台服务器的连接。与路由器/防火墙的交叉连接为在 ISP 连接失效时，或路径上任何组件失效时，提供了另一条路径。

前端网络

前端提供核心 Web 服务，如 HTTP/HTTPS，使用 Microsoft Internet Information Server (IIS) 提供 HTML 和 ASP 页面服务，使用 LDAP（Lightweight Directory Access Protocol）进行用户身份验证。还可以将“站点服务器商业版”装载到前端服务器上，以提供附加的数据库驱动的服务。

前端服务器按服务和功能分组 — 例如 http://www.microsoft.com/、http://search.microsoft.com/、SMTP（电子邮件）或 FTP（下载）。SSL 服务 (HTTPS) 同样是从普通 HTTP 通信中隔离出来的。这使得经过特殊配置的、带有高成本的硬件安全加速器模块的服务器，可支持高速加密功能。更进一步，SSL 会话继承了带状态性，并可能需要特殊的故障转移处理。

在示例站点中运行 Windows 2000 的每个 Web 群集均使用 NLBS（网络负荷平衡服务 — 在 Windows NT 中也称为 Windows 负荷平衡服务）。每个克隆体在每个发布相同内容的 NLBS Web 群集中有相同的配置。这将为无状态 Web 应用程序提供透明的故障转移，与单个服务器相比从根本上提高了服务能力。Web 群集通过添加克隆体分担群集的负荷来支持广阔的可伸缩性。

客户机向使用虚拟 IP 地址的每个 Web 群集提出请求，该虚拟 IP 地址是 NLBS 群集中的所有前端服务器均可以响应的。前端服务器则访问位于后端群集文件共享服务器和后端群集 SQL 服务器上的站点内容。

提供 Web 服务所需的所有 COM 对象，包括从 ASP 页调用的对象，均安装并注册在每个前端服务器上。该站点的 ASP 页可以装载在前端服务器的本地磁盘上，也可以保持在后端群集文件共享服务器上。

每个前端服务器均特殊加强了安全性并连接到三个网络：

• 前端网络 — Internet 访问。
  
  
• 后端网络 — 访问 DMZ 服务器，并通过内部防火墙访问安全网络。
  
  
• 管理网络 — 支持管理和运作功能。

这种网络隔离，在提高总体可用带宽和冗余的同时提高了安全性。

注意该站点中任何服务器上唯一可公共访问的 IP 地址为 NLBS 虚拟 IP 地址，只有前端服务器才可以响应的这个地址。用于面向 Internet 的 NIC（网络接口卡）的 IP 过滤，可确保只有被支持的功能的正确通信类型和源，才能进入前端服务器。这些网络之间的 IP 转发也已禁用。

后端网络

后端网络通过使用高速、私用的 10.10.1.x LAN 支持所有 DMZ 服务器。这种体系结构可防止从 Internet 直接访问 DMZ 服务器，即使防火墙被突破，因为不允许 Internet 路由器转发指定的 IP 地址范围（请参阅 http://www.ietf.org/rfc/rfc1918.txt 上的 Address Allocation for Private Internets（专用 Internet 的地址分配）），包括范围 10.x.x.x。当使用前端网络时，冗余交换机可提供对所有前端和后端服务器的访问。所有后端交换机共享公共网络，因此后端通信量负荷将成为主动站点的问题，特别是单独的管理网络不能进行记录并且其他前端管理网络还在通信。

后端网络的主要组件为加强了安全性的服务器群集，它们提供对 Web 内容和临时永久状态，如会话内事务性数据（例如购物推车内容），的存储服务。由于所有永久数据随处可得，因此没有必要提供备份工具。通过添加群集和分区数据库可实现可伸缩性。

这些服务器使用了 Windows 2000 上的“Microsoft 群集服务”，实现了带故障转移能力的高度可用性。一个服务器失效不会导致数据服务的失效甚至服务的中断。当失效的服务器恢复联机时，可以继续数据服务。由于硬盘的确会失效，因此使用 RAID 驱动器阵列可提供必要的数据冗余保护。

群集内的文件共享支持文件存储服务。群集上运行的 Microsoft SQL Server 提供数据库服务。每个群集服务器至少使用了四个 NIC：一个用于每个交换机、一个用于专用核心 LAN（应该使用其他专用网络地址，如 192.168.10.x）、一个用于管理 LAN。除服务器物理地址外，群集还具有多个虚拟 IP 地址，以支持群集本身和每个群集服务地址对（用于冗余）。

加强 DMZ 实用程序 DC 的服务器支持所有 DMZ 服务器的本地域帐户、本地 DHCP 和名称服务（WINS，或最好为 DNS）以及本地实用程序文件服务。对内部企业域的单向信任关系，提供了对安全的内部系统的身份验证式访问。

安全网络

另一道防火墙形成了 DMZ 的内部边界，并将所谓的安全网络与后端网络隔离开。防火墙配置成只允许端口与源/目的对之间所要求的通信。安全网络又由一个专用网络（本例中为 10.10.2.0）、一对耦合的交换机、各种服务器和标记为 VPN/路由器的设备组成，这个标记为 VPN/路由器的设备提供了与内部企业网的连接。安全网络在逻辑上为企业网的一部分。安全网络上的服务器通常也是内部企业域的成员，因此域控制器和地址及名称服务器也假定是内部的。

为了支持其他功能，在本节中可能还需要其他服务器。有多种可能的处理方法，然后在安全性数据存储与内部系统之间传输事务性数据。事务的范围是从传统的同步 (MTS — Microsoft Transaction Service) 到异步 (MSMQ - Microsoft Message Queue) 乃至基于批处理或基于电子邮件的存储和转寄。这些内容已超出本文档的范围。

但请注意，对于许多组织来说，Internet 是许多通道中唯一提供用户服务的传送通道，这很重要。以书店或银行为例。大部分业务逻辑和处理发生在内部的现有系统内。Internet 解决方案必须与这些现有系统协作并为其提供服务。

安全数据存储

安全 SQL 群集是可选的，并只为更复杂的事务性站点中所需。它们提供了高度可用性、身份验证数据库的永久存储、长期事务存储，并保证客户信息和帐户数据的机密性。与 DMZ 中的服务器群集不同，这些服务器必须备份，既可以使用直接连接的可移动存储设备，也可以通过企业网进行备份。其他功能与 DMZ 群集类似。为了冗余，每个服务器将重复连接到安全网络的两个交换机上。同样又是通过分区数据库和添加群集，来实现可伸缩性。

升级服务器

升级服务器出现在安全网络部分，尽管它们可能位于企业网或甚至位于 DMZ 中。它们接受和升级来自企业网或外部内容提供商的内容，然后将内容部署到 Web 服务器，以使站点保持一致状态。通常有很多机制可用，包括 Microsoft Content Replication（Microsoft 内容复制系统）和诸如 RoboCopy 等工具。

企业网连通性

示为 VPN/路由器的、将站点与企业网相连的设备实际上是个路由器，如果需要，它可以和 VPN 安全性功能结合，来签署和加密通信。另外，使用 Windows 2000 内置 IPSec 特性也可添加 VPN 功能。这将在根据需求的基础上支持端对端的安全性，这样可以节约 VPN 硬件支持的成本。

就企业数据中心中宿主的站点而言，连接企业网易如反掌。在这种情况下，VPN/路由器直接与企业网相连。

大型商务站点经常由远程的企业数据中心宿主。专用热线经常用来连接站点与企业网，特别是在需要高性能、低响应时间的情况。另外，Internet 本身也可能用于传输，这种情况下使用 VPN 技术确保所有通信的安全非常重要。

管理网络连通性

我们以管理网络的讨论来结束我们的教程，管理网络提供了监控和管理站点的基本功能。为简单起见，我们只演示用 LAN 连接单独管理网络的计算机。这些是用单独的 NIC 实现的。某些站点没有使用单独的管理网络。相反，它们瓦解后端网络上的管理通信。为安全性、网络负荷和管理起见，我们不建议这样做。

与路由器、交换机和防火墙的管理连接没有显示。用于紧急带外 (OOB) 访问的串口拨号连接也没有显示。这并不表示不需要它们。当管理网络（或用于管理的后端网络）不可用时，仍然可以通过这种设置访问每个主机。

摘要

下面章节使用前例的模型，详细讨论本文档所描述的体系结构如何满足这四个目标：

• 线性可伸缩性 — 可持续增长以满足用户需求和业务复杂性。
  
  
• 持续服务可用性 — 使用冗余和功能专业化来提高容错能力。
  
  
• 数据和基础结构的安全性 — 保护数据和基础结构免受恶意攻击或盗用。
  
  
• 管理的简便性和完整性 — 确保运作能够满足增长的需求。

可伸缩性

简介

图 4 例举了站点可伸缩性的两个不同维度。第一个维度，即水平轴，表示在有代表性的一天，访问站点的独特客户机的数量。随着独特客户数量的增加，配置用于支持增加的客户库的系统数量也将增加。典型情况下，支持客户库所需的站点上的内容也必须增加。

第二个维度，即垂直轴，表示站点的业务复杂性程度。我们已经标识了三个主要类别。当然，在它们之间还有许多变种。类别之间通常通过包含下级分类的功能而互为基础。最底层分类，和在业务逻辑复杂方面最简单的，是内容提供商类。上一层的分类，除来内容外还有事务处理，但许多业务处理是脱机完成的。而最上层的分类既有内容还有事务，而且许多业务处理逻辑完全集成在联机处理中。

随着站点在图中从左到右、从下向上移动，站点的运行和应用程序部署的难度明显增加。

图 4. 扩展维度

在本节的其余部分，我们考虑图 4 环境中的可伸缩性。首先，我们关注扩展独特客户和内容，然后再看业务复杂性的增加。

扩展客户和内容

接下来的图 5 和图 6 两个图例，说明了前端系统的数量如何变化，以满足客户不断增长的需求，以及如何增加分区的数据存储的数量来扩展联机内容。

（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）

图 5. 小型站点

上图表示了具有一个 IIS Web 服务器，一个文件或 SQL Server 和一个在 DMZ 内的实用程序服务器的基本站点，它连接安全 SQL Server 或文件服务器和安全升级服务器。下图表示，如图 5 所示的小型站点，应如何扩大才能支持更多客户和更多内容。

（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）

图 6. 扩大的站点

在前端，IIS Web 服务器的数量和这些服务器的 Web 群集的数量有所增加，并使用 NLBS 在它们之间平衡了负荷。在后端，文件服务器和 SQL Server 群集的数量有所增加，因此，逻辑需要包括在前端 Web 服务器中，才能将数据请求路由到正确的后端数据分区。我们下一步再说明这两种技术。

扩展前端系统

增加克隆的 IIS Web 服务器的数量、将其分组为 Web 群集和使用负荷平衡系统，是增加支持的独特客户数量的主要技术。但请注意，这涉及重要的应用程序状态考虑，我们将在后面讨论。

除增加 IIS Web 服务器的数量外，优化 Web 服务器执行的 Web 应用程序代码也很重要（这超出了本文档的范围）。

针对可伸缩性的 Web 前端负荷平衡

负荷平衡以虚拟 IP 地址的形式，向客户机提供了单一的服务名称，然后将客户机分布于提供该服务的服务器集上。

进行负荷平衡有三种主要技术：

• Round Robin DNS (RRDNS)。
  
  
• 带有专用的第三方外挂盒的智能 IP 负荷平衡。
  
  
• 服务器内部使用 Windows 2000 的 NLBS 的智能 IP 负荷平衡。

RRDNS 是配置“域名服务器 (DNS)”的一种方法，以使 DNS 对主机名的查询在一系列提供相同服务的 IP 地址中顺序分布。这是负荷平衡的基本形式。该方法的优点是：无成本、易于实现，并且不需要变动服务器。缺点是：没有关于单个服务器负荷或可用性的反馈机制，并且由于 DNS 更改的传播延迟导致将请求继续发往故障的服务器，从而没有办法从可用的服务器集中快速删除故障的服务器。

基于服务器的负荷平衡将一组服务器组成 NLBS 群集，然后令群集中的每个服务器根据源的 IP 地址决定是否处理该请求，来完成负荷平衡。如果群集中的一个服务器故障，则群集中的其他成员重新分组并调整源 IP 地址范围的分区。NLBS 的优点是低成本（NLBS 是 Windows 2000 操作系统的一部分），不需要特殊硬件或更改网络基础结构，而且没有单个故障点。目前的限制是服务器不能动态调整负荷，重组是根据服务器故障进行的而不是根据应用程序失效进行的（尽管第三方工具，如 NetIQ 和 Microsoft 的 HTTPMon，可用于削弱这些限制）。

将 RRDNS 与 NLBS 组合可产生更好的扩展和可用的配置。NLBS 群集中的所有节点必须在同一 LAN 子网上，并响应同一 IP 地址。配置不同子网上的多个 NLBS 群集，并将 DNS 配置为在多个 NBLS 群集顺序分布请求，是可能的。这增强了 NLBS 的可伸缩性并避免了 RRDNS 的缺点，因为有多台计算机可用于响应发往每个 NLBS 群集的每个请求。Microsoft.com 便以这种方式工作。

图 7. RRDNS & NLBS：三个独立 LAN 网段，一个域名

应用程序状态考虑

为了向客户机屏蔽服务器故障，请不要将应用程序客户机状态存储在 IIS Web 服务器上。不能动态平衡客户机请求的负荷。最好是将客户机状态存储在数据存储器中，并在需要时，根据 URL 编码数据或客户机 cookie，对每个客户机请求检索客户机状态。带客户机高速缓存的 cookie 也是一种很有效的扩展方法，该方法在每个客户机系统中存储各自客户机的信息，在每个客户机请求中向 Web 服务器发送该信息，并使用该数据将内容专用化或采用其他客户机指定的操作。RFC 2109（“HTTP State Management Mechanism”（HTTP 状态管理机制），可从 www.ietf.org/rfc/rfc2109.txt 中找到）描述了 HTTP cookie 协议。

但是，某些应用程序和协议要求长期的从客户机到服务器的连接。使用“Secure Sockets Layer (SSL)”发送加密数据并验证服务器身份，就是一个主要示例。大部分 IP 负荷平衡产品支持允许应用程序或协议维持与同一服务器的连接机制，以便它们正常工作，尽管没有故障透明性。

扩展后端系统

增加多处理器系统的内存和处理器可扩展后端系统。Windows 2000 Advanced Server 操作系统支持多达 8 CPU 和 8 GB 内存。但是，在某些情况这不再可能，或不希望对单个系统的可用性有如此大的数据依赖性。基于这一点，通过对其服务的数据或提供的逻辑服务进行分区，来扩展后端系统，是十分必要的。我们将此称为分区。与用于扩展前端系统的克隆（复制硬件、软件和数据）不同，分区只复制硬件和软件，而将数据分布在各个节点。对特定数据对象的请求则需要路由到存储相应数据的正确分区。这种由数据决定的路由，需要运行在 Web 服务器上的应用程序软件来完成。可将由数据决定的路由层视为：与无状态负荷平衡相对的带状态负荷平衡，前者用于克隆前端系统的扩展。还需要开发管理分区的拆分和合并的软件，以使负荷均匀分散在所有分区之上，这样可避免任何单个分区成为热点。

但是，这种责任通常落在应用程序工程师头上，他们将数据分散在业务对象上，而随着数据大小和工作量的不断增长，业务对象也将均匀分布在数量不断增加的服务器上。幸运的是，如前所述，许多站点服务按对象分区相对简单。但是，分区对象尺度选择在站点部署完成后很难更改，这使得升级设计决断尤为重要。

扩展的另一个方法是将后端系统提供的服务，分区为向客户机提供服务的功能专业化系统。这通常称为 n 层模型。我们将在下面有关扩展业务复杂性的章节里详细讨论它。

扩展网络基础结构

随着站点通信量（包括从 Internet 和 DMZ 内的内部通信，到企业网络的）的增加，网络基础结构也必须改进。为了支持这种增长的需求，必须增加链接带宽、将集线器升级为交换机以及安装附加网络（例如，增设专用的管理网络，以减轻后端网络的负荷）。

扩展业务复杂性

下图说明了随着集成到系统的业务过程数量的增长和业务过程联机性的增长，对系统安全性和数量的需求也随之增长。最大系统容量 — 系统设计能否随着业务增长而平稳迅速增长 — 通常是任何站点最为关注的。

站点复杂性的三种模型是：“内容提供商”、“脱机事务处理”和“联机事务处理”。

内容提供商。在这个模型中，不需要访问内部网络的事务处理。所有 Web 服务和内容服务器都来自 DMZ 内部。所有内容先装配在升级服务器上，然后再通过复制推入 DMZ 服务器。如前一节所述，通过增加 Web 群集、增加 Web 群集的克隆、增加后端群集服务器，可扩展该模型。

（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）

图 8. “内容提供商”模型

脱机事务处理。本模型同“内容提供商”模型类似，但附加了对内部网络上已有业务应用程序的脱机事务处理访问。在“内容提供商”模型中，复制用于从升级服务器更新 DMZ 服务器内容。为了支持脱机（非实时）事务处理，需要将事务数据从 DMZ 异步传输到内部网络。“Microsoft 消息队列 (MSMQ)”服务可用于可靠传输这些脱机事务。为了支持传统的交付通道，应用程序系统和数据库都要在内部网络上实现。标记为“其他交付通道”的设备代表传统的表达设备，如客户工作站、交互式语音应答单元 (IVRU) 或专用输入设备，如销售点终端或 ATM。该模型的复杂性，随着与内部防火墙后面的内部网络中后端服务器交互数量的增加而增加。MSMQ 既能支持异步通讯又能保证消息可靠传递，所以对这种类型的交互很有用。批量处理请求也是分摊给内部网络发送消息的成本的另一个成功技术。

（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）

图 9. “脱机事务处理”模型

联机事务处理。在此模型中，Web 浏览器真正联机访问驻留在内部网络上的传统应用程序。业务应用程序的功能是在内部网络上实现的，它通常支持多个交付通道。从 DMZ 到内部网络的事务通讯是用标准同步通讯机制实现的。在连接客户机时，与联机业务应用程序集成的需求，大大增加了该模型的复杂性。本模型最为复杂并且难于扩展，因为与内部系统的交互必须同步操作，或至少在客户正与联机服务交互时。这些交互类型需要认真设计，并且尽量减少其数量。例如，购物篮只能用 DMZ 内部的交互来扩大，而且只能在客户请求之后；实际的购买应当使用内部系统。

（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）

图 10. “联机事务处理”模型

可用性

简介

增加站点可用性的主要技术是增加冗余组件。这些冗余组件可用于创建多个通信路径、多个提供相同服务的服务器、以及在事件中替代故障服务器的备用服务器。

考虑下面两图。第一幅在前端系统和后端系统中具有某种高度的可用性。而第二幅具有所有组件和网络链路的冗余。

（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）

图 11. 使用某些冗余的中型站点

在图 11 中，我们有两个 Web 群集，每个都有多个服务器，并且我们有两个服务器群集，每个均配置为使用“Microsoft 群集服务”的故障转移群集。我们在下面的章节中讨论增加服务可用性的基础构件。

（如果您的浏览器不支持inline frames，请点击这里在单独的页面观看此图）

图 12. 使用完全冗余的大型站点

在使用完全冗余的大型站点中，不仅有多个 Web 群集，而且每个服务器都配置为使用“Microsoft 群集服务”的故障转移群集。另外，还有与多个 ISP 的连接和独立的管理网络。

前端系统的可用性

如第四节中关于可伸缩性的描述指出的那样，当克隆技术与 NLBS 负载平衡和无状态 Web 服务器的使用相耦合时，克隆技术可用于提供高度可用的前端 Web 服务。如前所述，如果用 Round Robin DNS 配置多个 NLBS Web 群集，还可使 Web 服务器从网络基础结构故障中恢复。

在“可伸缩性”一节中已阐明了基本的思想，以及附加的要求，即在克隆失败或运行于克隆体的 Web 服务器停止响应时，负载平衡系统必须从 Web 群集删除克隆体直至其修复。NLBS 自动跟踪 Web 群集的运作成员并在其中的某个出现故障时重组。当 Windows 2000 上的 IIS Web 服务器故障时，将自动重新启动。但是当 IIS Web 服务器挂起时，则必须通过监控工具检测。Microsoft 的 HTTPMon 或第三方工具如 NetIQ (http://www.netiq.com/) 都能编写脚本完成这个工作。

网络基础结构的可用性

网络基础结构和站点与 Internet 连接的持续可用至关重要。如示例站点所示，首要技术是通过多个 ISP 拥有多个 Internet 连接。连接应该是不同的；即，从提供者到用户所在地通信工具应使用物理上独立的路径。这样就消除了因断线引起的站点故障 — 这种情况并不罕见。

为获得最大的可用性，还应考虑使用不同的电源和余富的不间断电源。基础结构中的多样性常常是宿主站点的一个主要魅力，其便利在于专门提供了配以多家 ISP 的宿主服务。

在站点内，交换机和路由器应以这样的方式相互连接，即每个服务总有多条路径与之连接。最后，如在“管理与运作”一节中所述，单独的管理网络和带外网络，对于各种网络基础结构故障情况下的管理性能和恢复功能很重要。

后端系统的可用性

通过 “Microsoft 群集服务”可使后端系统高度可用，该服务是为群集上运行的服务提供数据层冗余和故障转移功能的核心技术。“Microsoft 群集服务”使多个 SQL 数据库和文件共享可共享 RAID 设备，这样如果主文件或数据库服务器故障，将有备份服务器自动在线以替代其地位。如 NLBS 一样，利用该系统级服务不需要专门的编程。

数据库和 Web 内容的数据，都需要存储在 RAID 磁盘阵列上进一步保护。如果硬盘发生故障，数据将持续可用，并且运行的硬盘可在不中断服务的情况下和磁盘阵列进行热交换。

后端服务器之间将定期发送称为心跳的消息，来检测故障应用程序或服务器。心跳在专用网络（如群集心跳网络所示）上通过专用 NIC 发送。如果某一台服务器检测到心跳网络通讯故障，它将请求群集状态确认。如果另一台服务器没有响应，则自动将故障服务器的资源（如磁盘设备和 IP 地址）的所有权转移给幸存服务器。然后，在幸存服务器上重新启动故障服务器的工作。如果个别应用程序故障（不是服务器故障），“Microsoft 群集服务”通常将在同一服务器上重新启动该应用程序。如果失败，“Microsoft 群集服务”将转移应用程序资源，然后在另一台服务器上重新启动。

安全性

简介

安全性即通过充分保护信息的机密性、秘密性、完整性和可用性来管理风险。安全性机制和服务，如加密、身份验证、授权、责任和管理，都支持这个目标。由于保护机制永远不会是完美的，所以检测机制（监控和审核）将在可能的入侵发生时产生报警或触发响应（纠正操作）。

安全域概念，如“体系结构概述”中所述，对于保证策略一致性和最经济的安全性控制应用程序是无价的。在域中，安全性如同一条链子，它的力量与其不牢固的链接一样。在整个域的应用一致的控制是必要的，整个域可能包含网络、平台和应用程序层以及域中所有功能和组件。需要在低安全性的域的边界补偿控制将安全性提高到需要的程度。

保护站点的第一步是分析商业风险、被保护系统和数据的自然情况以及可用安全性机制的成本，然后确定最优商业方案。

通常，商业站点应该比只用于浏览的信息站点具有更高的保护。许多商业站点包括多个有不同安全性需要的功能。没有必要对整个站点应用最高安全性的保护。通过把这些复杂的站点分隔为安全域，可以有选择地实现最高安全性保护，这可能是昂贵的。

安全性策略和物理的安全性程序是有效的安全性程序的重要方面。此外，尽管大型站点固有的复杂性或由安全控制附加的复杂性，实现最简单的用户和管理接口是很重要的。复杂性引起错误配置和避免。在可行的场合尽可能实现基于策略的安全管理和配置自动化。由于本文的重点是关于安全的体系结构和技术，因此我们不会进一步讲述这个问题。但是，重要的是注意到有效的安全性不只是一个人和方法问题。如果人们没有意识到安全性需求或认为无关紧要，那么最好的技术也是没有用的。

在本节的其余部分，我们将讨论多种保护机制，包括网络和平台保护。（应用程序保护超出了本文的范围。）接下来我们考虑复杂的 Web 应用程序所需的客户身份验证和授权。

网络保护

DMZ 结构

示例站点说明了防火墙和 DMZ 的应用。MDZ 是在 Internet 和内部系统资源之间提供多层保护的重要体系结构元素。它包含：

• 面向 Internet 的防火墙，它过滤 Internet 通信并将其从 DMZ 中的网络通信分离。
  
  
• DMZ 中支持所需服务的特殊功能和高度安全性（加固的）组件，如 Web 或电子邮件服务。
  
  
• 面向内部的防火墙，它从安全的内部网络中分离出 DMZ 通信，同时对这些网络中有限数量的加固系统和服务提供可控制的访问。

面向 Internet 的防火墙在实际中广为使用（尽管常以安全性路由器的形式）。允许与公司或其他安全网络进行网络连接的所有 Web 站点，还应该使用内部防火墙，将 DMZ 与内部网络隔离。

对于保护站点 DMZ 是必要的，但在自身内部并不是足够的。DMZ 中的任何组件一旦被突破，均可用于攻击整个站点。敏感的客户和帐户信息以及身份验证/授权数据库，不应放置在 DMZ 中，而应放在安全的内部网络加以保护。性能方面的考虑也许增强了将敏感数据复制到 DMZ 的需要。如“平台保护”一节讨论的，利用其他机制提高数据安全性是必要的。

防火墙类型

防火墙通常在网络协议层发挥功能，并将许可的源/目的 IP 地址和端口（协议，如 HTTP 或 SMTP）之外的所有网络通信排除在外。

最简单的方式是，可从配置了正确的“访问控制列表 (ACL)”的网络路由器建立防火墙。这种安全性路由器实际上经常用作防火墙。它们能过滤不想要的通信（根据协议类型和源及目的地址），并保护 DMZ 不受部分 — 而非全部 — 服务拒绝的攻击。某些站点由于性能原因使用路由器，因为非常复杂的防火墙不能支持所需的吞吐量（有时在每秒上千兆的范围）。低风险站点也可能由于成本原因选择配置安全性路由器。

通过维护通讯状态，数据包屏蔽或带状态的防火墙提供完全的网络层隔离。它们能检测已知的服务拒绝的攻击，并提供附加的安全功能，如网络地址转换（NAT，它完全隐藏内部设备）以及 FTP（动态选择数据传输端口）。常用的防火墙包括 Cisco 的 PIX 或 Check Point 的 Firewall-1。这些设备现在都能支持每秒超过 150 兆的吞吐量。

不过防火墙不是万能的。由于它们一般都在网络层发挥功能，因此不能防止较高协议层的攻击。例如，在不能正确检查进来的字符串的 DMZ 内，应用程序或 Web 服务器很容易受到缓冲区溢出的攻击。这会导致服务的崩溃或恶化，会让解密高手得以控制组件。遗憾的是，这种本事比想象的更为普遍。

防火墙配置

面向 Internet 的防火墙，应该只许访问支持 Web 站点商业功能所需的服务，典型的如 HTTP 和 LDAP，以及不常用的 FTP 和 SMTP 邮件。支持有限的商业对商业或其他远程服务的虚拟专用网络 (VPN) 也可能是需要的。认真审查并禁止开放访问所有的端口，除非有强烈的商业要求必须如此。用于构造防火墙的现用平台（例如，Windows 2000 和 Checkpoint 的 Firewall-1）必须是极其坚固的。

根据支持访问内部数据和系统资源，以及支持和管理 DMZ 组件所需的协议和服务，面向内部的防火墙同样应该对通信进行限制。如果解密高手设法穿过 DMZ，内部防火墙则是保护内部网络的关键信息资源的重要手段。穿越内部防火墙所需的端口和地址的数量及种类，往往比外部防火墙的还多，尤其是通过 DMZ 后端网络来支持管理功能。得以访问内部网络是解密高手的首要目标。限制为只能访问极有限的几组必要端口和目标主机非常重要，这样才能确保 DMZ 中的泄密系统只有有限的机会攻击内部网络。

网络隔离

出于安全性，DMZ 中的内部数据网应该隔离，同时增加带宽。通常每台计算机装配了两块以上网络接口卡 (NIC)。示例站点一节说明了网络分段并进行了一定的讨论。关键原则是：

• 将不同 Internet 通信类型隔离为不同的 Web 群集 — 例如，HTTP、HTTPS 和 FTP。然后，每个群集可配置为拒绝传输服务所需的类型以外的数据。
  
  
• 将 Internet 通信与后端通信隔离。这样防止从 Internet 直接访问内部网络，并且允许为每个 NIC 配置过滤器，从而将通信限制为只适合服务器所需的类型。
  
  
• 如示例站点中所述，为内部 Web 站点网络使用非路由的网络地址。
  
  
• 为了将管理通信与所有其他通信隔离，我们采用了管理网络。也可配置 NIC 过滤器，以限制只适用于 NIC 的通信。还应将强大的管理功能限制为管理网络而不能穿越服务网络。它还消除了管理通信穿越防火墙，这大大减少了弱点。管理 LAN 本身的安全至关紧要。

HTTPS — 用于加密的 SSL

在 Internet 上发送数据如同通过邮政发送明信片：沿途的任何人都能截取。因此，标准的安全通信通道对于通过公共网络传递敏感客户信息的 Web 站点和其他应用程序非常重要。Secure Sockets Layer (SSL) 与 HTTPS 协议和服务器认证相结合，提供所需的加密功能以及 Web 服务器身份验证。很重要的一点是，了解 SSL 只能保护传输中的通信而不能替代其他站点安全机制。

服务器身份验证对客户端是透明的，因为目前使用的大部分 Web 浏览器可自动验证所有主要认证权威机构颁发的认证。对用户来讲知道与正确的站点而不是别人伪装的站点进行通信很明显是重要的。

SSL 加密为传输数据提供机密性和完整性，这对保护用户口令和信用卡信息尤其重要。由于美国商业部 (DOC) 施加的出口限制，目前有两个加密版本。使用 128 位密钥的较强版本，可在美国和国际上指定行业（如银行业和健康卫生行业）自由使用。对于其他用户，出口加密软件限制在 56 位。

SSL 的确存在问题。首先，SSL 是带状态的。在安全会话的创建和过程中必须维护状态，这增加了前端负载平衡系统的会话相关性需求。其次，加密/解密对 Web 服务器是高强度计算，可能没有足够的处理器周期在软件中支持这个功能。硬件加速器可减轻服务器负载，但成本很高，而且只部署在有限的前端服务器。换句话说，HTTPS 通常从 HTTP 隔离出来，并由特殊的前端服务器支持。由于这些原因，SSL 的使用限制在那些确实需要这一级保护的通信中。

入侵检测

入侵检测系统 (IDS)，如 Cisco 的 NetRanger 或 ISS 的 RealSecure，提供对网络通信的实时监控。IDS 能检测广泛的敌对攻击签名（模式），能产生报警警告操作人员，并在某些情况下使路由器停止与敌对源的通信。

部署某些入侵检测形式对于高度安全的环境很重要，这与在“安全性，简介”一节讨论的通过“预防、检测和反抗”实现安全的方法一致。IDS 传感器应该安装在每个不同的网络，甚至在防火墙或边界路由器之前。这些传感器与管理控制台通信，将在本文后面的“管理与运作”一节讲述。

遗憾的是，有几个原因导致 IDS 仍未普遍使用：

• 性能 — 对非常高性能的网络进行实时监控仍不可行。
  
  
• 错误接受，错误拒绝 — IDS 从正常网络通信中区分攻击的能力正在提高，但还远远不够。IDS 管理器由于低信噪比而淹没在记录中。
  
  
• 成本 — IDS 的实现和运作的成本很高。

还有些其他技术可用于入侵检测 — 例如，将 telnet 端口通信路由到某一陷阱或专用的服务器。虽然可能来不及防止它们了，但使用第三方服务器日志分析工具可提供有关入侵信息。Cisco 在其某些可用于检测网络入侵的路由器上提供了 NetFlows 功能，但当前没有很好的分析工具支持。遗憾的是入侵检测技巧的状态还没有很好开发。

平台保护

加固组件

加固是保护单独服务器操作系统的另一个重要方式。所有的 DMZ 及其与之通信的内部系统都需要加固。这包括严密限定和配置所有使用 ACL 资源（例如，文件和注册项）的访问权限，取消支持业务功能及计算机管理不需要的协议、服务和实用工具。必须严加注意安全和审查的设置。

TCP/IP 协议堆栈应该在可行的地方使用过滤器。Windows 2000 中的 IPSec（IP 安全）实现有很多成熟完善的过滤策略，即使每有使用其完整性和加密功能。无需重新启动，按 IP 地址/子网进行有选择的端口防范是可行的。所有的过滤都在底层进行，所以诸如 IIS 之类的服务根本看不到信息包。

Service Pack 4 for Windows NT 4.0 配发的“安全配置编辑器”(SCE) 是实现一致的、基于策略的控制的重要新工具。Windows 2000 增加了“组策略编辑器”(GPE)，它将该功能（及更多功能）扩展到域、活动目录组织单位甚至计算机组。现在，大多数操作系统的安全配置设置可在策略模板集中定义。这些模板可针对各类机器构造，并对站点内所有的计算机系统地实现。由于这些模板应实施产品计算机的紧密防范，所以最好另外构建一套模板用于维护和诊断。相关的分析功能允许对服务器的当前安全配置按策略进行分析和验证，这是验证持续符合策略的重要方法。

第三方网络和系统安全扫描工具，是保证站点服务器的有效安全配置的另一个重要的辅助内容。厂商提供的著名产品如 Internet Security System (ISS — http://www.iss.net/)（英文）和 Network Associates (http://www.nai.com/)（英文）包括广泛的攻击情形，以提供对网络和系统弱点的评估。

为了得知解密高手的最新本事和紧跟安全防卫潮流所需的补丁程序，留心各方面的安全警示，如来自 CERT (http://www.cert.org/)（英文）的，是必要的。Microsoft 为其产品提供电子邮件安全公告。（管理员可以在 http://www.microsoft.com/security/（英文） 上注册该服务。）

关键服务组件，如域控制器、域名服务、Internet 信息服务器和 Microsoft SQL Server 都有特殊的附加需求。可在 http://www.microsoft.com/security/（英文） 找到一个配置 Windows NT 4.0 / IIS 4.0 Server 的出色而完整的安全校验表。许多 Windows NT 配置项同样可应用于 Windows 2000 和其他 DMZ 主机。

监控

必须定期监控（审查）平台，以保证配置和策略不会偏离最初的安全配置。许多日志和工具都提供了这一功能，包括 Windows 2000 事件日志、IIS 日志、安全配置和分析以及 sysdiff（NT 资源工具包）。Windows 2000 使用代码签名和 System File Checker（系统文件检查器）验证重要系统模块的完整性。大量的第三方工具都支持完整性检查，包括不同来源的防病毒扫描器和 Tripwire 的 tripwire (http://www.tripwiresecurity.com/)（英文），其验证所选的文件和注册设置。

为保证访问权限根据站点策略只可用于有授权的人，定期审查管理员、组和服务帐户也很重要。对只有相对少量帐户的站点而言，这不过是个简单的手动过程。

Windows 域结构

站点区由多类服务器组成，每一类都包含大量的设备。特大型的站点可能包含上千的服务器。单独的后端网络通常支持 DMZ 内的所有服务器。由于支持站点所需的管理和服务帐户很少，所以单域结构适于管理所有 DMZ 服务器帐户。支持到安全网络和内部服务器及其数据库的身份验证，可能需要与内部域的单向信任关系。Windows 2000 通过企业的活动目录提供灵活站点帐户集成，同时支持站点的高度安全需要。

保护站点数据的安全

保护数据完整性和机密性的安全机制包括，网络和系统访问控制、加密和核查或监控工具。

首先需要对站点的可用数据进行分类，如程序和 HTML 代码；客户信息包括口令或其他身份验证/授权；广告；产品目录和其他内容。应逐个类型理解未授权访问（机密性/秘密性）和未授权破坏或修改（完整性）的影响。例如，大多数静态 HTML 页面是公开的而不需要访问保护。另一方面，这些页面的破环行为会严重降低用户对站点的信心。

理解了数据特征、评估了相关风险并确定了保护控制的成本后，可靠的商业判断应确定所需的保护。

必须做出的最有代价的和重要的决定之一为，是否在地理上复制站点系统和数据库，或者采用可供选择的可能计划。自然灾难、火灾、恐怖分子攻击和主网络中断不太可能，但总有站点不能运行的潜在可能。

经过认真规划、实现和维护的 DMZ 是相当安全的。不过，高度敏感的数据通常值得额外的保护。常用的方法有：

• 敏感数据应存储在内部防火墙之内（例如，示例站点的安全网络）。由于某些访问路径必须通过防火墙开放才能合法访问数据，因此这个解决方案并非万能的，并可能将性能降低到无法接受的程度。
  
  
• 数据库通常主要包含低敏感的数据，但有一些数据必须加以保护，如信用卡号。如果此类数据在 DMZ 内，应在数据库中加密并在需要使用时解密。
  
  
• 口令只有经过单向算法转换后才能存储，从不以明码存储。
  
  
• 需要特别注意用于客户身份验证的目录，因为该子系统的突破会暴露所有的客户数据。

Microsoft 的 SQL Server 7.0 关系型数据库加强了 ANSI/ISO SQL 标准，它指定用户不能查看或修改数据，除非数据的拥有者授予其许可。为确保严格而安全的身份验证，在 Windows NT 身份验证模式下运行 SQL Server 非常重要。（由于系统管理员以明码传送的口令定义用户登录帐户，因此不推荐 SQL Server 的身份验证模式。）保护 SQL Server 一般在本文的范围之外。有关详细信息，请参阅 MSDN 提供的 SQL Server 7.0 Books Online。

客户（成员）访问控制

客户访问控制包括验证客户身份的身份验证机制，以及指定所验证用户可访问的资源的授权机制。

大型站点的身份验证可与匿名客户浏览器的 cookie 表示一样简单。（客户的 cookie 还广泛用于维护客户身份验证和授权的状态。为了防止篡改，Web 服务器应使用密钥来标记 cookie。还应该对 cookie 中的敏感数据加密。）匿名注册常用于跟踪广告和客户的个人化。

对于用户的网站应用程序，使用最广泛的身份验证机制是基于窗体的登录，它将用户 ID 和口令组合在加密的 SSL 会话中。尽管 X.509 客户验证正进一步应用于商业应用程序，但还不可能在近期内面向用户的站点流行。

身份验证苦于行业标准的整体匮乏。已有的第三方方法还是专用的。从传统上看，大多数身份验证函数硬性编写在商业逻辑中，因此开发和维护的成本很高。

基于 LDAP 的目录服务器 — 通常为可伸缩性和可用性而克隆的 — 位于 DMZ 中用于支持身份验证，有时也用于授权。本身已提供 LDAP 的“Windows 2000 活动目录”可支持框围以外的上百万用户。“活动目录”的可扩展构架，可组成与 Windows 文件系统、IIS 和其他 Microsoft 产品良好结合的安全访问控制基础。

Microsoft 的“站点服务器 3.0”和“站点服务器 3.0 商业版”可扩展为虚拟支持无限的用户数量。“站点服务器”可在本机 Windows 目录服务和 — 对大型站点很重要的 — SQL Server 数据库上实现 LDAP 协议。与 IIS 结合的“站点服务器成员”支持身份验证和授权，包括用户、组、凭据、权限、角色和首选项。“成员”的可扩展构架，在对象、甚至属性级上支持站点专用的、真正的 ACL。“站点服务器成员”可大大减轻与客户访问功能相关的负担，同时提供强大而完全集成的内置功能。

Microsoft 的“护照”服务 (http://www.passport.com/) 提供了另一种高级的客户身份验证方法。“护照”是通用的登录服务，合作伙伴可以将其集成在自己站点内。对客户的便利在于：通过 Microsoft 的伙伴 Wallet 服务，简化了对合作伙伴的站点的登录访问，并能进行安全的、单击方式的购物。由于身份验证功能下放给了“护照”，因此减轻了合作伙伴站点上开发和支持这种功能的负担。合作伙伴也能共享客户配置文件信息，并有权访问存储在 Wallet 中的安全信用卡数据。合作伙伴必须在其站点上安装“护照”管理器来代理“护照”登录、管理 cookie 和转换 wallet 数据。“护照”使用广泛应用浏览器 cookie 的 Kerberos 样式的身份验证。

要点

站点安全并非附加的特性。预先规划安全，并根据它评估实现期望的保护的风险和成本，是非常重要的。安全域模型是保证在站点上实现充分的、节省成本的安全性的重要工具。

保护机制可划分为网络安全、平台安全和应用程序安全（超出本文范围）。网络安全的关键元素是防火墙/DMZ、网络分段和 SSL 加密。平台安全由强化的操作系统和服务组成，还包括实现审核功能和监控工具。

电子商务和顾客个人化支持需要客户身份验证和授权。LDAP 协议支持访问控制功能。保密的顾客信息，特别是口令和帐户信息，应该存放在内部防火墙之中。

管理与运作

简介

站点对网络和不间断服务的依赖，向保证正在运行的服务的可用性、健壮性和性能的操作人员，施加了相当压力。设计精良的管理系统，是成功管理和运作大型商务站点的关键。良好的部署工具可使 Web 站点平稳加速地成长。良好的监控和疑难解答工具可使操作人员在商务受到影响之前，迅速解决组件和服务出现的问题。管理系统本身必须能够确保系统不间断地运行。

许多大型站点在地理上与操作人员相隔甚远，而且常驻在接近高容量 Internet 带宽的被管理的数据中心之中。为了减少上外地工作的出差成本，管理网络必须提供远程部署、供给、监控和为地域上十分分散的站点排除故障的能力。

站点系统的管理和运作系统是非常复杂和困难的。运作人员在部署、调整和运作 Web 站点系统方面面临挑战。Microsoft 和许多第三方厂商提供了大量 Windows NT 系统的管理产品。另外成套的 Microsoft 开发工具，使操作人员能够自定义管理系统，以更好地运行站点。

站点的管理应结合系统和网络管理。Microsoft 的“系统管理服务器”可用于系统管理任务，如计划、部署及更改和配置管理。Microsoft 的工具和服务包，如“性能监视器”、“SNMP 服务”、WMI、事件日志和备份工具，可用于事件管理、性能管理和存储管理（操作管理）。

大型站点经常从提供网络基础结构、服务和工具的 Web 宿主公司购买网络管理（例如，排除故障和解决点小问题，还有对服务器、骨干路径、路由器、电源系统的全天候监控，还有其他影响站点内容向全世界传播的一切）。本节专门讨论系统和运行管理，而将网络管理留给 Web 宿主提供商，并说明如何使用 Microsoft 的产品和技术建立可靠而强大的管理系统。

本节中要解决的主要内容：

• 为提高可用性和增强安全性，而将管理网络与服务网络分开。
  
  
• 分布管理网络组件来：
  • 消除或减少性能瓶颈。
    
    
  • 消除单个故障点。
    
    
  • 允许独立扩展。
    
    
  • 提高管理系统可用性。
• 尽可能使用 Microsoft 工具和产品，获得因与底层平台紧密结合而带来的更高的性能。
  
  
• 尽可能使任务自动化。
  
  
• 监控能改进基础结构的每一件事情，并在问题发生前先识别它们。

 管理基础结构

管理网络

管理和运作可以共享后端网络，也可以存在于单独的 LAN 之上。使用后端网络的管理（有时称为带内管理）成本较低并易于运作。但是由于下面的原因，这种方式可能不适合管理全天候服务：

• 带内管理妨碍了服务网络的性能。与管理相关的通知，如 SNMP 陷阱，可能会布满网络，产生并/或扩大性能瓶颈的影响。
  
  
• 服务网络瘫痪时，不可能产生故障通知。
  
  
• 安全的含义。

因此，对于大型 Web 站点，为可伸缩性、可用性和安全性起见，开发人员应该建立分离的管理网络。

管理系统组件

通常，管理系统是由管理控制台、管理服务器和管理代理组成的。

图 13. 管理系统组件

图 13 是个简图，它说明了核心管理系统组件以及它们之间的通信。

管理控制台

管理系统是通过管理控制台与用户的接口。管理控制台负责：

• 用户登录和身份验证（网络操作员、管理员）。
  
  
• 提供对所有管理服务器的访问：一旦访问了某个管理服务器，用户可根据该服务器的权限，查看所有被管理节点的状态、发布在这些节点上更新软件和配置的命令。
  
  
• 提供对用户发布的命令的响应。

许多当前的解决方案实现了管理控制台和管理服务器，它们本应视作两个逻辑层，但为节省成本和方便使用起见，被实现在单一层中。但有时因为可用性、可伸缩性和被管理的网络远离操作中心等原因，希望或需要解除这两层之间的耦合。

管理服务器

管理服务器是管理系统的主力。管理服务器通过专用的或标准的协议，与被管理的节点（Windows NT 服务器、Cisco 路由器和其他网络装置）通信。管理服务器负责：

• 在其权限内接受、过滤和关联来自被管理节点的事件。
  
  
• 收集、存储和分析性能信息。
  
  
• 在被管理节点上分布和安装软件。
  
  
• 更新被管理节点上的配置参数。

因为管理服务器收集大量信息（每天数据多达数千兆），所以该信息通常存储在单独的计算机，即后端服务器上。

管理代理

管理代理是驻留在被管理节点上的程序。为了接受管理，每个设备 — 不论是 Windows NT 服务器还是简单的网络集线器 — 都必须有一个管理代理。管理代理主要执行以下功能：

• 监控被管理设备的资源并接收资源主动发送的通知和事件。
  
  
• 提供配置和调整被管理节点资源的工具。
  
  
• 按需查询被管理设备的资源，查看它们当前的配置、状态和性能数据。

某些节点可能只有一个代理，如 SNMP 管理的网络路由器。其他，如 Windows NT 服务器，比较复杂而且包括多个使用不同协议的代理。代理和服务器使用标准的和专用的协议通信。

扩展管理基础结构

为了保护最初投资，管理系统必须能从小做起并与其管理的站点一起扩大。当某个站点扩展并新添了设备和服务后，管理系统必须充分扩展。

小型站点可用非常简单的管理系统管理，这种管理系统通常使用后端网络。最简单的管理系统是集中系统：少量装有管理服务器和控制台软件的计算机。每台计算机都能管理整个站点。下面介绍集中管理系统。要扩展这样的管理系统，开发人员必须将其分布开来。接着，我们要介绍分布式管理系统所需的步骤。最后，给大家一个分布式管理系统的示例。

集中管理系统

管理系统既可以集中也可以分布。单个中央管理实体控制着全部管理系统，这就是集中管理系统的特征。集中管理是由一台（或多台）强大的计算机实现的，这（些）计算机允许访问该站点系统的所有组件，监控所有设备并接受来自所有被管理元素的报警和通知。中央管理通常是由主服务网络完成的。

由于集中管理系统简单、低成本和容易管理，所以它在小型环境（如只有几个服务器的启动站点）中很受欢迎。Microsoft 为集中管理系统提供了丰富的工具和应用程序，如 SMS、PerfMon、时间日志、Robocopy 和脚本工具。第三方厂商还提供了其他应用程序和工具。

分布式管理系统

随着 Web 站点的快速增长，集中管理系统被证明是低效率的。集中在一台或两台计算机上的集中管理系统存在严重问题：缺乏可伸缩性，产生性能瓶颈，并且具有单个故障点。这些问题使集中管理系统不适用于管理非常大的、迅速扩展的和高度可用的站点。为了解决可伸缩性和可用性问题，管理系统应按下面方法分布：

• 将管理控制台从管理服务器分离。
  
  
• 添加更多的服务器，使每一个服务器管理较少的节点。
  
  
• 添加更多的控制台，允许访问更多的管理员和技术员。
  
  
• 在服务器之间，按地域或管理功能划分工作量。

管理系统示例

我们的示例站点使用在单独 LAN 上实现的分布式管理系统。

图 14 描绘了示例站点所用的管理系统。因为本章的主题是管理系统，所以我们把被管理的系统 — 站点本身 — 表示为云状。有关示例站点体系结构的详细内容，请参阅图 3。

图 14. 管理系统示例

在本管理系统示例中，不同线条样式、粗细和注释分别表示管理 LAN、远程访问和安装在管理系统组件上的应用程序。主要有：

• 管理网络（粗实线）。
  
  
• RAS 拨入管理网络（细实线）。

管理控制台

在本示例管理网络中，管理控制台是与管理服务器分离的，这样可将其集中在（高度安全的）“网络操作中心”。必须仔细选择管理工具和应用程序，以远程提供几乎所有的管理功能。

管理控制台可以运行 Windows NT 服务器，工作站或专业版。它们通常安装了许多应用程序：“系统管理服务器管理员控制台”、“终端服务 (TS) 客户机”、Telnet、Internet Explorer 和 SNMP MIB 浏览器。这些工具全都提供远程管理功能，因此能被旅行中的技术人员用于漫游的环境中。

管理服务器

在分布系统中，每个管理服务器只能为其管辖范围内的被管理节点服务 — 如，一个区或一个分区、一层楼、一幢大楼、一个校园、一座城市等等。例如，本地的管理服务器可以运行在欧洲和北美的每个办公室中，管理着本地的事件和网络。分布管理服务器并将它们分区、使它们只管理有限数量的节点，将允许人们：

• 将管理服务器锁在保险柜中。
  
  
• 减少或消除网络拥堵（就是说，亚洲的 Windows NT 服务器由东京的管理服务器升级，而用不着新泽西的服务器）。
  
  
• 消除单个故障点。

同一管理服务器不与其他区域的被管理节点交互（但是，也不排除这样做）。

我们建议管理服务器运行 Windows NT 4.0 服务器版或 Windows 2000 服务器版，以保证更好的系统稳定性，并提供仅在服务器版本中可用的附加服务。管理服务器拥有的管理应用程序，提供了站点所需的系统和网络管理功能。Microsoft 提供的服务和应用程序应安装在管理服务器上（“性能监视器”、“系统管理服务 (SMS)”和“事件日志”）。SNMP 陷阱管理器或陷阱接收器也应安装在管理服务器上。

后端服务器 (BES)

后端服务器是具有大容量硬盘的计算机，用于长期存放管理服务器收集的信息。没有必要用单独的计算机存储管理数据。但是，最大的商务站点每天要记录数以千兆计的数据（为了日后的数据采集和利用），所以用单独的计算机来存储这些信息。大型数据库常用于存储被管理节点记录的事件、性能计数器和统计数据。SMS 数据库也可放在 BES 上。后端服务器还可宿主操纵数据库中所存数据的实用程序和工具：收集程序、分析程序等。这样使许多顾客能够使用自己的高度自定义的或传统的工具。

分布式与集中的

分布式管理系统比集中管理系统有许多重要的优点。它们提供了更好的可伸缩性和可用性，并且减少或消除了性能瓶颈和故障单点。但是，分布式管理系统也有一些不足之处，如较高成本（与添加更多的设备和管理有关）并越来越复杂。在为站点设计管理系统时，请仔细权衡使用集中的或分布式管理方法的利弊。

管理系统需求

部署和安装

要成功地部署新服务和设备，管理系统必须提供部署和安装工具。开发包括安装和配置新设备，以及将站点内容和数据复制到新机器上。下面的工具和技术经常用于配置新服务和机器。

无人值守的/自动的服务器安装

为了部署新服务器，请使用脚本建立服务器的黄金（或理想的）版本。然后，使用诸如 Norton Ghost 和 Ghost Walker (http://www.ghost.com/)（英文）的工具，捕获黄金服务器系统盘的映像副本，再使用此黄金映像构建新服务器。

SysPrep (Windows 2000)

SysPrep 是在多台机器上完全安装 Windows 2000 的工具（可以从“Windows 2000 的资源大全”中得到）。完成了单台系统上的初始安装步骤之后，管理员可以运行 SysPrep，准备好用于复制的示例计算机。通常站点区域中的 Web 服务器都基于相同的映像，只是次要的配置有所不同（如名称和 IP 地址）。另外，SysPrep 与 winnt.sif 应答文件的组合，提供了对每台计算机进行次要配置的工具。

内容复制

“内容复制服务”和 Robocopy 经常用于内容复制。“内容复制服务”是“Microsoft 站点服务器”产品系列的一个(http://www.microsoft.com/siteserver/site/（英文）)。 Robocopy 是个 32 位 Windows 命令行应用程序，该程序简化了在多处维护文件夹树的同一副本的任务。Robocopy 可在“Windows NT/2000 资源大全”中得到。

更改和配置

“系统管理服务器”提供了站点服务器的更改和配置管理所需的全部工具。SMS 使许多更改和配置管理任务自动化，如硬件清单/软件清单、产品一致性、软件分布/安装和软件度量。

有关“Microsoft 系统管理服务器”的详细内容，位于 http://www.microsoft.com/smsmgmt/（英文）。其他来自第三方的工具，位于 http://www.microsoft.com/ntserver/management/exec/vendor/ThrdPrty.asp（英文）。

性能监控

持续监控对于运行站点的 24x7 服务很重要。许多站点广泛利用日志和基于计数器的监控，以及尽可能多的远程管理，来保证持续的可用性并提供改进其基础结构的数据。用于监控站点服务器性能的工具包括 Performance Monitor（英文）、SNMP MIB 浏览器和 HTTPMon。

事件管理

事件管理需要监控站点系统的健康状况和状态（通常是实时的），警告管理员出现的问题，以及为便于管理在同一地点合并事件日志。事件监控工具可以跟踪各服务器或网络组件，还可以关注应用程序服务，如电子邮件、事务处理或 Web 服务。对于有上百台机器的站点，要从背景噪音中过滤出重要的事件，事件过滤、警告和显示工具是绝对必要的。诸如事件日志、SNMP 代理和 SMS（用于事件到 SNMP 陷阱地转化）等工具可用于事件管理。

带外紧急恢复

在管理网络本身瘫痪时修复故障节点，是一个很难管理的问题。当带内的干涉不可能时，可通过带外 (OOB) 管理支援。

OOB 管理指对管理的节点提供技术访问的产品，这些技术访问利用的是拨号电话线或串行电缆，而非管理网络。因此，每个被管理节点上必须有用于带外访问的串口。使用 OOB 管理可使故障的服务或节点成为联机，以进行带内修复、分析故障原因等。

OOB 需求

OOB 管理应该提供下面的全部或部分功能：

操作系统和服务控制

• 重新启动故障服务或节点。
  
  
• 使故障服务或节点脱机。（这很重要，因为故障节点可使网络充斥故障通知。）
  
  
• 设置和控制固件。
  
  
• 更改固件配置。
  
  
• 设置操作系统和服务。

BIOS 和“启动设备控制”

• 硬件电源管理。
  
  
• BIOS 配置和硬件诊断。
  
  
• 远程控制台输入和输出。

OOB 解决方案

有许多解决方案可完成上面描述的任务。表 2 汇总了使用最广泛的来自 Microsoft 和第三方厂商的解决方案。

表 2. 带外解决方案

功能	名称	厂商
终端服务器	可用于 Windows NT 4.0 终端服务器版或 2000 服务器版 TermServ	Microsoft Seattle Labs
设置和安装	无人值守操作系统和后期操作系统的外壳脚本 Ghost IC3 远程安装服务（仅限 Windows 2000）	Microsoft Norton ImageCast Microsoft
BIOS 配置和硬件诊断	集成远程控制台 (IRC) 远程监视板 (RIB) 显现远程服务器访问	Compaq Compaq Apex
硬件电源管理	集成远程控制台 (IRC) 远程监视板 (RIB) 远程电源控制	Compaq Compaq Baytech

OOB 安全

拨号进入控制台端口即显露要访问的网络。保护 OOB 操作可防止这种情况出现。起码需要对管理人员进行严格的身份验证，一般使用由安全令牌提供的一次性（问答）口令。管理员都有基于硬件或软件的令牌，用它们与目标场所的访问服务器协商。这打开了与终端服务器的连接，服务器轮流提供对某一主机的串口访问。理想情况下，还使用链接加密，防止入侵者造成的窃听和可能的泄密。日益流行的解决方案是，用基于 VPN（虚拟专用网络）的公共密钥提供严格的身份验证和加密。

管理任务的自动化

管理系统的设计应允许自动操作的执行，如停止或启动服务或整个节点，在某个事件发生时运行脚本或批处理文件，或者在管理网络不可用时尝试带外恢复。设计得好的系统会利用电子邮件、电话、寻呼机或移动电话，自动通知 IT 技术人员出现的事件或问题。

多种工具和应用程序可自动化管理任务：

• 在性能监控器的“报警窗口”中的计数器上设置一个报警值，这样，当所选计数器的值等于、大于或小于指定的设置时，即触发一条消息的发送、一个程序的运行，或一个日志的启动。
  
  
• SNMP 管理器提供自动化工具，在收到某一陷阱时，产生通知，然后运行一个程序、批处理或脚本。
  
  
• BackOffice 组件（如 Microsoft Exchange 和 SQL Server）可在与服务相关的事件发生时（例如，远程邮件服务器在预定义的时间间隔内没有应答消息），触发例外。例如 Microsoft Exchange 服务器可发送电子邮件、在屏幕上显示报警，或向外部应用程序发送通知。
  
  
• 使用 Windows 脚本主机 (WSH) 或任一其他脚本机制编写灵活的脚本，使其监控系统，并在需要时产生消息或触发自动任务。

还有许多实现自动化的第三方解决方案可用，它们列在：http://www.microsoft.com/ntserver/management/exec/vendor/ThrdPrty.asp（英文）。

安全

管理基础结构的安全是极为重要的，因为该子系统的泄密会使整个站点的其他每个组件的泄密。在讨论安全体系结构的前一节中讨论的所有安全元素，在此都用到了。

尽管用得十分广泛，但最流行的管理协议之一 — SNMP — 从安全的角度看尚有欠缺。SNMP 共有字串是非常脆弱的口令。虽然它不允许用户登录，却允许某人控制节点。请仔细选择并严密控制每个站点的管理协议。

摘要

在这篇文章中，我们讲述了如何使用 Microsoft Windows 平台和其他 Microsoft 技术，建立可扩展的、可用的、安全的和易于管理的站点基础结构。我们强调了保持大型站点的操作和设计的简单和灵活，并着重讲述“.com”如何根据体系结构的以下四个目标，成功地部署和运作站点：

• 线性可伸缩性 — 持续增长以满足用户需求和业务复杂性。
  
  
• 持续服务可用性 — 使用冗余和功能专业化来提高容错能力。
  
  
• 数据和基础结构的安全性 — 保护数据和基础结构免受恶意攻击或盗用。
  
  
• 管理的简便性和完整性 — 确保操作能够满足增长的需求。

我们预计，这是众多文章中的第一篇，全面而深入涉及用 Microsoft 产品和技术设计、开发、配置和运作大型商业网站。