Achieving Service Level Agreement by Virtualization
You probably noticed that the focus will be at the enterprise level and not necessarily the parties involved individually. The goal is maximize the utility function of the enterprise, which may or may not mean the two parties are completely satisfied. The enterprise serves as yet another entity in this triangle. This entity is usually presented by a committee such as the Center of Excellence (COE) for a particular technology—in this case, virtualization technologies1.
The Service Provider is the IT entity that provides the services required by the Service Consumer. The Service Consumers are essentially end users with specific business requirements. In the financial market, users could be traders or risk analysts. In the biotechnology or the pharmaceutical markets, users are researchers and scientists. The Service Consumers provide both functional and non-functional requirements. Functional requirements will be implemented as the business logic by the Service Provider. The non-functional requirements are things such as the turn-around time, response time, and other quality measurements that will be satisfied by the COE. These non-functional requirements will, most likely, end up in an informal document at the beginning among all three parties. Remember that the COE manages the infrastructure, even though the infrastructure requirement is provided by the Service Providers (the group that writes the code).
You have gone full circle with this explanation, but how does this relate to achieving SLA at the enterprise level? Clearly, the COE is responsible for a number of these Service Provider-Service Consumer combinations. The COE is also responsible for providing the infrastructure, a topic that you will learn about later in this article. You can imagine how sharing can allow multiple duples to meet their SLA requirements without any of these groups ever needing to over-provision their infrastructure requirements. Because the COE is managing the infrastructure, provisions can be made at the enterprise level where the overall usage profile is available.
If you recall from the previous article in this series, I mentioned that one of the many goals of virtualization is to maximize utilization of resources. In the scenario just described, how can the COE provision its infrastructure with more resources as needed? Cycle stealing is a term that you have heard over the past decade in reference to Grid and distributed computing as a mean to increase computing power on the fly. The idea is to find out about unused resources across the enterprise and add them to your Grid to be used. When those resources are needed by their original owner, give the owners what you borrowed without any side-effects due to your usage.
Even though cycle stealing adds additional computing capacity to the Grid, a number of steps must be taken beforehand to ensure proper planning:
- Examine the resources and their OS build
- Determine the usage work profile of the target CPUs
- Broker a shared grid relationship between the grid application and resource provider
These preliminary steps are required because, in most cases, the homogeneity of the target resources will be the key factor in how the application scales. For example, a .NET-based application can only utilize resources that are Windows based and primed with a specific version of the .NET Framework.
When a heterogeneous set of resources is present, cycle stealing will only add to the overall available compute resource count if it shares the same OS version, processor architecture, and so forth. In the .NET example, neither a Linux-based resource nor a different version of the .NET Framework aids the application in adding to the overall available resource count. The same applies with C++-based applications. A homogeneous build environment is required in this case to borrow unused CPUs for a C++-based application. Multiple versions of the C++ complier (GNU GCC or Visual Studio) may need to be configured on a given resource for that resource to be part of the available resource.
Complementary workloads would enable proper scheduling of resources in such a way that utilization is maximized. For example, application groups can share between different regions during off hours. A New York-based user requiring resources during normal business hours can harness the computing resources sitting idle in London during their off hours of the night. As shown in Figure 2, resources from across the pond are migrated over as needed to meet the SLA requirement of users in NY. This is a radical case where you know for a fact that after 6PM GMT, a number of desktops in London are left unused.
Figure 2: The COE Controls how resources can be reused to achieve desired QoS
A finer grained scenario would allow you to be more dynamic in your resource provisioning. Let me make the following statement:
Rule 1: "The total maximum resource requirement of all users must be less than or equal to the total available resources at any given time to meet the SLA for all users at all times."
What does this mean? This is resource sharing amongst complementary workloads. Imagine that you have a total of three users with the following resource needs:
|Time Block 1||Time Block 2||Time Block 3|
|User A||50 CPU/HR||100 CPU/HR||400 CPU/HR|
|User B||200 CPU/HR||50 CPU/HR||100 CPU/HR|
|User C||100 CPU/HR||300 CPU/HR||50 CPU/HR|
Table 1: Depicting Usage Profile and Resource Requirement for three users
Clearly, you need to have at least 550 CPU/HR available at all times. What is interesting is that if there were no sharing available, you needed to have a total of 900 CPU/HR available to ensure that you meet each user's peak period, as shown in the highlighted cells.
Page 1 of 2