In the blog of Vijay and in the podcast of Ronnie Chan a new feature of HyperFlex is mentioned: iSCSI. In this blog I will describe what iSCSI is. I already made a blog about iSCSI Target and Initiator Configuration and even a config of iSCSI QoS Nexus (2014 post, so things can be changed.)
What is SCSI
Before I start with iSCSI, you must know how it all started. It started with Small Computer System Interface or SCSI. This is a protocol with Commands and Data for a computer to devices. It is not a protocol just for storage. You can connect all kind of SCSI devices to it.
Back in the days you could have a computer with a SCSI controller with a SCSI bus. Here you could attach a SCSI Cable to it.
On the cable you could have multiple devices like CD-ROM, Scanners, Drives and Storage.
Each device connect on the SCSI cable did have a Target number. Normally this done by dip-switches.
The “Computer” with the SCSI controller is the Initiator. This initiator could have connection to different Targets.
A drive has a LUN number which is assigned for the whole block device. If a Storage device was connected with multiple drives, you could have some volumes with different LUN numbers.
What is iSCSI
iSCSI is the protocol to have the SCSI commands over a network. You can read about it in RFC 3720, RFC 3721, RFC 3722 and RFC 3723. If there are more RFC’s, I don’t know. To understand the iSCSI protocol, reading there RFC’s is a good start.
In the diagram you see the Initiator having a connection to a Target. On that Target is the block storage is. An Initiator can only use SCSI commands. Those SCSI commands are encapsulated in iSCSI. iSCSI is working with discovery and login of the Targets. iSCSI don’t have a physical cable for a connection between the Initiator and Target. Therefore, a discovery and login process is in place. In the Ethernet, TCP/IP packet iSCSI packets are encapsulated. It will find it’s way to the Target, which only understand the SCSI commands for the block device.
iSCSI Qualified Name (IQN)
RFC 3721 describe the IQN format. IQN has nothing to do with the ip addresses of the network. IQNs identify the Initiators and Targets.
An example of an IQN is : iqn.2018-02.com.iamjoost:win-initiator
It start with iqn.
Followed with the year-date of when the company registered it’s domain, followed with the domain name in reverse order. Example: 2018-02.com.iamjoost
Now there is the : followed with an unique string. If you keep this string easy, its easy to configure. In the Operating System you can change the IQN of the Initiator.
It’s very easy if you know how its format.
Don’t be afraid of IQN. Even I understand it.
Joost
iSCSI Discovery and Login
Via the Discovery of a Target the Initiator know to which Target(s) it can connect. If you know the Target(s) where the Initiator can connect to, you can Login to this Target.
After the Login, you now have connection with the Target and you will see one or more new block devices. These devices should be initialized, partitioned and formatted similarly to a normal drive.
This is just iSCSI in a Nutshell and more iSCSI blogs will follow. Stay Tuned!
I have a problem in iscsi configuration in my REDHAT server. The iscsi Luns are coming from NetApp storage. I have 5 RHEL servers. Each server has multiple iscsi sessions to target but with different iface names…these iface names belongs to other servers to which Luns are shared. Is this a proper setup?
My understanding is every server should have the iscsi sessions using it’s own initiators. Can someone clarify on the same?
Thanks
Pradeep.
Hi,
I am no NetApp expert, but shared LUNs shouldn’t be a problem.
Each initiator (RHEL Server) can connect to the same target. The Target (NetApp) should be configured to allow connections from all configured Initiators.