为有效地管理软件开发，很多组织正在转移到IBM® Rational® ClearCase® 和 IBM® Rational® ClearQuest®平台。在这些组织计划采用这些技术时，为成功地用好这些技术，有必要了解支持这些工具的新硬件的相关知识。请点击文章顶部或底部的讨论，参与论坛讨论，与其他读者分享您对本文的看法。 1.1 目标 本指南是写给支持计划组的，他们评估ClearCase实施方案的硬件需求。本指南集中描述IBM pSeries和xSeries服务器，以及它们的操作系统，pSeries的AIX和xSeries上的LINUX和Microsoft Windows®。本指南使用ClearCase 2003.06.00版本。 1.2 文档术语 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 通过对永久数据仓库VOB的存取，ClearCase使得多个开发人员进行并行开发工作变得更加容易。任何项目都可以使用多个VOB。单独的开发人员工作区，称为视图（View），控制着VOB的存取。 下面几节简要描述VOB和视图，以及讨论它们如何影响性能。 2.1 VOB 结构简述 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 视图结构简述 在视图存储目录中，主要的存储区是 .s目录，它是视图的私有区域。它包含检出的文件、不共享的二进制或者目标文件，以及临时文件。视图的空间大小将主要由产生的不共享的导出的目标文件大小决定。共享的文件可以被wink in，它们不增加视图的大小。 Config_spec 是一组规则，用来定义哪些文件在开发人员视图中可见。甚至在很大的视图中，config_spec 也不会变得很大，因为它只是一些简单的用来控制视图规则的文本文件。 Db_files 包含有关视图存储目录信息的ClearCase内部元数据。 2.3 VOB和视图大小的影响 旧的不再使用的VOB不需要保存，以便充分节约空间。主要问题在于是应该拥有一个大的VOB还是几个小的VOB，关键在于性能与易管理性的平衡。在下面的情况下，大的VOB将带来性能的瓶颈：
一般来说，你应该考虑把一个大的VOB按照有明确意义的方式分为几个小的VOB。如果VOB只有很少的使用率，那么它的大小不应该成为问题。另一方面，如果系统管理员的资源比较缺乏，而且只有少量的开发人员，这时使用大的VOB是有利的。 从2002版本开始，ClearCase VOB在其数据库中不再有记录数的限制。但是当VOB数据库的大小达到接近于两倍的VOB服务器的内存大小时，VOB的访问性能将开始显著下降。 3 ClearCase期望的硬件特性 在具体的部署建议之外，其它一些因素也是很重要的：
3.1 VOB
服务器的规格 VOB服务器定义为一台专门为了ClearCase的VOB服务的机器。在一个网络中可能有多台VOB服务器。为了最理想的性能，VOB服务器应该具有以下特点： 3.1.1 专门的机器 VOB服务器应该只完成ClearCase任务：
然而，VOB服务器可以同时作为License服务器而不会产生明显的性能问题。在有一个VOB服务器的地方，把VOB服务器同时用作ClearCase注册服务器和License服务器是有意义的，这样可以降低系统失败点。 3.1.2 足够的内存 为获得较好的性能，在多数情况下建议全部VOB数据库的一半容量驻留在服务器的物理内存中。这是由于把VOB读到内存中可以充分降低对磁盘访问的需求，从而对增加性能有利。因此，一个只有256M内存的服务器只能支持很小的开发组的VOB。这个假定基于服务器上每个VOB的数据库信息都被同时访问，因此这是一个保守的估计。有可能VOB拥有大量的单元，这些单元与关联的小数据库相关。相对于其它需要更多的强烈的读/写操作（或者参与大的audited build）的VOB，这些处于只读状态的VOB（或者没有audited build）不需要那么多的资源。 3.1.3 快速的磁盘 I/O 对于经常处于日常更新状态如每晚的Build或者每日的开发工作的VOB来说，一个高性能的I/O子系统是必要的。下面这些点强调了对于ClearCase服务器有一个快速的磁盘I/O的必要性：
3.1.4 服务器资源优先级 在规划 ClearCase环境时，上面提到的因素都对ClearCase能工作得多好产生重要的影响（与项目大小相关）。机器资源影响的优先级顺序如下：
3.2 视图服务器规格
视图服务器与VOB服务器有很多类似的地方，因为视图也是一个本地数据库。视图服务器也应该是一台专门的服务器，但是他的内存和磁盘I/O的容量由下面因素决定：视图服务器上要呈现多少个视图，以及视图使用的方式 （开发、Build、测试、发布等等）。 如果开发者登陆到他自己的视图服务器工作的话，对视图服务器的资源需求并不是那么高。建议开发者工作在支持 ClearCase的桌面平台，使用本地视图多于使用视图服务器。在进行每晚的Build或者发布工作时，需要好的磁盘I/O。在视图服务器和相应VOB服务器之间不应该有路由。 4.1 IBM 硬件概述
当前文档范围限制在pSeries 和xSeries系列服务器上。在我们继续处理其它系列时，文档将被扩展到其它IBM服务器产品的细节上。 IBM硬件产品也包括SAN。ESS是一个包含两台紧密耦合的RS/6000（或者pSeries）服务器的统一存储设备，提供全面的容错能力。ESS允许统一合并存储，提供高性能的数据解决方案。它支持全部主流平台，包括UNIX，Windows和大型主机。使用ESS的最关键的有利之处是在灾难恢复和数据可用性方面。对于大型项目，高度推荐使用ESS。 4.2 p-Series 服务器
4.2.1 入门级服务器 在入门级服务器的列表中， p615和p630 服务器比p640 （B80）更加强大，因为它们采用了POWER4芯片组，对于ClearCase操作有更强大的I/O能力。 p640服务器适合在小的用户组作为视图/客户端服务器。p615在性能上等效于p640，可以作为视图服务器。作为视图服务器来说，p630能够比p640支持更多一些的用户。通过附加的RAM，这些服务器都可以支持大的VOB。 p615和p630都有两个不同型号：E 和C。除了"C"表示机架结构的系统和"E"表示桌面式系统外，它们没有别的区别。从存储的观点来看，"C"系列有更好的I/O通道可以支持较大的存储空间。 4.2.2 服务器配置 很多pSeries 服务器（除了p615 和640之外）支持LPAR，它允许组织在一台机器上运行多个虚拟服务器。例如，我们可以在一台P690机器上配置两个VOB服务器和一个视图服务器，并动态分配任何一个服务器实例的资源而不需要停掉它们。注意这些服务器的分配基于文档化的使用模型。更详细的信息可以参考IBM服务器目录。 4.3 xSeries 服务器
要了解硬件的更多信息可以参考 IBM的Intel硬件目录。 4.4 SAN
一个最好的例子可能是无服务器备份（通常被第三方备份软件引用）。这个系统允许磁盘存储设备直接通过高速的SAN链路把数据直接复制到备份设备上，不需要任何服务器的干涉。数据保持在SAN上，意味着数据传输不需要LAN，服务器的资源仍然可以被客户机使用。关于SAN的更多细节可以参考此文章。 4.4.1 VOB 数据的高可用性 上面提到，SAN设备可以作为关键的VOB存储的可靠仓库，它们非常容易使用和维护，同时又达到最大的可用性。另外的特性如下：
4.4.2 优越的备份能力 从灾难恢复的观点来看，SAN能够提供很多好处。因为大多数SAN技术提供的备份方案既能保证很短的锁定VOB的时间，又能够保证快速的文件访问能力，SAN是一个理想的备份和灾难恢复方案。 IBM在SAN环境下提供的解决方案是ESS，它是一个顶级的SAN服务器，能够提供一些强大的高可用性的特性。它的一些具体特性如下：
4.4.3 支持 UNIX/Windows 混合环境 在ClearCase 中，把需要在UNIX 和 Windows客户端共享同一个VOB库的环境称为interoperability （或者interop）环境。 由于UNIX客户端不能访问Windows的VOB或者视图（ClearCase的限制），用户总是工作在位于UNIX主机上的VOB服务器的interop环境。 在把VOB存储放在SAN上后，Windows客户端可以访问UNIX VOB的数据-不需要在每个Windows客户端上安装NFS或者在UNIX服务器上安装SMB模拟器（CIFS）。为了在没有CIFS的情况下访问UNIX VOB 数据，在Windows下使用Snapshot视图。如果需要支持动态视图，需要在UNIX服务器上安装CIFS模拟器，或者在工作站上安装NFS客户端。 4.4.4 何时项目需要在SAN上投资？ 尽管对于任何使用ClearCase的项目我们都强烈建议使用SAN，但它并不总是必须的。存在下面的因素时，你可以考虑在SAN上投资：
5 典型的情景 5.1 小型项目 （10-30
用户） 这个情景有如下假定：
所有类似的情景都包含 SAMBA，因为后端在UNIX下而客户端在Windows下。 5.1.1.1 VOB服务器推荐硬件 由于 UCM是非常I/O 密集的，表3中给出的环境是比较理想的：
5.1.1.2 视图服务器推荐硬件 在这个情景下，用户主要工作在Windows客户端，因为它们使用WSAD。这时不需要视图服务器，因为用户的工作站就可以作为视图服务器来访问VOB。 5.1.2 情景 2: 小型本地开发组，增长有限（C/C++ 开发环境） 在C/C++开发环境下开发的范围变化很大。这个情景主要指那些写后端代码和维护以前的代码的开发组。通常多数企业C/C++开发是在UNIX架构，尽管也有相当一部分的Visual C++开发人员。对于Visual C++开发环境，与上一个使用WSAD的情景相同，除了编译器不同之外。 在这种情况下，项目组：
5.1.2.1 推荐的VOB服务器硬件配置 本情景的合适的VOB服务器环境如表4所示：
5.1.2.2 视图服务器推荐硬件 这里我们推荐的视图服务器的配置如表5所示：
5.2 中等规模的项目
（30- 150 用户） 基于WSAD的开发环境类似于前面的小项目情景，尽管它们的硬件需求不同。如果项目大小保持在30-60个用户，前面的场景的硬件配置也应该能够很好的工作。如果用户数跨越了60，那么必须至少选择一种下面的处理方式：
在ClearCase中更多的I/O意味着更好的性能。在这个情景下源文件有大约250,000个，产生的Biuld大小为2-4 GB. 5.2.1.1 推荐的VOB 服务器硬件 对于这样的项目，表6中的硬件配置是首选的：
5.2.1.2 推荐的视图服务器硬件 在这个情景下，用户主要工作在Windows客户端，因为它们使用WSAD。这时不需要视图服务器，因为用户的工作站就可以作为视图服务器来访问VOB。 5.2.2 情景 2: C/C++开发环境 在这个情景下处理的文件数目相当大（250,000个源文件，不包括二进制文件）。此时项目使用一个专门的二进制VOB服务器也是值得的。由于项目要处理二进制文件，它需要一个高可用性和快速的磁盘系统。在这种情况下，要确保你有RAID或者使用ESS用于存储。 项目有几个视图服务器，允许多个开发人员登陆同一台机器完成开发和单元构建工作。 5.2.2.1 推荐的VOB服务器硬件 表7显示了本情景下合适的硬件配置：
5.2.2.2 推荐的视图服务器硬件 这个情景下最理想的硬件配置如表8所示：
5.3
中等规模的项目（150-250 个用户）,
成长的和地理分布的 5.3.1 情景1：使用WSAD工具开发的项目 在这种情景下，使用ClearCase 的用户组与前面的情景很类似。因为我们使用WSAD作为开发环境，用户的机器和构建服务器都可以作为客户端。当工作在WSAD环境下时，UCM是合适的开发方法，此时UCM甚至可以支持多地点的开发。这时代码比5.2.1.1.节的情景稍微多一些（大约300,000个源文件）。仅有的不同之处是那里用户组不是位于多个地方。 5.3.1.1 推荐的VOB服务器硬件 本例中，可以在不同的地方使用不同的VOB服务。表9是最低推荐的配置：
5.3.1.2 推荐的视图服务器硬件 在这个情景下，用户主要工作在Windows客户端，因为它们使用WSAD。这时不需要视图服务器，因为用户的工作站就可以作为视图服务器来访问VOB。 5.3.2 情景2: C/C++开发环境 这个情景与5.3.1节提到的情景非常类似，除了用户可以分布在不同地方之外。此时文件数比WSAD情景要多，因为多数C/C++开发支持重用的代码 （大约有350,000个或者更多）。这些文件将分布在数个VOB中，正如本文档其它情景中提到的一样。 5.3.2.1 推荐的VOB服务器硬件 表10的硬件配置是这个情景下的最小配置：
5.3.2.2 推荐的视图服务器硬件 表11为推荐的最低配置：
5.4 大型项目（超过250
个用户）
5.4.1 推荐的VOB服务器硬件 此时，表12的配置是合适的：
5.4.2 推荐的视图服务器硬件 在这种场景下，WSAD开发人员的工作站在SAMBA的帮助下可以作为视图服务器。对于其它用户，视图服务器的配置如表13所示：
5.5 大型分布的项目
（超过250个用户） 6 附录 A 6.1 硬件配置表
6.1.2 客户工作站（对每个目标平台重复此表）
6.1.3 ClearCase 内部操作 不管是从服务器还是客户机来看，下面提到的方面都是需要考虑的。如果文件系统共享是在服务器端，那么服务器应该有足够的CPU资源以便文件系统共享方案能够支持更多用户。如果文件系统共享是在客户端，要考虑需要管理哪个级别的客户权限以便访问文件系统
6.1.4 网络架构和远程访问 在ClearCase 中网络架构是一个关键因素。在企业环境中部署ClearCase 时需要考虑多种因素：
6.1.5 专用服务器 在ClearCase环境中，预先知道哪些服务将被放到ClearCase VOB服务器上是有利的。需要考虑的因素如下：
6.1.6 客户端环境 客户端环境就是开发人员使用ClearCase 进行他们日常工作的环境。在把ClearCase 安装到用户的桌面前，理解客户端环境是一个好的习惯。为了保证安装ClearCase 后其它应用也能正常工作，也需要评估一下客户端环境。
7 附录 B （ClearCase
文件存取路径）
7.1
存储目录和远程文件访问 ClearCase 应用和ClearCase Multi-Version File System （MVFS） 需要访问存储目录的内容。在ClearCase 的3.2.1版之前，所有这样的访问都使用标准的操作系统文件访问机制。例如在checkin操作时，运行在客户端系统上ClearCase过程将打开，读写源文件容器，以便检入信息。一般来说，VOB存储目录与checkin执行的机器是不同的机器。这时ClearCase 客户端过程使用远程文件访问机制来访问源文件容器。ClearCase 使用的远程文件访问机制依赖于：
7.2 同种环境和interop环境对比 在版本 3.2.1以前， interop 模式需要下面至少一种情况为真：
剩余的内容描述版本 3.2.1及以后的特性。 7.2.1 何时使用哪种远程文件访问机制？ 正如上面描述的，使用远程文件访问机制依赖于几个因素。对于任何具体配置，都可以使用超过一种的远程文件访问机制。要想理解应该使用那种机制，参考下面的内容： 7.2.1.1 VOB存储目录访问 下面的表14描述了VOB服务器和客户端类型、视图类型、访问类型以及相应的远程访问机制。访问类型列描述了ClearCase文件是如何访问的：
出现 "*"意味着在不管出现"*"的列如何选择，这一行都适用。
注释： 1. ClearCase Control Panel中的Use CCFS 检查框控制这个配置的行为：如果清空检查框，访问UNIX服务器时，ClearCase 需要NFS 或者TAS。如果选中检查框， ClearCase将使用 CCFS （访问UNIX服务器时不再需要NFS 或者TAS）。检查框的设置不影响访问非UNIX的服务器。 2. 一些操作（如 compare）使用NFS或者TAS，另一些操作（如 checkin， make branch）使用CCFS。如果Use CCFS检查框清空，所有操作都使用NFS 或者TAS。 3. 在特定情况下，运行在Windows NT 客户端的动态视图服务器过程是否使用CCFS访问VOB存储目录下的远程文件，依赖于 Use CCFS 检查框的设置。 （"特定情况"指视图服务器过程必须在VOB cleartext 池中创建版本的cleartext 时。） 7.2.1.2 视图存储目录访问 下面的表15描述了不同的客户端和服务器操作系统类型以及视图的不同类型下使用哪个远程文件访问机制。（注意当视图服务器和客户端在同一台机器上时，直接使用本地文件系统访问视图存储目录，不需要远程文件访问机制。）
注意 Windows 9x 客户端不能使用 UNIX 视图。 7.2.2 怎样设置"Use CCFS" 是最好的？ 对于怎样设置"Use CCFS" 是最好的这个问题没有一个简单的答案。使用CCFS的主要的益处在于，当客户端系统仅仅使用快照视图而且他们需要访问UNIX VOB时，不需要购买、安装、配置和管理额外的软件。当符合以上需求而不能负担额外的费用时，应该使用CCFS。 在对比 CCFS和NFS时，另一个需要考虑的因素是， CCFS 构建在 TCP之上，而目前所有Windows NT下实现的NFS客户端都构建在UDP上。这二者各有其有利和不利的方面。依赖于使用的网络状况，网络的速度和服务器与客户端的相对位置，以及系统负载容量， NFS/UDP可能比CCFS/TCP快，也可能比它慢。 注意: 在你的环境下测试ClearCase 使用CCFS的性能时，确保安装了最新的补丁包，以便你能够运行CCFS的全部最新的性能改进。
|
