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!
