Resource Utilization and Provisioning Within Virtualization
A Note Before You Begin
You covered some of the basics of virtualization and grid computing in my past two articles, Service Virtualization: The Road to Simplification and Achieving Service Level Agreement by Virtualization. I feel that this article is more like a bridge between what you have covered and what will be covered in the future articles. I tried to tie up some loose ends from what you have covered thus far, but I have left a number of questions unanswered. As you move forward, these questions will be answered one by one as you delve deeper into this topic.
How do you go about provisioning your unused resources? Is it a safe assumption that your resources will be idle after 5PM? How about 6PM? Do you use a feedback model, or do you simply use a heuristically modeled policy and modify it as needed? The fact of the matter is that there is no one concrete answer when it comes to resource provisioning. In my previous article, I gave you a rule of thumb, but not only I did not explain where that rule of thumb came from, I did not even tell you how you should go about finding that low water mark. I will delve into some of the details of resource provisioning and utilization in this article and try to close some loose ends I left in the previous article.
Before I go any further, I need to cover some basic ground. There are two primary classes of scheduling:
- Adaptive or dynamic
Static scheduling has been around for years and years. Its concept goes back to the mainframe days when you needed to "call ahead" and reserve resources. You knew how many CPUs you had beforehand and scheduled access accordingly. Resources were reserved for a given application based on a user's priority and type of application. On a good day, the number of CPUs did not change; in other words, no systems crashed, and no system was overloaded. The systems were composed of large, expensive SMPs (Symmetric Multi-Processor), and intra-communication between these large systems was a hassle. Most of the scheduling was done at the Operating System level, with the scheduler simply taking care of the macro-schedule across many systems.
Adaptive scheduling is what many, if not all, commercial vendors support today. The basic idea is that the scheduler can handle a dynamic set of resources. Servers or desktops could be added and removed from the overall infrastructure, and the scheduler could handle this change in real time. Little or no administration is required to provision systems, and off-the-shelf cheap blades are making up the Grid with very high-speed communication links connecting the resources and the users. The resources are located sometimes even globally, and the scheduler opts with policies to make decisions for a given user. Scheduling is more difficult in this case because the number of clients or requests could spike at any moment, and the scheduler must be such that it does not fall apart when these boundary conditions arise. I will spend more time on the scheduler in future articles, but I just wanted to give you a background before you move to the next section.
Types of Resources
There are two types of resources that I want to emphasize for this article:
- Dedicated resources
- Dynamic resources
As its name suggests, a dedicated resource is one that is part of your Grid all the time. You are the sole sponsor and owner of that resource. You dictate its location, its configuration, OS type, amount of memory, vendor, and so forth. I will not get into the details of the Center of Excellence (COE) concept that was previously discussed. Even with a COE involved, the ownership is transferred to the COE in the same manner. The rest are the same. The good thing about a dedicated resource is that, well, it's dedicated! Little or no planning is required from your perspective to realize your overall compute capabilities. Your dedicated resources represent the minimum resource you have available at your disposal. This is solely due to the fact that, within the enterprise, there are used resources that you could take advantage of when you are allowed to do so.
If you recall the SETI@Home project back in the early 90s, you know what I am referring to when I talk about dynamic resources. One could think of dynamic resources as resources that do not belong to you, but you are granted access to use when the resources are not used for anything more important. I won't discuss the details of "importance" because everyone's perspective is different regarding this matter. Desktops that are reprovisioned after hours can be thought of as dynamic resources. Now, the quest is not to set aside a block of hours for a given resource to be used for something else, but have a finer and more granular method by which idleness is measured. As you delve more into the overall enterprise grid model, you will realize why and how this fine granular reporting paves the way for a scalable architecture.