Single-system image (SSI) is a form of distributed computing, an abstract way of providing a single entry point to a large underlying infrastructure to your users. Many multi-processor systems strive to provide a singular view to the underlying physical processors, to make the multi-processor system look as if it was a single processor. Well, the question is, does it make sense?
The concept of a single-system image is nothing new, and it goes back to the beginning days of computing. Abstraction methods were/are used to give the user the perception of a unified system. The question, however, stands that if we actually need a “single-system”?
This is a loaded question with no right answer. Did you notice that I said no right answer, as opposed to saying that there is no wrong answer? There are technological and there are political cases for and against achieving such lofty goal across the enterprise.
The concept behind SSI is that your environment is made to look as if it is one single node being accessed by the outside. This sounds great in theory, but in practice this opens up the discussion of sharing as when a number of users are on the same virtual environment, there will be resource contention and there could be scarcity in available resources.
Let’s take another approach to the problem, through the perspective of an operating system managing a multi-CPU machine. A number of CPU-intensive applications may be contending to gain access to the underlying resources. It is the OS’s job to schedule and ensure proper access by all who need access, and the user is not aware of the fact that there are multiple physical CPU’s and memory channels, etc. The OS provides a single-system image to the user. This is a small case of SSI; let’s apply this concept to the enterprise.
SSI for the Enterprise
Applying this concept to the enterprise is a little more challenging as the number of nodes to worry about is greatly larger. There are other variables that we have to worry about as well:
- Locations of the resources in question
- Connectivity among the locations
- Heterogeneity of the system (hardware, software)
These are the same issues and concerns that one needs to deal with when talking about an enterprise Grid. This is due to the fact that to have an enterprise-wide Grid, one must have a single-system image of the underlying resources in mind. An enterprise Grid and a single-system image go hand-in-hand, and to solve one is to solve the other.
Managing resources is a balancing act between what is available and what is requested. A single-system image allows a resource manager to manage resources across the enterprise as the full picture of the underlying infrastructure would now be available. Resource management is a three step process:
1. Place request in accordance to a complimentary combination of resource usage
2. Remember that you cannot squeeze 101 percent utilization from a resource, no matter how much you try
3. If your resources are being used by only a handful of jobs while other jobs are starving, revisit step 1
This is not as easy as it looks. Finding job profiles that are complimentary is not an easy task as many jobs have unpredictable usage requirements and are only known at runtime. Figure 1 better illustrates this problem. If users can be happy with what is given to them, then there is no problem. If more than one user tries to access a shared pool of resources, then management of those resources is key.
Figure 1: Resource Contention
Finding a real-time solution to this problem is not easy (in fact, scheduling problems are considered unsolvable – more on this later). The point is that step 2, which is management part of resource management, requires the full view of the system along with availability, capability, etc.
Figure 2: A Single-entry approach of a Resource Manager