IBM Service Delivery Manager puts you in the driver’s seat: Reserve virtual resources before you need them
by Paul Quigley
This discussion focuses on the reservation system when provisioning virtual servers with IBM Service Delivery Manager (ISDM). Throughout the discussion, the ISDM reservation system will be compared to a car rental reservation system.
ISDM is a software appliance solution that brings together, into an integrated platform, the capabilities of Tivoli Service Automation Manager (TivSAM), integrated with advanced monitoring of virtual environments from Tivoli® Monitoring and Tivoli Monitoring for Virtual Servers, and with enterprise metering and cost accounting capabilities provided by Tivoli Usage and Accounting Manager.
ISDM helps service providers as well as internal IT departments to deliver IT services in an efficient, standardized, and cost-effective way, achieving the benefits of a cloud delivery model. ISDM enables the data center to accelerate the creation of service platforms for a wide spectrum of workload types with a high degree of integration, flexibility and resource optimization with many core service management capabilities, such as, a self-service user interface.
Consider this analogy - when traveling on business, you might have the opportunity to place a reservation for a rental car. Your reservation would include a request for a resource (the rental car) to start on a specific date. Your reservation request identifies parameters such as what class (size) of rental car you want, options such as GPS navigation, and when you plan to return the rental car.
The ISDM reservation system is analogous to the rental car reservation system. Your service request identifies a resource (master image), how many virtual servers you need, what size of resource (CPU, memory, and disk), options (for example, additional software to install), the start date, and an end date.
ISDM provides a web-based, self-service, UI where users can request what they want, when they want it, and specify how long they need it for. In the graphic below, a project, LFG02a, containing 1 virtual server, is scheduled to start on April 1, 2013, ending on April 30, 2013. This service request is a reservation for resources for the month of April. The resources will be allocated, if they are available, when you click Finish.
Notice the message, There are sufficient resources, at the bottom of the screen. This message indicates that the service request can be fulfilled. All requests for resources, including ones for future projects, are run through a resource checking algorithm before the request can be submitted. If the resources are not available, you will not be able to submit the service request.
Much like the car rental analogy, if there are sufficient resources, the service request is scheduled and the resources for the project are reserved. When your travel date arrives, you go to the rental car counter and expect that your car reservation will be honored. The same applies to virtualized resources with ISDM – when the start date arrives, the resources are provisioned automatically.
Similarly, the dates for the reservation can be modified. Users can use the Modify Reservation offering from the self-service UI if, for example, the test dates change or the test is canceled.
Suppose that you are traveling with coworkers and they will share the same rental car. You might need to modify the reservation to upgrade to a minivan or request an additional car. Similarly, with ISDM, after you have requested a virtual server, you might need to modify the resources allocated to the virtual sever. For example, you might need to increase disk space to install a new software product. Requests to modify the virtual server are also run through the resource checking algorithm, to determine if you can obtain a larger resource.
A rental car company needs to ensure they have sufficient cars available to satisfy demand. Resource capacity is critical. You might ask, “How does ISDM determine the resource capacity?” ISDM determines resource capacity when the resource pool is initially configured by running a discovery workflow against the hypervisor.
The discovery workflow communicates with the hypervisor to discover:
- Hypervisor clusters
- Data stores
- Disk capacity
- Memory capacity
- CPU capacity
- Existing virtual machine templates
- Existing virtual machines
- And more
In the case of the rental car company, resources (cars) might need to be moved from one location to another to satisfy increased demand. In the case of ISDM, resources can be added to the hypervisor and discovered by running the discovery workflow again.
ISDM provides notifications when a resource is about to be de-provisioned. An e-mail is sent to the cloud administrator 48 hours before the end of the project reservation. The graphic below is for the LFG02a project about to be decommissioned:
In this case, the resource checking algorithm is run in the background. If resources are not available, you will not be able to select the new date.
Let’s look at a slightly more complex example. For this discussion, assume today is Feb. 22. Suppose you have three cloud administrators: Admin1, Admin2, and Admin3, and each has an active project (with resources allocated), as follows:
- Admin1 has PROJECTA with 1 virtual server active for Feb. 1 – 28
- Admin2 has PROJECTB with 1 virtual server active for Feb. 15 – Mar. 31
- Admin3 has PROJECTC with 1 virtual server active for Feb. 1 – June 30
Further, suppose there are two requests for future projects, as follows:
- Admin2 has PROJECTD with 1 virtual server reserved for Mar. 1 – June 15
- Admin3 has PROJECTE with 1 virtual server reserved for Mar. 1 – July 31
Admin1 has just learned that the resources for PROJECTA will be needed until Mar. 15. Admin1 uses the Modify Reservation offering, but, hypothetically, the request will not be allowed due to the resource reservations for the other two currently active projects (B and C) and the two future projects (D and E).
Admin1 needs to contact the other cloud administrators to verify their need for the resources. It might be possible for Admin2 to change the start date for PROJECTD to Mar16, for example. That would allow Admin1 to change the end date for PROJECTA to Mar 15.
Understanding the ISDM reservation system enables cloud providers to create virtualized environments more quickly, reducing errors, leading to improved customer satisfaction.
For more information about IBM Service Delivery Manager and Tivoli Service Automation Manager, visit http://www.ibm.com/software/tivoli/products/service-delivery-manager.
Paul Quigley is a Senior Technical Enablement Specialist with IBM Software Services for Tivoli with expertise in Tivoli Service Automation Manager, Tivoli Provisioning Manager and Smart Cloud Provisioning.