EMC Storage Product Knowledge Sharing

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

What are the CLARiiON SAN fan-in and fan-out configuration rules?"

Fan-Out Rule:

• For FC5300 with Access Logix software - 1 - 4 servers (eight initiators) to 1 storage system.
  
• For FC4500 with Access Logix - 15 servers to 1 storage system; each server with a maximum of one (single) path to an SP.
  
• For FC4700 with Base or Access Logix software 8.42.xx or higher - 32 initiators per SP port for a maximum of 128 initiators per FC4700. Each port on each SP supports 32 initiators. Ports 0 and 1 on each SP in a FC4700 handles server connections. Port 1 on each SP in a FC4700 with MirrorView also handles remote mirror connections. In a remote mirror configuration, each path between SP A port 1 on one storage system and SP A port 1 on another storage system counts as one initiator for each port 1. Likewise, each path between SP B port 1 on one storage system and SP B port 1 on another storage system counts as one initiator for each port 1.
  
• For FC4700 with Base or Access Logix software 8.41.xx or lower - 15 servers to 1 storage system; each server with a maximum of one (single) path to an SP.
  
• For CX200 - 15 initiators per SP, each with a maximum of one (single) path to an SP; maximum of 15 servers.
  
• Fan-Out for CX300 - 64 initiators per SP for a maximum of 128 initiators per storage system.
  
• For CX400 - 32 initiators per SP port for a maximum of 128 initiators per CX400. Each port on each SP supports 32 initiators. Ports 0 and 1 on each SP in a CX400 handles server connections. Port 1 on each SP in a CX400 with MirrorView also handles remote mirror connections. In a remote mirror configuration, each path between SP A port 1 on one storage system and SP A port 1 on another storage system counts as one initiator for each port 1. Likewise, each path between SP B port 1 on one storage system and SP B port 1 on another storage system counts as one initiator for each port 1.
  
• Fan-Out CX500 - 128 initiators per SP and maximum of 256 initiators per CX500 available for server connections. Ports 0 and 1 on each SP handle server connections. Port 1 on each SP in a CX500 with MirrorView/A or MirrorView/S enabled also handles remote mirror connections. Each path used in a MirrorView or SAN Copy relationship between two storage system counts as an initiator for both storage systems.
  
• For CX600 - 32 initiators per SP port and maximum of 256 initiators per CX600 available for server connections. Ports 0, 1, 2, and 3 on each SP in any CX600 handle server connections. Port 3 on each SP in a CX600 with MirrorView also handles remote mirror connections. In a remote mirror configuration, each path between SP-A port 3 on one storage system and SP-A port 3 on another storage system counts as one initiator for each port 3. Likewise, each path between SP-B port 3 on one storage system and SP-B port 3 on another storage system counts as one initiator for each port 3.
  
• Fan-Out CX700 - 256 initiators per SP and maximum of 512 initiators per CX700 available for server connections. Ports 0, 1, 2, and 3 on each SP in any CX700 handle server connections. Port 3 on each SP in a CX700 with MirrorView/A or MirrorView/S enabled also handles remote mirror connections. Each path used in a MirrorView or SAN Copy relationship between two storage system counts as an initiator for both storage systems
• An initiator is any device with access to an SP port. Each port on each SP supports 32 initiators. Check with your support provider to confirm that the above rules are still in effect.

Save Set Staging:

Save set staging is a process of transferring data from one storage medium to another. Staging reduces the time it takes to complete a backup by directing the initial backup to a high performance file type or adv_file device. The data can then be staged to a storage medium, freeing up the disk space. Any volume type, such as Default, Index Archive, or Default Clone, can be staged. Staging is particularly well suited for data that has been backed up on file type or adv_file devices. Staging allows the occupied disk space on file type or adv_file devices to be reclaimed so that the disk space can be used for other purposes. Use staging to move the data to more permanent storage, such as an optical or tape volume, or even another, lower-priority device. Staging also allows data to be moved off the device outside the backup period, ensuring that sufficient disk space is available for the next backup session. Additional licencing may be required.

You can create, edit, and delete staging policies as you can for other NetWorker resources. As part of the client setup, the use of a staging device can be selected for each pool (or set of pools) for backup, archive, and migration. The files are retained for the specified time in the disk staging pool before being moved to a tape device or optical disk. Any number of devices can be in the staging pool, and a save set can be staged as many times as required, for example to disk, to optical disk, to a local tape device, and to a remote tape device. Also, a volume can be staged to a second volume, and then that data on the second volume can be staged back to the first volume.

The staging process is driven by one of the following events:

- As part of an automatic process, such as keeping the save set for 30 days on the staging device before staging the data to the next device.

- As part of an event driven process, such as when available space in the staging pool drops below a set threshold. When this happens, the oldest save sets are moved first, until available space reaches the upper threshold that has been set.

- As part of an administrator initiated process, such as allowing the administrator to either reset the threshold and kick off staging or manually select save sets to stage.

When you enable a staging policy, the NetWorker server creates a clone of the save set you specify on a clone volume of the medium you specify. After the save set is staged, the save set is deleted from the filesystem to free the space.

The NetWorker server tracks the location of the save set in the media database. The retention policy for the save set does not change when the data is staged. If the file type volume is on a storage node that is running NetWorker software 6.1 or earlier, the tape is not automatically marked appendable after the staging operation.

There is available WWN decoder tool for EMC but I am going to discuss how to decode manually?
Each Symmetrix SAF port, RAF port, EF ficon port or DAF port (DMX only) has a unique worldwide name (WWN). The WWN is associated with the Tachyon chip on the director. It was intended to remain unique per director so that the director can be accessed on a storage area network. The Symmetrix SAF/RAF/DAF/EF WWN is dependent on the Symmetrix serial number, the director number, the processor letter, and the port on the processor. When the SAF/RAF/DAF is inserted into the Symmetrix, it discovers the Symmetrix serial number and slot number and the WWNs are set for the ports on the director.

Symm 4/4.8/5 (2-port or 4-port) Fibre Channel front directors, the WWN breakdown are as follows:

For Symm DMX product family (DMX-1/2/3), the WWN breakdown are as follows:

The director WWN (5006048ACCC86A32) can be broken down (in binary) as follows:

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

Vendor Worldwide Names WWN :