逻辑体系结构示例设计:协作网站

本文内容:

  • 关于模型

  • 总体设计目标

  • 服务器场

  • 用户、区域和身份验证

  • 管理网站

  • 应用程序池

  • Web 应用程序

  • 网站集

  • 内容数据库

  • 区域和 URL

  • 区域策略

  • 备份和还原协作网站

  • 设计安全的外部协作

本文介绍如何在实际中实施逻辑体系结构组件,以获得可行的设计。本文旨在结合使用以下模型:逻辑体系结构示例设计:Windows SharePoint Services 协作(该链接可能指向英文页面) (https://go.microsoft.com/fwlink/?linkid=124861&clcid=0x804)(该链接可能指向英文页面)。

关于模型

本模型说明如何部署一个名为 Fabrikam, Inc. 的虚构公司。如果您正在使用在此模型中表示的一种或多种类型的协作网站来规划解决方案,则可以将此模型用作您自己的设计的基础。

本模型通过所表示的三种不同类型的协作网站来说明 Windows SharePoint Services 3.0 的一般部署:

  • 工作组网站

  • 自助式网站

  • 合作伙伴协作网站

该模型几乎适用于所有逻辑体系结构组件,它阐述了如何将这些组件纳入整体设计中。本文介绍此模型的设计目标,并说明如何使用本模型中阐述的逻辑体系结构组件实现这些目标。

每种不同类型的协作网站:

  • 承载具有不同数据特征的数据。

  • 适用于不同的使用情况配置文件。

  • 需要不同的权限管理策略。

因此,该模型中的设计选择旨在优化每个应用程序的性能和安全性。

工作组网站

工作组网站表示高度结构化和管理严密的协作网站,其中:

  • 首要网站集数量较少,这些网站集旨在包括大量数据(与自助式网站相比较而言)。

  • 顶级 URL 适用于每个工作组。

  • 将在网站层次结构、分类以及自定义项方面进行更多的规划。

  • 每个工作组的内容位于一个单独的数据库中,可对其单独进行管理。

下图说明工作组网站的网站层次结构:

工作组网站的组织

自助式网站

自助式网站是管理严密的工作组网站的备选方案。通过使用“自助式网站管理”,可以允许用户和工作组创建其自己的网站集。可以在管理中心中打开“自助式网站管理”。如果想要允许组或社区创建网站,最好使用此方法。如果要承载网站并且要允许用户创建网站(但不想让用户等待详细的过程),也可以使用此方法。

自助式网站的特征通常与管理严密的网站不同。特征可能包括以下几个方面:

  • 大量的首要网站集。

  • 每个网站集的数据量较少。

  • URL 自动生成,但通常没有意义。

下图说明在设计示例中实现的自助式网站:

用于自助式网站创建的网站

在规划实现自助式网站时应注意一些折衷,它们将影响您管理这些类型的网站的方式:

  • 创建网站时较为随意,在各网站间没有组织原则,而没有实施精心设计的分类。因为每个新网站都是一个网站集,所以无法在自助式网站之间共享模板和导航。

  • 因为每个网站集只对该网站集的内容提供搜索,所以无法跨网站集提供搜索结果的汇总。

  • 网站集在规模和用途方面可能相差很大。

  • 网站可能容易被放弃。

管理自助式网站可能包括基于内容数据库的目标大小管理内容存储以及定期删除不再使用的网站。

有关实现自助式网站管理的详细信息,请参阅Plan process for creating sites (Windows SharePoint Services)

合作伙伴协作网站

合作伙伴 Web 应用程序承载可供外部使用的网站,以便与合作伙伴公司的员工实现安全的协作。此应用程序旨在帮助员工简便地创建安全网站来进行协作。影响该应用程序的设计选择的关键因素包括:

  • 内容隔离   不允许合作伙伴访问服务器场上承载的其他类型的内容。

  • 独立的合作伙伴帐户身份验证   合作伙伴帐户通过表单身份验证进行管理。合作伙伴帐户未添加到企业目录。

  • 权限管理   各网站所有者管理自己网站的权限,只邀请必要的参与者参加协作。

下图说明合作伙伴协作网站。

合作伙伴网站中的项目网站的层次结构

总体设计目标

该模型说明 Windows SharePoint Services 3.0 功能在几种不同类型的协作应用程序(工作组网站、自助式网站和合作伙伴网站)中的实际实现。本文讨论了每个单独网站应用程序的设计实现方案。该模型的主要设计目标包括:

  • 创建一个可以增长的环境设计框架。各协作应用程序的设计决策并不妨碍添加其他应用程序。例如,初始部署可能只包括协作工作组网站或只包括合作伙伴网站。通过使用类似的逻辑体系结构设计,可以在不影响初始协作网站设计的情况下向解决方案添加其他类型的协作网站。换句话说,设计并不包含限制环境使用的设计选择。

  • 在不危害不同协作应用程序中的内容安全的情况下,为几个类别的用户提供访问权限。来自不同的网络区域(内部和外部)且使用不同身份验证提供程序的用户都可以参与协作。而且,用户只能访问他们应可以访问的内容。通过遵循类似的逻辑体系结构设计,您可以有机会为处在多个位置且具有不同目标的用户提供访问权限。例如,您最初的设计可能仅用于内部员工访问。但是,通过使用类似的设计,您可以允许远程员工、合作伙伴员工或甚至客户进行访问。

  • 确保设计可用于 Extranet 环境。可进行特别的设计选择,以确保服务器场可安全地部署在外围网络中或在Design extranet farm topology (Windows SharePoint Services) 中讨论的任何 Extranet 拓扑中。

本文的其余部分讨论该模型中的每个逻辑组件(从上到下)并讨论应用于该模型的设计选择。这种方法旨在演示基于应用程序配置逻辑体系结构组件所使用的不同方式。

服务器场

此模型说明包含五个服务器的服务器场。但是,可以对任何规模的服务器场(包括单个服务器)实现此模型。该模型中的服务器场由使用以下拓扑的五个服务器组成:

  • 两个前端 Web 服务器

  • 每个搜索服务器对应于一个应用程序服务器

  • 两个群集数据库服务器或镜像数据库服务器

该模型通过展示以下项目说明 Windows SharePoint Services 3.0 的逻辑体系结构:

  • 所有网站都在前端 Web 服务器间进行镜像。

  • 管理中心网站安装在应用程序服务器上,以防止用户直接访问。

事实上,除了根据需要提高容量和性能外,服务器计算机的数量和服务器场的拓扑结构对逻辑体系结构并不重要。逻辑体系结构可独立于服务器场拓扑结构进行设计。性能和容量规划过程将帮助您设计服务器场的规模,以实现性能和容量目标。有关详细信息,请参阅Plan for performance and capacity (Windows SharePoint Services)

用户、区域和身份验证

该模型说明五种不同类别的用户,每个类别都分配到不同的区域。在每个 Web 应用程序中最多可以创建五个区域,同时使用以下可用的区域名称之一:默认区域、Intranet 区域、Internet 区域、自定义区域或 Extranet 区域。承载多个 Web 应用程序的服务器场能够支持来自五个以上网络区域的用户请求(每个 Web 应用程序最多支持五个区域)。但是,该模型只显示五个区域。

用户和身份验证

该模型演示如何对来自不同网络区域的用户应用身份验证。下表还演示如何对每种类型的用户和区域应用身份验证。

区域 用户 身份验证

Intranet

内部员工

NTLM(集成的 Windows)

默认

远程员工

NTLM(集成的 Windows)或使用轻型目录访问协议 (LDAP) 的表单身份验证。

Extranet

合作伙伴员工

表单身份验证

内部员工

Intranet 区域用于内部员工访问。使用集成 Windows 身份验证。

远程员工

默认区域用于远程员工访问。默认区域的设置目标为:

  • 通过内部 Active Directory 目录服务环境进行身份验证。

  • 为内部员工和远程员工使用 Windows 身份验证可简化权限管理。这一目标很重要,原因是:如果用户通过两个不同的身份验证提供程序连接到网站,则 Windows SharePoint Services 3.0 会为每个用户创建两个不同的帐户并且其中每个帐户都必须具有权限。

该模型介绍了对远程员工进行身份验证的两个不同选项。通过第一个选项(使用 NTLM 的集成 Windows 身份验证),两个设计目标均可实现。第二个选项(使用 LDAP 的表单身份验证)可实现第一个目标,但不能实现第二个目标。因此,第一个选项是针对远程员工的首选方法。

下表总结了这两个身份验证选项之间的差别。

比较类型 使用 NTLM 的集成 Windows 身份验证 使用 LDAP 提供程序的表单身份验证

功能

此方法依赖于使用 Internet Security and Acceleration (ISA) Server 2006 或 Intelligent Application Gateway (IAG 2007) 来验证用户身份,然后将用户凭据发送到 Windows SharePoint Services 3.0。这些服务器使用表单身份验证以针对 Active Directory 环境验证用户身份。然后,它们将 Windows 凭据转发到 Windows SharePoint Services 3.0。有关详细信息,请参阅以下资源:

由于该区域是默认区域,因此 NTLM 身份验证用于满足索引组件的要求。有关详细信息,请参阅下文“默认区域的配置要求”。

Windows SharePoint Services 3.0 通过使用 LDAP 提供程序的表单身份验证,针对内部 Active Directory 环境验证远程员工的身份。

优点

Windows SharePoint Services 3.0 不会为在内部和远程工作的用户创建两个不同的帐户。这样可极大地简化权限管理。

不需要使用代理服务器验证用户身份并转发凭据。

缺点

要求 ISA Server 2006、IAG 2007 或其他代理服务器产品进行额外的协调并进行配置。

如果用户需要在内部和远程连接到 Windows SharePoint Services 3.0,则会在 Windows SharePoint Services 3.0 中创建两个不同的用户帐户。结果,这两个帐户都需要对网站和文档具有一定权限。如果员工希望既可以通过内部网络工作又可以远程工作,则需要为这两个用户帐户管理对其自己的网站和文档的权限。

合作伙伴员工

合作伙伴员工通过 Extranet 区域访问网络,并使用表单身份验证进行身份验证。这要求一个单独的目录和提供程序,如 Microsoft SQL Server 数据库和提供程序,以存储 Extranet 中的合作伙伴帐户。此方法的优点是,可单独管理合作伙伴帐户,并且您无需向内部员工目录添加合作伙伴帐户。

或者,也可以使用 Web 单一登录 (SSO),针对合作伙伴自己的目录进行身份验证。但是,这种方法要求为每个合作伙伴目录提供一个单独的区域。

因为该模型假定 Fabrikam 在同一合作伙伴应用程序中与几个不同公司的合作伙伴进行合作,所以使用表单身份验证。未指定目录和提供程序。

区域

设计区域时,有几个关键决策对于成功部署至关重要。这些决策包括对以下区域的设计和配置决策:

  • 默认区域

  • 用于外部访问的区域

以下各节描述该模型中采用的决策。

默认区域的配置要求

最需要关注的区域就是默认区域。Windows SharePoint Services 3.0 对默认区域的配置有以下要求:

  • 当用户请求无法与区域关联时,就会应用默认区域的身份验证和策略。因此,默认区域必须是最安全的区域。

  • 索引组件至少需要通过一个区域访问内容才能对内容进行爬网。索引组件使用 NTLM 身份验证。因此,若要对内容进行爬网,必须至少将一个区域配置为使用 NTLM 身份验证。此外,爬网程序在遇到可以通过身份验证的区域之前,将按以下顺序对区域进行轮询:默认区域、Intranet 区域、Internet 区域、自定义区域和 Extranet 区域。但是,如果爬网程序首先遇到的是已配置为使用 Kerberos、基本或摘要式身份验证的区域,则爬网程序不会进行身份验证,也不会尝试访问下一个区域。因此,请确保区域的配置不会阻止索引组件对内容进行爬网。有关与对内容进行爬网相关的身份验证要求的详细信息,请参阅Plan authentication methods

  • 可以从默认区域发送含有链接的管理电子邮件。其中包括发往接近配额限制的网站所有者的电子邮件。因此,收到这种电子邮件的用户必须能够通过默认区域访问链接。这一点对网站的所有者尤为重要。

  • 只能通过默认区域使用以主机命名的网站集。需要访问以主机命名的网站集的所有用户都必须能通过默认区域进行访问。

在该模型中,默认区域用于远程员工进行访问,具体原因如下:

  • 员工可以访问管理电子邮件中的链接,而无论他们是在内部还是以远程方式访问网站。

  • 当无法确定与用户请求关联的区域时,可防止泄露内部服务器名称和 URL。因为默认区域已经配置为用于远程员工,所以应用该区域时,URL 不会泄露敏感数据。

配置 Extranet 环境的区域

在 Extranet 环境中,出于以下两个原因,区域的设计至关重要:

  • 可从多个不同的网络发起用户请求。在该模型中,用户可从内部网络、Internet 和合作伙伴公司发起请求。

  • 用户可以跨多个 Web 应用程序参与协作。例如,内部员工和远程员工可以跨所有 Web 应用程序(工作组网站、自助式网站和合作伙伴网站)参与和管理内容。

在 Extranet 环境中,确保遵循以下设计原则:

  • 配置跨多个 Web 应用程序的区域,使这些区域互为镜像。身份验证的配置以及目标用户应相同。但是,与区域关联的策略在 Web 应用程序之间可以不同。例如,确保 Intranet 区域在所有 Web 应用程序中都用于同一个员工。换句话说,不要在一个 Web 应用程序中为内部员工配置 Intranet 区域,而在另一个 Web 应用程序中为远程员工配置 Intranet 区域。

  • 为每个区域和每个资源准确配置相应的备用访问映射。

在该模型中,每个 Web 应用程序的默认区域对于远程员工访问的配置完全相同。此外,Intranet 区域在所有 Web 应用程序中对内部员工访问权限的配置也完全相同。Extranet 区域只配置用于一个 Web 应用程序。

在创建区域时,将自动创建备用访问映射。但是,如果您使用代理服务器或网关产品以便可通过 Internet 访问网站,将需要为每个区域添加一个附加备用访问映射项。这可确保在内部网络之外向用户返回的 URL 根据其区域的上下文可用于用户。有关详细信息,请参阅Plan alternate access mappings

如果各 Web 应用程序中的区域不互相镜像,并且指向外部资源的链接不适当,则会产生如下风险:

  • 可能会将服务器名称、域名系统 (DNS) 名称和 IP 地址泄露到内部网络之外。

  • 用户可能无法访问网站和其他资源。

管理网站

在此模型中,管理中心网站驻留在搜索服务器上。这样可防止用户直接联系该网站。如果性能瓶颈或安全漏洞影响到前端 Web 服务器的可用性,管理中心网站仍然可用。此外,管理中心网站驻留在一个专用应用程序池和 Web 应用程序中。

该模型或本文并未详述管理网站的负载平衡 URL。建议采取以下措施:

  • 如果管理 URL 中使用端口号,则使用非标准的端口。端口号默认包含在 URL 中。尽管端口号通常不用于面向客户的 URL,但为管理网站使用端口号可将对这些网站的访问权限限制到非标准端口,以提高安全性。

  • 为管理网站创建单独的 DNS 项。

应用程序池

通常会实施单独的 Internet Information Services (IIS) 应用程序池,以在不同网站间实现进程隔离。应用程序池提供了一种可供多个网站在同一台服务器计算机上运行的方式,但它们仍拥有自己的工作进程和标识。这样可缓解某个网站受到任何可能的安全问题威胁,而攻击者利用这些安全问题可以在服务器上注入代码以攻击其他网站。

从实际角度来说,可以考虑在下列每种情况下使用专用的应用程序池:

  • 需要将经过身份验证的内容与匿名内容分开。

  • 需要隔离主要用于与外部合作伙伴或客户协作的网站。这会将外部帐户隔离到一个应用程序池内的网站中。

  • 需要隔离用户具有更多自由度以创建和管理网站并针对内容进行协作的网站。

该模型以下列方式使用应用程序池:

  • 管理网站驻留在一个专用应用程序池中。这是 Windows SharePoint Services 3.0 的一项要求。

  • 内部协作网站(工作组网站和自助式网站)驻留在一个应用程序池中。

  • 合作伙伴 Web 应用程序驻留在一个专用应用程序池中。

Web 应用程序

Web 应用程序是通过 SharePoint 产品和技术创建和使用的 IIS 网站。每个 Web 应用程序都表现为 IIS 中一个不同的网站。应为每个 Web 应用程序分配一个唯一的域名,这将有助于防止跨网站脚本攻击。

一般来说,专用 Web 应用程序的用途是:

  • 将匿名内容与经过身份验证的内容分开。

  • 隔离用户。在该模型中,合作伙伴网站驻留在一个专用的 Web 应用程序和应用程序池中,以确保合作伙伴无法访问内部协作内容。

  • 强制实施权限。通过专用的 Web 应用程序,可以使用管理中心的“Web 应用程序的策略”页强制实施权限。例如,可以在内部协作网站上创建一个策略,以明确拒绝合作伙伴帐户的访问权限。强制实施 Web 应用程序的策略时不考虑对 Web 应用程序中单独的网站或文档配置的权限。

  • 优化性能。如果网站所处的 Web 应用程序中有数据特征相似的其他应用程序,则网站会获得更好的性能。例如,自助式网站的数据特征包含大量小型网站。相比之下,工作组网站通常包含少量极大型网站。通过将这两种不同类型的网站分别放置在单独的 Web 应用程序中,生成的数据库就会由特征相似的数据组成,从而优化数据库性能。在该模型中,工作组网站和自助式网站没有独特的数据隔离要求 — 它们共享同一应用程序池。但是,工作组网站和自助式网站分别位于单独的 Web 应用程序中,以优化性能。

  • 优化可管理性。由于创建单独的 Web 应用程序会产生单独的网站和数据库,因此可以实施不同的网站限制(回收站、有效期和大小),并协商不同的服务级别协议。例如,如果自助式网站的内容并非组织中最重要的内容类型,则可以延长还原自助式网站的时间。这样,您便可以在还原这些网站之前,还原更加重要的内容。在该模型中,自助式网站位于单独的 Web 应用程序中,以便管理员能够将其与其他应用程序区别对待,更加严格地管理内容的增长。

网站集

网站集在逻辑体系结构和信息体系结构之间建立了一座桥梁。该模型中的网站集的设计目标是,满足 URL 设计的要求并从逻辑上划分内容。

为了满足 URL 设计的要求,每个 Web 应用程序都包括一个单一的根级别网站集。管理路径用来合并第二层的首要网站集。有关 URL 的要求以及使用管理路径的详细信息,请参阅下文中的“区域和 URL”。在第二层的网站集之下,每个网站都是一个子网站。

下图显示了工作组网站的网站层次结构。

协作网站的逻辑体系结构

考虑到根级别网站集的要求,设计决策的核心是第二层的网站集。该模型根据应用程序的性质选择各个选项。

自助式网站

在该模型中,自助式网站包含一个首要网站,其 URL 为 http://sites。这里使用了一个管理路径(通过使用通配符包含),从而使用户创建的网站不受数量限制。管理路径下的所有网站都是独立的网站集,这些网站集继承用于创建首要网站的网站模板。下图说明自助式网站。

有关自助式网站的详细信息,请参阅Plan process for creating sites (Windows SharePoint Services)

工作组网站

当在工作组网站应用程序中设计网站集时,建议根据组织的运作方式为组织创建有限数量的网站集。由 Windows SharePoint Services 3.0 管理员通过这种方法创建网站集。创建网站集之后,各团队可以根据其需要在网站集中创建网站。

通过这种方法可以实现精心设计的分类;而这种分类可为工作组网站的管理和增长模式提供结构框架。还可以有更多机会在共享网站集的项目和团队之间共享模板和导航。信息架构师面临的挑战是如何创建适合组织的第二层网站集。下表列出了针对不同类型的组织的建议。

组织类型 建议的网站集分类法

产品开发

  • 为每个正在开发的产品创建一个网站集。允许参与开发的团队在该网站集中创建网站。

  • 对于每个长期开发项目,为每个参与产品开发的大型团队创建一个网站集。例如,为下列每个团队创建一个网站集:设计师、工程师和内容开发人员。

研发

  • 为每个长期研发项目创建一个网站集。

  • 为每一类研发项目创建一个网站集。

高等教育机构

  • 为每个院系创建一个网站集。

国家立法机关

  • 为每个政党创建一个网站集。同属一个政党的政府官员可以共享模板和导航。

  • 为每个委员会创建一个网站集。或者,为所有委员会创建一个网站集。

企业法务部门

  • 为每个企业客户创建一个网站集。

制造企业

  • 为每个产品生产线创建一个网站集。

合作伙伴网站

合作伙伴网站用于与外部合作伙伴针对具有固定范围或固定期限的项目开展协作。在设计上,合作伙伴 Web 应用程序中的网站相互没有关联。合作伙伴网站的要求包括确保实现以下目标:

  • 项目所有者可以方便地创建合作伙伴协作网站。

  • 合作伙伴和其他参与方只能访问其参与的项目。

  • 权限由网站的所有者管理。

  • 在一个项目中搜索结果不会泄露其他项目的内容。

  • 管理员可以方便地确定不再使用的网站并删除这些网站。

为了满足这些要求,该模型为每个项目使用了一个网站集,这种方式有以下好处:

  • 各个网站集可在项目间提供适当级别的隔离。

  • 可实现自助式网站创建。

内容数据库

可以使用下面的两种方法在设计中结合使用内容数据库(该模型就采用了这两种方法):

  • 根据相应的大小警告阈值确立内容数据库的目标大小。在达到大小警告阈值时创建新数据库。利用此方法,可以仅根据目标大小将网站集自动添加到一个或多个可用的数据库。

  • 将网站集与特定的内容数据库关联。利用此方法可以将一个或多个网站集放置到可以独立于其他数据库进行管理的专用数据库中。

如果选择将网站集与特定的内容数据库关联,则可以使用以下方法实现这一点:

  • 使用 Stsadm 命令行工具在特定的数据库中创建网站集。

  • 应用下列数据库容量设置,使某个数据库专用于单独一个网站集:

    • 生成警告事件之前允许的最大网站数量 = 1

    • 此数据库中允许创建的最大网站数量 = 1

  • 通过执行下列步骤,向专用数据库添加一组网站集:

    1. 在 Web 应用程序中,创建数据库并将数据库状态设置为“就绪”。

    2. 将所有其他数据库的状态设置为“脱机”。内容数据库脱机时,不能创建新网站集。但是,仍可访问脱机数据库中的现有网站集,以进行读取和写入操作。

    3. 创建网站集。这些网站集将自动添加到数据库。

    4. 将所有其他数据库的状态设置回“就绪”。

工作组网站

该模型为每个工作组网站集使用了一个专用数据库。这种方法使您能够独立管理每个团队的数据库的备份、还原和迁移。而且当项目完成时,您可以方便地存档与项目关联的数据库。

自助式网站

对于自助式网站,该模型通过管理数据库使其达到最大目标大小,以实现规模效率。为实现此目标,对下列设置进行了配置:

  • 网站最大存储空间为   该设置在管理中心的“配额模板”页上配置,可限制个人网站的大小。

  • 第二阶段回收站   该设置在“Web 应用程序常规设置”页上配置,可确定为第二阶段回收站所分配的额外空间。

  • 此数据库中允许创建的最多网站数   该设置在创建数据库时配置。使用为前两个值指定的数字计算网站允许的总大小。然后,根据每个数据库的大小目标,确定数据库可容纳的网站数。

基于 100 GB 的目标数据库大小和 500 MB 的目标“我的网站”大小,该模型提供了下列示例大小设置:

  • 每个网站的网站大小限制 = 500 MB

  • 数据库的目标大小 = 100 GB

  • 最大网站数量 = 200

  • 网站级警告 = 175

当达到网站级警告时,会创建一个新数据库。创建新数据库后, 新建的自助式网站将交替添加到新数据库和现有数据库,直至其中一个数据库达到最大网站数为止。

合作伙伴网站

与自助式网站类似,合作伙伴网站通过管理数据库使其达到最大目标大小,以实现规模效率。

因为合作伙伴网站驻留在专用 Web 应用程序中,所以您可以创建更适合所创建大小类型的大小限制。该模型提供了下列示例大小设置:

  • 数据库的目标大小 = 100 GB

  • 每个网站的存储配额 = 5 GB

  • 最大网站数量 = 20

区域和 URL

该模型说明了如何跨企业部署中的多个应用程序协调 URL。

设计目标

以下目标会影响 URL 的设计决策:

  • URL 规则不限制可通过其访问内容的区域。

  • 可在模型中的所有应用程序中使用标准 HTTP 和 HTTPS 端口(80 和 443)。

  • URL 中不包含端口号。在实践中,端口号通常不用于生产环境中。

设计原则

为了实现这些设计目标,应遵循以下设计原则:

  • 不使用以主机命名的网站集。请注意,以主机命名的网站集不同于 IIS 主机标头。以主机命名的网站集不能使用备用访问映射功能。通过多个域 URL 访问相同内容时要求使用备用访问映射功能。因此,使用以主机命名的网站时,只能通过默认区域访问这些网站。备用访问映射功能还可支持外部安全套接字层 (SSL) 终止,这便于在远程员工访问及合作伙伴访问的情况下使用 SSL (HTTPS)。有关使用以主机命名的网站集的详细信息,请参阅White paper: Create shared hosting solutions on Windows SharePoint Services

  • 每个应用程序都包含一个根网站集。这是使用备用访问映射的要求。如果 Web 应用程序中要求使用多个根网站集并且您希望只使用默认区域实现用户访问,以主机命名的网站集是一个不错的选择。

  • 对于包含多个高级别网站集的应用程序,其中的每个网站集都表示一个顶级团队或项目(例如,工作组网站),该模型采用了管理路径。管理路径有助于在更大程度上控制这些类型的网站的 URL。

设计折衷

满足设计目标需要做出一些折衷,具体如下:

  • URL 会加长。

  • 不使用以主机命名的网站集。

设计负载平衡的 URL

创建 Web 应用程序时,必须选择要分配给该应用程序的负载平衡 URL。此外,您还必须为 Web 应用程序内创建的每个区域创建负载平衡 URL。如果使用负载平衡 URL,则其中会包括协议、方案、主机名和端口。负载平衡 URL 必须在所有 Web 应用程序和区域中都是唯一的。因此,每个应用程序以及每个应用程序内的每个区域都要求在模型中使用唯一的 URL。

内部协作网站

两种不同类型的内部协作网站分别需要一个唯一的 URL。在该模型中,这些网站的目标访问群体是内部员工和远程员工。下表列出了内部员工和远程员工访问每个应用程序时使用的 URL。

应用程序 内部员工 URL 远程员工 URL

工作组网站

http://teams

https://teams.fabrikam.com

自助式网站

http://sites

https://sites.fabrikam.com

合作伙伴网站

在该模型中,合作伙伴网站可供内部员工、远程员工和合作伙伴员工访问。尽管远程员工和合作伙伴员工都使用 SSL (HTTPS) 从外部访问合作伙伴网站,但他们需要不同的 URL,以实现使用单独的区域的好处 — 即,不同的身份验证方法和不同的区域策略。下表列出了内部员工、远程员工和合作伙伴用来访问合作伙伴网站的 URL。

区域 URL

内部员工 URL

http://partnerweb

远程员工 URL

https://remotepartnerweb.fabrikam.com

合作伙伴 URL

https://partnerweb.fabrikam.com

为 URL 路径使用显式包含和通配符包含

通过定义管理路径,可以指定 Web 应用程序的 URL 命名空间中哪些路径用于网站集。可以指定根网站下个别路径中存在一个或多个网站集。如果不存在管理路径,则根网站集下创建的所有网站都是根网站集的一部分。

可以创建以下两种类型的管理路径:

  • 显式包含   具有所分配的显式 URL 的网站集。显式包含仅应用于一个网站集。可在根网站集下创建许多显式包含。使用此方法创建的网站集的示例 URL 为 http://team/Team1。

  • 通配符包含   添加到 URL 的路径。此路径表示直接在路径名称之后指定的所有网站都是唯一网站集。此选项通常用于支持自助式网站创建操作的应用程序。使用此方法创建的网站集的示例 URL 为 http://sites/site1。

如以下部分所述,该模型同时采用了这两种类型。

显式包含:工作组网站

在该模型中,这两个工作组网站应用程序都使用显式包含。

工作组网站

在工作组网站应用程序中,每个工作组网站集都使用显式包含。对于使用显式包含创建的网站集的规模限制大约为 100 个网站。作为一种最佳管理方案,建议您将首要工作组网站的数量限制在可管理的范围内。此外,工作组网站的分类应在逻辑上符合企业运作的方式。100 个网站的建议适用于很多组织。如果您的组织需要为工作组网站设计更大的规模,请改用通配符包含。

在该模型中,使用显式包含将生成下表列出的 URL。

内部员工(Intranet 区域) 远程员工(默认区域)

http://team/Team1

https://team.fabrikam.com/Team1

http://team/Team2

https://team.fabrikam.com/Team2

http://team/Team3

https://team.fabrikam.com/Team3

在本示例中,根网站集 http://team 不一定要承载用户的内容。

通配符包含:合作伙伴网站和自助式网站

合作伙伴网站和自助式网站都采用通配符包含。通配符包含适用于允许用户创建自己的网站集的应用程序。通配符包含表示,通配符之后下一个项是网站集的根网站。

自助式网站

在该模型中,自助式网站包括一个名为 /sites (http://selfservice/sites) 的通配符包含。

这将生成下表所列格式的 URL。

内部(Intranet 区域) 远程员工(默认区域)

http://selfservice/sites/site1

https://selfservice.fabrikam.com/sites/site1

http://selfservices/sites/site2

https://selfservice.fabrikam.com/sites/site2

http://selfservice/sites/user3

https://selfservices.fabrikam.com/personal/user3

合作伙伴网站

合作伙伴网站在设计上允许员工方便地创建安全的网站,以便与外部合作伙伴开展协作。为了实现这一目标,允许创建自助式网站。

在该模型中,合作伙伴网站包括一个名为 /sites (http://partnerweb/sites) 的通配符。这将生成下表所列格式的 URL。

内部员工(Intranet 区域) 远程员工(默认区域)

http://partnerweb/sites/project1

https://remotepartnerweb.fabrikam.com/sites/project1

http://partnerweb/sites/project2

https://remotepartnerweb.fabrikam.com/sites/project2

http://partnerweb/sites/project3

https://remotepartnerweb.fabrikam.com/sites/project3

参与协作的合作伙伴员工可以使用下表中列出的 URL 访问合作伙伴网站。

合作伙伴(Extranet 区域)

https://partnerweb.fabrikam.com/sites/project1

https://partnerweb.fabrikam.com/sites/project2

https://partnerweb/fabrikam.com/sites/project3

区域策略

您可以为 Web 应用程序创建策略,以强制实施 Web 应用程序级别的权限。可以为 Web 应用程序定义通用策略,也可以只为特定区域定义策略。策略将对 Web 应用程序或区域内的所有内容执行权限。为网站和内容配置的所有其他安全设置都将被策略权限替代。可以根据用户或用户组配置策略,但不能根据 SharePoint 组配置策略。

此模型提供一个示例:拒绝合作伙伴帐户访问内部协作网站。

备份和还原协作网站

可以使用多个选项来备份和还原适合协作网站的内容:

  • 内置备份和恢复工具 — 如果数据库小于 100 GB,并且没有将很多自定义项打包成解决方案,则使用随 Windows SharePoint Services 3.0 提供的工具。

  • Microsoft SQL Server 2005 备份和恢复工具 — 如果您具有 SQL 数据库管理员权限,则使用这些工具。

有关详细信息,请参阅Choose backup and recovery tools (Windows SharePoint Services)

设计安全的外部协作

此设计示例宣传材料包括有关如何规划外部安全协作的概述。本节包含每项的简介文本以及指向 TechNet 库中对应文章的链接。

设计建议 指南

选择 Extranet 拓扑

通过使用边缘防火墙或将服务器场放入外围网络中以保护服务器场。有关详细信息,请参阅 TechNet 上的以下文章:

保护客户端-服务器通信的安全

Extranet 环境中的安全协作依赖于客户端计算机与服务器场环境之间的安全通信。如果适用,请使用安全套接字层 (SSL) 来保护客户端计算机与服务器之间的通信。

有关详细信息,请参阅 TechNet 上的以下文章:

保护后端服务器和管理中心网站

外部安全协作需要“面向 Internet”的服务器。您可以通过在 Web 服务器与其他服务器之间放置防火墙和将管理中心网站驻留在后端服务器上,以限制来自 Internet 的访问。

有关详细信息,请参阅 TechNet 上的以下文章:

配置备用访问映射

备用访问映射支持如下 Internet 部署方案:Internet Information Services (IIS) 接收的 Web 请求的 URL 与最终用户键入的 URL 不相同。在包含反向代理发布和负载平衡的部署方案中,最可能出现此情况。例如,反向代理可以执行高级功能(如通过使用 SSL (HTTPS) 在 Internet 上接收 Web 请求),但通过使用 HTTP 将请求转发到服务器。这称作“外部 SSL 终止”。

有关详细信息,请参阅Plan alternate access mappings

下载此书籍

本主题包含在以下可下载书籍内,以方便您阅读和打印:

有关可下载书籍的完整列表,请参阅 Windows SharePoint Services 的可下载书籍(该链接可能指向英文页面)