Calling It: NUMA Will Be The Shizzle In Two Years

No matter how much hardware and software we throw at data center computing, there is the hard fact that we are limited to using only the resources on a single piece of server hardware. Oh, we can virtualize the PCI bus and share peripherals among multiple servers with virtual IO, and that has use cases. Non-Uniform Memory Architecture (NUMA) is used in high-performance computing to aggregate fundamental computer resources like CPU, RAM and IO across a high speed bus. NUMA has the capability of virtualizing the hardware itself and it's going to be the hot thing within two years.

I first learned about NUMA in a reader comment to a product review that Joe Hernick performed on Liquid Computing's LiquidIQ. Liquid Computing has apparently closed its doors.  NUMA systems interconnect resources using intelligence to allocate resources like CPU and memory close together within the same local board, only reaching out over the bus- -a crossbar- -when needed. The process is similar to how your OS uses virtual memory by keeping frequently-used blocks on high-speed RAM and less frequently-used blocks on disk. Of course, accessing RAM via a crossbar is orders of magnitude faster than accessing a memory page on disk vs RAM, but the idea is similar. NUMA is used in cases where data processing is occurring over GBs or TBs of data and going to disk, when even a high-speed SAN is far too slow.

While NUMA is used primarily in research applications, it's going to squeeze out into general IT. Why? Because as Jayshree (who needs no last name) said  a few days ago during an interview, today's virtualized data center is looking a lot more like a high-performance computing data center with high-volume, high-capacity, high-IO computing systems than racks of discrete servers doing discrete things. Soon, IT will start bumping into CPU and RAM limitations that adding new discrete servers won't be able to solve well. Jake McTique has written about increasing performance in VMware's vSphere .

If you think NUMA is crazy talk, consider what happens if you can't fit your CPU, RAM and IO requirements within a single server? Even a modest requirement like an eight-core processor means you need a server that has eight cores. How many of those do you have laying around? On a NUMA-based system, that constraint is removed. Need eight cores? Take them from the available pool. Need 128 GB of RAM but your servers have 64GB each? Pool the RAM and you're good to go. You stop thinking of discrete servers and start thinking of processing requirements. I need eight cores, 192 GB RAM and12 GB of IO.

I know I am glossing over lots and lots of details -- details that are not trivial -- and frankly, I don't even claim to fully understand them. I'm not even sure I know the right questions to ask. For example, what are the OS requirements for NUMA? How does the system schedule and allocate resources? How does a NUMA system change application development? Or does it? Remember it took a long time for applications to take advantage of multi-threading and multi-core architectures. Will a NUMA optimized application require a special software architecture or will the NUMA system just magically handle the details?  It is fault tolerant? If so, what is the fault tolerance? And so on.But let's look at the potential and what it means for server-provisioning and dynamic resource allocation. Wouldn't it be great to scale up existing servers dynamically on demand such as adding CPU's, RAM, and IO without having to take the server down? What would that do to your ability to respond to peaks and valleys? Gone are the days when you add processing power by provisioning a bigger server or adding a new server to an existing pool. If your company interacts with customers and you have a sale or promotion, you know you will have a temporary need for more processing to handle the load. Sure, you could use a cloud service, but that has its own issues. If you want to do an analysis over a large data set, do  you want to wait until you are old and gray, or would you rather grab more RAM or IO? Wouldn't it be useful to prioritize computing power to your most pressing business need? I'm not suggesting that hardware allocations are going to be changing minute by minute- -they don't today- -but your processing needs to change sometimes predictably and sometimes not.

What about the impact on availability? Anyone who has recovered from a server failure in minutes compared to hours by spinning up a VM understands the power of hypervisor virtualization. But take that one step further to hardware virtualization. If you can add and remove hardware dynamically on running systems, it's not a reach to imagine being able to distribute an entire server- -OS, application, data, the whole shebang- - or even a hypervisor, over many server blades. Lose one blade, and you just lose some of the processing resources, but the server keeps running. Recovery is as quick as adding more hardware. Do that and you might be chuckling at peers who are proud of their 99.999 percent reliability (5 minutes of downtime per year) and you can boast 100 percent. You know downtime is never just five minutes and it never happens when no one is looking.

I think it will take a few years to get these questions answered. I expect that hypervisor vendors like VMware, Microsoft, Citrix and the Linux KVM developers will be working on this. I know there is work within the Linux community on NUMA, but I don't know the extent. Hardware vendors have NUMA systems running. HP's recently announced Superdome 2  is the latest case. Considering that the new Integrity blades can run in a Superdome 2 chassis and HP c-class chassis, I'd imagine HP will explore, if they haven't already, the efficacy of putting NUMA into the c-class systems. I don't have any inside knowledge about HP's plans, but it's what I'd do. Regardless, Superdome is already in the market as is 3Leaf, IBM and others.

I think it's got legs and I think we are just starting to see it emerge from research and HPC silos. Besides, it's fun to say. NUMA. Go ahead, try it.