iSCSI Training Course

I just finished an iSCSI Training Course last week at the Solution Technology Training Facility, and I must say that I had a great time.

First, I want to thank the students that joined me, for their participation and enthusiasm.  When I do SAN protocol training, I always encourage questions at any time, and there were quite a few right from the start, all the way through the last day.

As with many of the iSCSI classes that I do, we start off with where iSCSI comes from (evolution of SCSI) , along with the applications and environments where iSCSI makes sense as a SAN solution.

Then we start to look at how iSCSI is actually “done” – that is, how SCSI Phases, Commands, Data, Messages, and Status are encapsulated into iSCSI Protocol Data Units (PDUs) and are sent back and forth over a TCP connection, to get some kind of work done (storing and retrieving data).  We even go into the details of all the iSCSI PDUs.  That takes up most of the first day, but that is when the fun begins, at least for me.

The “fun” is when we start to look at iSCSI protocol using a protocol analyzer.  In my classes, we use Wireshark, and start by looking at some captured traces that I supply.  We do this so that we can get to know the analyzer and the iSCSI protocol in a controlled way.  We even add color to our traces so we can easily recognize iSCSI activity.  Once that is done, it is time to start building our own iSCSI SAN and capturing ‘live’ traces of what is going on.  This is the basics of what makes up our own iSCSI Lab, which is unique every time we do them.

The iSCSI Lab is made up of one or more iSCSI Initiators, one or more iSCSI Targets, and of course the infrastructure (network) to connect all of the components together.  These components can be hardware, software, or a mix of the two.

Last week, we did a “mostly software” lab, but all of that has to run on computers (hardware).  And like many other labs I have done, there were issues with some of the hardware.  The good news is, we had a chance to do a little debugging and had other hardware that we could use.  As a result, I believe one of the key objectives of building an iSCSI SAN was achieved – that is how to use the information and tools available to debug any issues that may come up.

After a relatively short time, we had the iSCSI Initiator software installed, and the iSCSI Target software installed on working computers.  Then we did a “controlled exercise” to capture analyzer traces as the students attempted to connect and log into the targets.  Again, we were challenged by having basic connectivity (we could ping from each machine), but there were issues with doing the TCP connection and iSCSI Login sequences.  Once again, we used the analyzer traces that we captured to debug the issue and get successful iSCSI Login PDUs flowing between the initiators and targets.

There were a few other challenges, such as Disk Administration and configuration duties, but once that was done we had a working iSCSI SAN where data was moving back and forth across the network.  After all of this “work” was done, we had a great time capturing traces and looking at the differences between different iSCSI Initiator implementations in detail.  I must say that it was interesting to see how different people “do the SCSI thing” in the world of storage.

There were other challenges involving weather, wind, and trees, but that will have to covered in a future post.

Incoming search terms for the article: