I'll skip the partition setup and PV (physical volume)/VG (volume group)/LV (logical volume) setup in this post. Probably I'll find some time to write a about it (not so soon :P).
This is my block list. Please note that, I have a LV setup at /dev/sda3 with xfs file system setup in the server, while /dev/sda4 is solely a partition.
2 packages you must install in the server, which is targetcli (to setup the iscsi target block) and targetd.
Enable and start target service.
Run targetcli to setup iscsi target
targetcli is like another command prompt. You can do ls to list out the available target/settings.
Create the target blocks.
Create iqn.
You can "cd" to the "sub"... I don't know what to call that. :D
Check out the portals, 0.0.0.0 means all interfaces of this machine, and 3260 is the default port for this. We will create acls for the access permission, and luns to link to the block that we created earlier.
This is for the block that we setup with the LV.
This is for the block that we setup for /dev/sda4.
You may directly exit, or do a saveconfig before exit. Please note that, saveconfig command is only available at "root" level, which is "/".
Lastly, enable the port in firewall!
OK, so now we are done with the server side.
For client side, we need to install iscsi-initiator-utils package.
Enable and start the iscsi and iscsid services.
Connect to the iscsi target for LV
First, update the initiatorname and restart iscsid service. Then do the target discovery, and connect to the target. You can see the new disk available by running the lsblk command result.
As this disk space is already formatted to xfs type earlier, so you can mount to it and use it right away.
----- If you just need to create and connect to an iscsi target, please stop here. -----
As I found this post very messy, so I made a divider here.
Update as of 20171001 : the disk might be needed to be allocated to another machine as a raw disk, let the target machine to decide the partition and the file format, hence, I would think the 2nd way should be the proper one. I never been a sys admin, thus I can't be sure. But it seems more logical to me now.
Warning : Below is messed with the experiments that I performed on the setups. Read it at your own risk. :D
I was doing some "security" test. The server that host this disk space cannot access to it after it is set as a target block via targetcli. I "assumed" this is a security feature.
While I left my client keep connected to this disk, I manage to connect to it using my host (Windows 7).
You can see my disk is available in the disk management. OK, I'll stop the Windows part right here.
I test the same for another CentOS machine (3rd virtual machine). It is accessible and content is available too! @_@'
Anyway, back to the raw disk space.
Connect to the iscsi target for raw disk
The connection is established the same way, but you won't be able to mount the disk, You'll need to format the disk, then only able to mount it.
We will use the initiator name that we defined for the raw block at the client end.
1. Update /etc/iscsi/initiatorname.iscsi
2. Restart iscsid
3. Run iscsiadm discovery to ensure the client machine able to "see" the target
4. Connect to the target.
From the lsblk command, you'll see the sdb is available now. As mentioned earlier, you won't be able to mount this disk. This is due to the disk is not "formatted".
We'll format it to ext4 file system, then mount again.
Now we are able to use it!
It is available on second connection as well. The file is found in the 2nd connection.
I made change on the file, but the content is not visible in my first connection! Why?
First connection:
Second connection (I just do a cat on that same file):
Third connection from my Windows host. Nothing special observed.
After a while, I notice something on my first connection.
Nothing special on second connection though.
Alright, I rebooted 3 machines, then both client machines are giving the same result. The test file is still there, just the content is empty.
I tested the same for the xfs target. Before reboot, it has the same behaviour as the raw disk. After reboot, it retain the content that I wrote from second connection (or second/latest write to the file), for both client machines. I can't comprehend. :-s
Anyway, with this experiment, and based on what I think how it should be, the target iscsi shouldn't be shared. This means, there should be only a client machine connecting to the target. If the content/files/disk space is meant for sharing, it should be shared through samba or nfs share.
No comments:
Post a Comment