Servers first
There are several ClearCase server host roles, and the order of installing ClearCase hosts is important. Most of the roles can be combined to one server, but consider separating at least VOB and view servers (see Figure 6-1 on page 71 and Figure 7-1 here).
Figure 7-1. ClearCase server roles
If you decide to start with one server only, you can use DNS alias names for each ClearCase role. Then, when time comes to separate the services, you can change the aliases in the DNS to point to the new hosts.
However, if you are using this approach, notice that ClearCase caches effectively, and it takes some time to flush the caches. You may end up restarting ClearCase services on clients to refresh the caches, therefore schedule the change outside of office hours, if possible.
Also, if a host running ClearCase is known by several names, each alias has to be introduced to ClearCase. For further information on this subject, please refer to alternate_hostnames in the ClearCase Administrator’s Guide.
Server connections
When the general environment is ready for ClearCase installation, check the connectivity to the respective server. As the administrator, you must have immediate access to the server(s). The administration can be done in most cases from the command line, but a graphical interface when administrating the server(s) makes it easier to perform the various tasks at hand.
On UNIX or Linux servers you could, for example, install the free Virtual Network Computing (VNC)[3] application that enables you to access your UNIX and/or Linux machines from any client running a VNC viewer. On many Linux distributions the VNC application is part of the distribution package. On a Windows workstation you have to install the application separately to be able to connect to the UNIX or Linux server.
In a UNIX/Linux environment you should also avoid using the root account for normal ClearCase tasks. Instead you should use the VOB administrator account. However, for some tasks, like changing the registry password, you must have root access.
In a pure Windows environment you can use the remote desktop feature to log in to the server using your VOB administrator account (which should belong to the ClearCase users group, the ClearCase albd process group, and to the local administrator group).
Before commencing, do a final status check:
Have you verified the administrator access permission?
Have all user and group accounts been created?
Do user accounts belong to the correct groups?
Registry server
The cornerstone of a ClearCase environment is the ClearCase registry server. It holds the information of ClearCase resources, such as which regions are available, which VOB are served by which hosts, and where the storage directories are, and which views are available. The ClearCase registry server communicates this information by using remote procedure calls (RPCs) with other ClearCase hosts.
ClearCase registry
Each ClearCase hosts knows only one registry server, which in turn, provides the only known ClearCase registry.
The following information exists in the ClearCase registry:
Information about the regions in this registry
Server, access path, and universal unique identifier (UUID) of VOBs in this registry (VOB objects)
Server, access path, and UUID information of views in this registry (view objects)
List of hosts that have contact to this registry
ClearCase region
A ClearCase region is a subset of views and VOBs introduced in the ClearCase registry of the registry server. If the registry has the information of the view or VOB object, the view or VOB can have a tag in any of the regions listed in this registry. If a tag exists for a VOB or view, the VOB or view can be accessed.
Each ClearCase host belongs to only one ClearCase region, which provides the following information:
VOB tag, access path, and UUID information for each VOB running on a ClearCase server in this region
View tag, access path, and UUID information for each view running on a ClearCase server in this region
Storage locations in this region for views and VOBs
The registry server belongs to one of these regions, however, not all the VOBs and views have to be introduced in the registry server’s region.
The clients that use this registry server can use the ClearCase regions listed in the registry.
Accessing VOBs or views from another region
You use the commands cleartool lsvob or cleartool lsview to list the VOBs or views. To list items from another region under the same registry, use the switch -region added by the region name from where you want the list.
To add a VOB from another region to the current region in this registry:
Create VOB tag with the command cleartool mktag -vob -region -tag... or using ClearCase Administration Console in Windows.
To get a VOB from another registry to current region:
Either use ClearCase Administration Console in Windows to introduce the VOB in the current region, or use command cleartool register -vob to introduce the VOB object and then use the cleartool mktag -vob -region... -tag... to create tag for the VOB in the region.
ClearCase registry services in a nutshell
Here is some detailed information about the registry. This information may be overkill, but we think it may clear up how the registry works:
Each ClearCase host knows only one registry server, and belongs to one of the registry regions this registry server provides. So, in a ClearCase environment, there is at least one registry server, which provides at least one ClearCase registry region.
The registry can be spread over multiple registry servers, but each server must host at least one region.
A registry server holds the information of the ClearCase regions in this registry, and the information about VOB and view objects. These objects are mainly identification and storage location of the VOBs and views. The registry collects host names of the list of clients when a client host connects to the registry host to ask for registry data.
Any ClearCase host belongs to one registry region, and only the VOBs and views having tags in the this region are easily accessible. Any VOB or view having a tag in another region in the same registry can be made visible by adding a tag for it into the current region.
The tag of a VOB or a view may be the same in the different regions, but it does not have to be. Please document the situation well, if you have the need for different tags for one VOB or view in different regions.
In the region information you may also have storage locations, which are used as default storage path patterns for new VOBs and views.
You may be forced to have several regions. If, for example, some of your hosts access the VOBs using a different path than the other hosts, these hosts using different paths must have a region of their own. The VOB and view tags and access paths are introduced to this region using the paths the clients can access. A classic example of this is having a mixed UNIX or Linux and Windows environment. In this case you need a region for the UNIX hosts and another for the Windows hosts.
Introducing VOB and view tags from a UNIX region to a Windows region has been made easy. There is a special tool, ClearCase Region Synchronizer, to assist with this.
VOB and view servers belong to only one region of the only known registry server. All VOBs or views stored in the server must have a tag in the server’s region to get the server processes up and running. If you have several regions, you have to create tags to the other regions for VOBs and views needed in those regions.
A VOB or a view cannot be tagged in any of the regions if the object information has not been introduced to the registry.
Thus, by having two separate registry servers, for example, you can have two isolated environments. You can, however, at your will, introduce any item from one registry to the other, and then make a tag for it in any region in that registry.
License server
Before you can access data in ClearCase repositories, you need a license. ClearCase license server provides the licenses for anyone asking for them. The licenses are floating user-based licenses, so a user might use several computers while taking just one license.
The system tries to reserve the license for someone who really needs it. When a user starts working with ClearCase, the license is reserved for him. Thereafter, the ClearCase client host he is working on checks for license availability every 15 to 20 minutes. If the user is accessing VOBs and the license is in use, the license will be held reserved, unless a more privileged user requires the license.
If, on the other hand, no access is made to the VOBs, the license time-out period is started and the license is released after the time-out for others to use. When the user accesses VOBs during this time-out period, the license is refreshed and a new time-out period starts to run.
Typically there are periods when a designer does not actively access the VOBs, but afterwards wants to perform a check-in, for which a license is needed again. To avoid unnecessary license requests and possible license unavailability situations, and to make the use of ClearCase as smooth as possible, the license is kept reserved by default for one hour.
After the one hour time-out, the license becomes available for others, if the user does not need it any more. You can make the time-out period shorter, down to 30 minutes, but it may then affect your work.
Thus, a short time-out period combined to a too tightly optimized amount of licenses may lead to a situation where a user does not get a license after a time-out, if there are no free licenses. Without a license, he cannot access the VOBs.
Install the license server next to the registry server to have a working environment for the VOB and view servers, which should be installed next.
VOB and view servers
You might consider starting with one server for all the ClearCase server roles (Figure 7-2). However, Rational recommends not installing a combined VOB and view server, and with a good reason.
Figure 7-2. All-in-one server
The different VOB and view server processes will eventually—when your ClearCase environment is running in full power—load the single server to a point where ClearCase actions start to take a noticeable amount of time. You may still not see too much processor load, nor network congestion, but some actions just seem to be slower than before.
In a small environment, an all-in-one server works at the beginning, but the ClearCase workload tends to build up, and finally you will have performance problems, which may be quite tough to resolve.
So, to be on the safe side, separate the view services from the VOB server. If you can handle backing up parts of local disk of the workstations, use local views. When using local dynamic views, most views will be created using the workstation’s disk space as storage. Also, the view server process for each view will run on the workstation. There will be less network traffic and the system will feel to be more responsive using local views.
VOB server hosts run several server processes for each VOB defined for that server. Additionally there is a process in each VOB server taking care of VOB database locking. This lock manager process manages the write and read access requests for all VOBs in the server. The lock manager has different capabilities on different architectures.
By default, a Windows server can support up to 18 VOBs and a UNIX or Linux server will support 36 VOBs. However, this can be tuned. The tuning is described in the ClearCase Administrator’s Guide.
About sizing of a server
Then how many VOBs can you have in one server? This is a tough question, and not so good an answer, is: It depends. ClearCase processes are typically small and they are not threaded. Still, if you have several processors in the server, ClearCase processes divide nicely between the processors. And if you have enough memory, the processing itself goes smoothly.
Windows servers, which have several VOBs, and possibly views, may stop processes mysteriously after 90 processes running because of a too small non-interactive desktop heap size. You might consider raising the heap to 2 MB as explained in the technotes, reference numbers 1142584 and 1131345, available at the ClearCase support site:
UNIX servers have a typically higher default number of processes and open file descriptors to start with. Familiarize yourself with how these can be raised, if needed.
Typically, in VOB servers, the number of processors is not the most important or the only thing affecting the server performance. If you are having performance problems, check that there is nothing else running on the ClearCase VOB server. Dedicate the VOB server to be purely a VOB server. Then check for memory. There should be enough memory to hold more than half of the DB directories of the VOBs on the server.
The processor power and memory are not the only factors in ClearCase server performance. The network and disk system I/O have a vital effect on the total performance. The more active your developers are and the more traffic they generate to the server, the more the network interface and disk system will be loaded.
When your ClearCase environment grows and becomes more active and you have to upgrade the servers, consider a server with a high-performance network interface, and a decent disk subsystem or a dedicated NAS to carry the file load, or you can split the load between several servers.
It is relatively easy to add another VOB server—or another view server—to an existing environment; it is even a manageable job to move VOBs or views from a server to another. No change is required in the clients, because the client hosts get the information from the registry server, and you will have updated the registry information when the change is done.
So start now, and keep in mind that your requirements and your environment will change with time. Be prepared!
You might start with a combined registry, license, and VOB server (Figure 7-3). When your environment grows, you might then consider separating the registry server. In a large active environment, the RPC load to the registry server could grow so high that other services might start to suffer. Or, perhaps more probably, you will have several VOB servers to carry the load.
Figure 7-3. Vob server running the key roles, separate view server
Prepare for change
The changes in your change management system have to be planned and documented, too. A change, such as having a new registry server, affects every ClearCase host in the environment. Plan for the future from the start. Details on changing parts of the ClearCase environment are documented in the ClearCase Administrator’s Guide, and the changes do affect the environment.
Changing the license server
The name of the license server is registered in every client and server during the installation process, and has to be changed in each host. In UNIX or Linux the information is in the file /var/adm/rational/clearcase/config/license_host, and in Windows the information is in the Windows registry, but in most cases it is easiest to change the information using the ClearCase Control Panel applet. In UNIX, root privileges are needed, and in Windows, local administrator rights.
Changing the registry server
Also registry server information is stored in each server and client host. For Windows hosts use again the Control Panel applet to change the Windows registry entry of the ClearCase registry server—and possibly ClearCase registry region—using local administrator rights. In UNIX, as root, go to the directory /var/adm/rational/clearcase/rgy and edit the contents of the rgy_host.conf to change the registry host and the contents of rgy_region.conf to change the ClearCase region.
You might, however, try another approach by using ClearCase registry backup feature to create a fresh backup of the registry and then run the command rgy_switchover. The hosts, that cannot be reached, have to be handled separately.
If you did not use a DNS alias for a registry server, remember to upgrade the site defaults in the release area.
Sometimes you might consider reinstalling the clients, to have the latest accepted patches or service releases.
Moving a VOB to another server
This affects the clients, as the VOB has to be locked for the move. No work can be done until the VOB is unlocked. Because you update the ClearCase registry information, no change in the client workstations is needed. Just take care to announce to your community to check in whatever they have checked out in that VOB.
Moving a view to another server
If you do this between dedicated view servers and not between workstations, all the work is done outside the workstations. Remember to shut down the view server process before the move and remove the tag, so the view cannot be used, move the storage directory, upgrade view storage location information, the view object, and retag the view. No change in the clients is needed, check-in before any major change in environment is a good procedure.
Relocating the release area
Relocation of the release area has no effect on the Windows ClearCase hosts. If you install UNIX hosts using the full copy method, this has no effect either.
For UNIX hosts, if you use another installation type, the relocation of the release area has vital effects. In practice, it is best to reinstall ClearCase in these hosts.
UNIX servers and Windows clients
If you are using Windows clients and a UNIX server, you need an interoperative solution to provide access to the VOB (and maybe view) storage areas. Basically, there are four different approaches you might take.
SMB (CIFS) on the UNIX server
To provide access for Windows clients, you can use Samba or TAS,[4] which support the Server Message Block (SMB) protocol. The advantage of this kind of solution is that you can do all the modifications in one place. The clients see the server as a normal Windows server; no additional software is needed in the clients.
[4] TAS, or TotalNET Advanced Server, is a product of Engenio Information Technologies, Inc., formerly LSI Logic Storage Systems, Inc., subsidiary of LSI Logic Corporation, who acquired Syntax in 2000.
The supported version of Samba fully supports the current Active Directory. If you use Samba on Solaris, build Samba as a 64-bit application for best ClearCase performance.
Common Internet File System (CIFS) is the latest incarnation of the SMB protocol.
NFS in the clients
With this solution no additional software is needed on the server, but every client must have NFS software installed. In some environments the NFS solution may have somewhat better performance in certain situations.
NAS or SAN for storage areas
Network-attached storage (NAS) is a computer with a very tuned up operating system providing disk space and access. It cannot be used for other purposes. NAS provides relatively high input/output rates and has built-in disk management often with a high level of data availability.
No additional software is needed for either the servers or for the clients, regardless of their architecture. The servers should have ClearCase installed in local disk space for stability, but view and VOB storage locations can be located on NAS disk space.
To fully utilize the speed of NAS, dedicate the NAS system solely to ClearCase VOBs or views. Other uses of the same NAS box can affect ClearCase performance.
A storage area network (SAN) is a high-speed network that allows the establishment of direct connections between storage devices and processors (servers) within the distance supported by fibre channels.
SAN can be viewed as an extension to the storage bus concept, which enables storage devices and servers to be interconnected using similar elements as in local area networks (LAN) and wide area networks (WAN): routers, hubs, switches, directors, and gateways. A SAN can be shared between servers and/or dedicated to one server. It can be local, or can be extended over geographical distances.
Use of snapshot views
When you use snapshot views, you do not need an additional interoperative tool; ClearCase File System (CCFS) running on the server handles this function. The use of snapshot views is the only supported way to have a Windows VOB server and UNIX or Linux clients.
The snapshot views provide a selected local copy out of the VOB or VOBs used in the design as well as giving an organized way to update both the snapshot and the VOB.
CCFS is installed in UNIX hosts by default and started when ClearCase is started. You can select not to start it. Refer to Appendix C, “ClearCase administration directory files” on page 327.
Server based solutions, other than the CCFS, that are used for interoperative access will need planning, installation, and testing phases.