Fibre Channel
Fibre Channel – often referred to as FC, is and has been the main infrastructure and protocol used in the storage networking industry since the mid 1990s. Its high speed (multi-gigabit) data rate has been enhanced over the years, allowing up to about 8 gigabits per second today, and twice that rate in the near future.
Not Necessarily Fiber-Optics
One of the biggest misconceptions is that Fibre Channel exclusively used fiber optic cables, or links. While it is true that long distance runs will be carried over optical links, many FC disk enclosures carry the signals over copper cables, or traces on a backplane. Obviously there has to be somewhere that the conversion takes place between optics and copper, and a very common component that does this is the GBIC (GigaBit Interface Converter).
Topologies
There are three basic topologies used with Fibre Channel. These are point-to-point, Arbitrated Loop, and Switched Fabric.
Point-to-point is the simplest, and is exactly what it sound like, where two devices, or nodes, are connected directly together.
Arbitrated Loop is when a series of device are connected in a ring, or loop. This allows multiple devices to be connected and available for use. This is a very common configuration for a JBOD (Just a Bunch of Disks) type enclosure. A limitation of this configuration is that only two node can use the loop at any given time.
Switched Fabric is the most common topology used in enterprise class storage system. This means that a Fibre Channel Switch will be used to connect multiple devices and adds the capability of having multiple communications occurring at that same time. The more ports you have on the switch, the more simultaneous communications you can have. Of course this increases the cost and complexity of the system, but you don’t get high speed simultaneous data flow for free.
There is much more to Fibre Channel than what will fit in a single glossary post, but I will try to add more in the future. Please let a comment if you have specific questions.
Incoming search terms for the article:
Asynchronous Event Notification (AEN)
Asynchronous Event Notification (AEN) - Note: this is now referred to as Asynchronous Event Reporting (AER).
Asynchronous Event Notification (AEN) is a process or procedure that may be used by SCSI targets to notify a SCSI initiator of “events” that occur in the target, when the target is NOT executing an Active Process (a command). An example of an “event” could be a Unit Attention caused by removing a CD or DVD from a player or recorder (medium is removed). These events normally result in a Contingent Allegiance Condition (CAC). Without AEN, the initiator will not know of any events until it tries to send another command, or another command is processed from the queue.
The hard part of AEN involves the target becoming a “temporary initiator” and being able to use the SEND command to tell an initiator about the event. This initiator would also have to become a “temporary target” to be able to receive this report. Since devices rarely change rolls, especially initiators, this is a seldom used feature of the SCSI world.
But the good news is, with the advent of Serial Attached SCSI (SAS), parts of the infrastructure, called SAS Expanders, have the capability to send and receive “broadcasts” – which can be used to notify “management processes” about different types of events. This can be loss of synchronization on a link, a link that comes up or goes down, and the ability to send SCSI event notifications. Expanders usually also contain another function called a SCSI Enclosure Services (SES) device. This can also enhance the system by monitoring things like air flow, temperature, and backplane voltages.
If you have any questions about this just let me know by leaving a comment on this page.
Incoming search terms for the article:
Contingent Allegiance Condition (CAC)
A Contingent Allegiance Condition (CAC) is a SCSI “condition” that exists after there is some kind of problem. What I usually say during class is “these are big words for ‘Hey – We have an error.’ – or some other kind of problem”.
I often find that if you move the words around, it is easier to understand the concepts from the SCSI standards. Here is an example:
A Contingent Allegiance Condition is: a Condition (state) that is Contingent (dependent) upon the Allegiance (connection) between two entities, or components, in a SCSI-based system.
Now for the translation – and I will try to keep it short. In the universe of Storage Area Networking, which is almost entirely SCSI based, the first thing we have to do to be able to issue a command is to make a connection, between the Initiator, through the Target, and finally to the Logical Unit, or at least the code that represents the Logical Unit. Making this connection establishes what is called a Nexus – or I_T_L Nexus. I like to refer to a nexus as a “process ID” – or identifier – for every command within the system.
Since a storage area network, or even a relatively small parallel SCSI system can have multiple initiators, targets, and logical units, it is important to uniquely identify each command, or process, that is sent through the system. That way, we can keep track of all the commands that have been issued and reconnect them back with the original initiator that issued the command.
So that is where the “Contingent Allegiance” part of a CAC comes in – its all about the Nexus, and the connection that it represents.
Now the “Condition” part is simply a “state” that is not considered “normal”. You see, when everything works in a SCSI system, the normal “flow” is:
- Make a connection (establish a Nexus)
- Issue a command (from initiator to target)
- Process the command (Target moves data to or from storage, if needed)
- Receive GOOD status (00h code)
- Close the connection (Nexus “goes away”)
When something goes wrong, then you do NOT receive GOOD status – you most often get back a CHECK CONDITION status (02h code) from the target. This is how the initiator is informed that an error occurred.
The other part you are supposed to know is that the target has generated some sense data, which will explain why the error occurred. And this is where the CAC and Nexus part comes in – the target is supposed to keep the sense information based on the nexus, and that particular command.
What clears this Contingent Allegiance Condition? Normally it is when the same initiator issues another command to that same target and logical unit (remember – its all about the nexus). Usually, the next command is a REQUEST SENSE command, which retrieves the sense data from the device, and it can be decoded by the initiator. Based on this sense data, the initiator should take the appropriate recovery action. What action will the initiator take? The answer is – it depends. It depends on the content of the sense data.
Please let me know if you have any questions or comments.
Incoming search terms for the article:
- auto contingent allegiance
- normal Auto Contingent Allegiance
- contingent allegiance condition
- Contingent Allegiance
- scsi auto contingent allegiance
- auto contingent allegiance condition
- AEN posted for recently logged event
- what is auto contingent allegiance
- auto contingent allegiance scsi
- auto-contingent allegiance condition
Categories: Glossary Tags: SCSI, Sense Data, Status Codes