Configuring the Linux iSCSI San Client

Configuring the Linux iSCSI San Client

4.1. Installing ISCSI (Starter) service

This installation package is in the system's installation package. Find the ISCSI-INITIATOR-UTILS-6.2.0.871-0.10.EL5.X86_64.RPM package. The installation.

[Email protected] ~]# RPM-UVH iscsi-initiator-utils-6.2.0.871-0.10.el5.x86_64.rpm

1:iscsi-initiator-utils ########################################### [100%]

[Email protected] ~]# Rpm-qa | grep iscsi-initiator-utils

Iscsi-initiator-utils-6.2.0.871-0.10.el5

2.2 Configuring the ISCSI (initiator) service

The initiator package has just been installed. Now let's start the initiator service (ISCSID) and make it start automatically when the system boots. When you configure the iSCSI service to start automatically, it automatically logs on to the iSCSI target when the system starts.

[[Email protected] ~]# service Iscsid start

[Email protected] ~]# chkconfig iscsid on

[[email protected] ~]# chkconfig iSCSI on

Use the Iscsiadm command to check all available targets on the NAS server:

[Email protected] ~]# iscsiadm-m discovery-t sendtargets-p 192.168.0.188

Manually sign in to an ISCSI target

[Email protected] ~]# iscsiadm-m node-t iqn.2006-01.com.openfiler:tsn.ocr-p 192.168.0.188-l

[Email protected] ~]# iscsiadm-m node-t iqn.2006-01.com.openfiler:tsn.oradata-p 192.168.0.188-l

[Email protected] ~]# iscsiadm-m node-t iqn.2006-01.com.openfiler:tsn.hisdata-p 192.168.0.188-l

Disconnecting iSCSI Login Status

[Email protected] ~]# iscsiadm-m node-t iqn.2006-01.com.openfiler:tsn.ocr-p 192.168.0.188-u

Configure Automatic Logon

When the computer boots (or the ISCSI initiator service starts/restarts), the client automatically logs on to each of the targets listed above. Same as the manual login process described above, but there are 2 parameters added here.

[Email protected] ~]# iscsiadm-m node-t iqn.2006-01.com.openfiler:tsn.ocr-p 192.168.0.188--op update-n node.startup -V Automatic

[Email protected] ~]# iscsiadm-m node-t iqn.2006-01.com.openfiler:tsn.oradata-p 192.168.0.188--op update-n Node.star TUP-V Automatic

[Email protected] ~]# iscsiadm-m node-t iqn.2006-01.com.openfiler:tsn.hisdata-p 192.168.0.188--op update-n Node.star TUP-V Automatic

4.3 Creating a persistent local SCSI device name

View the/dev/disk/by-path file to determine which file the file is mapped to:

[Email protected] by-path]# Ls/dev/disk/by-path-al

You need to use Udev's dynamic management tools. Udev provides a dynamic device directory that uses a set of configurable rules to point to the actual device through symbolic links. When Udev receives a device event
(for example, when a client logs on to an ISCSI target), it matches its configured rules to identify the device according to the available device properties provided in Sysfs. Matching rules can provide additional device information or specify device node names and multiple symbolic link names.
and instructs Udev to run other programs (for example, a SHELL script) as part of the device event handling process.

4.3.1. Creating a new Rule file

Creates a file/etc/udev/rules.d/55-openiscsi.rules that contains only a row of name-value pairs that are used to receive events. A callout SHELL script (/etc/udev/scripts/iscsidev.sh) is also defined to handle the event.

55-openiscsi.rules file configuration is very important, especially in terms of file permission attributes, you must ensure that the correct

[Email protected] ~]# More/etc/udev/rules.d/55-openiscsi.rules

#/etc/udev/rules.d/55-openiscsi.rules

kernel== "sd*", bus== "scsi", program= "/etc/udev/scripts/iscsidev.sh%b", symlink+= "iscsi/%c", owner= "grid", GROUP= " Asmadmin ", mode=" 0660 "

4.3.2. Create a UNIX SHELL script that will be called when the event is received

(1) First create a directory on the server to store Udev scripts:

[Email protected] ~]# mkdir-p/etc/udev/scripts
Check if the path to the/sys/class/iscsi_host/host${host}/device/session*/iscsi_session*/targetname is correct

(2) Create a UNIX shell script/etc/udev/scripts/iscsidev.sh on the server:

[Email protected] ~]# more/etc/udev/scripts/iscsidev.sh

#!/bin/sh

# FILE:/etc/udev/scripts/iscsidev.sh

Bus=${1}

host=${bus%%:*}

[-e/sys/class/iscsi_host] | | Exit 1

File= "/sys/class/iscsi_host/host${host}/device/session*/iscsi_session/session*/targetname"

target_name=$ (Cat ${file})

# OPEN-SCSI Drive

If [-Z "${target_name}"]; Then

Exit 1

Fi

echo "${target_name##*.}"

Description: Let's take a look at the role of this script:

[[Email protected]]# more/sys/class/iscsi_host/host2/device/session1/iscsi_session:session1/targetname
Iqn.2006-01.com.san

From this command, we can see that this script is to get the name of the target. The rule will create the corresponding file under the corresponding directory based on the last string of the target name returned by the script.
The simple point is to do a mapping based on target. Because the target name is unique, the mapping name is also unique. This avoids mapping to a different system directory, where shared data is not available.

(3) Modify the shell script you just created as an executable file:

# chmod 755/etc/udev/scripts/iscsidev.sh
(4) Restart the ISCSI service on the server:

[[Email protected] ~]# service iSCSI Stop
[[Email protected] ~]# service iSCSI Start
(5) Verification

[Email protected]]# ls-l/dev/iscsi/*
lrwxrwxrwx 1 root root 6 Oct 14:16/dev/iscsi/san. /sdc

Because here we use UDEV configuration, it ensures that the iSCSI target is mapped to a unique device. We use this unique mapping/dev/iscsi/san when we use it.

Make an explanation of this mapping to the client. Because the beginning of the piece is a little blurred.

Storage configuration Only one thing to do is to provide me with a target. This target is a mapping done on the store. The server is connected to the storage via initiator.

This target is then mapped to its next available device, such as/DEV/SDC. If there is only one target. Then there is no problem.

This target is mapped to/DEV/SDC every time initiator is connected. But if there are multiple target, then there is a problem here.

Because the connection to the initiator is random. Maybe a is connected first, and that a is mapped to the/DEV/SDC. If B is connected first, B maps to/DEV/SDC. This is where the problem lies.

The dynamic management of Udev is a good solution to this problem. We use scripting to get the name of each target with a script, and then we create a device in our specified directory with the last string of each target in the rule.
This is because the rules are unique. So each device is unique. We will be able to use this unique device without any problems. such as the/dev/iscsi/san in the experiment. This is a Jedi position.

To view information for each iSCSI:
Iscsiadm-m Session-p 3

When these commands are completed, iSCSI Initator logs this information to the/VAR/LIB/ISCSI directory:

/var/lib/iscsi/send_targets records the conditions of each target,
The/var/lib/iscsi/nodes records the nodes situation under each target. The next time the iSCSI Initator is started (Service iSCSI start), it will automatically log on to each target.
If you want to manually log in to each target, you need to remove the contents of the/var/lib/iscsi/send_targets directory and the contents of the/var/lib/iscsi/nodes.

This article is from the "11300506" blog, please be sure to keep this source http://11310506.blog.51cto.com/11300506/1957572

Configuring the Linux iSCSI San Client