Delphix and Ethernet are the Future

Delphix Virtual Databases on Unix & Linux use NFS

Delphix provisions virtual database copies using NFS for Unix and Linux databases.  NFS is a protocol that uses TCP/IP and requires Ethernet, so Delphix appears like Network Attached Storage (NAS) to database servers.

Occasionally customers ask why we do not provision over Fibre Channel (FC) using FCP which is the network and protocol used by Storage Attached Network (SAN) arrays.  The short answer is because most customers are gradually shifting data traffic workloads to Ethernet for a variety of reasons.

NAS versus SAN (NFS versus FCP)

A key difference between NAS and SAN storage is that with NAS the storage owns the filesystem which provides great flexibility around managing storage allocation.  A SAN presents raw storage to a database server as if it were directly attached.  The database server will deploy a filesystem to the presented storage.   Unfortunately the SAN administrator has little visibility into the utilization of pre-allocated storage which is why its not unusual to find SANs with only 50% utilization because of the inconvenience of resizing and the difficulty in tracking what space is used where.

This rather stunning fact is capitalized on by the growing number of Software Defined Storage (SDS) solutions that pool together storage resources across storage arrays and disks and present them as a single pool of resource.   The SDS abstraction layer can achieve much better utilization by leveraging better insight into the actual storage allocation versus consumption.   It is slightly ironic that one of the promises of centralized network storage was to consolidate storage and yet lack of insight into actual usage continued if not exacerbated the previous underutilization of siloed DAS.  Neither can you share unused bandwidth on a Fibre Channel network, this translates to bandwidth underutilization which is one of the key failings addressed by virtualization.

This leads to another point of irony which is that SANs and their corresponding FC networks are now viewed as siloed technologies.

Bottom line is SAN and Fibre Channel do not play ball in a virtual world.

Hasn’t this debate got form?

A lot of bias against NAS interfaces and use of Ethernet networks for data transport stems all the way back to 2001 when the only real choices were 2Gb FC or 1Gb Ethernet.  SAN was better than NAS back then not because of the protocol itself, but because the transport frequency was higher.

People were also mistakenly concerned about lost writes and corrupted databases which does not happen when using NFS over TCP.

Even though both Fibre Channel and Ethernet bandwidth has improved the uptake of these has dragged far behind.  For example most customers using SAN storage still only use an 8Gb FC connection, even though 8Gb FC has been around since 2008.  10Gb Ethernet has been around since 2002, but most customers still only have 1Gb Ethernet which they use for non data traffic.

My Way is the Highway

You can think of Fibre Channel being like a railway system with specialist vehicles and tracks, with high utilization on the trains – standing room only – but low utilization of the tracks - not enough trains.  On the other hand Ethernet is more like a road system, more connectivity, higher utilization and if you want speed build better roads or move to Germany.

Why make the move?

So apart from being fabulously expensive, difficult to manage and not easily virtualized, why should I change from FC SAN to Ethernet NAS?

•  Ethernet speeds are advancing more rapidly that FC.  Switch vendors are skipping 20Gb Ethernet and offering 40Gb.
• Switch vendors provide FC connectors mainly for “backwards compatibility”
• FC can run over Ethernet
• You only need 10Gb Ethernet for your most important databases, few databases need more than 2Gb of bandwidth
•  If you apply the same network discipline to configuring and managing data traffic over Ethernet as you have done in the past with Fibre Channel then you will have at least comparable performance and security, but better utilization and lower costs.

You don’t have to throw away your SAN.  Delphix is storage agnostic but since SAN is so ubiquitous the majority of Delphix customers use existing SAN storage to underpin Delphix, what we call Delphix enabled storage.

If you are running Oracle

Oracle introduced direct NFS (dNFS) in 2007 with joint development and testing with EMC.   Oracle dNFS can be used with single instance and clustered Oracle databases, it improves performance, availability and scalability of Oracle databases running on NFS mounted storage, whilst reducing system CPU consumption.

Almost all customers that test Oracle dNFS decide to use it thereafter.   Every Delphix benchmark I have been involved with has benefited from dNFS, to the point we can get the same performance from a Delphix virtual Oracle database as from an Oracle database underpinned by the same physical storage.

Summary

The reasons customers are moving to Ethernet for data traffic are precisely in alignment with Delphix goals to simplify data management and lower component and operational costs.

With Delphix and Ethernet you can lower your storage costs, lower your network costs, lower your operating costs and speed up your data management and provisioning tasks.

Acknowledgements

Many thanks to Jeff Browning, the “Oracle Heretic” for some excellent background collateral.  Any mistakes or misinterpretations are of course mine, they are all mine!