An automated VM-cloud management system populates the configuration management database, with the server and compute resource detail of the VMS; as part of an automated provisioning process. This is called the ‘CMDB’ or configuration management database. The CMDB may reside within the ITSM platform, or more commonly, within the Cloud accounts on a server. The CMDB should be backed up and the information sent to another cloud platform for Disaster Recovery.
Because cloud compute services can be ordered, approved, and automatically deployed at any time and on any day an engineer desires, this automated update to configuration management is critical. Following are changes to configuration management that you should consider in a cloud environment:
For clients with VM estates:
- VMs running within isolated Dev/Test subnetworks should not require the same level of configuration management as production VMs because they are sandboxes in which developers can work. There is little point in enforcing strict change and configuration management, which only slows down development efforts. Only when the VMs are deployed into production must the developers begin to follow all change, security, and configuration management policies.
- Updates to the Common Operation Environment (COE) must also be considered. Cloud compute services automatically deploy templates or build- images of standard operating environments. An example would be Cloud Formation Templates, or JSON scripts. These COE templates will be created with all updates, patches, and security certifications completed. These COE images can be automatically deployed within the cloud environment without going through the typical manual security process for each server.
For Cloud Platform providers:
- Update notifications to VM changes or deployments must be considered. Users or consumers of the cloud must be provided with advanced notice—10 days, for example— before any changes or updates are made to already deployed customer VMs. Customers may “opt out” of any planned upgrade within this window if they believe it will have a negative impact on their project, timeline, or code stability.
- Changes to the actual VM servers and hypervisor software should be treated differently than customer-owned (also called guest) VMs. Normally, the cloud provider upgrades its server farm. Then, in a different maintenance window, it schedules any necessary customer upgrades.
- Customers expect near-zero downtime in a cloud environment, so traditional maintenance windows or outages should be replaced, when possible, with rolling-over production systems to secondary hosts, performing upgrades on the offline systems, and then transitioning back to the primary hosts—preferably without customers experiencing any downtime.
When clients are deploying to a cloud platform the above VM considerations and Cloud provider responsibilities are important to understand, document and contract.
==END
