While iSCSI might have the little "i" so common in Apple’s naming schemes, it has nothing to do with Mr. Jobs. In this case, the "i" stands for "Internet." SCSI (Small Computer System Interface) is an interface used for connecting PCs to peripherals such as hard drives. SCSI is nothing new. It’s been around for a long time. It is, in fact, a preferred choice for production environments because of its performance. iSCSI adds a new dimension to the SCSI interface. It allows the SCSI commands to be sent via existing network cabling. What does this mean? It means that you can easily create a SAN (Storage Area Network) using your existing network infrastructure. (A SAN is an integral part of a clustered server setup.)
How Does it Work?
iSCSI requires the installation of a special piece of software, called an initiator, on the host machine. This allows the host to accommodate incoming iSCSI commands. Microsoft has released a free download for Server 2000 and Server 2003. Server 2008 comes with the iSCSI initiator included out of the box. The initiator, installed on the host, initiates and receives requests from the iSCSI target via the IP network.
In Plain English, Please?
It sounds more complicated than it is. The host machine (running the iSCSI initiator) is connected to your network. It sends special network traffic to the target machine (where the iSCSI devices are installed) to access the storage devices. The data being written to and read from the drive is encapsulated within that network traffic and sent back to the host machine. In essence, it’s like having a really, really long drive cable connected from your host machine to your target machine. Since it all runs over TCP/IP (which is the same protocol used by most web traffic), there’s no need to install specialized networking gear to make iSCSI work.
It Sounds Too Good to Be True!
Like a lot of innovative technology, this does sound too good to be true, which doesn’t stop it from actually being true. Considerations must be taken to ensure that the performance of your iSCSI SAN meets your needs and expectations. While you don’t need specialized networking hardware, you do want to use high-speed dedicated hardware for the SAN. This means gigabit Ethernet cards in your target and host machines. (This gigabit card should be in addition to the existing network card being used to access the public/internal networks.) Having such a card dedicated to the SAN traffic will help you achieve optimal performance. Isolating the SAN traffic onto a private network will also help boost your SAN’s performance. Dual processors are also recommended in all of your iSCSI hosts.
Security is also a concern. By default, no security protocol is in place for IP traffic, even that being carried over an iSCSI connection. This is an obvious concern. Fortunately, CHAP and IPSec can be used to maintain security of your data being transmitted. CHAP is used as a negotiation between the host and target. If the host and target both know the secret password, the connection is established. If not, the connection is terminated. This prevents unauthorized machines from accessing your data via a direct connection, but does not protect your encapsulated data while it is in transit. For that, IPSec is required. IPSec is a security method which can be implemented on your iSCSI network to encrypt the traffic as it flows from point A to point B, protecting it from people attempting to intercept it.
SAN and Clustering
Clustering servers requires that they have access to the same shared storage. If we go back to the diagrams from the last post, we can see that centralized storage is an integral part of the clustering scenarios I outlined.
The SAN allows both clustered servers to access the data being written. If the storage were local to one of the servers and that server failed… you can see where that goes. It renders your cluster ineffective. Thus, centralized SAN storage becomes imperative to redundancy.