- Created by Eric Puchalski , last modified on Nov 20, 2018
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 16 Next »
Equipment racks (including those for servers, PDUs, telecom equipment, etc.) require unique identifiers based primarily on the rack's physical location. Rack names are divided into three segments with the segments separated by hyphens. Since rack names are based on the rack's location, a rack name could change in the event the rack is moved from one physical location to another. Rack names follow the form of:
{data_center}-{zone}-{identifier}
Where:
{data_center} | A code representing the standard UCI abbreviation for the data center or computer room in which the rack is located. All data centers and computer rooms have a unique identifier. See the list below for acceptable data center codes. |
---|---|
{zone} | A code indicating the unique space identified for the room or area where the rack is located. If the zone has a room number that defines the entire zone then that room number should be used. If the rack is located in a room that is divided into several smaller areas then use a code that indicates in which area in the room the rack is located. See below for a list of valid zone codes when a room number is not an appropriate choice to indicate the zone. |
{identifier} | An identifier that is unique to the rack within the data center and zone where the rack is located. The identifier can be any combination of characters, numbers, or symbols but should be kept fairly simple in order to keep the complete rack name easy to manage. |
Data Center Codes
Only data center codes from the following list should be used when generating rack names:
OITDC | OIT Data Center at Engineering Gateway |
ADC | Aldrich Hall Data Center |
CPDC | Central Plant Data Center |
SLDC | Science Library Data Center |
SDSC | San Diego Supercomputer Center |
Code | Data Center |
---|
Zone Codes
Only zone codes from the following list should be used when a room number is not appropriate for a rack name:
Code | Zone |
---|---|
SSP | Secure Server area in the OIT Data Center at Engineering Gateway |
CORE | Core Server area in the OIT Data Center at Engineering Gateway |
ALH115 | Room 115 at Aldrich Hall |
EG1141 | Room 1141 at Engineering Gateway |
ROWx | A Row of racks with x being the row designation. |
Equipment Rack CI Name Examples
The following are examples of CI names that have been standardized using the conventions described above.
Rack Name | Description |
---|---|
OITDC-CORE-J31 | Rack J31 located in the core zone of the OIT Data Center at Engineering Gateway. |
ADC-MAIN-B | Rack B located in the main zone of the Aldrich Hall Data Center. |
CPDC-ROWA-01 | Rack 01 located in Row A at the Central Plant Data Center. |
Typical Life Cycle for Equipment Racks
Although some CIs have a special life cycle, the typical life cycle for most CIs representing hardware is:
Phase 1: Request & Approval
During this phase, a need for the asset is determined and a decision is made to deploy the asset. Specifications for the equipment are determined, quotes are obtained, approvals are collected from appropriate stakeholders, and a supplier is selected. In some cases, the "supplier" may be internal if, for example, an existing device can be repurposed or one is located in another department.
Phase 2: Ordering & Acquisition
If the asset is being acquired from a third party, an order is placed. If the asset is being transferred internally within OIT or from another department, the required documentation is prepared and executed. This phase ends at the point where the asset has been delivered and is ready for installation or configuration.
Phase 3: Testing & Installation
The asset must be compared to the original specifications and acquisition documents to confirm that it matches the original requirements. Any required assembly and configuration is done during this phase. This includes operating system software, application software and services, databases, network connections, user definition and security rules, and arrangements made for backups and disaster recovery. When all configuration steps are complete, a system test is performed on the asset in place to ensure it meets all client requirements. This phase ends when the asset is ready to be deployed into production.
Phase 4: In Service & Maintenance
This phase represents the useful production life of the asset. Throughout this phase, the asset will undergo periodic maintenance, upgrades, failures, and fixes. At some point, the usefulness of the asset will come to an end and plans need to be made to take it out of service. (Normally, these plans are made well in advance of the decommissioning of the asset.)
Phase 5: Retirement
When the asset is no longer needed, either because it is being replaced by something newer or it no longer serves any useful function, it is retired. Retirement can be a fairly complex process depending on the asset class. If the services provided by the asset are no longer needed then retirement can be as simple as taking the asset off line and disposing of it or making it available for other purposes. Plans for retirement are generally made well in advance of the actual deinstallation of the asset.
CI Maintenance
Owner | Create CI | Change CI | Decommission CI | Maintain Relationships | Comments |
---|---|---|---|---|---|
|
|
|
|
|
Typical Relationships
The following relationships should be used when defining dependencies for equipment racks:
Relationship | Dependent Class |
---|---|
Configuration Management Process
Overview
CI Life Cycles Overview
CI Naming Standards Overview
How to Maintain the CMDB Quality and Data Integrity
Resources
Committee Membership and Meetings
C/wiki/spaces/adcom/pages/68025789
OIT Architecture Review Board
Configuration Items
On this page...
- No labels