Server configurations overview and guidelines

This topic provides an overview of server configurations and lists the guidelines to follow.

In this topic:

StarTeam server configurations

Before using StarTeam Server, you must decide what database to use and where to store the database and file revisions. Then you must create at least one StarTeam Server configuration (an instance of the StarTeam Server). This topic discusses StarTeam Server configurations and their storage hives.

A StarTeam Server configuration defines:

• The set of options, including endpoints (the TCP/IP port) and encryption levels, used for server access.
• Location of the database that stores project data and other related information.
• Locations for the repository and repository-related folders.

Any number of projects can be stored in the database associated with a particular server configuration. However, the database must be configured properly to store the amount of data produced by those projects. For more information about specific databases supported by StarTeam Server, refer to the StarTeam Release Notes.

You can create a server configuration by using the Server Administration tool. A server configuration defines a specific database as the repository for its data. To prevent corruption, that database can be associated with only one server configuration. However, that database can be used by other applications. The application stores all projects on the Server, which may contain numerous server configurations.

To access an existing project, you must first add its server configuration to your system. The StarTeam Server can be accessed from any of its clients. Each client must have a user name and the correct access rights to access the selected server configuration. Your company or team may store its data on several server configurations on one or more computers. Any of these configurations can be accessed from a number of clients.

More than one instance of the StarTeam Server may be running on the same computer. For example, you might run one server configuration with a sample project and another with a software development project, both on the same computer. Each server configuration has a different name and a different port or endpoint for each protocol. When a configuration is in use, another session using that configuration cannot be started.

Before creating a server configuration, you need to decide upon a unique name for the configuration. This name is case insensitive and cannot contain : \ /, but can contain blanks or apostrophes ( ' ).

The StarTeam Server places server log files in the location designated as the server configuration's repository path. When you first start a new server configuration, the StarTeam Server creates the Attachments folder, HiveIndex, and other folders in the same location. These folders are maintained by the StarTeam Server. Do not delete them.

Other server configuration settings control where, when, how, and by whom the data is accessed. Some initial settings that you provide for the server configuration are properties that are necessary to start it. For example, if the user name and password that allow StarTeam Server to access the database are not accurate, StarTeam Server cannot run. Before starting StarTeam Server, you can change these properties to meet your requirements.

Back to top

Native-II vaults/hives

Native-II is a vault architecture that provides greater scalability for all server configurations created with StarTeam and for server configurations converted to Native-II vault format with StarTeam. Server configurations have one or more hives. A hive is a logical disk container of files that includes an Archive area and a Cache area. The archive area consists of a folder tree in which unique file revisions are stored. The cache area consists of a folder tree that stores uncompressed file revisions on a temporary basis. Hives can hold an unlimited number of files, providing increased storage capacity, larger file revisions, more locations to store archives, and faster, more efficient performance. A single server configuration can have several hives, each of which has its own archive and cache path.

The initial hive used for storage of the server configuration’s archive files is created along with the server configuration. You must supply an archive path and a cache path to this hive when creating the server configuration. The default paths are repository_path\DefaultHive\Archives and repository_path\DefaultHive\Cache. If desired, the location of these paths can be changed later by using the Hive Manager dialog found in the Server Administration tool.

Native-II vaults store each file revision in its entirety (even though the archive file may be compressed). But the revisions can be spread over many volumes by the use of hives for storage. If one hive fills up, you can add another, without changing any data locations or moving any archive files. When a server configuration has multiple hives, StarTeam adds files to each hive in turn before reusing the first hive's archive path.

When you create a server configuration, it automatically has at least one hive (either the default or a custom hive). To increase the amount of available space for a server configuration, you can add one or more new hives with the Hive Manager. You can create hives while the server configuration is running, because the configuration already has an initial path, if only to a Default Hive in the repository path. The main purpose of the Hive Manager is to create new hives for an existing StarTeam configuration, to increase the amount of available space.

Back to top

Server configuration guidelines

In terms of initial planning, one of the most important decisions your organization must make is how many StarTeam configurations it will use. While distributing projects across multiple StarTeam Servers will increase administrative costs, it will also increase project independence and improve performance and availability. By estimating project growth and considering interdependencies ahead of time, you can avoid having to split up a configuration that has become too large. Below are some strategies to consider when developing the server deployment plan for your organization.

Advantages of shared server configurations

Transactional integrity	Because a configuration uses a single database, all data within the same configuration is transactionally consistent. That is, a configuration represents a data consistency boundary. If you backup and later restore a configuration, all information within the configuration will be restored to the same point in time.
Linking	Items in the same configuration can be linked, even if they are in different projects. StarTeam does not allow cross-configuration linking.
Sharing and moving	An item can be shared or moved to any folder, view, or project within the same configuration. Moving or sharing items across configuration boundaries is not allowed.
Administrative simplicity	Administrative tasks such as adding users and groups, applying security, performing backups, and so forth are done at the configuration level.
Shared customizations	Many StarTeam resources such as filters, queries, custom forms, and work-flows can be defined at the configuration level and shared by all projects. (However, custom forms and workflow can also be customized per project or per view.)
Shared server components	All data in the same configuration utilize a single server process, database, vault, and root MPX Cache Agent. New projects can be added dynamically without adding any new server-side components.

Advantages of Separate Server Configurations

Performance	Larger configurations take longer to start, use more resources, and tend to return larger command responses. Conversely, smaller configurations have less data and fewer concurrent users, so they tend to perform better in these regards.
Managing growth	Even if you initially place multiple configurations on a single machine, you can easily move a configuration to its own machine if you need to.
Maintenance schedules	Separate configurations can be independently started and stopped for installing patches, upgrading hardware, etc. When a configuration is offline, all projects it contains are unavailable.
Custom fields	Custom fields are added at the “type” level, which has configuration-level scope. This means that if you add a custom field to a CR, all CRs in that configuration will have a value for that field. Hence, if different teams or business units have competing interests in custom fields, this argues for placing their projects in separate configurations.

Back to top

Additional server configuration considerations

This section describes additional factors to consider when developing the server deployment plan for your organization.

Business unit divisions

When multiple business units require their own StarTeam projects, it often works well to define StarTeam Servers along organizational boundaries. That is, deploy a separate StarTeam Server for each major business unit or department, allowing each to access its own projects. Dividing along business unit lines isolates separate (and sometimes competing) requirements for security, backup processes, and other administrative issues. Separate servers can also help mitigate ownership or “turf” issues.

Where development life-cycle processes cross server configurations, clients can open multiple projects in a single StarTeam client. “Deploying” interrelated artifacts from one project to another can also be used to address cross-configuration integration needs.

Leverage StarTeam support for distributed teams

Team members that require access to the same artifacts should share a single StarTeam Server. Dividing a StarTeam Server solely due to geographically dispersed teams is not necessary. StarTeam was designed to work well with distributed teams. StarTeam emphasizes a centralized configuration approach with publish/subscribe messaging and MPX Cache Agents to support distributed teams.

Avoid partitions for internal/external access

In many situations, teams both behind and outside the corporate firewall require access to the same StarTeam configuration. A common practice in this scenario is to deploy the StarTeam Server process in the DMZ area of the firewall, placing the database server and storage server behind the firewall. Depending on the capabilities of the firewall, it may be appropriate to configure a dedicated port to the StarTeam Server. Alternatively, you can install two network interface cards (NICs) on the StarTeam Server machine: one “outward” facing and one “inward” facing. In this scenario, StarTeam allows specific inbound IP addresses (or address ranges) to be configured with different connection security requirements.

StarTeam provides SSL-like encryption for the command API, preventing eavesdropping on client/server traffic. All MPX Message Broker and MPX Cache Agent traffic is also encrypted, making data private across public links. To limit access to specific teams, you can use reference views or StarTeam’s security ACLs to limit access to specific projects, views, folders, and even individual artifacts. Other security features, such as strong password management and automatic account lockouts, further increase the viability of using the same StarTeam configuration for both internal and external users.

Plan for growth

In planning how many StarTeam configurations to create, take a long-term view: at least three to five years. If you can estimate concurrent user usage, this is the best metric for capacity planning. On today’s hardware, StarTeam readily supports up to 300 concurrent users. Some customers have configurations that peak at over 400 concurrent users, and one customer has seen peaks of 600 concurrent users. But at these concurrency levels, the application types become important (that is, batch applications tend to demand more than online clients). Even a 300-concurrent user load may drive down responsiveness unacceptably if a substantial number of users are running high-demand applications.

Another way to gauge configuration scalability is with command rates. You can measure the command rates of an existing configuration by using the server trace functionality. The StarTeam Server can be tuned to provide adequate performance with command rates from 200,000 to 300,000 commands per hour (56 to 83 commands per second). Command rates of 400,000 per hour (111 per second) or more with adequate performance have been observed with good network infrastructure (low latency). Attempts to drive a single configuration higher than this tend to produce unacceptable response times.

If you cannot project user concurrency rates or command rates, you can use “defined” users, but the server load is less predictable using defined users alone. In geographically-distributed user communities, we typically see a defined-to-concurrent ratio around 10:1. So, we would expect 1,000 named users to yield about 100 concurrent user sessions during peak periods. In less-distributed topologies, where users are concentrated in one or two time zones, we expect the defined-to-concurrent ratio to be closer to 5:1. If you don’t have better data, use these approximations to estimate your peak concurrent user rate.

After estimating your three-to-five year projection, you should have an idea of how many StarTeam configurations will be needed to support your user community.

Back to top

Project structure

An instance of the StarTeam Server controls the storage of your files. Each StarTeam Server instance runs a server configuration. Here’s an overview of the project structure controlled by an instance of StarTeam Server.

Server	A server is a computer running the StarTeam Server software. StarDisk enables you to connect to the server. The StarTeam Server controls the repository, which is a storage place for file revision archives, and a database that contains information about files, such as their descriptions, the number of revisions, and so on.
Project	A project is a way to group all the materials needed to accomplish some goal. Large, complex projects have many folders and files that are worked on by many team members. A project is the collection and organization of all these files and folders. A project might contain the files that comprise a software program, a technical publication, a legal case, a financial forecast, a building, an aircraft, or anything involving numerous files, each of which may undergo many revisions as the job progresses.
View	A view, also called a project view, is a way of looking at a project. It enables users to see the parts of the project they need to see, without the confusion of seeing the entire project. Users might use several different views of a single project, or views of several different projects, depending on the files they must use to do their work. Each project has only one root view, which is created automatically when the project is created. The root view may have several child views, each of which may have several child views of their own. A view that has child views can be referred to as a parent view.
Folder	Each view has one root folder. That folder can have any hierarchy of folders. Usually those folders have names that indicate their contents, such as Marketing Materials, Product Documentation, and Source Code.

Below are some diagrams illustrating how all these pieces fit and work together.

Server-level hierarchy

The server can manage any number of projects.

Project-level hierarchy

Each project has one root view and any number of child views.

View-level hierarchy

The root view and every child view has one application folder as a root folder.

Back to top

Using a test server

A simple but often overlooked measure you can take to smooth out administrative operations in your environment is to deploy a StarTeam Server configuration as a test server. Your test server can use lower-cost hardware than your production server, but it should be capable of running on a backup copy of your production server. With this capability, your test server can provide many useful benefits, including:

• You can test new SDK applications, workflow rules, release procedures, and so forth on the test server without fear of unwanted side-effects to your production server.
• You can use the test server to stage new releases of StarTeam and simulate upgrade and migrate operations before applying them to the production server.
• You can use the test server for training new developers and administrators.
• You can test backup and recovery procedures for your organization. Once you are sure your emergency procedures are functional, you can use the test server as a backup machine in the event of a catastrophic failure to the production machine.

Back to top