Looking for something else?
ISCSI storage area networks (SANs) are frequently touted as a solution for small-midsized businesses (SMBs) moving to networked storage. But, why not just use Fibre Channel? Terri McClure, analyst with Enterprise Strategy Group, discusses the pros and cons of iSCSI SANs, the iSCSI SAN market and whether iSCSI SAN solutions are really a good fit for SMBs.
When you start looking at iSCSI versus Fibre Channel (FC), the barriers to adoption are very low for iSCSI. It really comes down to three things; cost, operational savings and existing expertise. With iSCSI, there is a lower capital investment upfront. The cost of FC switches and HBAs remains significantly higher for FC than it does for iSCSI.
A typical SMB has IT employees wearing multiple hats. Networking administrators know IP networking and they can translate that knowledge easily to support an iSCSI SAN, so you've got the existing expertise already in-house. You can gain significant operational savings because your information is moving over an IP network. It is not necessarily the same network, but it is the same type of network and that simplifies your management, training and gives you personnel transferability.
It's more affordable than a Fibre Channel SAN. When you step back and look at the big picture, if all storage is directly connected, it is stranded and can't be leveraged. Say you have two servers. If server A runs out of storage capacity and server B has a bunch of excess storage capacity, in a direct-attached environment you can't leverage server B to help out server A.
So, in any networked environment, Fibre Channel or IP, you gain economies of scale and free up all stranded storage. And that is what really makes iSCSI SANs affordable; the gains in storage consolidation and utilization. You don't have stranded, unused storage capacity directly attached to storage. And because utilization rates are better, there are typically fewer storage array requirements.
So, you're reducing your footprint, you're saving on power and cooling, management costs are lower and you're probably saving on software licenses as well. An iSCSI SAN could pay for itself in a few short years thanks to operational savings from your storage consolidations. Plus, you get an operational benefit from leveraging your IP network administrators on the storage side.
Everything has its tradeoffs. An iSCSI SAN should not share a network with regular network traffic. The data transfer takes up too much network bandwidth and it will impact application performance. So, there is some upfront investment in networking equipment. SMBs typically have small IT groups, so you have the pain and agony of adding yet another IT project to a group that is probably close to maxed out.
There is some minimal CPU overhead in packetizing the SCSI blocks and you've got some TCP/IP overhead, but if it's configured correctly, the overhead, packetizing and network latency should be transparent to end users. In fact, ESG recently did some research and found that 87% of early iSCSI adopters were satisfied with their iSCSI application performance. Seeing that satisfaction rate among current iSCSI end-users should help dispel the performance concerns of any potential customers.
However, there is one notable exception that has to be considered with iSCSI performance, particularly with backup. Backup is bandwidth intensive, so you should look at that separately. It is typically bandwidth intensive and single threaded, so system administrators should evaluate the impact on network performance compared to a Fibre Channel, SAN and iSCSI.
A virtual LAN, or a VLAN as it is often referred to, is a virtual network of servers that are not co-located like traditional servers. They could even be on different network segments, but they are bound together by software as if they are co-located on the same segment.
So when you are creating an iSCSI SAN, you can create the same efficiencies for a VLAN as you can for a co-located SAN and what you are really doing with the VLAN and iSCSI SAN is creating a virtual datacenter spread across the network cloud. With a VLAN, you still need to separate your storage traffic from your regular network traffic, but it becomes your virtual datacenter.
You've got your usual suspects; EMC, HP, and IBM. All of those vendors have rolled out targeted efforts to gain space in the SMB share. You've also got NetApp, known as a leader in NAS, who supports iSCSI block data and file sharing in the same array.
Many major vendors now support shared block and file storage in the same array. For SMBs it's really important to think about a unified or multiprotocol storage deployment in the SAN, because most small businesses need both block and file data. An iSCSI SAN can be a good solution to optimize an iSCSI storage investment and increase utilization, because so many of them now can serve both file and block-based data.
If an SMB is deploying a virtualization solution, you really need storage networking to get the maximum return on investment. When you think about virtual servers, some of the benefit is to be able to move your virtual machines between physical machines.
To be able to do that, the machines need to be able to see the same pool of disks. If they can't, you are limited in how much you can leverage your virtualization solution. Recent ESG research found that 81% of SMB end users surveyed were planning to acquire new network storage systems to accommodate their virtual server environments. Virtualization is a major driver of SANs because of the benefits of being able to see the same pool of information between multiple servers. So, to really maximize your virtualization investment you have to have a SAN.
I don't think that there is any need to wait.
10 GigE is still pretty expensive compared to 1 GigE. The new Cisco Nexus 5000 switch is still running at about $900 a port. I don't think there is any danger in deploying now with a gigabit infrastructure. You should at least have 1 GigE, but there is no need to wait for 10 GigE.
Terri McClure is an analyst with Enterprise Strategy Group.