Contoso Labs-Fabric Choices (Storage)
Contoso Labs Series - Table of Contents
The first step on the way to defining our architecture is designing our fabric. That involves taking the goals, users, services, and resources we talked about in previously, and then figuring out the optimal deployment configuration.
Storage Choices Came First
It quickly became apparent in our discussions that storage was going to be the issue that drove most of our choices. There are many options available out there, with varying levels of complexity, performance, availability, and costs. We had to decide which configurations made the most sense, plus the kind of sacrifices to make and risks to take.
To begin with, we needed to identify the characteristics of our workload. Based on experience and our user base, we knew the general profile of what our storage needed to look like. We're not hosting production workload VMs that need to support hundreds or thousands of users. These VMs are used for learning and demonstration purposes, not hosting data. That made our lives simpler by boiling our storage requirements down to: 1) Support some serious IOPS. 2) Reasonably light overall capacity.
This immediately ruled out SANs. The types of SANs that support high-IOPS workloads tend not to be the cheap entry level kind, but the big ones that come with a commensurate price tag. That meant we were going shopping for Windows Storage Spaces capable JBOD's, and using the advanced storage features we shipped in Windows Server 2012 R2, like data tiering. That let us concentrate our limited budget on the high cost items which gave us the biggest return on our dollars: SSDs.
Scale-Out File Server to the Rescue
That decision meant we'd be using Server 2012 R2 storage services to provide access to the nodes. While iSCSI is a possibility, we strongly believe that the Scale-Out File Server is the future of storage services in a Microsoft cloud, and designed around that. The continuous availability features of SOFS and SMB 3.0 make for a powerful storage solution that addressed our needs perfectly.
This choice gave us the added benefit of being able to use a converged fabric design, where one set of cables (Ethernet) provides all of the storage, management, and tenant traffic, load balanced and on the same wires. A cost-saving benefit of a converged design was avoiding the purchase 288 FibreChannel HBAs, a cost which would have stopped our deployment in its tracks.
It's worth noting right up front that most of the time, you're going to want a complete solution from a vendor you trust, rather than building the one we'll lay out in upcoming posts. If a complete single-vendor solution that met all of our needs was available at the time we had to commit to purchasing, we might have gone for it. As it stands, we built our own and will pass our experience along to you!
The next post will discuss how these storage decisions affected our network design, and some of the tradeoffs we made there.