Earlier this week I posted some notes from a TechEd North America 2012 session that discussed the Cluster-In-A-Box solution. Basically, this product is a single box unit, probably with two server blades, all the cluster networking, and JBOD storage attached by SAS Expanders, all in a single chassis. For a small implementation, you can install Hyper-V on the blades in the box, and use the shared JBOD storage to create a small, economic cluster.
I’ve been thinking about the process for expanding our scaling beyond this box. At the moment, without playing with it because it doesn’t exist in the wild yet, I can envision three scenarios.
On the left I have put together a cluster-in-a-box. It has 2 server blades and a bunch of disk. Eventually the company grows. If the blades can handle it, I can add more CPU and RAM. It is likely that the box solution will also allow me to add one or more disk trays. This would allow me to scale up the installation.
I’ve reset back to the original installation, and the company wants to grow once again. However, circumstances have changed. Maybe one of the following is true:
- I’ve reached my CPU or RAM limit in the blades
- My box won’t support disk trays
- I’m concerned with putting two many eggs in one basket, and want to have more hosts
In that case, I can scale out by buying another cluster-in-a-box, with the obvious price of having another cluster and storage subsystem to manage.
Scale Up & Out
I’ve reset once again. Now the company wants to grow. Step #1 because my box allows it, is to scale up. I add more disk and CPU and grow the VM density of my 2 node cluster. But eventually I start approaching a certain trigger point where I need to buy once again. What I can do now is add a second cluster in a box, probably starting with a basic kit, and grow it with more disk and CPU as the company grows.
Migrate To Traditional Cluster & Scale-Out-File-Server (SOFS)
Let’s consider another scenario. The company starts with a cluster in a box and scales it up. We’re approaching the point where we need to scale out. We have a choice:
- Scale out with another cluster in a box?
- Migrate to a traditional cluster with dedicated storage?
My big concern might be flexibility and simplicity as I scale the size of the infrastructure. Having lots of clusters is with isolated storage might be good … but I think that’s a minority of situations. Maybe we should migrate to something more traditional … but not iSCSI because we already own a cool storage platform!
In this case, I’m going to leverage a few things we can do in Windows Server 2012:
- Shared Nothing Live Migration will allow me to move my virtual machines from the cluster in a box to a Hyper-V cluster made up of traditional rack/blade servers.
- SMB 3.0 (with Multichannel and Direct) gives me great storage performance so I can re-use the cluster in a box as a storage platform.
- I can convert the cluster in a box into a Scale-Out File Server (SOFS).
Obviously I have not tested this but here’s how I think it could go:
- Enable SOFS on the cluster in a box with a single initial share on each CSV
- Prepare the Hyper-V hosts and cluster them without storage
- Grant admins and the Hyper-V hosts full permission to the SOFS shares
- Use Shared Nothing Live Migration to move the VMs to the new Hyper-V cluster, placing VMs in the same CSV as before via the share … this will require some free disk space.
With this solution you can grow the environment. The cluster in a box becomes a dedicated storage platform, and you can add disk to it. Your single Hyper-V cluster can scale well beyond the 2 node limit of the cluster in a box. And you can do that without any service downtime … well, that’s what I think at the moment We’ll find out more in the future, I guess.
This blog post is the property of Aidan Finn (@joe_elway / http://www.aidanfinn.com) and may not be reused in any manner without prior consent of Aidan Finn. You may quote one paragraph from this blog post if you link to the original blog post.