分类： 系统运维
2012-05-31 16:57:16
IBM 于 2007 年 11 月对外发布了 AIX 6.1 操作系统，在这之前曾经发布过三个 Open Beta，相信许多用户和合作伙伴已经接触到了 IBM 在新版本 AIX 中提供的新特性。本系列文章旨在带领读者探索 AIX 6.1 中的新特性和对 AIX 5L 中已有功能的增强，并了解这些新特性对用户的影响。首先我们会做一个全面而概括的介绍，然后再针对其中一些亮点独立成篇进行详细介绍。
AIX 6.1 在开发阶段时的版本代号起初是 5.4，由于 POWER 6 处理器的发布，IBM 为了突出 AIX 对 POWER 6 处理器的支持，并与新处理器的命名保持一致，后来将这个新版本定为 AIX 6。因此 AIX 6 虽然提供了很多的新特性和增强，但依然很好的保持了与 AIX 5L 之间的兼容性，绝大多数应用程序在二进制兼容的支持下，不需要做修改即可以运行。IBM 与第三方软件厂商之间也在紧密合作，对第三方软件产品（如 Oracle 数据库）进行兼容性认证，相信不用多久，许多第三方软件商即会发布自己的产品与 AIX 6.1 之间的兼容认证信息。
细心的读者可能会注意到比起之前的 AIX 5L，AIX 6 在名称中已经去掉了“L”。这并不代表 AIX 6 已经取消了对 Linux 的支持。相反，由于对 Linux 的兼容支持已经彻底融入 AIX 6，并且 Linux 操作系统也已经完全支持在 IBM POWER 平台上运行，因此 AIX 的名称上已经不再需要加上“L”来突出 Linux 支持。IBM 继续提供 AIX Toolbox for Linux Applications，为 AIX 准备了预编译好的一些常见 Linux 应用的 RPM 安装包（如 GCC，GNOME，KDE，Apache，PHP，Python 等等），可以直接在 AIX 上安装使用。
系统基础功能
硬件支持更新
AIX 6.1 中，支持 CHRP（Common Hardware Reference Platform）架构的平台和以下处理器：
以下处理器的支持已经被移除：
只提供 64 位内核，32 位内核已经被去除。
在 AIX 5L 中，同时提供了 32 位和 64 位的内核。当使用 32 位内核时，系统只支持 32 位的代码，而在 64 位内核模式下，32 位和 64 应用程序都得到支持。下表给出了 AIX 各版本支持的内核。
|
AIX 5.2 |
AIX 5.3 |
AIX 6.1 |
|
|
unix_up （32 位单处理器内核） |
× |
||
|
unix_mp （32 位多处理器内核） |
× |
× |
|
|
unix_64 （64 位多处理器内核） |
× |
× |
× |
从 AIX 5.3 开始，已经不再支持单处理器内核。而从 AIX 5.2ML 03 和 5.3 开始，新安装系统的已经默认是 64 位多处理器内核。在 AIX 6.1 中，由于老的处理器已经不再支持，因此 32 位内核也被移除。AIX 6.1 中的 64 位内核保持了对 32 位和 64 位应用程序的二进制兼容，32 位应用程序的兼容性不会受到影响。32 位的内核扩展和驱动程序则必须移植到 64 位才能与 AIX 6.1 保持兼容。
图形化的安装界面
AIX 6.1 中提供了图形化安装界面的支持，要启用该方式，必须要满足以下先决条件：
图形化安装有以下限制：
AIX 6.1 中的图形化安装界面为初级用户提供了一个快速和直观的安装界面，可以帮助用户在一个全新的系统上快速安装。对于高级用户，选择旧的文本安装模式则更加合适。
限制每用户的进程数量和每进程的线程数量
AIX 6.1 提供了对系统资源更加细粒度的控制手段，可以对每用户的进程数量和每进程的线程数量进行限制。与其他的 ulimit 限制一样，可以通过 chuser 命令对某个用户的资源限制进行永久修改，也可以用 ulimit 命令对当前 Shell 的限制进行动态修改。
下表给出了 AIX 5.3 和 6.1 系统上 ulimit –a 命令的输出：
|
AIX 5.3 |
AIX 6.1 |
|
|
Ulimit -a |
time(seconds) unlimited |
time(seconds) unlimited |
修该用户的进程数限制可以使用命令 ulimit –a 或者 chuser nproc=X nproc_hard=Y
修改每进程的线程数可以使用命令 ulimit –r 或者 chuser threads=X threads_hard=Y
线程模型（Threading Model）默认从进程域 (M:N 模型 ) 改为系统全局域 (1:1 模型 )
在 AIX 5L 中，pthread 线程的默认模型是 m:n 方式，而从 AIX 6.1 开始，默认改为了 1:1 方式。这两种方式在系统中通过 AIXTHREAD_SCOPE 环境变量来进行控制。如果设置 AIXTHREAD_SCOPE=P，则线程模型为进程域（M:N 模型），设置 AIXTHREAD_SCOPE=S 则为系统域（1:1 模型）。
1:1 模型下，每个用户空间的线程都对应于内核中的一个线程，线程的调度由内核在系统全局范围进行；而 M:N 模型下，多个用户线程对应于内核中的多个内核线程，用户线程调度仅限于在本进程范围内进行，而对应的内核线程则交由内核进行调度。许多应用程序例如数据库和 Java 应用要求设置为 1:1 方式以提供更好的性能，在 AIX 5L 中这些应用程序会要求配置 AIXTHREAD_SCOPE 环境变量，而在 AIX 6.1 中默认即为为 1:1 方式，不再需要进行配置。
关于 AIX 线程模型的更详细信息，可以参见 AIX 信息中心：
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftungd/doc/prftungd/thread_tuning.htm
POWER 6 上的动态可变的内存页大小支持
IBM POWER 处理器支持使用不同的页面大小来管理内存，在 AIX 中也提供了各种机制来使用各种大小的内存页。
以上几种内存页大小中，Large page 和 Huge page 的使用对应用程序来讲与普通的内存页不同，应用程序必须要针对其进行特别设计，并单独配置、分配和管理。64 KB 作为 POWER 5+ 处理器新增的尺寸，在 AIX 5.3 中需要通过 LDR_CNTRL 环境变量来为应用程序指定，使用时对应用透明。而在 AIX 6.1 中为 64 KB 页提供了自动的支持：当运行在 POWER 6 处理器上时，AIX 6.1 会根据情况，在需要时自动将 16 个 4 KB 页归并成为一个 64 KB 页对待，或者将一个 64 KB 页自动拆开成为 16 个 4 KB 页进行操作。使用 svmon 命令的 -P 参数可以查看进程的 64 KB 页使用的情况
支持最大物理内存容量增加
AIX 6.1 支持的最大物理内存大小达到了 32TB，相比于之前版本的最大 16TB，提供了更大的内存空间，为支持更大规模的应用负载做好了准备。
NIM NFS4 支持
IBM AIX 从 5.3 开始提供了 NFS v4 协议的支持，相比于 NFS v2, v3，NFS v4 优势在于：
在 AIX 6.1 中，NIM 已经与 NFS v4 集成到了一起，在创建资源时可以指定 NFS 协议版本和认证方式，进一步提高了 NIM 的灵活性和安全性。
X-Windows 升级
AIX 6.1 中的 X-window 系统升级到了 Release 7.1，并为以前的 R5 和 R6 版本提供了兼容文件，以支持老旧的应用程序。
国际化支持加强
AIX 6.1 进一步增强了国际化支持，包括以下几个方面：
存储、I/O 和文件系统
LVM 配置和跟踪日志
在 AIX 6.1 中新增加了以下措施，以增强 LVM 系统的可用性：
gsclvmd 故障管理增强
gsclvmd 子系统的故障处理和记录功能得到了增强，gsclvmd 进程会对出现的故障进行归类记录并采取相应的动作，比如关闭磁盘卷组。
JFS2 无日志模式
AIX 6.1 中的 JFS2 文件系统现在支持以无日志的模式来 mount，此模式可以提高 JFS2 I/O 性能，但是在出现故障时也无法通过日志记录来恢复文件系统错误。无日志模式适用于数据完整性不太重要，或者数据能够很容易的重新恢复的情况，如将文件备份恢复到磁盘时，将文件系统用作临时存储时。
要使用无日志模式，可以在 mount 文件系统时使用 -o log=NULL 参数，或者编辑 /etc/filesystems 文件，修改该文件系统对应的 log 属性条目。
JFS2 内联快照
从 AIX 5.2 开始，JFS2 文件系统即支持创建快照 (Snapshot)。快照是文件系统在某个时刻的状态和内容的记录，自快照创建后，它的内容即固定下来了。一个文件系统可以有多个快照，快照可以直接备份，或者供原文件系统作为回滚点。在 AIX 6.1 以前，JFS2 文件系统的快照必须保存在一个单独的逻辑卷（LV）上，从 AIX 6.1 开始新引入的内联快照（Inline Snapshot）允许快照内容保存在原文件系统上，访问和管理更加方便快捷。
内联快照保存在该文件系统的 /mount_point/.snapshot/snapshot_nam e 目录下，可以直接进入该目录查看和访问内容。SMIT 菜单也做了相应增强，与外部快照一样，可以对文件系统创建内联快照并直接进行备份。
加密文件系统
AIX 6.1 中新增加的 EFS( 加密文件系统 ) 提供了细粒度的文件加密支持，用户可以选择对某个文件或者目录进行透明加密，文件在写入磁盘时自动加密，从磁盘读入到内存时自动解密。只有持有密钥的用户，才被允许访问加密后的数据。在需要对敏感数据进行保护的环境中，EFS 可以提供很好的保护。
要使用 EFS，必须安装 AIX 6.1 Expansion Pack 光盘上的 Crypto Library 软件包（clic.rte 文件集），并开启 RBAC 支持（默认即处于开启状态）。
需要注意的是：
iSCSI 增强
AIO 动态调整
在 AIX 5L 中，AIO 的管理接口以 aio0 和 posix_aio0 两个设备的形式出现，AIO 子系统默认不会加载，如要启动 AIO 支持，需要将 aio 设备启用，重新启动系统后才能生效。对 AIO（minservers/maxservers/maxreqs）参数的调整，需要使用 chdev 命令修改 aio0 或者 posix_aio0 设备的属性，然后重启。从 AIX 5.3 TL5 开始，引入了 aioo 命令，使得对 minservers/maxservers/maxreqs 参数的调整可以动态进行，不需要重新启动系统。
AIX 6.1 中，AIO 的支持更加动态。AIO 子系统默认即加载，但不激活。应用程序发起 AIO 请求时，AIX 内核会自动激活 AIO 子系统。对 AIO 参数的调整与其他 I/O 参数一样统一使用 ioo 命令。
网络
1.IPv6 增强
AIX 6.1 中对 IPv6 支持做了以下增强：
这些更新使得 AIX 6 对 IPv6 的支持更加完善，性能更优，能更好的应用于 IPv6 网络。
2. 支持 IGMPv3 协议
IGMP v3（Internet Group Management Protocol v3）协议对原有的 v1 和 v2 版本的协议进行了增强，可以针对来源地址对数据包进行过滤。IBM 在 AIX 5L 中实现了 IGMP v1 和 v2，在 AIX 6.1 中新增加了对 v3 协议的支持。
3.NFS 增强
IBM 在 AIX 6.1 中对 NFS 做了如下增强：
以上的增强使得 AIX 在大型企业级的 NFS 文件服务中的性能，安全性和健壮性都有了较大的提高。
4. 内置 FTP 服务支持 SSL
AIX 6.1 开始，FTP 服务支持 TLS（Transport Layer Security）协议，可以对 FTP 的数据和命令通道进行传输加密。要使用此功能需要安装 Expansion Pack 光盘上的 openssl 软件包并配置 /etc/ftpd.conf 文件。具体的配置信息请使用 man ftpd 命令查看手册。
通过 TLS 加密方式使用 FTP 使得用户认证信息不再以明文方式在网络上传输，因此能大大提高 FTP 服务的安全性，但是由于数据加密需要消耗处理器资源，因此和会对性能造成影响。在需要大吞吐量的 FTP 服务时，要仔细评估加密所带来的影响。
注意：AIX 默认开启有 telnet 服务。由于 telnet 服务也采用明文方式传输用户帐号和密码信息。因此如果需要保证远程访问的安全性，仅仅将 FTP 服务使用 SSL 保护是不够的。建议将 telnet 服务关闭，使用 ssh 方式提供远程登录服务。AIX 在 Expansion Pack 光盘上提供了 openssh 软件包，提供了 ssh 客户端和服务器端程序，安装后即可使用。
5. 名字解析缓冲
IBM 在 AIX 6.1 中引入了一个称之为 netcd 的系统服务，负责缓存本地应用程序对以下记录的查询请求：
当应用程序进行查询时，netcd 进程会将查询记录缓存下来并设置一个超时时间（TTL），在这个时间到期前，任何对同一个记录的查询将直接从 netcd 的本地缓存返回，而不需要再次连接服务器进行查询。对于有大量查询请求的应用程序，该项改进可以大大改善查询的性能，毕竟对于每次查询都与服务器建立连接，发送查询并等待返回是一个相当耗时的操作，尤其是在负责解析的服务器比较繁忙或者网络带宽有限的情况下。
与 netcd 服务同时提供的还有 netcdctrl 命令，可以用于查看和刷新 netcd 的缓存状态，或者设置日志级别。
6. 集成 NDAF
NDAF（Network Data Administration Facility）提供了基于 NFS4 协议的网络文件服务的中心管理和数据复制和同步环境。使用 NDAF，系统管理员可以通过多台 AIX 服务器提供一个单一的 NFS v4 文件服务，并由一个单一控制点在这些服务器上创建和同步数据。NFS 客户端可以使用一个统一的名字空间（也就是 NFS 服务器上输出的路径）来访问数据，即使数据实际上位于不同的服务器上。AIX 5.3 TL5 中引入了该功能，包括在 Expansion Pack 光盘中，而从 AIX 6.1 开始它被集成进了安装 CD 成为基本系统的一部分。
性能
1. 默认安装后的性能参数已经经过调整，性能更好
当用户在 AIX 系统上安装应用程序时（尤其是大型的应用软件，如数据库，中间件等）经常会需要按照其要求配置 AIX 系统，如设置 VMM 参数，配置 AIO/CIO 等。IBM 据此对 AIX 6.1 的系统配置和参数做了相应的调整，以提高系统安装后的默认配置下的性能，减少系统管理员需要做的额外工作。
改变了的配置主要包括：
2. 受限制的调整参数 (Restricted tunables)
AIX 6.1 中对系统参数调整命令（vmo，ioo，schedo，no，nfso，raso）做了更新，增加了一类称之为“受限”的参数。此类参数能对更多系统内部行为进行调整，但同时也可能由于不适当的修改导致影响系统稳定性和数据完整性。因此除非有 IBM 开发人员的参与和指导，否则普通用户和系统管理员不应改变这些参数。
受限参数默认在使用 vmo/ioo/schedo/no/nfso/raso 命令查看参数列表时（-a，-L，-x 参数）不会显示，如要查看，必须要同时使用 -F 参数。例如下列 raso 命令的输出结果：
| # raso –a -F kern_heap_noexec = 0 kernel_noexec = 1 mbuf_heap_noexec = 0 mtrc_commonbufsize = 3799 mtrc_enabled = 1 mtrc_rarebufsize = 199 tprof_cyc_mult = 1 tprof_evt_mult = 1 tprof_inst_threshold = 1000##Restricted tunables recovery_action = 1 recovery_average_threshold = 5 recovery_debugger = 0 recovery_framework = 0 |
其中加粗标出的部分就是“受限参数”。在修改这些参数时，会有警告提示，如要做永久修改，必须要经过确认才会生效，并且在系统启动时会记录一条 errlog。
再次提醒：这些受限参数必须要在 IBM 专业人员的指导和要求下才能进行修改，否则可能造成系统不稳定或者数据丢失，IBM 不为用户自行修改造成的问题负责。建议用户在任何情况下需要修改受限参数时都先做好数据备份。
3. 性能监控工具更新
由于 AIX 6.1 支持新的硬件和提供了新的特性，性能监控的工具也进行了相应的更新以反映新的数据。更新主要包括：
虚拟化
1. 工作负载分区（Workload Partitions）
AIX 6.1 在虚拟化方面的最大变化就是引入了 WPAR。WPAR 是纯软件的虚拟化解决方案，他与 IBM POWER 平台上传统的 LPAR（逻辑分区）方案有着本质上的不同，下表给出了 LPAR 和 WAPR 的简单比较，更多的内容会有专文进行阐述。
|
LPAR |
WPAR |
|
|
实现技术 |
硬件支持，POWER 处理器加 Hypervisor（微码内置功能） |
软件功能，由 AIX 内核实现 |
|
管理方法 |
HMC 或 IVM |
AIX 系统命令，WPAR Manager |
|
特点 |
一个服务器，多个物理或虚拟设备，多个 OS |
一个 OS，一套物理或虚拟设备，多个应用环境 |
|
操作系统 |
AIX 或者 Linux |
仅 AIX 6.1 |
|
成本 |
需要购买 APV |
随 AIX 6 附带，无额外费用。 |
承载 WPAR 的 AIX 系统在 WPAR 的术语中称之为全局环境（Global Environment），它既可以运行在一个物理机器上，也可以是一个 LPAR。WPAR 相比于 LPAR 是更加轻量级的虚拟化解决方案，它与全局 AIX 环境共享处理器，内存，网络和文件系统资源，创建和初始化操作简单快捷。
WPAR 又分为系统 WPAR（System WAPR）和应用 WPAR（Application WPAR）两类。系统 WPAR 是一个完整的 AIX 环境，拥有独立的资源，如独立的 init 进程树提供网络服务，独立的文件系统，用户帐户等。创建系统 WPAR 的过程实际上包括了 AIX 软件包安装的过程。对于用户来讲，访问 WPAR 与其他独立的 AIX 系统差异不大，既可以登录到终端，可以使用 telnet 连接。而应用 WPAR 则是一个更加精简的环境，它只包含应用程序特定的进程和相应的内核支撑环境，它不包含自己独立的资源，只能共享使用全局环境的资源。当应用 WPAR 中包含的应用程序启动时，它也就启动，当应用停止时应用 WPAR 也就被删除了，因此从用户的角度来看它更加接近于传统的 chroot。
WPAR 为用户带来了以下好处：
要注意的是，LPAR 和 WPAR 两者之间并不冲突，完全可以互补。
2.WPAR 动态应用迁移，使用 IBM Workload Partition Manager?
动态应用迁移（Live Application Mobility）是 AIX 6 WPAR 提供的一项高级特性，它允许 WPAR 动态的移动到另外一个系统上，而不影响其中应用的持续运行。该功能的关键特点在于：
Workload Partition Manager 是 IBM 单独销售的专用于 WPAR 管理的软件平台。它除了为 Live Application Mobility 提供支持外，还可以对 WPAR 进行创建，修改，删除，监控等管理操作，并支持对多台服务器实行集中式图形化管理。如果不使用 WPAR Manger，管理员只能够使用基本的命令行工具或者 SMIT 来管理 WPAR，因此即使不需要 Live Application Mobility 功能，也推荐使用 WPAR Manager 来降低 WPAR 管理的复杂度。
Live Application Mobility 可以被用来进一步提高灵活性和可用性。当平台需要进行升级，或者由于故障需要停机维护时，通过此功能可以将工作负载动态的切换到其他硬件上，在不影响应用的同时即可完成维护任务。
3.Live Partition Mobility 支持
Live Partition Mobility 是 IBM POWER 6 的平台提供的新一代虚拟化高级特性，它使得逻辑分区（LPAR）可以在物理系统之间动态迁移。与 WPAR 的 Live Application Mobility 类似，它也可以帮助提高应用的灵活性和可用性。
Live Partition Mobility 需要 POWER 6 硬件平台的支持，被迁移的 LPAR 内运行的操作系统也必须要支持此特性。IBM 在 AIX 6.1 和 5.3 TL7 中增加了对 Live Partition Mobility 的支持。
4. 支持多个共享处理器池（Multiple Shared Processor Pools）
多个共享处理器池是 POWER 6 平台引入的虚拟化新特性。在 POWRE 5 平台上，所有的共享处理器（Shared Processor）逻辑分区（LPAR）都使用一个统一的、系统全局的处理器池（Processor Pool），并从中取得自己的处理器资源。POWER 6 对这一特性做了增强：一个物理系统中可以有多个处理器池，每个池可供一个或多个（即一组）LPAR 使用，并且处理器池中的处理器数量和 LPAR 数量都动态可调，这样可以按组来控制 LPAR 的处理器资源分配。AIX 6.1 和 AIX 5.3 TL7 系统的对这一特性提供了支持，并升级了性能工具以支持获取系统处理器池的信息。
可管理性
1.IBM Systems Director Console
IBM 为 AIX 用户提供了多种手段来执行 AIX 管理任务，每个管理员都可以选择自己习惯的方式以最高的效率来执行。AIX 5L 中提供的管理手段包括：
在 AIX 6.1 中，新增加了称之为 IBM Systems Director Console 的管理工具。该工具提供了基于 Web 界面的管理手段，因此不需要安装客户端，任何能运行受支持的浏览器的系统都可以连接到该工具执行管理任务。系统管理员通过 IBM Systems Director Console 界面可以访问到：
通过将系统管理任务集成到 Web 界面，AIX 6.1 提供了更加简便高效的管理手段，对于降低管理难度和成本具有很大的意义。而对于熟练的系统管理员，如不需要使用 IBM Systems Director Console，则可以将其关闭以节省系统资源，只需要将 /etc/inittab 中 pconsole 子系统对应的启动条目删除即可。
2.Workload Manager 增强
工作负载管理器（Workload Manager）是 AIX 系统内置的资源控制系统，管理员可以使用 WLM 来控制处理器，内存，I/O 资源的分配。在 AIX 6.1 中，WLM 的功能的到增强，用以控制 WPAR 的资源分配。事实上，WPAR 的资源分配控制功能在底层正是由 Workload Manager 提供。但要注意的是，WPAR 的资源控制操作不应该通过 WLM 来直接进行，而应该使用 WPAR 的管理工具，如 WPAR Manager。并且目前 WLM 只支持在全局环境中运行，控制全局环境中的应用或者 WPAR 的资源，而不支持在 WPAR 内运行。
可用性
RAS 组件框架
企业级的 RAS（Reliability，Availability，Serviceability）历来是 IBM System p 服务器和 AIX 操作系统的核心优势，在 AIX 6 中，其 RAS 特性又有了大幅增强，提供了一个组件式的 RAS 基础框架，其中包含以下组件（又称之为 Domain）：
基于这个框架，AIX 系统自身的各个部分和第三方的软件都可以向系统注册并执行其特有的故障检测和控制，tracing 和 dump 等功能，以提供更加强大和灵活的 RAS 特性。
伴随着 RAS 组件框架还增加了一系列的系统管理命令，其中最主要的是 errctrl，ctctrl 和 dumpctrl 命令，可对各个 AIX 各个子系统或者设备的 RTEC，CT 和 CD 属性进行控制。
Dump 功能的增强
Dump 是 AIX 系统中用于故障诊断的一项非常重要的功能，dump 数据中包括了故障发生时的内存内容和处理器状态等信息，可用于重现故障时的场景以进行分析。旧式的 dump 方法是在崩溃时对整个系统的内存都进行转储，由于现代系统的物理内存越来越大，进行一次完整 dump 的时间也越来越长，间接的增加了由于宕机带来的停机时间。AIX 6 中引入了几种新的 dump 手段，更加灵活方便，对业务影响更小。下表对各种 dump 方式做了总结：
|
方式 |
AIX 版本 |
说明 |
|
传统 dump |
所有 |
原始方式，随着 CPU 数量的增加，物理内存的加大，dump 需要的时间也越来越长。 |
|
Minidump |
V5.3 TL3 |
数据不是像传统的 dump 方式那样保存到磁盘上，而是保存到 NVRAM 中，系统下次启动时，再写入到 error log 中。因此 Minidump 的容量非常小，只保存了关键的信息，同时转储所需要的时间也很短。 |
|
Parallel dump |
V5.3 TL5 |
Dump 数据存储的格式发生改变，数据块以无序方式存储，使得多处理器的系统可以按照每个处理器同时转储一块区域的方式将内存数据写入到 dump 设备。此改进使得大型系统（多 CPU，大内存）的 dump 速度得到大大提升，仅仅受限于 I/O 速度。 |
|
Component Dump |
V6 |
在上一主题“RAS 组件框架”中我们已经提到，Component Dump 使得管理员可以对 dump 的详细程度和各组件的 dump 属性进行更加精确的控制。 |
|
Live Dump |
V6 |
Live Dump 方式基于新的 Component Dump 框架。执行时，只有那些注册到 CD 框架并且声明为支持 Live Dump 特性的组件才会有数据转储。Live Dump 还有另外一项非常重要的特性，就如其名称表明的一样，在 dump 时不需要重新启动系统。因此 Live Dump 方式减少了需要转储的数据并显著的降低了 dump 所需要的停机时间。 |
|
Firmware-Assisted Dump |
V6 |
传统的 dump 方式实际上是由已经发生故障的 AIX 内核进行的，这样存在两个问题：
在 POWER 6 平台上，系统微码引入了对 AIX dump 的支持。AIX 6 可以在发生崩溃时立即重启，系统微码会保护崩溃时的内存区域的内容不受影响。在 AIX 6 系统启动过程中，内核会将由微码保护起来的内存区域转储并释放。使用此方式，dump 的可靠性得到了大幅提升。 |
可见，在 AIX 6 中，dump 方式的改进主要在于可更加细致的控制 dump 的内容，减少 dump 对系统的影响，增加 dump 过程的可靠性这几方面。
Storage protection keys
Storage protection keys 是 POWER 6 处理器新增加的一项功能，系统内存可以按照区域分配不同的 key，通过硬件提供支持来保证只有持有正确的 key 的代码可以修改其内容。该技术可以应用在 AIX 内核或者用户应用程序代码中，防止由于代码的错误行为（无论是有意还是无意）而可以任意破坏其它内存区域，因此可以进一步提高系统的稳定性。AIX 5.3 TL6 中加入了 Storage protection keys 的 API，应用程序可以使用此功能，但是内核并不支持使用 key 来保护。而 AIX 6 中，内核代码和用户应用代码都可以使用 Storage protection keys 功能。
内核故障恢复
作为系统的关键部分，AIX 内核的稳定性直接影响到整个系统的可用性。如果内核出现了错误，往往造成整个系统直接崩溃。AIX 6 内核包括了自动故障恢复功能（Kernel error recovery），当错误出现时，可以自动采取动作，避免造成崩溃。
AIX 6 内核中增加了一个称之为恢复管理器（Recovery Manager）的组件，所有需要提供故障自动回复的内核组件或者扩展模块都会向 Recovery Manager 注册其特定的恢复例程（Recovery Routine）。当某个组件发生错误时，它会产生一个异常，将执行转交给 Recovery Manager，由其执行该组件的恢复例程。当恢复例程执行结束后，Recovery Manager 会将执行交还该组件，使其继续运行下去。
恢复例程内通常会执行以下操作，使得出错的组件可以恢复到正常的执行状态：
恢复例程通常在尝试进行任何恢复动作前会先触发一个 Live Dump，并在 AIX error log 中会记录一次内核故障恢复事件（Lable 为 RECOVERY、RECOVERY_NOTIF 或 RECOVERY_TIME）。
内核故障恢复功能的开启可以通过 raso 命令来进行控制，包括受限参数 recovery_action、recovery_average_threshold、recovery_debugger 和 recovery_framework。也可以通过 SMIT 菜单来访问，快捷路径为 krecovery。
在线内核升级（Concurrent update）
在 AIX 6 之前的版本中，任何对 AIX 内核进行更新的操作之后都必须要执行 bosboot 命令更新 Boot LV 然后重新引导系统才会生效，在补丁升级任务结束后经常会看到这样的提示信息，
| * * * A T T E N T I O N * * * System boot image has been updated. You should reboot the system as soon as possible to properly integrate the changesand to avoid disruption of current functionality. |
就是因为这个原因。因此当 IBM 发布一个关键的内核补丁时，用户通常会面临一个两难的局面：如果升级补丁，必须要重新启动，这会带来一段宕机时间；而如果不更新补丁，又会面临潜在的问题。
AIX 6 通过引入在线内核升级（Concurrent update）功能改善了这个问题，该功能的特点在于：
换页空间校验
AIX 6 增加了对换页空间（Paging space）数据的正确性校验，通过记录被换页的内存数据的校验和（checksum），AIX 6 确保内存数据在写入到磁盘时和从磁盘读入时是一致的。如果校验数据表明 Paging space 中的数据不正确，AIX 会记录一个错误日志，并根据错误的内存数据属于哪个区域而采取相应的行为：如果属于内核使用的系统内存，那么停机；如果属于应用程序使用的部分，则给相应的进程发送异常信号。
Paging space 的中的数据以 4KB 为单位计算校验和，校验和长度（checksum size）可以在 8/16/32 bit 中进行选择，如果 checksum size 设置为 0，则关闭了该功能。当打开校验功能时，每个 Paging space 设备会对应一段大小为 256MB 的专用内存区域，用来记录存储到该设备上的每个内存页的校验和。Paging space 的校验和长度设置记录在 /etc/swapspaces 文件中，可以在创建时使用 mkps –c 参数来指定，也可以在创建好之后使用 chps –c 参数来修改。
安全
Trusted AIX
Trusted AIX 是 AIX 6 提供的一种工作模式，在此模式下，AIX 系统使用 Label 对系统中的 Subjects（通常是系统中的进程）和 Objects（被访问的资源，包括文件，内存中的 IPC 对象，网络数据包，以及其他任何资源）进行标记，说明其安全属性。相比于普通的 AIX，在 Trusted AIX 环境下某个 Subject 是否可对某个 Object 执行相应的操作，均需根据其附属的 Label 来进行判断，而通过合理的设置 Label，可以对系统上的数据进行不同级别的保护。
在普通的 AIX 环境下用户可以使用以下一些手段来对数据进行隔离和访问控制：
这些手段也是 UNIX 世界中传统的方式，简单，实用，但是却有着各种不足，例如：
Trusted AIX 在这些传统方法的基础之上进一步提供了更加强大和全面的手段，来加强对数据的保护。在 Trusted AIX 环境下可以做到：
Trusted AIX 设计主要是针对需要极高安全性的用户，例如军事国防等领域。由于控制更加严格，不可避免的增加了管理难度，降低了易用性，并带来一些特定的限制。用户在部署 Trusted AIX 之前需要对此有充分的了解：
Trusted Execution Environment
在 AIX 5L 中有一项称之为 Trusted Computing Base（TCB）的安全特性，该功能主要用于保证关键的系统文件是可信的。TCB 通过 crontab 定时对关键的系统文件属性进行扫描，并将结果与其保存在数据库内的数据进行对比，以鉴别这些文件是否被修改过。TCB 可以在一定程度上保证系统不受被篡改过的程序的危害。AIX 6 中开始提供了一个新的功能，称之为 Trusted Execution（TE） Environment，可以看作为 Trusted Computing Base 的增强。原有的 TCB 仍然可用，用户可以在这两者间选择启用任意一个。
TE 与 TCB 最大的不同在于，TCB 只能依赖于 crontab 这类方法来定时检查关键文件的正确性，两次检查之间会存在一个窗口期；而 TE 除此之外，还可以在文件 每次 被访问（执行）的时刻，即时进行检查，以确保任何时候载入的代码都是可信任的。TE 维护一个称之为 Trusted Signature Database（TSD）的数据库，其中记录了受到保护的文件的各类属性，最重要的是文件哈希值（Hash），通过对比 TSD 中和磁盘上的文件的 Hash 值，即可以判断文件是否处于完整可信，未被篡改的状态。
Trusted Execution 提供了 trustchk 命令来设置 TE 的工作策略，对系统的进行完整性检查和管理 TSD。正如前文曾经提到过的，完整性检查有两种工作方式：
系统完整性检查 在每次系统启动时，或者在 crontab 中定时运行，对整个系统中受到监控的文件的属性进行扫描，与 TSD 中存储的信息进行对比。
运行时完整性检查 在收到保护的文件每次被读入时对其签名进行检查，确保文件始终是可信的，而不是被篡改过（例如插入了木马，恶意代码）。
Trusted Execution 策略可以设置为对执行文件，共享库，脚本和内核扩展模块进行检查；可以锁定 TSD 数据库和受保护的文件为不可修改状态；还可以设置受信任的执行文件和共享库路径，只有在此路径下的执行文件和共享库才能被调用。将这些策略进行适当的设置和组合，可以对系统关键文件的完整性进行灵活而强大的保护。
Trusted Execution 与 Trusted Computing Base 另外一个不同在于，TCB 是安装时的选项，其开启和关闭必须在安装时就进行选择，而 TE 是一个动态选项，可以通过 trustchk 命令来动态控制开启或者关闭。
增强的基于角色的访问控制（Role Based Access Control）
增强的 Role Based Access Control（RBAC）是 AIX 6 中另一项非常重要的安全特性，事实上，从 AIX 4.2 开始便包含了一个 RBAC 应用框架，但该框架有如下不足：
为了解决这些问题，AIX 6 中引入的了一个新的 RBAC 框架，称之为 Enhanced RBAC，原有的框架改称为 Legacy RBAC。
RBAC 的核心思想是将权限细分，并与用户分离，用户在执行某个特权操作时，只需要具有相应的最小权限，而不需要拥有某个特殊的用户身份和其他不相干的权限。RBAC 框架中有以下几个重要的概念：
授权（Authorizations）授权是对用户的能力的定义。在执行任务时，用户必须要具有对应的授权才能够使用特定的命令。
特权（Privileges）特权是对进程的能力的定义。进程需要有足够的特权级才能进行受到安全限制的操作。
角色（Roles）角色是将授权赋予给某个用户的手段。一个角色可以包含有为执行某个任务而需要的多个授权，当该角色被赋予某个用户时，该用户即拥有了这些授权，可以执行对应的系统管理任务。
如果没有 RBAC，系统的权限实际上集中在特定的用户手上，无法分离。典型的是 root 用户，可以访问系统中所有资源，以 root 身份运行的程序也就可以执行任意的操作。如果普通的用户需要执行某个操作，比如管理文件系统，由于权限与用户身份绑定在一起，那么他只能设法以 root 身份来执行任务，例如使用 SUID 的程序。引入 RBAC 支持之后，权限和用户不再是绑定的。用户如果需要某个特权来执行管理操作，他只需要获得相应的授权即可，不需要改变自己的身份。
默认情况下 RBAC 的配置文件位于 /etc/security 目录下，保存了角色，授权，特权命令，特权设备和特权文件数据。对这些配置修改后，管理员需要使用 setkst 命令将配置文件中的数据上传到 AIX 内核中的 Kernel Security Table（KST）才会生效。配置文件数据还可以存放在 LDAP 目录中，该特性由 /etc/nscontrol.conf 文件控制。通过将 RBAC 配置保存在 LDAP 目录中，多个 AIX 服务器可以共享同样的 RBAC 配置，简化企业网络的安全管理。
超过 8 字符的密码支持
AIX 5L 中支持的最大密码长度为 8 个字符长，这是由于密码加密过程算法使用的是 crypt() 调用，该方法会将密码在 8 字节处截断。从 AIX 6.1 和 AIX 5.3 TL7 开始，支持可加载的密码算法（Loadable Password Algorithm），这样 AIX 系统可以支持更多种密码算法来对密码进行加密，并且密码的最大长度也扩展到了 255 个字符（各种密码加密算法支持的最大长度不同）。由于密码算法可变，密码长度更长，用户密码被暴力破解的可能性也就相应降低了。
内核和应用开发环境
ProbeVue
AIX 6 中引入了称之为 ProbeVue 的新的的跟踪手段，它的最大特点在动态跟踪。“动态”意味着应用程序不需要做任何修改就可以在运行过程中随时插入跟踪点，收集执行时的状态数据。而以往的跟踪方法（静态跟踪）需要在程序源代码中加入跟踪点，并在编译时使用对应的选项以生成带跟踪和调试信息的执行文件。由于加入这些额外信息的程序往往执行速度更慢并占用更多内存，因此生产系统通常不会运行运行这些调试版本的代码，导致发生程序发生问题时，往往需要停止原来的生产版本程序，启动带跟踪信息的版本，等待问题再次发生然后进行跟踪调试。相比之下使用 ProbeVue 可以在生产系统中不用中断应用程序，随时可以被跟踪收集信息。
ProbeVue 中重要的概念包括：
Probe 中断正在执行的代码，以收集当时系统状态和进程上下文信息的动作。
Probe Action 在一个 Probe 中执行的具体动作，通常包括收集各种系统全局数据和进程特有的上下文信息的过程，并将这些信息保存到缓冲区，供跟踪工具读取和分析。
Probe Point 程序代码执行过程中可以进行 Probe 操作的位置。ProbeVue 支持两种类型的 Probe Point：Probe Location 和 Probe Event
Probe Location 代码中的某个具体的位置，当执行到这个位置时，该点的 Probe Action 就会被触发
Probe Event 对应于一个抽象的事件（Event）而不是具体的代码位置，当某个 Event 发生时，触发具体的 Probe Action。
ProbeVue 使用称之为 Vue 的专用脚本语言来进行具体的跟踪工作， Vue 脚本的主要内容可以归纳为
Vue 脚本通过将多个 Probe 语句组合到一起可以完成非常复杂的跟踪操作，收集丰富的调试信息，大大的增强了 AIX 系统下的调试手段。
TI-RPC
传输无关的 RPC（Transport Independent Remote Procedure Call）是 AIX 内包含的一套应用编程接口（API），它使得在编写使用 RPC 方式进行网络计算的应用程序时不再需要关注下层具体的传输协议（常见的如 TCP，UDP，或者其他任何支持的网络传输协议）。应用程序只需要关注具体的 RPC 问题，而 TI-RPC 会处理下层的传输细节，这样可以大大增加应用程序的可移植性。
在 AIX 6 之前，AIX 系统内部已经提供了 TI-RPC 接口，主要供操作系统自身使用（例如 NFS 功能），但是 IBM 并不为客户使用该 API 提供支持。从 AIX 6 开始，IBM 正式支持 TI-RPC 作为 AIX 标准的编程接口。同时该接口也保持与 Sun Solaris 系统中的 TI-RPC API 的兼容性，应用程序移植时几乎不需要做任何修改。
总结
到此为止，我们对 AIX 6 中的新增功能和对原有特性的增强做了一个比较全面的介绍，由于篇幅的关系，很多细节没有进行详细的描述，并且还有不少特性由于涉及内容太过于深入也没有介绍到。读者可以参考 IBM 红皮书《IBM AIX Version 6.1 Differences Guide》来学习更多具体的内容。
