An Online SAN Training Course – SCSI-3 Architecture and Commands – is coming up starting July 19, 2010. I am scheduled to facilitate this course (I’m the instructor), which is open to anyone, so if you have the need or desire to attend one of my SAN training classes, please go to the link at the bottom of this page to sign up.
It is NOT free, as this is how I make my living, but the price is very reasonable. But if you enter “Greg – Bonus Item” in the “Notes” field of the registration form, you will receive a “bonus item” along with the most current version of the In-Depth Exploration of SCSI book (the book is included with the cost of the class). Since the book and bonus have to be shipped to you, please sign up early enough to arrive (sorry I didn’t post this earlier).
You can see the details of the course by clicking this link, and I will be able to answer your SCSI related questions using Voice over IP (VoIP), so all you will need is your computer with a microphone connected, and we’re good. You could also call in over the phone, but who wants to do that for 4 days in a row, for 4 hours a day. I also attempt humor and tell “SCSI stories” to get everyone involved, and will be decoding protocol analyzer traces to show how SCSI works, what happens when it doesn’t work (that means decoding sense data), that kind of thing. And of course if you have any specific questions, that would be the time to ask them.
These Online Training classes are usually a lot of fun, and you don’t have to travel anywhere, or for some, you don’t even have to leave your home! Just fire up your computer (with relatively high speed internet), login each day, and we can take a deeper look at how SCSI works.
I hope to “see” you soon.
Click Here to Sign Up for the SCSI Architecture and Commands Training Course.
Secure Registration Form
A Nexus, in the world of Storage Networking is a unique identifier. It identifies the components involved in a command or sequence of commands. It is normally made up of the following parts:
Initiator (I), Target (T), LUN (L), and Queue Tag (Q). This is an ITLQ nexus.
Establishing the Nexus
In parallel SCSI (and most storage systems), everything starts on the host side of the system. When a host wants move some data (do a READ or WRITE) it will need to know that a storage device exists, and then build and send a command to it. But there is another SCSI protocol that takes place to connect and issue the command. That protocol is below.
- Arbitration - initiator ID is placed on the bus (usually #7).
- Selection - target ID is place on the bus and target takes control. At this point, an I_T nexus exists.
- Message(s) – target asks for bytes to identify the LUN and Q-Tag (if needed). This is where the full I_T_L_Q nexus is established.
- Command - CDB is sent to the device, which processes the command and controls the flow.
- Data - this is the data movement phase (IN for READ, OUT for WRITE).
- Status - information is sent back to the host (command worked or had an error).
- Message - this tell the host that the command is done.
Once the command is finished, the nexus is “released” and can be used again. This is because the nexus is only needed while the command is in progress.
Disconnect and Reconnect
The protocol shown above shows a single connection, where everything is done during that connection. But where the nexus really comes into play is when there is a disconnect and reconnect after the command had been issued. This is one of the biggest benefits of “networked” storage. While the storage devices are disconnected, the host can connect to another device and start a different command with it.
The important part is that while a command is still in process (no status yet), the nexus remains and is known to the host. The storage device also can do “slow stuff” while disconnect, such as moving the heads, spinning the platters, that kind of thing. When the device has the data ready (READ), or has resources to accept more data (WRITE), then it will use the same nexus values (I_T_L_Q) and will reconnect to the original host to continue the command sequence. This can happen multiple times for a single command, and the nexus remains until the command is complete.
Categories:
Glossary Tags:
Nexus
Addresses and Identifiers are some of the most important parts of the Storage Networking world. These are the parts of the system that allow use to identify what entity we are trying to connect to an communicate with. If you look at the definition of “nexus” in the SAN, it is all about the identifiers of the components.
Address vs. Identifier
I just want to be a little picky here, for just a moment about terminology. Some protocols will use the term “Address”, when it really should be “identifier”. For example, in networking it is very common to use the phrase “MAC Address” when the MAC is really an identifier. It normally identifies a particular piece of hardware that is almost always at an endpoint or port to a particular device. Addresses, if you think about it, are normally used to tell us how to get somewhere, like looking up the address of a building. But very often there are multiple points-of-entry to a building (or device), so and address only gets us close to where we really want to go. <Picky mode off>
Why Do We Care?
I will often hear the above question about these addresses and identifiers. The simple answer, in most cases, is : troubleshooting! Depending on what interface and protocol we are using, we will be looking to identify what pieces of the system are involved when a problem occurs, what the source and destination device is, and what happened to cause a problem. So if you are asked what devices and pieces of the infrastructure are involved, you need to be able to find that out.
Sample Addresses & Identifiers
Parallel SCSI – Parallel SCSI uses what are called SCSI IDs. These are simply bits on a bus, in the range of 0 (zero) through 15. This bits are used during the connection sequence to select, or reselect another device on the bus.
Serial Attached SCSI (SAS) – SAS uses SAS Addresses. This is a 64-bit address that is used in the connection sequence to start (or continue) communication with another device in the SAS domain.
Fibre Channel (FC) – FC uses Source ID (S_ID) and Destination ID (D_ID) when communicating between devices. These are in the frame header.