Showing posts with label iscsi. Show all posts
Showing posts with label iscsi. Show all posts

How to increase Oracle ASM disk group size

Jephe Wu - http://linuxtechres.blogspot.com

Objective:  increase existing ASM disk group size
Environment: RHEL 6.4 64bit, Oracle 11.2.0.4, iscsi, multipath, udev and ASM, EMC storage
Concept:  increase disk group size by increasing ASM disk size itself or adding some more ASM disk

Part I: Add additional Lun as ASM disk

Steps:
1. create a new Lun in EMC storage
2. use the following methods to find out the newly created disk name ,e.g. /dev/sdae etc

dmesg
more /proc/partitions  (the new lines at the bottom)
ls -l /sys/block
ls -l /dev/disk/by-uuid/

3. find out the WWID
scsi_id --whitelisted --replace-whitespace –-device=/dev/sdae
multipath -ll 

4. vi /etc/multipath.conf to use alias for newly added ASM lun, e.g. db1
then run multipathd reload to reload the configuration

4. find out the lunid and wwid for each Lun so we know which volume is which

It's best to get lunid from storage administrator so that we can confirm which volume is which, otherwise, try to run the following command to find out. If sg_inq command is not available, yum install sg3_utils first

for x in /dev/dm-* ; do export lunid=$( /usr/bin/sg_inq --page=0x83 ${x} | grep "^ 00" | cut -d" " -f17 | awk '{ print strtonum( "0x" $1 ) };' ) ; export wwid=$( /sbin/scsi_id --whitelisted --replace-whitespace --device=${x} ) ; echo ${lunid} == ${x} == ${wwid}; done

5. As the root user, identify the Device Mapper Universally Unique IDentifier (DM_UUID)
for each device mapper volume. The example below shows the DM_UID for the
partitions of the volumes labeled db1,db2,fra, and redo. 

# for i in db1p1 ; do printf "%s %s\n" "$i" "$(udevadm
info --query=all --name=/dev/mapper/$i | grep -i dm_uuid)"; done

db1p1 E: DM_UUID=part1-mpath-3600c0ff000d7e7a899d8515101000000
6. Create a file labeled 99-oracle-asmdevices.rules within /etc/udev/rules.d/

7. Within 99-oracle-asmdevices.rules file, create rules for each device similar to the
example below:
KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-3600c0ff000dabfe5f4d8515101000000",OWNER="oracle",GROUP="oinstall",MODE="0660"

  • If one has made a change and don't want to reboot the system then can utilize udevadm trigger instead. Specify --type and--action or it will effectively work like start_udev.
 # /sbin/udevadm trigger --type=subsystems --action=add
 # /sbin/udevadm trigger --type=devices --action=add
 # /sbin/udevadm trigger --type=subsystems --action=change
 # /sbin/udevadm trigger --type=devices --action=change
  • One can even trigger only specific devices like below;
 # echo change > /sys/block/sda/sda1/uevent


8. make partition for new Lun, only run on one of RAC node if any
# parted /dev/mapper/db1 mklabel gpt mkpart primary "1 -1"
Information: You may need to update /etc/fstab.

Once the partition is created, a newly created device mapper device is created as db1p1.
# ls -l /dev/mapper/db1p1 
lrwxrwxrwx. 1 root root 8 Apr 16 15:15 /dev/mapper/db1p1 -> ../dm-11

NOTE: A newly created partition requires the alias name followed by p1 such as db1p1 seen
above. If p1 is missing, please run the following command to add the partition mappings to
the device mapper disks.
# kpartx -a /dev/mapper/db1

9.  if there's multiple paths on one system, you might need to run partprobe to update all available path for created partitions, and also run kpartx -a /dev/mapper/db1 on another RAC node
10. add partitioned new disk into disk group by CLI or asmca through vnc/xterm or ssh -X
ALTER DISKGROUP data_finance ADD DISK
     '/dev/mapper/db1p1';

Part II:  increase existing Lun size
Steps:

1. increase size of one of LUNs on storage 
2. make OS recognize the new size 
To re-scan logical units on a system that uses multipathing, execute the aforementioned command for each sd device (i.e. sda, sdb, and so on) that represents a path for the multipathed logical unit. To determine which devices are paths for a multipath logical unit, use multipath -ll; then, find the entry that matches the logical unit being changed. It is advisable that you refer to the WWID of each entry to make it easier to find which one matches the logical unit being changed.
echo 1 > /sys/block/sdax/device/rescan
echo 1 > /sys/block/sday/device/rescan
echo 1 > /sys/block/sdaz/device/rescan
echo 1 > /sys/block/sdba/device/rescan

Instead you can use /usr/bin/rescan-scsi-bus.sh script for rescanning all SAN LUNs. The sg3_utils package provides the rescan-scsi-bus.sh script, which can automatically update the logical unit configuration of the host as needed (after a device has been added to the system). The rescan-scsi-bus.sh script can also perform an issue_lip on supported devices. For more information about how to use this script, refer to rescan-scsi-bus.sh --help.

Now, run multipath -F followed by multipath -v2 mpathX to reload the mutipath configuration.

If the LUNs are configured over iSCSI protocol, the following command can be used to get the new LUN size:
# iscsiadm -m session -R

3. If it's multipath device, run kpartx -a /dev/mapper/mpathX if necessary
4. multipathd -k"resize map <multipath_device>"
5. reload multipath configuration : multipathd reload or multipathd restart, then run miltipath -ll to see new size.
Note: if you enabled 'queue if no path' option, then do not use multipathd -k'resize map mpatha'
6. resize /dev/mapper/mpathX by running resize2fs if necessary
7. check and resize ASM disk group
select name, total_mb, usable_file_mb from v$asm_diskgroup;
alter diskgroup DATADG resize all;

References:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/DM_Multipath/index.html#online_device_resize
http://www.novell.com/support/kb/doc.php?id=7009660
https://access.redhat.com/solutions/127103
http://www.jk-47.com/2012/08/extending-an-existing-lun-w-oracle-asm/
https://orainternals.wordpress.com/2012/08/29/do-you-need-asmlib/

Preparing Oracle database ASM diskgroup from EMC storage luns

Jephe Wu - http://linuxtechres.blogspot.com

Environment:  RHEL6.4 64bit, HP DL380, Oracle database 11.2.0.3 RAC, ASM, iscsi software initiator and multipath, EMC storage luns
Objective: create EMC Storage luns to present to 2 RAC nodes through iscsi and multipath to be used by Oracle ASM, use udev instead of Oracle ASMLIB


Steps
1. decide how many luns and groups of luns to be created on EMC storage
let's say we will create the following RAC database
database name: racdb
instance names: racdb1 and racdb2
cluster name/scan name:  racdb-scan.domain.com

data lun: data1 and data2, asm disk group: +DATA, external redundancy, for data files and temp files only
redo lun: redo1 and redo2, asm disk group:  +REDO, external redundancy, for redo logs and control files
reco lun: reco1 and reco2, asm disk group: +RECO, external redundancy, for rman backups
arch lun: arch1 and arch2, asm disk group: +ARCH, external redundancy, for archive logs only
ocr/votedisk lun: grid1 and grid2, 5G each, asm disk group: +GRID, external redundancy

2. setting up iscsi software initiator on RHEL6.4
We have installed one additional 4-port NIC on HP DL380 so that we can have a pair of NIC for bonding.

PCI NIC: eth4 eth5 eth6 eth7
on board:  eth3 eth2 eth1 eth0

bond0:  eth0 and eth4
bond1: eth1 and eth5
eth2 and eth6 are in different subnet for iscsi initiator use

eth2: 192.168.0.1/29
eth6: 192.168.0.2/29
EMC: 192.168.0.5/29

change initiator name on each node to be same as server name
[root@db1 iscsi]# more initiatorname.iscsi 
InitiatorName=iqn.1994-05.com.redhat:db1

on each node: discovery and setup auto iscsi login:

iscsiadm -m discovery -t st -p 192.168.0.5
will output for target information xxxx, then
iscsiadm -m node -T xxxx -p 192.168.0.5
iscsiadm -m node -T xxxx -p 192.168.0.5 -l

other useful iscsi commands:
iscsiadm -m session [-P1 | -P3]
login all Luns exported on the target: iscsiadm -m discovery -t st -l
node and discovery database directory:  /var/lib/iscsi
disconnect: iscsiadm -m node -T target_iqn_name -p ipaddress -u
remove target from database so it won't connect upon reboot: iscsiadm -m node -T target_iqn_name -p ipaddress --op delete
delete all bindings for iface0: iscsiadm -m node -I iface0 --op=delete
logout all target: iscsiadm -m node -U all
login all node: iscsiadm -m node -L all
rescan lun:  iscsiadm -m node -p 192.168.40.10 --rescan
Change default iscsi replacement timeout from 120s to 15s based on redhat recommendation:
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 10
The replacement_timeout setting will control how long to wait for session re-establishment before failing pending SCSI commands up to multipath:
node.session.timeo.replacement_timeout = 15
And add this statement to the device section in /etc/multipath.conf:
features                "1 queue_if_no_path"

Setting up DM-Multipath

References

Installation 

# yum install device-mapper-multipath
# cp /usr/share/doc/device-mapper-multipath*/multipath.conf /etc

whitelist local disk sda

# /lib/udev/scsi_id --whitelisted --replace-whitespace –-device=/dev/sda 3600508b1001030353434363646301289
Uncomment and modify the blacklist section within the /etc/multipath.conf file to include the scsi id of the local disk on the system. Once complete, save the changes made to  the multipath.conf file.
blacklist {  wwid 3600508b1001030353434363646301289
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" 
devnode "^hd[a-z]"
devnode "^sd[a]$"  #add this for making sure sda is blacklisted
#The reason for blacklisting a second time with a regular expression is in case the scsi_id program fails to read the WWID  #from sector zero of a local device. See the blacklist section in the configuration example. The  #WWID line and devnode “^sd[a]$” line both serve as a blacklist for device sda.
}
# Start the multipath daemon.
# service multipathd start
Starting multipathd daemon: [ OK ]
6. Enable the multipath daemon to ensure it is started upon boot time. # chkconfig multipathd on
7. Identify the dm- device, size, and WWID of each device mapper volume for Oracle  data disks and recovery disks. In this example, volume mpathb is identified via the  following command: # multipath -ll
8. Uncomment the defaults section found within the /etc/multipath.conf file. defaults {  udev_dir /dev  polling_interval 10  path_selector "round-robin 0"
path_grouping_policy multibus 
getuid_callout "/lib/udev/scsi_id --whitelisted  --device=/dev/%n" 
prio alua  path_checker readsector0 
rr_min_io 100 
max_fds 8192 
rr_weight priorities 
failback immediate 
# no_path_retry fail   # comment out this as we already put 'feature "1 queue if _no_path"' . see https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/DM_Multipath/queueifnopath_issues.html  user_friendly_names yes  }
9. find out the mapping for lun name and wwid
# more /root/lun.sh
for x in /dev/dm-* ; do export lunid=$( /usr/bin/sg_inq --page=0x83 ${x} | grep "^ 00" | cut -d" " -f17 | awk '{ print strtonum( "0x" $1 ) };' ) ; export wwid=$( /sbin/scsi_id --whitelisted --replace-whitespace --device=${x} ) ; echo ${lunid} == ${x} == ${wwid}; done
Eventually, run /root/lun.sh on both nodes to confirm the consistency on both nodes
10. Uncomment the multipath section found within the /etc/multipath.conf file and create  an alias for each device mapper volume in order to enable persistent naming of those  volumes. Once complete, save the changes made to the multipath.conf file.
multipaths
 {
  multipath {
wwid 3600c0ff000d7e7a899d8515101000000
alias data1
}
multipath {
wwid 3600c0ff000dabfe5a7d8515101000000
alias data2
}
 multipath {
wwid 3600c0ff000d7e7a8dbd8515101000000
alias reco1
}
multipath {
 wwid 3600c0ff000dabfe5f4d8515101000000
alias reco2
 } 
bla bla
}
10.Restart the device mapper multipath daemon. # service multipathd restart ok  Stopping multipathd daemon: [ OK ]  Starting multipathd daemon: [ OK ]
11. verify it by multipath -ll
12. reload udev rules
Reload udev command: udevcontrol reload_rules

Partitioning Device Mapper Shared Disks

Partitioning of the device mapper shared disks is only required when using Oracle ASMLib.
For the simplification of ensuring to meet all requirements, this reference architecture creates  a partition for each device mapper volume. For each device mapper volume, create a partition using parted. An example is shown below.
# parted /dev/mapper/db1 mklabel gpt mkpart primary "1 -1"
Information: You may need to update /etc/fstab.
Once the partition is created, a newly created device mapper device is created as db1p1.
# ls -l /dev/mapper/data1p1
 lrwxrwxrwx. 1 root root 8 Apr 16 15:15 /dev/mapper/data1p1 -> ../dm-11
NOTE: A newly created partition requires the alias name followed by p1 such as data1p1 seen  above. If p1 is missing, please run the following command to add the partition mappings to  the device mapper disks. And you should run command below on another node to generate all *.p1 files
# kpartx -a /dev/mapper/data1
Setting up udev
1. As the root user, identify the Device Mapper Universally Unique IDentifier (DM_UUID)  for each device mapper volume. The example below shows the DM_UID for the  partitions of the volumes labeled db1,db2,fra, and redo. 
# for i in data1p1 data2p1 ... reco1p1 reco2p1; do printf "%s %s\n" "$i" "$(udevadm  info --query=all --name=/dev/mapper/$i | grep -i dm_uuid)"; done 
data1p1 E: DM_UUID=part1-mpath-3600c0ff000d7e7a899d8515101000000 
data2p1 E: DM_UUID=part1-mpath-3600c0ff000dabfe5a7d8515101000000 
reco1p1 E: DM_UUID=part1-mpath-3600c0ff000d7e7a8dbd8515101000000
reco2p1 E: DM_UUID=part1-mpath-3600c0ff000dabfe5f4d8515101000000
2. Create a file labeled 99-oracle-asmdevices.rules within /etc/udev/rules.d/
3. Within 99-oracle-asmdevices.rules file, create rules for each device similar to the  example below: KERNEL=="dm-*",ENV{DM_UUID}=="part1-mpath-3600c0ff000dabfe5f4d8515101000000",OWNER="oracle",GROUP="oinstall",MODE="0660"
KERNEL=="dm-*",ENV{DM_UUID}=="<enter-value-according-to-your-environment>",OWNER="oracle",GROUP="oinstall",MODE="0660"
4. Save the file labeled 99-oracle-asmdevices.rules
5. reboot to check if the owner and group are changed.

Windows VM iscsi timeout when doing controller giveback for Netapp storage

Jephe Wu - http://linuxtechres.blogspot.com

Problem: Windows VM iscsi drive timeout and disappear after Netapp giveback operation, which caused Microsoft SQL server 2012 down, as data files are on iscsi D drive.
Objective:  find out why iscsi drive disappeared during giveback operation
Environment:  Windows 2008 R2 VM sitting on ESXi 5.1 cluster, D drive is iscsi drive on Netapp ONTAP 7 mode storage, VM is using Microsoft software iscsi initiator connecting Netapp portal target group.



Observation
When doing giveback between two controller heads on Netapp, iscsi drive on ESXi Windows 2008 R2 VM lost connection to the target which caused D drive timeout then disappear, which caused SQL server 2012 down. After around 18 minutes, iscsi drive reconnected back, SQL server restarted and operation resumed.

There was no any issues during takeover for Netapp, only there's issue during giveback.

Root Cause
After some research, the KB article from Netapp below indicated the problem:

Microsoft iSCSI SW Initiator takes a long time to reconnect to the filer after disruption. - http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=202007

I've pasted above KB article as follows:
------------------

Bug ID202007
TitleMicrosoft iSCSI SW Initiator takes a long time to reconnect to the filer after disruption.
Duplicate of
Bug Severity3 - Serious inconvenience
Bug StatusClosed
ProductData ONTAP
Bug TypeISCSI - Windows 
Description Formatted
 During initial target discovery ("Add Target"), the Microsoft iSCSI SW
 Initiator uses the iSCSI SendTargets command, to retrieve from the target
 a list of IP addresses at which the target can be accessed.
 
 In a filer configuration with multiple physical networks or multiple VLANs,
 it is possible that some of the filer's addresses are not accessible to
 a given host.  In this situation, the SendTargets response sent by the
 filer will advertise some addresses which are not accessible by that host.
 
 When the Microsoft SW initiator loses connectivity to the target (such
 as during filer reboot, takeover, and giveback), the initiator attempts
 to restablish connectivity to the target using the following default
 algorithm, which Microsoft calls 'port-hopping':
 
   - attempt to reconnect over the same IP address which was being
     used before the disruption
   - cycle through the other IP addresses from the SendTargets response,
     attempting to reconnect, until connectivity is reestablished.
 
 Each inaccessible IP address in the list can add a delay of 15-20
 seconds, the TCP connection establishment timeout.  If there are many
 inaccessible IP addresses in the list, it may take a long time for the
 Microsoft initiator to cycle through the list before it finally
 successfully reconnect to the target.  If the total reconnect time
 exceeds the timeout configured on the host (MaxRequestHoldTime (non-MPIO),
 or PDORemovePeriod (MPIO)), the application will result in I/O errors.
 
Workaround Formatted
 This long reconnect time can be minimized by disabling the use of
 the Microsoft 'port-hopping' technique.  This is achieved by directing
 the Microsoft iSCSI initiator to use a specific IP address to create
 a TCP connection. The steps are:
 
 1. In the "Logon to target" box, click "Advanced ..."
 2. In the "Target Portal" list, change the value from "Default" to a
    specific IP address.  Select the same filer IP address as was
    originally specified in the "Add Target Portal" dialog under 
    "Discovery" tab.
 
 After the disruption occurs, the Microsoft initiator will use only the
 IP address previously specified in the advanced logon setting to reconnect
 to the filer and will not try other IP addresses advertised in the
 SendTargets response.
 
Notes Formatted
 
Fixed-In VersionThis bug is not scheduled to be fixed, you may opt to open a technical support case if you would like to contact NetApp regarding the status of this bug. A complete list of releases where this bug is fixed is available here.
Related Bugs
Bug Watch StatusThis bug is unwatchable.
--------------------

And also the article below explained above issue
http://software.tectrade.co.uk/SAN/NSeries/gc52129616.pdf  page 16 and 17

-------------
Microsoft iSCSI SW Initiator takes a long time to reconnect to the storage
system after disruption
In a storage system configuration with multiple physical networks or multiple
VLANs, the Microsoft iSCSI software Initiator can take several minutes to
reconnect to the storage system.

During initial target discovery (Add Target), the Microsoft iSCSI software
initiator uses the iSCSI SendTargets command to retrieve a list of IP addresses
at which the target can be accessed.

In a storage system configuration with multiple physical networks or multiple
VLANs, it is possible that some of the storage system's addresses are not
accessible to a given host. In this situation, the SendTargets response sent by
the storage system will advertise some addresses which are not accessible by
that host.

When the Microsoft iSCSI initiator loses connectivity to the target (such as
during storage system reboot, takeover, and giveback), the initiator attempts
to reestablish connectivity to the target using the following default algorithm,
which Microsoft calls “port-hopping”:

1 Attempt to reconnect over the same IP address which was being used
before the disruption.
2 Cycle through the other IP addresses from the SendTargets response,
attempting to reconnect, until connectivity is reestablished.
Each inaccessible IP address in the list can add a delay of 15-20 seconds,
which is the TCP connection establishment timeout. If there are many
inaccessible IP addresses in the list, it may take a long time for the iSCSI
initiator to cycle through the list before successfully reconnecting to the target.
If the total reconnect time exceeds the timeout configured on the host
(MaxRequestHoldTime for non-MPIO, or PDORemovePeriod for MPIO), the
Windows applications experience I/O errors.

This long reconnect time can be minimized by disabling the use of the
Microsoft “port-hopping” algorithm by using a specific target IP address for
each connection in the iSCSI Initiator.

Disabling the Microsoft iSCSI port-hopping algorithm
Disable the Microsoft iSCSI port-hopping algorithm in the iSCSI Initiator to
minimize the recovery time in configurations with many iSCSI target ports.
1. Open the Microsoft iSCSI initiator applet and select the Targets tab.
2. Click Log On.
3. In the Logon to target dialog box, click Advanced.
4. In the Target Portal list, change the value from Default to one of the
storage system IP addresses specified in the Target Portals list on the
Discovery tab.

After a disruption occurs, the Microsoft initiator uses only the IP address
specified to reconnect to the storage system and does not try other IP
addresses advertised in the SendTargets response.

Note: If the specified IP address is unreachable, no failover occurs.

---------------------

Note: Changing from 'default' to specific IP in advanced setting will be persistent across the reboot, see Microsoft support replied as follows:

----------
Once you have set the ISCSI configuration to use the specific IP address. Even though if we restart the server or the session gets disconnected the bindings are persistent. Unfortunately there is no specific utility by which we can confirm that it’s still using the Specific IP, but as per the configuration it will remain as it is.
This setting will remain persistent until and unless the entries from the Discovery Tab is removed. Once the entry from Discovery Tab is removed. We will have to re-configure once again with the specific IP`s.
------------------


How to Prove above solution from Netapp KB 
Install Wireshark on Windows VM, enable all interfaces monitoring and filter traffic only for iscsi (tcp.port==3260) During giveback operation. You will notice it will try all the IPs from non-stroage facing Interface if it cannot communicate with the correct IP in certain period
References

What are the parameters that control how MS iSCSI survives lost TCP connections without causing applications harm?

==========
During transient loss of connection, instead of reporting "Device not available" immediately, the Microsoft iSCSI initiator will try to reconnect to the target and resubmit outstanding SCSI commands.
There are three registry values related MS iSCSI retry behavior, found in the following path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\[Instance_Number]\Parameters
Note: the [Instance_Number] may be different from system to system, depending on how many SCSI adapters already exist on the system.
    The three registry values are:
  1. DelayBetweenReconnect [default: 5 (seconds)]
  2. MaxConnectionRetries [default: 0xFFFFFFFF, infinite]
  3. MaxRequestHoldTime [default: 60 (seconds)]
Explanations: Normally you don't need to modify DelayBetweenReconnect and MaxConnectionRetries. The MaxRequestHoldTime is probably the only one that you may want to change. It defines how long Microsoft iSCSI initiator should hold and retry outstanding commands, before notifying upper layer of a Device Removal event. This event usually causes I/O failures to applications using the iSCSI disk. MaxRequestHoldTime is only relevant with non-MPIO environments. When MPIO is involved, this value is ignored.
Device Removal event can be bad for applications actively using an iSCSI Logical Unit Number (LUN), especially if a cable-pull, filer reboot, filer cluster failover, etc., takes more than MaxRequestHoldTime of 60 seconds to recover. Unless you have special requirement that need the retry window to be smaller or larger, 180 (seconds) is a good value to start with.
Note: Even after a Device Removal event is reported, Microsoft iSCSI initiator will still keep trying to reconnect to the target, as defined by the first two registry values,DelayBetweenReconnect and MaxConnectionRetries.
The Windows iSCSI host must be rebooted after changing the registry value(s).
=============