Posts Tagged ‘iSCSI’


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.

 

Advertisements

I have become a huge fan of iSCSI for use with SBS.  If you are not familiar with iSCSI, this first part of my posts will give you an overview of what it is and does and how it can be used.

iSCSI stands for Internet Small Computer System Interface.  SCSI has long been a favorite for high performance and reliable disk storage for servers.  There are several reasons for its popularity:

  • SCSI controllers almost always had RAID implemented to protect against single or even multiple drive failures.  Extra information was stored across the disk volumes to make certain that all the data could be recovered by replacing the errant disk.  Hot swap is also common, meaning that a drive could be replaced without stopping the system.
  • SCSI offloaded many of the processing tasks associated with reading and writing data to the controller rather than having the computer’s processor do all the work.
  • Data transfers from the device to memory were more efficient and often very much faster than for standard access drives.
  • SCSI disks themselves were often more rugged, faster and reliable than standard disk drives.

With high speed networks becoming not only the norm but very affordable, and with the need for shared storage among many servers, iSCSI came into vogue.  The controller and drives were now located in a separate box, and the commands to read and write and otherwise process the stored data were sent over the network instead of over a local bus.  Data to be read or written also travels over the network, and is done so with excellent efficiency.

Removing the disk drives from the server itself offers a great deal of flexibility.

  • It no longer matters where the server and controller/drives are located.  They can be next to each other, in different rooms, or across the country or world; response time and performance are still considerations, however.
  • Multiple servers can access the iSCSI device by using their network connections.
  • Servers “see” a disk on the iSCSI device as an allocated volume.  Volumes can be assigned from among a pool of drive space, and the remaining drive space can be used for other volumes on the same or different servers.
  • You can quickly create a new volume and hence drive for a special purpose on a server then as quickly delete it once you are done.  Think testing, making copies, and so much more.
  • iSCSI devices can be managed separately from the servers they provide storage for.

You might be tempted to ask, isn’t that just what a NAS device does?  The answer is no.  NAS devices provide file level access.  The server sees the files as a share, not a disk device.  While this may not strike you as being important, it certainly is critical for things like Exchange databases.  Exchange does not support storing data on NAS devices but does for iSCSI devices.  And for virtual machines, you are going to want to assign them drives, not folders.  More about virtual machines later.

While this is not an exhaustive list by any means, it will probably get you thinking about how cool it would be to have this flexibility for particular situations you have found yourself facing before.  So why don’t you have iSCSI already?

Historically, the answer was oh so simple: cost.  Storage area networks with iSCSI were outrageously expensive and could only be justified in some of the most business critical scenarios.  Think hundreds of thousands of dollars.  But after a while, the price came way down.  To tens of thousands of dollars.  Not exactly the budget range of most SBS installations.  If you are one of them who could afford it, please do call me, though, as I know we can work a deal.

Today, you can purchase a small iSCSI system for about the same price as a medium-sized NAS device.  As the size of an iSCSI system increases, you are going to pay about $800-$1500 more for the device over the cost of the individual disks.  Let me assure you that it is money very well spent.  I suspect you will save around half of it by more efficient use of your disk space.  I will have another post on selection and cost.

Well, cost aside, you might say, it is probably difficult and technically challenging to set up and use an iSCSI device.  Not at all.  Support for iSCSI is not only built into SBS, it is also built into Windows 7, and you may have occasion to use it with client computers in your environment.  I admit to having done so by needing a test or copy disk, which I allocated and attached in less than a minute.  It takes me longer to go grab a USB drive and plug it in.

While it may not be universally true of all iSCSI device manufacturers, many have provided great web based interfaces that are intuitive and easy to use.  When you first install the device, you have a few general tasks to do to get it ready to use.

  1. Set up the network connection.  Assign IP address(es) to the network adapter(s).
  2. Setup credentials.  Hopefully, your device will support the domain AD credentials, and it is a simple matter to provide the administrator credentials for the device to access AD.
  3. Initialize the storage for iSCSI if the device does not do it automatically.
  4. Create one or more iSCSI volumes.

To calibrate this effort, if you are not familiar with the interface, this might take 15 minutes.  If you are, maybe 3-4 minutes.

Once you have done this, turn your attention to the server.

  1. From the start menu, accessories, chose iSCSI Initiator.  You will see
  2. Enter the IP address you set up for the iSCSI device into the Target box and click Quick Connect.
  3. The targets will appear.
  4. Highlight the volume you want to use and click Connect.  The status should change to Connected.

That is how hard it is to get the iSCSI work done.  Let me repeat.  That is how hard it is to get the iSCSI work done.

But there is still the issue of making this volume a drive on the server.  To do that, you need to open Server Manager.  Once you have, click on Storage to expand, then click on Disk Management.  You should see something like this:

Note the unallocated disk at the bottom.  Right click on the Disk 7 (or whatever yours shows) area, then chose Initialze Disk.  Accept the defaults and click ok.

Now right click inside the disk space, create a new simple volume.  The wizard will let you assign a drive letter and to do a quick format. Once you are done, your disk is ready to use.

The next part of my iSCSI posts will discuss some practical situations on how to use it for a variety of applications and special circumstances.