[配置管理]19服务器部署的关键因素

StarTeam服务器部署的关键因素1、服务器端组件部署策略根据StarTeam所支持团队的大小，需要采取不同的部署方案来保证StarTeam的性能及可靠性。存储库大小、并发用户数、是否部署StarTeamMPX、应用程序的复杂程度（指自定义表单、自定义字段等）等等，都会对StarTeam的性能产生影响。根据经验数据，团队的大小在一定程度上与project、view的数量成正比，而project、view的数量又决定了存储库中数据量，所以我们可以使用并发用户数来界定StarTeam配置库（ServerConfiguration）的大小。根据并发用户数多少把StarTeam配置库分为三种类型：1.小型配置库：并发用户数不超过50；2.中型配置库：并发用户数不超过100；3.大型配置库：并发用户数达到并超过100；1.1一个服务器上部署多个配置库对于小型或中型的配置库，可以把所有的StarTeam服务器端组件（StarTeamServer、Database等）都部署到一台机器上。下图给出了相应的部署图。一台机器上所有配置库的并发用户之和不能超过100，但一台服务器的并发用户数的峰值到达100时，建议把服务器上的某个配置库迁移到另一台机器上。StarTeamServer相关的RootMessageBroker进程、RootCacheAgents进程、DatabaseServer进程以及所有的StarTeamServer进程都运行在一台机器上，因此对机器配置有以下要求：DatabaseServer进程需要分配一个CPU及1G内存；每增加一个StarTeam配置库需要分配一个CPU及1G内存；1.2中型配置库当并发用户数达到中型配置库的标准时，首先需要为Database提供一个单独的机器安装。下图给出了相应的部署图。如图，除数据库独立外，其他进程仍然可以运行在同一台机器上。DatabaseServer进程占用的负载被转移后，允许的并发用户数可以到达200－300。然而对于有多个配置库的情况，vaults和databases会分布在不同磁盘上，不利于备份和管理，因此建议把需要备份的数据放到一个公用的磁盘上，如下图所示：1.3大型配置库大型配置库是指可以支持100个以上并发用户的配置库。对于大型配置库，需要给每个StarTeamServer进程提供单独的机器，DatabaseServer进程也需要单独的机器支持，RootMessageBroker进程，RootCacheAgents进程最好也使用单独的机器（MPX）支持。特别是当并发用户数达到并超过200、300时，MPX进程运行在单独的机器上会很好的消除StarTeamServer上的网络阻塞和资源争用。下面给出了多个大型配置库的部署图：对于大型配置库的部署需要注意：1.每个StarTeamServer进程需要运行在一个单独的机器上，机器配置需要满足2CPU、2G内存用于支持100－200的并发用户，200个以上的并发用户需要4CPU、4G内存；如果预期用户数还会持续增加，推荐使用4CPU、4G内存；2.DatabaseServer进程需要运行在单独的机器上，多个StarTeam配置库可以共享一个DatabaseServer。StarTeamserver和DatabaseServer之间需要1G的高速网络连接。3.RootMessageBroker进程，RootCacheAgents进程可以运行在同一台机器上，称为MPX。每个CacheAgent需要访问相应的vault，此时高速网络连接并不是必须的，通过网络的文件访问就足够了。如果需要使用工作流NotificationAgent，也可以部署到这台机器上。4.所有的StarTeamvault和database使用一个公共的存储服务器管理。2、影响服务器性能的因素对于StarTeam服务器端硬件的选择，需要考虑各方面的因素，例如，计划部署几个配置库（ServerConfiguration）、配置库中大概会有多少工作产品、预期的并发用户数、预期组织内项目及人员的增长情况等等。即使对这些因素有明确的的预期，在评估硬件需求的过程中也仅仅是估算，而不可能做到精确的计算。这是因为，配置库使用过程中会有一些不确定因素，例如文件大小、配置库增长情况、同时进行签出操作的并发用户数等等。正是因为有这些不确定因素，我们更需要了解StarTeam服务器端的各种服务对那种硬件资源的占用得更多。下面介绍StarTeam服务器端的各种服务对不同硬件资源的占用情况。2.1StarTeamServer进程相关StarTeamServer进程对硬件资源的占用按重要级别排序依次为：1)内存StarTeamServer进程推荐的最小内存为256M。如果需要支持10－20个用户，内存必须达到512M；当并发用户数介于50－100之间时，必须有1－2G的内存支持StarTeamServer进程；而并发用户数超过200时，必须有2－4G内存支持。注意：对于32位的Windows操作系统，给一个进程分配的最大虚拟内存是2G，当2G内存都被使用的情况下，StarTeamServer进程可以把最大虚拟内存调至3G。2)CUPCPU的速度、一二级缓存大小等参数都会对StarTeamServer的性能产生影响，由于它是多总线的架构，多个CUP对提高StarTeamServer的性能有帮助。当预期并发用户数介于25－50之间时，可以考虑使用带有双核处理器的机器；当并发用户数介于50－100之间时，可以考虑使用带有四核处理器的机器。3)网络在并发操作较多的情况下，网络带宽对StarTeamServer的性能有较大影响。如果使用独立于StarTeamServer的数据库服务器，那么需要在这两台服务器之间提供100M-1G的内网带宽。当连接StarTeamServer服务器的客户端很多，且执行的操作，例如批量的文件签出操作，也相当多时，客户端和StarTeamServer服务器端的网络连接将称为瓶颈。带宽为100M的内网将足以支持100－200个并发用户，当并发用户数超过200时，需要考虑使用1G的带宽。事实上，所有的StarTeamServer进程都是处理到数据库和Vault的I/O操作，下面介绍数据库和Vault对硬件资源的占用情况。2.2数据库相关数据库也是StarTeam服务器端的一部分，需要考虑数据库的配置、备份、收缩等操作。当需要考虑数据库硬件选择时，下面给出了一些参考意见：1)内存与StarTeamServer类似，数据库系统也是使用内存缓存机制来改进性能的。对于大型的StarTeam配置库，需要将数据库系统放到单独的服务器上，并使内存大小足以满足数据库服务的需要。2)磁盘阵列使用磁盘阵列会在很大程度上提高数据库I/O操作的性能，不同的RAID级别对性能改进和容错能力有不同程度的支持，可以考虑对数据库使用某种级别的磁盘阵列。3)CPU与StarTeamServer类似，数据库系统也支持多线程，使用速度更快，多个处理器的系统也会提高数据库系统的性能。4)网络前面提到过，如果有单独的数据库服务器，那么就要求在数据库服务器与StarTeamServer服务器之间使用高速的专线网络连接。2.3Vault相关所有基于文件的操作都是针对Vault进行的，例如签入、签出操作，添加附件等等。Vault由Cache、Archive、Attachments组成，下面给出针对这几个部分的I/O操作：1)CacheCache是Vault中使用最频繁的部分，签入文件时会向cache中新增文件；签出时，如果cache中已经有这个文件就直接签出，如果没有这个文件，待签出文件会被添加到cache中。2)ArchiveArchive的使用频率仅次于Cache，每个文件在签入时，会向archive中新增文件，或者更新archive中已有的文件。文件签出时，如果在cache中没有找到相应的文件，就会访问archive中的文件。3)AttachmentsAttachment中的文件的使用频率更低，只有当通过CR、task、topic和requirement对象访问时，才会向Attachment文件夹中添加文件或读文件。注意避免将Cache和Archive安装到系统盘。如果数据库和StarTeamServer在同一台机器上，避免将数据库数据文件与Vault存储在一个盘。如果有多个磁盘，请将数据库、Cache、Archive和系统分布在不不同的磁盘，从而使允许的I/O并发数最大。如果对Vault采用RAID机制，会提高Cache和Archive的性能。但是，由于Cache中的数据来源于Archive，因此RAID的容错特性只对Archive有效。2.4MPXMessageBroker相关MPX可以降低网络拥塞，即使是将MessageBroker与StarTeamServer进程部署到同一台机器上。但是在没有增加硬件的情况下，StarTeamMPX会使客户端相应时间和服务器端吞吐量有一定增涨。因为，MPXMessageBroker是独立的进程，可以通过把该进程与StarTeamServer进程部署到两台不同的服务器上来缓解网络拥塞。另外，MPXMessageBroker进程对所在服务器的要求并不高，内存大小和CPU数量对MessageBroker进程并没有影响。因为，MessageBroker进程只起通信服务器的作用，对内存和CPU的占用很少，而且几乎没有磁盘I/O操作。2.5使用性能相关如何使用StarTeam进行配置管理也会对某些特定操作的性能产生很大影响，下面总结了会对内存占用、数据库性能、客户端响应速度产生较大影响的因素：同时连接的客户端数：每个并发连接都会在StarTeamServer进程中占用少量的资源，每个活动的客户端请求也会分配到一个工作线程和一个可用的数据库连接；打开的视图个数：使用StarTeam客户端打开的每个视图都需要缓存一些与视图相关的信息。在一个客户端session内，暂时回滚到某个以前的视图也需要缓存一些信息；每个视图中item的个数：一个活动视图需要的缓存大小与视图中显示的项的个数成正比；分支视图的个数及层次：分支视图的数量和层次越多，针对特定事务启用的数据库进程也越多；可派生视图的创建：创建可派生所需要的时间与父视图中显示的工作产品的数量成正比。3、数据库容量规划相关StarTeam支持Oracle、MicrosoftSQLServer(以及MSDE)和IBMDB2数据库。当存储库支持的是小型团队（50－100人），而工作产品数量不超过中型（数千个工作产品）时，可以使用MSDE作为数据库存储库。当存储库需要支持大型团队（几千或上百个用户），或者工作产品数量巨大（上万或者更多）时，需要选择一种商业数据库。StarTeam存储库的增长主要取决于一些三种类型的信息：Object表：StarTeam会为每一类进行版本控制的对象（文件、文件夹、CR、Task和topic）建一个相应的表存储工作产品类型相关的数据。会给每个对象的初始版本创建一条记录，当对象被修改时，也会给后续的修订创建相应的记录。每个对象的记录将占用100－200字节，此外，每个工作产品表可以有2－4个索引，每个索引可以使每条记录的数据量增加50％。可以假设每个对象的修订占用400个字节，并以此进行粗略的估计。视图成员（Item）表：当向StarTeam视图中增加需要版本控制的对象时，会创建一个视图成员，或称为项。通过item将对象和视图关联起来了，并使用item来存储对象在视图中的特定属性。所有的item数据都存储在一张有索引的单独的表中，同时，表和索引记录中，每个item都需要300字节的空间。注意，当对象在多个视图中共享时（例如，从父视图派生一个子视图），每个视图中item的个数都在增加。例如，当1000个文件在三个不同的视图中都出现时，会创建3000个项（大概需要900K）。Log表：在存储库中，StarT