News Analysis

More questions and answers from SAN school lesson # 8

SearchStorage.com Staff

SAN School: Lesson 8



"Tying your SANs together"

In this eighth lesson of SAN School, you learned how to tie your SANs together. To form a more powerful network and utilize SANs most effectivly you have to begin to create a connected environment that allows you to share and protect data seamlessly. In Lesson 8 Christopher Poelker extoled the virtues of a centralized SAN environment--an environment that is easier to manage and tie your applications together. This lesson explained how to extend the SAN, connectivity between SANs and SAN islands, IP storage, virtualization (in-band, out-of-band) and SW/HW pooling.

Since so many of you asked Chris Poelker questions during this SAN school Webcast, he didn't have time to answer them all. Therefore, we sent those questions to Professor Poelker and are posting them along with the answers for you here.

Here you'll find answers to questions pertaining to:

** LAN free and Serverless backups
** LAN free backup and datapaths from disk to tape
** Best practices in building a network for iFCP
** Routing IP over a Fibre Channel network
** Why use IFCP?
** Creating SWAN's or greenfield iSCSI SANs

Back to the SAN School table of contents

Question: What is the difference between LAN Free and Serverless backups?

Professor Poelker: LAN free backup usually involves the ability to share a SAN connected tape library between all the nodes connected in the SAN. The backup server simply co-ordinates access to the tape resources. Each server in the SAN actually runs a copy of the backup engine, and moves it's own data to tape. This is sometimes called the "SSO" or shared storage option from some backup vendors. The backup server becomes the traffic cop for the SAN connected tape resources, and allows each server in the SAN to back up it's own data. This removes the need to "PULL" data over the LAN via backup agents to a backup server connected tape resource.

Serverless backup is accomplished by the backup server having the ability to connect to storage on behalf of other hosts connected to the SAN, and back up that hosts storage on it's behalf. This usually involves the use of snapshot or image copies of the production LUNS in the SAN. The snapshot is used as the source media for backup, so that the production application can continue during backup. The snapshot is given access through LUN security in the SAN for access by the backup server, and the backup server sends the data to tape. Another method is to use the SCSI extended copy command called E-Copy, which allows even the backup server to get out of the backup path. E-copy allows data to move directly from disk to tape via a "data router", which provides the E-copy intelligence.

Question: Is Serverless backup the only solution for backup on a SAN?

Professor Poelker: Not at all. All the traditional methods for backing up data are still available for SAN connected servers. Using the SAN as the data path rather than traditional LAN based backup is what makes SAN based backup a better solution. You will find the fibre channel protocol provides a faster lower overhead/latency data path (up to 200MB per second) data path for backup streams. This is due to the fact that Fibre channel transmits data in larger SCSI blocks, rather than needing to be formatted into IP packets.

Question: In LAN free backups, could you explain the datapath from disk to tape?

Professor Poelker: During LAN free backup, the data path to tape is through each server backing up it's own data to tape, over the SAN. Data is read from the servers LUNS into server memory over one SAN HBA connection, then sent out to the tape library through (hopefully) another dedicated HBA for tape backup through the SAN.

Question: What is the "best practice" in building a network for iFCP? VLAN 100Mbps, VLAN 1Gbps? Is latency an issue?

Professor Poelker: The best practice is to provide the iFCP WAN connection with the correct amount of bandwidth to handle PEAK loads across the connection. The idea is to have a balance in WAN network costs and data throughput requirements. If you have a good understanding of timeframes for peak workloads, and If your WAN vendor provides the ability to lease bandwidth on demand, you should be able to maximize the utilization of your links vs the monthly costs for those links.

Let's say you know that the last Tuesday of every month is used for month end batch processing, and your bandwidth requirements increase during those periods. If a T1 connection handles the normal daily traffic across the link, but the month end processing requires a T3 link, your WAN vendor may be able to charge you for the bandwidth you actually use for the entire month, providing T1 bandwidth normally, and then increasing that bandwidth to T3 speeds during month end. Check with your WAN vendor to see if they can provide this "sliding scale" access to the links for your lease. Hey, if you have the budget, then Gig-E is always a great thing to have!

Question: I believe that the technology to route IP over a Fibre Channel network was mentioned. Can you provide any more details on this technology? Are there specific vendors who do this?

Professor Poelker: Sure, this works like Microsoft's redirector layer (NDIS?) You can assign multiple protocols to the HBA connection. Both IP and FC traffic can then pass over the links. JNI and Emulex provide this functionality, and most of the SAN switch vendors support IP traffic and IP routing over the fabric. This is a great way to provide MSCS cluster heartbeat connections over the same link as the data traffic for wide area clustering. I know the 5-2.21a8 version of the Emulex port driver for Windows 2000 supports this. Go to http://www.emulex.com/ts/docfc/frame92l.htm for more info.

Question: If ISCSI can map FC to IP, why should I use IFCP?

Professor Poelker: iSCSI is used for block access to disk resources for HOSTS over IP for servers that do not have fibre channel HBA connections to a SAN. This requires an iSCSI driver for each server for the LAN NIC, and either native iSCSI storage arrays, or an iSCSI bridge from that converts iSCSI traffic to FC traffic for traditional FC based SAN storage arrays.

IFCP is a protocol used between SAN islands to create a SWAN (storage wide area network). Both iSCSI and iFCP use IP as the transport mechanism, but they are used for different applications. IFCP is used for connecting fabrics together, and iSCSI is used for IP hosts to access disks.

Question: Will most iSCSI deployments, in your opinion, be able to create SWAN's or greenfield iSCSI SANs?

Professor Poelker: iSCSI devices can be used in place of fabric switches, so that the core of the SAN fabric can be created using traditional GIG-E switches, which can not only save money, but a company to leverage the existing technical expertise in data network environments. SWANS are not created via iSCSI, they are created by two other protocols, being FCIP and iFCP. FCIP and iFCP are used to connect SAN based switched fabrics together over IP links.

If you missed lesson eight of SAN School, view it anytime here

About Christopher Poelker:

Aside from being an author and a SearchStorage.com SAN expert Christopher Poelker is a storage architect at Hitachi Data Systems. Prior to Hitachi, Chris was a lead storage architect/senior systems architect for Compaq Computer, Inc., in New York. While at Compaq, Chris built the sales/service engagement model for Compaq StorageWorks, and trained most of the company's VAR's, Channel's and Compaq ES/PS contacts on StorageWorks. Chris' certifications include: MCSE, MCT (Microsoft Trainer), MASE (Compaq Master ASE Storage Architect), and A+ certified (PC Technician).


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
 

COMMENTS powered by Disqus  //  Commenting policy