I. How To Merge Two Switches With Different Active Zone Sets??

I. How to merge two switches with different active zone sets??
Brocade Switches:
How to merge two switches with different active zone sets."
Merging Two B-series Directors and/or Switches with Different Active Zoning Configuration
Before Beginning The following procedure is disruptive to fabric traffic.:
--It will require disabling the switch and the removal of the effective zoning configurations at one step. Removing this
configuration will stop the data flow. Since this step in the procedure takes only a few moments to complete, data should resume
as soon as the new configuration is activated.
To evaluate the impact on an OS platforms and applications, please refer to the ESN Topology Guide for OS platform timeout
recommendations as well as the actual configuration files of the servers to identify their current timeout settings.
Supported Director and Switch Types

The following information on fabric merging applies to the following EMC Director and Switch types:
ED-12000B
DS-32B2
DS-16B2
DS-16B
DS-8B
NOTE: Also applies to similar OEM version of these switch types. See ESM for latest switch firmware qualification prior to
merging non-EMC Directors and/or Switches into an EMC SAN.
Host Requirements:
A host computer with a FTP service is required.
Merging
1. Log into the first switch via telnet or WebTools

a. Known as “swo1” for this example
b. For DS-16Bs, DS-8Bs, and comparable switch models running firmware 2.5.0d and above, default access zoning must be set
to “ALLACCESS”
NOTE: This is an offline command that will interrupt data flow.
1. Issue switchdisable command
2. Issue configure command
3. Enter “y” when prompted for “Zoning Operation parameters”
4. Enter “1” when prompted for “Default Access”
5. Enter “n” for all other parameters
6. Issue switchenable command
2. Upload the first switch (or one switch of a multi-switch fabric) configuration to a host using FTP
a. Use configupload command or use WebTools
b. Name the file “sw01_config.txt”
1. All zoning and configuration data for this switch will be located in this file.
3. Log into the second switch via telnet or WebTools
a. Known as “sw02” for this example
b. For DS-16Bs, DS-8Bs, and comparable switch models running firmware 2.5.0d and above, default access zoning must be set
to “ALLACCESS”
4. Upload the switch configuration to a host using FTP
5. Open in a text editor (i.e. Microsoft Word, VI, emacs, etc) for both “sw01_config.txt” and “sw02_config.txt” files
a. The uploaded configuration contains a list of switches in the fabric, list of ISLs, list of ports, name server data, and zoning
information.
b. For the purposes of merging, one need only be concerned with the zoning section of the uploaded configuration, which may
be found at the end of the file. It contains zones, aliases, and defined and effective configurations.
Example sw01_config.txt Zoning Section

[Zoning]
cfg.cfg_1:zone_1
zone.zone_1:10:00:00:08:00:00:00:01
alias.HBA1:10:00:00:08:00:00:00:01
enable:cfg_1
[Zoning]
cfg.cfg_2:zone_2
zone.zone_2:10:00:00:00:09:00:00:02
alias.HBA2:10:00:00:00:09:00:00:02
enable:cfg_2
6. Make a copy of “sw01_config.txt” and rename the copy as “configmerge.txt”

7. Copy aliases from “sw02_config.txt”
a. Highlight and copy the alias data
8. Paste aliases from “sw02_config.txt” to “configmerge.txt”
a. Paste under existing alias data in “configmerge.txt”
9. Copy zones from “sw02_config.txt”
a. Highlight and copy the zone data
10. Paste zones from “sw02_config.txt” to “configmerge.txt”
a. Paste under existing zone data in “configmerge.txt”
11. Copy zone names from “cfg.cfg” line of “[Zoning]” section from “sw02_config.txt” to “configmerge.txt”
a. Copy zone name(s) to “cfg.cfg” line after existing zones separating each zone with a semicolon
b. The last zone name will not be followed by a semicolon
Example Configmerge.txt Zoning Section After Paste from sw02_config.txt

[Zoning]
cfg.cfg_1:zone_1;zone_2
zone.zone_1:10:00:00:08:00:00:00:01
zone.zone_2:10:00:00:00:09:00:00:02
alias.HBA1:10:00:00:08:00:00:00:01
alias.HBA2:10:00:00:00:09:00:00:02
enable:cfg_1
NOTE: Areas highlighted in red above illustrate the additions from “sw02_config.txt”
12. Save changes to “configmerge.txt”
13. Download “configmerge.txt” to sw01
a. Use configdownload command or use WebTools
1. If using configdownload command, the switch must be manually disabled before downloading commences. Use the
switchdisable command. After completion, the switch must be manually enabled. Use the switchenable command.
2. Using WebTools automatically disables and re-enables the switch.
b. After downloading, the newly merged configuration is automatically the effective configuration because it is already specified in
the “[Zoning]” section as the enabled configuration.
14. Issue cfgsave command on sw01
a. Saves the configuration to flash
15. Issue cfgshow command to see defined and effective zoning configurations
Example Output of cfgshow Command on sw01 After Configmerge.txt is Downloaded
Defined configuration:
cfg: cfg_1 zone_1; zone_2
zone: zone_1 10:00:00:08:00:00:00:01
zone: zone_2 10:00:00:00:09:00:00:02
alias: HBA1 10:00:00:08:00:00:00:01
alias: HBA2 10:00:00:00:09:00:00:02
Effective configuration:
cfg: cfg_1
zone: zone_1 Protocol:ALL 10:00:00:08:00:00:00:01
16. On sw02, issue the following commands to remove both defined and effective zoning configurations
a. cfgdisable
b. cfgclear
c. cfgsave
Example Output of “cfgshow” Command on Second Switch After Removing the Configuration
no configuration defined
no configuration in effect
18. Connect the switches via a fiber optic cable to the ports chosen to be E_ports.
a. sw02 will inherit the zoning data from sw01 when they exchange fabric parameters.
NOTE: Be sure to check that both switches have unique Domain IDs. Be sure to check the fabric parameters such as EDTOV,
RATOV, Data Field Size, Core Switch PID are identical.
19. Issue cfgshow command on second switch to see defined and effective zoning configurations.
Example Output of cfgshow Command on sw02 After Fabric Merge
zone: zone_1 10:00:00:08:00:00:00:01
zone: zone_2 10:00:00:00:09:00:00:02
alias: HBA1 10:00:00:08:00:00:00:01
alias: HBA2 10:00:00:00:09:00:00:02
cfg: cfg_1
NOTE: Zoning configurations on both switches are now identical.

20. Issue switchshow and fabricshow commands to verify a successful fabric merge
Hope this info will help you to replace a switch in your enviornment or merge.
Managing a Fibre Channel SAN

There are different type of SAN like IP SAN, NAS over SAN etc... We will discuss about Fibre Channel SAN. It gives you more option in
order to manage and minimize downtime means reducing company cost.
In general if you think storage environments, physical interfaces to storage consisted of parallel SCSI channels supporting a small
number of SCSI devices. With Fibre Channel, the technology provides a means to implement robust storage area networks that may
consist of 100’s of devices. Fibre Channel storage area networks yield a capability that supports high bandwidth storage traffic on the
order of 100 MB/s, and enhancements to the Fibre Channel standard will support even higher bandwidth in the near future.
Depending on the implementation, several different components can be used to build a Fibre Channel storage area network. The Fibre
Channel SAN consists of components such as storage subsystems, storage devices, and server systems that are attached to a Fibre
Channel network using Fibre Channel adapters. Fibre Channel networks in turn may be composed of many different types of
interconnect entities. Examples of interconnect entities are switches, hubs, and bridges.
There are various type of SAN implementation so lets discuss little bit about physical view and logical view of SAN.
The physical view allows the physical components of a SAN to be identified and the associated
physical topology between them to be understood. Similarly, the logical view allows the relationships and associations between SAN
entities to be identified and understood.
Physical View
From a physical standpoint, a SAN environment typically consists of four major classes of components. These four classes are:
· End-user platforms such as desktops and/or thin clients;
· Server systems;
· Storage devices and storage subsystems;
· Interconnect entities.
Typically, network facilities based on traditional LAN and WAN technology provide connectivity between end-user platforms and server
system components. However in some cases, end-user platforms may be attached to the Fibre Channel network and may access
storage devices directly. Server system components in a SAN environment can exist independently or as a cluster. As processing
requirements continue to increase, computing clusters are becoming more prevalent.
We are using new term cluster. this itself is big topic to cover but we will have brief idea about cluster. A cluster is defined as a group of
independent computers managed as a single system for higher availability, easier manageability, and greater scalability. Server system
components are
interconnected using specialized cluster interconnects or open clustering technologies such as the Fibre Channel - Virtual Interface
mapping. Storage subsystems are connected to server systems, to end–user platforms, and to each other using the facilities of a Fibre
Channel network. The Fibre Channel network is made up of various interconnect entities that may include switches, hubs, and bridges.
Logical View
From a logical perspective, a SAN environment consists of SAN components and resources, as well as their relationships,
dependencies and other associations. Relationships, dependencies, and associations between SAN components are not necessarily
constrained by physical connectivity. For example, a SAN relationship may be established between a client and a
group of storage devices that are not physically co-located. Logical relationships play a key role in the management of SAN
environments. Some key relationships in the SAN environment are identified below:
· Storage subsystems and interconnect entities;

· Between storage subsystems;
· Server systems and storage subsystems (including adapters);
· Server systems and end-user components;
· Storage and end-user components;
· Between server systems.
As a specific example, one type of relationship is the concept of a logical entity group. In this case, server system components and
storage components are logically classified as connected components because they are both attached to the Fibre Channel network. A
logical entity group forms a private virtual network or zone within the SAN environment with a specific set of
connected entities as members. Communication within each zone is restricted to its members.
In another example, where a Fibre Channel network is implemented using a switched fabric, the Fibre Channel network may further still
be broken down into logically independent sections called sub-fabrics for each possible combination of data rate and class of service.
Sub-fabrics are again divided into regions and extended-regions based on compatible service parameters.
Regions and extended regions can also be divided into partitions called zones for administrative purposes.
Host HBA installation and configuration

To display what HBA's are installed.
#prtdiag -v
#dmesg
#cat /var/adm/messages grep -i wwn more
To set the configuration you must carry out the following:
-changes to the /etc/system file

-HBA driver modifications
-Persistent binding (HBA and SD driver config file)
-EMC recommended changes
-Install the Sun StorEdge SAN Foundation package
Changes to /etc/system: ( Plz ignore 3 equal sign when u edit the file)
SCSI throttle === set sd:sd_max_throttle=20

Enable wide SCSI === set scsi_options=0x7F8
SCSI I/O timeout value === sd:sd_io_time=0x3c (with powerpath)
sd:sd_io_time=0x78 (without powerpath
Changes to HBA driver (/kernel/drv/lpfc.conf):
fcp-bind-WWNN=16
automap=2
fcp-on=1
lun-queue-depth=20
tgt-queue-depth=512
no-device-delay=1 (without PP/DMP) 0 (with PP/DMP)
xmt-que-size=256
scan-down=0
linkdown-tmo=0 (without PP/DMP) 60 (with PP/DMP)
Persistent Binding
Both the lpfc.conf and sd.conf files need to be updated. General format is
name="sd" parent="lpfc" target="X" lun="Y" hba="lpfcZ"
X is the target number that corresponds to the fcp_bindWWNID lpfcZtXY is the LUN number that corresponds to symmetrix volume
mapping on the symmetrix port WWN or HLU on the clariionZ is the lpfc drive instance number that corresponds to the fcp_bind_WWID
lpfcZtX
To discover the SAN devices

#disk;devlinks;devalias (solaris 2.6)
#devfsadm (solaris 2.8)
#/usr/sbin/update_drv -f sd (solaris 2.9 >)
Windows
To display what HBA's are installed. use admin tool "device manager"
#Registry edits
#EMC recommended changes
#Install emulex exlcfg utility
Arbitrated loop without powerpath/ATF:-
InitLinkFlags=0x00000000 (arbitrated loop, auto-link speed)

WaitReady=45
LinkDown=45
TranslateQueueFull=1
Arbitrated loop with powerpath/ATF:
InitLinkFlags=0x00000000 (arbitrated loop, auto-link speed)

WaitReady=10
LinkDown=10
Fabric without powerpath/ATF:
InitLinkFlags=0x00000002 (fabric, auto-link speed

WaitReady=45
LinkDown=45
TranslateQueueFull=1
Fabric with powerpath/ATF:
InitLinkFlags=0x00000002 (fabric, auto-link speed)

WaitReady=10
LinkDown=10
Modifying the EMC environment :

In the shortcut for the elxcfg add the "--emc" option to the target option.
control panel -> admin tools -> computer management -> select disk management -> (top menu)action -> rescan tools
HP
To display what HBA's are installed.
#/opt/fcms/bin/fcmsutil /dev/td# (A5158A HBA)

#/opt/fc/bin/fcutil /dev/fcs# (A6685A HBA)
On a HP system there is no additional software to install. The HP systems Volume address setting must be enabledon the SAN, you
can check this will the following command.
#symcfg -sid -FA all list (confirm that the volume set addressing is set to yes)
To discover the SAN devices:

#ioscan -fnC disk (scans hardware busses for devices according to class)
#insf -e (install special device files)
AIX
To display what HBA's are installed

#lscfg
#lscfg -v -l fcs*

#List HBA WWN and entry on system
#Determine code level of OS and HBA
#Download and install EMC ODM support fileset
#run /usr/lpp/Symmetrix/bin/emc_cfgmgr (symmetrix) #or /usr/lpp/emc/CLARiiON/bin/emc_cfgmgr (clariion)

#/usr/lpp/EMC/Symmetrix/bin/emc_cfgmgr -v
if the above does not work reboot server
Hope this will be documented and useful info for novice user.
Handling BCV and Clone Disk on Veritas Volume Manager.

Handling BCV and Clone Disk on Veritas Volume Manager.
Get Output of Vxdisk List command
# vxdisk list
Vxdisk list command showing that some disks are marked with the udid_mismatch flag.
Write a New UUID to Disk
You can use the following command to update the unique disk identifier (UDID) for one or more disks:
# vxdisk [-f] [-g diskgroup] updateudid disk ...
Note : The -f option must be specified if VxVM has not raised the udid_mismatch flag for a disk.
Importing a disk group containing cloned/BCV disks
You can then import the cloned disks by specifying the -ouseclonedev=on option to the vxdgimport command, as shown in this
example:
# vxdg -o useclonedev=on [-o updateid] import mydg ( Group Name )
Note: This form of the command allows only cloned disks to be imported. All non-cloned disks remain unimported. .) However, the
import fails if multiple copies of one or more cloned disks exist.
You can use the following command to tag all the disks in the disk group that are to be imported:
# vxdisk [-g diskgroup] settag tagname disk ...
where tagname is a string of up to 128 characters, not including spaces or tabs.

For example, the following command sets the tag, my_tagged_disks, on several disks that are to be imported together:
You can use the following command to ensure that a copy of the metadata is placed on a disk, regardless of the placement policy for
the disk group:
# vxdisk [-g diskgroup] set disk keepmeta=always
Alternatively, use the following command to place a copy of the configuration

database and kernel log on all disks in a disk group that share a given tag:
# vxdg [-g diskgroup] set tagmeta=on tag=tagname nconfig=all nlog=all
To check which disks in a disk group contain copies of this configuration information, use the vxdglistmeta command:
# vxdg [-q] listmeta diskgroup
The tagged disks in the disk group may be imported by specifying the tag to the vxdgimport command in addition to the
-ouseclonedev=on option:
# vxdg -o useclonedev=on -o tag=my_tagged_disks import mydg
If you have already imported the non-cloned disks in a disk group, you can use
the -n and -t option to specify a temporary name for the disk group containing
the cloned disks:
# vxdg -t -n clonedg -o useclonedev=on -o tag=my_tagged_disks import mydg
iSCSI details
I tried to collect some good information on iSCSI driver details which was request by some reader. Hope this will help you on iSCSI
queries. Leave comment if it is useful... I will try to write iSCSI overview in next entry. Happy Reading!!!!!!
The iSCSI driver provides a transport for SCSI requests and responses to storage devices via an IP network instead of using a direct
attached SCSI bus channel or an FC connection. The SN 5400 Series Storage Router, in turn, transports these SCSI requests and
responses received via the IP network between it and the storage devices attached to it. Once the iSCSI driver is installed, the host will
proceed with a discovery process for storage devices as follows:
1. The iSCSI driver requests available targets through the SendTargets discovery mechanism as configured in the /etc/iscsi.conf
configuration file.
2. Each iSCSI target sends available iSCSI target names to the iSCSI driver.
3. The iSCSI driver discovery daemon process looks up each discovered target
in the /etc/iscsi.bindings file. If an entry exists in the file for the target, the corresponding SCSI target ID is assigned to the target. If no
entry exists for the target, the smallest available SCSI target ID is assigned and an entry is written to the /etc/iscsi.bindings file. The
driver then sends a login request to the iSCSI target.
4. The iSCSI target accepts the login and sends target identifiers.
5. The iSCSI driver queries the targets for device information.
6. The targets respond with the device information.
7. The iSCSI driver creates a table of available target devices.
Once the table is completed, the iSCSI targets are available for use by the
host using all the same commands and utilities as a direct attached (e.g., via
a SCSI bus) storage device.
- All Linux kernels released on or before Feb 4, 2002 have a known bug in the buffer and page cache design. When any writes to a
buffered block device fail, it is possible for the unwritten data to be discarded from the caches, even though the data was never written
to disk. Any future reads will get the prior contents of the disk, and it is possible for applications to get no errors reported.
This occurs because block I/O write failures from the buffer cache simply mark the buffer invalid when the write fails. This leaves the
buffer marked clean and invalid, and it may be
discarded from the cache at any time. Any future read either finds no existing buffer or finds the invalid buffer, so the read will fetch old
data from disk and place it in the cache. If the fsync(2) function initiated the write, an error may be returned. If memory pressure on the
cache initiated the write, the unwritten buffer may be discarded before fsync(2) is ever called, and in that case fsync will be unaware of
the data loss, and will incorrectly report success. There is currently no reliable way for an application to ensure that data written to
buffered block devices has actually been written to disk. Buffered data may be lost whenever a buffered
block I/O device fails a write. The iSCSI driver attempts to avoid this problem by retrying disk
commands for many types of failures. The MinDiskCommandTimeout defaults to "infinite", which disables the command timeout,
allowing commands to be retried forever if the storage device is unreachable or unresponsive.
- All Linux kernels up to and including 2.4.20 have a bug in the SCSI device initialization code. If kernel memory is low, the initialization
code can fail to allocate command blocks needed for proper operation, but will do nothing to prevent I/O from being queued to the non-
functional device. If a process queues an I/O request to a SCSI device that has no command blocks allocated, that process will block
forever in the kernel, never exiting and ignoring all signals sent to it while blocked. If the LUN probes initiated by the iSCSI driver are
blocked forever by this problem, it will not be possible to stop or unload the iSCSI driver, since the driver code will still
be in use. In addition, any other LUN probes initiated by the iSCSI driver will also block, since any other probes will lock waiting for the
probe currently in progress to finish. When the failure to allocate command blocks occurs, the kernel will log a message similar to the
following:
***************************************************************
kernel: scsi_build_commandblocks: want=12, space for=0 blocks
In some cases, the following message will also be logged:
kernel: scan_scsis: DANGER, no command blocks
***************************************************************
- Linux kernels 2.2.16 through 2.2.20 and 2.4.0 through 2.4.18 are known to have a problem in the SCSI error recovery process. In
some cases, a successful device reset may be ignored and the SCSI layer will continue on to the later stages of the error recovery
process. The problem occurs when multiple SCSI commands for a particular device are queued in the low-level SCSI driver when a
device reset occurs. Even if the low-level driver correctly reports that all the commands for the device have been completed by the
reset, Linux will assume only one command has been completed and continue the error recovery process. (If only one command has
timed out or failed, Linux will correctly terminate the error recovery process following
the device reset.) This action is undesirable because the later stages of error recovery may send other types of resets, which can affect
other SCSI initiators using the same target or other targets on the same bus. It is also undesirable because there are more serious
bugs in the later stages of the Linux SCSI error recovery process. The Linux iSCSI driver now attempts to avoid this problem by
replacing the usual error recovery handler for SCSI commands that timeout or fail.
- Linux kernels 2.2.16 through 2.2.20 and 2.4.0 through 2.4.2 may take SCSI devices offline after Linux issues a reset as part of the
error recovery process. Taking a device offline causes all I/O to the device to fail until the HBA driver is reloaded. After the error
recovery process does a reset, it sends a SCSI Test Unit Ready command to check if the SCSI target is operational
again. If this command returns SCSI sense data, instead of correctly retrying the command, Linux will treat it as a fatal error, and
immediately take the SCSI device offline.
The Test Unit Ready will almost always be returned with sense data because most targets return a deferred error in the sense data of
the first command received after a reset. This is a way of telling the initiator that a reset has occurred. Therefore, the affected Linux
kernel versions almost always take a SCSI device offline after a reset occurs.
This bug is fixed in Linux kernels 2.4.3 and later. The Linux iSCSI driver now attempts to avoid this problem by replacing the usual error
recovery handler for SCSI commands that timeout or fail.
- Linux kernels 2.2.16 through 2.2.21 and 2.4.0 through 2.4.20 appear to have problems when SCSI commands to disk devices are
completed with a check condition/unit attention containing deferred sense data. This can result in applications receiving I/O errors, short
reads or short writes. The Linux SCSI code may deal with the error by giving up reading or writing the first buffer head of a command,
and retrying the remainder of the I/O.
The Linux iSCSI driver attempts to avoid this problem by translating deferred sense data to current sense data for commands sent to
disk devices.
- Linux kernels 2.2.16 through 2.2.21 and 2.4.0 through 2.4.20 may crash on a NULL pointer if a SCSI device is taken offline while one
of the Linux kernel's I/O daemons (e.g. kpiod, kflushd, etc.) is trying to do I/O to the SCSI device. The exact cause of this problem is still
being investigated.
Note that some of the other bugs in the Linux kernel's error recovery handling may result in a SCSI device being taken offline, thus
triggering this bug and resulting in a Linux kernel crash.
- Linux kernels 2.2.16 through 2.2.21 running on uniprocessors may hang if a SCSI disk device node is opened while the Linux SCSI
device structure for that node is still being initialized.
This occurs because the sd driver which controls SCSI disks will loop forever waiting for a device busy flag to be cleared at a certain
point in the open routine for the disk device. Since this particular loop will never yield control of the processor, the process initializing the
SCSI disk device is not allowed to run, and the initialization process can never clear the device busy flag which the sd driver is
constantly checking.
A similar problem exists in the SCSI generic driver in some 2.4 kernel versions. The sg driver may crash on a bad pointer if a /dev/sg*
device is opened while it is being
initialized.
- Linux kernels prior to 2.4.20-8 (Redhat 9 distribution) had a problem of a rare occurrence of data corruption. This data can be buffer
cache data as well as raw I/O data. This problem occurs when iSCSI driver sends the I/O request down to TCP. Linux iSCSI driver
handles this problem by copying the incoming I/O buffer temporarily in an internal buffer and then sending the copied data down to TCP.
This way the iSCSI driver keeps the original data intact. In case, this sent data gets corrupted (this gets detected by turning on CRC),
the driver repeats the foregoing process.
The iSCSI Driver Version 3.2.1 for Linux is compatible with SN 5400 Series Storage Routers running software version 3.x or greater. It
is not compatible with SN 5400 Series Storage Routers running software versions 1.x or 2.x.
===============================================================================
CONFIGURING AND USING THE DRIVER
===============================================================================
This section describes a number of topics related to configuring and using the iSCSI Driver for Linux. The topics covered include:
Starting and Stopping the iSCSI driver
Rebooting Linux
Device Names
Auto-Mounting Filesystems
Log Messages
Dynamic Driver Reconfiguration
Target Portal Failover
iSCSI HBA Status
Using Multipath I/O Software
Making Storage Configuration Changes
Target and LUN Discovery Limits
Dynamic Target And LUN Discovery
Persistent Target Binding
Target Authentication
Editing The iscsi.conf File
iSCSI Commands and Utilities
Driver File Listing
--------------------------------------
STARTING AND STOPPING THE iSCSI DRIVER
--------------------------------------
To manually start the iSCSI driver enter:
/etc/init.d/iscsi start
The iSCSI initialization will report information on each detected
device to the console or in dmesg(8) output. For example:
********************************************************************
Vendor: SEAGATE Model: ST39103FC Rev: 0002
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: hdwr sector= 512 bytes.
Sectors= 17783240 [8683 MB] [8.7 GB]
sda: sda1
********************************************************************
The directory /proc/scsi/iscsi will contain a file (the controller
number) that contains information about the iSCSI devices.
To see the iscsi devices currently available on this system, use the utility:
/usr/local/sbin/iscsi-ls -l
If there are problems loading the iSCSI kernel module, diagnostic information will be placed in /var/log/iscsi.log.
To manually stop the iSCSI driver enter:
/etc/init.d/iscsi stop
When the driver is stopped, the init.d script will attempt to kill all processes using iSCSI devices by first sending them "SIGTERM" and
then by sending any remaining processes "SIGKILL". The init.d script will then unmount all iSCSI devices in /etc/fstab.iscsi and kill the
iSCSI daemon terminating all connections to iSCSI devices. It is important to note that the init.d script may not be able to successfully
unmount filesystems if they are in use by processes that can't be killed. It is recommended that the you manually stop all applications
using the filesystem on iSCSI devices before stopping the driver. Filesystems not listed in /etc/fstab.iscsi will not be unmounted by the
script and should be manually unmounted prior to a system shutdown.
It is very important to unmount all filesystems on iSCSI devices before stopping the iSCSI driver. If the iSCSI driver is stopped while
iSCSI devices are mounted, buffered writes may not be committed to disk and file system corruption may occur.
---------------
REBOOTING LINUX
---------------
The Linux "reboot" command should not be used to reboot the system while iSCSI devices are mounted or being used since the
"reboot" command will not execute the iSCSI shutdown script in /etc/rc6.d/ and file system corruption may occur. To safely reboot a
Linux system, enter the
following command:
/sbin/shutdown -r now
All iSCSI devices should be unmounted prior to a system shutdown or reboot.
• ------------
DEVICE NAMES
------------
Because Linux assigns SCSI device nodes dynamically whenever a SCSI logical unit is detected, the mapping from device
nodes (e.g., /dev/sda or /dev/sdb) to iSCSI targets and logical units may vary.
Variations in process scheduling and network delay may result in iSCSI targets being mapped to different SCSI device nodes
every time the driver is started. Because of this variability, configuring applications or operating system utilities to use the
standard SCSI device nodes to access iSCSI devices may result in SCSI commands being sent to the wrong target or logical
unit.
To provide a more reliable namespace, the iSCSI driver scans the system to determine the mapping from SCSI device nodes
to iSCSI targets, and then creates a tree of directories and symbolic links under /dev/iscsi to make it easier to use a particular
iSCSI target's logical units.
Under /dev/iscsi, there will be a directory tree containing subdirectories for each iSCSI bus number, each target id number on
the bus, and each logical unit number for each target. For
example, the whole disk device for bus 0, target id 0, LUN 0 would be /dev/iscsi/bus0/target0/lun0/disk.
In each logical unit directory there will be a symbolic link for each SCSI device node that may be connected to that particular
logical unit. These symbolic links are modeled after the Linux
devfs naming convention.
The symbolic link 'disk' will map to the whole-disk SCSI device node
(e.g., /dev/sda, /dev/sdb, etc.).
The symbolic links 'part1' through 'part15' will map to each
partition of that SCSI disk (e.g., /dev/sda1, dev/sda15, etc.).
Note that these links will exist regardless of the number of disk partitions. Opening the partition devices will result in an error if
the partition does not actually exist on the disk.
The symbolic link 'mt' will map to the auto-rewind SCSI tape device node for this LUN (e.g., /dev/st0), if any. Additional links for
'mtl', 'mtm', and 'mta' will map to the other auto-rewind devices (e.g., /dev/st0l, /dev/st0m, /dev/st0a), regardless of whether
these
device nodes actually exist or could be opened. The symbolic link 'mtn' will map to the no-rewind SCSI tape device node for
this LUN (e.g., /dev/nst0), if any. Additional links for 'mtln', 'mtmn', and 'mtan' will map to the other no-rewind devices (e.g.,
/dev/nst0l, /dev/nst0m, /dev/nst0a), regardless of whether those device nodes actually exist or could be opened. The symbolic
link 'cd' will map to the SCSI cdrom device node for this LUN (e.g., /dev/scd0), if any.
The symbolic link 'generic' will map to the SCSI generic device
node for this LUN (e.g., /dev/sg0), if any.
Because the symlink creation process must open all of the SCSI
device nodes in /dev in order to determine which nodes map to
iSCSI devices, you may see many modprobe messages logged to syslog
indicating that modprobe could not find a driver for a particular
combination of major and minor numbers. This is harmless, and can
be ignored. The messages occur when Linux is unable to find a
driver to associate with a SCSI device node that the iSCSI daemon
is opening as part of it's symlink creation process. To prevent
these messages, the SCSI device nodes with no associated high-level
SCSI driver can be removed.
-------------------------
AUTO-MOUNTING FILESYSTEMS
-------------------------
Filesystems installed on iSCSI devices cannot be automatically mounted at
system reboot due to the fact that the IP network is not yet configured at
mount time. However, the driver provides a method to auto-mount these
filesystems as soon as the iSCSI devices become available (i.e., after the IP
network is configured).
To auto-mount a filesystem installed on an iSCSI device, follow these steps:
1. List the iSCSI partitions to be automatically mounted in
/etc/fstab.iscsi which has the same format as /etc/fstab. The
/etc/fstab.iscsi file will not be overwritten when the driver is
installed nor will removing the current version of the driver delete
/etc/fstab.iscsi. It is left untouched during an install.
2. For each filesystem on each iscsi device(s), enter the logical volume on
which the filesystem resides. The mount points must exist for the
filesystems to be mounted. For example, the following /etc/fstab.iscsi
entries will mount the two iSCSI devices specified (sda and sdb):
*************************************************************************
#device mount FS mount backup fsck
#to mount point type options frequency pass
/dev/sda /mnt/t0 ext2 defaults 0 0
/dev/sdb /mnt/t1 ext2 defaults 0 0
*************************************************************************
3. Upon a system restart, the iSCSI startup script invokes the
iscsi-mountall script will try to mount iSCSI devices listed in
/etc/fstab.iscsi file. iscsi-mountall tries to mount the iSCSI devices
for "NUM_RETRIES" (default value 10) number of times, at an interval of
"SLEEP_INTERVAL" seconds (default value 1) between each attempt, giving
the driver the time to establish a connection with an iSCSI target.
The value of these parameters can be changed in the iscsi-mountall script
if the devices are not getting configured in the system within the
default time periods.
Due to variable network delays, targets may not always become available in the
same order from one boot to the next. Thus, the order in which iSCSI devices
are mounted may vary and may not match the order the devices are listed in
/etc/fstab.iscsi You should not assume mounts of iSCSI devices will occur in
any particular order.
Because of the variability of the mapping between SCSI device nodes
and iSCSI targets, instead of directly mounting SCSI device nodes,
it is recommended to either mount the /dev/iscsi tree symlinks,
mount filesystem UUIDs or labels (see man pages for mke2fs, mount,
and fstab), or use logical volume management (see Linux LVM) to
avoid mounting the wrong device due to device name changes resulting
from iSCSI target configuration changes or network delays.
------------
LOG MESSAGES
------------
The iSCSI driver contains components in the kernel and user level.
The log messages from these components are sent to syslog. Based on the
syslogd configuration on the Linux host, the messages will be sent to the
appropriate destination. For example, if /etc/syslog.conf has the following
entry:
*.info /var/log/messages
then all log messages of level 'info' or higher will be sent to
/var/log/messages.
If /etc/syslog.conf has the following entry:

*.info;kern.none /var/log/messages
then all log messages (except kernel messages) of level info or higher
will be sent to /var/log/messages.
If /etc/syslog.conf has the following entry:
kern.* /dev/console
then all kernel messages will be sent to the console.
All messages from the iSCSI driver when loading the iSCSI kernel
module will be placed in /var/log/iscsi.log.
The user can also use dmesg(8) to view the log messages.
------------------------------
DYNAMIC DRIVER RECONFIGURATION
------------------------------
Configuration changes can be made to the iSCSI driver without having to stop
it or reboot the host system. To dynamically change the configuration of the
driver, follow the steps below:
1. Edit /etc/iscsi.conf with the desired configuration changes.
2. Enter the following command:
/etc/init.d/iscsi reload
This will cause the iSCSI daemon to re-read /etc/iscsi.conf file and to
create any new DiscoveryAddress connections it finds. Those discovery
sessions will then discover targets and create new target connections.
Note that any configuration changes will not affect existing target sessions.
For example, removal of a DiscoveryAddress entry from /etc/iscsi.conf
will not cause the removal of sessions to targets discovered through this
DiscoveryAddress, but it will cause the removal of the discovery session
corresponding to the deleted DiscoveryAddress.
----------------------
TARGET PORTAL FAILOVER
----------------------
Some SN 5400 Series Storage Routers have multiple Gigabit Ethernet ports.
Those systems may be configured to allow iSCSI target access via multiple
paths. When the iSCSI driver discovers targets through a multi-port SN 5400
Series system, it also discovers all the IP addresses that can be used to
reach each of those targets.
When an existing target connection fails, the iSCSI driver will attempt to
connect to that target using the next available IP address. You can also
choose a preferred portal to which the iSCSI driver should attempt to connect
to when the iSCSI driver is started or whenever automatic portal failover
occurs. This is significant in a situation when you want the connection
to the targets to be made through a faster network portal (for example, when
the I/Os are going through a Gigabit Ethernet interface and you do not
prefer the connection to failover to a slower network interface).
The preference for portal failover can be specified through the
"PreferredPortal" or "PreferredSubnet" parameter in /etc/iscsi.conf.
If this preference is set, then on any subsequent failover the driver will
first try to failover to the preferred portal or preferred subnet whichever
is specified in the conf file. If both preferred portal and preferred subnet
entries are present in the conf file then the preferred portal takes
precedence. If the preferred portal or preferred subnet is unreachable,
then the driver will continuously rotate through the list of available
portals until it finds one that is active.
The Portal Failover feature is turned on by default and the whole process of
failover occurs automatically. You can chose to turn off portal failover
by disabling the portal failover parameter in /etc/iscsi.conf.
If a target advertises more than one network portal, you can manually
switch portals by writing to the HBA's special file in /proc/scsi/iscsi/.
For example, if a target advertises two network portals:
10.77.13.248:3260 and 192.168.250.248:3260.
If the device is configured with targetId as 0, busId as 0, HBA's host
number is 3 and you want to switch the target from
10.77.13.248 to 192.169.250.248, use the following command:
echo "target 0 0 address 192.168.250.248" > /proc/scsi/iscsi/3
Where the syntax is:
echo "target address " >
/proc/scsi/iscsi/
The host system must have multiple network interfaces to effectively
utilize this failover feature.
----------------
iSCSI HBA STATUS
----------------
The directory /proc/scsi/iscsi will contain a special file that can be
used to get status from your iSCSI HBA. The name of the file will
be the iSCSI HBA's host number, which is assigned to the driver
by Linux.
When the file is read, it will show the driver's version number,
followed by a list all iSCSI targets and LUNs the driver has found
and can use.
Each line will show the iSCSI bus number, target id number, and
logical unit number, as well as the IP address, TCP port, and
iSCSI TargetName. If an iSCSI session exists, but no LUNs have
yet been found for a target, the LUN number field will contain a
question mark. If a TCP connection is not currently established,
the IP address and port number will both appear as question marks.
----------------------------
USING MULTIPATH I/O SOFTWARE
----------------------------
If a third-party multipath I/O software application is being used in
conjunction with the iSCSI driver (e.g., HP Secure Path), it may be
necessary to modify the configuration of the driver to allow the
multi-pathing software to operate more efficiently. If you are using
a multipath I/O application, you may need to set the "ConnFailTimeout"
parameter of the iSCSI driver to a smaller value so that SCSI commands
will fail more quickly when an iSCSI network connection drops allowing
the multipath application to try a different path to for access to the
storage device. Also, you may need to set the "MaxDiskCommandTimeout"
to a smaller value (e.g., 5 or 10 seconds), so that SCSI commands to
unreachable or unresponsive devices will fail more quickly and the
multipath software will know to try a different path to the storage device.
Multipath support in the iSCSI driver can be turned on by setting
Multipath=<"yes" or "portal" or "portalgroup"> in /etc/iscsi.conf.
If Multipath=<"yes" or "portal">, then the discovered targets that
are configured to allow access via multiple paths will have a separate
iSCSI session created for each path (i.e., iSCSI portal). The target
portal failover feature should not be used if Multipath=<"yes" or "portal">
since multiple sessions will be established with all available paths.
------------------------------------
MAKING STORAGE CONFIGURATION CHANGES
------------------------------------
Making changes to your storage configuration, including adding or
removing targets or LUNs, remapping targets, or modifying target
access, may change how the devices are presented to the host operating
system. This may require corresponding changes in the iSCSI driver
configuration and /etc/vfstab file.
It is important to understand the ramifications of SCSI routing
service configuration changes on the hosts accessing the associated
storage devices. For example, changing the instance configuration
may change the device presentation to the host's iSCSI driver,
effectively changing the name or number assigned to the device
by the host operating system. Certain configuration changes,
such as adding or deleting targets, adding or deleting LUNs
within a particular target, or adding or deleting entire instances
may change the order of the devices presented to the host.
Even if the host is only associated with one SCSI routing
service instance, the device order could make a difference.
Typically, the host operating system assigns drive identifications
in the order they are received based on certain criteria. Changing
the order of the storage device discovery may result in a changed
drive identification. Applications running on the host may require
modifications to appropriately access the current drives.
If an entire SCSI routing service instance is removed, or there
are no targets available for the host, the host's iSCSI driver
configuration file must be updated to remove the appropriate
reference before restarting the iSCSI driver. If a host's iSCSI
configuration file contains an IP address of a SCSI routing
service instance that does not exist, or has no targets available
for the host, the iSCSI driver will not complete a login and
will keep on trying to discover targets associated with this SCSI
routing service instance.
In general, the following steps are normally required when reconfiguring
iSCSI storage:
1. Unmount any filesystems and stop any applications using iSCSI
devices.
2. Stop the iSCSI driver by entering:
/etc/init.d/iscsi stop
3. Make the appropriate changes to the iSCSI driver
configuration file. Remove any references to iSCSI
DiscoveryAddresses that have been removed, or that
no longer have valid targets for this host.
4. Modify /etc/fstab.iscsi and application configurations as
appropriate.
5. Restart the iSCSI driver by entering:
/etc/init.d/iscsi start
Failure to appropriately update the iSCSI configuration using
the above procedure may result in a situation that prevents
the host from accessing iSCSI storage resources.
-------------------------------
TARGET AND LUN DISCOVERY LIMITS
-------------------------------
The bus ID and target ID are assigned by the iSCSI initiator driver
whereas the lun ID is assigned by the iSCSI target. The driver provides
access to a maximum of 256 bus IDs with each bus supporting 256 targets
and each target capable of supporting 256 LUNs. Any discovered iSCSI
device will be allocated the next available target ID on bus 0.
If a target ID > 256 on bus 0, then a next available target ID on bus 1
will be allocated. If a bus ID > 256 and LUN ID > 256 it will be ignored
by the driver and will not be configured in the system.
--------------------------------
DYNAMIC TARGET AND LUN DISCOVERY
--------------------------------
When using iSCSI targets that support long-lived iSCSI discovery sessions,
such as the Cisco 5400 Series, the driver will keep a discovery session
open waiting for change notifications from the target. When a notification
is received, the driver will rediscover targets, add any new targets, and
activate LUNs on all targets.
If a new LUN is dynamically added to an existing target on a SCSI routing
instance with which the driver has established a connection, then the driver
does not automatically activate the new LUN. The user can manually activate
the new LUN by executing the following command:
echo "scsi add-single-device " >
/proc/scsi/scsi
where;
HBA#: is the controller number present under /proc/scsi/iscsi/
bus-id: is the bus number present on controller .
target-id: is the target ID present on ,.
LUN: new LUN added dynamically to the target.
-------------------------
PERSISTENT TARGET BINDING
-------------------------
This feature ensures that the same iSCSI bus and target id number are used
for every iSCSI session to a particular iSCSI TargetName, and a Linux SCSI
target always maps to the same physical storage device from one reboot to
the next.
This feature ensures that the SCSI numbers in the device symlinks described
above will always map to the same iSCSI target.
Note that because of the way Linux dynamically allocates SCSI device nodes
as SCSI devices are found, the driver does not and cannot ensure that any
particular SCSI device node (e.g., /dev/sda) will always map to the same
iSCSI TargetName. The symlinks described in the section on Device Names are
intended to provide a persistent device mapping for use by applications and
fstab files, and should be used instead of direct references to particular
SCSI device nodes.
The file /etc/iscsi.bindings is used by the iSCSI daemon to store bindings of
iSCSI target names to SCSI target ID's. If the file doesn't exist,
it will be created when the driver is started. If an entry exists for a
discovered target, the Linux target ID from the entry is assigned to the
target. If no entry exists for a discovered target, an entry is written to
the file. Each line of the file contains the following fields:
BusId TargetId TargetName
An example file would be:
*****************************************************************************
0 0 iqn.1987-05.com.cisco.00.7e9d6f942e45736be69cb65c4c22e54c.disk_one
0 1 iqn.1987-05.com.cisco.00.4d678bd82965df7765c788f3199ac15f.disk_two
0 2 iqn.1987-05.com.cisco.00.789ac4483ac9114bc6583b1c8a332d1e.disk_three
*****************************************************************************
Note that the /etc/iscsi.bindings file will permanently contain entries
for all iSCSI targets ever logged into from this host. If a target is
no longer available to a host you can manually edit the file and remove
entries so the obsolete target no longer consumes a SCSI target ID.
If you know the iSCSI target name of a target in advance, and you want
it to be assigned a particular SCSI target ID, you can add an entry
manually. You should stop the iSCSI driver before editing the
/etc/iscsi.bindings file. Be careful to keep an entire entry on a single
line, with only whitespace characters between the three fields. Do not
use a target ID number that already exists in the file.
*****************************************************************************
NOTE: iSCSI driver versions prior to 3.2 used the file /var/iscsi/bindings
instead of /etc/iscsi.bindings. The first time you start the new driver
version, it will change the location and the name of the bindings file
to /etc/iscsi.bindings
*****************************************************************************
---------------------
TARGET AUTHENTICATION
---------------------
The CHAP authentication mechanism provides for two way authentication between
the target and the initiator. The authentication feature on the SN 5400
system has to be enabled to make use of this feature. The username and
password for both initiator side and target side authentication needs to be
listed in /etc/iscsi.conf. The username and password can be specified as
global values or can be made specific to the target address. Please refer to
the Editing The iscsi.conf File section of this document for a more detailed
description of these parameters.
---------------------------
EDITING THE ISCSI.CONF FILE
---------------------------
The /etc/iscsi.conf file is used to control the operation of the iSCSI driver by allowing the user to configure the values for a
number of programmable parameters. These parameters can be setup to apply to specific configuration types or they can be
setup to apply globally. The configuration types that are supported are:
• DiscoveryAddress = SCSI routing instance IP address with format a.d.c.d or a.b.c.d:n or hostname.
• TargetName = Target name in 'iqn' or 'eui' format eg: TargetName = iqn.1987-05.com.cisco:00.0d1d898e8d66.t0
• TargetIPAddress = Target name with format a.b.c.d/n
• Subnet = Network portal IP address with format a.b.c.d/n or a.b.c.d&hex
• Address = Network portal IP address with format a.b.c.d/32
The complete list of parameters that can be applied either globally or to the configuration types listed above are shown below.
Not all parameters are applicable to all configuration types.
• Username = CHAP username used for initiator authentication by the target.
• OutgoingUsername = <>
• Password = CHAP password used for initiator authentication by the target.
• OutgoingPassword = <>
• IncomingUsername = CHAP username for target authentication by the initiator.
• IncomingPassword = CHAP password for target authentication by the initiator.
• HeaderDigest = Type of header digest support the initiator is requesting of the target.
• DataDigest = Type of data digest support the initiator is requesting of the target.
• PortalFailover = Enabling/disabling of target portal failover feature.
• PreferredSubnet = IP address of the subnet that should be used for a portal failover.
• PreferredPortal = IP address of the portal that should be used for a portal failover.
• Multipath = Enabling/disabling of multipathing feature.
• LoginTimeout = Time interval to wait for a response to a login request to be received from a target before failing a connection
attempt.
• AuthTimeout = Time interval to wait for a response to a login request containing authentication information to be received from
a target before failing a connection attempt.
• IdleTimeout = Time interval to wait on a connection with no traffic before sending out a ping.
• PingTimeout = Time interval to wait for a ping response after a ping is sent before failing a connection.
• ConnFailTimeout = Time interval to wait before failing SCSI commands back to an application for unsuccessful commands.
• AbortTimeout = Time interval to wait for a abort command to complete before declaring the abort command failed.
• ResetTiemout = Time interval to wait for a reset command to complete before declaring the reset command failed.
• InitialR2T = Enabling/disabling of R2T flow control with the target.
• MaxRecvDataSegmentLength = Maximum number of bytes that the initiator can receive in an iSCSI PDU.
• FirstBurstLength = Maximum number of bytes of unsolicited data the initiator is allowed to send.
• MaxBurstLength = Maximum number of bytes for the SCSI payload negotiated by initiator.
• TCPWindowSize = Maximum number of bytes that can be sent over a TCP connection by the initiator before receiving an
acknowledgement from the target.
• Continuous = Enabling/disabling the discovery session to be kept alive.
A detailed description for each of these parameters is included in both the man page and the included sample iscsi.conf file.
Please consult these sources for examples and more detailed programming instructions.
----------------------------
iSCSI COMMANDS AND UTILITIES
----------------------------
This section gives a description of all the commands and utilities available with the iSCSI driver.
- "iscsi-ls" lists information about the iSCSI devices available to the driver. Please refer to the man page for more information.
LUN Management
LUN Basics
Simply stated, a LUN is a logical entity that converts raw physical disk space into logical storage space that a host server's operating
system can access and use. Any computer user recognizes the logical drive letter that has been carved out of their disk drive. For
example, a computer may boot from the C: drive and access file data from a different D: drive. LUNs do the same basic job. "LUNs
differentiate between different chunks of disk space. "A LUN is part of the address of the storage that you're presenting to a [host]
server."
LUNs are created as a fundamental part of the storage provisioning process using software tools that typically accompany the particular
storage platform. However, there is not a 1-to-1 ratio between drives and LUNs. Numerous LUNs can easily be carved out of a single
disk drive. For example, a 500 GB drive can be partitioned into one 200 GB LUN and one 300 GB LUN, which would appear as two
unique drives to the host server. Conversely, storage administrators can employ Logical Volume Manager software to combine multiple
LUNs into a larger volume. Veritas Volume Manager from Symantec Corp. is just one example of this software. In actual practice, disks
are first gathered into a RAID group for larger capacity and redundancy (e.g., RAID-50), and then LUNs are carved from that RAID
group.
LUNs are often referred to as logical "volumes," reflecting the traditional use of "drive volume letters," such as volume C: or volume F:
on your computer. But some experts warn against mixing the two terms, noting that the term "volume" is often used to denote the large
volume created when multiple LUNs are combined with volume manager software. In this context, a volume may actually involve
numerous LUNs and can potentially confuse storage allocation. "The 'volume' is a piece of a volume group, and the volume group is
composed of multiple LUNs,"
Once created, LUNs can also be shared between multiple servers. For example, a LUN might be shared between an active and
standby server. If the active server fails, the standby server can immediately take over. However, it can be catastrophic for multiple
servers to access the same LUN simultaneously without a means of coordinating changed blocks to ensure data integrity. Clustering
software, such as a clustered volume manager, a clustered file system, a clustered application or a network file system using NFS or
CIFS, is needed to coordinate data changes.
SAN zoning and masking
LUNs are the basic vehicle for delivering storage, but provisioning SAN storage isn't just a matter of creating LUNs or volumes; the
SAN fabric itself must be configured so that disks and their LUNs are matched to the appropriate servers. Proper configuration helps to
manage storage traffic and maintain SAN security by preventing any server from accessing any LUN.
Zoning makes it possible for devices within a Fibre Channel network to see each other. By limiting the visibility of end devices, servers
(hosts) can only see and access storage devices that are placed into the same zone. In more practical terms, zoning allows certain
servers to see one or more ports on a disk array. Bandwidth, and thus minimum service levels, can be reserved by dedicating certain
ports to a zone or isolate incompatible ports from one another.
Consequently, zoning is an important element of SAN security and high-availability SAN design. Zoning can typically be broken down
into hard and soft zoning. With hard zoning, each device is assigned to a zone, and that assignment can never change. In soft zoning,
the device assignments can be changed by the network administrator.
LUN masking adds granularity to this concept. Just because you zone a server and disk together doesn't mean that the server should
be able to see all of the LUNs on that disk. Once the SAN is zoned, LUNs are masked so that each host server can only see specific
LUNs. For example, suppose that a disk has two LUNs, LUN_A and LUN_B. If we zoned two servers to that disk, both servers would
see both LUNs. However, we can use LUN masking to allow one server to see only LUN_A and mask the other server to see only
LUN_B. Port-based LUN masking is granular to the storage array port, so any disks on a given port will be accessible to any servers on
that port. Server-based LUN masking is a bit more granular where a server will see only the LUNs assigned to it, regardless of the other
disks or servers connected.
LUN scaling and performance

LUNs are based on disks, so LUN performance and reliability will vary for the same reasons. For example, a LUN carved from a Fibre
Channel 15K rpm disk will perform far better than a LUN of the same size taken from a 7,200 rpm SATA disk. This is also true of LUNs
based on RAID arrays where the mirroring of a RAID-0 group may offer significantly different performance than the parity protection of a
RAID-5 or RAID-6/dual parity (DP) group. Proper RAID group configuration will have a profound impact on LUN performance.
An organization may utilize hundreds or even thousands of LUNs, so the choice of storage resources has important implications for the
storage administrator. Not only is it necessary to supply an application with adequate capacity (in gigabytes), but the LUN must also be
drawn from disk storage with suitable characteristics. "We go through a qualification process to understand the requirements of the
application that will be using the LUNs for performance, availability and cost," For example, a LUN for a mission-critical database
application might be taken from a RAID-0 group using Tier-1 storage, while a LUN slated for a virtual tape library (VTL) or archive
application would probably work with a RAID-6 group using Tier-2 or Tier-3 storage.
LUN management tools

A large enterprise array may host more than 10,000 LUNs, so software tools are absolutely vital for efficient LUN creation, manipulation
and reporting. Fortunately, management tools are readily available, and almost every storage vendor provides some type of
management software to accompany products ranging from direct-attached storage (DAS) devices to large enterprise arrays.
Administrators can typically opt for vendor-specific or heterogeneous tools. A data center with one storage array or a single-vendor
shop would probably do well with the indigenous LUN management tool that accompanied their storage system. Multivendor shops
should at least consider heterogeneous tools that allow LUN management across all of the storage platforms. Mack uses EMC
ControlCenter for LUN masking and mapping, which is just one of several different heterogeneous tools available in the marketplace.
While good heterogeneous tools are available, he advises caution when selecting a multiplatform tool. "Sometimes, if the tool is written
by a particular vendor, it will manage 'their' LUNs the best," he says. "LUNs from the other vendors can take the back seat -- the
management may not be as well integrated."
In addition to vendor support, a LUN management tool should support the entire storage provisioning process. Features should include
mapping to specific array ports and masking specific host bus adapters (HBA), along with comprehensive reporting. The LUN
management tool should also be able to reclaim storage that is no longer needed. Although a few LUN management products support
autonomous provisioning, experts see some reluctance toward automation. "It's hard to do capacity planning when you don't have any
checks and balances over provisioning," Mack says, also noting that automation can circumvent strict change control processes in an
IT organization.
LUNs at work
Significant storage growth means more LUNs, which must be created and managed efficiently while minimizing errors, reigning in costs
and maintaining security. For Thomas Weisel Partners LLC, an investment firm based in San Francisco, storage demands have simply
exploded to 80 terabytes (TB) today -- up from about 8 TB just two years ago. Storage continues to flood the organization's data center
at about 2 TB to 3 TB each month depending on projects and priorities.
This aggressive growth pushed the company out of a Hitachi Data Systems (HDS) storage array and into a 3PARdata Inc. S400
system. LUN deployment starts by analyzing realistic space and performance requirements for an application. "Is it something that
needs a lot of fast access, like a database or something that just needs a file share?" asks Kevin Fiore, director of engineering services
at Thomas Weisel. Once requirements are evaluated, a change ticket is generated and a storage administrator provisions the
resources from a RAID-5 or RAID-1 group depending on the application. Fiore emphasizes the importance of provisioning efficiency,
noting that the S400's internal management tools can provision storage in just a few clicks.
Fiore also notes the importance of versatility in LUN management tools and the ability to move data. "Dynamic optimization allows me
to move LUNs between disk sets," he says. Virtualization has also played an important role in LUN management. VMware has allowed
Fiore to consolidate about 50 servers enterprise-wide along with the corresponding reduction in space, power and cooling. this lets the
organization manage more storage with less hardware.
LUNs getting large
As organizations deal with spiraling storage volumes, experts suggest that efficiency enhancing features, such as automation, will
become more important in future LUN management. Experts also note that virtualization and virtual environments will play a greater
role in tomorrow's LUN management. For example, it's becoming more common to provision very large chunks of storage (500 GB to 1
TB or more) to virtual machines. "You might provision a few terabytes to a cluster of VMware servers, and then that storage will be
provisioned out over time.
How to merge two switches with different active zone sets??

How to merge two switches with different active zone sets."
Merging Two B-series Directors and/or Switches with Different Active Zoning Configurations
Before Beginning The following procedure is disruptive to fabric traffic.:
--It will require disabling the switch and the removal of the effective zoning configurations at one step. Removing this configuration will
stop the data flow. Since this step in the procedure takes only a few moments to complete, data should resume as soon as the new
configuration is activated.
To evaluate the impact on an OS platforms and applications, please refer to the ESN Topology Guide for OS platform timeout
recommendations as well as the actual configuration files of the servers to identify their current timeout settings.
Supported Director and Switch Types

The following information on fabric merging applies to the following EMC Director and Switch types:
ED-12000B
DS-32B2
DS-16B2
DS-16B
DS-8B
NOTE: Also applies to similar OEM version of these switch types. See ESM for latest switch firmware qualification prior to merging non-
EMC Directors and/or Switches into an EMC SAN.
Host Requirements:
A host computer with a FTP service is required.
Merging
1. Log into the first switch via telnet or WebTools

a. Known as “swo1” for this example
b. For DS-16Bs, DS-8Bs, and comparable switch models running firmware 2.5.0d and above, default access zoning must be set to
“ALLACCESS”
2. Upload the first switch (or one switch of a multi-switch fabric) configuration to a host using FTP
3. Log into the second switch via telnet or WebTools
a. Known as “sw02” for this example
b. For DS-16Bs, DS-8Bs, and comparable switch models running firmware 2.5.0d and above, default access zoning must be set to
“ALLACCESS”
4. Upload the switch configuration to a host using FTP
5. Open in a text editor (i.e. Microsoft Word, VI, emacs, etc) for both “sw01_config.txt” and “sw02_config.txt” files
a. The uploaded configuration contains a list of switches in the fabric, list of ISLs, list of ports, name server data, and zoning
information.
b. For the purposes of merging, one need only be concerned with the zoning section of the uploaded configuration, which may be found
at the end of the file. It contains zones, aliases, and defined and effective configurations.

[Zoning]
cfg.cfg_1:zone_1
zone.zone_1:10:00:00:08:00:00:00:01
alias.HBA1:10:00:00:08:00:00:00:01
enable:cfg_1
[Zoning]
cfg.cfg_2:zone_2
zone.zone_2:10:00:00:00:09:00:00:02
alias.HBA2:10:00:00:00:09:00:00:02
enable:cfg_2
6. Make a copy of “sw01_config.txt” and rename the copy as “configmerge.txt”

7. Copy aliases from “sw02_config.txt”
a. Highlight and copy the alias data
8. Paste aliases from “sw02_config.txt” to “configmerge.txt”
a. Paste under existing alias data in “configmerge.txt”
9. Copy zones from “sw02_config.txt”
a. Highlight and copy the zone data
10. Paste zones from “sw02_config.txt” to “configmerge.txt”
a. Paste under existing zone data in “configmerge.txt”
11. Copy zone names from “cfg.cfg” line of “[Zoning]” section from “sw02_config.txt” to “configmerge.txt”
a. Copy zone name(s) to “cfg.cfg” line after existing zones separating each zone with a semicolon
b. The last zone name will not be followed by a semicolon
Example Configmerge.txt Zoning Section After Paste from sw02_config.txt

[Zoning]
cfg.cfg_1:zone_1;zone_2
zone.zone_1:10:00:00:08:00:00:00:01
zone.zone_2:10:00:00:00:09:00:00:02
alias.HBA1:10:00:00:08:00:00:00:01
alias.HBA2:10:00:00:00:09:00:00:02
enable:cfg_1
NOTE: Areas highlighted in red above illustrate the additions from “sw02_config.txt”
12. Save changes to “configmerge.txt”
13. Download “configmerge.txt” to sw01
a. Use configdownload command or use WebTools
1. If using configdownload command, the switch must be manually disabled before downloading commences. Use the switchdisable
command. After completion, the switch must be manually enabled. Use the switchenable command.
2. Using WebTools automatically disables and re-enables the switch.
b. After downloading, the newly merged configuration is automatically the effective configuration because it is already specified in the
“[Zoning]” section as the enabled configuration.
14. Issue cfgsave command on sw01
a. Saves the configuration to flash
Example Output of cfgshow Command on sw01 After Configmerge.txt is Downloaded
zone: zone_1 10:00:00:08:00:00:00:01
zone: zone_2 10:00:00:00:09:00:00:02
alias: HBA1 10:00:00:08:00:00:00:01
alias: HBA2 10:00:00:00:09:00:00:02
cfg: cfg_1
16. On sw02, issue the following commands to remove both defined and effective zoning configurations
a. cfgdisable
b. cfgclear
c. cfgsave
Example Output of “cfgshow” Command on Second Switch After Removing the Configuration
no configuration defined
no configuration in effect
18. Connect the switches via a fiber optic cable to the ports chosen to be E_ports.
a. sw02 will inherit the zoning data from sw01 when they exchange fabric parameters.
NOTE: Be sure to check that both switches have unique Domain IDs. Be sure to check the fabric parameters such as EDTOV, RATOV,
Data Field Size, Core Switch PID are identical.
19. Issue cfgshow command on second switch to see defined and effective zoning configurations.
Example Output of cfgshow Command on sw02 After Fabric Merge
zone: zone_1 10:00:00:08:00:00:00:01
zone: zone_2 10:00:00:00:09:00:00:02
alias: HBA1 10:00:00:08:00:00:00:01
alias: HBA2 10:00:00:00:09:00:00:02
cfg: cfg_1
NOTE: Zoning configurations on both switches are now identical.

20. Issue switchshow and fabricshow commands to verify a successful fabric merge
Hope this info will help you to replace a switch in your enviornment or merge.
Overview of RAID Striping

Very simply, RAID striping is a means of improving the performance of large storage systems. For most normal PCs or laptops, files are
stored in their entirety on a single disk drive, so a file must be read from start to finish and passed to the host system. With large
storage arrays, disks are often organized into RAID groups that can enhance performance and protect data against disk failures.
Striping is actually RAID-0; a technique that breaks up a file and interleaves its contents across all of the disks in the RAID group. This
allows multiple disks to access the contents of a file simultaneously. Instead of a single disk reading a file from start to finish, striping
allows one disk to read the next stripe while the previous disk is passing its stripe data to the host system -- this enhances the overall
disk system performance, which is very beneficial for busy storage arrays.
Parity can be added to protect the striped data. Parity data is calculated for the stripes and placed on another disk drive. If one of the
disks in the RAID group fails, the parity data can be used to rebuild the failed disk. However, multiple simultaneous disk failures may
result in data loss because conventional parity only accommodates a single disk failure.
RAID striping
The performance impact of RAID striping at the array and operating system level.
RAID striping or concatenation: Which has better performance?
Designing storage for performance is a very esoteric effort by nature. There are quite a few variables that need to be taken into
account.
RAID-50: RAID-5 with suspenders
RAID-50 combines striping with distributed parity for higher reliability and data transfer capabilities.
RAID-53: RAID by any other name
RAID-53 has a higher transaction rate than RAID-3, and offers all the protection of RAID-10, but there are disadvantages as well.
RAID-10 and RAID-01: Same or different?
The difference between RAID-10 and RAID-01 is explained.
RAID explained
RAID, or redundant array of independent disks, can make many smaller disks appear as one large disk to a server for better
performance and higher availability
EMC: Merging Fibre channel fabrics

You have two fabrics running off of two switches. You'd like to make them one fabric. How to do that?
For the most part, it's simply connecting the two switches via e_ports.
Before doing that, however, realize there's several factors that can prevent them from mergingg
Incompatible operating parameters such as RA_TOV and ED_TOV
• Duplicate domain IDs.
• Incompatible zoning configurations
• No principal switch (priority set to 255 on all switches)
• No response from the switch (hello sent every 30 seconds)
To avoid the issues above:
• Check IPs on all Service Processors and switches; deconflict as necessary.
• Ensure that all switches have unique domain ids.
• Ensure that operating parameters are the same.
• Ensure there aren't any zoning conflicts in the fabric (port zones, etc).
Once that's done:
• Physically link the switches
• View the active zone set to ensure the merge happens.
• Save the active zone set
• Activate the new zone set.
EMC: Enterprise SAN Fabric Topology Port Calculation
EMC recommends no more than four connectrix switches per fabric based on the following formulae:
One Switch
-32 Total ports

- 4 ports reserved for card failure
28 ports remaining.
- (int(28/5)) No more than 4:1 ratio, hosts : fa
23 Possible host connections
-2 to support multi-pathing
-11 total host connections
Two Switch
- 64 Total ports
- 4 ports reserved for E_ports
- 56 ports remaining.
-(int(56/5)) No more than 4:1 ratio, hosts : fa
-45 Possible host connections
-/ 2 to support multi-pathing
22 host connections (gain of 11)
Three switches
- 96 total ports
-80 ports remaining
-/ 2 to support multi-pathing
-32 host connections (gain of 10)
Four switches
-128 total ports
-100 ports remaining
- / 2 to support multi-pathing
-40 host connections (gain of 8)
Putting in that fourth connectrix means that you gain only 8 host connections from a 32 port connectrix switch.
Kashya :- Advances in Data Protection and Replication

Kashya (EMC Acquired last year ) develops unique algorithmic technologies to enable an order of
magnitude improvement in the reliability, cost, and performance of an enterprise’s data protection
capabilities. Based on the Kashya Data Protection Appliance platform, Kashya’s powerful solutions
deliver superior data protection at a fraction of the cost of existing solutions. Kashya’s Data Protection
Appliance connects to the SAN and IP infrastructure and provides bi-directional replication across any
distance for heterogeneous storage, SAN, and server environments.
The recent Storage industry challange is minimize downtime and how to keep business running 24 X
7 X 365. The data that drives today’s globally oriented businesses is stored on large networks of
interconnected computers and data storage devices. This data must be 100% available and always
accessible and up-to-date, even in the face of local or regional disasters. Moreover, these conditions
must be met at a cost that is affordable, and without in any way hampering normal company
operations.
To reduce the business risk of an unplanned event of this type, an enterprise must ensure that a copy
of its business-critical data is stored at a secondary location. Synchronous replication, used so
effectively to create perfect copies in local networks, performs poorly over longer distances.
Replication Method:
1) Synchronous – Every write transaction committed must be acknowledged from the

secondary site. This method enables efficient replication of data within the local
SAN environment.
2) Asynchronous – Every write transaction is acknowledged locally and then added to a
queue of writes waiting to be sent to the secondary site. With this method, some
data will normally be lost in the event of a disaster. This requires the same
bandwidth as a synchronous solution.
3) Snapshot –A consistent image of the storage subsystem is periodically transferred to the

secondary site. Only the changes made since the previous snapshot must be transferred, resulting in
significant savings in bandwidth. By definition, this solution produces a copy that is not up-to-date;
however, increasing the frequency of the snapshots can reduce the extent of this lag.
4) Small-Aperture Snapshot – Kashya’s system offers the unique ability to take frequent snapshots,
just seconds apart. This innovative feature is utilized to minimize the risk of data loss due to data corruption that typically follows
rolling disasters.
Kashya’s advanced architecture can be summarized as follows:

• Positioning atθ the junction between the SAN and the IP infrastructure enables Kashya
solutions to:
• Deploy enterprise-class data protection♣ non-disruptively and non-invasivel
• Support heterogeneous server, SAN, and♣ storage platforms
• Monitor SAN and WAN behavior on an ongoing basis, to♣ maximize the data
protection process
• Advanced algorithms, that:-θ Automatically manage the replication process, with strict
adherence to userdefined policies that are tied to user-specified business objectives
SAN Zoning in details

Lets discuss about most important thing in SAN environment ZONING. Zoning is the only way to restrict access for storage to all the
host. We will be discussing about Zoning in details.
There are two type of Zoning basically : Hard Zoning and Soft Zoning. Lets first define what is Zoning??
Zoning is nothing but map of host to device to device connectivity is overlaid on the storage networking fabric, reducing the risk of
unauthorized access.Zoning supports the grouping of hosts, switches, and storage on the SAN, limiting access between members of
one zone and resources in another.
Zoning also restricts the damage from unintentional errors that can corrupt storage allocations or destabilize the network. For example,
if a Microsoft Windows server is mistakenly connected to a fabric dedicated to UNIX applications, the Windows server will write header
information to each visible LUN, corrupting the storage for the UNIX servers. Similarly, Fibre Channel register state change notifications
(RSCN) that keep SAN entities apprised of configuration changes, can
sometimes destabilize the fabric. Under certain circumstances, an RSCN storm will overwhelm a
switch’s ability to process configuration changes, affecting SAN performance and availability for
all users. Zoning can limit RSCN messages to the zone affected by the change, improving overall
SAN availability.
By segregating the SAN, zoning protects applications against data corruption, accidental access,
and instability. However, zoning has several drawbacks that constrain large-scale consolidated
infrastructures.
Lets first discuss what are type of Zoning and pro and cos:
As I have mentioned earlier that Zoning got two types basically you can say three but only 2 types popular in industry.
1) Soft Zoning 2) Hard Zoning 3) Broadcast Zoning
Soft Zoning : Soft zoning uses the name server to enforce zoning. The World Wide Name (WWN) of the elements enforces the
configuration policy.
Pros:
- Administrators can move devices to different switch ports without manually reconfiguring
zoning. This is major flexibility to administrator. You don't need to change once you create zone set for particular device connected on
switch. You create a zone set on switch and allocate storage to host. You can change any port for device connectivity
Cons:
- Devices might be able to spoof the WWN and access otherwise restricted resources.
- Device WWN changes, such as the installation of a new Host Bus Adapter (HBA) card, require
policy modifications.
- Because the switch does not control data transfers, it cannot prevent incompatible HBA
devices from bypassing the Name Server and talking directly to hosts.
Hard Zoning: - Hard Zoning uses the physical fabric port number of a switch to create zones and enforce the policy.
Pros:
- This system is easier to create and manage than a long list of element WWNs.
- Switch hardware enforces data transfers and ensures that no traffic goes between
unauthorized zone members.
- Hard zoning provides stronger enforcement of the policy (assuming physical security on the
switch is well established).
Cons:
- Moving devices to different switch ports requires policy modifications.
Broadcast Zoning: · Broadcast Zoning has many unique characteristics:

- This traffic allows only one broadcast zone per fabric.
- It isolates broadcast traffic.
- It is hardware-enforced.
If you ask me how to choose the zoning type then it is based on SAN requirement in your data center environment. But port zoning is
more secure but you have to be sure that device is not going to change otherwise every time you change in storage allocation you have
to modify your zoning.
Generally use in industry is soft zoning but as i have mentioned soft zoning has many cos. So, it is hard to say which one you should
use always. So, analyze your datacenter environment and use proper zoning.
Broadcast zoning uses in large environment where are various fabric domain.
Having said that Zoning can be enforced either port number or WWN number but not both. When both port number and WWN specify a
zone, it is a software-enforced zone. Hardware-enforced zoning is enforced at the Name Server level and in the ASIC. Each ASIC
maintains a list of source port IDs that have permission to access any of the ports on that ASIC. Software-enforced zoning is exclusively
enforced through selective information presented to end nodes through the fabric Simple Name Sever (SNS).
If you know about switch then you must notice that in Cisco we have FCNS database and Brocade Name Server. Both are for same
purpose to store all the information about port and other. FCNS is stand for Fibre Channel Name Server.
There are plenty of thing on Switch itself to protect your SAN environment. Each vendor comes with different security policy. Zoning is
the basic thing in order to secure your data access.
Hope this info will be useful for beginner. Please raise a comment if you want to know specific things.
Different Vendor Worldwide Names WWN Details
Vendor Worldwide Names WWN :
Twenty-four of the sixty-four bit •World Wide Name• must be unique for every vendor. A partial listing of those vendors most familiar to
EMC with regard to Symmetrix Fibre Channel connectivity.
If decoding a HBA WWN, then issue an 8f, command to view the WWN in the FA login table. Bytes 1-3 of the World Wide Names
contain the unique vender codes. Note that if there is a switch connected between the FA and the host bus adapter, then the name and
fabric servers of the switch will login to the FA. These WWNs can be decoded in the same way as the HBA WWNs.
In the following example the unique vendor code is 060B00, this indicates that the HBA attached was supplied by Hewlett Packard.
UTILITY 8F -- SCSI Adapter utility : TIME: APR/23/01 01:23:30

------------------------------------
HARD LOOP ID : 000 (ALPA=EF) LINK STATE : ONLINE: LOOP

CHIP TYPE/REV: 00/00 Q RECS TOTAL: 3449 CREDIT: 0 RCV BUFF SZ: 2048
IF FLAGS : 01/ TAGD/NO LINK/NO SYNC/NO WIDE/NO NEGO/NO SOFT/NO ENVT/NO CYLN
IF FLAGS1: 08/NO PBAY/NO H300/NO RORD/ CMSN/NO QERR/NO DQRS/NO DULT/NO SUNP
IF FLAGS2: 00/NO SMNS/NO DFDC/NO DMNQ/NO NFNG/NO ABSY/NO SQNT/NO NRSB/NO SVAS
IF FLAGS3: 00/NO SCI3/NO ..../NO ..../NO ..../NO ..../NO ..../NO ..../NO ....
FC FLAGS : 57/ ARRY/ VOLS/ HDAD/NO HDNP/ GTLO/NO PTOP/ WWN /NO VSA
FC FLAGS1: 00/NO VCM /NO CLS2/NO OVMS/NO ..../NO ..../NO ..../NO ..../NO ....
FC FLAGS2: 00/NO ..../NO ..../NO ..../NO ..../NO ..../NO ..../NO ..../NO ....
FC FLAGS3: 00/NO ..../NO ..../NO ..../NO ..../NO ..../NO ..../NO ..../NO ....
HOST SID PORT NAME (WWN) NODE NAME RCV BUF CREDIT CLASS
-----------------------------------------------------------------------------
000001 50060B0000014932 50060B0000014933 992 EE 4 3
PRLI REQ: IFN RXD
DONE.
The following are common HBA vendor codes:
Refer to the open systems host matrix if you need to know whether these HBAs are supported for specific hosts.
00-00-D1 (hex) ADAPTEC INCORPORATED

0000D1 (base 16) ADAPTEC INCORPORATED
00-30-D3 (hex) Agilent Technologies

0030D3 (base 16) Agilent Technologies
00-60-69 (hex) BROCADE COMMUNICATIONS SYSTEMS

006069 (base 16) BROCADE COMMUNICATIONS SYSTEMS
00-02-A5 (hex) Compaq Computer Corporation

0002A5 (base 16) Compaq Computer Corporation
00-60-48 (hex) EMC CORPORATION

006048 (base 16) EMC CORPORATION
00-00-C9 (hex) EMULEX CORPORATION

0000C9 (base 16) EMULEX CORPORATION
00-E0-24 (hex) GADZOOX NETWORKS

00E024 (base 16) GADZOOX NETWORKS
00-60-B0 (hex) HEWLETT-PACKARD CO.

0060B0 (base 16) HEWLETT-PACKARD CO.
00-50-76 (hex) IBM
005076 (base 16) IBM
00-E0-69 (hex) JAYCOR NETWORKS, INC.

00E069 (base 16) JAYCOR NETWORKS, INC.
08-00-88 (hex) MCDATA CORPORATION

080088 (base 16) MCDATA CORPORATION
08-00-0E (hex) NCR CORPORATION

08000E (base 16) NCR CORPORATION
00-E0-8B (hex) QLOGIC CORP.

00E08B (base 16) QLOGIC CORP.
00-00-6B (hex) SILICON GRAPHICS INC./MIPS

00006B (base 16) SILICON GRAPHICS INC./MIPS
,
00-10-9B (hex) VIXEL CORPORATION
00109B (base 16) VIXEL CORPORATION
This information will help you to identify the vendor of particularar HBA's WWN.
How VERITAS Dynamic Multi-Pathing (DMP) works with a CLARiiON

array?
DMP With CLARiiON:-
CLARiiON arrays are active-passive devices that allow only one path at a time to be used for I/O. The path that is used for I/O is called
the active or primary path. An alternate path (or secondary path) is configured for use in the event that the primary path fails. If the
primary path to the array is lost, DMP automatically routes I/O over the secondary path or other available primary paths.
For active/passive disk arrays, VxVM uses the available primary path as long as it is accessible. DMP shifts I/O to the secondary path
only when the primary path fails. This is called "failover" or "standby" mode of operation for I/O. To avoid the continuous transfer of
ownership of LUNs from one controller to another, which results in a severe slowdown of I/O, do not access any LUN on other than the
primary path (which could be any of four available paths on a FC4700 and CX-Series arrays).
Note: DMP does not perform load balancing across paths for active-passive disk arrays.
DMP failover functionality is supported and should attempt to limit any scripts or processes from using the passive paths to the
CLARiiON array. This will prevent DMP from causing unwanted LUN trespasses.
To view potential trespasses, look at the ktrace (kt_std) information from SPcollect, messages similar the following can be seen
happening with regularity.
09:07:31.995 412 820f6440 LUSM Enter LU 34 state=LU_SHUTDOWN_TRESPASS

The "Enter LU ##" is the decimal array LUN number one would see in the Navisphere Manager browser. When the messages occur,
there will be no 606 trespass messages in the SP event logs. This is an indication that thetrespasses are the 'masked out' DMP
trespass messages. Executing I/Os to the /dev/dsk device entry will cause this to happen.
Using the SPcollect SP_navi_getall.txt file, check the storagegroup listing to find out which hosts these LUNs belong to. Then obtain
an EMCGrab/EMCReport from the affected hosts and you will need to look for a host-based process that could potentially be sending
I/O down the 'passive' path. Those I/Os can be caused by performance scripts, format or devfsadm commands being run or even host
monitoring software that polls all device paths.
One workaround is to install and configure EMC PowerPath. PowerPath disables the auto trespass mode and is designed to handle I/O
requests properly so that the passive path is not used unless required. This will require changing the host registration parameter
"failover mode" to a '1'. This failover mode is termed an "explicit mode" and it will resolve the type of trespass issues noted above.
Setting Failover Values for Initiators Connected to a Specific Storage System:
Navisphere Manager lets you edit or add storage system failover values for any or all of the HBA initiators that are connected to a
storage system and displayed in the Connectivity Status dialog box for that storage system.
1. In the Enterprise Storage dialog box, navigate to the icon for the storage system whose failover properties you want to add or edit.
2. Right-click the storage system icon, and click Connectivity Status.
3. In the Connectivity Status dialog box, click Group Edit to open the Group Edit Initiators dialog box.
4. Select the initiators whose New Initiator Information values you want to add or change, and then add or edit the values in Initiator
Type, ArrayCommPath and Failover Mode.
5. Click OK to save the settings and close the dialog box.
Navisphere updates the initiator records for the selected initiators, and registers any unregistered initiators.
Background Verify and Trespassing
Background Verify must be run by the SP that currently owns the LUN. Trespassing is a means of transferring current ownership of a
LUN from one SP to the other. Therefore, aborting a Background Verify is part of the trespass operation – it is a necessary step.
LSAN Zonng (Logical SAN)

An LSAN is a Logical Storage Area Network that spans multiple Physical fabrics and allows specified devices from these autonomous
fabrics to communicate with each other without merging the physical fabrics. In other word, A logical network that spans multiple
physical fabrics. It allows specified devices from the autonomous fabric to communicate with each other using a FC router without
merging the physical fabrics.
- A LSAN zone is a traditional zone with a special naming convention.
- Zone names must start with “LSAN_” or “lsan_” or “LSan_”
- LSAN zones are architecturally comaptiable with FOS and M-EOS
- FC Router uses LSAN zones to determine which devices need to be exported/imported into which routed fabrics.
- LSAN zones must be configured in all fabrics where the shared physical devices exist.
- The router performs zoning enforcement for edge fabrics at the ingress Router EX Port.
LSAN Implementation Rules:
- LSAN zone members must be defined using the device Port WWN, Zone members, including aliases, need to be defined using
WWPN.
- LSAN zone name on the routed fabrics do not need to be identical, but is recommended for ease of administration and
troubleshooting.
- LSAN zones in routed fabrics sharing devices are not required to have identical membership. Shared devices must exist in both
fabrics LSAN zones.
Once the LSAN zones are enabled, you will be able to check status of LSAN zones and members from the FC Router using the
command lsanzoneshow –s
Router:admin>lsanzoneshow –s
Fabric ID: 1 Zone Name: lsan_zone1
10:00:00:00:98:23:12:11 Exist
10:00:00:00:98:23:ab:cd Imported
Fabric ID: 2 Zone Name: lsan_zone1

10:00:00:00:98:23:12:11 Imported
10:00:00:00:98:23:ab:cd Exist
The output reveals what devices are “Exported (Exist) and Imported from all the routed fabrics.
Switch Interoperability Limitation

MDS Interoperability Mode Limitations
When a VSAN is configured for the default interoperability mode, the MDS 9000 Family of
switches is limited in the following areas when interoperating with non-MDS switches:
• Interop mode only affects the specified VSAN. The MDS 9000 switch can
still operate with full functionality in other non-interop mode VSANs. All switches that
partake in the interoperable VSAN should have that VSAN set to interop mode, even if
they do not have any end devices.
• Domain IDs are restricted to the 97 to 127 range, to accommodate
McData's nominal restriction to this same range. Domain IDs can either be set up
statically (the MDS 9000 switch will only accept one domain ID; if it does not get that
domain ID, it isolates itself from the fabric), or preferred (if the MDS 9000 switch does
not get the requested domain ID, it takes any other domain ID).
• TE ports and PortChannels cannot be used to connect an MDS 9000
switch to a non-MDS switch. Only E ports can be used to connect an MDS 9000 switch to
a non-MDS switch. However, TE ports and PortChannels can still be used to connect an
MDS 9000 switch to other MDS 9000 switches, even when in interop mode.
• Only the active zone set is distributed to other switches.
• In MDS SAN-OS Release 1.3(x), Fibre Channel timers can be set on a per
VSAN basis. Modifying the times, however, requires the VSAN to be suspended. Prior to
SAN-OS Release 1.3, modifying timers required all VSANs across the switch to be put into
the suspended state.
• The MDS 9000 switch still supports the following zoning limits per switch
across all VSANs:
– 2000 zones (as of SAN-OS 3.0, 8000 zones)
– 20000 aliases
– 1000 zone sets
– 20000 members
– 8000 LUN members
– 256 LUN members per zone/alias
Brocade Interoperability Mode Limitations
When interoperability mode is set, the Brocade switch has the following limitations:
• All Brocade switches should be in Fabric OS 2.4 or later.
• Interop mode affects the entire switch. All switches in the fabric must
have interop mode enabled.
•  Msplmgmtdeactivate must be run prior to connecting the Brocade

switch to either an MDS 9000 switch or a McData switch. This command uses Brocade
proprietary frames to exchange platform information. The MDS 9000 switch and McData
switches do not understand these proprietary frames, and rejection of these frames
causes the common E ports to become isolated.
• Enabling interoperability mode is a disruptive process to the entire

switch. It requires the switch to be rebooted.
• If there are no zones defined in the effective configuration, the default
behavior of the fabric is to allow no traffic to flow. If a device is not in a zone, it is
isolated from other devices.
• Zoning can only be done with pWWNs. You cannot zone by port numbers
or nWWNs.
• To manage the fabric from a Brocade switch, all Brocade switches must
be interconnected. This interconnection facilitates the forwarding of the inactive zone
configuration.
•  Domain IDs are restricted to the 97 to 127 range to

accommodate McData's nominal restriction to this same range.
• Brocade WebTools will show a McData switch or an MDS 9000 switch as
an anonymous switch. Only a zoning configuration of the McData switch or the MDS 9000
switch is possible.
• Private loop targets will automatically be registered in the fabric using
translative mode.
• Fabric watch is restricted to Brocade switches only.
• The full zone set (configuration) is distributed to all switches in the
fabric. However, the full zone set is distributed in a proprietary format, which only
Brocade switches accept. Other vendors reject these frames, and accept only the active
zone set (configuration).
• The following services are not supported:
– The Alias Server
Registering HBAs With the Storage System

Registering Fibre Channel HBAs or iSCSI NICs with the storage system enables the storage system to see the HBAs or NICs. To
register HBAs or NICs with the storage system, you will start or restart the Navisphere Agent on the host.
Microsoft Windows
To register the host’s HBAs with the storage system, start the Navisphere Agent as follows:
1. On the Windows host, right click My Computer and select Manage.
2. Click Services and Applications and then click Services.
3. Find EMC Navisphere Agent service.
4. If already started, stop the EMC Navisphere Agent service.
5. Start the EMC Navisphere Agent service.
AIX
To register the host’s HBAs with the storage system, on the AIX host, stop and start the Navisphere Agent. For example:
# rc.agent stop
# rc.agent start
HP-UX
To register the host’s HBAs with the storage system, on the HP-UX host, stop and start the Navisphere Agent. For example:
# /sbin/init.d/agent stop
# /sbin/init.d/agent start
Linux
To register the host’s HBAs with the storage system, on the Linux host, stop and start the Navisphere Agent. For example:
# /etc/init.d/naviagent stop
# /etc/init.d/naviagent start
NetWare
To register the host’s HBAs with the storage system, on the NetWare host, restart the Navisphere Agent. In the NetWare server console
screen, enter:
sys:\emc\agent\navagent.nlm -f
sys:\emc\agent\agent.cfg
Solaris
To register the host’s HBAs with the storage system, on the Solaris host, stop and start the Navisphere Agent. For example:
# /etc/init.d/agent stop
# /etc/init.d/agent start
VMware ESX server 2.5.0 and later

To register the host’s HBAs with the storage system, on the VMware host, stop and start the Navisphere Agent. For example:
# /etc/init.d/agent stop
# /etc/init.d/agent start
EMC PowerPath Pseudo Devices

Lets first disuss what is Powerpath software. If you are familiar with EMC product and then definitelly will be using EMC Powerpath
software.
Those who are new to storage world, it will interesting to know about this product as there are only few software in this category like
DMP,PVLINK, LVM etc from other vendor. This sofware is one of the most robust compare to other, thats reason EMC generationg
more revenue out of this Product.... So, not tooooo much marketttin :)))
EMC PowerPath software is Host/Server based failover software, what is that mean failover. failover can be anything like
server,HBA,Fabric etc. If you have fully licenced package in your enviornment then you will have all capability. Most important not least
this software got good feature like dynamic IO Loading and Automatic Failure detection which is missing in other product. Basically in
short we can define that EMC PowerPath provides you to have HA configuration. EMC Powerpath slogan is like "set it and forget".
EMC PowerPath features a driver residing on the host above HBA Device Layer. This transparent componenet allows PowerPath to
create Virtual(power) devices that provide failure resistant and load balanced paths to storage systems. An application needs only to
reference a virt ual device while Powerpath manages path allocation to storage system.
With PowerPath, the route between server and storage system can assume a complex path. One powerpath device include as many as
32 physical I/O paths ( 16 for Clariion), with each path designated to the operating system by different name.
In most cases, the application must be reconfigured to use pseudo devices, otherwise PowerPath load balancing and path failover
functionality will not be available.
The following describe whether application need to be reconfigure to use pseudo devices.
1) Windows Plateform :- No. ( Application not require to reconfigured to use Pseudo Devices )
2) AIX :- NO- For LVM, Yes, if applicaiton do not use LVM
3) HP-UX - NO
4) Solaris :- Yes, Incluing filesystem mounting tables and volume managers.
5) Linux :- Same as Solaris
if you attach new LUN to Host, powerpath automatically detect that LUN if you have exposed
correctly and create device name like emcpower1c, emcpower2c etc, even when you type command
on CLI like
#powermt display dev=all;
you will be able to device entry like emcpowerN.....
Hope this will help you to understand why powerpath uses pseudo devices?
Fibre Channel SAN Configuration Rules

Single-initiator zoning rule :--Each HBA port must be in a separate zone that contains it and the SP ports with which it communicates.
EMC recommends single-initiator zoning as a best practice.
Fibre Channel fan-in rule:--A server can be zoned to a maximum of 4 storage systems.
Fibre Channel fan-out rule:-The Navisphere software license determines the number of servers you can connect to a CX3-10c, CX3-
20c,CX3-20f, CX3-40c, CX3-40f, or CX3-80 storage systems. The maximum number of connections between servers and a storage
system is defined by the number of initiators supported per storage-system SP. An initiator is an HBA
port in a that can access a storage system. Note that some HBAs have multiple ports. Each HBA port that is zoned to an SP port is one
path to that SP and the storage system containing that SP. Depending on the type of storage system and the connections between its
SPs and the switches, an HBA port can be zoned through different switch ports to the same SP port or to different SP ports, resulting in
multiple paths between the HBA port and an SP and/or the storage system. Note that the failover software running on the server may
limit the number of paths supported from the server to a single storage-system SP and from a server to the storage system.
Storage systems with Fibre Channel data ports :- CX3-10c (SP ports 2 and 3), CX3-20c (SP ports 4 and 5), CX3-20f (all ports),
CX3-40c (SP ports 4 and 5), CX3-40f (all ports), CX3-80 (all ports).
Number of servers and storage systems As many as the available switch ports, provided each server follows the fan-in rule above and
each storage system follows the fan-out rule above, using WWPN switch zoning.
Fibre connectivity
Fibre Channel Switched Fabric (FC-SW) connection to all server types.
Fibre Channel switch terminologySupported Fibre Channel switches.
Fabric - One or more switches connected by E_Ports. E_Ports are switch ports that are used only for connecting switches together.
ISL - (Inter Switch Link). A link that connects two E_Ports on two different switches.
Path - A path is a connection between an initiator (such as an HBA port) and a target (such as an SP port in a storage system). Each
HBA port that is zoned to a port on an SP is one path to that SP and the storage system containing that SP. Depending on the type of
storage system and the connections between its SPs and the switch fabric, an HBA port can be zoned through different switch ports to
the same SP port or to different SP ports, resulting in multiple paths between the HBA port and an SP and/or the storage system. Note
that the failover software running on the server may limit the number of paths supported from the server to a single storage-system
SP and from a server to the storage system.
EMC PowerPath Migration Enabler

PowerPath Migration Enabler is a host-based software product that enables other technologies, such as array-based
replication and virtualization, to eliminate -application downtime during data migrations or virtualization
implementations. PowerPath Migration Enabler allows EMC Open Replicator for Symmetrix and EMC Invista customers
to eliminate downtime during data migrations from EMC storage to Symmetrix, and during virtualized deployments to
Invista.. PowerPath Migration Enabler—which leverages the same underlying technology as PowerPath—keeps arrays
in synch during Open Replicator for Symmetrix data migrations, with minimal impact to host resources. It also enables
seamless deployment of Invista virtualized environments by encapsulating (or bringing under its control) the volumes
that will be virtualized. In addition,
EMC PowerPath boasts the following benefits:
PowerPath Migration Enabler with Open Replicator for Symmetrix:

¨ Eliminates planned downtime
¨ Provides flexibility in time to perform migration
PowerPath Migration Enabler with EMC Invista:
¨ Eliminates planned downtime
¨ Eliminates need for data copy and additional storage for data migration
¨ I/O redirection allows Administrators to “preview” deployment without committing to redirection
Differences between a SnapView clone, Mirror, and snapshot?
Most of user asked me what are basic differences between EMC Clone/Mirror/Snapshot? This is really confusing terminology because
most of things will be same logically.Only thing change that is implementation and purpose of uses. I am trying to write basic and
common differences:
1) A clone is a full copy of data in a source LUN. A snapshot is a point-in time "virtual" copy that does not occupy any disk
space.
2) A snapshot can be created or destroyed in seconds, unlike a clone or mirror. A clone, for example, can take minutes to
hours to create depending on the size of the source LUN.
3) A clone or mirror requires exactly the same amount of disk space as the source LUN. A snapshot cache LUN generally
requires approximately 10% to 20% of the source LUN size.
4) A clone is an excellent on-array solution that enables you to recover from a data corruption issue. Mirrors are designed for
off-site data recovery.
5) A clone is typically fractured after it is synchronized while a mirror is not fractured but instead is actively and continuously
being synchronized to any changes on the source LUN.
Clones and mirrors are inaccessible to the host until they are fractured. Clones can be easily resynchronized in either direction. This
capability is not easily implemented with mirrors.
Restoring data after a source LUN failure is instantaneous using clones after a reverse synchronization is initialized. Restore time from
a snapshot depends on the time it takes to restore from the network or from a backup tape.
Once a clone is fractured, there is no performance impact (that is, performance is comparable to the performance experienced with a
conventional LUN). For snapshots, the performance impact is above average and constant due to copy on first write (COFW).
I left one more term EMC BCV(Business Continuity Volume). It is totally different concept thought. I will try to cover in upcoming post
though I have discussed about EMC BCV in my older post. But it is more or less cloning only only implementation change.
EMC BCV Operation on Host running Oracle Database

Here I am going to discuss about TimeFinder BCV Split operation where Host running on Oracle Database. This split operation is
different from normal BCV split operation. There are differences in command as well. Thats reason I am putting steps for this:
The following steps describes splitting BCV devices that hold a database supporting a host running an Oracle database. In this case,
the BCV split operation is in an environment without PowerPath or ECA. The split operation described here suspends writes to a
database momentarily while an instant split occurs. After an establish operation and the standard device and BCV mirrors are
synchronized, the BCV device becomes a mirror copy of the standard device. You can split the paired devices to where each holds
separate valid copies of the data, but will no longer remain synchronized to changes when they occur.
The Oracle database is all held on standard and BCV devices assigned to one Oracle device group.
1) Check device status on the database BCVs

To view and check status of the database BCV pairs, use the following form:
symmir –g DgName query
Check the output to ensure all BCV devices listed in the group are in the synchronized state
2) Check and set the user account
For SYMCLI to access a specified database, set the SYMCLI_RDB_CONNECT environment variable to the username and password of
the system administrator’s account. The export action sets this variable to a username of system and a password of manager, allowing
a local connection as follows:
export SYMCLI_RDF_CONNECT=system/manager
The ORACLE_HOME command specifies the location of the Oracle binaries and the ORACLE_SID command specifies the database
instance name as follows:
export ORACLE_HOME=/disks/symapidvt/oraclhome/api179
export ORACLE_sid=api179
You can test basic database connectivity with the symrdb command as follows:
symrdb list –type oracle

3) Backup the database
For safety, perform a database hot backup. For example:
symioctl begin backup –type oracle –nop
4) Freeze the database

For safety, perform a freeze on the database I/O. For example:
symioctl freeze –type oracle –nop
This command suspends writes to the Oracle database.
5) Split all BCV devices in the group

To split all the BCV devices from the standard devices in the database device group, enter:
symmir –g oraclegrp split –instant -noprompt
Make sure the split operation completes on all BCVs in the database device group.
6) Thaw the database to resume I/O

To allow writes to the database to resume for normal operation, enter:
symioctl thaw –type oracle –nop
7) End the backup

To terminate the hot backup mode, enter the following command:
symioctl end backup –type oracle –nop
EMC PowerPath Pseudo Devices

Lets first disuss what is Powerpath software. If you are familiar with EMC product and then definitelly will be using EMC Powerpath
software.
Those who are new to storage world, it will interesting to know about this product as there are only few software in this category like
DMP,PVLINK, LVM etc from other vendor. This sofware is one of the most robust compare to other, thats reason EMC generationg
more revenue out of this Product.... So, not tooooo much marketttin :)))
EMC PowerPath software is Host/Server based failover software, what is that mean failover. failover can be anything like
server,HBA,Fabric etc. If you have fully licenced package in your enviornment then you will have all capability. Most important not least
this software got good feature like dynamic IO Loading and Automatic Failure detection which is missing in other product. Basically in
short we can define that EMC PowerPath provides you to have HA configuration. EMC Powerpath slogan is like "set it and forget".
EMC PowerPath features a driver residing on the host above HBA Device Layer. This transparent componenet allows PowerPath to
create Virtual(power) devices that provide failure resistant and load balanced paths to storage systems. An application needs only to
reference a virt ual device while Powerpath manages path allocation to storage system.
With PowerPath, the route between server and storage system can assume a complex path. One powerpath device include as many as
32 physical I/O paths ( 16 for Clariion), with each path designated to the operating system by different name.
In most cases, the application must be reconfigured to use pseudo devices, otherwise PowerPath load balancing and path failover
functionality will not be available.
The following describe whether application need to be reconfigure to use pseudo devices.
1) Windows Plateform :- No. ( Application not require to reconfigured to use Pseudo Devices )
2) AIX :- NO- For LVM, Yes, if applicaiton do not use LVM
3) HP-UX - NO
4) Solaris :- Yes, Incluing filesystem mounting tables and volume managers.
5) Linux :- Same as Solaris
if you attach new LUN to Host, powerpath automatically detect that LUN if you have exposed correctly and create device name like
emcpower1c, emcpower2c etc, even when you type command on CLI like
#powermt display dev=all;
you will be able to device entry like emcpowerN.....
Hope this will help you to understand why powerpath uses pseudo devices?
What are the differences between failover modes on a CLARiiON

array?
What are the differences between failover modes on a CLARiiON array?
A CLARiiON array is an Active/Passive device and uses a LUN ownership model. In other words, when a LUN is bound it has a default
owner, either SP-A or SP-B. I/O requests traveling to a port SP-A can only reach LUNs owned by SP-A and I/O requests traveling to a
port on SP-B can only reach LUNs owned SP-B. It is necessary to have different failover methods because in certain situations a host
will need to access a LUN on the non-owning SP.
The following failover modes apply:
Failover Mode 0 –
LUN Based Trespass Mode This failover mode is the default and works in conjunction with the Auto-trespass feature. Auto-trespass is a
mode of operation that is set on a LUN by LUN basis. If Auto-Trespass is enabled on the LUN, the non-owning SP will report that the
LUN exists and is available for access. The LUN will trespass to the SP where the I/O request is sent. Every time the LUN is trespassed
a Unit Attention message is recorded. If Auto-trespass is disabled, the non-owning SP will report that the LUN exists but it is not
available for access. If an I/O request is sent to the non-owning SP, it is rejected and the LUN’s ownership will not change.
Note: The combination of Failover Mode 0 and Auto-Trespass can be dangerous if the host is sending I/O requests to both SP-A and
SP-B because the LUN will need to trespass to fulfill each request. This combination is most commonly seen on an HP-UX server using
PV-Links. The Auto-trespass feature is enabled through the Initiator Type setting of HP-AutoTrespass. A host with no failover software
should use the combination of Failover Mode 0 and Auto-trespass disabled.
Failover Mode 1 – Passive Not Ready Mode In this mode of operation the non-owning SP will report that all non-owned LUNs exist
and are available for access. Any I/O request that is made to the non-owning SP will be rejected. A Test Unit Ready (TUR) command
sent to the non-owning SP will return with a status of device not ready. This mode is similar to Failover Mode 0 with Auto-Trespass
disabled. Note: This mode is most commonly used with PowerPath. To a host without PowerPath, and configured with Failover Mode 1,
every passive path zoned, for example, a path to SP-B for a LUN owned by SP-A, will show to the server as Not Ready. This will show
as with offline errors on a Solaris server, SC_DISK_ERR2 errors with sense bytes 0102, 0700, and 0403 on an AIX server or buffer to
I/O errors on a Linux server. If PowerPath is installed, these types of messages should not occur.
Failover Mode 2 – DMP Mode In this mode of operation the non-owning SP will report that all non-owned LUNs exist and are available
for access. This is similar to Failover Mode 0 with Auto-trespass Enabled. Any I/O requests made to the non-owning SP will cause the
LUN to be trespassed to the SP that is receiving the request. The difference between this mode and Auto-trespass mode is that Unit
Attention messages are suppressed. Note: This mode is used for some Veritas DMP configurations on some operating systems.
Because of the similarities to Auto-Trespass, this mode has been known to cause “Trespass Storms.” If a server runs a script that
probes all paths to the Clariion, for instance format on a Solaris server, the LUN will trespass to the non owning SP when the I/O
request is sent there. If this occurs for multiple LUNs, a significant amount of trespassing will occur.
Failover Mode 3 – Passive Always Ready Mode In this mode of operation the non-owning SP will report that all non-owned LUNs exist
and are available for access. Any I/O requests sent to the Non-owning SP will be rejected. This is similar to Failover Mode 1. However,
any Test Unit Ready command sent from the server will return with a success message, even to the non-owning SP. Note: This mode is
only used on AIX servers under very specific configuration parameters and has been developed to better handle a CLARiiON non-
disruptive upgrade (NDU) when AIX servers are attached.
Restrictions & recommendations for binding disks into LUNs:

LUN to bind Restrictions and recommendations ----------- Any LUN You can bind only unbound disk modules. All disk modules in a
must have the same capacity to fully use the modules' storage space.
--- In AX-series storage systems, binding disks into LUNs is not supported.
RAID 5 - You must bind a minimum of three and no more than sixteen disk modules. We recommend you bind five modules for more
efficient use of disk space. In a storage system with SCSI disks, you should use modules on different SCSI buses for highest
availability. *
RAID 3 - You must bind exactly five or nine disk modules in a storage system with Fibre Channel disks and exactly five disk modules in
a storage system with SCSI disks. In a storage system with SCSI disks, you should use modules on separate SCSI buses for highest
availability. You cannot bind a RAID 3 LUN until you have allocated storage-system memory for the LUN, unless on a FC4700 or CX-
series *
IMPORTANT: RAID 3, non FC4700/CX-series does not allow caching, therefore, when binding RAID 3 LUNS, the -c cache-flags switch
do not apply
RAID 1 - You must bind exactly two disk modules. *
RAID 0 - You must bind a minimum of three and no more than sixteen disk modules. If possible in a storage system with SCSI disks,
use modules on different SCSI buses for highest availability. *
RAID 1/0 - You must bind a minimum of four but no more than sixteen disk modules, and it must be an even number of modules.
Navisphere Manager pairs modules into mirrored images in the order in which you select them. The first and second modules you
select are a pair of mirrored images; the third and fourth modules you select are another pair of mirrored images; and so on. The first
module you select in each pair is the primary image, and the second module is the secondary image. If possible in a storage system
with SCSI disks the modules you select for each pair should be on different buses for highest availability. *individual disk unit none
RAID-6 New Protection on DMX-4 With Enginuity 5772 code

RAID 6 Protection
RAID 6 was implemented to provide superior data protection, tolerating up to two drive failures in the same RAID group. Other RAID
protection schemes, such as mirroring (RAID 1), RAID S, and RAID 5, protect a system from a single drive failure in a RAID group.
RAID 6 provides this extra level of protection while keeping the same dollar cost per megabyte of usable storage as RAID 5
configurations. Although two parity drives are required for RAID 6, the same ratio of data to parity drives is consistent. For example, a
RAID 6 6+2 configuration consists of six data segments and two parity segments. This is equivalent to two sets of a RAID 5 3+1
configuration, which is three data segments and one parity segment, so 6+2 = 2(3+1).
When to use different RAID Type?
As we know that we have different type of RAID but all the raid type are not suitable for the all application. We select raid type
depending on the application and IO load/Usages. Actually there are so many factor involved before you select suitable raid type for
any application. I am trying to give brief idea in order to select best raid type for any application. You can select raid type depending on
your environment.
When to Use RAID 5

RAID 5 is favored for messaging, data mining, medium-performance media serving, and RDBMS implementations in which the DBA is
effectively using read-ahead and write-behind. If the host OS and HBA are capable of greater than 64 KB transfers, RAID 5 is a
compelling choice.
These application types are ideal for RAID 5:
1) Random workloads with modest IOPS-per-gigabyte requirements
2) High performance random I/O where writes represent 30 percent or less of the workload
3) A DSS database in which access is sequential (performing statistical analysis on sales records)
4) Any RDBMS table space where record size is larger than 64 KB and access is random (personnel records with binary content, such
as photographs)
5) RDBMS log activity
6) Messaging applications
7) Video/Media
When to Use RAID 1/0

RAID 1/0 can outperform RAID 5 in workloads that use very small, random, and write-intensive I/O—where more than 30 percent of the
workload is random writes. Some examples of random, small I/O workloads are:
1) High-transaction-rate OLTP
2) Large messaging installations
3) Real-time data/brokerage records
4) RDBMS data tables containing small records that are updated frequently (account balances)
5) If random write performance is the paramount concern, RAID 1/0 should be used for these applications.
When to Use RAID 3

RAID 3 is a specialty solution. Only five-disk and nine-disk RAID group sizes are valid for CLARiiON RAID 3. The target profile for RAID
3 is large and/or sequential access.
Since Release 13, RAID 3 LUNs can use write cache. The restrictions previously made for RAID 3—single writer, perfect alignment with
the RAID stripe—are no longer necessary, as the write cache will align the data. RAID 3 is now more effective with multiple writing
streams, smaller I/O sizes (such as 64 KB) and misaligned data.
RAID 3 is particularly effective with ATA drives, bringing their bandwidth performance up to Fibre Channel levels.
When to Use RAID 1

With the advent of 1+1 RAID 1/0 sets in Release 16, there is no good reason to use RAID 1. RAID 1/0 1+1 sets are expandable,
whereas RAID 1 sets are not.
Different RAID Explained

RAID is a redundant array of independent disks (originally redundant array of inexpensive disks). RAID is a way of storing the
same data in different places (thus, redundantly) on multiple hard disks. By placing data on multiple disks, I/O (input/output)
operations can overlap in a balanced way, which improves performance. Since multiple disks increases the mean time
between failures (MTBF), storing data redundantly also increases fault tolerance.
A RAID appears to the operating system as a single logical hard disk. RAID employs the technique of disk striping, which
involves partitioning each drive's storage space into units ranging from a sector (512 bytes) up to several megabytes. The
stripes of all the disks are interleaved and addressed in order.
In a single-user system where large records, such as medical or other scientific images, are stored, the stripes are typically
set up to be small (perhaps 512 bytes) so that a single record spans all disks and can be accessed quickly by reading all
disks at the same time. In a multi-user system, better performance requires establishing a stripe wide enough to hold the
typical or maximum size record. This allows overlapped disk I/O across drives.There are at least nine types of RAID, as well
as a non-redundant array (RAID-0).
RAID-0:
This technique has striping but no redundancy of data. It offers the best performance but no fault-tolerance.
RAID-1:
This type is also known as disk mirroring and consists of at least two drives that duplicate the storage of data. There is no striping.
Read performance is improved since either disk can be read at the same time. Write performance is the same as for single disk
storage. RAID-1 provides the best performance and the best fault-tolerance in a multi-user system.
RAID-2:
This type uses striping across disks with some disks storing error checking and correcting (ECC) information. It has no advantage over
RAID-3.
RAID-3:
This type uses striping and dedicates one drive to storing parity information. The embedded error checking (ECC) information is used to
detect errors. Data recovery is accomplished by calculating the exclusive OR (XOR) of the information recorded on the other drives.
Since an I/O operation addresses all drives at the same time, RAID-3 cannot overlap I/O. For this reason, RAID-3 is best for single-user
systems with long record applications.
RAID-4:
This type uses large stripes, which means you can read records from any single drive. This allows you to take advantage of overlapped
I/O for read operations. Since all write operations have to update the parity drive, no I/O overlapping is possible. RAID-4 offers no
advantage over RAID-5.
RAID-5:
This type includes a rotating parity array, thus addressing the write limitation in RAID-4. Thus, all read and write operations can be
overlapped. RAID-5 stores parity information but not redundant data (but parity information can be used to reconstruct data). RAID-5
requires at least three and usually five disks for the array. It's best for multi-user systems in which performance is not critical or which do
few write operations.
RAID-6:
This type is similar to RAID-5 but includes a second parity scheme that is distributed across different drives and thus offers extremely
high fault- and drive-failure tolerance.
RAID-7:
This type includes a real-time embedded operating system as a controller, caching via a high-speed bus, and other characteristics of a
stand- alone computer. One vendor offers this system.
RAID-10:
Combining RAID-0 and RAID-1 is often referred to as RAID-10, which offers higher performance than RAID-1 but at much higher cost.
There are two subtypes: In RAID-0+1, data is organized as stripes across multiple disks, and then the striped disk sets are mirrored. In
RAID-1+0, the data is mirrored and the mirrors are striped.
RAID-50 (or RAID-5+0):
This type consists of a series of RAID-5 groups and striped in RAID-0 fashion to improve RAID-5 performance without reducing data
protection.
RAID-53 (or RAID-5+3):
This type uses striping (in RAID-0 style) for RAID-3's virtual disk blocks. This offers higher performance than RAID-3 but at much higher
cost.
RAID-S (also known as Parity RAID):
This is an alternate, proprietary method for striped parity RAID from EMC Symmetrix that is no longer in use on current equipment. It
appears to be similar to RAID-5 with some performance enhancements as well as the enhancements that come from having a high-
speed disk cache on the disk array.
What is LUN_Z or LUNz?

Lets discuss about LUNz/LUN_Z in Operating System specially in CLARiiON environment. We know that what is LUN?? LUN is nothing
but logical slice of disc which stands for Logical Unit Number. This terminology comes with SCSI-3 group, if you want to know more just
visit www.t10.org and www.t11.org
A SCSI-3 (SCC-2) term defined as "the logical unit number that an application client uses to communicate with, configure and
determine information about an SCSI storage array and the logical units attached to it. The LUN_Z value shall be zero." In the
CLARiiON context, LUNz refers to a fake logical unit zero presented to the host to provide a path for host software to send configuration
commands to the array when no physical logical unit zero is available to the host. When Access Logix is used on a CLARiiON array, an
agent runs on the host and communicates with the storage system through either LUNz or a storage device. On a CLARiiON array, the
LUNZ device is replaced when a valid LUN is assigned to the HLU LUN by the Storage Group. The agent then communicates through
the storage device. The user will continue, however, to see DGC LUNz in the Device Manager.
LUNz has been implemented on CLARiiON arrays to make arrays visible to the host OS and PowerPath when no LUNs are bound on
that array. When using a direct connect configuration, and there is no Navisphere Management station to talk directly to the array over
IP, the LUNZ can be used as a pathway for Navisphere CLI to send Bind commands to the array.
LUNz also makes arrays visible to the host OS and PowerPath when the host’s initiators have not yet ‘logged in to the Storage Group
created for the host. Without LUNz, there would be no device on the host for Navisphere Agent to push the initiator record through to
the array. This is mandatory for the host to log in to the Storage Group. Once this initiator push is done, the host will be displayed as an
available host to add to the Storage Group in Navisphere Manager (Navisphere Express).
LUNz should disappear once a LUN zero is bound, or when Storage Group access has been attained.To turn on the LUNz behavior on
CLARiiON arrays, you must configure the "arraycommpath.

I. How To Merge Two Switches With Different Active Zone Sets??

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

I. How To Merge Two Switches With Different Active Zone Sets??

Uploaded by

Copyright:

Available Formats

I. How to merge two switches with different active zone sets??

Supported Director and Switch Types

1. Log into the first switch via telnet or WebTools

Example sw01_config.txt Zoning Section

6. Make a copy of “sw01_config.txt” and rename the copy as “configmerge.txt”

Example Configmerge.txt Zoning Section After Paste from sw02_config.txt

NOTE: Zoning configurations on both switches are now identical.

Managing a Fibre Channel SAN

· Storage subsystems and interconnect entities;

Host HBA installation and configuration

To set the configuration you must carry out the following:

-changes to the /etc/system file

SCSI throttle === set sd:sd_max_throttle=20

Changes to HBA driver (/kernel/drv/lpfc.conf):

To discover the SAN devices

Arbitrated loop without powerpath/ATF:-

InitLinkFlags=0x00000000 (arbitrated loop, auto-link speed)

Arbitrated loop with powerpath/ATF:

InitLinkFlags=0x00000000 (arbitrated loop, auto-link speed)

Fabric without powerpath/ATF:

InitLinkFlags=0x00000002 (fabric, auto-link speed

Fabric with powerpath/ATF:

InitLinkFlags=0x00000002 (fabric, auto-link speed)

Modifying the EMC environment :

To display what HBA's are installed.

#/opt/fcms/bin/fcmsutil /dev/td# (A5158A HBA)

To discover the SAN devices:

To display what HBA's are installed

To set the configuration you must carry out the following:

#run /usr/lpp/Symmetrix/bin/emc_cfgmgr (symmetrix) #or /usr/lpp/emc/CLARiiON/bin/emc_cfgmgr (clariion)

To discover the SAN devices

Handling BCV and Clone Disk on Veritas Volume Manager.

Get Output of Vxdisk List command

Write a New UUID to Disk

# vxdisk [-f] [-g diskgroup] updateudid disk ...

Importing a disk group containing cloned/BCV disks

# vxdg -o useclonedev=on [-o updateid] import mydg ( Group Name )

# vxdisk [-g diskgroup] settag tagname disk ...

where tagname is a string of up to 128 characters, not including spaces or tabs.

# vxdisk [-g diskgroup] set disk keepmeta=always

Alternatively, use the following command to place a copy of the configuration

# vxdg [-g diskgroup] set tagmeta=on tag=tagname nconfig=all nlog=all

# vxdg [-q] listmeta diskgroup

# vxdg -o useclonedev=on -o tag=my_tagged_disks import mydg

# vxdg -t -n clonedg -o useclonedev=on -o tag=my_tagged_disks import mydg

If /etc/syslog.conf has the following entry:

SAN zoning and masking

LUN scaling and performance

LUN management tools

How to merge two switches with different active zone sets??

Supported Director and Switch Types

1. Log into the first switch via telnet or WebTools

Example sw01_config.txt Zoning Section

6. Make a copy of “sw01_config.txt” and rename the copy as “configmerge.txt”

Example Configmerge.txt Zoning Section After Paste from sw02_config.txt

NOTE: Zoning configurations on both switches are now identical.

Overview of RAID Striping

EMC: Merging Fibre channel fabrics

EMC: Enterprise SAN Fabric Topology Port Calculation

-32 Total ports

Kashya :- Advances in Data Protection and Replication

1) Synchronous – Every write transaction committed must be acknowledged from the

3) Snapshot –A consistent image of the storage subsystem is periodically transferred to the