I don’t know about you, but the thought of using a “server” as a “backup storage” resource may sound a bit odd at first. After this post, you may change your tune. Let’s dig into this a bit.
I’m sure you’ve heard of the Cisco UCS Unified Computing line of servers and their associated Fabric Interconnect technologies. Additionally, you may know that there are M-Series, B-Series and C-Series form factors for the various configuration options that are in high demand for the modern data center. Which reminds me, you should check out this PDF poster of all of the current UCS components; it is my go-to resource to see how the different UCS offerings can be arranged and interconnected.
So let’s zoom in on the Cisco UCS C3160. It has a few key specifications that caught the interest of a number of keen architects in my extended professional networks which led to this notion of putting the C3160 in place as high performance and high capacity backup storage system. The most interesting specification is that the C3160 can hold up to 60 small form factor drives. Two additional small form factor SSD drives are in place for the boot volume. What this means is that these 60 drives can be used as a backup storage repository. RAID levels are available on this configuration as well, in particular the Cisco 12G SAS Modular RAID controller supports RAID levels 0, 1, 5 and 6. I’d recommend RAID level 6 for this large of a storage resource in terms of drive capacity (up to 4 TB) and the sheer number of drives coupled with rebuild times and have some spares in place. That being said, there is easily over 200 TB available for backup storage in one C3160 server. Let’s take the following figure:
I’ve simplified the diagram, but imagine VMware vSphere and/or Microsoft Hyper-V workloads in a data center running on Cisco UCS Servers (any form factor). With the Fabric Interconnect, that large amount of storage that is provided on the C3160 becomes an outstanding candidate for backup storage. There are a few reasons this arrangement works, regardless of what backup technologies are used.
First of all the backup storage is in close proximity to the source data. Additionally, there is ultra-low latency to get from the C3160 to the source data. This is especially true when UCS and the Fabric Interconnects extend to the primary storage systems of the VMware vSphere and/or Microsoft Hyper-V VMs themselves. Additionally, the C3160 isn’t a chump when it comes to actually holding the backups. There can be up to 512 GB of RAM and an operating system installed to leverage compute and memory resources in addition to all of the storage capacity in use. These resources help with any synthesizing or transformation of backups. This storage practice is really important when it comes to larger backup sizes and it requires less time to do full backups on the running VMs. This keeps the VMs running at their highest performance levels (what we really care about right?!).
I’ve been talking for a long while of this notion of the “Ultimate Backup Storage Architecture” (including a recent blog post) and what I’ve learned over the years is that this is a mindset or way of thinking rather than a part number or reference architecture. Additionally, it’s impossible to make one design work for all situations. What I am doing is lining up configurations and robust systems that can be used to deliver the Ultimate Backup Storage Architecture for the right situations. The C3160 is a perfect server to keep in the arsenal.
Have you noticed that the UCS C3160 is different in terms of its storage capacity? It’s a great way to connect a large amount of storage with compute and memory resources as well. How could you use it for your backup design and do you keep backups in mind when you design with Cisco UCS? Share your experiences below.
One clarification, the C3160 doesn’t have the same fabric interconnects as other UCS products as it doesn’t currently connect to UCSM. The C3160 is currently managed through CIMC. Stay tuned in regards to having the C3160 managed with UCSM.
If it’s too much data for one machine, you could also setup a Hadoop cluster and rely on the distributed nature of HDFS to store large amounts of data. I’ve found the UCS C-series to be really good for that.