Sun Java System Web Server 7、Solaris Zones 和 DMZ 的用户方案

随着由服务器和软件组件构成的庞大网络的管理成本的不断增加，人们的注意力开始转向建立各种新方法，以此降低 IT 基础结构的成本和提升系统的管理。虽然服务器整合与虚拟化技术有助于改善数据中心管理，但是还有更好的方法，用来置备应用程序和提升安全性与可维护性。为了使这些资源管理技术行之有效，我们必须可以独立管理应用程序，根据业务需要控制资源的利用，快速隔离故障，并确保多个应用程序之间的安全。

Solaris Zones（Solaris Containers 技术的组成部分）可以提供一种简单高效的方法，使这种环境可在 OS 级实现。我们将了解使用区域 (Zone) 如何实现服务器的虚拟化和整合，以及 Sun Java System Web Server 7（下面简称 Web Server 7）如何使用这种环境改善应用程序的置备和可维护性。

本文介绍了下列主题：

    * Solaris Zones：含义和使用原因
    * Web Server 方案中各个区域的相关性
    * 区域的类型以及如何创建区域
    * 各种区域中均支持安装 Web Server 7
    * Web Server 7 的实际实现
    * 配置步骤：
          o 管理服务器
          o 管理代理
          o 注册
          o 群集
          o 会话复制
          o 部署 Web 应用程序
          o 监视
          o 反向代理


什么是 Solaris Zones？

区域是 Solaris 10 OS 的一项应用程序和资源管理功能。借助这项功能，该 OS 可以作为安全隔离的虚拟 OS 环境（或区域）显示给应用程序。这些区域将 OS 独立性的优点与一定程度的集中式资源管理完美结合。因此，应用程序可以通过安装并运行在不同的区域中来实现相互隔离，同时，某些 OS 资源可以进行集中分配和管理。从区域环境的角度讲，OS 资源包括诸如进程管理、内存、网络配置、文件系统、软件包注册表、用户帐户、共享库之类的资源，在某些情况下还包括安装的应用程序。

使用区域提供了一种在 Solaris OS 的实例中创建虚拟操作系统环境的方法，从而使一个或多个进程可在系统中按照与其他活动隔离的方式运行。无论用户 ID 和其他证书信息如何，这种隔离方式都能防止指定区域中运行的进程监视或影响其他区域中运行的进程。区域是一个沙箱。一个或多个应用程序在其中运行时，既不会影响系统的其余部分，也不会与这些部分进行交互。使用区域还提供了一个抽象层，可将应用程序与部署这些应用程序的计算机的物理属性分开，例如物理设备路径、网络接口名称和网络路由表等。

为何使用区域？

安全性

网络服务可在区域中运行，这便限制了安全受到侵犯时可能出现的损坏。如果入侵者成功利用了区域中运行的软件中的安全漏洞，则此入侵者只能在该区域中执行一部分可能的操作。例如，在大多数区域中运行的应用程序不能装入定制的内核模块、修改内核内存或创建设备节点。区域中可用的权限集是那些在整个系统中可用的权限集的子集。

隔离

使用区域，可以在同一计算机上部署多个应用程序，即使这些应用程序运行在不同的信任域中，要求独占访问全局资源或者需要进行逐个配置也是如此。例如，使用与每个区域关联的特定 IP 地址，可以将（同一系统内）不同区域中运行的多个应用程序绑定到同一网络端口。此外，可以阻止这些应用程序监视或拦截其他应用程序的网络通信流量、文件系统数据或进程活动等。

虚拟化

区域提供了一个虚拟环境，此环境可以在应用程序中隐藏详细信息（例如物理设备、系统的主 IP 地址以及主机名）。因为可以在不同的物理计算机上维护同一应用程序环境，所以，这对支持快速部署（和重新部署）应用程序很有用。虚拟环境功能十分强大，通过它可以单独管理每个区域：如果用户知道区域管理员执行的任何操作都不会影响该系统的其余部分，可以向该管理员提供超级用户口令。这种功能引起了正在寻求更加细化的方法以在客户（内部和外部）之间划分系统的服务提供商的关注。

粒度

与物理分区技术（如域或使用逻辑分区的 LPAR）不同的是，区域提供的隔离几乎可细化到任何程度。区域不需要专用的 CPU、物理设备或物理内存块。可以在单个域或系统中运行的多个区域之间复用这些资源，也可借助操作系统中可用的资源管理功能为每个区域分别分配这些资源。结果是，即使小型单处理器系统也能支持同时运行多个区域。主要限制（除每个区域中运行的应用程序的性能要求外）在于保存每个区域内特有文件的磁盘空间。

透明化

区域的一项基本设计原则是，避免更改正在执行应用程序的环境，但为实现安全和隔离目标而必须更改的情况除外。区域不显示应用程序必须连接的新 API 或 ABI。相反，使用区域可以提供具有某些限制的标准 Solaris OS 接口和应用程序环境。这些限制主要影响尝试执行特权操作的应用程序。

Web Server 方案中各个区域的相关性

使用区域可以帮助实现下列目标。

服务器的整合和/或利用

使用区域，可以更有效地利用计算机上的资源。通过在单个计算机的不同非全局区域 (non-global zone) 中运行 Web Server 实例，可对这些运行在专用的、未充分利用的计算机上的实例进行整合。根据这些区域中运行的组件的资源要求，全局管理员可以在这些区域中动态地分配资源。

集中式生命周期管理

区域使集中管理生命周期成为可能。可在区域中安装、升级和卸载 Web Server，而不干扰其他区域中的其他安装。在多个非全局区域中运行组件时，可以满足运行时隔离、安全性、可伸缩性及其他要求。例如，可以在全局区域 (global zone) 中安装 Web Server，并在不同的非全局区域中运行多个实例。为了实现这个目标，生命周期管理由全局管理员执行，但是配置和运行时管理委托给区域管理员处理。

版本隔离

并行的不同 Web Server 版本集可在不同区域中运行。这样，便可在一段时间内实现两个 Web Server 版本之间的迁移。

组织独立性

不同组织可以维护同时存在并运行于同一台计算机上的不同的 Web Server 部署，或不同的 Web Server 运行时实例。例如，不同的开发者小组可以使用自己的特定 Web Server 实例，或者不同组织可以使用不同的 Web Server 部署进行测试、预试生产或生产。根据特定目标，可以采用各种方法实现组织独立性：一种方法是将配置和运行时管理委托给区域管理员处理的同时集中管理 Web Server 的生命周期，另一种方法是将所有管理功能（生命周期、配置和运行时）委托给区域管理员处理。

完全根区域 (Whole Root Zone)

在这个特殊模型中，将会安装区域所需的组成特定元簇 (metacluster) 的所有软件包，以及由全局管理员选择的其他所有软件包。创建完全根非全局区域时，在全局区域中安装的所有软件包对完全根区域均可用。此时，将会创建软件包数据库，并将所有软件包复制到非全局区域，从而创建所有文件的专用独立副本。

此模型的优点是：允许区域管理员定制其区域的文件系统布局（例如，创建 /usr/local），并可以添加任意非随附软件包或第三方软件包。此模型的缺点是：虚拟内存系统无法共享可执行文件和共享库中的文本段，而且采用这种方式配置的每个区域的磁盘使用量也会显著增加。

稀疏根区域 (Sparse Root Zone)

此模型只包含全局区域中现有的部分文件系统的读/写副本（因此名为稀疏根区域），而其他文件系统从全局区域作为回送虚拟文件系统以只读方式加以挂载。全局管理员在创建稀疏根区域时选择要与该稀疏根区域共享的文件系统（默认情况下为 /usr、/lib、/sbin 和 /platform 目录）。

完全根区域与稀疏根区域

选择使用完全根非全局区域还是稀疏根非全局区域取决于资源效率和管理控制之间的折衷。完全根区域可以内存和其他资源作为代价来实现管理控制（独立性和隔离）的最大化。稀疏根区域可以管理独立性为代价优化可执行文件和共享库的高效共享（而且磁盘使用量显著降低）。目前，无法衡量是稀疏根区域还是完全根区域在性能方面更占优势；可能需要视软件而定。

使用命令行创建本地区域

下面是一个示例：

# zonecfg -z <zone_name>
<zone_name> No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:<zone_name>> create -b（使用 -b 选项将创建\
完全根区域，不使用 -b 选项将创建稀疏根区域）
zonecfg:<zone_name>> set autoboot = true
zonecfg:<zone_name>> set zonepath = /<path>/<zone_name>
zonecfg:<zone_name>> add net
zonecfg:<zone_name>:net> set physical = <network_interface> eg; hme0
zonecfg:<zone_name>:net> set address = <ip_address>
zonecfg:<zone_name>:net> end
zonecfg:<zone_name>> verify
zonecfg:<zone_name>> commit
zonecfg:<zone_name>>^d
#
# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- <zone_name> configured /<path>/<zone_name>
#
# zoneadm -z <zone_name> install
#
# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- <zone_name> installed /<path>/<zone_name>
#
# zoneadm -z <zone_name> boot
# zlogin -C <zone_name>

<== Here give all the required input such as Lang, TERM type, hostname, NIS etc.
....
SunOS Release 5.10 Version s10_u1wos 64-bit
Copyright 1983-2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: <zone_name>
NIS domain name is <nis_domain_name>

各种区域中均支持安装 Web Server 7

已针对各种方案和各种区域对 Web Server 7 安装进行了测试，如下所述：

    * 在全局区域中安装 Web Server。可在创建本地区域之前和之后安装 Web Server。
    * 在完全根本地区域中安装 Web Server。可在创建其他本地区域之前或之后或在全局区域中安装后安装 Web Server。
    * 在稀疏根本地区域中安装 Web Server。可在全局区域或其他本地区域中安装之前或之后安装 Web Server。
    * 在任何区域（全局或本地）中安装 Web Server，然后删除其他本地区域（全局区域除外）。即使删除其他本地区域，也不会影响 Web Server 安装。
    * 在全局区域中安装 Web Server 管理服务器，然后通过管理服务器在其他本地区域中创建实例（完全根区域或稀疏根区域），前提是先在这些本地区域上安装管理代理并将其注册到管理服务器。这样，便可创建全局管理服务器，以便提升管理和安全性。


Web Server 7 的典型实际实现

下面举例说明了一种应用方案。在此方案中，节点已在防火墙（隔离区或 DMZ）之后的不同区域中配置，而管理服务器已在其他防火墙（非隔离区或 MZ）之后配置，因此，管理服务器最安全，且最不易受外界影响。其中一个节点可以配置为反向代理服务器。为了提升安全性，反向代理服务器既可在防火墙之外，也可位于 DMZ 之内。实际的 Web 服务器使用反向代理服务器进行访问。反向代理服务器通过防火墙从实际的 Web 服务器检索 Web 资源，因而可以极大地避免利用漏洞实施攻击。DMZ 可以包含一个目录服务器，而 MZ 可以包含一个数据库服务器。

web_server_zones_fig_th.gif (15.81 KB)

2008-6-13 18:03

位于 MZ（非隔离区）之中：管理服务器（位于 MZ 之中时要用的专用/未注册的 IP 地址）

位于 DMZ（隔离区）之中：节点（上图中的 IP 地址并不是真的；仅用作示例）

已在服务器中配置四个不同的区域，如以上示例 DMZ 区域中所示。主机名和类型如下所述：

    * GZ-1：全局区域
    * WRZ-1：完全根本地区域
    * SRZ-1 和 SRZ-2：稀疏根本地区域

GZ-2 是另外一种可以配置为反向代理的服务器。

不同的安装和配置选项

在上例中，需要安装一个管理服务器，以及一个或多个节点（上例中是四个节点），以便创建服务器群。

安装管理服务器的方法

CLI 模式：通过 console 安装管理服务器。

运行 ./setup --console。

接受“许可证协议”之后，选择“自定义安装”，然后选择“作为管理服务器安装”。需要指定 SSL/非 SSL 端口。

GUI 模式：通过 GUI 安装管理服务器。

./setup 将调用 GUI 屏幕进行安装。

接受“许可证协议”，选择组件和 Java 配置之后，选择“自定义安装”，然后选择“作为管理服务器安装”。需要指定 SSL/非 SSL 端口。完成安装过程。此外，可以指定自己的 Java 路径。所需的 J2SE 版本至少为 1.5.0_08 (UNIX) 和 1.5.0_07 (Windows)。

安装管理代理使节点属于服务器群的方法

CLI 模式：通过 console 为节点安装管理代理。

运行 ./setup --console。

依次选择“自定义安装”和“创建管理节点”。指定主机名和端口。在安装期间，可将节点注册到管理服务器。系统提示进行注册时，请指定要注册该节点的远程管理服务器的主机名和端口。

GUI 模式：通过 GUI 安装管理代理。

./setup 将调用 GUI 进行安装。

依次选择“自定义安装”和“创建管理节点”。指定主机名和端口。在安装期间，可将节点注册到管理服务器。系统提示进行注册时，请指定要注册该节点的远程管理服务器的主机名和端口。

将节点注册到管理服务器的方法

如果在安装期间没有注册节点，仍可在安装后使用 wadm 命令从某个节点注册这些节点。管理服务器必须在运行，以使注册成功。

在安装管理代理之后注册节点：

../wadm --host=<admin-server-host> --port=<admin-ssl-port> \
--user=<admin-user> （将提示输入口令）

wadm> register-node

注销节点（如果需要的话）：

../wadm --host=<admin-server-host> --port=<admin-ssl-port> \
--user=<admin-user> （将提示输入口令）

wadm> unregister-node

创建群集配置

前提条件：必须存在服务器群。通过以上步骤创建服务器群。

群集中的所有实例必须是同构的。

假定：配置称作 config1；管理服务器位于名为 AS1 的节点上；注册到该管理服务器的管理代理分别位于名为 WRZ-1、SRZ-1 和 SRZ-2 的节点上。

   1. 创建配置。

      wadm> create-config --http-port=3456 --server-name=AS1 config1

      GUI 导航：“常见任务”-->“配置任务”-->“新建配置”
      可以使用此进程创建多项配置。
   2. 创建实例。

      wadm> create-instance --config=config1 AS1

      GUI 导航：a) 实例可在创建 config 时创建，如步骤 1 所述。在该向导中，第一页是“配置信息”-->“下一步”-->“侦听器属性”-->“下一步”-->“配置属性”-->“下一步”-->“创建实例”。
      b) “常见任务”页。选择配置。单击“新建实例”。
   3. 创建多个实例。

      wadm> create-instance --config=config1 AS1 WRZ-1 SRZ-1 SRZ-2

      GUI 导航：a) 与步骤 2a 相同。位于“创建实例”页时，选择多个节点，然后添加全部节点，以便创建多个实例。
      b) 与步骤 2b 相同。简单的群集配置现已完成。要使这些配置处于活动状态，必须在本地和远程节点上对其进行部署，如下一步所述。
   4. 部署配置。

      wadm> deploy-config config1

      GUI 导航：转到“配置”选项卡。通过选中相应复选框选择所需的配置。使用“更多配置操作”下拉菜单，选择“部署”。

群集配置现已准备就绪。

会话复制

执行群集操作之后，下一个重要步骤是，对会话复制进行配置，使实例中部署的应用程序的会话可以进行故障转移。会话故障转移的目的是为了使 Web 应用程序具有高可用性。通过在同一群集的两个服务器实例之间复制 HTTP 会话，轻量级会话故障转移可以实现上述目标。此后，每个 HTTP 会话都在远程实例上拥有备份副本。如果单个节点在任意特定时刻出现故障，使群集中的一个实例呈现为不可用，则该群集仍将保持会话的连续性。

   1. 创建配置，然后创建多个实例，如上所述。
   2. 启用会话复制：

      wadm> set-session-replication-prop --config=config1 enabled=true

   3. 部署配置，并启动所有实例。
      GUI 导航：“配置”-->“实例”--> "Java" -->“会话复制”。
      通过部署所有 Web 应用程序并从客户机访问同一目标来检查上述配置。

部署 Web 应用程序

   1. 使用 CLI 向配置中添加 Web 应用程序：

      wadm> add-webapp --config=config1 -vs=config1 -uri=/simple warfile

      GUI 导航：单击 config 之后，单击 VS。然后，选择“添加 Web 应用程序”。
   2. 部署 Web 应用程序，并访问所有实例。
   3. 您也可以使用 ant 部署简单的 Web 应用程序。

监视

这项功能提供了运行时组件和进程的状态方面的信息，可以用来：

    * 确定性能瓶颈
    * 调整系统以获得最佳性能
    * 有助于规划容量
    * 预测故障
    * 出现故障时分析根本原因

此外，这项功能有时可以用来确保一切如期正常运行。

通过 wadm 命令，可以获得本地和远程实例的监视数据。下面是一些重要的监视命令：

wadm> get-stats-xml-prop --config=name --vs=name
    获得特定节点上特定配置的统计信息
wadm> enable-stats-xml [--uri=uri] --config=name --vs=name
    通过浏览器获得特定配置和特定节点的统计信息
wadm> get-perfdump-prop --config=name --vs=name
    获得特定节点上特定配置的 perfdump 值
wadm> enable-perfdump --config=name --vs=name
    通过浏览器获得特定节点上特定配置的 perfdump 值
wadm> get-webapp-stats --config=name --vs=name --uri=path-of-web-app-uri
    获得特定 Web 应用程序的统计信息
wadm> get-virtual-server-stats
    获得特定虚拟服务器的统计信息

GUI 导航：选择“监视”-->“实例”。

反向代理

正如前面所述的那样，上述方案中的其中一个节点可以配置为反向代理服务器。为了提升安全性，反向代理服务器既可在防火墙之外，也可位于 DMZ 之内。实际的 Web 服务器使用反向代理服务器进行访问。反向代理服务器通过防火墙从实际的 Web 服务器检索 Web 资源，因而可以极大地减少由于漏洞而受到的攻击。借助基本的反向代理功能（包括 URL 重写和循环共享负载平衡），可以使用服务器确保 DMZ 和其他服务器产品的安全。与 NSAPI 过滤器结合使用时，这些功能可以进一步处理代理内容（字符串替换和压缩等）。

前提条件：

    * 反向代理配置名称：RPConfig
    * 原始服务器 1 主机名：WRZ-1
    * 原始服务器 1 端口：3456
    * 原始服务器 2 主机名：SRZ-1
    * 原始服务器 2 端口：3456

1. 配置反向代理，以将请求传递到原始服务器。HTTP 请求是由客户机向 RP 发出。RP 将请求传递到原始服务器：

wadm> create-reverse-proxy --configRPConfig --vsRPConfig --uri-prefix / --server http://WRZ-1:3456

2. 配置反向代理，以将简单粘滞应用程序的请求传递到不同服务器。在这种配置下，第二个 HTTP 请求应该转到为第一个请求提供服务的同一个服务器，而且第二个请求应该可以检索会话信息。

wadm> create-reverse-proxy --configRPConfig --vsRPConfig --uri-prefix \
/ --server http://SRZ-1:3456,http://WRZ-1:3456

GUI 导航：选择“配置”-->“实例”--> "VS" -->“内容处理”-->“反向代理”。

结论

本文旨在为您提供关于如何设置 Web Server 7 的指导性原则。此外，可参阅管理员指南，以了解其他配置详细信息，如设置安全策略、搜索集合和模式匹配等。

由于 Web Server 7 具有许多新增功能，完全改进了管理功能，而且是当今市场上同类产品中最安全可靠且性能最佳的产品之一，因此我相信它肯定会给您带来全新的用户体验。有关更多信息，请查看使用 Java System Web Server 6.1 SP5 的测试结果：Sun Fire T1000 Server with CoolThreads Technology Outperforms All Competing 1U Systems on the Market。http://www.sun.com/smi/Press/sunflash/2006-06/sunflash.20060606.2.xml