An astute TechRepublic reader followed up on a recent post about SAS, SATA and iSCSI storage arrays with some additional questions. Below are my answers to each one.
When iSCSI is used, how is the data encapsulated on the Ethernet?
In this case, a picture really is worth a thousand words, so take a look at Figure A below. In it, you can see that iSCSI operates on the Session layer — layer 5 — of the ISO OSI model. In order to be able to chat with other devices using iSCSI, the SCSI commands that are generated at the presentation layer ultimately need to make their way down to the physical layer. The diagram explains what happens at each layer.
Figure A
A look how how iSCSI packets are encapsulated
Is there any encryption or is this not an issue? If we have been hacked, can the iSCSI data flow be intercepted and used in any way, or is this a moot point because of the complexity of the data streams, particularly if there are multiple iSCSI initiators?
On its own, iSCSI traffic is not encrypted, but that doesn’t mean that it’s impossible to protect iSCSI traffic from prying eyes. Many consider isolating iSCSI traffic to be a best practice. That means that the iSCSI traffic gets its own dedicated network – either using separate physical switches or a dedicated, non-routable VLAN – on which to operate. As mentioned, this network is not connected to any other.
Most iSCSI systems also support the use of the Challenge Handshake Authentication Protocol (CHAP). By using CHAP, iSCSI initiators are forced to authenticate using the CHAP secret before they are granted access to the iSCSI target. In some cases, you can also configure an iSCSI target to respond only to initiators that have certain attributes, such as:
- Specific iSCSI World Wide Name (WWN)
- From a specific IP address
If you want to encrypt the iSCSI traffic – the ultimate and best protection from snooping – you can implement IPSec for the iSCSI traffic. This is a good article about that practice.
In a virtualized environment, I’m assuming that each virtual server has its own iSCSI initiator loaded, or can it share a single instance on a single hardware server?
When you’re running systems in a virtual environment, such as under vSphere or Hyper-V, it’s generally recommended that the hosting server – the actual vSphere or Hyper-V host – maintain the connections to the iSCSI storage. From there, the hypervisor handles what connects to the storage. It’s common, for example, to place virtual machine files, including virtual machine hard drives, on the iSCSi storage. When this configuration is in place, the virtual machines themselves actually have no idea at all that they are using iSCSI storage. To them, it is just local storage.
That said, it is possible to install an iSCSI initiator from inside a virtual machine and connect that virtual machine to a separate iSCSI target. When you do that, only that specific virtual machine will see the iSCSI connection that was established. Be aware, however, that doing this can introduce performance issues for that virtual machine since that virtual machine then needs to handle all of the encapsulation activities using its own virtual processors.
It appears that inexpensive 10GbE switches and adapters are now on the horizon. When do you think 10GbE will be the standard?
The implementation of 10 GbE networking equipment is becoming more and more common as prices come down. Larger organizations have been implementing 10 GbE gear at their cores for quite some time. This trend will continue down the spectrum as more SMBs find needs to implement ever faster networks. I believe that storage – both iSCSI and Fibre Channel over Ethernet (FCoE) will drive this trend in the data center; storage performance has become an Achilles’ Heel for many. If I had to guess, I’d say that 10 GbE will be the standard in data centers in the 2014 to 2015 time frame, at least for new implementations. It will still take some time to clear out legacy 1 GbE connections.
