IBM SmartCloud Provisioning 1.2 – User scenarios
Introduction...2
Scenario 1: Critical security vulnerability patch to be applied to user images within a specified time interval...2
Simplified Patch Compliance Practice...2
Alternate Flows...2
Using Windows off-line patching tools...2
Instances that Cannot Be Simply Replaced...3
Offline Persistent instances...3
Short Lived Instances...3
Scenario 2: Capacity planning and resource consolidation...4
Analyze data for capacity planning...4
Consolidate resources...4
Scenario 3: Restrict who can do what...5
Roles management...5
Introduction
This document provides some recommended procedures to simplify many common operational practices by using IBM SmartCloud Provisioning 1.2. Future releases of the product will provide additional automation to further simplify the operational procedures.
Scenario 1: Critical security vulnerability patch to be applied to
user images within a specified time interval.
This scenario requires patching all the relevant resources (images and instances) available in the cloud environment. The following procedure describes the recommended steps to apply the required patch.
Simplified Patch Compliance Practice
1. Using the Image Library, perform a search on all the images matching the vulnerability criteria and generate a list for subsequent steps.
2. For each image identified with the vulnerability in step #1
a. Using the Image Library check if the image is not currently in-use by any running instances
I. Using historical data from the SmartCloud Provisioning reports check for recent usage of the image
II. If it's been a long time since the image has been used, consider retiring the image rather than continuing the procedure.
b. Check the image out into an operational repository, e.g. VDE service region
c. Create a virtual machine instance of the image d. Apply the patch to the virtual machine (instance). e. Capture the virtual machine as a new image f. Check in the patched image as a new version
3. Using the Image Library, identify the running instances created from the matching images in step #1. Generate a list for subsequent steps.
4. For each running virtual machine identified in step #3. a. Quiesce the application and file system(s).
b. Create a new instance from the latest version of the image from step #2. c. Detach persistent volumes from the un-patched instance
d. Attach persistent volumes to the new instance created in step 4b. e. Terminate the original instance.
5. Using the Image Library, identify the operational repositories storing the matching images in step #1. Generate a list for subsequent steps.
6. Check-out the patched image from the image library to the operational repositories identified in step #5
7. Delete old versions of the image(s) from each operational repository identified in step #5
Alternate Flows
Using Windows off-line patching tools
Many Windows patches can be applied off-line using Microsoft DISM instead of creating an instance, patching the instance, and capturing as an image.
• Check the image out of the Image Library
• Copy the image onto a storage node so it appears as a volume
• Attach the volume to a Windows service VM with the Microsoft DISM tools installed.
• Use DISM to apply the patch to the volume
• Disconnect the volume
• Register the volume as an image
• Check the new image into the Image Library as a new version
Note: This procedure can be automated using scripts and command line tools
The strategic direction for this off-line patching use case is to leverage the Image Library. This would avoid the need of moving images out of the library and then back into it.
Instances that Cannot Be Simply Replaced
Sometimes instances weren't designed for this kind of modern management. Persistent Instances commonly fall into this category. In these cases, we recommend using traditional patch management tools like IBM TEM for live patching.
Offline Persistent instances
Follow the same procedures for patching images either using off-line tools like Microsoft DISM or by launching the instance for live patching.
Short Lived Instances
Very short-lived instances are expected to be terminated before the patch dead-line expires. In this case no action is required
Scenario 2: Capacity planning and resource consolidation
This scenario requires monitoring the resource utilization to identify• images and/or instances no longer used
• images not properly used
• similar images and/or persistent instances
Ideally this scenario (for both the cases analyzed below) should be exposed by the Image Library, which is supposed to be the central repository of all the image related
information.
For the current release not all the steps can be covered using only the Image Library. Analyze data for capacity planning
In order to identify not used/mis-used resources, apply the same approach described above for the vulnerability assessment phase of scenario 1:
1. Using the Image Library UI, identify which instances have been created for each available image
2. For each identified image and instance, check their utilization leveraging historical data
a. Specific scripts can be provided for SmartCloud Provisioning operational repositories
b. Custom scripts can be created for VMware operational repositories c. Utilization for images must be matched with the utilization of the related
instances
3. Moreover, check if several versions of the same image are available and older versions are still present on the operational repositories.
This is an indicator of the fact that old versions of an image are still in use, while they should no longer be used in favor of the newest versions
Consolidate resources
In order to consolidate the resources being used in the cloud, leverage the Image Library analytics capabilities to find similarities across images and persistent instances:
1. For each available image and persistent instance, find the similar ones 2. For the similar images perform a more detailed analysis leveraging the
comparison capabilities provided by the Image Library
Scenario 3: Restrict who can do what
This scenario covers the capabilities of the cloud Administrator to control which actions can be performed by which users.
In this way the administrator can manage the cloud resources in a more efficient way, avoiding the proliferation of images and the misuse of storage and computing resources The SmartCloud Provisioning product provides two ways of implementing such control:
• Leveraging the roles
• Leveraging the quotas associated to each cloud user Roles management
The SmartCloud Provisioning product today provides two out-of-the-box roles, an administrative role and a standard user role, both having privileges to
• create instances
• capture instances into new images
• create volumes
The cloud Administrator could create additional roles to hide some capabilities, like for example the capability of capturing a VM into a new image, thus reducing the risk of creating too many images and consuming storage.
This is not currently exposed by the standard interfaces of the product, and requires some manual activities on the code side.
Quotas management
The SmartCloud Provisioning product provides the capability to assign a quota to a group of users, thus controlling how many resources each group member can consume.
The cloud Administrator can enable such capability and partition the cloud users to have a better control on the resource utilization
