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.
The next sections describe additional factors to consider when developing the server deployment plan for your organization.
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.
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.
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.
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.