The MOST important infrastructure design consideration - The Applications!

I’ve spent a fair amount of time over the last two years preparing for my VCDX, while the VCAP-DCA/VCIX-DCA is the last step before I fully dive in, I’ve been preparing myself not just for an exam/test but to be the best possible architect I can be. To that end, preparation is an on-going, ever evolving process.

During this time, I have seen many blog posts about doing designs, talking about application requirements in terms of CPU, memory, disk (space, I/O, throughput), network, and security. I have seen some posts (even by current VCDX’s) from vendors talking about how their solutions solve problems, even if they might not be the best solution. I’ve long said that most organizations have the need for different products to support their infrastructure, and that no one solution is a fit for all workloads. Now, as this has got me in trouble in the past, nothing is 100% valid, just like no product is a 100% fit for all workloads. There very well could be environments that run, fully supported, on one “stack” of vendor hardware.

For example maybe a solution for application A is preferred, but for application B it might be ranked lower. Some peoples take, is it worth deploying different solutions for different applications and adding in complexity to your environment? That answer, as I think any good architect would say, “It depends” - and not just on raw performance statistics like IOPS, or CPU utilization. Let’s take a look.

If were starting a design today, I would gather requirements from the business (including things like local, state, regional, or industry regulations), application owners, application performance requirements, team/training considerations, space, cooling, availability - its a long list. I would then compile an initial list of those requirements, known risks, and constraints before I even begin considering hardware. If you are engaging a vendor or VAR to help you in this process, and they are leading with a hardware solution and fitting your business onto that - it could be a red flag that you and  your organizations best interest are not front and center, but rather just making a sale of a product.

Now that I have all that information gathered, I need to once again step back and dive further into the applications the organization relies upon. Let’s say for example that from a performance perspective, and business perspective that 3x Isilon S210 nodes will provide sufficient near term performance and capacity, and since adding additional nodes is easy, the organization can expand as needed. Great right? Well not if we failed to take a look at the application requirements. In my earlier example I mentioned application A and application B, let’s put a name with those - call it Microsoft SQL 2014 and Microsoft Exchange 2013. Taking a look at the SQL server requirements, it would appear as though our hardware selection is a fit - there are some considerations for analysis services, and for clustering but we can adhere to those requirements with the Isilon S210.

Now, let’s take a look at Exchange; hmmm interesting note here. It seems as though Exchange is NOT supported on NFS storage - even if it is presented and managed via a hypervisor:

A network-attached storage (NAS) unit is a self-contained computer connected to a network, with the sole purpose of supplying file-based data storage services to other devices on the network. The operating system and other software on the NAS unit provide the functionality of data storage, file systems, and access to files, and the management of these functionalities (for example, file storage).
All storage used by Exchange for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support the use of NAS volumes, other than in the SMB 3.0 scenario outlined in the topic Exchange 2013 virtualization. Also, in a virtualized environment, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't supported.

So, here is a scenario where the proposed hardware solution, which is NAS/NFS based is not supported by one of the applications. In this case, the application vendor has a specific requirement around the application, above and beyond things like CPU, memory, or I/O. There is now an additional design decision - leverage two different solutions - one NFS such as Isilon, or NetApp for applications that support NFS, and a block solution for Exchange? This also dives into another level of “it depends” - if certain applications are expecting NFS storage some place, is it worth having two hardware solutions or making changes to the design of how the application works? For example, if you decided to go all block, either the application requiring NFS needs to change, or you still add another layer of complexity and management by possibly virtualizing an NFS server.  You may also find a storage solution that supports both block, NFS, and/or SMB 3.0 - the later of which would be supported as storage for Hyper-V. However, you’ve now introduced multiple-hypervisors into the environment, is that really any less complex than two hardware solutions? As an internal IT person, if the appropriate work was done at the begining, you hopefully are not spending a lot of time managing storage, that would be a waste. I can tell you, from personal experience as a former internal IT person, whose company supported a write heavy application that then offloaded cold data to cheap storage, I spent almost no time configuring storage because we put the appropriate thought into it before hand. Instead we focused on our applications, automation, and other projects in support of new application features.

There are many possibilities, it is all about building a reslient, reliable, and supported solution. Make sure all OTS and custom applications are documented, and considerations such as things like supported configurations are taken into account before you move on to design and hardware selections. Now this is just a singular example, there are considerations in designing infrastructure for much more than just storage, such as networking - ACLs, communication between applications, and the affects an ACL/firewall might put on communication. There is backup, disaster recovery, replication, automation - one of the reasons a VCDX design in many cases ends up being hundreds of pages.

Having this level of information helps you properly identify all the actual project requirements, after all - hardware, virtualization, storage, SDN, SDS, etc… is all about application availability and supportability, not about what kind of metal it runs on! I wouldn’t want anyone to think this is an anti-NFS or anti-block post, far from it - again its about supporting the applications your organization needs. This also presents an opportunity for you to reflect on if there are better, supported, options available. If your VAR/vendor is trying to sell you an unsupported solution, it is probably in your best interest to move along.

Now that I’ve said that applications are the MOST important consideration, I’m sure someone will find that use case where its not, but standing by this one - I’ve never had a CFO ask me if their virtual machine was having problems - its all about the apps!