ISCSI SAN technology is changing the economics of SAN affordability. Not only is Fibre Channel SAN technology expensive, but deploying and managing it is complicated. This has made SANs impractical for small and medium-sized businesses (SMB), and even enterprise data center budgets limit the number of servers or storage systems that can be added to a Fibre Channel SAN.
But iSCSI changes all that, supporting block-based SAN using existing Ethernet technologies that are far less expensive, not to mention more broadly understood by IT professionals. Today, countless small and medium-sized enterprises are adopting iSCSI, and large enterprises are deploying iSCSI SANs for remote offices, workgroups and departments.
Still, iSCSI can coexist with Fibre Channel SANs through the use of iSCSI routers or bridges to connect the two architectures. This coexistence of iSCSI and Fibre Channel may be intriguing to large organizations that have invested in Fibre Channel infrastructure but plan to adopt iSCSI over time.
Here are eight best practices for iSCSI SAN deployment and integrating iSCSI with Fibre Channel.
Best Practice No. 1: Weigh the need for iSCSI vs. Fibre Channel
While iSCSI does provide notable benefits for SAN users, not all users will benefit equally from iSCSI in their enterprise. Even though iSCSI is almost always cheaper than Fibre Channel and usually performs as well, that doesn't mean iSCSI is always appropriate. "If I had Fibre Channel built out, there's probably not a lot of value in adding iSCSI," says Phil Goodwin, president of Diogenes Alylitical Laboratories.
Still, there are many cases when iSCSI would make a smart add-on to an existing Fibre Channel storage infrastructure, such as deploying a large number of low-end host devices. "If you really want Fibre Channel, but you also have 100 Windows servers that you need to add to the SAN, and you (can't afford to buy all the Fibre Channel host bus adapters (HBA), then use iSCSI," says Stephen Foskett, director of data practice at Contoural Inc. The trick is understanding the role that iSCSI will play in your particular environment, weighing the management demands and determining if there's adequate justification for "blending" the two SAN technologies.
Experts also note there is a point of inflection for both iSCSI and Fibre Channel SANs. Although it's probably not worth adding iSCSI for just a few devices, it might make economic sense to replace small Fibre Channel deployments, especially those not providing critical performance benefits for key applications, with iSCSI to create a single fabric, rather than preserving two SAN types in the business.
Best Practice No. 2: Don't assume Fibre Channel outperforms iSCSI
Some companies avoid iSCSI because of its reputation for so-so performance. But in actual practice, Fibre Channel and iSCSI are equally capable of supporting the same block-based applications. According to research from Enterprise Strategy Group (ESG), half of the early adopters of iSCSI are using it for mission-critical applications -- a strong statement of support for iSCSI reliability. Only the most bandwidth-intensive applications might push Ethernet into a bottleneck. These include OLTP applications that handle a large number of small transactions and could suffer a performance penalty due to packet overhead in the IP environment.
Best Practice No. 3: Don't hold off for 10 Gbps Ethernet
Some IT professionals are delaying the adoption of iSCSI until 10 Gbps Ethernet is readily available. The assumption is that the added bandwidth promised by 10 Gigabit Ethernet (GigE) will improve iSCSI performance. But since iSCSI adopters are already seeing adequate performance using the current 1 Gbps connectivity, moving to 10 Gbps would have little effect on application performance. There's no need to wait on 10 GigE. You should probably evaluate iSCSI even if there's no immediate need for it.
Best Practice No. 4: Consider the use of TOE HBAs for iSCSI
Although iSCSI can be deployed using conventional Ethernet NICs and switches, you might want to consider more specialized iSCSI SAN NICs and switches. The latest generation of NICs include a built-in firmware-based initiator and may incorporate TCP/IP Offload Engine (TOE) capability. A TOE performs much of the iSCSI command processing directly on the NIC, improving iSCSI performance by offloading low-level processing tasks from the host's main CPU. You can also use Ethernet (iSCSI) switches with high-performance low-latency ports to improve data transfers across the iSCSI SAN.
Best Practice No. 5: Take iSCSI security into account
Contrary to popular belief, iSCSI SANs can be more secure than Fibre Channel SANs. For example, iSCSI establishes security through advanced authentication methods, such as CHAP. According to Foskett, CHAP is "a much more secure method" and is "super simple to set up because people have been using CHAP in the IP world for a decade."
The authentication protocols native to Fibre Channel are rarely used. Many SAN architects instead rely on the relatively isolated nature of Fibre Channel fabrics and the complexities of LUN zoning and masking to keep SAN data secure. Furthermore, Fibre Channel does not support native encryption over the wire, but iSCSI can utilize IPSec encryption to protect data in flight.
One weakness of iSCSI security lies in the proliferation of Ethernet networks. It's a bad idea to pass storage data on the same network that handles everyday user traffic because your secure SAN data can "leak out" over the LAN ... possibly onto the Internet.
As a result, network designers must isolate iSCSI SAN data from Ethernet user data. One way they can accomplish this is by building a different LAN dedicated to iSCSI use, but it's usually more practical to partition networks logically. For example, you could establish an iSCSI SAN using a VLAN, which carves up the physical LAN into a logical portion used exclusively by the SAN. This allows storage administrators to regulate and guard the traffic that the VLAN carries.
Best Practice No. 6: Look for mature initiators
Most network activities are operated and directed through software drivers. In the iSCSI realm, the drivers that reside on host servers are known as initiators. Their performance is often limited by poor coding methodologies or inadequate testing. Experts suggest that you use mature initiator software from the NIC vendor or a recognized source, such as Microsoft.
You can also rely on the firmware that is hard-coded into iSCSI NICs, such as Alacritech Inc.'s SES2100 Accelerator card, the Magic 2028-4P 1 Gb Copper TCP/IP Accelerated NIC from LeWiz Communications Inc. and the QLogic Corp. QLA4050C iSCSI HBA. The coming shift to 10 GigE may require the use of hardware-based initiators.
Best Practice No. 7: Make sure virtualization software supports iSCSI
It's common to see iSCSI performance bottlenecks in virtual servers. Even though you can easily add more virtual machines to a physical server, you're stuck with the same amount of server resources, such as CPU, memory and I/O. Many virtual machines demand significant storage access, so virtualization should maximize the utilization of your iSCSI NICs, particularly TOE cards.
However, make sure that the virtualization software fully supports iSCSI. Foskett reports that current VMware versions do not currently support iSCSI HBAs. This issue should be resolved soon, but in the meantime, there are no real workarounds to this type of problem except to employ Fibre Channel in the virtualized environment.
Best Practice No. 8: Embrace iSCSI's new storage management features
Vendors are incorporating ambitious feature sets into new iSCSI products that may not have been affordable (or even practical) in comparable Fibre Channe products. This new period of iSCSI creativity is spawning integrated features, such as thin provisioning, subdisk RAID and automated tiered storage, which are a real boon for iSCSI SAN adopters.
In addition, iSCSI arrays are also noted for their scalability, making it easy to buy and deploy additional iSCSI arrays over time with little, if any, direct management.
iSCSI vendors: Fibre Channel over Ethernet (FCoE) purely defensive
Learn all about iSCSI and Fibre Channel SANs
Locking down an iSCSI or Fibre Channel SAN
Users leaving Fibre Channel for iSCSI SANs find pros, cons