Storage Networking without the SAN - really?

Its origin is sometimes traced to avant-garde architectures conjured up by wickedly smart computer scientists at Google, Facebook and Amazon. Or perhaps, it has an older lineage. Regardless, it’s likely causing you to reconsider the relationship between applications, storage and the networks interconnecting them. I can tell you that the controversy is certainly stirring up concern from the biggest storage vendors in the planet, and will certainly have repercussions on choices you’re making today.

Direct-attached storage making a comeback
Being SAN-averse could just be one of those things youthful newcomers gravitate to- a trend that skips a generation. History tells us that as recently as two decades ago, storage-area networks (SANs) were nowhere to be found. All your disks came in application servers – so called Direct Attached Storage or DAS, private to each host. You bought the whole package from your favourite server vendor.

DAS configurations flourished until two difficulties became apparent; one with financial implications, the other affecting operations.

First, a good percentage of servers were running out of internal disk space, while their neighbours had plenty to spare. Missing was an equitable way to distribute available capacity where it was most needed. Companies were forced to buy more disks for the overloaded systems, although they had vast vacancies in the adjacent racks.

The second problem with DAS really hit home with clustered machines, especially after server virtualisation made virtual machine (VM) mobility possible. In VM clusters, multiple physical servers need access to the same data in order to rapidly take over for each other should one go down or become overloaded. Imagine how crazy slow it would be if every time an app updates its disks, it also has to send a copy to 7 other servers in an 8-way cluster. The delay waiting on all to acknowledge would drive users insane.

SANs offer a very appealing alternative - one collection of disks, packaged in a convenient external enclosure where any data updates become immediately accessible from multiple servers in a cluster. No thrashing of networks to keep everyone synchronized. The SAN phenomena drove huge growth across all the major independent storage hardware manufacturers, EMC, NetApp, HDS. It also spun up numerous others.

As investors, one has to wonder how their fortunes will be affected if the pendulum swings back to DAS and SANs fall out of favour?

Such speculation is fanned by dissatisfaction with the performance of virtualised, mission-critical apps running off disks in the SAN, leading directly to the rising popularity of server-side Flash cards (solid state memory).

The arguments put into question where best to locate your storage, or more precisely, how much and what type of storage should be directly attached to the servers and how much should be a shared resource located over the network?

Server-side viewpoint
The server-side flash position seems pretty compelling. Much like DAS did 20 years ago before SANs became the rage. The concept is simple. Keep the disks close to the applications, on the same server. Don’t go out over the wire to access storage for fear that network latency will slow down I/O response.

The SAN supporters, on the other hand, contend that server-side storage wastes resources. Better to centralise your assets and make them readily shareable.
Those defending server-resident storage strike back saying, we can pool those resources just fine. Slap in a global name space and we can get to all the storage regardless of which server it’s attached to. Ever wonder how? You guessed it; over the network. Oh, but what about that wire latency? They’ll counter that it only impacts the rare case when the app and its data did not happen to be co-located.

Well, how about those replicas we’re making to make sure we don’t lose data when a server blows up? You guessed right again. The copies are made over the network.

What conclusion can we reach? The network is not our enemy, it is our friend. We just have to use it judiciously.

Now then, we have oodles of storage piling up. Should we get bigger servers to fill them up with tons of disks? Why not? Servers are inexpensive, and so are the drives.

What should I do with the data I have on my SANs? Move them back into the servers?

Need we Take Sides?
Maybe our choice need not be so binary. For many organisations, it makes perfect sense to have some storage inboard on the servers ‘cozying up’ to the apps, supplemented by some externally shared storage on premises, and the really bulky archives in the public cloud –especially those requiring long-retention.
The difficulty for those taking sides is they don’t tolerate the other alternatives. And so it’s all about convincing you to pick one location vs. the other. Their rigid convictions arise from a myopic perspective driven by the impact on their company’s revenues.

You can see where I’m going with this.
If instead of choosing sides, one designs software to leverage your storage assets in all three places: the Server, the SAN and the Cloud, then we remove the religious bias over location. You are then free to route the requests where most appropriate, and put the network to good use when it’s beneficial.

Techniques like infrastructure-wide automated storage tiering follow these principles. Really active bits stay close to the programmes, munching on them using local flash storage, whereas infrequently used data gravitates further away over the wire.

Caching plays a really important role keeping everything going smoothly. It is the ultimate speed matcher. And what is the ultimate storage device closest to the app? Good old server memory (DRAM).

Controlling caches, placement, replicas, and thin provisioning – that’s where all the software smarts come into play. And being able to hover across all 3 locations (server, SAN and cloud) makes all the difference in the world.

Don’t force me to take sides. Each one has their merit, that’s why we evolved this far.