产品升级是所有软件系统都必须考虑的重要问题,升级的复杂度会因具体部署环境不同而变化。企业环境中的 IBM Rational ClearCase/ClearQuest 通常就是一个多站分布式部署的复杂系统,由于部署采用多站,而且产品被分为各个组件分布在不同的机器上协作完成任务,机器之间有比较紧密的耦合关系;同时,企业应用的数据量庞大,数据和产品都存在集成,这些因素都增加了升级过程中的风险。本文将以一个典型的 ClearCase/ClearQuest 企业部署环境为例,介绍从 2003.06.15 版本到 7.0.1 版本的阶段式升级策略,这种策略能够保证项目进度在升级过程中不受影响。为了适应 2003.06.15 到 7.0.1 之间的那些版本间的升级,给用户更全面的参考,文章从版本兼容性的角度详细阐述了为何如此安排升级策略。另外,为了提供更好的保障,本文还提供了一些情况下的数据备份、恢复方法以供参考。 1. 前言文章假设读者已经具备了 ClearCase/ClearQuest 产品的部署配置知识,所以没有给出细节描述。考虑到文章中涉及这些内容,读者可以参考以下几方面内容的文章:
本文主要针对 ClearCase/ClearQuest 系统升级管理员撰写。不过由于产品部署初期也会预先考虑到远期产品升级问题,因此也可为 ClearCase/ClearQuest 的系统管理员和部署配置人员提供参考。 产品升级(Product Upgrade)是产品使用过程中一个不可缺少的重要环节。它在遵循向后兼容(Backwards Compatibility)的原则下,修正原有产品的缺陷(Defect),同时添加新的功能(New Feature)。在非企业环境下,大部分产品都孤立地安装于一台物理机器上,因此产品的升级相对简单。然而在大部分企业的应用环境中,产品之间互相集成、分布式部署,所以必须研究讨论产品的升级策略,这样才能降低升级存在的固有风险。 在此,主要针对 IBM Rational 两款软件配置管理(Software Configuration Management)工具展开升级的讨论: ClearCase —业内优秀的软件配置管理工具。以下简称 CC。 ClearQuest —软件变更管理和缺陷跟踪工具。以下简称 CQ。 在企业应用环境下,CC 和 CQ 可以互相集成使用。它们的结合使得 CC 管理的各个文件的不同版本不再是孤立的元素,而是被 CQ 有机组合在一起,构成一个完整的软件变更集。这样集成,可以把需求分析员、开发者、项目管理人员有效的组织在一起,协同完成软件的开发和测试。 此外,CC/CQ 是相对典型的客户端 / 服务器(C/S)的结构,所有的资源由服务器控制。为了提高访问效率、平衡服务器负载,产品被分为不同的组件,分布式部署在不同的物理机器上;同时,为了减小跨国、跨地域低带宽访问的可能性,CC/CQ 都采用多站点(MultiSite)部署;为了提高数据安全性,产品和数据也是分离的。 在这样的环境中,各台机器、各个站点之间的产品和组件存在复杂的关联性;分离的数据和产品也存在关联性。因此升级存在风险。一台服务器升级失败可能会影响全局,甚至威胁到原有数据,从而影响整个项目的进度和成败。因此必须讨论和使用一种合理的升级策略去解决以上的问题。 复杂环境的升级涉及两个重要的方面:产品部署的拓扑结构和软件版本。显然,在一篇文章中不可能完全覆盖所有的情况。为了更好的描述升级策略,文章做了两个前提性的约定(或假设):
不过,即使拓扑结构或者软件版本不完全相同也可以参考此文。因为在产品部署方面,升级策略是围绕一些基本理念展开讨论的,兼顾了相似的拓扑结构。而在版本升级路线方面,由于 2003.06.15 和 7.0.1 是目前差别较大且较常见的两个版本,因此在他们之间的那些版本升级也可以参考(例如:从 7.0.0 升级到 7.0.1);另外文章还在第 4 章着重讨论了版本兼容性,以供参考。 下面,开始围绕这个典型的拓扑结构展开升级的讨论。 2. CC/CQ 升级综述CC/CQ 的复杂环境部署有非常多的组合类型。图 1 是一个比较典型的拓扑结构,适用于中小型企业,这是一个较通用的结构:可以通过继续缩小和删减机器达到简化作用,也可以通过扩展,增强功能,从而适应于大型企业。 图 1 拓扑结构图中,所有的 CC/CQ Server 和 Client 被划分为两大部分:Master Site(主站)和 Replica Site(从站)。在跨地区的团队协作中,为了提高 CC 和 CQ 的本地客户的访问效率,总是采用这种多站(MultiSite)的分布式部署。数据分别在每个站点有各自的拷贝,它们之间通过 MultiSite Server 进行同步和传输。 在 Master Site 和 Replica Site 中, CC/CQ 的 Server 有着相同的部署,它们各自服务于本地的 Client。因此两个站点中的同名机器承担着相同的角色。当然,在实际情况下,站点与站点的部署可能不相同,但是为了集中讨论主要问题,这里假设它们是相同的。下表 1 以 Master Site 为例,分别介绍每台机器承担的角色。Replica Site 亦同。 表 1 机器角色
在上表中,有几点需要注意:
在每个站点中,可以发现: CC 和 CQ 的集成是通过 CCCQ Admin 来管理的,而有的企业可能只需要单独使用 CC 或者 CQ,不需要集成。那么完全可以省略 CCCQ Admin,将 CC CQ 分开考虑,使其自成一体。这在表 1 中也有体现:红色标出的 CC 可以构成一个单独的 CC 站点;而蓝色标出的 CQ 亦同。 实际上,图 1 是一种特定的拓扑结构。更加抽象的拓扑结构如图 2 所示。图 2 力图简化图 1,从而给读者更清晰、完整的视角。 图 2 抽象拓扑结构在此,MultiSite 的部署不仅仅只包含 Master Site 和 Replica Site 的情况了,MultiSite 由任意多个站点构成。每个站点之内的机器自成一体,拓扑结构可以相同,也可以不同。不过需要注意的是,虽然大部分情况下,Master Site 和 Replica Site 没有太大区别,地位是平等的;然而对于 CQ,它们还是有主从之分:因为 CQ Master DB 的修改权利只有主站拥有,所以在升级 CQ Feature level 和 CQ Package 时需要注意,只能先升级 CQ Master Site,后升级 CQ Replica Site,而不能颠倒顺序。 针对于图 2 的抽象描述,可以将升级的策略归纳为一个更通用的指导方针:“阶段升级策略”(Stage Upgrade Strategy)。它将升级顺序分为几个阶段,每个阶段包含一台或多台物理机器,一次性对这些机器中安装的产品同时升级,每阶段升级完毕后,提供了相应的验证方法,以便及时找出问题。升级的阶段如图 3 所示。 图 3 升级阶段阶段升级策略先升级服务器(Server),后升级客户端(Client),最后升级数据;而在升级 Server 的过程中,又将 CC 和 CQ 分开进行,先升级 CC,后升级 CQ。而对于 MultiSite,一般是先升级 Master Site 的一个产品,然后再升级 Replica Site 的同一个产品。MultiSite 的升级顺序最好不要颠倒,以免带来意外的麻烦。特别是升级 CQ Feature Level 和 Package 的时候。 阶段升级策略将整个升级分为了几个大的阶段,在每个阶段的间隙,升级工作可以暂停,CC 和 CQ 能正常使用。所以基本不会中断项目的进度。可以选择周末或者晚上来做升级工作。 而这些大的阶段中,还可以划分为更小的步骤。每个步骤都有保证是否升级成功的验证方法。在步骤之间,升级也是可以暂停的。这可以参考 CC/CQ 组件间版本兼容性,在第 4 章详细讨论。 另外,阶段升级策略还包含了备份与恢复的操作,它们属于升级的一部分,为升级的失败提供解决方案,降低升级风险。这在第 3 和第 5 章讨论。 根据图 3 所示的“升级阶段”思路,在表 2 中列出了图 1 部署环境的详细升级步骤以供参考。 表 2 详细升级步骤
在上表中,有几点需要注意:
总之,在以上的升级详细步骤中,每个步骤之间都是可以暂停的,而每个步骤升级和验证的时间基本不会超过 2 个小时;每个阶段的时间从升级到调试成功不会超过 5 个小时。因此,这样的升级方法,能够在不影响项目正常进度的情况下,分阶段完成升级;同时其中的备份工作能够最大限度的保证大量数据的安全性。 当然,以上的升级策略只是一种参考,在了解了每个详细步骤和其中原理的情况下是能够更具需要自行调整的。下面从升级前的准备开始,围绕表 2 的升级步骤展开描述。 3. 升级前的准备准备工作是为了防止升级过程中,人为操作失误或者不可预测的原因导致重要数据损坏。在“阶段式升级策略”中。准备工作分为两个部分: (1)总体准备阶段。 在所有站点,停止同步、传输的服务,并手动导入所有剩余的 CC/CQ MultiSite packets。此动作的目的,主要是保证所有 packets 导入,因为新老版本的 packets 格式有可能是不兼容的。兼容性请参考第 4 章。
暂停系统中和 CC 计划任务中所有和 MultiSite 传输相关的计划。
CC 使用命令“multitool syncreplica -import”导入。 CQ 使用命令“multiutil syncreplica –import”导入。 (2)分步准备阶段。
3.1.1 备份 ClearCase 的注册文件 CC 注册文件保存在 CC Registry Server 上(在表 1 中也就是 CC RGY)。它记录整个 CC 站点所有注册信息,包括:VOB Object、VOB Tag、View Object、View Tag、CC Host、Region、Vob Storage Location、View Storage Location 等注册信息。 注册文件实际上是一组普通文件的集合。如果 CC 按默认路径安装,在 Windows 平台上,注册文件位置在 C:\Program Files\Rational\ClearCase\var\rgy 目录下。在 Linux 平台上,注册文件的位置在 /var/adm/rational/clearcase/rgy 目录下。 备份它们只要用系统自带的复制命令,如:xcopy,cp 等,将这个文件夹的内容复制到备份的位置,恢复的时候也只需要将备份的文件复制到原来的位置就可以了。 3.1.2 备份 ClearCase 的 VOB 和 VIEW VOB 的备份 在介绍 VOB 备份之前,首先需要了解一下 VOB 的存储目录。在 VOB 的存储目录中(如:VOB Storage Location),有很多以 <VOB-TAG>.vbs 命名的文件夹。这个文件夹里面存储的是 VOB 的物理数据,真正的 VOB 数据就在这里面了,所以这就是所说的 VOB 数据库文件。这些文件由于存储于文件系统之上,因此对文件系统有很大的依赖性。例如,Windows NTFS 文件系统会记录文件的 ACL,而 Linux 也会有类似的记录。这些记录不能被手动更改,一旦更改就会导致很多访问 VOB 的奇怪问题,甚至会损坏 VOB。这种损坏有时是很难恢复的。因此,在备份工具的选择上有三点需要特别注意: ① Windows 的备份工具要能够保留 NTFS ACLs 的信息。当然,如果是在 FAT 文件系统上的话就不需要考虑这一点了,因为 FAT 文件系统没有关于 ACLs 的元数据。 ②备份工具要能够保留文件的访问时间。 ③在 Linux 系统上,推荐使用 cpio 命令。因为无论文件处于什么状态,它能够安全、无遗漏的读取所有 VOB 数据库文件,并保留原有信息,因此是备份 VOB 的最好选择。 以上有关“.vbs”文件更详细的信息,请阅读参考文献。下面介绍 VOB 备份。 备份 VOB 有两种方法,快照(snapshot)和标准(standard),这里介绍后者。 备份的步骤: ①锁定 VOB,即所有用户都不能够访问此 VOB。在 Windows 图形界面上,可以通过 ClearCase Administration Console 来锁定 VOB,或者在命令行的方式下使用 cleartool lock 命令。命令行方式适用于任何平台。 ②停止所有 ClearCase 的服务,以保证没有任何内部进程在访问 VOB。 ③备份 VOB,将 VOB 的存储目录里面的文件全部都拷贝到备份介质上。 ④备份完成后,解锁 VOB。使用 cleartool unlock 命令。 下面是一个命令行方式的示例:
VIEW 的备份 备份 View 的方法与备份 VOB 相比,相对容易一些,也比较相似。需要注意的是,无论是备份 Dynamic View 还是 Snapshot View,都一定要备份完整,保证一致性。这些对保存 View 中那些 private file 和 check-out file 很重要。以下是备份 View 的命令行示例:
当然,以上 VOB 和 View 的备份都是针对于图 1 描绘拓扑结构的。对于更复杂的情况,例如 VOB 的 Multiple Storage Pool,请参考相关文档。 CQ 的数据主要是存放在 CQ DB 中。所以 CQ 的备份包含两个方面:备份 CQ DB;备份 CQ 数据库的连接信息。备份 CQ 遵循以下步骤:
CC 和 CQ 的 Web Server 备份的主要是配置文件,备份方法相同,如下:
恢复的方法其实就是把 RWP 配置文件拷贝回原路径,这在第 5 章将不在讨论。更加复杂和详细的备份(包括 SSL 的配置备份)请参考相关文档。 CC 2003.06.15 支持 2 种 VOB Schema Version:53 和 54,与 schema 53 相比,schema 54 具有如下的优势:
CC 7.0.0 以上的版本完全抛弃了旧的 schema 53 格式,全部采用了 schema 54 格式,所以必须将现有的 VOB Schema 版本升级到 54。 可以使用“cleartool describe -long vob: <vobtag>”命令来查看 VOB 的 Schema Version,可以使用“cleartool -ver”来确定 VOB Server 当前所用的 Schema Version。 如果你的 VOB 的 Schema Version 是 53,在升级完成之后需使用 reformatvob 命令来升级 Schema Version。请参考第 4 章关于 VOB Schema Version 的讨论。 至此,升级前的准备工作就完成了。以下展开升级的讨论。 4. 升级4.1.1 产品升级方法 第二章讨论了 CC/CQ 的升级步骤。不过并没有具体介绍针对于每台机器怎样升级。这里将讨论如何升级这些机器上的产品。 升级产品的方式分为两种:
第一种方式,升级依照原安装路径安装,原有配置文件依然可以使用,升级快速便捷。但是在版本跨度较大的产品升级时或许存在一定风险的。例如:从 2003.06.15 到 7.0.1 的升级。 第二种方式,在升级过程中,一些原有配置文件也许会被卸载程序清除,因此安装新产品后需要手动恢复。不过,在跨度较大的产品升级时是安全的。 采用第二种方式,升级的过程和安装卸载过程完全相同,可以参考相关安装卸载文档。这里对第一种方式——直接升级方式做出描述: (1)在 Window 环境中,使用 Desktop Image 的安装方式,直接将 7.0.1 安装盘插入,安装向导会自动选择本机器上已经安装的组件进行升级。如果从 2003.06.15 升级到 7.0.1,在安装向导中,可以修改选择的组件,然后升级;而如果从 7.0.0 升级到 7.0.1,安装向导不会出现组件选择界面,直接升级。 (2)在 Linux 环境中,我们利用 Release Area 安装方式升级,利用 Release Area 的文件直接安装。安装向导也将会自动选择已安装组件,我们也可以增加新的组件,然后升级。 以上的升级方法,对于 CC/CQ 都是适用的。CC 依照以上方法升级完后就可以正常使用了。而对于 CQ,当从 2003.06.15 升级到 7.0.x 后,为了保证新老版本的 CQ 都能够正常连接 CQ DB,需要执行以下几个重要的后续操作:
当原有版本为 2003.06.15 时,对于 Master DB 为 Oracle 和 SQL Server 的情况,只需要导入原来备份的 profile 文件即可。对于 Master DB 为 DB2 需要重新创建新的连接。这在 3.2 节提到过。
打开 CQ Maintenance Tool,选择需要更新的连接,然后依次点击 Schema Repository -> Update -> Selected Connection,如图 4。这时候界面就变成了可编辑的状态,修改数据库的连接信息,点击 finish。如果原来的信息是正确的,那么就不需要修改任何字段,直接点击 finish 就可以了。 图 5 修改数据库的连接信息
打开 CQ Designer,在 Database 菜单中选择 Update User Database Property,如图 5。然后选择要更新的数据库名,确认数据库连接信息,无误后点击 Upgrade,数据库属性就被更新了。 图 6 选择要更新的数据库名通过以上的步骤和方法,就能够升级每台机器上的 CC/CQ 产品了。另外,在升级中,还有几点需要说明:
4.1.2 ClearCase 数据升级方法 CC 的数据升级包含两个方面内容,VOB Schema 和 Feature Level。前者的升级使得 VOB 对文本文件大小的支持提高到 2GB;后者的升级使得 VOB Container 的大小提高的 2GB。不过,它们的升级在第二章被放在了分开的两个部分,以下分别讨论: ① CC VOB Schema Version 的升级 升级前的准备包含检查 VOB Schema Version 的步骤。如果 Schema Version 是 53 的,就需要执行升级了。升级 VOB Schema Version 必须安排在 VOB Server 升级后立即进行,否则 VOB 是没有办法被 VOB Server 正常访问的。以下是升级的命令行示例:
需要注意的是:升级 VOB Schema Version 也可以在升级完 VOB Server 前就进行。但是在 VOB 升级前,如果 2003.06.15 的 VOB Server 上的 Schema Version 是 53 的话,是没有办法直接将其 Schema Version 升级为 54 的。除非重新安装 2003.06.15 版本的 CC 产品,并在安装时选择支持 VOB Extension。 ② CC Feature Level 的升级 当产品升级到 7.0.x 后,CC VOB 支持的 feature level 5, feature level 5 支持某些元素超越 2GB 的大小限制。如果你想利用 feature level 5 带来的好处,当 CC VOB Server 升级完后,建议将 CC VOB 的 feature level 升为 5。 CC VOB 的 Feature Level 被分为 2 种:VOB Family Feature Level 和 VOB Replica Feature Level。前者指的所有 Site 上同一个 VOB Family 的 Feature Level;后者指的同一个 VOB Family 下,每个 Replica 的 Feature Level。其升级顺序必须遵循:首先逐个升级每个站点的 VOB Replica Feature Level,再升级 VOB Family 的 Feature Level。 现假设 VOB 有两个 Replica:R1,R2,分别在 Master Site 和 Replica Site,以下是升级步骤:
实际上在每次升级操作后,后续操作都可以中断,继续其它的工作而不影响正常使用,所以可以将 VOB Feature Level 的升级安排在每个站点的 VOB Server 升级之后,然后在所有站点的所有的 VOB Server 升级完后再升级 VOB family 的 feature level。这里为了方便,将其安排在了所有 CC/CQ 升级结束之后。 4.1.3 ClearCase/ClearQuest 集成的升级 CC 和 CQ 的集成包括 Base CC-CQ 集成和 UCM-CQ 集成。集成的配置主要依靠 CCCQ Admin Host,因此集成的升级和这台机器的升级有较大的联系。 在第二章升级策略中,这台机器的升级是属于 CC 升级部分的,因此在 CC 升级后,这台机器的 CC 和 CQ 产品就同时更新到了新版本(7.0.1)。此时,所有 CC 的服务器都是新版本(7.0.1),而 CQ 的其他的服务器和数据库都是旧版本(2006.06.15)。对于 UCM-CQ 集成,此时所有的新老客户端都是可以正常访问 CC VOB 和 CQ 数据库的;对于 Base CC-CQ 集成,推荐把老客户端都升级到 7.0.1 版本后使用。 在这里我们要注意,Base CC-CQ 集成是由 CCCQ Admin Host 上的集中控制脚本完成的,此时这个脚本还处于旧的版本。为了保证以后当其他机器上的 CQ 升级到新版本后能够正常使用集成功能,这个脚本也必须跟新到新的版本。以下是新脚本相关文件的路径:
把以上的目录和文件拷贝覆盖原来版本的集中控制脚本,并依照原来 config.pl 的配置,重新配置 ..\CQCC\config.pl。 另外,在升级过程中还有以下几个方面需要注意:
4.1.4 ClearQuest 数据升级方法 在第二章的详细步骤中,还包括 CQ 数据的升级,分为两个部分:CQ Feature Level 的升级和 CQ Package 的升级,这两者的升级顺序可以颠倒,以下展开描述:
①在升级 Feature Level 时,有几点注意事项:
当 Master Site 升完 Feature Level 后,Replica Site Feature Level 需在 Replica Site 手动升级,而不是直接从 Master Site 同步实现的。 ② Feature Level 升级方式有两种:
Feature Level 升级是在 CQ Maintenance Tool 工具中实现,点击 Schema Repository > Upgrade > Selected Connection,按照导航界面对 Master DB 和 User DB 的 Feature Level 进行升级。 ③ Multisite 环境中,升级 Feature Level 的详细步骤如下:
实际上,Master Site 和 Replica Site 的 Feature Level 可同时升级。
①升级 Packages 有以下几点注意事项:
②升级 Package 的方法: 在 CQ Designer 里实现升级 Packages,以下是两种升级方法:
③ Multisite 环境中,升级 Package 的详细步骤如下:
为了兼顾从 2003.06.15 到 7.0.x 以及 7.0.x 之间的各种升级路径,同时为了更好诠释阶段式升级策略,下面讨论升级过程中的版本兼容性以及相关的升级注意事项。 4.2.1 ClearCase (1)Register Server、VOB Server、View Server 从 2003.06.15 到 7.0.1 版本,CC Servers 按照 Register Server、VOB Server、View Server 的顺序,前者的高版本与后者的低版本兼容,但前者的低版本与后者的高版本不兼容。如下表 3 所示。“√”代表兼容,“×”代表不兼容: 表 3 CC Register Server、VOB Server 和 View Server 版本兼容性
对于这几个 CC Servers,有以下几点需要说明: ①因为 Register Server 上有 ClearCase 所有注册信息,所以它需要先升级。从 2003.06.15 升级到 7.0.1 后,如果是 Windows 环境的 Register server,Register server 不需要修改文件;如果是 Linux 环境的 Register server,需要在 /var/adm/rational/clearcase/config/ 目录重新创建 rgy_svr.conf 文件,并在其中写入 Master。 ② View server 必须要在 VOB Server 后面升级,因为高版本的 View server 不能兼容低版本的 VOB server。 ③从理论上讲,只要遵循 CC 升级策略的顺序,VOB Server 和 View server 升级完毕后,不需要修改任何文件,都可正常运行。 (2)Multisite Server Multisite Server 的兼容性包含两个方面的内容:shipping server 和 packets。 2003.06.15 版本与 7.0.x 版本的 Shipping Server 是完全兼容的,也就是说使用 shipping server 在站点之间传递 packets 是没有问题的。 Packets 版本的兼容性实际上和 VOB 及其 replica 的 feature level 兼容性有关。在本文的升级策略中,原有 VOB 的 feature level 为 4,并且一直保持不变,没有升级,因此它们产生的 packets 是兼容的。具体的兼容性可以参考 VOB feature level 有关文档。 总之,在 2003.06.15 与 7.0.x 之间各版本的 CC Multisite server 从升级的角度看是相互兼容的。 (3)CCRC、CC Web Server 和其他 CC Servers 对于 CC, 在这里特地介绍 CCRC 客户端、CC Web Server 和其他 CC Servers 间的兼容性。当 CCRC 升级到 7.0.x 版本时,Server 也必须升级到新的版本,旧 CCRC 客户端与新的 7.0.x Server 不兼容;7.0.x 版本的 Web servers 只与 7.0.x 版本的 VOB servers 兼容,所以 Web Server 在 VOB Server 后面升级。CCRC、Web Server 和其他 Servers 间的版本兼容性如下表: 表 4 CCRC、Web Server 与其他 Server 版本兼容性
对于 CC Web Server, 还有如下几点需要说明: ①对于 2003.06.15 到 7.0.1 的 Rational 产品,在同一台机器上,这些产品的 Web Server 必须是同一个版本。升级某一个产品的 Web Server 时,也应该升级同机器上其他产品的 Web Server. ②在升级前需要备份 Web Server 的客户化配置文件。对于 2003.06.15 版本的 Rational 产品来说,这些配置文件在 <Rational 产品安装目录 >/common/rwp/conf 目录;对于 7.0 的产品来说,这些配置文件在 <Rational 产品安装目录 >/common/rwp/IHS 目录。一旦升级完毕,需要恢复这些客户化配置文件。 对于本实验环境,由于 Web Server 没有相关的客户化配置,所以对于 Web Server 不需要备份什么文件,升级完毕后,不需要修改任何文件,Web Server 直接就可正常运行。 4.2.2 ClearQuest (1)Multisite Server 2003.06.15 版本的 Multisite Server 与 7.0.x 的 Multisite Server 不兼容 ; 但 7.0.x 版本间的 Multisite Server 相互兼容。如下表: 表 5 CQ Multisite Server 版本兼容性
所以在本文 Multisite 环境中,Master Site 和 Replica Site 的 CQ Multisite Server 在同一个阶段升级的。 (2) CQ Web Server 除了前面 CC Web Server 谈到的内容外,对于 CQ Web Server 还有如下内容需要补充: ① Rational CQ Web 包括两个组件 The Rational CQ Server 和 The Rational CQ Web Application。 ② Rational CQ Web server 可能分布在一台、两台或三台机器,如 CQ Server 在一台机器上,CQ Web Application 在第二台机器上,IBM HTTP Server (IHS) 在第三机器上。在进行 Web server 升级时,这三台机器都需要升级。 ③在本文实践环境中 CQ Web Server 都放在一台机器上了,当 CQ Web Server 升级完毕后,不需要修改任何文件,在另外一台机器浏览器上进行测试,一切正常。 (3)Feature Level 与 Client 版本兼容性 CQ 的 2003.06.15 版本和 7.0.0.x 版本都只支持 Feature Level 5, 7.0.1 版本支持 Feature Level 5 和 Feature Level 6。Feature Level 与 Client 版本兼容性如下表: 表 6 Feature Level 与 Client 版本兼容性
由于当 Feature Level 升为 6 时,只有 7.0.1 版本的客户端运行正常,所以在升级 CQ Feature Level 之前需将 CQ 的所有的客户端都升级到了 7.0.1 版本。 5. 升级后处理升级以后首先要检查 CQ 和 CC 各个服务的状态,并启动所有的服务,如果所有服务都能正常启动,并且一些基本的操作也都没有问题,那么升级就算成功了,如果遇到服务不能启动的情况,查看系统和应用程序日志,会有很大帮助的,如果一切顺利的话我们就顺利的完成了升级。 虽然,按照以上所述的升级策略,能够保证大部分的升级顺利进行。但是不能否认,任何操作都有可能导致失败。有时是人为的因素,有时是不同系统之间的差异性和兼容性导致的。总之有失败就必然要讨论如何从失败中恢复。这也就是第 2 部分需要备份的原因。 另外,这里指的恢复主要是指数据的恢复,而不包含整个产品的降级安装和回滚。换句话说就是在一个部署、安排、版本和原来完全一样的空白系统中,把原来的数据恢复到备份时的状态。分为两个部分:CC 和 CQ。 在第 3 部分,CC 的备份包括三个部分:注册文件、VOB、View。 注册文件的恢复较为简单,在第二部分已经提到,这里不做论述。而 View 的恢复可以参考以下 VOB 的恢复。以下就 VOB 恢复做出讨论: 对应第 3 部分的示例,这里接着通过一个简单的例子来说明恢复 VOB 的过程。
在 Windows 平台 : 控制面板 -> “ClearCase”-> “Services Startup” -> “Stop ClearCase” 在 Linux 平台上 :
在 Windows 平台 :
在 Linux 平台 :
ClearQuest 的恢复也包含两个部分,CQ DB 连接的恢复;数据库的恢复。这里只介绍前者。关于后者,涉及到 DB2、Oracle 或者 SQL Server 的数据库恢复,请参考相关文档。 第一种方法是使用之前备份的 profile,使用 CQ Maintenance Tool 将其导入 CQ 中就可以了,如图 7 所示。 图 7 使用 CQ Maintenance Tool6. 总结至此,大部分和复杂环境升级相关的主要内容介绍完毕。在文章的开头,我们设计了一种假设情况下的复杂部署环境,覆盖了有关集成、产品组件分散部署、多站点三个主要方面。接下来,在准备工作和升级工作中,围绕阶段升级策略展开讨论,并从版本的兼容性以及相关注意事项出发,为升级策略的正确性提供了有力的支持和参考。最后,以升级失败后的恢复收尾,为产品升级中遇到的大部分情况提供了较为完备的参考。 不过,在实际环境中,产品的部署和所假设的环境有很大差别:
由此可以看到,复杂环境的升级和复杂环境的部署其实有很大关系。一方面,由于部署的复杂化,一些其他的用户自定义配置文件在升级准备阶段需要备份(例如:HTTP 服务器的配置文件,CC 和 CQ 日常事务定制文件,等等)。另一方面,升级设计的服务器就不仅仅只是假设环境中那些服务器了。 但是,万变不离其宗——分阶段的升级策略依然是值得参考的。只要明白了为什么采用这种策略,就可以根据需要,自主调整升级方案的细节,参考版本兼容性,完成升级。当然,学习更多关于 CC/CQ 复杂环境部署的文章会利于理解其升级。这方面可以阅读参考文档中的相关文献。 参考资料 |