Now that you have the basics of how to create a volume on an iSCSI target and mount it for use, let’s explore some reasons for doing so.
Server Storage
The simplest case I will present is a single SBS server. There are several important data stores for SBS:
- Exchange Server
- SharePoint
- Shared folders
- LOB or other data that is used by SBS members
When you first install SBS, these are all going to be located on the OS drive. Using the SBS console, you can migrate them to another drive location. In the case of LOB data, which is set up independently, you no doubt can chose the drive on which to locate it.
You could start with disks installed on the server in a traditional fashion. Maybe the drives are 500GB, 1TB, or larger drives. Your Exchange requirements might be modest, say 15GB. You estimate that SharePoint files are likely to grow to 20GB in the next six months to a year. Shared folders might start at 20GB but could go up or down depending on what migrates to SharePoint, for example, and what other growth you anticipate.
You can use one drive for Exchange, one for SharePoint, one for shared folders, and one for LOB data. But perhaps your server can’t accommodate that many drives. And it certainly might not accommodate them as RAID 5 or 6 volumes and be independent of each other. What are the choices? Well, you could use one physical disk, no RAID, and create several volumes and use different ones for different data types. Or perhaps use several drives to create a RAID set and and allocate volumes on it.
Now that you have several volumes on your drive or drive array, sized to accommodate the data you anticipate, what happens if you start to run out of space? If you have a partition management software tool, you could expand the size of the allocation if there is more free space on the drive(s), or shrink another partition if that were possible and then increase the size of the desired one. Or, if you have the space available, create another larger partition and move the data to the new one.
Using iSCSI targets is similar to this approach but without the drawbacks and pitfalls of locally attached drives. First, your storage platform is robust and will have RAID enabled drive support. Since mountable drives are created from an available pool of space, you can start with the most reasonable size for each disk you need. Later, you can, on the fly, create a new iSCSI target that is larger or smaller, move or migrate the data to it, disconnect the original target and then delete it. It is far easier than partition management.
Don’t forget backups. You can create an iSCSI target and mount it on the SBS server and then configure backups to this drive. Need another destination? Very simple. You get the idea.
Virtual Machines
You probably know from reading some of my other posts I am a fan of virtual machines. I like the idea of running SBS as a Hyper-v machine; the same box can support test machines, client machines used for remote access, special LOB servers, you name it. In a virtual machine environment, iSCSI shines.
Start with the drive on which you store the .vhd files. These can be on a locally attached or a iSCSI drive. I use iSCSI because I can allocate a right-sized disk in a matter of minutes and have it available on the host server. Once the virtual machine is created, I can allocate and attach additional iSCSI targets to meet the needs of that vm.
Consider that you might want to test some new software or application, such as a web site, SharePoint feature, or LOB application. Create a virtual machine and allocate the disk space it needs. If it turns out to be incorrect, or once your testing has been completed, it is a simple matter to delete the iSCSI targets and return the disk space back to the available pool.
Note a potential disaster recovery scenario. If you were to lose the host server, the .vhd for the virtual machines would still be on the iSCSI target. Simply use them to create a virtual machine on another host, and you are back up and running.
Testing
Admittedly, I stole some of my own thunder when talking about virtual machines, but the testing environment is perfect for iSCSI. Just allocate a target, use it and then delete it once the testing is done.
But it is not just for server and server-level software that iSCSI is useful in testing. Suppose you want to test from your desktop. Guess what. Windows 7 has the same iSCSI initiator, and you can download one for XP. That means you can create disks, use them and subsequently delete them at the client desktop as well as at the server.
Ad Hoc Uses
I have also used iSCSI targets for quick, one time efforts. I wanted to update the OS on a laptop for a friend, and I wanted to end up with a clean install but make sure I didn’t lose anything important. The trouble was that my friend couldn’t tell me what was important…. So I removed the laptop drive, connected it to my desktop with a USB drive connector, copied it completely to an iSCSI target I created, put the drive back in his laptop and installed the new OS. There were a few things to go back and retrieve, but once he was satisfied I simply deleted the drive.
I will often be called upon to change something at an installation. I usually create an iSCSI target, do an appropriate backup (sometimes it is just copying files, other times, a more holistic backup), then make the changes. Getting back to the original state if something goes wrong is neat and tidy; so is the deletion of the disk once I am done.
Less Common But On My Wish List
Recall from Part I that the SCSI commands to read and write data are sent over the network to the target device. Theoretically, it doesn’t matter whether the network is local or very WAN. Practically, it is how long it takes for the commands and data to get back and forth.
Here is where I think cloud backups might go for some types of transaction-sensitive data. Suppose you have a database that gets updates continuously from user transactions, web traffic, etc. If that data were stored on an iSCSI target, remember that the data and commands to read and write it travel across the network. Now imagine that the iSCSI target machine, when it gets a write command, also sends that command with the data to another iSCSI target, a mirror, that is remote, i.e., the cloud (public or private). The difference is that the local target can respond back to the server that the write is complete, but there are no such time constraints on the write to the cloud. The iSCSI target would have to create a queue of writes and execute them in order as they complete asynchronously to the writes it completes locally. This is not unlike playing a log file against a database.
Because only writes need be executed across the WAN, this is a very efficient operation and with broadband speeds continuing to increase, such a scheme because a very practical continuous backup procedure.
No solution like this is commercially available that I know of, and it would not be appropriate for every application. Nevertheless, you heard it here first if it does come to pass.
I hope this gives you a flavor of the convenience and wide range of uses that iSCSI provides. In Part III I will discuss the costs and purchasing of a unit.