为有效地管理软件开发，很多组织正在转移到 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 文档术语
Enterprise Storage Server: 基于RAID的存储设备家族，包括IBM的大型主机、UNIX和 Microsoft Windows NT网络。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的存储目录结构。
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 到开发者的视图，并不需要把二进制文件复制到开发者的工作空间，这样可以保持开发者的视图最小化。
2.2 视图结构简述
与VOB类似，视图也有一个ClearCase定义的内部的数据结构。在视图存储目录中，主要的存储区是 .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。
3.1 VOB 服务器的规格
如果用户为ClearCase准备一个强大的专门的服务器，将更有可能成功安装ClearCase。虽然从技术上并没有什么能够阻止用户在ClearCase服务器上安装第三方的软件，但这已经证明不是一个好的选择。
VOB服务器定义为一台专门为了ClearCase的VOB服务的机器。在一个网络中可能有多台VOB服务器。为了最理想的性能，VOB服务器应该具有以下特点：
3.1.1 专门的机器
VOB服务器应该只完成ClearCase任务：
不要在VOB服务器上进行编译、Build和测试工作。
不要在VOB服务器上运行ClearCase 视图。
ClearCase视图与VOB竞争同样的资源；为了管理需要，可以在VOB服务器上拥有少量的视图。
不要在VOB服务器上运行其它的第三方软件 （如DB2或者 Informix）。
VOB服务器不应该作为：
网关服务器或者 UUCP/Internet 代理服务器。
NFS 服务器，除为ClearCase VOB使用之外 （没有邮件功能，没有用户根目录功能）。
NIS/DCE/AFS 主服务器或者 Windows 域服务器。
Web服务器。
VOB服务器上不允许直接用户登陆。
然而，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的必要性：
足够的磁盘控制器
对于频繁读写的VOB来说，建议在SCSI总线上，一个硬盘对应一个控制器。
磁盘阵列以及硬件的RAID系统也可以增加性能。
在一个通道上用菊花链连接几个硬盘将导致严重的性能降低。
如果磁盘控制器为多于一个的硬盘服务的话，它最好支持多个通道。但最好的性能是每个硬盘有专门的控制器和通道。
不要把VOB放在一个硬盘分区上，使用多个硬盘以平衡负载。
保存在硬盘上的VOB的最小建议容量是2G。
依赖于项目产生多少代码，这个数据可以变化。
更大的项目可以考虑使用IBM ESS等的需求。
RAID
ClearCase可以在任何RAID配置下工作，但硬件RAID是首选的。
基于软件的RAID将显著地降低 ClearCase的性能 （特别是在Build时）。
相对于RAID 5 ，更加建议使用RAID 0+1 （镜像和带区）。
RAID配置的细节可以参考 此定义。
SAN
ClearCase 支持SAN，它支持的NAS解决方案由 Network Appliance, Inc 提供。
在大多数部署情况下，推荐的SAN方案是ESS。
使用 GSA作为NAS设备也可以被评估。
足够的网络带宽
ClearCase 视图和VOB的主机应该在同一个子网，从一个机器访问另一个不需要使用路由。
如果现有的LAN已经过于饱和，你可以考虑为ClearCase 机器加一个子网（例如，在VOB服务器和配置View的机器上加一块附加网卡）
最好的解决方案是对于VOB服务器和视图客户端使用100MB的网络或者更高（FDDI, CDDI, ATM, 快速以太网，等等）。
在交换网络环境中使用ClearCase 时，支持10/100 baseT 的交换机通常已经足够了。
3.1.4 服务器资源优先级
在规划 ClearCase环境时，上面提到的因素都对ClearCase能工作得多好产生重要的影响（与项目大小相关）。机器资源影响的优先级顺序如下：
内存
磁盘 I/O （非常接近于内存）
网络
CPU
3.2 视图服务器规格
在一个地方可以选择使用一个或者多个视图服务器。视图服务器并不总是最优性能的，但是有很多因素指导着为什么采用这样的选择：
开发者没有支持ClearCase的机器。
开发者的主目录在他们本地没有备份，或者他们没有本地硬盘空间。
管理和备份单个的机器比多台分布的机器要容易。
由于NIS的安全原因
视图服务器与VOB服务器有很多类似的地方，因为视图也是一个本地数据库。视图服务器也应该是一台专门的服务器，但是他的内存和磁盘I/O的容量由下面因素决定：视图服务器上要呈现多少个视图，以及视图使用的方式 （开发、Build、测试、发布等等）。
如果开发者登陆到他自己的视图服务器工作的话，对视图服务器的资源需求并不是那么高。建议开发者工作在支持 ClearCase的桌面平台，使用本地视图多于使用视图服务器。在进行每晚的Build或者发布工作时，需要好的磁盘I/O。在视图服务器和相应VOB服务器之间不应该有路由。
4 企业部署指南
4.1 IBM 硬件概述
IBM有多种硬件解决方案，包括服务器，计算机芯片以及存储方案。服务器按照e-server分为以下几种不同的类别：
zSeries （Mainframe）
iSeries （AS/400）
pSeries （Power chips）
xSeries （Intel）
当前文档范围限制在pSeries 和xSeries系列服务器上。在我们继续处理其它系列时，文档将被扩展到其它IBM服务器产品的细节上。
IBM硬件产品也包括SAN。ESS是一个包含两台紧密耦合的RS/6000（或者pSeries）服务器的统一存储设备，提供全面的容错能力。ESS允许统一合并存储，提供高性能的数据解决方案。它支持全部主流平台，包括UNIX，Windows和大型主机。使用ESS的最关键的有利之处是在灾难恢复和数据可用性方面。对于大型项目，高度推荐使用ESS。
4.2 p-Series 服务器
IBM的e-server服务器家族已经完成了它自己的更新换代，IBM pSeries服务器的最新的芯片架构是POWER4芯片架构。POWER4芯片架构的范围包括入门级的桌面应用系统到顶级的类似p690的系统。PSeries服务器也有一些属于老一代的POWER架构，通常是POWER3。POWER2架构的服务器已经极为罕见了。可以按照下面的表来选择合适的用于VOB服务器或者视图服务器的pSeries服务器范围。
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提供的xSeries服务器基于Intel平台。本节主要给那些要在Windows 或者 Linux环境下使用ClearCase方案的组织使用。本节描述的服务器都可以作为VOB或者视图服务器。XSeries服务器分为两个类型。
4.4 SAN
SANs在两个和更多的设备之间采用串行通信（例如光纤通道或者 SCSI），它们比传统的并行SCSI有很多优点：
光纤通道 （和 SCSI） 可以合并，几个连接可以看作一个连接，比并行SCSI可以更快地进行通信。即使一个单个的光纤通道现在也可以达到每方向上2GB/秒的速度。
单个光纤通道SAN上可以连接16M个设备。
你可以很容易地从连接在SAN上任何计算机上访问任何连到SAN上的设备。
一个最好的例子可能是无服务器备份（通常被第三方备份软件引用）。这个系统允许磁盘存储设备直接通过高速的SAN链路把数据直接复制到备份设备上，不需要任何服务器的干涉。数据保持在SAN上，意味着数据传输不需要LAN，服务器的资源仍然可以被客户机使用。关于SAN的更多细节可以参考此文章。
4.4.1 VOB 数据的高可用性
上面提到，SAN设备可以作为关键的VOB存储的可靠仓库，它们非常容易使用和维护，同时又达到最大的可用性。另外的特性如下：
完成全部的写磁盘操作，即使在系统和电源失效时。
重新启动只需要一两分钟，快速恢复访问。
不需要 fsck （UNIX 或者 Linux 的文件系统检查程序）
fsck是一个UNIX程序，用来检查文件系统的内部一致性，坏块等等，还可以修复一些错误。
秒级的快照备份存储
存储容量可以在不中断情况下增长。
可用时间超过 99.99%。
4.4.2 优越的备份能力
从灾难恢复的观点来看，SAN能够提供很多好处。因为大多数SAN技术提供的备份方案既能保证很短的锁定VOB的时间，又能够保证快速的文件访问能力，SAN是一个理想的备份和灾难恢复方案。
IBM在SAN环境下提供的解决方案是ESS，它是一个顶级的SAN服务器，能够提供一些强大的高可用性的特性。它的一些具体特性如下：
Peer-to-Peer Remote Copy （PPRC）:
一个基于硬件的灾难恢复和工作负荷移植方案，它可以保证把数据同步复制到远程的地方。备份的数据拷贝可以用来从原始系统的失败中快速恢复，不丢失任何数据，可以选择保持商业应用正常运行。PPRC设计给那些用户，它们需要修复系统到原来的应用系统，并且可以接受一些原始位置的I/O操作的性能上的冲击。
FlashCopy:
提供快速的数据复制能力，以及消除了定期停止应用程序以便完成备份和恢复任务的需求。FlashCopy提供接近瞬间的数据复制，并能在需要时使数据可用，并不影响磁盘子系统和服务器应用程序的性能。而在传统的数据复制技术中，应用程序通常需要在整个数据备份期间关闭，时间可能长达几个小时。
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上投资：
有很大的代码和二进制版本
VOB服务器的后端方案不可靠
在最小的锁定时间进行离线的数据备份 （灾难恢复）
使用ClearCase 的interop 模式
降低管理服务器存储的管理开销
全面提升ClearCase的性能
5 典型的情景
本节描述一些使用ClearCase的项目遇到的典型的情景。本节仅仅提供一些典型情景，根据实际的环境限制，具体的实现方式可以不同。本节的估计只是基于从一个长时间的项目来看的最好的选择，没有考虑Build环境和测试环境。这些指导仅仅突出了服务器和客户端的需求。所有本文中提及的文件都可以扩展到几个VOB，它们基于实现的方式而不同。在所有后面的场景中提到的视图服务器的概念都是指开发组工作的开发服务器。传统上，任何安装ClearCase客户端的服务器都可以看作视图服务器，除了开发人员使用UNIX/Linux工作站之外，在那里视图的存储不能放在它们工作站本地。这时有专门的视图服务器。
5.1 小型项目 （10-30 用户）
5.1.1 情景1: 小型本地开发组，增长有限 （WSAD 环境）
这个情景有如下假定：
小型开发组，有10-20个开发人员。使用WebSphere Application Developer （WSAD） 在强大的桌面环境开发。
VOB服务器在AIX/Linux平台
单元开发Build由开发人员使用 WSAD完成
整个系统build由专门的Build团队完成
大约近60,000 个源文件
开发人员在UCM 环境中使用快照和动态视图
所有类似的情景都包含 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的情景相同，除了编译器不同之外。
在这种情况下，项目组：
在UNIX/AIX/Linux 架构下开发源代码
有一个VOB服务器和一个视图服务器客户端
视图服务器客户端是开发人员的机器，开发人员也在这里进行他们的开发和单元构建工作
由于项目组很小，开发/视图服务器客户端也可以作为每晚Biuld的服务器。
使用UCM 作为基于过程的开发模型
有大约60,000 个源文件
5.1.2.1 推荐的VOB服务器硬件配置
5.1.2.2 视图服务器推荐硬件
5.2 中等规模的项目 （30- 150 用户）
5.2.1 情景1: 使用WSAD工具开发的项目
基于WSAD的开发环境类似于前面的小项目情景，尽管它们的硬件需求不同。如果项目大小保持在30-60个用户，前面的场景的硬件配置也应该能够很好的工作。如果用户数跨越了60，那么必须至少选择一种下面的处理方式：
在p615服务器上增加内存和硬盘，它可以支持最多16GB内存和1-2 TB的硬盘空间。
升级到p630，它可以处理更多的用户负荷，有更好的硬件I/O管理能力。
在ClearCase中更多的I/O意味着更好的性能。在这个情景下源文件有大约250,000个，产生的Biuld大小为2-4 GB.
5.2.1.1 推荐的VOB 服务器硬件
5.2.1.2 推荐的视图服务器硬件
在这个情景下，用户主要工作在Windows客户端，因为它们使用WSAD。这时不需要视图服务器，因为用户的工作站就可以作为视图服务器来访问VOB。
5.2.2 情景 2: C/C++开发环境
在这个情景下处理的文件数目相当大（250,000个源文件，不包括二进制文件）。此时项目使用一个专门的二进制VOB服务器也是值得的。由于项目要处理二进制文件，它需要一个高可用性和快速的磁盘系统。在这种情况下，要确保你有RAID或者使用ESS用于存储。 项目有几个视图服务器，允许多个开发人员登陆同一台机器完成开发和单元构建工作。
5.2.2.1 推荐的VOB服务器硬件
5.2.2.2 推荐的视图服务器硬件
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服务。
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服务器硬件
5.3.2.2 推荐的视图服务器硬件
5.4 大型项目（超过250 个用户）
这个场景是非常复杂的项目，所有的开发人员位于同一个地点。项目构建得支持多个平台，还包括过去十年来已经构建和维护的代码。后端代码用C/C++编写，前端代码用Java编写，有些文档使用WSAD和国际化代码。项目环境如下：
超过500,000个文件
Builds产生10-15GB的二进制代码
17种不同的语言
使用makefile和Ant 脚本构建二进制代码
大约有500个开发人员
愿意在墙角放一台专门的服务器 （硬件合并努力的初步）
5.4.1 推荐的VOB服务器硬件
5.4.2 推荐的视图服务器硬件
在这种场景下，WSAD开发人员的工作站在SAMBA的帮助下可以作为视图服务器。
5.5 大型分布的项目 （超过250个用户）
这个场景与前面的非常类似，但此时开发人员是分布在不同地方的。这里推荐的配置与5.4节的非常类似。我们也建议使用单一的P690把所有服务器集中在一个物理实体中，其中拥有多个LPARS。
<script type="text/javascript"> function ImgZoom(Id)//重新设置图片大小 防止撑破表格 { var w = $(Id).width; var m = 550; if(w < m) { return; } else { var h = $(Id).height; $(Id).height = parseInt(h*m/w); $(Id).width = m; } } window.onload = function() { var Imgs = $("content").getElementsByTagName("img"); var i=0; for(;i
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 文档术语
Enterprise Storage Server: 基于RAID的存储设备家族，包括IBM的大型主机、UNIX和 Microsoft Windows NT网络。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的存储目录结构。
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 到开发者的视图，并不需要把二进制文件复制到开发者的工作空间，这样可以保持开发者的视图最小化。
2.2 视图结构简述
与VOB类似，视图也有一个ClearCase定义的内部的数据结构。在视图存储目录中，主要的存储区是 .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。
3.1 VOB 服务器的规格
如果用户为ClearCase准备一个强大的专门的服务器，将更有可能成功安装ClearCase。虽然从技术上并没有什么能够阻止用户在ClearCase服务器上安装第三方的软件，但这已经证明不是一个好的选择。
VOB服务器定义为一台专门为了ClearCase的VOB服务的机器。在一个网络中可能有多台VOB服务器。为了最理想的性能，VOB服务器应该具有以下特点：
3.1.1 专门的机器
VOB服务器应该只完成ClearCase任务：
不要在VOB服务器上进行编译、Build和测试工作。
不要在VOB服务器上运行ClearCase 视图。
ClearCase视图与VOB竞争同样的资源；为了管理需要，可以在VOB服务器上拥有少量的视图。
不要在VOB服务器上运行其它的第三方软件 （如DB2或者 Informix）。
VOB服务器不应该作为：
网关服务器或者 UUCP/Internet 代理服务器。
NFS 服务器，除为ClearCase VOB使用之外 （没有邮件功能，没有用户根目录功能）。
NIS/DCE/AFS 主服务器或者 Windows 域服务器。
Web服务器。
VOB服务器上不允许直接用户登陆。
然而，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的必要性：
足够的磁盘控制器
对于频繁读写的VOB来说，建议在SCSI总线上，一个硬盘对应一个控制器。
磁盘阵列以及硬件的RAID系统也可以增加性能。
在一个通道上用菊花链连接几个硬盘将导致严重的性能降低。
如果磁盘控制器为多于一个的硬盘服务的话，它最好支持多个通道。但最好的性能是每个硬盘有专门的控制器和通道。
不要把VOB放在一个硬盘分区上，使用多个硬盘以平衡负载。
保存在硬盘上的VOB的最小建议容量是2G。
依赖于项目产生多少代码，这个数据可以变化。
更大的项目可以考虑使用IBM ESS等的需求。
RAID
ClearCase可以在任何RAID配置下工作，但硬件RAID是首选的。
基于软件的RAID将显著地降低 ClearCase的性能 （特别是在Build时）。
相对于RAID 5 ，更加建议使用RAID 0+1 （镜像和带区）。
RAID配置的细节可以参考 此定义。
SAN
ClearCase 支持SAN，它支持的NAS解决方案由 Network Appliance, Inc 提供。
在大多数部署情况下，推荐的SAN方案是ESS。
使用 GSA作为NAS设备也可以被评估。
足够的网络带宽
ClearCase 视图和VOB的主机应该在同一个子网，从一个机器访问另一个不需要使用路由。
如果现有的LAN已经过于饱和，你可以考虑为ClearCase 机器加一个子网（例如，在VOB服务器和配置View的机器上加一块附加网卡）
最好的解决方案是对于VOB服务器和视图客户端使用100MB的网络或者更高（FDDI, CDDI, ATM, 快速以太网，等等）。
在交换网络环境中使用ClearCase 时，支持10/100 baseT 的交换机通常已经足够了。
3.1.4 服务器资源优先级
在规划 ClearCase环境时，上面提到的因素都对ClearCase能工作得多好产生重要的影响（与项目大小相关）。机器资源影响的优先级顺序如下：
内存
磁盘 I/O （非常接近于内存）
网络
CPU
3.2 视图服务器规格
在一个地方可以选择使用一个或者多个视图服务器。视图服务器并不总是最优性能的，但是有很多因素指导着为什么采用这样的选择：
开发者没有支持ClearCase的机器。
开发者的主目录在他们本地没有备份，或者他们没有本地硬盘空间。
管理和备份单个的机器比多台分布的机器要容易。
由于NIS的安全原因
视图服务器与VOB服务器有很多类似的地方，因为视图也是一个本地数据库。视图服务器也应该是一台专门的服务器，但是他的内存和磁盘I/O的容量由下面因素决定：视图服务器上要呈现多少个视图，以及视图使用的方式 （开发、Build、测试、发布等等）。
如果开发者登陆到他自己的视图服务器工作的话，对视图服务器的资源需求并不是那么高。建议开发者工作在支持 ClearCase的桌面平台，使用本地视图多于使用视图服务器。在进行每晚的Build或者发布工作时，需要好的磁盘I/O。在视图服务器和相应VOB服务器之间不应该有路由。
4 企业部署指南
4.1 IBM 硬件概述
IBM有多种硬件解决方案，包括服务器，计算机芯片以及存储方案。服务器按照e-server分为以下几种不同的类别：
zSeries （Mainframe）
iSeries （AS/400）
pSeries （Power chips）
xSeries （Intel）
当前文档范围限制在pSeries 和xSeries系列服务器上。在我们继续处理其它系列时，文档将被扩展到其它IBM服务器产品的细节上。
IBM硬件产品也包括SAN。ESS是一个包含两台紧密耦合的RS/6000（或者pSeries）服务器的统一存储设备，提供全面的容错能力。ESS允许统一合并存储，提供高性能的数据解决方案。它支持全部主流平台，包括UNIX，Windows和大型主机。使用ESS的最关键的有利之处是在灾难恢复和数据可用性方面。对于大型项目，高度推荐使用ESS。
4.2 p-Series 服务器
IBM的e-server服务器家族已经完成了它自己的更新换代，IBM pSeries服务器的最新的芯片架构是POWER4芯片架构。POWER4芯片架构的范围包括入门级的桌面应用系统到顶级的类似p690的系统。PSeries服务器也有一些属于老一代的POWER架构，通常是POWER3。POWER2架构的服务器已经极为罕见了。可以按照下面的表来选择合适的用于VOB服务器或者视图服务器的pSeries服务器范围。
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提供的xSeries服务器基于Intel平台。本节主要给那些要在Windows 或者 Linux环境下使用ClearCase方案的组织使用。本节描述的服务器都可以作为VOB或者视图服务器。XSeries服务器分为两个类型。
4.4 SAN
SANs在两个和更多的设备之间采用串行通信（例如光纤通道或者 SCSI），它们比传统的并行SCSI有很多优点：
光纤通道 （和 SCSI） 可以合并，几个连接可以看作一个连接，比并行SCSI可以更快地进行通信。即使一个单个的光纤通道现在也可以达到每方向上2GB/秒的速度。
单个光纤通道SAN上可以连接16M个设备。
你可以很容易地从连接在SAN上任何计算机上访问任何连到SAN上的设备。
一个最好的例子可能是无服务器备份（通常被第三方备份软件引用）。这个系统允许磁盘存储设备直接通过高速的SAN链路把数据直接复制到备份设备上，不需要任何服务器的干涉。数据保持在SAN上，意味着数据传输不需要LAN，服务器的资源仍然可以被客户机使用。关于SAN的更多细节可以参考此文章。
4.4.1 VOB 数据的高可用性
上面提到，SAN设备可以作为关键的VOB存储的可靠仓库，它们非常容易使用和维护，同时又达到最大的可用性。另外的特性如下：
完成全部的写磁盘操作，即使在系统和电源失效时。
重新启动只需要一两分钟，快速恢复访问。
不需要 fsck （UNIX 或者 Linux 的文件系统检查程序）
fsck是一个UNIX程序，用来检查文件系统的内部一致性，坏块等等，还可以修复一些错误。
秒级的快照备份存储
存储容量可以在不中断情况下增长。
可用时间超过 99.99%。
4.4.2 优越的备份能力
从灾难恢复的观点来看，SAN能够提供很多好处。因为大多数SAN技术提供的备份方案既能保证很短的锁定VOB的时间，又能够保证快速的文件访问能力，SAN是一个理想的备份和灾难恢复方案。
IBM在SAN环境下提供的解决方案是ESS，它是一个顶级的SAN服务器，能够提供一些强大的高可用性的特性。它的一些具体特性如下：
Peer-to-Peer Remote Copy （PPRC）:
一个基于硬件的灾难恢复和工作负荷移植方案，它可以保证把数据同步复制到远程的地方。备份的数据拷贝可以用来从原始系统的失败中快速恢复，不丢失任何数据，可以选择保持商业应用正常运行。PPRC设计给那些用户，它们需要修复系统到原来的应用系统，并且可以接受一些原始位置的I/O操作的性能上的冲击。
FlashCopy:
提供快速的数据复制能力，以及消除了定期停止应用程序以便完成备份和恢复任务的需求。FlashCopy提供接近瞬间的数据复制，并能在需要时使数据可用，并不影响磁盘子系统和服务器应用程序的性能。而在传统的数据复制技术中，应用程序通常需要在整个数据备份期间关闭，时间可能长达几个小时。
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上投资：
有很大的代码和二进制版本
VOB服务器的后端方案不可靠
在最小的锁定时间进行离线的数据备份 （灾难恢复）
使用ClearCase 的interop 模式
降低管理服务器存储的管理开销
全面提升ClearCase的性能
5 典型的情景
本节描述一些使用ClearCase的项目遇到的典型的情景。本节仅仅提供一些典型情景，根据实际的环境限制，具体的实现方式可以不同。本节的估计只是基于从一个长时间的项目来看的最好的选择，没有考虑Build环境和测试环境。这些指导仅仅突出了服务器和客户端的需求。所有本文中提及的文件都可以扩展到几个VOB，它们基于实现的方式而不同。在所有后面的场景中提到的视图服务器的概念都是指开发组工作的开发服务器。传统上，任何安装ClearCase客户端的服务器都可以看作视图服务器，除了开发人员使用UNIX/Linux工作站之外，在那里视图的存储不能放在它们工作站本地。这时有专门的视图服务器。
5.1 小型项目 （10-30 用户）
5.1.1 情景1: 小型本地开发组，增长有限 （WSAD 环境）
这个情景有如下假定：
小型开发组，有10-20个开发人员。使用WebSphere Application Developer （WSAD） 在强大的桌面环境开发。
VOB服务器在AIX/Linux平台
单元开发Build由开发人员使用 WSAD完成
整个系统build由专门的Build团队完成
大约近60,000 个源文件
开发人员在UCM 环境中使用快照和动态视图
所有类似的情景都包含 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的情景相同，除了编译器不同之外。
在这种情况下，项目组：
在UNIX/AIX/Linux 架构下开发源代码
有一个VOB服务器和一个视图服务器客户端
视图服务器客户端是开发人员的机器，开发人员也在这里进行他们的开发和单元构建工作
由于项目组很小，开发/视图服务器客户端也可以作为每晚Biuld的服务器。
使用UCM 作为基于过程的开发模型
有大约60,000 个源文件
5.1.2.1 推荐的VOB服务器硬件配置
5.1.2.2 视图服务器推荐硬件
5.2 中等规模的项目 （30- 150 用户）
5.2.1 情景1: 使用WSAD工具开发的项目
基于WSAD的开发环境类似于前面的小项目情景，尽管它们的硬件需求不同。如果项目大小保持在30-60个用户，前面的场景的硬件配置也应该能够很好的工作。如果用户数跨越了60，那么必须至少选择一种下面的处理方式：
在p615服务器上增加内存和硬盘，它可以支持最多16GB内存和1-2 TB的硬盘空间。
升级到p630，它可以处理更多的用户负荷，有更好的硬件I/O管理能力。
在ClearCase中更多的I/O意味着更好的性能。在这个情景下源文件有大约250,000个，产生的Biuld大小为2-4 GB.
5.2.1.1 推荐的VOB 服务器硬件
5.2.1.2 推荐的视图服务器硬件
在这个情景下，用户主要工作在Windows客户端，因为它们使用WSAD。这时不需要视图服务器，因为用户的工作站就可以作为视图服务器来访问VOB。
5.2.2 情景 2: C/C++开发环境
在这个情景下处理的文件数目相当大（250,000个源文件，不包括二进制文件）。此时项目使用一个专门的二进制VOB服务器也是值得的。由于项目要处理二进制文件，它需要一个高可用性和快速的磁盘系统。在这种情况下，要确保你有RAID或者使用ESS用于存储。 项目有几个视图服务器，允许多个开发人员登陆同一台机器完成开发和单元构建工作。
5.2.2.1 推荐的VOB服务器硬件
5.2.2.2 推荐的视图服务器硬件
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服务。
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服务器硬件
5.3.2.2 推荐的视图服务器硬件
5.4 大型项目（超过250 个用户）
这个场景是非常复杂的项目，所有的开发人员位于同一个地点。项目构建得支持多个平台，还包括过去十年来已经构建和维护的代码。后端代码用C/C++编写，前端代码用Java编写，有些文档使用WSAD和国际化代码。项目环境如下：
超过500,000个文件
Builds产生10-15GB的二进制代码
17种不同的语言
使用makefile和Ant 脚本构建二进制代码
大约有500个开发人员
愿意在墙角放一台专门的服务器 （硬件合并努力的初步）
5.4.1 推荐的VOB服务器硬件
5.4.2 推荐的视图服务器硬件
在这种场景下，WSAD开发人员的工作站在SAMBA的帮助下可以作为视图服务器。
5.5 大型分布的项目 （超过250个用户）
这个场景与前面的非常类似，但此时开发人员是分布在不同地方的。这里推荐的配置与5.4节的非常类似。我们也建议使用单一的P690把所有服务器集中在一个物理实体中，其中拥有多个LPARS。
2120
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
