Sometimes, the things we learn early in life teach us the basic fundamentals we need in the future. Many of us probably had toys like this growing up or have them for our own kids.
Of course there are some out there who will say that they can get the square peg into the round hole if the beat the hell out of it. This is true, but you waste a lot of energy as well as probably damaging the peg and hole.
This simple concept of properly matching objects together fits with the final layer of the XenDesktop 7 blueprint.
So far, the blueprint has been mostly conceptual. The hardware layer takes the conceptual and turns it into physical. The hardware layer has us think about the storage fabric, server footprint and VM allocations.
But just like the block toy, we have the same situation occurring within the hardware layer. We need to properly match hardware technologies together.
Think about storage fabric and server footprint for a moment.
With storage fabric, I can choose either local, direct attached or centralized storage, while server footprint lets me opt for either rack mounted servers or blade servers. These two decisions, although separate, are tightly coupled, just like our block toy.
The type of storage fabric you select will have a dramatic impact on the server footprint, and the server footprint you select will also have an impact of the storage fabric.
Let’s say you want to go with blade servers for some reason. Although at first glance it would seem like I can go with either local or centralized storage, this is not truly the case. Due to the physical space limitations with blade servers, I will most likely only be able to support two disk spindles per blade. So although I could use local storage for desktop virtualization when using blade servers, I’m trying to force a square peg into a round hole.
What if we go with rack mounted servers (round peg) and centralized storage (square hole)?
Guess what? You can fit a round peg into a square hole, but you have unused space. It doesn’t fit perfectly. And that is exactly what we have with rack mounted servers with centralized storage. You can do it. It does work. But it typically isn’t the optimal solution, whereas local storage with rack mounted servers seems like a much better fit.
Depending on what you choose might impact the hardware you are capable of running. For example, if you chose local storage, you will have problems trying to run your environment with blade servers. Why? Because you only get 2 disk spindles. Not enough to handle the storage requirements for a virtual desktop solution (unless you add on storage optimization technologies.)
These two decisions helps us adding details to our architecture:
Of course the next part of the hardware layer is to start calculating how many physical servers you need and how much storage is required, which is a discussion for another time. But for now, we have the framework for our complete solution.