成功的管理分布地域的开发

为有效地管理软件开发，很多组织正在转移到IBM® Rational® ClearCase® 和 IBM® Rational® ClearQuest®平台。在这些组织计划采用这些技术时，为成功地用好这些技术，有必要了解支持这些工具的新硬件的相关知识。

1 概述

1.1 目标

为有效地管理软件开发，很多组织正在转移到IBM? Rational® ClearCase® 和 IBM® Rational® ClearQuest®平台。在这些组织计划采用这些技术时，为成功地用好这些技术，有必要了解支持这些工具的新硬件的相关知识。

本指南是写给支持计划组的，他们评估ClearCase实施方案的硬件需求。本指南集中描述IBM pSeries和xSeries服务器，以及它们的操作系统，pSeries的AIX和xSeries上的LINUX和Microsoft Windows®。本指南使用ClearCase 2003.06.00版本。

1.2 文档术语

网络。ESS单元构建得能够高度容错，它们使用如光纤通道、SCSI、ESCON和FICON等界面连接。

ESCON （S CONnector）: IBM S/390的光纤通道，依赖于连接方式，它可以在60公里的距离内传输率达到17 M字节/秒。ESCON允许外部设备跨越很大的范围如大学校区和城市范围。

FICON （FIber CONnector）: IBM 大型主机的通道，1998年起由G5服务器使用。它基于光纤通道标准，能够把ESCON的半双工的17MB/秒的速度提高到全双工100MB/秒。每个FICON通道每秒钟支持超过4,000次 I/O操作，相当于八个ESCON通道。

Logical Partitioning （LPAR）: 一种在pSeries 服务器 （从P630及以上）上的技术，它允许用户在一台服务器上创建多个服务器实例，而且可以给这些实例动态分配系统资源 （如CPU、内存等等）。

NAS （Network Attached Storage）: 一个连在网络上的专门的文件服务器。NAS设备包含一个微内核的操作系统和文件系统。它只处理支持通用文件共享协议的I/O请求，如NFS （UNIX） 和SMB/CIFS （DOS/Windows）等。

RAID （Redundant Array of Independent Disks）: 用于增加性能或者提供容错能力的子系统。RAID由两块或更多的普通硬盘和一个专门的磁盘控制器组成。它最初是为服务器和独立的磁盘存储系统开发的，但现在日益广泛使用在桌面计算机上，主要用来容错。RAID也可以用纯软件的方式实现，但这会降低性能，特别是在失败后重建数据时的性能。

Storage Area Network （SAN）: 一种网络磁盘存储设备。在大型企业中，一个SAN连接着多个服务器，作为中央存储池。相对于管理数百台拥有自己的磁盘的服务器来说，SAN可以改善系统管理工作。由于把所有公司的储存数据集中在单一的设备上，诸如磁盘维护和日常数据备份这样的功能就很容易安排和控制。在一些SAN中，磁盘自己就可以把数据复制到其它磁盘上作为备份，不需要通过任何主计算机处理。

Symmetrical multiprocessing （SMP）: 一种硬件的多处理器技术，计算机指令可以分配到多个CPU上以提高应用程序的性能。当提到4路或8路服务器时，表示它们分别有4个或者8个CPU。

Versioned Object Base （VOB）: ClearCase的数据储存库。

视图（View）: ClearCase的工作区，用来存取VOB中包含的文件。

回页首

2 ClearCase

ClearCase提供全面的软件配置管理（software configuration management，SCM）解决方案，包括版本控制、工作空间管理、过程控制和Build管理。它独特的、透明的、不干扰开发组的方法可以让开发组加速他们的开发过程循环，保证产品正确地发布，可靠地Build，发布以前产品的补丁，以及组织自动化的开发过程等等。这一切都不需要改变开发人员的开发环境和他们的开发工具。

通过对永久数据仓库VOB的存取，ClearCase使得多个开发人员进行并行开发工作变得更加容易。任何项目都可以使用多个VOB。单独的开发人员工作区，称为视图（View），控制着VOB的存取。

下面几节简要描述VOB和视图，以及讨论它们如何影响性能。

2.1 VOB 结构简述

VOB可以存储源文件、二进制目标文件、目录、Web文件、文档、或者任何在软件开发项目中产生的文件。每个VOB都有它自己的元数据仓库，用来存储VOB的上下文细节信息。元数据目录和互相独立的三个文件池共同组成了VOB的存储目录结构，如图1所示：

VOB database directory 中包含ClearCase的内部元数据，这些数据用来对储存在文件池中的文件进行跟踪，以及维护VOB数据的一致性。

File storage container 保存检入到VOB中的任何文件的全部版本信息。包括源文件、二进制文件、Web相关文件等等。由于代码不断的变更，保存在VOB中每个文件的版本不断增长，file storage container将会变得相当大。

Cleartext pool 是一个内部缓存，用来保存VOB中最近访问过的任何类型的文本文件。只要用户访问了文本文件，ClearCase将会自动更新Cleartext pool 。访问过的文件将复制到Cleartext pool中，以便其它想要在他们的视图中访问相应文件的开发者能够快速访问它。

Derived object pool 在一个缓存目录中保存二进制文件，以便允许这些文件被其它开发这共享，通过使用一个名为wink in的ClearCase程序。这些文件可以被wink in 到开发者的视图，并不需要把二进制文件复制到开发者的工作空间，这样可以保持开发者的视图最小化。关于wink in的更详细的信息可以参考IBM ClearCase用户指南，可以访问下面的链接 product documentation page.。

2.2 视图结构简述

与VOB类似，视图也有一个ClearCase定义的内部的数据结构。图2显示了视图存储目录的内容。

在视图存储目录中，主要的存储区是 .s目录，它是视图的私有区域。它包含检出的文件、不共享的二进制或者目标文件，以及临时文件。视图的空间大小将主要由产生的不共享的导出的目标文件大小决定。共享的文件可以被wink in，它们不增加视图的大小。

Config_spec 是一组规则，用来定义哪些文件在开发人员视图中可见。甚至在很大的视图中，config_spec 也不会变得很大，因为它只是一些简单的用来控制视图规则的文本文件。

Db_files 包含有关视图存储目录信息的ClearCase内部元数据。

2.3 VOB和视图大小的影响

VOB维护着所有基于源代码的修改信息，随着时间推移，它的大小将变得相当大。控制VOB物理存储空间大小的机制是在VOB服务器上设置的。VOB服务器地设置主要集中在开发和Build过程上，因为在这里能收集到最多的用来Build的数据。合适的配置、调整以及VOB服务器的可用性，这些都是ClearCase产品环境的基本原则。

旧的不再使用的VOB不需要保存，以便充分节约空间。主要问题在于是应该拥有一个大的VOB还是几个小的VOB，关键在于性能与易管理性的平衡。在下面的情况下，大的VOB将带来性能的瓶颈：

• 大的VOB通常由很多开发人员使用，它将很可能在VOB服务器上带来网络争用问题。
• 在VOB中保持大量的文件也将带来磁盘I/O资源的争用问题，因为多个视图都需要访问VOB文件用来Build或者把它们放到cleartext pool中。
• VOB增大后ClearCase将消耗更多的内存和CPU资源。

一般来说，你应该考虑把一个大的VOB按照有明确意义的方式分为几个小的VOB。如果VOB只有很少的使用率，那么它的大小不应该成为问题。另一方面，如果系统管理员的资源比较缺乏，而且只有少量的开发人员，这时使用大的VOB是有利的。

从2002版本开始，ClearCase VOB在其数据库中不再有记录数的限制。但是当VOB数据库的大小达到接近于两倍的VOB服务器的内存大小时，VOB的访问性能将开始显著下降。

回页首

3 ClearCase期望的硬件特性

选择硬盘配置和ClearCase平台时，需要考虑很多因素。例如开发组的大小、网络拓扑、地理位置分布等等，这些都将对硬件解决方案产生很大的影响。

在具体的部署建议之外，其它一些因素也是很重要的：

• 高性能: 为了稳定的、可预测的时间响应。
• 可靠性和可用性: 为了最大的正常运行时间。
• 可测量性: 为了评估将来增长的需求
• 有效的支持组织: 为了支持用户采用ClearCase。