Weblog of Mark Vaughn, and IT professional and vExpert specializing in Enterprise Architecture, virtualization, web architecture and general technology evangelism
There is a lot of talk about the software-defined data center lately, though the shift from hardware to software has been going on since the first logical partitions appeared in mainframe computing. Surprisingly, this shift continues to sneak up on people. When that happens, there can be power struggles and confusion as to who’s responsible for what. Many technology disciplines — networking teams, for example — still see themselves as focused on managing hardware rather than software and fail to see that virtualization has moved us beyond these distinctions.
What a networking device does, it’s core functionality, has been abstracted and is taking a new form…but will network administrators embrace this change? I go into more detail on this topic in my latest TechTarget article “Virtualization widens schism between server and networking teams“. Please take a minute to read that, then come back here and tell me what you think.
Over the last few years, Cisco has made significant in-roads into the server market with their Unified Computing Environment (UCS) servers. One key differentiator with the UCS platform, and a frequent marketing point, was in their ability to use memory expansion technology to achieve higher memory densities than Intel architectures natively allow. Not only could you reach higher memory densities, but you can do it without the reduction in memory speed that other architectures incur when stretching into higher memory configurations.
With all of the focus on UCS providing server resources with large memory footprints, and VMware’s recent licensing adjustments to limit the amount of used RAM per license, does this impact the value of UCS? Not at all.
Cisco UCS has a number of game-changing features. To be honest, memory expansion is further down on my list of UCS’s top features. To me, the CapEx savings in networking and storage switch infrastructure is huge. That aspect, by itself, can yield significant financial savings. At the same time, reducing infrastructure has OpEx savings that stretch out far into the future. An when you speak OpEx, you cannot pass over the management aspects of UCS. Through the UCS Manager, you manage all aspects of your environment from one interface. Furthermore, with profiles, you abstract a server’s identity from it’s physical hardware and enable a level of flexibility within the physical infrastructure that was previously only available with virtualization. To me, these are the pillars of the UCS value proposition, and their value is independent of the memory configuration or any underlying licensing.
In fact, I would argue that the value of UCS is even stronger in VMware’s new licensing model. If you are designing an ESX host with 192GB of RAM, it will require two Enterprise Plus licenses, regardless of the hardware vendor. With your licensing being what it is, and possibly (though not likely) more expensive than it was before, why not select a hardware platform that will carry a lower CapEx and OpEx burden? The new licensing model may encourage some users to cap their memory sizes at 192GB and scale horizontally from there. That potentially leads to more servers. Outside of UCS, that would likely equate to a significant increase in port count on your networking and SAN infrastructure.
Regardless of server platform, high memory densities and VM density are just now reaching critical mass and driving people to consider higher memory configurations. Likely, if you are building a 2 CPU server with 256GB RAM or higher, you are using it to replace two servers that were 2 CPU and 96GB RAM or lower. You were 4 licenses before (driven by CPU count), and you will be 3-4 licenses after (driven by memory utilization). In fact, if using less than 288GB RAM in this scenario, you would go from 4 licenses to 3 and still have a net savings in licenses. Remember, every Enterprise Plus license adds 96GB vRAM entitlements to your overall pool. So three licenses would entitle you to allocate up to 3 CPU (unlimited cores) and up to 288GB vRAM. This is also a pool consisting of all licenses in your environment and used by all servers in your environment, so memory does not have to be consumed by the same ESX host that the CPU from that license is allocated to. (For more information on vRAM pooling and VMware vSphere 5 licensing, see the links at the end of this post.)
There has been a lot of discussion around VMware’s new licensing, and some great resources out there to address that in more detail (see links below). But rest assured, this new model does not impact the value of UCS. Independent of software licensing models, it always makes sense to reduce management overhead, increase flexibility and improve availability, while reducing costly networking and SAN infrastructure. The value propositions of UCS are above the level of licensing discussions. And if you are going to build vSphere hosts that span into the higher memory densities, then do it on a platform that does not force you to sacrifice memory speed for memory density.
Disclosure: I work for a leading Cisco partner. In fact, I chose my current employer largely based on their relationship with Cisco and their success built around virtualization and UCS.
This is a phrase I am hear more and more of lately, and I love the concept behind it. Virtualization has consolidated servers, and blade servers have consolidated the footprints of those virtualization hosts. Now, blade solutions are beginning to employ even greater efficiencies with creative and flexible wiring strategies. As FCoE and converged networking matures, blade technologies are deploying these to collapse cables and leverage a single cable to provide multiple services (network and both block level and file level storage solutions).
Physical servers are also leveraging this, though blade solutions will often be more efficient in this arena. I also think that Cisco’s UCS has really taken this and run with it, others are catching on and making progress in this arena (i.e. HP’s Blade Matrix technologies). Regardless of your blade solution, this is a concept that you need to get familiar with and evaluate in relation to your future technology goals. In reducing infrastructure, you lower costs, ease administration and provide greater agility. Who doesn’t want that?
