iSCSI FAQ

20 years ago the time before SCSI and Ethernet. Mini and mainframe manufacturers each had their own ways of communication between, client-mini-mainframe and proprietary operating systems that managed storage. With the advent of SCSI and Ethernet, things changed. For the first time people could connect multiple storage devices together from various vendors i.e. tape drive, disk drive and they would work with relatively low cost SCSI cards. Networks were no longer proprietary solutions, they used standard cards and cabling. With these advances came the client - server culture we have today.

The late 1990's saw the development of the Network Attached Storage device - NAS and the first Fibre hannel SAN. These two things changed the way people viewed storage and how it integrated into their infrastructure. Up until this time people bought a server with a processor, memory and disk space. When the disk space was full another server was purchased and so the cycle continued. Many of the corporates we deal with today have 100's of servers with Terabytes of disk space. The cost of maintaining this is becoming more problematic. Backups of the data are taking longer, mission critical applications with 100% uptime, increased server failures due to the sheer number of servers running, licensing costs and the cost of adding disk storage ever more problematic.

Both the NAS and Fibre Channel SAN address these issues by removing the data from the processor and memory and enable people to buy less more powerful servers or blade servers and increased disk space. With a NAS you connect the product directly to your Ethernet network and within a matter of minutes you have nstant disk space. A SAN needs far more planning and offers even more flexibility than a NAS device but essentially both remove the data from the servers. Now in 2006 we have iSCSI products that combine both SCSI and Ethernet into a single protocol. Over the next few years iSCSI will supplant all the other technologies. iSCSI storage products will act just like network printers do today. The management of storage will increasingly become easier as the technologies merge and management simplified. An example of this is an IP address will be allocated to the storage device, a device driver will loaded on the server/client and data will be automatically sent to the relevant device for backup, storage or archive.

This technology will kill the Fibre Channel and Network Attached Storage markets as it provides storage on demand with considerable cost savings. Large suppliers of existing Fibre Channel SAN's will need to view how they offer storage and at present these organisations are shunning IP storage in favour of Fibre Channel storage merely due to the loss in revenue that iSCSI would cause. Companies that looked at Fibre Channel and baulked at the price can now look at IP storage and see the massive gains that this technology now has.

It's shipping now, is available and it's supported.

2. What is iSCSI?

iSCSI is based upon existing industry standards, practises and applications that are known and understood by end users.

iSCSI is a network storage protocol that encompasses block level SCSI data in a TCP/IP frame, thus allowing servers to access storage resources over an existing IP infrastructure.

iSCSI is a combination of SCSI and Ethernet technologies that have been around for more than 20 years and are fully tried and tested.

iSCSI is a cost effective way to build SAN’s at much lower cost point, giving users greater consolidation in their environment.

The iSCSI storage protocol is supported by 99% of the major storage vendors and endorsed by Microsoft, IBM and Cisco therefore it is an industry standard.

iSCSI is an OPEN architecture that enables an optimised and cost effective TCO to be achieved and your TCO is protected for the future.

Fibre Channel is a TIED architecture that can only see an increase in TCO in the future

3. What are the advantages of iSCSI?

4. Do I need Fibre channel to build an iSCSI SAN?

No, fibre channel is a totally different networking topology than iSCSI.

5. Can I use my existing Fibre Channel storage in an iSCSI SAN?

Yes, if you connect your Fibre Channel storage to an iSCSI Appliance. These appliances can have internally a fibre channel card which you directly connect your existing FC storage.

6. What is an iSCSI Appliance?

An iSCSI Appliance has disk storage attached. This disk can be SATA, SAS, FC or SCSI based. The iSCSI Appliance also has multiple Gigabit cards for sustaining the transfer rates that are required by the servers on the network. The Appliance also offers a high degree of redundancy against component failure and typically single or dual processors. The disk that is connected to the iSCSI Appliance is then served up across your network using IQN names, this creates a handshake between the iSCSI Appliance and the server or workstation which is being provided with disk storage.

In addition to this Snapshots can be taken for the disk being offered up along with mirroring and high availability.

7. What are the drawbacks of Fibre Channel compared to iSCSI?

Fibre Channel is still viewed as an alien architecture. It requires special training and high-priced expertise to keep a Fibre Channel fabric operational. Fibre Channel also requires its own management software, which is not fully integrated with mainstream IP network management. So, although Fibre Channel fabrics have many technical strengths, overall they require additional skill sets and tools.

IP storage protocols such as iSCSI, iFCP and iSNS integrate directly into mainstream IP networking. Every company has a trained IP network staff, familiar with IP routing and Gigabit Ethernet switches. All other data types are being merged into IP networks, including voice and video. From an IT administrator's standpoint, IP storage is just one more variety of IP data that can be run over a familiar and strongly supported infrastructure.

8. Are there clear-cut situations for using IP storage versus Fibre Channel?

Any campus, MAN or WAN requirement is more easily addressed with IP storage than native Fibre Channel. Fibre Channel will give you up to 10Km links, but those must be dedicated, point-to-point connections. Extending Fibre Channel with DWDM is expensive and performance suffers significantly beyond 30Km.

Using storage over IP offers the flexibility of IP routing as well as gigabit speeds for MANs.

9. Even though the IP is well understood, my belief is that there are still issues regarding management, resource management, and virtualization. The main issue points to standards. Can you comment?

The outstanding issues you mention apply to storage networking in general, regardless of underlying plumbing. Standardization is an issue for storage management and virtualization, and while I think these will be addressed over the next several years we can at least now begin relieving some of the customer pain caused by the transport infrastructure. By building IP SANs, customers can leverage their existing IP expertise and resources, provide quality of service and advanced security (which Fibre Channel cannot currently provide), and still get significant end user value while the higher level applications are being further developed.

10. Will the eventual majority acceptance of one protocol over another help or hurt the speed at which technology benefits?

As the Internet community has shown, tremendous innovation can occur at an accelerated rate even though the applications are all sharing the same infrastructure. For storage networking, the plumbing itself is only one component. Settling on a mainstream protocol such as IP will help, not hinder, technology development. The exciting technology developments will occur in the area of storage virtualization and ubiquitous storage access. If it all runs on IP, it'll be easier to focus on the applications most meaningful to end-users.

11. Is a 10 Gigabit backbone an absolute prerequisite for an IP-based SAN solution?

In short, no, 10 Gigabit is not a prerequisite for IP SANs. Most storage applications do not take advantage of the 1 gigabit pipes now available. But 10 Gigabit links enable enterprise customers to build very large non-blocking core infrastructures that feed 100s of storage devices in a single IP SAN. Instead of trunking interswitch links, 10 Gigabit Ethernet links can be used (or for very high performance, trunked 10 Gigabit links). This allows companies to scale to large IP SANs using mainstream Gigabit Ethernet switch equipment. Now for vendors of large storage arrays, it's probably viable to have a 10 Gigabit iSCSI interface on the array: one big fat pipe (or multiple big fat pipes) to service 100's of initiators.

12. What assumptions are you making on the rate at which the speeds of Fibre Channel and Gigabit Ethernet will grow with time? What if Fibre Channel grows more rapidly?

Gigabit Ethernet has already been first to market with 10 Gigabit interfaces. There are enormous engineering resources behind IP and Gigabit Ethernet, so I don't think the much smaller Fibre Channel engineering community will be able to win a speed race. 10 Gigabit Ethernet interfaces are most useful for interswitch links and high performance disk arrays. This allows for building very large, non-blocking core switch infrastructures, which in turn feed hundreds of Gigabit end devices.

13. Do you think packet loss will be an issue in IP storage protocols?

Packet or frame loss also can occur in Fibre Channel fabrics if links are over-subscribed or poorly implemented. For IP storage, the TCP session control will insure that there is recovery from packet loss, should it occur. However, if the network is properly designed, this recovery mechanism won't be invoked frequently. I doubt that many users will start putting mission-critical IP storage data over congested or lossy network links. As in Fibre Channel fabric design, they will allocate sufficient bandwidth to accommodate the needs of the storage application. The advantage for the user is that the IP SAN is based on equipment and protocols that are more easily acquired and supported, and the bandwidth (as shown by the Qwest network in the Promontory Project) is readily available through IP/Gigabit Ethernet providers.

14. What year do you predict that IP storage will take over from SAN?

I don't know if Nostradamus has a quatrain on this, but I think we will see a fairly rapid shift over the next 2-3 years as iSCSI-capable storage arrays come to market. As a customer, if I am given a choice between a storage array with either a Fibre Channel interface or an iSCSI interface, and if 99% of my corporate network is already IP, I will probably select iSCSI, the interface that is more easily implemented and supported by my existing IT staff. Analysts reckon that by 2008 more iSCSI storage will ship than any other type.

15. Interoperability is a major issue in Fibre Channel based SANs today, but it has improved. Won't moving to iSCSI re- introduce many of these same issues all over again?

Well yes, it could. It's reassuring, however, that collectively the iSCSI vendors have taken a very aggressive and active approach to interoperability. The work of the University of New Hampshire iSCSI Consortium and the SNIA Interoperability venues at SNW and the SNIA Technology Center have helped to resolve interoperability issues in IP storage even as the technology itself is maturing. The lingering interoperability issues that have retarded more widespread adoption of Fibre Channel SANs would never be tolerated in the IP world. Specifically, interoperability problems that are the result of vendor dominance and foot-dragging due to competitive interests are directly opposed to the open systems philosophy that has driven IP and Ethernet. We already have seen, and I think will continue to see, higher standards for interoperability coming from the iSCSI initiative. In addition, the infrastructure that IP storage relies on is already well-established, mature, and interoperable.

16. Do you think network administrators will push storage problems to the storage administrator? (not-my-job syndrome)

We have a collision of worlds at work in storage networking. Some network administrators want nothing to do with SANs; others want to own everything that remotely resembles a networked solution. I think most large enterprises are undergoing a cultural melding between networking and storage, and this requires network administrators to become storage savvy, and for storage administrators to become competent in networking. One of the clear advantages of IP storage is that it removes the issue of having an "alien" architecture to deal with. If everything is run on IP, it makes the culture clash less severe.

17. Do you think that the effects of retransmissions during TCP sessions will not destroy the reliability of IP Storage?

As in the previous question on packet loss, a properly designed IP storage network should have minimal retransmissions. In any case, reliability is not affected. With TCP, you may lose packets, but you will never lose data. The real impact of excessive retransmissions would be on performance. If I'm putting my IP storage over lossy, congested links, I can expect a performance hit, just as I would if I were to run my storage data on lossy, congested Fibre Channel links. If I have allocated sufficient bandwidth, I can expect optimum performance.

18. Have you measured the impact of storage transfers over a typical wide area IP network?

We have a fair understanding of performance over different IP infrastructures based on showcase and customer testing. The good news is that IP networks today are relatively error-free and, depending on the customer's budget, available in just about any bandwidth. The kind of bad news is that speed of light is, at least so far, a law of physics, so no matter how much bandwidth you have, you'll always have propagation delay.

Generally, T3 (45 Mbps) is the lower limit recommended for storage applications. But it really does depend on the application. Some incremental tape backup applications might tolerate lower speeds and still meet their backup windows. Storage applications that need constant acknowledgement with only one outstanding IO will not perform well over high latencies or narrow pipes.

I would always recommend that customers pre-stage configurations with their actual applications (not just IOmeter). In most cases, even over poorer performing IP networks, the application will run. But it may not meet the customer's performance requirements. Measure the cloth lots of times, then cut.

19. Which in your view will succeed, in order over time, between FCIP, iFCP and iSCSI and why?

Good question. We will see all three protocols used initially, but I think that over time you will see FCIP fall out of favor. FCIP is just FC tunneling and it perpetuates a lot of the problems associated with large or extended Fibre Channel fabrics. The more FCIP products deployed, the more these issues will surface and customers will look at alternatives.

The iFCP protocol was developed precisely to overcome issues that have been identified with native FC extension and FCIP tunneling. So I think iFCP will endure as long as there are Fibre Channel products on the customers' books. Customers will want to preserve the investment they have made in their large EMC, HDS, IBM or Compaq storage arrays that use Fibre Channel interfaces. iFCP is the best way to bring those devices into an IP SAN, while still providing a migration path to iSCSI.

iSCSI may gradually displace Fibre Channel, both as a transport protocol and as an interface for storage devices. The iSCSI specification, however, doesn't even mention Fibre Channel, so there is a need for iFCP for transition and iSCSI for new devices.

20. Can I help justify dual-SAN solution by replacing tape? What about the need for archival recovery? Is there a "best practices" strategy for the roles of dual-SAN and tape?

Disk to disk replication solves a major issue with tape: restoral. While people may be quite diligent in performing their backups, few actually test their ability to restore from tape. They're often shocked by the results (both duration and finding that some tapes are bad).
Disk replication gives you a highly available copy of data should the primary array fail. No restoral needed before data can be accessed. So in that respect, it is much more efficient than tape.
My recommendation would be to do both. You also want to guard against the extreme case in which both disk arrays fail. Tape will provide the insurance that there will always be some means to get back into operation with data intact, even if it takes some time to do so.

21. Is there a difference between an iSCSI HBA and an iSCSI NIC?

The iSCSI adapter vendors are all in a toot about what to call these things. Companies from the IP space like Alacritech or Intel are content to call them iSCSI NICs. Companies from the Fibre Channel space like QLogic want to call them iSCSI HBAs. The acronym "NIC" seems to have a commodity connotation, whereas "HBA" implies some additional value. On the other hand, the "NIC" advocates point out that their products also can be used concurrently as a wire-speed GE NIC for NAS or client-server connections. That may prove to be an important capability - especially for blade servers, where card slots are scarce. For efficiency, all iSCSI adapters need to have TCP off-load and potentially some degree of iSCSI processing off-load as well.

22. If the world will eventually go to iSCSI, what is the value proposition for multi-protocol IP storage switches that do iSCSI-to-Fibre Channel translation?

There is significant value in having an iSCSI-to-Fibre Channel switch offering. The real investment customers make today is in the storage arrays themselves. The state-of-the-art happen to have Fibre Channel currently, and will have for the next few years. There is some cost in front-ending the Fibre Channel storage with an iSCSI-to-FC switch product, but the customer immediately realizes the value of using standard IP network infrastructure for the SAN core. Our solution also allows them to displace FC switches and associated cost and support.

We have had a lot of interest since the Alacritech announcement (and subsequent Intel announcement) since customers can now deploy 2/3 of the SAN with IP (host and interconnect). That provides more flexibility on the host connection side (since hosts can be plugged in anywhere within the IP network and are not bound by FC cabling to a fabric switch) and significant savings in terms of acquisition and support of high performance SAN cores built with Gigabit Ethernet switches instead of FC directors.

We will be having some showcase customer installations shortly, in which they're building IP SANs instead of FC SANS, but still using FC enterprise-class storage. The hosts will transition to iSCSI, the IP SAN core is already IP, and existing FC storage can be integrated with iSCSI storage as those come to market.

We don't see customers complaining about the cost of iSCSI-to-FC switching. Compared to the cost of the storage arrays, it's minimal. Their pressing concern is how the SAN infrastructure in general can be supported. They already have staff for IP and Gigabit Ethernet. They already have acquisition and support channels for their GE core networks. So provisioning iSCSI host adapters and IP storage switches is directly in line with their overall network and TCO strategy.

Since we've shown that both the iSCSI NIC (Alacritech being the first) and IP storage switching can perform at wire speed, the customer does not have to sacrifice performance in order to gain the benefit of using familiar, mainstream IP networking for storage data.

23. Why is iSCSI significant for users? For investors?

In the long term iSCSI will allow shared storage solutions to penetrate the majority of the IT market, not just the high-end enterprises where SANs reside today. By using mainstream IP networking technology, it will be possible to deploy shared storage anywhere within the network. Customers can use IP certified staff to support the SAN transport, leverage their existing acquisition and support channels for network hardware, and avoid the additional overhead of highly skilled, highly paid FC SAN experts (or dependence on FC vendors). In addition, use of IP for shared storage brings the advances already achieved for quality of service and security mechanisms, as well as scalability (using Gigabit and 10 Gigabit core Ethernet switches) and transport over any distance.

For investors, iSCSI immediately gains the market momentum already established by IP internetworking. FC SANs had to create their own wave; IP SANs can ride the tsunami of IP convergence, along with voice over IP, video and other technologies. Companies that are in the forefront of IP SAN technology (oh, let me see... Nishan for example) should see much faster market penetration, growth and profitability since the technology hits a much broader market.

24. How would you define how iSCSI works in layman's terms?

Information that is key to modern business is ultimately stored on disk in the form of blocks of data. That block data is written to and read from disk using the SCSI protocol, which is optimized for low-overhead movement of data from disks to file servers, application servers or workstations. The iSCSI protocol carries those SCSI commands for reads and writes of data to disk using TCP/IP, which has become the Esperanto of data communications. By using TCP/IP, iSCSI enables host computer systems, storage arrays and tape libraries to be plugged into a mainstream IP network. Data can now be stored and retrieved at very high speed and with high reliability over common network infrastructures and block data transport can be managed with established IP network management tools.

In an iSCSI configuration, a host system would have a Gigabit Ethernet card as the interface to the IP network. iSCSI can be run in software over a traditional GE NIC, although much better performance is gained by using an optimized iSCSI NIC. When the host system requests reads or writes of data to disk, it would send iSCSI commands across the IP network. The iSCSI commands would be sent to the IP address of a target iSCSI disk array. The iSCSI disk array would process the iSCSI packet(s) and either write to disk or read from disk the requested blocks of data. It is also possible to have an iSCSI host request data reads or writes from a Fibre Channel storage array, but this requires an IP storage switch to do wire-speed conversion of the iSCSI requests into corresponding Fibre Channel requests.

In short, for the layman, iSCSI simplifies storing or retrieving of blocks of data by using familiar, well-understood IP networking protocols and infrastructure and traditional SCSI commands.

25. Are there certain applications that are better suited to iSCSI instead of Fibre Channel and why? What sort of implementations can we expect to see iSCSI turn up first?

If Gigabit Ethernet had been the first gigabit serial transport, SANs today would already be based on iSCSI or something very similar. Historically, however, Fibre Channel was the first successful gigabit transport and so satisfied the requirement of a high speed pipe for shared storage solutions. Gigabit Ethernet was subsequently built on the advances made by Fibre Channel (optics, data encoding, low bit error rate, etc.).

In the meantime, the first SAN solutions in the market have been based on Fibre Channel. Vendors already have solved many of the problems associated with block data transfer over gigabit links, how to encapsulate SCSI commands, status and data, high performance switching, and so on using Fibre Channel. Does that mean that Fibre Channel is a better solution than Gigabit Ethernet and IP? No, it just means that Fibre Channel got there first.

Thanks to all this hard work done by Fibre Channel, IP SAN technology has been able to identify and avoid many of the issues that have surfaced with SANs. In this respect IP storage has a double benefit: IP is the 20-year incumbent in data communications, and it can opportunistically benefit from technical advances pioneered by Fibre Channel. From a technical standpoint, iSCSI is always better suited for shared storage solutions because it easily integrates into networks customers have been building for quite some time.

The product reality, however, is that storage arrays today are Fibre Channel-attached. Connectivity for host systems is now based on Fibre Channel HBAs (although that will change this year). So if I want to deploy an enterprise-class SAN solution today and use the best-in-class products available, quite a few of those will be Fibre Channel. iSCSI may be the best technical and supportable solution, but Fibre Channel necessarily plays heavily in practical solutions.

Since this is the state of things, a clever vendor would attempt to provide solutions that maximize use of IP, still allow attachment of Fibre Channel end devices (or even fabrics), and offer a migration path to iSCSI. We will have a showcase customer we'll be announcing soon that is building an IP SAN infrastructure with Nishan switches at the core, and using Fibre Channel hosts and Fibre Channel targets at the edge. This customer will also have the flexibility to integrate iSCSI NICs on hosts in the same heterogeneous IP SAN. This configuration does everything a Fibre Channel fabric does, but eliminates the Fibre Channel fabric issues.

We are also seeing iSCSI solutions that focus on host attachment using iSCSI. This eliminates the issue of having each host run by FC to a FC switch. The host can now attach to a standard Gigabit Ethernet switch anywhere in the network. The prerequisites for this type of implementation have been (1) low overhead iSCSI NICs with wire-speed performance and (2) wire-speed conversion of iSCSI to FC in an IP storage switch. As we demonstrated with Alacritech a few weeks ago, those prerequisites have been met.

As for economic considerations, anything that uses technology the customer already has in place and has support mechanisms for will contribute to lower TCO. It is expected that iSCSI NICs will be cheaper than HBAs, but I don't think that is the compelling argument for iSCSI SANs. Customers can leverage Gigabit Ethernet core networks, which are about half the per-port cost of FC switches. Customers can use their existing IP certified staff (again, lower cost than FC fabric experts). Customers can use the available services for Gigabit Ethernet and IP pipes (GE, ATM, SONET, etc.) for storage traffic over distance. For advanced services such as QoS and security, customers can use readily available IP offerings and not have to pay a premium for still proprietary FC equivalent services. Collectively, these advantages result in better economics (further enhanced as iSCSI solutions proceed down the food chain).

26. Are there certain SAN applications that are better suited to Fibre Channel instead of iSCSI?

Fibre Channel is better as the storage array interface, simply because that's what's available today. As for storage applications, I can only think of one application - high definition video - that really leverages the use of 4Gbps Fibre Channel for the host connection. So today, Fibre Channel may be a better solution for post-production editing of HD video. For almost all other storage applications, it's now possible to build two thirds if the SAN with IP (iSCSI hosts + IP storage switches) and use Fibre Channel at the storage interface.

27. Can they two protocols (Fibre Channel and iSCSI) be complementary or will they - by nature - cannibalize each other? How?

The approach is to take the world as it is and use Fibre Channel and iSCSI in a complementary fashion.

In the long term, however, even if Fibre Channel becomes more affordable and resolves its lingering interoperability issues, iSCSI will gradually surpass it. Why? Because customers will always gravitate to solutions that are more familiar, more manageable and do not require (expensive) expertise.

The transition from FC SANs to IP SANs may take several years, and I'm sure the FC vendors will still make a lot of money in the meantime, but market forces eventually will move SAN solutions to mainstream IP networking.

28. Is there an even better way to network storage? What? When will it be available?

If there is, it's in deep, deep stealth mode. However, as with Fibre Channel, even if it offers some exceptionally brilliant means to access shared storage, a new technology would have to deal with the acquisition, support, scalability and extensibility issues. I think 10 Gbps Ethernet will pretty much steamroller all other transports. To be competitive in the market, a new whiz-bang technology would have to call itself Ethernet.

29. Can iSCSI be successful at 1Gb speeds? If so which applications are we likely to see running it? If not, when will 10 Gb iSCSI be available?

Yes, most storage applications don't utilize a full gigabit of bandwidth (tape backup, for example, one of the most widely deployed SAN solutions, only uses ~15MB to 20MB per stream).

I think the Fibre Channel vendors pushed to bring out 2Gbps on the hopes that "speed sells" and because it involved minimal engineering effort (compared with bringing out 10Gbps FC). The video post-production market is the prime beneficiary of 2Gbps Fibre Channel. For most other SAN applications, it's overkill.

iSCSI is already able to benefit from existing 10Gbps Ethernet interfaces being offered by Foundry and others. Where you need that bandwidth currently is for inter-switch links. 10Gbps Ethernet lets you build high performance core networks which fan out to 100s of 1 Gbps device links. I can build this core today and support 100s or 1000s of hosts and storage devices, with the hosts using iSCSI adapters, and the targets front-ended by IP storage switches.

As customers drive storage consolidation to the next level, it'll make sense to have 10Gbps Ethernet interfaces on very large storage arrays to service higher populations of hosts.

30. Aren't Fibre Channel networks inherently more stable than IP networks (e.g., the Internet)?

Whether using Fibre Channel or IP for SANs, someone has to design the network, insure integrity of links, allocate and monitor bandwidth utilization, etc., depending on the upper layer application being run. I've seen some very poorly designed Fibre Channel SANs that suffer excessive retransmission due to inferior components, improper sizing, or simple ignorance of the technology.

Having the ability to transport block storage data over IP doesn't mean that people should expect to throw their mission-critical storage data onto any IP link or onto the Internet. Basic network design rules still apply. For local applications, Fibre Channel and Gigabit Ethernet share the same base technology and both have extremely low bit error rates (typically 10^-12 or better).

For properly designed IP SANs, the customer has several choices for deployment. One solution could be to simply devote an entire IP network infrastructure to storage, replicating what Fibre Channel does in terms of physical separation. Even then, the customer would have to understand how much bandwidth is required for specific storage applications, what a reasonable server-to-storage ratio is, how many interswitch (trunked) links should be provisioned, etc.

In this segregated scenario, the customer would still have QoS options available that are not yet standardized in Fibre Channel. For example, online transaction processing can be given higher priority (via 802.1p/Q or DiffServ) over backup streams, so that mission-critical storage business data always receives preferential treatment.

Alternately, a customer does have the option to use part of an existing IP network for both messaging and storage data. If I have extra ports or blades on my Gigabit Ethernet core switches, I might reasonably use them for storage. In that case, I might want to use VLANs to separate traffic flows so that my messaging traffic never sees storage traffic. Customers are already doing this to separate departments that are plugged into the same core switch. It assumes that the customer has the IP staff to configure and monitor such a configuration, but typically mid size and large customers do.

In Fibre Channel, all traffic is equal. There is no way to prioritize one stream over another. With IP, we have several options for doing this, both to provide QoS for different types of storage traffic and to provide QoS for storage traffic in general over messaging traffic for mixed configurations. This assures stability for the upper layer storage applications.

I agree that some vendors have over-sold the idea of throwing storage data on any IP network infrastructure. Nishan, however, has been working with enterprise-class end users that are either dedicating IP segments to storage or have the IP resources to provide support for advanced QoS features in their Cisco, etc. switches and routers. In addition, provisioning services from a competent ISP that can implement QoS and security/encryption options makes it reasonable to use Internet links.

31. What is an iSCSI TOE?

An iSCSI TOE is a TCP/IP Offload Engine that takes away the CPU processing of the IP and SCSI packets and handles them on the HBA. Certain systems can also boot from a TOE card directly to the storage. If you require to boot from a TOE you do not need any disk drives to reside in your server.

32. What does iSCSI do?

iSCSI provides block-level disk storage to servers or clients on a network. This storage appears to the servers as local disk and as such applications can be loaded and run normally.

33. How easy is it to serve up disk storage?

All of the disk storage resides on the iSCSI Appliance. This appliance can see all of the available disk that it can serve up. Once you have loaded the initiator drivers or installed TOE cards. It is just a simple matter of mapping the Server Name to the iSCSI Appliance and giving the server disk. The user then needs to go to disk manager and format and partition the disk as if it were local.

34. What would happen if my server being served iSCSI disk crashes?

Normally it would involve restoring tapes and previous backups to bring a server back. With iSCSI the disk does not reside locally, therefore it is remote. All you need to do is re-map the iSCSI disk to another server and the data will be intact as if nothing happened.