IP-SAN has been used for file services. But it is actually
capable of much more. by Pramod S.
has been enough debate on the SAN vs. NAS issue. But
those who have written about this have generally taken
the traditional view of differentiating SAN and NAS.
The aim of this article is to understand SAN and NAS
from a functional point of view, and to look at IP-SAN
not just as a File-server but also as a complete storage
system, which can take care of other application needs
too. Technologies like iSCSI, iFCP (Internet Fiber Channel
Protocol) etc have been briefly discussed as these have
not yet been widely accepted in the market, and the
technology is also not completely mature.
Technically, a product might offer many features, but
what is the point in buying something 'big' when those
technical features cannot be converted to business goals?
The technology that you plan to implement, should ensure
the required uptime, give you sufficient performance,
reduce maintenance, and be scalable. Overall, it should
make a difference in the way you work, so that with
the same or less effort you deliver more support to
A Storage Area Network may be defined as a dedicated
network of servers and storage with:
Any to any connection
Multiple paths to all resources
Open structure using industry standard protocols
No nodal dependencies (it can function even if a node
or two is down)
High bandwidth and High
Scales up with no performance loss
A SAN can be deployed in two ways: using Fiber Channel
or the IP way. The first is called FC-SAN while the
second is IP-SAN. IP-SAN can also mean the network built
with iSCSI as the protocol. I will limit my discussion
to NFS/CIFS as the protocols for the IP-SAN.
Let's examine the functional difference between FC-SAN
and an IP-SAN.
As seen in the diagram, in an FC-SAN the file I/O is
between the application and the file-system, which talks
to the volume manager, which in turn makes block I/O
to the storage device. As we see here, the file-system
and the volume manager (if any) are on the server and
the storage has the RAID and the disks.
on image for larger view
The basic components of the system are the same, but
here the application makes the file I/O to a file-system
which is outside the server and the block I/O now happens
within the storage between the volume manager and the
Traditionally, NAS has been used for File services only
and SAN for all other applications. But those were the
days of File-services from servers and 10 Mbps LANs.
With dedicated appliance and gigabit speeds on the wire,
throughputs that can be obtained from NAS devices are
really good. Applications have their own requirements
or limitations in terms of the bandwidth that they use.
Just because you have connected a 200 Mbps link between
the server and the storage, the application server will
not use the full bandwidth, it might not use half of
it tooit all depends on the application requirements.
An application might require about 20 Mbps bandwidth,
so there's no point giving it 200 Mbps Also, the servers
have to be big enough to pump so much of data in and
out, a small or medium server will not be able to pump
so much I/O. A detailed assessment of the I/O requirements
and server capacities needs to be made before sizing
any storage device.
IS PERFOMANCE EVERYTHING?
But why is performance associated with speed and power?
What is overlooked is the performance the applications
will require. Should one only look at storage for performance
or look at other aspects like ease of use, recoverability,
Good performance can be achieved on both IP and the
FC storage. Performance is definitely required when
things are running fineit should run at optimum
speed as per business requirements, but performance
is not everything. Performance is good as long as things
are normal, but when there is a crisis or some failure,
the credibility of the storage vendor comes into play,
in terms of recoverability.
Traditionally, FC-SAN has been considered to be difficult
and IP-SAN easy to deploy. Also FC-SAN is associated
with interoperability issues, which the IP-SAN is not.
Though this does exist to an extent, it is much different
from what it was before. FC-SANs are coming up with
management tools, which make deploying FC-SAN relatively
simple and vendors on IP-SAN making their devices faster
and faster so that there is little distinction on what
can run on IP-SAN and on FC. But to date IP-SAN deployments
are extremely simple and easy to deploy, manage and
provide some exceptional recovery methods.
on image for larger view
Storage on IP-SAN has evolved to a large extent than
what it was before. With performance getting closer
to SAN storage, while still maintaining all the manageability,
and recoverability features, they make an ideal choice
for most requirements. Current IP-SAN technology can
address 80 to 85 percent of the storage requirements.
The rest is better on SAN because of specific requirements
or application needs, but can still be met on IP-SAN
if the investment in FC does not make business sense.
There are many media companies who use IP-SAN for streaming
audio/video data. There are also enough implementations
of databases (OLTP & DSS) or ERP/Billing etc on
IP-SAN. This is evidence that traditional approaches
are things of the past.
If we look at a development environment where databases
have been deployed for developing applications or small
SAP implementations with 100 odd users, even an average
size IP-SAN would be enough to provide the required
performance. You don't even need a big IP-SAN device.
DAFS (Direct access file system) an open protocol fore-fronted
by IP-SAN vendors, has shown extremely good results
on the industry standard TPC benchmarks for OLTP. The
real world benchmark showed the best price/performance
for a Unix-based system, the best per-processor performance
for a SPARC-based system, and the best performance per
CPU-MHz on SPARC ever achieved show that extremely high
OLTP requirements can also be met on the IP-SAN where
performance outweighs all other requirements.
NAS with SAN
on image for larger view
NAS represents devices that attach themselves on the
IP network and provide CIFS/NFS services. I would differentiate
NAS from IP-SAN as IP-SAN being setup with a dedicated
interconnect (Gigabit) between servers and NASwhen
the same storage, is connected on the Non-Dedicated
10/100 Mbps Network. Performance is one of the main
criteria of IP-SAN along with other features of IP storage.
A typical setup showing an IP-SAN also being connected
as NAS is shown below.
Storage requirements need to be looked at not just from
the performance point of view, but a holistic approach
needs to be taken with business needs in mind. Traditional
approaches of 'IP for file' and 'FC for databases' are
passé. Decisions need to be made considering
all the storage requirements of an enterprise (file
services and database or other applications), and the
infrastructure or manpower in place. The investment
that needs to be made for the deployment of the new
infrastructure is also an important factor.
are some other differences between FC-SAN and IP-SAN:
SCSI-III Protocol for data access
NFS/CIFS Protocol for data access
Fiber Channel Network
Gigabit Ethernet Network
Volume manager using server OS/ Middleware
on the server
Volume manager on the storage
File-system using server OS/ Middleware on
File-system on the storage
RAID on storage
RAID on the storage
Only hardware Sharing
Hardware and Data Sharing
Use HBA to connect from the server
Use NIC to connect from the server
Wire Speed 100 - 200 MB/Sec/HBA
Wire Speed 125 MB/sec/HBA
between IP-SAN and NAS:
NFS / CIFS access to storage for specific
NFS/CIFS access to storage on the standard
servers on a dedicated Gigabit or Higher Network
For High Performance requirements along with
For less performance intensive access along
IP-Storage features like data sharing, recoverability,
other IP-Storage features like data sharing,
ease of use etc.
recoverability, ease of use etc.
S. is Systems Specialist Apara Enterprise solutions