IBM WebSphere 开发者技术期刊: WebSphere Application Server V6 的系统管理

http://www.ibm.com/developerworks/cn/websphere/techjournal/0501_williamson/0501_williamson.html

增强系统管理概述

本文是系列文章 -- 显著增强 IBM® WebSphere® Application Server V6 系统管理功能性的第一篇文章。第一部分提供了每个系统管理增强的概述，后续的文章将集中在单个特性的细节上。

引言

IBM WebSphere Application Server V6 在系统管理特性方面较上一个版本 5 有很大的加强。本文是涉及本领域内产品发展的系列文章中的第一篇。这篇文章提供了第 6 版中系统管理加强的简短介绍，其后续的文章将集中在单个特性的细节上。

这一系列文章面向那些熟悉 WebSphere Application Server V5 系统管理架构的用户。不了解这些概念的读者可以回顾一下为版本 5 所编写的类似的系列文章，也同样发布在 IBM WebSphere 开发者技术期刊上，以及 IBM 出版书籍 IBM WebSphere V5 System Administration（参阅参考资料）。

本文中将主要介绍如下这些方面的增强：

增量单元升级

WebSphere
概要文件

向后兼容能力

端口冲突解决方案

细粒度的应用程序更新

更新应用程序的首次展示

增强的
EAR 文件管理

配置档案文件

管理命令任务

Web
服务器管理

与操作系统的集成

J2EE
1.4 管理规范

系统应用程序

节点组。

回页首

增量单元升级

WebSphere Application Server V6 部署管理器既可以管理 WebSphere Application Server V6 （以后称为版本 6）节点，也可以管理 WebSphere Application Server V5 （以后称为版本 5）节点。这就允许一个单元升级为新版本的一个节点，同时使对单元内运行的应用程序影响最小。图片 1 图示了最中间的单元从版本 5 升级到版本 6。

图片 1. 版本 6 中混合版本的单元



增量移植过程从你的版本 5 的部署管理器向版本 6 移植开始。部署管理器必须一直是移植到新版本的单元的第一个部分，并且必须始终是最高的版本，每个单元内的节点应该是固定的版本，这样就允许它管理单元中所有的节点而不用管它们的版本。

当部署管理器被移植到版本 6 时，单元中的节点保持不变，不管它们在部署管理器升级以前支持什么版本。一旦部署管理器被升级到版本 6，单元中的单个节点就可以被升级。随着增量升级的进行，单元的中心配置存储库将包含版本 5 和版本 6 两种配置文档。配置同步确保只有能被版本 5 运行时所使用的配置文档能够被复制到他们的节点中。

版本 6 中的集群可以运行为下面这两种模式中的一种：

兼容模式时版本 5 和版本 6 的应用程序服务器能够在同一个集群中同时运行。

性能模式能使一个包含所有版本 6 服务器的集群更有效的执行负载均衡和灾难恢复。

当在单元中的节点包含不同的版本时，WebSphere 产品移植逻辑根据兼容性自动设置模式。

在版本 6 中，关于一个节点的信息（比如操作系统平台和产品特性）是由这个节点指定的一个属性文件中的配置存储库维护。混合了版本单元管理逻辑的版本 6 使用这些信息来决定在特定节点的给定资源上，哪个管理功能是合适和有效的。例如，当显示的为版本 5 服务器时，版本 6 的特性并不显示在管理控制台上。当为某个节点、节点代理或者服务器显示属性时，管理控制台判断出该对象依赖哪个版本的节点，所以将只显示对于这些版本合法的属性。这一特性称为版本 6 管理信息的 Adapt-A-View 增强。

wsadmin 脚本客户端同样可以判断出配置对象依赖的节点版本。如果你试图去查看或者修改该版本不适用的属性时，会出现异常。如果你试图显示或者修改不赞成使用的属性时，一个警告会被记录下来。

在版本 6 中，基于应用程序使用的 WebSphere Application Server 特性，所有的应用程序都被分类成版本 5 或者版本 6 兼容的应用程序。所有的应用程序都可以使用管理功能来进行更新，以进行重新安装，编辑或者将模块重新映射到新的目标。当重新映射一个模块时，用于版本 6 的新目标可能不是一个版本 5 的目标（包含版本 5 成员的应用程序服务器或集群）。

在版本 6 中，还有更多的关于增量单元升级和混合单元管理特性的细节。本系列文章的其它部分将更加详细的介绍这些重要的新特性。

混合版本单元的版本 5 节点中的临时性约束

一旦到版本 6 的增量升级已经开始，单元中的版本 5 节点可能会有一些约束。这些约束将在版本 5 和版本 6 的后续维护版本中可以解除。

一个新的版本 5 的节点不能被添加到版本 6 的单元中。然而，我们可以通过将其添加到单元中以前将该节点升级到版本 6 来达到同样的目的。在版本 6 单元中的版本 5 节点不能从单元中移除。通过下面这两种途径也可以达到同样的目的：

将节点升级到版本 6，接下来执行 removeNode，或者

写在版本 5 节点，接下来在部署管理器上执行 cleanupNode，将到被卸载的节点的引用从主要单元存储库中移除。

一旦增量升级过程已经在进行中，就不允许在版本 5 的节点上定义新的应用程序服务器。用于版本 6 的一个特性维护补丁将添加底版本配置模板来解决这个约束。

WebSphere 概要文件

版本 6 产品安装程序将其创建的文件放置于两个单独环境中的一个当中。它将核心产品文件（"系统"文件）安装在一个位置，并且在一个单独的位置它创建一个初始概要文件，其是一个运行时执行环境，包含配置文件，部署应用程序的默认位置，日志和其它数据。一个机器上的所有的概要文件可以共享同样的核心产品文件，但是它们并不能进行修改。

版本 6 概要文件由终端用户拥有和编写的文件集以及终端用户身份下执行的流程组成。在 UNIX/Linux 系统中，创建的概要中所有的文件和目录同执行创建概要工具的用户有同样的组和所有者许可。考虑 WebSphere 概要的一个方式是将其作为用户数据分区 -- 同 UNIX®/Linux® 操作系统环境中的用户目录类似。

WebSphere 概要同 WebSphere 产品的二进制或者系统文件在物理上是分离的，其仅仅被终端用户流程所读取并且不能修改。WebSphere 系统文件只能够被产品维护更新修改，例如补丁等。WebSphere 系统文件可以被扩展了 WebSphere 平台的产品安装所修改，但是这也被认为是产品维护。

概要里面存储和更新的文件包含下列这些：

在该概要下执行的 WebSphere 流程存储库

所有变化的日志（

SystemOut.log

，tranlog，FFDC，

activity.log

，等等）

证书（至少是随产品提供的初始集）

安装的（扩展的）应用程序二进制文件

安装的 JCA Resource Adapter 库

属性文件

临时工作目录

Cloudscape 数据库

概要环境设置文件

版本 6 支持多种类型的概要文件。概要文件类型定义了该分区如何被定制，来为终端用户支持特定功能的环境。目前，版本 6 中共支持三种类型的概要文件：

应用程序服务器 -- 用于 Express 和 Application Server Base 包和 Network Deployment（ND）独立应用服务器包的独立应用程序服务器环境。在初始的概要文件中包含一个默认的应用程序服务器定义。

dmgr -- Deployment manager 环境，仅仅对于 ND 版本可用（同版本 5 中的 ND 版本同样）。

custom -- 一个自动联合的节点，不包含于定义的应用程序服务器定义。一个空管理节点，准备好为中央单元 deployment manager 添加资源和服务器配置。

同一个概要文件类型（或不同概要文件类型）的多个实例可以被创建并且关联至相同的产品安装（也就是说，同一个共享的系统文件）。一个概要文件的每个实例，不管它的类型或者位置，都被注册在一个概要文件注册表中，该注册表是一个 XML 文件，在产品安装目录的根目录中的属性目录中。

该系列后续的文章将更加详细的介绍 WebSphere 概要文件。

向后兼容能力

在版本 6 中，系统管理功能中的向后兼容能力有重要的改进。一些新的特性已经建立在版本 5 使用的相同的产品管理构造上。例如，版本 6 中配置存储库的结构和概念同版本 5 中是相同的。然而，版本 6 在现存的基础上添加了一些新的目录，并且在已经存在的目录中添加了许多新的文件。因此，如果你查看版本 6 安装的节点配置目录，你将发现版本 5 中同样的文件，但是添加了一些新的文件。

对于向后兼容能力的承诺扩充了静态的配置文件，并且包含为支持版本 5 和版本 6 管理程序的互操作性而进行的工作。版本 5 wsadmin 程序可以连接到版本 6 应用程序服务器并且与之通信，并且版本 6 deployment managers 可以与版本 5 节点代理通信来管理相同单元内安装的地基产品。

Wsadmin 脚本兼容性

不管为消除那些针对版本 5 所编写和执行的 wsadmin 脚本对版本 6 特性的影响做了多少努力，这里仍然有一些不可避免的对脚本的影响。

当把版本 5 的 deployment manager 和应用程序服务器节点移植到版本 6 时，被移植的配置默认是兼容模式，也就意味着旧的版本 5 的配置被保留并且就的脚本仍旧可以运行。运行时发现这个旧的配置，只要在新的配置与其并不存在冲突，将继续采用这个旧位置的设置。如果旧的配置位置仍然被使用，将在日志里面记录警告信息。

提供的 convertScriptCompatibility 工具可以用来更新配置，将所有的脚本一次转化成版本 6 的形式。推荐的最佳实践是将脚本更新到版本 6 越快越好，因为新创建的配置（比如，新应用程序服务器定义）使用新的版本 6 的配置（例如，对于通道），旧的脚本并不能在其上面工作。

下面的列表描述了版本 5 和版本 6 之间影响脚本的详细的不同点：

事务日志 -- 事务日志目录的位置已经从 ApplicationServer::TransactionService 改变到 ServerEntry::recoveryLogs。只要新的位置没有被使用就将一直使用旧的位置中的值。修改旧位置的脚本仍旧可以使用；直到在新位置设定值以后这个值才能起作用。

HTTP 传送 -- 版本 6 的新架构使用新的通道框架来进行通信和关联端点配置。Web 容器的 HTTP 定义被映射到这个通道框架支持的顶部。当在版本 5 的移植中选择兼容模式时，旧的 HTTPTransport 对象被留在配置中，因此现有的脚本可以修改这些对象并且无改变的运行。通道框架运行时代码将识别出旧
HTTPTransport 配置并且在日志中记录警告消息，指明该配置应该升级。

服务器进程定义 -- 服务器进程地难以配置对象的名字已经从 processDef 更改为 processDefs。

regexp 命令 -- WebSphere Application Server V6 中提供了新版本的 Jacl（1.3.1）。通过这个版本的 Jacl，regexp 命令仅仅支持 tcl 8.0 regexp 命令语法。

ConfigID

由于用于被允许的 ObjectName 类格式的 JMX 规范的更改，版本 6 中使用的 configID 包含一个竖线字符（"|"）而不是冒号字符（":"）作为分隔符。ConfigID 格式中的这个更改在大多数 wsadmin 脚本中不会有问题，因为 configID 在 wsadmin 执行中间不一定要保持一致，并且不会被持久的存储起来以供重新使用。ConfigID 应该始终从配置的一个查询中获得，该配置在脚本中被使用之前执行。

端口冲突解决方案

WebSphere Application Server 定义了许多服务器使用的端口，并且在一个运行的单独主机系统中每个端口都必须是唯一的。管理工具中已经作了一些改进，来帮助确保端口定义不会发生冲突。确保端口不会被冲用的流程在不同的产品工具之间是不同的。

概要文件创建工具（Profile Creation Tool）作为产品安装的一部分执行，其显示了在主机系统的所有 WebSphere Application Server 安装中唯一的端口列表。虽然不是必须的，你仍然可以将这些端口号修改为你自己想要的。

如果你使用静默安装（silent install），你需要修改响应文件，使端口是唯一的。默认的响应文件包含一个不冲突的端口的列表（默认的应用程序服务器端口同默认的部署管理器端口并不冲突）。如果你特定类型的多个服务器，你应该修改该端口清单。

AddNode 工具也被加强了，可以为安装的节点代理执行一定的避免端口冲突的功能。AddNode 程序着眼于当前安装中定义的端口，并且跨越所有与该安装相关的概要，来发现和解决端口定义中的冲突。如果你在单个的主机系统中有多个 WebSphere 安装，你可以定义特殊的端口来供节点代理使用，通过在 addNode 的命令中添加如下的命令行选项：

-portprops
<filename>

来实现这一功能。指定的文件应该包含一系列 key-value 属性，使用在配置文件

serverindex.xml

中定义的端口名，该文件保存在配置数中的节点目录中。例如：

清单 1

BOOTSTRAP_ADDRESS=9001

SOAP_CONNECTOR_ADDRESS=9002

ORB_LISTENER_ADDRESS=9003

任何没有指定的端口将使用它们的默认值，其在当前的安装中将是唯一的，但是不保证在相同主机系统的不同安装之间也是唯一的。

细粒度的应用程序更新

在 WebSphere Application Server V6 的应用程序管理中有许多非常有用的增强。

在版本 6 中重新部署一个应用程序显然更佳的有效率。当更新一个应用程序的时候，仅仅是需要更改的那部分应用程序代码需要上交给系统。应用程序管理逻辑将计算出系统需要执行的最小的动作，以便在更新应用程序的时候达到最小的负面影响。

在某些情况下，更新可以在不影响运行中的应用程序任何部门的情况下来进行。然而，因为一次典型的应用程序更新确实会造成应用程序服务器中的服务中断，在版本 6 中有一些推荐使用的附加特性可以来同 fine-grained application update 一起使用，为那些必须避免服务终端的客户来服务。接下来描述的 Rollout Application Update Option，为应用程序更新提供了改进的服务可用性。

上一个版本的 WebSphere Application Server 仅仅支持移除整个应用程序（也就是说，完整的

.ear

文件），并且经常为了任何更改停止和重新启动整个应用程序。版本
6 在 wsadmin 脚本中引入了更加强大的接口，管理控制台，和用于应用程序管理的 Java™ API 可以通过如下的方式来更新部署的应用程序或者模块：

替换，添加，或者移除一个单独的模块（

.war

，EJB

.jar

，或者连接器

.rar

文件）

替换，添加，后者移除一个单独的文件

替换，添加和/或者删除在一个压缩文件（

.zip

）中包含的多个文件。

如果一个应用程序在其运行时被更新，WebSphere Application Server 将自动停止被更新影响的组件。

在更新的过程中被停止的应用程序的任何部分在对应用程序代码的更新已经就位的情况下将自动被重新启动。没有被应用程序更新所影响的部署信息将被保留下来。当整个应用程序都被更新的时候，除了应用程序绑定以外，所有的部署相关信息（例如，classloader 设置，共享库）和部署目标配置（例如，会话管理设置）将被保留下来。

与这里提供的概括的信息相比，本系列随后的文章将提供应用程序管理增强的更详细的信息。

更新应用程序的首次展示

版本 6 添加了一个新的管理功能，并且合并到了产品中；一个用来更新部署在集群上的应用程序的过程通过一种方式来确保应用程序不会发生服务中断。我们推荐客户使用版本 5 中的 wsadmin 脚本来自动化这一操作，但是在版本 6 中，该逻辑在管理程序实现的时候已经被加强了。

版本 5 中默认的应用程序更新逻辑在更新发布和启动的过程中，在应用程序可用性上创建一些间隙。这些间隙的根本原因应用到运行中的服务器上的是一个异步的更新流程，这些服务器形成了一个 WebSphere 集群。

Application Rollout 已经作为一个内建的应用程序更新选项添加。当选择着一个选项时，自动单元同步被禁用，并且下面的步骤将依次被应用到每个集群成员中：

在给定的节点上停止所有的集群成员，使应用程序客户端恢复到其他节点上的集群成员。

将应用程序更新发布到节点。

重新启动集群成员，使其开始处理应用程序请求，但是执行新版本的应用程序。

这个功能仅仅在应用程序的更新与前一个版本的应用程序是"兼容"的时候可以正常工作。换句话说，在相同的集群内同时执行两个版本的应用程序必须是切实可行的，并且客户端应该可以将请求正常地引导至任何版本的应用程序。许多应用程序的修正落入兼容更新的类别，但是对于应用程序开发人员来说并不需要知道哪个是，哪个不是。

这个新功能及可以通过管理控制台实现，也可以通过 wsadmin 脚本实现。在管理控制台中，其是 Enterprise Applications 中的 Rollout Update 按钮。同样，也可以通过 wsadmin 脚本中 AppManagement MBean 的 updateCluster 操作来实现。

增强的 EAR 文件支持

在 WebSphere Application Server 的前一个版本中，在部署应用程序以前，用户必须设置 WebSphere 环境配置来分步支持应用程序。应用程序使用的资源和变量必须在应用程序安装以前存在于 WebSphere 配置中。

在版本 6 中，伴随的 Application Server Toolkit 使用户可以定义 WebSphere 配置元素，比如数据源和虚拟主机，作为应用程序的一部分。这些 WebSphere 配置元素和设置可以被打包进开发工具导出的

.ear

文件。在部署的时候，用户可能选择处理这些内置的配置元素，这些配置元素可以为应用程序自动的设定
WebSphere 配置来作为部署的一部分。

配置档案文件

WebSphere Application Server V6 新增了从一个环境中导出和导入部分 WebSphere 配置存储库到另一个环境中的功能。

通过将概要（或者概要的一部分）导出到一个配置档案文件中，并将其导入到另外一个概要，用户可以从一个 WebSphere 概要传送配置到另一个中。这个机制在相同和不同安装的概要之间都可以正常工作。在这个版本中的一个约束是该机制仅仅在未联合的 WebSphere 概要上可以工作。

命令 exportServer 和 exportWasProfile 既可以使配置片断到处到一个档案文件中，也可以到处整个概要配置。命令 importServer and importWasProfile 可以把这些档案文件概要引入到现有的环境中并且与现有的目标环境配置融合。在导入到目标环境中时，档案文件中的配置数据可以接纳本地单元、节点和服务器的名称。

本系列中后续的文章将更加详细的描述配置档案文件。

管理命令任务

在版本 6 中，管理任务的自动化通过 wsadmin 中的 AdminTask 特性变得更加容易了。这个新的特性中已经实现了更多的有关管理的任务，其支持交互执行和将多个单独的脚本命令结合到一个单独的基于任务的命令。通过高级的 admin 任务提供自动化的任务的例子包含服务器管理、集群管理和资源管理。

AdminTask 特性提供了多种友好的和基于任务的 wsadmin 命令。对于一些那种复杂的管理操作，AdminTask 命令可能有多个步骤，类似于控制台中的向导，并且给予它们的功能领域进行分组。（关于 AdminTask 命令和命令组的更详细的帮助信息通过各种 AdminTask 帮助命令可以查看）。所有的 AdminTask 命令可以在交互的模式下执行，其引导用户通过操作的每一个步骤。在交互命令会话的结尾，会生成整个响应的 AdminTask 命令来帮助用户学习 AdminTask 命令语法。

本系列中的后续文章将提供关于这个新的 Admin Command Task 得更加详细的信息。

Web 服务器管理

在 WebSphere Application Server V6 中，HTTP Web 体现为一个特定的服务器类型；服务器类型只是一个配置模板的特别组身份。在版本 6 中尉 Web 服务器定义了一个新的服务器类型，其包含两个不同的 Web 服务器配置模板：一个用于 IHS Web 服务器，另一个用于所有其他 WebSphere 支持的"普通"Web 服务器。

通过在 WebSphere 拓扑中明确地表现 Web 服务器可以得到很多好处。在用于 Web 服务器插件的

plugin-cfg.xml

文件中使用的所有配置属性被导出来，并且可以通过管理控制台或者
wsadmin 脚本自动化进行修改。基于它的配置和与应用程序服务器的联系，每个 Web 服务器都会生成单个定制的

plugin-cfg.xml

文件。当应用程序已经安装以后，与应用程序服务器的这些联系通过为应用程序选择
Web 服务器作为一个部署目标来确定。通过部署应用程序的联系，彼此关联 Web 服务器和应用程序服务器，当应用程序被部署或者修改时会动态的重新生成

plugin-cfg.xml

关联。

本系列的后续文章中将版本 6 中的 Web 服务管理提供更加详细的描述。

与操作系统的集成

在版本 6 中，当安装在 Microsoft Windows 操作系统上时，在 Express、Base 和 Network Deployment（ND）独立环境中的所有的 WebSphere 应用程序服务器将会注册为 Microsoft® Windows® 操作系统服务。当服务器注册为 Windows 服务时，操作系统负责来启动和停止进程。结果，WebSphere 系统管理命令行工具应经被修改来解决它们可以在 Windows 操作系统上执行，并且使用操作系统服务来控制服务器的可能性，而不是直接启动和停止。

这个影响了如下的命令行工具：

stopServer

addNode/removeNode

backup/restoreConfig

任何其他停止和启动服务器的代码。

WASService.exe

工具同样做了进一步的增强，该工具用来执行将
WebSphere 服务器注册为 Windows OS 服务。

本系列后续的文章将更加详细的描述版本 6 中的这个特性。

J2EE 1.4 管理规范

J2EE™ 1.4 规范为应用服务器厂商添加了一些需求，来实现对于管理的支持。这个版本的 J2EE 规范添加了一些需求来支持：

Java Management Extensions（JMX 1.2）

J2EE Management Specificiation（JSR 77）

J2EE Deployment （JSR 88）

J2EE Connector Architecture（JCA 1.5）。

除了 J2EE 规范有关的管理特性，WebSphere 内嵌的消息组件（支持 Java Messaging Service（JMS））已经被重新设计来更好的集成到应用服务器管理中。

本系列后续的文章将更加详细的描述 J2EE 1.4 规范和 WebSphere Application Server V6 提供的新的管理功能。

系统应用程序

WebSphere Application Server V6 中的一个新的概念是系统应用程序，该应用程序是作为标准的 J2EE 应用程序来开发，但是倾向于作为 WebSphere Application Server 产品的一部分，不被终端用户所操纵。

系统应用程序在所有与单个的 WebSphere Application Server 安装相关的概要中是共享的。对于每个安装来说，仅仅有一套包含逻辑的应用程序文件，并且这些应用程序文件其余核心产品二进制文件位于一起。系统应用程序被认为是由 WebSphere 产品逻辑"拥有"和控制的，与其不同的是用户应用程序都是在 WebSphere Application Server 用户来控制的。

WebSphere Application Server V6 系统应用程序的例子包含

adminconsole.ear

和

filetransfer.ear

。并不是所有随
WebSphere Application Server 提供的应用程序都是系统应用程序；例如，J2EE Samples 就不是系统应用程序。

系统应用程序并没有显示在控制台中，并且也不包含在通过 wsadmin

$AdminApp

list
命令返回的列表中。

节点组

WebSphere Application Server 节点具备支持多种功能的能力，这取决于底层的操作系统，安装的 WebSphere 产品版本，以及在相同的节点上安装的任何拓展的产品。如果这个节点不支持兼容能力，在其上面执行某些功能可能是不合适的。例如，在一个 WebSphere 集群中，既包含 zSeries 节点也包含其他操作系统的节点就是不合适的。因为 zSeries 上的负载均衡逻辑和其他平台是不兼容。这里还有一些其他的例子表明区分节点能力和兼容性是非常重要的，例如当一个单元中包含安装有 WebSphere
Business Integration 的节点，并且你需要确保定义的用来运行 WebSphere Business Integration 应用程序的集群包含仅仅有 WebSphere Business Integration 安装的节点。

在版本 6 中，引进了节点组的概念，用来帮助区分具备不同能力的节点。除非明确地指出，单元中所有的节点都包含在 DefaultNodeGroup 中。然而，如果节点备联合到单元中，它们可以被指派到不同的节点组，来区分单元中不同节点集合的能力。例如，如果一个单元中的 DefaultNodeGroup 中包含分布式的节点，任何 zSeries 节点都必须明确的关联到一个单独的节点组，以同其他操作系统平台节点区分开来。在 addNode 命令中有一个新的 -nodegroupname 选项用来明确地指定备联合的节点应该位于的
NodeGroup。

某些管理操作需要其包含的节点都是兼容的并且属于同样的节点组。当向 WebSphere 集群中添加额外的成员时，这个新的集群成员所依赖的节点必须同集群中其他服务器一样来自相同的节点组。

结束语

本文是一系列文章中的第一篇，提供了 WebSphere Application Server V6 中国的新的系统管理特性的概述。这一系列种后续的文章将更深的探索版本 6 中的管理问题。特别的是，后续的文章将包含：2005-3-9

增量单元升级流程

概要和配置档案文件

重新设计的 Web 服务器管理

应用程序更新和 Rollout Application Update Tool

新的 admin 命令任务

WebSphere Application Server V6 的 Windows 集成

J2EE 1.4 支持

WebSphere Application Server V6 在 WebSphere Application Server V5 所建立的基础上构建，并且这系列文章将帮助你更加熟悉版本 6 的管理。请注意阅读本系列的后续文章。