Configuration and administration of iSCSI
This chapter contains special considerations for when you are administering or changing the configuration of an Internet Small Computer System Interface (iSCSI) SAN.
This chapter describes the following topics:
15.1 Changing the iSCSI port configuration
This section describes how to make configuration changes to a SAN Volume Controller or IBM Storwize system’s iSCSI ports. In particular, it describes changing the iSCSI ports’ IP addresses and enabling or disabling iSCSI capabilities from IP ports. The impact of changing an iSCSI port’s IP address depends on whether that port is an initiator port or a target port Section 15.1.1, “Changing the iSCSI initiator ports’ IP addresses” on page 298 describes changing the initiator ports’ IP addresses. Section 15.1.2, “Changing the iSCSI target ports’ IP addresses” on page 298 describes changing the target ports’ IP addresses. If a port is both an initiator port and a target port, the considerations in both sections apply.
|
Attention: A SAN Volume Controller or IBM Storwize system’s IP ports can be used both for iSCSI and IP replication. This section considers only IP ports that are being used for iSCSI. If the system is also using these ports for IP replication, you must also consider the effects of reconfiguring the port on the system’s IP replication partnerships.
|
15.1.1 Changing the iSCSI initiator ports’ IP addresses
You can change the IP address of an iSCSI initiator port by using the cfgportip command. If that port is the source port for any iSCSI storage port objects, this command fails unless the -force flag is used. For more information about this command, see IBM Knowledge Center.
Changing the IP address of an iSCSI initiator port is nondisruptive if the new IP is accessible to all of the target ports with which the initiator port in question has a session. You can check which IP addresses these are by using the lsiscsistorageport view; look in the target IP fields of the lines of the view for which the source port ID field contains the index of the iSCSI port object of interest.
You typically do not need to make configuration changes to any storage controllers that are connected to the initiator port because the storage controller identifies an initiator by its IQN.
15.1.2 Changing the iSCSI target ports’ IP addresses
You can change the IP address of an iSCSI target port by using the cfgportip command. For more information about this command, see IBM Knowledge Center.
If you change the IP address of a target port, you also must change the configurations of any hosts that are connected to that port. They must be reconfigured to establish iSCSI sessions that use that port’s new IP address.
Changing the IP address of an iSCSI target port is disruptive because it brings down any iSCSI sessions with hosts that are using that port. However, if the host has dual-redundant connections to the SAN Volume Controller or IBM Storwize system that use different target ports, it might still be possible to change the IP addresses without loss of access to data.
Because changing the IP address of a target port involves reconfiguring the host, the procedure to change the IP address without loss of access to data depends on the type of hosts that are connected to the target ports.
The following example describes how to do this task when the hosts that are connected to those target ports are other SAN Volume Controller or IBM Storwize systems. To change target port IP addresses to which other types of hosts are connected, you must adapt these instructions for the types of hosts in question. These instructions describe how to use the CLI both on the system whose target ports you want to reconfigure and on the SAN Volume Controller and IBM Storwize systems that are acting as hosts that are attached to these ports. You can use either the CLI or the GUI to change the target system configuration, but you must use the CLI to make the changes on the SAN Volume Controller or IBM Storwize host systems without loss of access to data.
|
Attention:
•Failure to follow these instructions correctly can result in loss of access to data. Do not attempt to proceed past step 1 without resolving any connectivity problems that are uncovered in that step. Do not attempt to repeat step 2 for a new target port until the previous target port is successfully reconfigured and all hosts have good connectivity to it.
•When you are doing this task, the system has a single point of failure. While one of the target ports is being reconfigured in step 2, each host has a connection to only one target port of the system.
|
Complete the following steps:
1. Ensure that all the hosts that are connected to the system that is using the target ports in question have a dual-redundant connection to the system by using at least two target ports. Also, ensure that all of those connections have good connectivity. To do this task when the hosts are other SAN Volume Controller or IBM Storwize systems, complete the following steps on each of the hosts in question:
a. Check that the controller object that represents the target system is not degraded. The degraded field of the detailed lscontroller view for the controller object that represents it should contain no.
b. Check that each iSCSI storage port object that represents a set of connections to the target system has full connectivity. The status field of the lsiscsistorageport view should contain full.
If any host does not have full and dual-redundant connectivity to the target system, diagnose and fix the problem before you continue.
2. Change the IP address of each of the target ports in question and reconfigure the hosts to use the new IP address by completing the following steps. To prevent loss of access to data, do not start reconfiguring a target port until you are finished reconfiguring the previous target port and the hosts all have good connectivity to it.
a. Change the IP address of the target port in question with the cfgportip command on the target SAN Volume Controller or IBM Storwize system.
b. Reconfigure any hosts’ connections with this port to connect to it by using the new IP address. When the hosts in question are other SAN Volume Controller or IBM Storwize systems, do this task by carrying out the following steps on the hosts in question:
i. Identify the connections that must be reconfigured by using lsiscsistorageport; look for the iSCSI storage port object for which the target IP field contains the old IP address of the target port in question. Note the details of that iSCSI storage port object.
ii. Remove the iSCSI storage port object that represents those connections by using the rmiscsistorageport command.
iii. Re-create the iSCSI storage port object with the same details as before, but with the new IP target port IP address by using the detectiscsistorageportcandidate and addiscsistorageport commands.
iv. Check that the new connections have good connectivity to the target port by using the lsiscsistorageport command. The status field for the corresponding iSCSI storage port object should contain full.
If you discover during step iv that any host does not have good connectivity to the target port, diagnose and fix the problem before you continue.
For full instructions about using the CLI commands in this step, see the IBM Knowledge Center IBM Knowledge Center.
3. When you have reconfigured the IP addresses of all the target ports in question and reconfigured all the hosts that are connected to those ports, repeat the checks in step 1 on page 299 to ensure that the procedure has restored full and dual-redundant connectivity.
15.1.3 Enabling or disabling iSCSI on IP ports
In certain circumstances, you might want to enable or disable iSCSI capability on IP ports, for example, to dedicate a port to IP replication or to use a port that was previously dedicated to IP replication for I/O. To enable or disable iSCSI host attachment or iSCSI external virtualization on a port, use the cfgportip command. For the full documentation of this command, see IBM Knowledge Center.
To use a port for iSCSI host attachment, in addition to enabling iSCSI host attachment on that port, you must also reconfigure your hosts to establish iSCSI sessions that use that port as the target port. Before you remove host attachment capabilities from a port, you should first ensure that any hosts that are connected to that port still have a dual-redundant connection after it is reconfigured, and then reconfigure these hosts to stop using that port before reconfiguring it. This process depends on the type of hosts in use.
To use a port for iSCSI external virtualization, in addition to enabling iSCSI external virtualization on it, you must also create iSCSI storage port objects to use that port to connect to storage controllers. Typically, you do not need to reconfigure the storage controllers to do this task. If you want to remove external virtualization capabilities from a port, you should first ensure that the system still has a dual-redundant connection to any storage controllers that are connected to that port after it is reconfigured. Typically, you do not need to reconfigure those storage controllers.
15.2 Adding or removing nodes or I/O groups
MDisks that are visible though iSCSI connections to storage controllers can be connected in three different ways, as described in 15.2.1, “Adding nodes” on page 300. Adding nodes to a SAN Volume Controller initiator cluster can have different impacts on MDisks that are connected differently.
15.2.1 Adding nodes
This section describes how to add nodes.
MDisks that are connected through all nodes in the SAN Volume Controller cluster
For the MDisks that are connected through cluster-wide connectivity, adding a node causes the new iSCSI sessions to be automatically established from the newly added nodes to the configured LUNs or target iSCSI ports on the storage controller. You must ensure that the new nodes are correctly configured with the correct IP addresses and flags such that the initiator iSCSI ports on those nodes can access the configured LUNs and iSCSI targets on the storage controllers. For key considerations while you are configuring a new node, see “Key considerations for adding a node” on page 301.
MDisks that are connected through an I/O group of the SAN Volume Controller cluster
For the MDisks that are connected through I/O group-wide connectivity, adding a node does not have any impact. No action is necessary from users in such cases because connectivity to each iSCSI target port (or LUN) on the storage controller must be available from two nodes of a single SAN Volume Controller initiator IO group for the corresponding MDisk to be in the online state.
MDisks that are connected through a site of the SAN Volume Controller cluster
For the MDisks that are connected through site-wide connectivity, adding a node has an impact only if some (or all) of the new nodes are added to that site. The new nodes that are part of that site automatically initiate an iSCSI session with the storage controllers, if connectivity is cluster-wide. You must ensure that the new nodes are correctly configured with the correct IP addresses and flags such that the initiator iSCSI ports on those nodes can access the existing LUNs and iSCSI targets on the existing storage controllers. For more information, see “Key considerations for adding a node” on page 301.
Key considerations for adding a node
Consider the following things when you add a node:
1. Modify the LUN mapping policy on the storage controller.
The LUN mapping policy must be enhanced such that all the new SAN Volume Controller nodes can access the existing LUNs and storage controllers. If the storage controller is IBM Storwize or XIV, the IQNs of the new nodes must be added to the host object. If the storage controller is Dell, the IP addresses, IQNs, or user name and CHAP secret (depending upon the type of access policy that is used) of the new nodes must be added to the access list of the existing LUNs.
2. Configure ports on the SAN Volume Controller initiator.
All the new nodes must be configured such that they can access all existing iSCSI storage controllers that expose MDisks. This requirement means that all iSCSI initiator ports on the new nodes must be configured with IP addresses that are accessible to the storage controller ports. In addition, the storage flag must be set to yes for those ports that are used to access the storage controllers. For more information, see 15.2.3, “Adding ports to the SAN Volume Controller initiator” on page 302.
3. Check the connectivity status on the SAN Volume Controller initiator.
If steps 1 and 2 are done correctly, adding a node causes an increase in the number of iSCSI sessions to the storage controller because node addition automatically triggers an iSCSI session from the new nodes. However, it can take up to 1 minute to establish a session with storage controller after the IP addresses are configured on the new nodes.
Check the connectivity status by using the lsiscsistorageport CLI command. If the status for a target IQN shows full, it means that the new nodes can access the storage controller. If the status is partial, wait for 1 minute for the session to become established. If the status continues to be partial, then new nodes cannot establish an iSCSI session with the storage controller, which means that step to debug the issue. For more information, see 11.2.7, “Viewing the discovery results” on page 222.
4. Troubleshoot degraded MDisks.
If any MDisk goes to a degraded state while you are adding a node, it means that either an iSCSI session is not established to the storage controller from the new nodes or LUN mapping is not done on the storage controller. You can check the connectivity status by doing step 3 on page 301. If the field status shows FULL but the MDisk state is degraded, LUN mapping is not configured for the new nodes correctly. For more information, see the corresponding storage controller’s documentation.
15.2.2 Removing nodes from a SAN Volume Controller initiator cluster
Removing I/O groups or nodes from the SAN Volume Controller initiator cluster does not have any impact on MDisks while there is at least one path to the storage controller. The MDisks continue to be in the same state. No action is required from the user. However, if removing nodes removes all the iSCSI sessions to a storage controller, then the MDisk from that storage controller goes offline. Ensure that the last path to an MDisk is available before you remove a node.
15.2.3 Adding ports to the SAN Volume Controller initiator
If a user wants to add iSCSI ports to the SAN Volume Controller, new ports must be configured with the storage flag set to true.
When an IP is already configured on the ports and you want to enable storage functions on that port by using the GUI, connect to the SAN Volume Controller initiator GUI and click Settings → Network. Go to the Ethernet Ports tab, right-click the required IP, and select Modify Storage Ports, as shown in Figure 15-1.
Figure 15-1 Modifying the storage attribute of an IP
Select Enabled from the drop-down menu for the corresponding IP type and click Modify, as shown in Figure 15-2.
Figure 15-2 Enabling the storage attribute of an IP
Alternatively, you can use the cfgportip CLI command:
svctask cfgportip -node <node id> -storage yes <port id>
svctask cfgportip -node <node id> -storage_6 yes <port id>
When iSCSI ports are enabled for storage use, you can use them for connecting to the iSCSI storage controller.
If a new hardware adapter is being added, follow the instructions that are given in IBM Knowledge Center.
15.2.4 Removing ports
iSCSI ports can be removed only if the ports are not actively used for iSCSI virtualization sessions. You can check whether a port is being using in iSCSI virtualization or not by using the lsiscsistorageport command, as shown in Figure 15-3.
Figure 15-3 Checking whether a port is being used in iSCSI virtualization
The second column, src_port_id, shows the port ID. In this example, ports 3 and 4 are being used for iSCSI virtualization, so they cannot be removed. All other ports can be removed.
If any port is already in use for connecting to iSCSI-connected MDisks, the storage flag for that port cannot be turned off, and the IP address for that port cannot be removed. Before removing and disabling a hardware adapter, you must ensure that there are no active sessions from those ports to the iSCSI storage controller.
15.3 Changing the system name or node name
This section explains how to change the system name or the node name.
15.3.1 Changing the system name or node name of the initiator (SAN Volume Controller system)
Changing the initiator’s system name or node name causes the initiator’s IQN or IQNs to change. For example, consider a scenario where you want the old system’s name is “redbookscluster1” and you want to change it to “redbookscluster2”.
Each node’s present IQNs are iqn.1986-03.com.ibm:2145.redbookscluster1.nodeX. where X is the node index. After you change the system name, new IQNs for each node will be iqn.1986-03.com.ibm:2145.redbookscluster2.nodeX, where X is the node index. When the initiator’s IQN changes, SAN Volume Controller does not log out all the existing sessions that are established with the old IQN, so all the logged in session remain logged in and I/O continues until the iSCSI session is reestablished. After the session is reestablished, all the LUNs that were visible through sessions that were established with old IQNs are no longer accessible.
Therefore, before changing the system name/node name, you must perform some administrative steps to ensure that the LUNs remain accessible after sessions are reestablished with the new IQNs and everything continues to work correctly. These administrative steps depend on which iSCSI controllers to which the SAN Volume Controller is connected.
Steps for changing the initiator’s system or node name when it is connected to SAN Volume Controller or IBM Storwize controllers
If you are using SAN Volume Controller or IBM Storwize controllers, complete the following steps to change the initiator’s name:
1. On the SAN Volume Controller or IBM Storwize controller, add the IQN or IQNs to the host object so that all existing MDisks can be accessed through these IQNs. Complete the following steps:
a. Connect to the SAN Volume Controller GUI.
b. Select Hosts → Hosts and select the host object that represents the SAN Volume Controller initiators.
Figure 15-4 Changing the properties of the host object
A window opens.
d. Go to the Port Definitions tab, as shown in Figure 15-5.
Figure 15-5 IQN list of a host object
e. Click Add → iSCSI Port. Provide the new IQN of the iSCSI initiator, and then click Add Port to List. Similarly, add all the IQNs to the port list. After adding all the IQNs, click Add ports to Host, as shown in Figure 15-6.
Figure 15-6 Adding the IQNs to the host object
Now, the host object has both the old IQNs and the new IQNs, as shown in Figure 15-7.
Figure 15-7 IQN list of the host object
|
Attention: Do not remove the old IQNs yet because there are active iSCSI sessions from those IQNs. These IQNs can be removed after you change the system or node name on the initiator.
|
Alternatively, you can add these new IQNs by using the addhostport command:
addhostport -iscsiname iqn.1986-03.com.ibm:2145.redbookscluster2.node1 0
addhostport -iscsiname iqn.1986-03.com.ibm:2145.redbookscluster2.node2 0
After this step, the new node IQNs can access all the MDisks that the old IQNs were accessing.
|
Note: The new IQNs that must be added are not set on the initiator yet. They must be deduced from the IQN naming format. If the node name is changed, the last part of the IQN of that initiator node is replaced by the new node name. If the system name is changed, the portion of the IQN between the last two dots is replaced by the new system name.
|
2. On the SAN Volume Controller or IBM Storwize initiator, change the system name. To do this task, complete the following steps:
a. Connect to the SAN Volume Controller initiator system and click Monitoring → System.
b. Click Actions.
Figure 15-8 Changing the system name
Figure 15-9 Renaming the system
3. On the SAN Volume Controller or IBM Storwize initiator, after you change the system name, remove the iSCSI sessions from the SAN Volume Controller or IBM Storwize target controllers and add them back again one by one. That is, remove sessions from one port, add them back, remove sessions from the second port, add them back, and so on. It is important to do this task one port at a time so that access to a LUN is not lost.
|
Note: For a cluster-wide or I/O Group-wide discovery, a warning appears in the SAN Volume Controller or IBM Storwize initiator’s GUI window. This warning is automatically corrected when the session is added back.
|
Figure 15-10 shows the controller connectivity list. Ports 3 and 4 of both nodes are connected to both the controllers.
Figure 15-10 Controller connectivity list
Complete the following steps:
a. Remove sessions from port 3 to SAN Volume Controller or IBM Storwize controller iqn.1986-03.com.ibm:2145.redbooksbackendcluster2.node1 and add it back:
rmiscsistorageport 2
svctask detectiscsistorageportcandidate -srcportid 3 -targetip 192.168.104.190
addiscsistorageport 0
b. Repeat the same task for sessions from port4:
rmiscsistorageport 3
svctask detectiscsistorageportcandidate -srcportid 4 -targetip 192.168.104.191
addiscsistorageport 0
c. Repeat it for sessions to controller iqn.1986-03.com.ibm:2145.redbooksbackendcluster2.node2:
rmiscsistorageport 4
svctask detectiscsistorageportcandidate -srcportid 3 -targetip 192.168.104.192
addiscsistorageport 0
rmiscsistorageport 5
svctask detectiscsistorageportcandidate -srcportid 4 -targetip 192.168.104.193
addiscsistorageport 0
4. On the SAN Volume Controller or IBM Storwize Controller, remove the old iSCSI IQNs from the host object:
a. Connect to the controller GUI and click Hosts → Hosts.
b. Select the host object and click Properties.
c. Go to the Port Definitions tab. It displays all the IQNs. The new IQNs are active and old IQNs are offline, as shown in Figure 15-11.
Figure 15-11 IQN list of the host object
d. Select the old IQNs and click Delete Port. A window opens, as shown in Figure 15-12. In the Verify the number of ports to delete field, enter the number of old IQNs that you want to delete.
Figure 15-12 Deleting old IQNs from the host object list
When this task is complete, the host object contains only the new IQNs with an active status, as shown in Figure 15-13.
Figure 15-13 IQN list of the host object
You can also use the rmhostport command to do this task:
rmhostport -iscsiname iqn.1986-03.com.ibm:2145.redbookscluster1.node1 0
rmhostport -iscsiname iqn.1986-03.com.ibm:2145.redbookscluster1.node2 0
Changing the initiator’s system or node name when it is connected to Dell controllers
Each LUN on the Dell EqualLogic controller has an independent IQN and each LUN can have different access methods. Here are the access methods:
IP list access Provide a list of initiator IPs that can access a LUN.
IQN list access Provide a list of initiator IQNs that can access a LUN.
CHAP access All initiators that authenticate themselves with a specified user name and CHAP secret combination can access the LUN.
Mixed access Mix of IP and IQN access, CHAP access, or both.
If accessibility of LUNs is configured by initiator IP or CHAP access, nothing must be done. Any change in the initiator’s IQN has no impact when the IP or CHAP on the initiator is unchanged because when the iSCSI session is reestablished, the initiator retries the login with the new IQN but with the same IP and CHAP secret, and it access to the LUNs is enabled.
If accessibility of LUNs is configured by using the initiator IQN, you must add the IQNs of the initiators to the access list before you change the initiator system name.
When this step is complete, follow the same steps to change the system name as specified for IBM Storwize, and then reestablish iSCSI sessions with the Dell controller one at a time. Now, you can remove the old IQNs from the LUNs access list on the Dell controller.
Changing the initiator’s system or node name when connected to an XIV controller
The process to change the SAN Volume Controller or IBM Storwize initiator’s system or node name when connected to an XIV controller is similar to the process for when it is connected to the IBM Storwize controller. To add access to new IQNs for the LUNs, see IBM Knowledge Center, especially Chapter 2, “Adding a port to a host.
Changing the target controller IQN
You can change the IQN of a target SAN Volume Controller or IBM Storwize controller without any downtime. However, changing the IQNs on a Dell EqualLogic controller without losing access to LUNs is not feasible. XIV does not allow its target iSCSI name (IQN) to be changed. IBM Knowledge Center explains how to define a target object in XIV 10.2.4 by using target_define. In the CLI, you can change only the local target name, not its iSCSI name (IQN).
If you must change the IQN of a target SAN Volume Controller or IBM Storwize controller, you must remove iSCSI sessions to the affected target ports and add them back one at a time. This task must be done for all target ports with new IQNs.
Figure 15-14 displays source ports 3 and 4 of all the initiator nodes that are connected to two target IBM Storwize controller nodes.
Figure 15-14 Source ports 3 and 4 connected to IBM Storwize server redbookbackendcluster
Complete the following steps:
1. Remove the sessions from port 3 to controller node1 and add it back:
rmiscsistorageport 2
svctask detectiscsistorageportcandidate -srcportid 3 -targetip 192.168.104.190 -chapsecret secret1
addiscsistorageport -chapsecret secret1 0
2. Repeat the process for port 4, and then for controller node 2:
rmiscsistorageport 3
svctask detectiscsistorageportcandidate -srcportid 4 -targetip 192.168.104.191 -chapsecret secret1
addiscsistorageport -chapsecret secret1 0
rmiscsistorageport 4
svctask detectiscsistorageportcandidate -srcportid 3 -targetip 192.168.104.192 -chapsecret secret1
addiscsistorageport -chapsecret secret1 0
rmiscsistorageport 5
svctask detectiscsistorageportcandidate -srcportid 3 -targetip 192.168.104.193 -chapsecret secret1
addiscsistorageport -chapsecret secret1 0
Figure 15-15 shows the results of these steps.
Figure 15-15 Source ports 3 and 4 connected to Storwize server redbookbackendcluster2
15.4 Changing the CHAP configuration
In certain circumstances, you can change the CHAP configuration for a SAN Volume Controller or IBM Storwize system’s iSCSI sessions without a loss of access to data. This configuration change can be introducing CHAP authentication, removing CHAP authentication, or changing the CHAP secret for a connection that already uses CHAP authentication.
A CHAP configuration applies to a connection between an initiator system and a target system, so to change the CHAP configuration you must make configuration changes to both the target system and initiator system. Therefore, whether the CHAP configuration of a SAN Volume Controller or IBM Storwize system’s iSCSI connections can be changed without disruption depends on the properties of the host or storage controller to which it is connected.
Section 15.4.1, “General considerations” on page 312 describes the general principles of changing the CHAP configuration without reference to any particular host or storage controller. Section 15.4.2, “Instructions for a SAN Volume Controller or IBM Storwize initiator system with an IBM Storwize target system” on page 313 gives specific instructions for changing the CHAP configuration for the connection between a SAN Volume Controller or IBM Storwize initiator system and an IBM Storwize target system; this is a case in which the configuration can be changed without loss of access to data.
15.4.1 General considerations
The process for changing the CHAP configuration of a SAN Volume Controller or IBM Storwize system’s iSCSI sessions is different for external virtualization and host-attached sessions. The considerations that are involved in making the change nondisruptively are also different.
External virtualization iSCSI sessions
SAN Volume Controller and IBM Storwize systems support only one-way (target authenticates initiator) CHAP authentication for iSCSI connections for external virtualization. The CHAP configuration that is used for the connection with a back-end storage controller is set when the corresponding iSCSI storage port object is created.
After an iSCSI storage port object is created, its CHAP configuration cannot be changed. So, to reconfigure CHAP, you must delete the object and re-create it. This is a disruptive process because it involves dropping the iSCSI sessions.
However, if the system has dual-redundant connections to the storage controller, it might be possible to change the CHAP configuration without loss of access to data. By reconfiguring the iSCSI storage port objects one at a time, the system can maintain access to data by using one of the objects while the other is being re-created. This situation works only if the storage controller either allows its CHAP configuration to be changed without dropping its iSCSI sessions or allows the CHAP configuration of those of its iSCSI sessions corresponding to a single iSCSI storage port object on the initiator system without disrupting the others. With an IBM Storwize system as the target storage controller, the CHAP configuration can be changed nondisruptively because the Storwize target system does not drop its host-attached iSCSI session when those connections’ CHAP configurations are changed.
Host-attached iSCSI sessions
Changing the CHAP configuration on a SAN Volume Controller or IBM Storwize target system does not disrupt its host-attached iSCSI sessions, even if the host’s CHAP configuration is not changed. This is because CHAP authentication occurs only when an iSCSI session is established and a SAN Volume Controller or IBM Storwize system does not drop its host-attached iSCSI sessions when their CHAP configurations are changed. If the host’s CHAP configuration does not match the SAN Volume Controller or IBM Storwize system configuration, the host cannot re-establish iSCSI sessions if they drop, for example, because of network disruption.
Whether it is possible to change the host’s CHAP configuration without disruption depends on the properties of the host. When the host is another SAN Volume Controller or IBM Storwize system with dual-redundant connections to the target IBM Storwize system, its CHAP configuration can be changed without loss of access to data by reconfiguring one iSCSI storage port at a time.
15.4.2 Instructions for a SAN Volume Controller or IBM Storwize initiator system with an IBM Storwize target system
It is possible to change the CHAP configuration between a SAN Volume Controller or IBM Storwize initiator system and an IBM Storwize target system without loss of access to data if each node of the initiator system has two redundant connections to the target system. This is possible because SAN Volume Controller or IBM Storwize systems do not drop their iSCSI sessions with hosts when the CHAP configuration for the connection with those hosts is changed. So, where there are dual-redundant connections between the target system and the initiator system, the initiator system’s CHAP settings can be changed one connection at a time while always retaining access to data by using the other connections.
This task can be completed only with the CLI. The following instructions describe how to change the CHAP settings in such a setup without losing access to data.
|
Attention:
•Failure to follow these instructions correctly can result in loss of access to data. Do not attempt to proceed past step 1 without resolving any connectivity problems that are uncovered in that step. Do not attempt to repeat step 3 for a new iSCSI storage port object until the previous iSCSI storage object is successfully reconfigured and has good connectivity.
•While you are following these instructions, the system has a single point of failure. While one of the iSCSI storage port objects is being reconfigured in step 3, each node of the initiator system has only one iSCSI session with the target system.
•During this procedure, the initiator cannot automatically reestablish iSCSI sessions if they drop. This situation increases the impact of network stability problems.
|
Complete the following steps:
1. Ensure that the initiator system has full and dual-redundant connectivity to the target system. Complete the following steps:
a. Check that the controller object that represents the target system is not degraded (the degraded field of the detailed lscontroller view for that controller should contain no).
b. Check that each iSCSI storage port object representing a set of connections to the target system has full connectivity (the status field of the lsiscsistorageport view should contain full).
If the initiator system does not have full and redundant connectivity to the target system, diagnose and fix the problem before continuing.
2. On the target system, change the one-way (the target authenticates the initiator) CHAP configuration as needed by using the chhost command. Section 5.2, “Configuring CHAP for an IBM Storwize storage system” on page 57 contains full instructions for configuring and authenticating CHAP for host attachment.
3. On the initiator system, re-create each iSCSI storage port object with the new CHAP configuration. To do this task, complete the following steps a - d for each iSCSI storage port object that represents a set of iSCSI sessions with the target system. Do not start re-creating an iSCSI storage port until the previous one is successfully re-created. For full instructions about using the CLI commands in this step, see IBM Knowledge Center.
a. Note the settings for the iSCSI storage port object in question, which are shown in the lsiscsistorageport view.
b. Remove the iSCSI storage port object by using the rmiscsistorageport command.
c. Create a iSCSI storage port object by using the detectiscsistorageportcandidate and addiscsistorageport commands. Use the same settings as the old object that noted in step a, but use the new CHAP configuration set in step 2.
d. Check that the new iSCSI storage port object has the correct settings and full connectivity by using the lsiscsistorageport view.
4. Check that the controller object representing the target system is not in a degraded state by using the detailed lscontroller view.
15.5 Changing the number of LUNs, ports, and IQNs in an IBM Storwize system
This section describes how to add and remove LUNs.
15.5.1 Adding and removing LUNs exposed from IBM Storwize or XIV controllers
To add/remove LUNs that are exposed from IBM Storwize or XIV controllers, complete the following steps:
1. On the storage controller, to add/remove LUNs from pre-configured IBM Storwize or XIV controllers to SAN Volume Controller storage pools, map (for adding new LUNs) or unmap (for removing LUNs) those LUNs to or from the host object. In this case, the host object is one or more SAN Volume Controller nodes. SAN Volume Controller nodes are identified by their IQNs. To modify the LUN mappings, see IBM Knowledge Center for IBM Storwize IBM Storwize and XIV.
2. On the SAN Volume Controller initiator, after the mapping is updated, refresh the LUN list on the SAN Volume Controller initiator side. To refresh the LUN list by using GUI, connect to the initiator GUI and click Pools → External Storage. Right-click the iSCSI controller (IBM Storwize or XIV controller) and click Discover Storage, as shown in Figure 15-16.
Figure 15-16 Refreshing the LUN list from a pre-configured controller
After new LUNs are available for use, they are displayed under that controller. For example, Figure 15-17 shows that a new LUN (mdisk8) is added for controller2. This LUN is configured on an IBM Storwize controller.
Figure 15-17 The mdisk8 LUN is added to the LUNs list
Alternatively, you can use the detectmdisk command to refresh the LUN list. Figure 15-18 shows that mdisk8 was added for controller2.
Figure 15-18 Example detectmdisk CLI command output
15.5.2 Adding LUNs from a Dell EqualLogic controller
Each LUN on Dell EqualLogic controller has an independent IQN. To add a LUN, complete the following steps:
1. On the Dell controller, modify the access policy of the newly created LUNs so that the required nodes of SAN Volume Controller initiator can access that LUN.
2. On the SAN Volume Controller initiator, run the detectiscsistorageportcandidate command to discover the newly created LUNs. The IQNs of the newly created LUNs are displayed by the lsiscsistorageportcandidate command.
3. On the SAN Volume Controller initiator, run the addiscsistorageportcandidate CLI command to establish an iSCSI session with those new IQNs. The isiscsistorageport command shows the status of the iSCSI session.
4. On the SAN Volume Controller initiator, newly added LUNs are displayed by the lsmdisk command.
15.5.3 Removing LUNs from a Dell EqualLogic controller
To remove LUNs from the Dell controller, complete the following steps:
1. On the SAN Volume Controller initiator, each LUN in the Dell EqualLogic controller has an independent IQN. To remove LUNs, remove the iSCSI session to those IQNs. The lsiscsistorageport command displays the list of iSCSI sessions; from that list, find the entries of the Dell EqualLogic controller LUNs by searching for the IQNs of those LUNs. Use the row indexes of those entries to remove the sessions by using the rmiscsistorageport command.
2. On the Dell controller, modify the access policy of the LUNs so that the SAN Volume Controller nodes cannot access (discover and log in to) those LUNs.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.