【分享】使应用程序支持非全局 zone 的最佳实践

By Chien Yen, 8/18/08                   

摘要：本文将介绍使应用程序能够支持非全局 zone 的最佳实践。本文将重点讨论 Solaris Containers 的 Solaris Zones 特性。

1. 简介

Solaris Containers 技术提供了一个虚拟化的运行时环境，并限制了应用程序可以使用的系统资源（如 CPU）。Solaris Containers 包含两个组件：资源管理（Resource Management）和 Solaris Zones。

Solaris Containers 的资源管理组件解决了各应用程序占用系统资源的问题。例如，可以指定一些 CPU 专门处理某个应用程序，或者允许多个应用程序共享 CPU，同时保持 CPU 的最小数量。支持将 CPU 专门指定给某个应用程序使用，以及在最低保证的情况下共享 CPU 的技术，分别叫做动态资源池（Dynamic Resource Pool）和公平共享调度（Fair Share Scheduler）。

Solaris Zones 分区技术用于虚拟化操作系统服务，并提供了一个隔离和安全的环境用于托管和运行应用程序。zone 分为两种类型：全局 zone 和非全局 zone。

Solaris Containers 提供了一个虚拟化环境，可以通过服务器整合来降低总体拥有成本（TCO）。管理员可以使用资源管理工具和 zone 来创建隔离应用程序和共享系统资源的环境，这种环境称为容器。资源共享不仅可以提高利用率，而且还有助于降低总体拥有成本。

首次安装 Solaris 10 操作系统时，不会安装任何附加的容器，这样整个操作系统就叫做全局 zone。这个全局 zone 的管理员负责通过安装非全局 zone 并给这些 zone 指定资源管理规则，来创建附加容器。各容器中的进程是相互隔离的。这是通过阻止进程从某个非全局 zone 访问另一个非全局 zone 来实现的。

某些约束被应用于非全局 zone 进程，从而实现容器隔离。第 4 节将介绍这些约束的详细信息。由于存在这些约束，非全局 zone 中的进程可能会因为以下原因而无法正常运行：

    * 某些具有权限的系统调用失败
    * 某些设备节点和文件系统不可用
    * 网络控制功能受到限制

因此，为了使应用程序支持非全局 zone，建议对应用程序进行限定。

本文介绍对应用程序进行限定使其支持非全局 zone 的最佳实践。由于以下原因，本文将着重论述 Solaris Containers 的 Solaris Zones 组件：

    * 对于应用程序限定，Solaris Containers 的资源管理方面是透明的。
    * Solaris Zones 特性为应用程序引入了一些新的限制。

根据应用程序类型、 zone 配置和工程设计资源的可用性，建议执行若干个限定过程，使 ISV 可以选择最适合其需要的方案。本文档提供这些限制的技术背景、实现过程以及针对 zone 限定应用程序的逐步过程。

本文涉及 Solaris Ready Test Suite 1.1（或更高版本）；此套件用于帮助您确认应用程序是否能在 Solaris 10 OS 上成功运行。该套件包括 Solaris 应用程序扫描程序，它是一种适合于应用程序 ELF 二进制代码和源代码的快速扫描工具。该扫描程序主要用于检查近期由接口导致的某些故障，或不属于 Solaris 发行版的库。它还提供了 DTrace 脚本，用于检查系统调用、因信号故障导致的应用程序崩溃，以及系统资源使用情况，而且还列出了所有打开的文件和端口。

2. 实现过程

针对非全局 zone 的限定过程最多可能涉及三个单独的操作：

   1. 在非全局 zone 中执行应用程序限定。如果没有发现任何错误，系统还会针对全局 zone 来限定应用程序。
   2. 在全局 zone 中调用脚本以监视在全局 zone 或在非全局 zone 中执行的测试操作。此操作将帮助测试工程师确定与 zone 限制有关的错误原因。
   3. 扫描应用程序源代码，了解与非全局 zone 不兼容的 API 和设备节点的使用情况。如果该工具没有报告任何问题，应用程序就可能同时在全局 zone 和非全局 zone 中工作。此操作增加了在操作 1 中执行的测试的信任级别。

对于要为应用程序添加非全局 zone 支持的 ISV，建议执行操作 1。 ISV 可以选择执行上述所有三项操作、其中的任何一项操作，或这些操作的组合。操作 2 和 3 仅检测运行时错误。如果 ISV 决定仅执行操作 2 或操作 3，则需要单独执行非全局 zone 中的附加安装测试。

ISV 根据以下因素决定要使用哪个限定流程：

    * 应用程序类型：权限与非权限以及设备使用情况
    * zone 配置：文件系统、设备节点、网络以及需要导出到 zone 中的系统资源
    * 测试环境：多级（tier）与多层（layer）软件堆栈
    * 测试套件：有权限和无权限
    * 工程设计资源

下面简要论述了各操作的优缺点。此论述假设典型的应用程序测试过程执行以下操作：

    * 由专门的测试小组执行
    * 遵循的测试计划定义了以下内容：
          o 测试环境
          o 测试过程中使用的工具
          o 安装过程
          o 功能测试
          o 性能测试
          o 接收条件
    * 包括开发小组用于解决测试小组所发现问题的错误报告机制

操作 1：在非全局 zone 中执行应用程序限定。

由于非全局 zone 比全局 zone 的约束更多，因此在非全局 zone 中成功测试后，就会自动为全局 zone 限定应用程序。此操作要求 ISV 首先决定一项 zone 配置或一组 zone 配置，然后在非全局 zone 中执行应用程序安装、功能和性能测试。第 3.1 节中显示了示例的 zone 配置设置。

必须更新测试计划，以反映附加的 zone 配置和设置过程。此操作还要求 ISV 在非全局 zone 中安装和初启功能和性能测试所需的所有测试套件、工具以及其他软件堆栈层。如果工具无法在非全局 zone 中运行，可能需要对测试工具进行修改。

此操作提供所有操作中最完整的测试和最高的信任级别。但是，它需要的工程设计资源比其他操作更多。

操作 2：在全局 zone 或非全局 zone 中执行应用程序限定和监视脚本。

上面提到的套件提供了一个实用程序，用于监视应用程序使用的设备节点以及非全局 zone 中不可用的权限。开始限定测试之前，应先在全局 zone 中启动该套件。可以在全局 zone 或非全局 zone 中执行限定测试。如果该套件没有标记任何警告，则应用程序很可能会在非全局 zone 中成功运行。

以下情况适用于此操作：

    * 不能对要测试的非全局 zone 提供测试工具和其他所需的软件堆栈，或者
    * 需要跟踪仅在非全局 zone 中出现的问题。

操作 2 可以与操作 1 一同执行。在这种情况下，监视脚本将监视非全局 zone 中运行的进程，并且用于确定在操作 1 中所发现错误的原因。对现有测试过程执行的更改处于最低程度。

安装限定将通过单独的测试执行。功能和性能测试在全局 zone 中执行。

操作 3：扫描应用程序源代码，找出与非全局 zone 不兼容的 API 的使用。

该套件包括一个实用程序，用于扫描 ISV 应用程序的源代码，了解非全局 zone 中不受支持的 API 和设备节点的使用。此外，该套件还将扫描第三方库的 ELF 二进制代码，了解第三方二进制代码中与 zone 不兼容的 API 的使用。该套件的输出将帮助开发小组确定与非全局 zone 支持有关的应用程序的潜在问题。此操作对应用程序源代码和二进制代码执行静态扫描，因而不要求测试工程师运行该应用程序。

该工具还将扫描第三方库，了解第三方二进制代码中与 zone 不兼容的 API 的使用。开发小组使用该工具确定支持非全局 zone 的应用程序的潜在问题。该工具可以报告如 open(2)，ioctl(2)，socket(2)，link(2) 和 unlink(2)等函数的一些确定的误报。确定的误报可能是由于以下因素导致的：

    * 获取传递给函数的变量参数的难度
    * 该工具的设计目标，即报告可能导致应用程序出现故障的所有潜在问题

此操作对现有测试过程可能没有影响或影响程度最低。通过此操作，开发小组承担了在非全局 zone 中限定应用程序的大多数负担。这可能不是件坏事，因为如果在测试过程中发现了问题，无论如何也需要涉及到开发小组。可能需要单独的安装测试或文档形式的安装指南来说明潜在的安装问题。

[ 本帖最后由 云杉上的蝴蝶 于 2008-8-21 03:18 编辑 ]