Server Types

We define five tiers of servers. No product requires all five. Five are the maximum. A product will likely have several servers for different purposes in each tier.

Prototype (proto): In ISDA's colocation rack. Defined as temporary, try-out, crash-and-burn systems.
Development: Virtualized via Server Operations' virtualization service. The environment for developers to perform their project work.
Test: Virtualized via Server Operaions virtualization service. The environment for internal ISDA testing.
Staging: Real production hardware via Server Operations standard offerings. For products that require it, this is for external developers or other end-users to test their integration. ISDA treats these as production. The configuration of this system is always identical to production.
Production: Real production hardware via Server Operatons standard offerings. This is the live system.

Note: For products that do not require staging, tiers, "test" will match the production configuration and all other requirements for a staging system, and IPS will not requisition a virtualized test environment.

Basic Naming Pattern

A hostname is composed of three call signs separated by hyphens. The last call sign is appended with a number to indicate the number of hosts in service for that tier. It ends up taking the form as \[product\] - \[tier\] - \[type\]\[number\], for instance "cms - dev - wcm1" or "map - prod - ws1". Each call sign is 2 to 5 characters.

Product and Type Calls Signs

map: MIT Application Platform
- ts: Touchstone, single sign-on (example map-test-ts1)
- ws: web-services environments (example: map-dev-ws1)
cms: content-managment system
- stlr: Stellar course-management system (example cms-test-stlr2)
- th: Thalia image management (example cms-dev-th1)

Production Servers

Naming Convention: \[product\]-prod-\[service\].mit.edu. Example: map-prod-ws1.mit.edu

Server Ops maintained physical hardware. No virtualization.
Assume that each service requires at least two load-balanced servers.

Staging Servers

Naming Convention: \[product\]-stage-\[service\].mit.edu. Example: map-stage-ws1.mit.edu

Server Ops maintained physical hardware. No virtualization.
Assume that each service requires at least two load-balanced servers.

Test Servers

Naming Convention: \[product\]-test-\[service\].mit.edu. Example: map-test-ws1.mit.edu

Server Ops virtualized server.
These are testing for developers, not operations. Assume only one server instance per service required.

Development Servers

Naming Convention: \[product\]-dev-\[service\].mit.edu. Example: map-dev-ws1.mit.edu

Server Ops virtualized server.
These are for software development, not operations or infrastructure prototyping. Assume only one server instance per service required.

Prototype Servers

Prototype servers are on ISDA's colocation rack. Prototypes are designed to crash and burn so IPS selected a very generic namespace to avoid the overhead of requesting new names from server operations on a regular basis.

First Call Sign	Second Call Sign	Third Call Sign
real: for hostnames of actual server hardware	proto: this is always the second part of the name	alpha, beta, etc: greek alphabet in order real machine is added to farm or VM is created.
virt: for hostnames of virtual operating systems

The Result: Names in the form "real - proto - alpha" or "virt - proto - omega."

Naming Convention Notes for Hostnames

numbers: Numbers describe the number of servers for that service for that tier. map-dev-ws1 and map-test-ws1 are both legal, because both are the 1st server rolled out for the service for that tier.

product: A 2 to 5 letter call sign for either a product group (such as map for MIT Application Platform) or a Meta-Project that has other Projects as its components (Project Athena, Project Minerva). **

** The previous convention was to use the department name in this spot, such as ISDA. However, these change often, but product or project names change less often. Also note that Athena servers are generally maintained by Server Operations, which has their own naming scheme and set of host organization policies.