In the first blog post focused on the supply layer, I discussed how resources are provisioned and configured to deliver the services and service elements defined in the delivery layer. Let’s now look at what happens when a user wants to access a service he already provisioned. And then let’s focus on usage metering and resource health management. And I’ll finalize describing how resource templates are created.
Accessing a service instance
I can access a running service, in which case all I need to do is rebuilding the link between the virtual machine(s) in the running environment and the user. The delivery layer identifies the service ID and the associated resource IDs and requests Resource LifeCycle Management to set-up the secure connection using the information available in the Resource Catalog & Repository.
The service may have been suspended. In this case it is no longer available in the running environment, but the saved virtual machine(s) are available. Service Instance Lifecycle Management will trigger the VM restore and rebuild the connections/isolations between them. To perform these tasks, Resource LifeCycle Management is triggered and uses
Resource Configuration and Element Adapter & Control to perform the tasks. The information is updated in the Resource Catalog & Repository to match the new situation.
If the user requests to de-provision the service, Service Instance LifeCycle Management requests the de-provisioning of all resources associated with the service ID. Here again the work is performed by the supply layer under the responsibility of Resource LifeCycle Management.
Upgrading a service
You may want to release a new version of a service, a configuration may need to be changed, a security parameter adapted. Each of these changes is focused on the service, but has implications for the resources that are involved in the delivery of the service. These changes are initiated by the service modeling & design function through the update of existing workflows in the service instance lifecycle management.
One question the person responsible of the design needs to ask himself is whether already provisioned service instances need to be updated. If that is the case a separate workflow needs to be created to perform the change on all provisioned service instances. Service Instance LifeCycle Management will scan the service model repository for all active and suspended service instances and for each will request the supply layer to perform the change. The actual change will be performed by the resource configuration under the responsibility of resource lifecycle management.
Upgrading a resource
But this is not all. A resource may have to be upgraded. For example, an operating system may need patching, or server firmware upgraded. These changes are not associated with a service, but with a resource and affect all services using the resource.
Now, both examples given above require you to take different approaches:
- Upgrading firmware is closely related to the actual infrastructure and is managed by the element controller. It may be triggered at resource lifecycle management level, but the actual work is done within the resource pool by the element controller. A similar procedure is applicable for all hardware and software involved in running and managing the cloud platform.
- Patching an operating system covers on the one hand patching OS’s installed on physical machines and OS’s embedded into virtual machines (both VM images and VM instances). The physical machines are under the responsible of the appropriate element controller. The VM images are handled by the hypervisor element controller. But that leaves us with the running and suspended instances. For these, we need to find out where they are and in what state. Here the resource catalog & repository is used as a reference. The actual patching is done by the appropriate element controller under the supervision of Resource LifeCycle Management.
As upgrading a resource may have impact on all supported services it supports; this operation should be done by implementing a robust change & configuration management ITIL processes.
Depending on the billing or chargeback method chosen, the actual consumption of resources may need to be measured. Here we depend on the measurement methods available. If the actual CPU and disk space usage can be monitored, we may be able to provide, at least for the resource consumption, real pay-per-use.
Now, the measurement of other resources such as software license keys or IP addresses, do not lend themselves to similar metering. Indeed, from the moment a license key is used, regardless of whether the actual service is available or suspended, the key cannot be used elsewhere. So, the provisioning and de-provisioning of the resources are the key elements to trap.
The actual health of a resource is monitored by the element health management function associated with the resource pool. That information is transferred to the resource health function that looks at all resources associated with a service and transfer the information to the service health management in the delivery layer.
Things become interesting if one of the resources fails. For example a physical server in one of the resource pools fails, halting a number of virtual machines. The element health will spot that and trigger the element controller to move the virtual machines to other resources within the same pool. If no other resources are available, resource health is notified. Resource health will call upon resource lifecycle management to migrate the VMs to another resource pool within the same supply layer. If no resources available in the supply layer, service instance lifecycle management is notified to initiate the migration to another supply layer.
Bursting to external resources
We know the term bursting today fundamentally means the possibility to provision infrastructure provided by an external service provider. We included in the architecture an external service provider management function that interacts to provision and use the external service. Let’s assume we provision a service (using the delivery layer), but not enough resources are available in our own resource pools to deliver the service. One of two things can happen. If the service can be performed on an external environment, then the supply layer may provision the service there. This decision is part of the policy management function within service instance lifecycle management in the delivery layer, We could argue the service broker can directly interact with an external service provider, so the supply layer does not need to be involved.
But what happens if the service needs to be delivered by the cloud platform itself. Other services will have to be migrated. So, the supply layer will have to identify which VMs can be pushed to an external service provider, stop them, provision appropriate resources with the external service provider and rebuild each VM there so it can continue running.
That is where the external service provider management function has its role.
Resource Template Design
Last but not least, the resource template design. We said that a resource, as known in the resource catalog may actually consist of several elements. A small server may consist in a single core virtual machine with a given amount of memory, Network connectivity, and hard disk space. The resource template allows the graphical design of such resources. So, these resources are identified and given a name. That name is then made available to the service modeling & design function. The service designer will now pick and choose the resource templates to use for the provisioning of the service.
Now we have described all the functions in the HP cloud functional reference architecture. As you can see we have done a thorough design work and gone in great details reviewing how a cloud platform works with other cloud environments in a hybrid model. I hope you enjoyed this series. Don’t hesitate to give me your feedback.