SCSI transport needs synchronous and low delays when we started SAN networks, and FC allows at that time 1.25G of synch transmission between host and disk array. That is part of the reason why.
Nowadays we can also use iSCSI with high performance Ethernet networks and IP stacks embedded in hardware
Your question has two parts.
1) Why FC in SANs
2) Why not use locally attached storage to an ethernet connected host (home made NAS)
FC emerged as the technical and commercial winner from the technologies available at the time, althought there are still benefits from using FC over ethernet the speed gap is closing or closed and the proliferation of Ethernet and IP skills and the reduction in complexity (no seperate HBA's or switches) means that FC is unlikely to continue as the leader in SAN connectivity.
SANs were a way of consolidating shared storage for easier management and more efficient hardware utilisation
I use 4Gb FC instead of copper because I have up to 6 clients accessing multi-gigabyte data sets at the same time on the same San, usually they are reading the same set.
The overall speed of FC allows for sync to happen without delay, stopping any version/parity errors happening.
I could use 10GbE over copper, but it has too high a latency for what I'm doing, FC, while being slower, can make up for the speed difference by having a lower latency.
FC Sans allow for high 'transaction per second' because of the higher bandwidth.
My primary San is a 7TB unit that outputs 1 GigaByte per second (not 1 GigiBit).
(it has a burst output of about 2Gigabytes per sec)
At the moment I'm managing 25TB of file-systems across 3 FC connected sans, If I tried to do this with copper it would take days, if not weeks for all the different jobs to synchronize.
Also the LTO auto changer that's connected to it all would be a waste of time over normal 1GbE.
10GbE is a faster option, but I'm not seeing deployment of it due to the costs involved and the smaller install base means it's harder to find quality install techs.
Another downside to 10GbE copper is the differences in distance and power requirements. Additionally the need for TOE's in the servers makes it that bit harder to control TCO (more part's equals higher failure rate, equals higher costs)
For me it's easier and cheaper to install FC systems.
Considering the already prodigious investment in existing FC, many will just stay with it and wait for 8Gb FC.
So, in answer to the question;
Existing install base, cost, support and experienced installers.
Your information is based on last generation storage practice.
Current trend is low cost iSCSI on gigabit ethernet network.
Now, for supercomputing, FC (fibre channel SAN) is needed (but this is the exception, not the norm).
It is a tradeoff of cost versus speed (iSCSI or pizza box SAN versus FC SAN's).
I am currently dedicated to a 300+TB SAN Infrastructure that runs all FC connected devices across 2 cities 50 miles apart.
Personally, I do not see iSCSI taking over the SAN infrastructure on the larger scale. It should only be viewed as a cheap altrenative for the smaller environments.
It would be good to do a google search for more information to back this up.
The main reason I/we have chose FC is (as mentioned above) response. There is not a high overhead of traffic, NOISE, and protocols.
It is SECURE from the curious hackers/snoops in house or out. FC Network is a point-to-point configuration.
An alternative to use the iSCSI is a DEDICATED ethernet that is iSCSI only. This still will not keep the typical hacker/snoop out.
On this current FC network that I am responsible for, the highest utilization I have seen was 30% of a 2GB ISL (Trunk) during a backup. I am in the process of changing it over to 4GB and adding more security. This is only in planning for future bandwidth that I will doubt will be needed even 5 years down the road.
I think there are three elements to answer with this
1) Why do people use SANs rather than ethernet based servers
This is because a SAN acts like a physical disk within the server - and is seen by the operating system as a local disk. This means that it doesn't have overheads such as locking, file sharing and security that an ethernet based server would. In most cases each area of storage is dedicated to a single server - but in the case of a server failure a second server can instantly gain access to the disk area to allow for continuity.
2) Why do we use fibre channel rather than copper wire
The main reason for this is that fibre channel is not subject to electromagnetic interference - as there is no current flowing. This means that the signal doesn't have to be filtered and undergo cleaning/error checking upon receipt. Modern transiever technology is closing the gap in this area.
Why do we not use the ethernet protocol for SANs
The ethernet protocol is primarily designed as a broadcast protocol for cummunicating between a large number of peer devices on a fairly unstructured network over reasonably long distances (100m). It therefore has provision for non-receipt of packages and collisions. In the highly controlled environment of a SAN this would simply present an unnecesary overhead
iSCSI is a great technology but in practice still has a higher latency than FC. For a large number of applications this latency difference will not be noticeable. Although if you have a very low latency requirement for your application be extremely careful in selection of your NIC, switches, and storage with iSCSI.
FC is more secure mostly for one brain dead reason. FC is typically always found a a separate storage network. Everyone is putting iSCSI on their normal network so it makes it easier to hack. Plus more people know how to hack a TCP network than FC. Put iSCSI on its own network and it will be just as secure at FC.
I think one big issue is being missed here, being redundancy. A FC disk still has TWO IO paths to the drive mechanism. This means a Storage array can be built as a resilient solution with the only single point of failure being the drive mechanism itself, and to catch that caveat we have multiple spindles and data guarding areas in the disk groups.
Furthermore, speed is still a good second reason. I’ve yet to find an ISCSI solution that will outperform a well built FC SAN array in true IOPS.
One trend I do see is that less critical systems utilize the FC arrays through ISCSI bridges. This saves some costs towards host connectivity as FC is still (and will probably remain) a very expensive way to connect an endpoint.
When you use a network connection using a fileserver, the data you need always has to pass through the complete ip-stack of the server and the client. This wil give you a bigger latency. This is fine if you are loading a simple file and than saving it. If you need constant streams of data (audio, video, ...) you will get speed drops.
Your question is very good.
There is no advantage of fiber over copper (Ethernet). Actually electricity flows faster (much faster) through copper than light through fiber.
Earlier, it was easier and cheaper to build signal emitters (LED) and receptors (photo diodes/transistors) then logical interfaces for copper.
Today, almost there is no difference, and seems that copper will prevail, because is more robust. Signal transported through fiber is more vulnerable.
Definitely, future is copper and Ethernet.
Drago Pejic, M. Sc., F.L.M.I.
http://www.dataintegrityinstitute.com
Links:
http://www.dataintegrityinstitute.com/productsandservices.htm
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment