how communication is going in netbackup?

Generally all hosts are connected to network switch.this switch is connected to netbackup master server.netbackup server is connected to switch.all tape drives to SAN switch.backup is going to tapedrives through netbackup master server.if overload is heavy in master server,we can add media server.

if media server is add,first host is communicated first with master server,after host id communicated with media server.media server is attached to tape libraries.

fail-over modes in clariion?

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.owner about the lun is 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.

Failover Mode 0 –
LUN Based Trespass Mode This failover mode is the default and works in conjunction with the Auto-trespass feature. If Auto-Trespass is enabled on the LUN, the non-owning SP will report that the LUN exists and is available for access. 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.

Failover Mode 1-
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.

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.

FLARE Code versions information

FLARE Code version information is as follows.

For the sake of this blog we will limit our explanation only to CX, CX3 and CX4 platforms.

Generation 1: CX200, CX400, CX600

Generation 2: CX300, CX500, CX700 including the iSCSI flavors

Generation 3: CX3-10, CX3-20, CX3-40, CX3-80

Generation 4: CX4-120, CX4-240, CX4-480, CX4-960      
(last three digits are the number of drives it can support)

The FLARE Code is broken down as follows (Please see the color coded scheme below).

1.14.600.5.022 (32 Bit)

2.16.700.5.031 (32 Bit)

2.24.700.5.031 (32 Bit)

3.26.020.5.011 (32 Bit)

4.28.480.5.010 (64 Bit)

The first digit: 1, 2, 3 and 4 indicate the Generation of the machine this code level can be installed on. For the 1^st and the 2^nd generation of machines (CX600 and CX700), you should be able to use standard 2^nd Generation code levels. CX3 code levels would have a 3 in front of it and so forth. 

These numbers will always increase as new Generations of Clariion machines are added.

The next two digits are the release numbers; these release numbers are very important and really give you additional features related to the Clariion FLARE Operating Environment. When someone comes up to you and says, my Clariion CX3 is running Flare 26, this is what they mean.

These numbers will always increase, 28 being the latest FLARE Code Version.

The next 3 digits are the model number of the Clariion, like the CX600, CX700, CX3-20 and CX4-480.

These numbers can be all over the map, depending what the model number of your Clariion is.

some facts about the BIN file in DMX?

• Only used with Symmetrix systems (Enginuity Code)
  .
• BIN file stands for BINARY file.
  .
• BIN file holds all information about the Symmetrix configuration
  .
• One BIN file per system serial number is required.
  .
• BIN file was used with Symmetrix Gen 1 in 1990 and is still used in 2010 with Symmetrix V-Max systems.
  .
• BIN file holds information on SRDF configurations, total memory, memory in slots, serial number of the unit, number of directors, type of directors, director flags, engines, engine ports, front end ports, back end ports, drives on the loop, drives on the SCSI bus, number of drives per loop, drive types in the slots, drive speeds, volume addresses, volume types, meta’s, device flags and many more settings.
  .
• The setup for host connection if the OS is Open Systems or Mainframe environments using FICON, ESCON, GbE, FC, RF, etc is all defined in the BIN file. Also director emulations, drive formats if OSD or CKD, format types, drive speeds, etc is all defined in the BIN file.
  .
• BIN file is required to make a system active. It is created based on customer specifications and installed by EMC during the initial setup.
  .
• Any ongoing changes in the environment related to hardware upgrades, defining devices, changing flags, etc is all accomplished using BIN file changes.
  .
• BIN file changes can be accomplished 3 ways.
  .
• BIN file change for hardware upgrades is typically performed by EMC only.
  .
• BIN file change for other changes that are device, director, flags, meta’s, SRDF configurations etc is either performed through the SYMAPI infrastructure using SymCLI or ECC (Now Ionix) or SMC (Symmetrix Management Console) by the customer. (Edited based on the comments: Only some changes now require traditional BIN file change, typically others are performed using sys calls in enginuity environment)
  .
• Solutions enabler is required on the Symcli, ECC, SMC management stations to enable SYMAPI infrastructure to operate.
  .
• VCMDB needs to be setup on the Symmetrix for SymCLI, ECC, SMC related changes to work.
  .
• Gatekeeper devices need to be setup on the Symmetrix front end ports for SymCLI, ECC, SMC changes to work
  .
• For Symmetrix Optimizer to work in your environment, you need DRV devices setup on your Symmetrix.(EDITED based on comments: Only required until DMX platform. Going forward with DMX3/4 & V-Max platforms it uses sys calls to perform these Optimizer changes).