EMC
From Wiki
Allocating and Unallocating Storage on a Symmetrix
This page gives a overview in allocating and unallocating storage from a EMC Symmetrix system
Adding Storage
- List all devices on a Symmetrix box that are available, but not assigned/mapped out to an fa.
-
# symdev -sid #### -noport list - Backup the VCM database
-
# symmaskdb backup
-
- Create a striped Meta volume
-
# cat MyMetafile.cmd -
form meta from dev 4FC config=striped, stripe_size=1920; -
add dev 4FD:4FF to meta 4FC;
-
- Preview, Prepare and commit the changes
-
# symconfigure -sid #### -f MyMetafile.cmd preview -nop -
# symconfigure -sid #### -f MyMetafile.cmd prepare -nop -
# symconfigure -sid #### -f MyMetafile.cmd commit -nop - Check the Meta volume
-
# symdev -sid #### show 4FC
-
- Check the log-ins (zoning) for the hosts HBA's
-
# symmask -sid #### list logins | grep <WWN HBA 0> -
# symmask -sid #### list logins | grep <WWN HBA 1> -
# symmask -sid #### list logins -wwn <WWN HBA 0> -
# symmask -sid #### list logins -wwn <WWN HBA 1> - Renaming the host HBA's in the VCM database
-
# symmask -sid #### -wwn <WWN HBA 0> rename <hostname/HBA 0> -
# symmask -sid #### -wwn <WWN HBA 1> rename <hostname/HBA 0>
-
- Check the available LUN id's
-
# symcfg -sid #### -dir 3c -p 0 -address -available list -
# symcfg -sid #### -dir 14c -p 0 -address -available list
-
- Map the Meta volume to the front-end directors
-
# cat MyMapfile.cmd -
map dev 4FC to dir 3c:0 target=0, lun=5; -
map dev 4FC to dir 14c:0 target=0, lun=5;
-
- Preview, Prepare and commit the changes
-
# symconfigure -sid #### -f MyMapfile.cmd preview -nop -
# symconfigure -sid #### -f MyMapfile.cmd prepare -nop -
# symconfigure -sid #### -f MyMapfile.cmd commit -nop - Check the configuration
-
# symdev -sid #### -sa 3c -p 0 -fibre list -
# symdev -sid #### -sa 14c -p 0 -fibre list
-
- Mask the Meta volume
-
# symmask -sid #### -wwn <WWN HBA 0> -dir 3c -p 0 add devs 4FC -
# symmask -sid #### -wwn <WWN HBA 0> -dir 14c -p 0 add devs 4FC - Update the VCM database
-
# symmask -sid #### refresh -nop
-
Removing Storage
- Remove the LUN masking configuration
-
# symmask -sid #### -wwn <WWN HBA 0> -dir 3c -p 0 remove devs 4FC -
# symmask -sid #### -wwn <WWN HBA 0> -dir 14c -p 0 remove devs 4FC - Update the VCM database
-
# symmask refresh -nop
-
- Off-Line the Volume 4FC
-
# symdev -sid #### not_ready 4FC -nop - Check the configuration
-
# symdev -sid #### show 4FC
-
- Unmap the meta volume from the front-end directors
-
# cat MyUnMapfile.cmd -
unmap dev 4FC from dir 3c:0; -
unmap dev 4FC from dir 14c:0;
-
- Remove the volume from the VCM database
-
# symconfigure -sid #### -f MyUnMapfile.cmd preview -nop -
# symconfigure -sid #### -f MyUnMapfile.cmd prepare -nop -
# symconfigure -sid #### -f MyUnMapfile.cmd commit -nop - Check the configuration
-
# symdev -sid #### -sa 3c -p 0 -fibre list -
# symdev -sid #### -sa 14c -p 0 -fibre list
-
- Dissolve Meta volume command file
-
# cat MyDisMetafile.cmd -
dissolve meta dev 4FC;
-
- Dissolve Meta volume
-
# symconfigure -sid #### -f MyDisMetafile.cmd preview -nop -
# symconfigure -sid #### -f MyDisMetafile.cmd prepare -nop -
# symconfigure -sid #### -f MyDisMetafile.cmd commit -nop
-
SRDF Configuration
- To list all RDF groups configured on a array
-
# symcfg -sid #### list –rdfg all
-
- The following command will displays how many RA/RF directors exist on the array
-
# symcfg -sid #### list –RA all
-
- To check the status of the SRDF link
-
# symrdf -g <DG_NAME> query
-
- The following command will list SRDF devices configured on the array
-
# symrdf -sid #### list
-
- The content of the command file used for the creation of the R1 and R2 pairs
-
--8<---- vi SRDF_config.cmd -8<---- -
1233 1175 -
123B 724 -
123E 727 -
-->8---- EOF SRDF_config.cmd ->8----
-
- On a host with a gatekeeper use the followin commands to create and establish a SRDF pair
-
# symrdf -sid #### -file SRDF_config.cmd -RDFG 1 -type R1 -establish createpair
-
- If abnormal exit use the following command:
-
# symrdf -sid #### -file SRDF_config.cmd -RDFG 1 -full establish
-
- To check the status use the following command:
-
# symrdf -sid #### -file SRDF_config.cmd -RDFG 1 query
-
- To list all device groups configured on a array
-
# symdg -sid #### list
-
- To list information regarding one device groups on a array
-
# symdg show <DG_NAME>
-
- To create a device groups on a array
-
# symdg -type <RDF1|R1|R2> create <DG_NAME>
-
- To add a device to the device groups on a array
-
# symld -g <DG_NAME> -sid #### add dev 4FC
-
- To remove a device from the device groups on a array
-
# symld -g <DG_NAME> -sid #### remove dev 4FC
-
SRDF Operations
List SRDF group across different dmx
# symdg list # symcg list # symrdf list
SRDF Split and failover
- Failover:
- Actions:
- Write disables (WD) R1
- Sets link to Not Ready (NR)
- Write enables R2
- Command:
# symrdf -g <DG_NAME> que
# symrdf -g <DG_NAME> est (R1 -> R2)
# symrdf -g <DG_NAME> failover (R1 WD, R2 RW)
- Actions:
- Update: Helps to speed up the failback operation by copying invalid tracks before write disabling any disks.
- Actions:
- Leaves service state as is.
- Merges the tracks
- Copies invalid tracks
- Command:
# symrdf -g <DG_NAME> update (R2 -> R1)
- Actions:
- Failback:
- Actions:
- Write disables R2
- Suspends RDF link
- Merges the disk tracks.
- Resumes the link
- Write enables R1
- Copies the changed data
- Command:
# symrdf -g <DG_NAME> failback (R1 RW, R2 WD)
- Actions:
- Split: Leaves both R1 & R2 in write enabled state.
- Actions:
- Suspends the rdf link.
- Write enables R2
- Command:
# symrdf -g <DG_NAME> split (R1 RW, R2 RW)
- Actions:
- Establish:
- Actions:
- Write disables R2
- Suspends the rdf link
- Copies data from R1 to R2
- Resumes the rdf link.
- Command:
# symrdf -g <DG_NAME> [ -full ] establish (R1 -> R2)
- Actions:
- Restore: Copies data from R2 to R1
- Actions:
- Write disables both R1 & R2
- Suspends the rdf link.
- Merges the track tables
- Resumes the rdf link.
- Write enables R1
- Command:
# symrdf -g <DG_NAME> [ -full ] restore
- Actions:
- Singular SRDF commands:
- Suspend:
# symrdf -g <DG_NAME> suspend
- Resume:
# symrdf -g ${group} resume - Swap:
# symrdf -g <DG_NAME> swap (swap personality R2 become R1)
- Suspend:
Set SRDF mode to adaptive copy
# symrdf -g <DG_NAME> set mode acp_wP
Set SRDF mode to sync
# symrdf -g <DG_NAME> set mode sync
Search device 4FC from Symmetrix ####
# symdev -sid #### show 4FC
List capacity of host myhost in Symmetrix ####
# symmaskdb -sid #### -host myhost list capacity
Swap the personalities of the devices and mark the old R1 devices to be refresh from the old R2 dev
# symrdf -g swap -refresh R1 # symrdf -g est
To remove dev in a SRDF group
# symld -g <DG_NAME> remove DEV001
To add dev in a SRDF group
# symld add dev 04FC -g <DG_NAME>
Delete and Add a SRDF group
# symdg delete <DG_NAME> # symdg create <DG_NAME> -type RDF2 # symdg list
List connected dev on control center manager
# sympd list
Check masking by dev or wwn
# symmaskdb -sid #### -dev 0747 list assign # symmaskdb -sid #### -wwn 10000000c9394494 list devs
Check if the wwn login to the fabric port
# symmask -sid #### -dir 8c -p 0 -wwn 10000000c9394494 list logins
TimeFinder (BCV) Configuration
- Create a Symmetrix device group
-
# symdg -type <Regular|RDF1|RDF2> create <DG_NAME>
-
- Add the source device to the device group
-
# symld -g <DG_NAME> -sid #### add dev 4FC
-
- Associate a target BCV devices to the disk group
-
# symbcv -g <DG_NAME> associate dev 0DFF - For Cloning a Copy on a Remote Symmetrix array
-
# symbcv -g <DG_NAME> associate dev 0DFF -rdf
-
- To check and find the logical device names
-
# symmir -g <DG_NAME> query
-
- To establish the link for the first time, execute a full establish
-
# symmir -g <DG_NAME> -full establish DEV<###> bcv ${bcv_log_dev}
-
- To fully re-establish all BCV pairs in the device group
-
# symmir -g <DG_NAME> -full establish -rdf
-
- To perform a consistent split of all PowerPath-connected standard devices with their remotely associated BCV's
-
# symmir -g <DG_NAME> split -rdf -instant -ppath stddevs -
# symmir -g <DG_NAME> split -rdf -consistent
-
Common Symmetrix Commands
- List the gatekeepers and array's
-
# symcfg list
-
- Change the status of a volume
-
# symdev -sid #### <rw_enable|not_ready|ready> <dev> -nop
-
- List all devices with a capacity of 8633 MB and not mapped to any front-end
-
# symdev list -sid #### -CAP 8633 -noport
-
- List devices available assigned to a host
-
# symmaskdb -sid #### -host <WWN HBA> list capacity
-
- List the masking details of the dev 4FC
-
# symmaskdb -sid #### -dev 4FC list assignment -v
-
- List the devices masked to the given wwn number
-
# symmaskdb -sid #### -wwn <WWN HBA> list devs
-
- Register the HBA with the VCM database
-
# symmask discover hba
-
- List locks on a array
-
# symcfg -lockn all list
-
- list locks on devices
-
# symdev -sid #### -lock list
-
Allocating and Unallocating Storage on a Clariion
About Navisphere CLI
Navisphere CLI provides a command line interface capable of managing multiple CLARiiON Storage arrays from a single host, both in-band and out-of-band (CX-series, CX3 series, CX4 series).
The classic CLI navicli is being replaced by Secure CLI naviseccli. Secure CLI is recommended because it is faster and more secure than Classic. New Navisphere features are only supported with Secure CLI. The only commands not currently supported by Secure CLI are commands issued to host agents. Java CLI and Classic CLI clients will be phased out in a future release. For this class, the /opt/Navisphere/bin/naviseccli commands are provided. The Java CLI is no longer supported.
Create a Navisphere Security File on the host
A storage system will not accept a command from Secure CLI unless the user who issues the command has a valid user account on the storage system.
You must use the -scope switch to add scope information to the security file. You can use the -password switch or enter your password into the password prompt, to supply the required password information to the security file. The -user and -secfilepath switches are optional.
You can specify valid account username, password, and scope (global or local) for each command you issue, or, more conveniently, you can create a Navisphere security file.
# naviseccli -addusersecurity -password <password> -scope 0 -user <username>
Where:
- The <password> and <username> are from the array.
- The scope specifies whether the user account on the storage system you want to log in to is local or global. It can be either of the following:
- 0 (the default) indicates global and is effective throughout the domain
- 1 indicates local and is only effective on the arrays for which the administrator has created an account for the user.
- The Security File resides in the user’s home directory
Adding Storage
Creating a Raid Group
The Disk location consists of : Bus, Enclosure, Disk for example 1_0_4 indicates that the disk is located in:
- Bus 1
- Enclosure 0
- Disk 4
To configure a raid group of 5 disks in raid 5 use the following command:
# naviseccli -h <SP IP ADDRESS> createrg <rgID> 1_0_0 1_0_1 1_0_2 1_0_3 1_0_4 -rm no -pri med -raidtype r5
To configure a raid group of 3 disks in raid 1+0 use the following command:
# naviseccli -h <SP IP ADDRESS> createrg 23 2_0_0 3_0_0 2_0_1 3_0_1 2_0_2 3_0_2 -rm no -pri low -raidtype r1_0
- -h IP Address of the Clariion Storage Processor
- <rgID> Decimal RAID Group ID
- -rm Auto Destroy the Raid Group after the last LUN is unbound on the Raid Group
- -pri Priority setting for Expansion/Defragment of the Raid Group
- -raidtype Setting of the Raid Type for the Raid Group (r0, r1, r3, r5, r6, r1_0, hs)
Get status of the Raid Group
The following command returns information regarding the RAID Group:
# naviseccli -h <SP address> getrg <rgID> [-disks] [-exdisks] [-legal] [-lunex] [-lunlist] [-lusc]
[-maxd] [-maxl] [-pod] [-prcntdf] [-prcntex] [-state]
[-tcap] [-type] [-ucap]
Bind the LUN
The bind command, when executed on RAID group storage systems, creates a LUN within an existing RAID Group
# naviseccli -h <SP address> bind raidtype [lun] -rg <rgID>
[-aa auto_assignment] [-cap capacity] [-elsz stripe-element-size]
[-n min_latency_reads] [-offset stripe-number] [-pl placement]
[-r rebuild-priority] [-rc read-cache] [-sp a|b] [-sq size-qualifier]
[-v verify-priority] [-wc write-cache]
Where
- -h IP Address of the Clariion Storage Processor
- raidtype Specifies the RAID type for the LUN (r0, r1, r3, r5, r6, r1_0, hs)
- lun optional LUN ID to assign to LUN
- -rg <rgID> RAID Group to bind LUN to
- -sq size-qualifier set blocks, MB, GB
- -rc read-cache Disable (0) or enable (1) read cache for the LUN
- -wc write-cache Disable (0) or enable (1) write cache for the LUN
- -cap capacity Priority setting for Expansion/Defragment of the Raid Group
Create Storage Group
Register the Host
Present LUN to Host
Create Meta LUN
Removing Storage
To get Partitions Properties in a RAID Group
# naviseccli –h <SP IP ADDRESS> getrg 15 –lunlist
Destroying a RAID Group via Command Parameters
The removerg command, removes a specified RAID group. All LUN's created on the RAID Group must be removed beforehand.
# naviseccli –h <SP IP ADDRESS> removerg <rgID>
Destroying Storage Groups
# navicli –h <SP IP ADDRESS> storagegroup –destroy –gname HostName
Clariion MirrorView Configuration
Clariion SnapView Configuration
Common Clariion Commands
- What is the correct command to add user security?
# naviseccli -AddUserSecurity -password mypass -scope 0 -user username
- What is the correct command to delete user security?
# naviseccli -RemoveUserSecurity -password mypass -scope 0 -user -username
- To get the Cache information
# naviseccli –h <SP IP ADDRESS> getcache
- Configure the Cache
# naviseccli -h <SP IP ADDRESS> setcache -wsza 550 -rsza 100 -wszb 100 -rszb 100
- To disable Write and Read Cache
# naviseccli –h <SP IP ADDRESS> setcache –wc 0 –rca 0 –rcb 0
- Set Page Size to 4 KB, Low WaterMark to 50%, and High WaterMark to 70%
# naviseccli –h <SP IP ADDRESS> setcache –p 4 –l 50 –h 70
- To enable Write and Read Cache
# naviseccli –h <SP IP ADDRESS> setcache –wc 1 –rca 1 –rcb 1
- wsza SPA write cache in MB
- rsza SPA read cache in MB
- wszb SPB write cache in MB
- rszb SPB read cache in MB
- p page size (2, 4, 8 or 16)
- l low watermark
- h high watermark
- wc/rc disable/enable read/write cache
- wca/rca disable/enable read/write SPA cache
- To get the Disk Summary
# naviseccli –h <SP IP ADDRESS> getdisk
- For a specific disk add the following option (Bus_Enclosure_Disk)
# naviseccli –h <SP IP ADDRESS> getdisk 0_0_9
- To get the RAID Group 0 Properties
# naviseccli –h <SP IP ADDRESS> getrg 0
- To get the Properties of the disks in the RAID Group 0
# naviseccli –h <SP IP ADDRESS> getrg 0 –disks
PowerPath Commands
To display powerpath registration key
# powermt check_registration or # emcpreg -list
On UNIX, PowerPath maintains the ASCII text file /etc/emcp_registration with the installed licenses
PowerPath license registration
# emcpreg -install
To set or validate the Load balancing policy
- so = Symmetrix Optimization (default)
- co = Clariion Optimization
- li = Least I/Os (queued)
- lb = Least Blocks (queued)
- rr = Round Robin (one path after another)
- re = Request (failover only)
- nr = No Redirect (no load-balancing or failover)
To see the current load-balancing policy and I/Os run the following command
# powermt display dev=<device>
To set the policy to default Clariion Optimization
# powermt set policy=co class=clariion dev=all
To set the policy to default Symmetrix Optimization
# powermt set policy=so dev=<device>
Restoring device paths under PowerPath control on a Solaris host
First, run powermt display dev=all and confirm the dead device paths:
Next, verify Connectivity Status of the paths for the affected host say Logged in and Registered.
Then follow these steps:
# powermt check (Choose "A" for all. Clear the dead paths.) # devfsadm -C (Scan the SCSI bus.) # powercf -q (Rebuild the logical link layer.) # powermt config (Bring the device paths into PowerPath control.) # powermt restore (Trespass LUNs to their default owners.) # powermt save (Save the current configuration.)
The powermt display dev=all command will now show all paths active and alive.
Display the powerpath devices for the new LUNs
# /etc/powermt display dev=all|sed 's/=/ /'|awk '/Pseudo/ {P=$NF} /Symmetrix ID/ {S=$NF} /Logical/ {print S ":" $4 ":" P}'| egrep -e "0A4D|0A49|0A46|0A42|0A3E"
Find the LUN-ID's for the emcpower devices used
# /etc/powermt display dev=all | sed 's/=/ /' |awk '/Pseudo/ {P=$NF} /Logical/ {print P ":" $NF}'| egrep -e "emcpower03|emcpower04|emcpower05|emcpower06|emcpower07|emcpower08"
Rename powerpath devices
If your powerpath pseudo devices do not match your previous output of a powermt display dev=all, please use the emcpadm command to rename the pseudo devices. See the manpages, associated product guide or emc166911.
Use the emcpadm command to change the emcpower pseudo devices to the desired names.
You can do it this way:
emcpadm renamepseudo -s <src pseudo device name> -t <tgt pseudo device name>
- Use the command below in order to determine the emcpower devices that are already in use
# emcpadm getused
- Use the command below in order to determine the emcpower devices that are available
# emcpadm getfree -n 5 -b emcpowera
- Use the command below to rename a device
# emcpadm rename -s emcpowerg -t emcpowerf
- The emcpadm getused command can now be used again to check the devices after the rename
# emcpadm getused
- Update the powermt.custom file with the new pseudo device mappings
# powermt save
# emcpadm getusedpseudos # emcpadm getfreepseudos # emcpadm renamepseudo -s emcpowerh -t emcpowerrh # emcpadm getusedpseudos
- This renames the device called emcpowerh, to be now called emcpowerrh
- To list the next five free PowerPath pseudo device names e.g. beginning at the device named emcpower20
# emcpadm getfreepseudos -n 5 -b 20
PowerPath shows paths in an Active/Dead state
First, run powermt display dev=all and confirm the dead device paths:
# powermt display dev=all Pseudo name=emcpower82a CLARiiON ID=APM00034403351 Logical device ID=60060160A2100A00108246567486D911 state=alive; policy=CLAROpt; priority=0; queued-IOs=0 Owner: default=SP A, current=SP B ============================================================================== ---------------- Host --------------- - Stor - -- I/O Path - -- Stats --- ### HW Path I/O Paths Interf. Mode State Q-IOs Errors ============================================================================== 2307 pci@8/fibre-channel@2 c5t9d23s0 SP B0 active alive 0 0 2308 pci@8/fibre-channel@1 c6t8d23s0 SP A0 active dead 0 0
For connections to a Clariion, verify in Navisphere Navisphere Connectivity Status shows the paths to the ports on SP-A and SP-B for the affected host say Logged in and Registered.
Then follow these steps:
- You can clear all the dead paths by Choosing the A option:
# powermt check
- To scan the SCSI bus execute the following command:
# devfsadm -C
- To rebuild the logical link layer execute the following command:
# powercf -q
- To bring the device paths into PowerPath control execute the following command:
# powermt config
- To trespass LUNs to their default owners execute the following command:
# powermt restore
- To save the current configuration
# powermt save
- The following command will now show all paths active and alive.
# powermt display dev=all
Solaris host not able to see newly assigned CLARiiON LUN's.
At some point, HLU ### was presented to the host and PowerPath had it in its control. The LUN was then removed from the Storage Group but was never removed from PowerPath. The OS will not find the new LUN until PowerPath lets go of the old LUN ###.
The HLU, not the ALU, is the LUN value that the Solaris OS will use when it scans the SCSI bus.
In this case HLU ### cannot be seen because powermt display dev=all is showing the following:
Pseudo name=emcpower###a CLARiiON ID=APM00052603252 Logical device ID=60060160C27B150068109AD15963DA11 state=alive; policy=CLAROpt; priority=0; queued-IOs=0 Owner: default=SP A, current=Unknown ============================================================================== ---------------- Host --------------- - Stor - -- I/O Path - -- Stats --- ### HW Path I/O Paths Interf. Mode State Q-IOs Errors ============================================================================== 1285 pci@1f/QLGC,qla@2 c4t0d4s0 SP A0 active dead 0 0 1285 pci@1f/QLGC,qla@2 c4t1d4s0 SP B1 active dead 0 0
To fix the issue follow these steps:
# powermt check #Clear all dead paths. Type A for all. # powercf -q #Update PP configuration DB, remove old entries from emcp.conf. # devfsadm -C #Clean the OS device tree and scan the SCSI bus to pick up the new LUN. # powercf -q #Update the PP configuration DB, add new entries to emcp.conf. # powermt config #Bring the new device into PowerPath's control. # powermt save #Save the new configuration.
How to completely remove/uninstall PowerPath package on Solaris.
If the following command pkgrm <EMCpower> failed to uninstall PowerPath on Solaris, use the following instructions.
Ensure the O/S does not have a mirrored boot disk within Solaris. If so, the mirror must be broken prior to PowerPath removal to ensure the package gets removed.
# /etc/emcp_cleanup # rm /dev/emcpsf # rm /devices/pseudo/emcp* # rm /etc/*.FCS # rm -r /dev/emc # rm -r /etc/emc # rm -r /opt/emc
Removes all the copies of powermt.custom (powermt.custom.x)
# rm /etc/powermt.custom* # rm -f /etc/PPVM_config # rm -f /etc/PPVM_config_bak # rm /etc/emcp_devicesDB.dat
Makes sure there is no emcp.conf.saved
# rm /kernel/drv/emcp.conf* # rm /etc/emcp_devicesDB.idx # rm /dev/dsk/emcp* # rm /dev/rdsk/emcp* # cp /etc/emcp_registration /var/bkup # rm -f /etc/emcp_registration
Reboot the server and ensure that PowerPath is no longer loaded. (check pkginfo and that there are no powerpath modules loaded in modinfo)
Reconfigure EMC master agent for relocated ECC server
ECC is short for EMC control center. It is the key component from EMC to manage its SAN storage and SAN-attached hosts. We just relocated the ECC server from a four-year old machine to the new HP server, with IP changed.
while the EMC engineer is donig the ECC server configuration, we are asked stop the master agents on all monitored hosts. As usually master agent can only be restarted from ECC console. Here are the step of stop/start/reconfigure master agent from command line on the client side.
- . Login to the client, switch to root.
- . change directory to /usr/ecc/exec
- . do a “./eccmad stop” to stop master agent.
- . do a “ps -ef | grep ecc” to see if any ECC agent is still running. Kill any running agents if they are not stopped by step 3.
- . modify ctg.ini file, change “Server Host” to new IP.
- . modify MGA520/MGA.ini file, change “Server Host” to new IP.
- . start the master agent (./eccmad start) when new ECC server is up.
In some cases, the host agent is “inactive” and the attempts to restart the host agent always fails, we need to check the “action command” to understand if the failure was caused by master agent. The first step in restarting host agent is to access master agent, so if this step fails, all the following attemps fails.
In case the failure starts at master agent step, we need to try “restart” the master from ECC console. If this also hangs (in most cases, yes), we need to login to that host and do it from comand line as we showed in previous paragraphs. (./eccmad stop/start)
What is the meaning of corrupt label; wrong magic number in /var/adm/messages on a Solaris server?
The message means that a disk does not have a Solaris label on it yet. The disk in the message is sd##. This can be associated with its corresponding CTD device in the output of ls -Ralsi dev. (In this case sd## corresponded to cXtYdZ.) A label can be written to the disk by means of the label option under the format command.
Reference Architecture for Backup and Recovery of OLTP's with Data Domain and using Fibre Channel
Document purpose
This document describes the reference architecture for Backup and Recovery of OLTP database environments based on EMC CLARiiON, EMC Data Domain, EMC NetWorker, and using Fibre Channel solution.
This by focusing on the advantages and capabilities of CLARiiON® technology, EMC Data Domain®, and EMC NetWorker® software.
Today's IT is being challenged by the business to solve the following pain points around the backup and recovery of the business critical data:
- Protect the business information as an asset of the business defined Recovery Point Objective (RPO - amount of data to recover) and Recovery Time Objective (RTO - time to recover)
- Efficient use of both infrastructure and people to support the business
- Difficulties around the backing up of large enterprise-critical systems multiterabyte systems
Recovery time objectives RTO continue to decrease while the precision of the recovery point objective RPO increases.
It is not uncommon for organizations to routinely exceed their backup window or even have a backup window that takes up most of the day. Such long backup operations leave little margin for error and any disruption can place some of the data at risk of loss.
Because of the demands generated by data growth and the RTO/RPO requirements in OLTP database environments, it is critical that robust, reliable, and tested backup and recovery processes are in place.
To meet these backup and recovery challenges enterprises need proven solution architectures that encompass the best.
DB2 Backup Terminology and Parameters
As a brief refresher, lets review some backup terminology.
Backup Type
- Offline database backup - database in deactivated status, log parameters settings for circular logging (LOGRETAIN = OFF and USEREXIT = OFF), only crash recovery or version recovery possible
- Online database backup - database activated (database files in use), log parameters settings for archive logging (LOGRETAIN=ON and USEREXIT=ON), rollforward recovery enabled
Logging
If you want to perform rollforward recovery, you must switch the database from circular logging to archive logging.
- Circular logging - reuse of log files in round robin, content not preserved. Circular logging does not allow for rollforward recovery. Circular logging therefore supports only crash and version recovery.
If a database is using circular logging, the database can be backed up only when no applications are connected to the database. This form of a backup is known as an offline backup. - Archive logging - upon commit, log files are closed and become offline archived logs. When a database uses archive logging, it can be backed up when the database is online. In addition archive logging allows you to back up at the tablespace level.
Log file
If a log contains information about transactions that have not been committed or rolled back, or if a log contains information that has been committed but has not been externalized to the database disk, the log is considered active.
If a log contains information about committed and subsequently externalized transactions (that is, transactions that have been persisted to disk), and the logs are located in the same disk as the active logs, these logs are online archive logs.
Archive logs that have been moved from the active log directory to another directory or media are known as offline archive logs.
- Online log file - log file with active content in defined database log directory.
- Offline log file - filled log file, moved from log file path to archive storage.
Recovery history file
Special logging repository for tracking various database activity: backup, restore, rollforward, alter, rename, quiesce tablespace, load, drop, reorganization of table or update of table statistics. Entries from this file are read with the LIST HISTORY command.
Reference architecture
The backup process was off-loaded to a NetWorker storage node host using a Navisphere SnapView Snapshots to minimize the impact to the production environment.
SnapView creates logical point-in-time views of production information using snapshots, and point-intime
copies using clones. Snapshots use only a fraction of the original disk space, while clones require the same amount of disk space as the source.
SnapView offers users the choice between Snapshots and Clones for use in their backup operations. It should be noted that creating Clones will take more time than creating Snapshots, since the former requires actually copying data. If the snapshot is to be used for backup using filesystem access, then the production host and secondary host must be running the same operating system. SnapView allows parallel processing without impacting the performance of the production application, tasks can include disk-based backup and recovery.
Backup and recovery was implemented using the database tools (RMAN for Oracle and db2backup for DB2), EMC NetWorker, and an EMC Data Domain DD880 appliance.
The following image depicts the overall physical architecture of the solution.

The following table describes the key components and their configuration details within this environment.
| Component | Configuration | Software |
|---|---|---|
| CLARiiON CX4-960 | FLARE 04.29.XXX.Y.ZZZ | |
| Data Domain DD880 | DDOS 4.Y.Z.W | |
| NG 8 | ||
| NetWorker | NetWorker Management Console, server, storage nodes, clients | NetWorker 7.5 |
| SL3000 | ||
| DB2 |
Hardware and Software Installation
Hardware Installation
M5000
LAN Information
SAN Information
Clariion
The CLARiiON series storage platform consists of these modular assemblies:
- SPE (storage processor enclosure) and SPS (standby power supply): SPEs include two storage processors for redundancy. Each SPE is shipped with the two SPS.
- UltraFlex I/O Modules: Depending on the system, a certain number of pre-configured connectivity modules with iSCSI and Fibre Channel are included in each initial starting system, more can be added at later time.
- UltraPoint DAE: Holds up to 15 drives. Connects to array through Fibre Channel at 4 Gb/s; additional DAEs will expand system capacity.
- Vault Pack: The initial five drives in the first DAE are used for FLARE operating system and vault drives.
Physical Size Considerations
When considering combining various configurations, special attention must be paid to the overall system and chassis size as new racks might be necessary.
The CLARiiON CX4-960 maximum configuration with 8 back-end Fibre Channel loops will expand to 6 cabinets.
Drive Configuration Rules and Guidelines
The CLARiiON CX4 series is configurable to accommodate several storage requirements, including storage capacity, RAID levels, RAID Groups, number of LUNs, LUN size, and back-end connectivity.
The CLARiiON CX4 systems can span up to 960 drives. The following table outlines the minimum and maximum capacities. These capacities can be reached using combination of lowest capacity vault drives for the minimum raw capacity column and high-capacity SATA II drives (as well as highest capacity Fibre Channel drives for vault drives on for maximum raw capacity column, respectively.
DAEs can be populated with combinations of:
- 450 GB, 15,000 rpm, 4 Gb/s Fibre Channel drives (168 disks)
- 1 TB, 7,200 rpm, 4 Gb/s SATA II drives (66 disks)
- 600 GB, 10,000 rpm, 4 Gb/s Fibre Channel drives (47 disks)
Power Requirements
When the configuration has more then 6DAE's, the power required are 4 power zones of 32A, with every 2 power zones on a different phase conductor. Only then the redundancy can be obtained when one of the phase conductors fails.
LAN Information
You need a standard CAT 5 or better Ethernet network cable for the management port on each storage-system SP.

On each SP connect one end of an Ethernet network cable to the management port on the SP and the other end to the network from which you will manage the storage system
The network IP (Internet Protocol) address (for example, 128.222.78.10) for communication with the virtual port).
Do not use IP addresses 128.221.1.248 through 128.221.1.255, 192.168.1.1, or 192.168.1.2.
Initializing the storage system
After the storage system is fully powered up for the first time, use the Navisphere Storage System Initialization Utility to initialize the storage system. Initialization sets the network parameters for storage-system management and/or creates a management user account for the storage system so you can manage it over the LAN.
| Clariion ID | Site | Storage processor | Nodename | IP Address | Subnet mask | Gateway | VLAN ID | Cable ID |
|---|---|---|---|---|---|---|---|---|
| CKM00100700030_CR2CX02 | CR2 | SPA | CR2CX02SPA | 10.21.10.41 | 255.255.255.0 | 10.21.10.1 | 1910 | E4 V01 DP-U02177 SWCR-201 2/44 DP-U02176 |
| CKM00100700030_CR2CX02 | CR2 | SPB | CR2CX02SPB | 10.21.10.42 | 255.255.255.0 | 10.21.10.1 | 1910 | E4 V01 DP-U02178 SWCR-202 3/15 DP-U02179 |
| CKM00101000327_CR5CX02 | CR5 | SPA | CR5CX02SPA | 10.23.10.91 | 255.255.255.0 | 10.23.10.1 | 3010 | O40/101 DP-U02182 SWCR-502 7/37 DP-U02181 |
| CKM00101000327_CR5CX02 | CR5 | SPB | CR5CX02SPB | 10.23.10.92 | 255.255.255.0 | 10.23.10.1 | 3010 | O40/201 DP-U02183 SWCR-501 7/28 DP-U02180 |
SAN Information
With the exception of slots A0 and B0, the slots occupied by the required I/O modules can vary between configurations. Figure below shows the I/O module slot locations and the I/O modules for the standard minimum configuration.

IMPORTANT
I/O modules are always installed in pairs one module in SP A and one module in SP B.
Both SP's must have the same type of I/O modules in the same slots. Slots A0 and B0 always contain a Fibre Channel I/O module with 2 back-end ports and 2 front-end ports, the 2 back-end BE ports are 0, 1 and the 2 front-end FE ports are 2, 3.
Each FC back-end port has a connector for a copper SFP-HSSDC2 (small form factor pluggable to high speed serial data connector) cable. Back-end connectivity cannot exceed 4 Gb/s regardless of the I/O module’s speed.
The FC module in slots A0 and B0 support the following back-end buses:
- Bus 0 on port 0
- Bus 1 on port 1
The FC module usually in slots A1 and B1, with both BE and FE ports, support the following back-end buses:
- Bus 2 on port 0
- Bus 2 on port 1
The other available slots can contain any type of I/O module that is supported for the storage system
| Site | Fabirc | Clariion Port | Clariion WWN | Cable ID | SAN Switch | Slot | Port |
|---|---|---|---|---|---|---|---|
| CR2 | Upper Fabric | SPB1 3 | 50:06:01:6b:3b:20:10:a8 | DP-M07733 | Englbp010 | 13 | |
| SPA0 2 | 50:06:01:60:3b:20:10:a8 | DP-M07732 | fngcr2swfup1 | 1 | 12 | ||
| SPA1 2 | 50:06:01:62:3b:20:10:a8 | DP-M07736 | fngcr2swfup1 | 2 | 12 | ||
| SPB0 3 | 50:06:01:69:3b:20:10:a8 | DP-M07738 | fngcr2swfup1 | 3 | 12 | ||
| Lower Fabric | SPA1 3 | 50:06:01:63:3b:20:10:a8 | DP-M07731 | Englbp020 | 13 | ||
| SPA0 3 | 50:06:01:61:3b:20:10:a8 | DP-M07734 | fngcr2swflo1 | 1 | 12 | ||
| SPB0 2 | 50:06:01:68:3b:20:10:a8 | DP-M07735 | fngcr2swflo1 | 2 | 12 | ||
| SPB1 2 | 50:06:01:6a:3b:20:10:a8 | DP-M07737 | fngcr2swflo1 | 3 | 12 | ||
| CR5 | Upper Fabric | SPB1 3 | 50:06:01:6b:3b:20:45:2e | DP-M07739 | Englbd010 | 13 | |
| SPA0 2 | 50:06:01:60:3b:20:45:2e | DP-M07744 | drsscr5swfup1 | 10 | 26 | ||
| SPA1 2 | 50:06:01:62:3b:20:45:2e | DP-M07745 | drsscr5swfup1 | 9 | 10 | ||
| SPB0 3 | 50:06:01:69:3b:20:45:2e | DP-M07746 | drsscr5swfup1 | 2 | 26 | ||
| Lower Fabric | SPA1 3 | 50:06:01:63:3b:20:45:2e | DP-M07743 | Englbd020 | 13 | ||
| SPA0 3 | 50:06:01:61:3b:20:45:2e | DP-M07740 | drsscr5swflo1 | 2 | 26 | ||
| SPB0 2 | 50:06:01:68:3b:20:45:2e | DP-M07741 | drsscr5swflo1 | 10 | 26 | ||
| SPB1 2 | 50:06:01:6a:3b:20:45:2e | DP-M07742 | drsscr5swflo1 | 9 | 10 |
Translating a CX4 Series World Wide Port Name (WWPN) to new port numbers.
CLARiiON software currently supports the generation of a unique front-end Fibre Channel WWN for 16 ports per array and eight (8) per SP. This format has been in place since the later releases of the FC4500 through the CX3 platforms. The new CX4 Series platform can be configured to support up to 24 Fibre Channel front-end ports per array and 12 per SP (CX4-960). Numbering of WWNs does go up to (30) WWNs per array and (15) WWNs per SP (CX4-960). This hardware change requires an increase in the number of WWN's supported per array.
Two unused bits within the vendor specific part of the World Wide Port Name (WWPN) have been reserved and added to the existing four bits of the port field. These bits are considered the high order bits of the port field (bits 18 – 19). This allows for the creation of 64 WWN's per array and 32 per SP. Conversions from a CX/CX3 array to a CX4 array will retain all current WWN's in use by the customer. The WWN Seed is not effected by this change. The EMC Global Services Tools organization is updating their WWN tools to handle this format change. The same hex digit is used as in the past plus two (2) binary bits from another hex byte. The two hex digits plus the addition hex digit that need to be broken down are in bold.
| Node Name | Port Name | SP – Logical Port id | WWN Port id | hex digit converted to binary |
|---|---|---|---|---|
| 50 06 01 60 B0 60 56 78 | 50 06 01 60 30 60 56 78 | SPA 0 | ( 0-7 ) | 0 = 0000 |
| 50 06 01 60 B0 60 56 78 | 50 06 01 68 30 60 56 78 | SPB 0 | ( 8-15 ) | 0 = 0000 |
| 50 06 01 60 B0 60 56 78 | 50 06 01 60 30 64 56 78 | SPA 8 | ( 16-23 ) | 4 = 0100 |
| 50 06 01 60 B0 60 56 78 | 50 06 01 68 30 64 56 78 | SPB 8 | ( 24-31 ) | 4 = 0100 |
| 50 06 01 60 B0 60 56 78 | 50 06 01 60 30 68 56 78 | SPA 16 | ( 32-39 ) | 8 = 1000 |
| 50 06 01 60 B0 60 56 78 | 50 06 01 68 30 68 56 78 | SPB 16 | ( 40-47 ) | 8 = 1000 |
| 50 06 01 60 B0 60 56 78 | 50 06 01 60 30 6C 56 78 | SPA 24 | ( 48-55 ) | C = 1100 |
| 50 06 01 60 B0 60 56 78 | 50 06 01 68 30 6C 56 78 | SPB 24 | ( 56-63 ) | C = 1100 |
In the figure below you can see a multi-cabinet storage-system configuration with eight DAE's on each
of four buses

Centera
Power Requirements
LAN Information
SAN Information
Celerra
For dual Control Station systems, a crossover cable from the port labeled CS on CS 0 to the port labeled CS on CS 1 see figure below:
Note: The blade enclosure with the attached product serial number (PSN) tag must be installed as the bottom or lowest blade enclosure to ensure that it becomes blade enclosure 0. Blade enclosure 0 has the PSN tag attached with a cable tie to the chassis power supply vent holes near the management module.
Power Requirements
The power cables connect the Celerra cabinet to the customer’s power supply circuits. To ensure high availability, be sure each cabinet power cord connects to a different circuit.
The power cables connect the Celerra NS-G8 system components to the customer’s power supply circuits. Blades have two power supplies. To ensure high availability, be sure each blade power supply connects to a different circuit.
Connect the two 240-volt AC power cables from the rack to the power outlets provided by the customer. Connect each cable to a different circuit for high availability.
LAN Information
The external network cables connect clients of the Celerra system to the blades. Connect the Ethernet LAN cable, labeled MGMT network symbol on the Control Station CS to the customer’s 10/100 Ethernet network that will be used to manage the Celerra system.
| Celerra ID | Site | Control Station | Nodename | IP Address | Subnet mask | Gateway | VLAN ID | Cable ID |
|---|---|---|---|---|---|---|---|---|
| FNGNS01 | CR2 | CS0 | fngns01c0 | 10.21.10.93 | 255.255.255.0 | 10.21.10.1 | 1910 | K6 V03 DP-U05939 SWCR-202 4/15 DP-U05939 |
| CS1 | fngns01c1 | 10.21.10.94 | 255.255.255.0 | 10.21.10.1 | 1910 | K7 V06 DP-U05940 SWCR-201 4/7 DP-U05940 | ||
| DRSNS01 | CR5 | CS0 | drsns01c0 | 10.23.10.95 | 255.255.255.0 | 10.23.10.1 | 3010 | |
| CS1 | drsns01c1 | 10.23.10.96 | 255.255.255.0 | 10.23.10.1 | 3010 |
Another external network cable connects the CS to the customer’s network for remote management of the system.
Slots 1, 2, 3, and 4 in the blade are available for external network cabling depending on the supported I/O module combination.
The private (internal) LAN cables connect the Control Station to the blades through the blade enclosure’s management modules. Each blade enclosure has two management modules, one on each side of the enclosure. The two management modules are redundant for each blade enclosure. If module A fails, module B assumes control of the private network.

These cables and switches make up a private network that does not connect to any external network.
The NS-G8 system has an internal network formed by daisy-chaining the management modules attached to each enclosure. The Control Stations communicate to all blades through the management modules on both sides of the enclosures.
SAN Information
Each CLARiiON CX4-960 SP has eight, twelve, or sixteen SAN ports, with four, eight, or twelve ports available for connections to SAN fabrics. If all of the SAN ports on the array are already connected to the fabric, you do not need to change these connections. If the array has two available ports on each SP, the recommended practice is to cable these ports to the switches and dedicate them to the Celerra gateway system. If you are using two switches to connect a CLARiiON CX4-960 array, connect the cables as illustrated below
Image:Clariion CX4-960 Celerra.jpg
Arrange the cables so that a failed component can be removed without disconnecting other cables.
Fibre Channel cables connect the blades to the Symmetrix and CLARiiON arrays
through Fibre Channel switches. Two Fibre Channel switches are recommended for high availability.
Blades connected to two switches for high availability
| Site | Fabirc | type | NS-G8 blade | NS-G8 WWN | Cable ID | SAN Switch | Slot | Port |
|---|---|---|---|---|---|---|---|---|
| CR2 | Upper Fabric | NDMP | NS-G8 B1 | DP-M07798 | fngcr2swfup1 | 3 | 18 | |
| NS-G8 A1 | DP-M07788 | fngcr2swfup1 | 9 | 18 | ||||
| NS-G8 B0 | DP-M07802 | fngcr2swfup1 | 10 | 16 | ||||
| NS-G8 A0 | DP-M07792 | fngcr2swfup1 | 3 | 26 | ||||
| NAS | NS-G8 B1 | DP-M07786 | fngcr2swfup1 | 2 | 29 | |||
| NS-G8 A1 | DP-M07790 | fngcr2swfup1 | 10 | 23 | ||||
| NS-G8 B0 | DP-M00632 | fngcr2swfup1 | 1 | 28 | ||||
| NS-G8 A0 | DP-M07796 | fngcr2swfup1 | 3 | 29 | ||||
| Lower Fabric | NDMP | NS-G8 B1 | DP-M07800 | fngcr2swflo1 | 1 | 1 | ||
| NS-G8 A1 | DP-M07791 | fngcr2swflo1 | 9 | 28 | ||||
| NS-G8 B0 | DP-M07795 | fngcr2swflo1 | 10 | 5 | ||||
| NS-G8 A0 | DP-M07801 | fngcr2swflo1 | 3 | 29 | ||||
| NAS | NS-G8 B1 | DP-M07799 | fngcr2swflo1 | 2 | 29 | |||
| NS-G8 A1 | DP-M07787 | fngcr2swflo1 | 10 | 24 | ||||
| NS-G8 B0 | DP-M07797 | fngcr2swflo1 | 3 | 28 | ||||
| NS-G8 A0 | DP-M07789 | fngcr2swflo1 | 1 | 29 | ||||
| CR5 | Upper Fabric | NDMP | NS-G8 B1 | DP-M00681 | drsscr5swfup1 | 10 | 18 | |
| NS-G8 A1 | DP-M00679 | drsscr5swfup1 | 9 | 18 | ||||
| NS-G8 B0 | DP-M00685 | drsscr5swfup1 | 10 | 19 | ||||
| NS-G8 A0 | DP-M00683 | drsscr5swfup1 | 9 | 19 | ||||
| NAS | NS-G8 B1 | DP-M00681 | drsscr5swfup1 | 10 | 18 | |||
| NS-G8 A1 | DP-M00679 | drsscr5swfup1 | 9 | 18 | ||||
| NS-G8 B0 | DP-M00685 | drsscr5swfup1 | 10 | 19 | ||||
| NS-G8 A0 | DP-M00683 | drsscr5swfup1 | 9 | 19 | ||||
| Lower Fabric | NDMP | NS-G8 B1 | DP-M00682 | drsscr5swflo1 | 10 | 18 | ||
| NS-G8 A1 | DP-M00680 | drsscr5swflo1 | 9 | 18 | ||||
| NS-G8 B0 | DP-M00686 | drsscr5swflo1 | 10 | 19 | ||||
| NS-G8 A0 | DP-M00684 | drsscr5swflo1 | 9 | 19 | ||||
| NAS | NS-G8 B1 | DP-M00682 | drsscr5swflo1 | 10 | 18 | |||
| NS-G8 A1 | DP-M00680 | drsscr5swflo1 | 9 | 18 | ||||
| NS-G8 B0 | DP-M00686 | drsscr5swflo1 | 10 | 19 | ||||
| NS-G8 A0 | DP-M00684 | drsscr5swflo1 | 9 | 19 |
NDMP tape backup device cables
The Celerra system can connect to NDMP tape backup devices using optical cables, either directly or through a Fibre Channel switch.
Each blade has two ports that can be used for tape devices: port 2 and port 3 in the I/O module located in slot 0. These ports sense the speed of the device they connect to and automatically configure for 1, 2, 4 or 8 Gb/s.
Both ports sense the topology of the Fibre Channel network they are connected to and automatically configure for arbitrated loop or switched fabric as needed
Data Domain 880
Power Requirements
LAN Information
| Site | Data Domain ID | Nodename | IP Address | Subnet mask | Gateway | VLAN ID | Cable ID |
|---|---|---|---|---|---|---|---|
| CR2 | 0F48W06604 | fngdd01eth0 | 10.21.10.91 | 255.255.255.0 | 10.21.10.1 | 1910 | K4 V01 DP-U05944 SWCR-201 3/5 DP-U05936 |
| fngdd01eth1 | 10.20.88. | 255.255.255.0 | 88 | K4 V02 DP-U05941 SWCR-202 2/48 DP-U05937 | |||
| 0F48W06627 | fngdd02eth0 | 10.21.10.92 | 255.255.255.0 | 10.21.10.1 | 1910 | K6 V01 DP-U05935 SWCR-202 4/14 DP-U05934 | |
| fngdd02eth1 | 10.20.88. | 255.255.255.0 | 88 | K6 V02 DP-U05943 SWCR-201 3/17 DP-U05942 | |||
| CR5 | drsdd01eth0 | 10.23.10.93 | 255.255.255.0 | 10.23.10.1 | 3010 | ||
| drsdd01eth1 | 10.20.88. | 255.255.255.0 | 88 | ||||
| drsdd02eth0 | 10.23.10.94 | 255.255.255.0 | 10.23.10.1 | 3010 | |||
| drsdd02eth1 | 10.20.88. | 255.255.255.0 | 88 |
SAN Information
| Site | Fabirc | Data Domain Slot/Port | Data Domain WWN | Cable ID | SAN Switch | Slot | Port |
|---|---|---|---|---|---|---|---|
| CR2 | Upper Fabric | FNGDD01 5/1 | DP-M07780 | fngcr2swfup1 | 2 | 23 | |
| FNGDD01 4/1 | DP-M07781 | fngcr2swfup1 | 3 | 13 | |||
| FNGDD02 5/1 | DP-M07784 | fngcr2swfup1 | 10 | 15 | |||
| FNGDD02 4/1 | DP-M07782 | fngcr2swfup1 | 9 | 12 | |||
| Lower Fabric | FNGDD01 5/2 | DP-M05691 | fngcr2swflo1 | 2 | 24 | ||
| FNGDD01 4/2 | DP-M05689 | fngcr2swflo1 | 3 | 30 | |||
| FNGDD02 5/2 | DP-M07785 | fngcr2swflo1 | 10 | 15 | |||
| FNGDD02 4/2 | DP-M07783 | fngcr2swflo1 | 9 | 21 | |||
| CR5 | Upper Fabric | DRSDD01 5/1 | DP-M00681 | drsscr5swfup1 | 10 | 18 | |
| DRSDD01 4/1 | DP-M00679 | drsscr5swfup1 | 9 | 18 | |||
| DRSDD02 5/1 | DP-M00685 | drsscr5swfup1 | 10 | 19 | |||
| DRSDD02 4/1 | DP-M00683 | drsscr5swfup1 | 9 | 19 | |||
| Lower Fabric | DRSDD01 5/2 | DP-M00682 | drsscr5swflo1 | 10 | 18 | ||
| DRSDD01 4/2 | DP-M00680 | drsscr5swflo1 | 9 | 18 | |||
| DRSDD02 5/2 | DP-M00686 | drsscr5swflo1 | 10 | 19 | |||
| DRSDD02 4/2 | DP-M00684 | drsscr5swflo1 | 9 | 19 |
SL3000 Tape Labrary
Base Module—Rear View Drawing
Image:SL3000 rear.jpg
Power Requirements
LAN Information
Electronics Control Module
Image:SL3000 ECM.jpg
| SL3000 ID | Site | Port | Nodename | IP Address | Subnet mask | Gateway | VLAN ID | Cable ID |
|---|---|---|---|---|---|---|---|---|
| CR2 | FNGSL3000A | 10.22.10.35 | 255.255.255.0 | 10.22.10.1 | 2099 | |||
| CR2 | FNGSL3000B | 10.22.10.36 | 255.255.255.0 | 10.22.10.1 | 2099 | |||
| CR5 | DRSSL3000A | 10.23.10.37 | 255.255.255.0 | 10.23.10.1 | 3010 | |||
| CR5 | DRSSL3000B | 10.23.10.38 | 255.255.255.0 | 10.23.10.1 | 3010 |
SAN Information
Software Installation
NetWorker Commands
NetWorker Resource Relationships
With NetWorker having many components that can link together in a variety of ways, it’s not always easy (particularly for new-comers) to have a mental map of how all those components interact. Having made repeated stabs over the years to come up with a coherent diagram showing those relationships, I have a frustrated understanding of the difficulty of drawing the relationships.
Lately I decided to take a slightly different approach – to reduce the level of the diagram to the bare basic components so as to try to give a big overview rather than every possible detail. It’s highly likely I’ve left stuff off, and my diagramming skills aren’t the best – but hopefully if you’re not sure of how everything fits together in NetWorker it may help to improve your mental map of it.
For the most part, I’ve tried to stick to components that are defined resource types within NetWorker. A couple of notable exceptions are “Volume” and “Level” … neither of these are defined resources as per the NetWorker resource database, but knowing where they appear in usage helps to fill in a few gaps that would otherwise be confusing.
mminfo commands
The mminfo command is typically performed on a NetWorker server.
- Display a media report of all volumes used for backups of client monet in the past week.
# mminfo -m -q "client=monet,savetime>=last week"
- Display a report of all volumes showing the volume name, % of space used on the volume, and the pool to which the volume belongs.
Here’s a quick summary of the important date/time fields that provide information about savesets:
- savetime – The time/date, on the client of the backup.
- sscreate – The time/date on the server of the backup.
- ssinsert – The time/date on the server of the last time the saveset was inserted into the media database.
- sscomp – The time/date that the backup completed*.
- ssaccess – The date/time that the backup was last accessed for backup or recovery purposes**.
mminfo, savetime and greater than/less than
Take a basic mminfo query, add someone not familiar with how NetWorker stores and works with dates/times, and you have instant chaos*.
So let’s look at a basic query that tends to cause a lot of confusion:
# mminfo -q "client=balder,savetime<=2 weeks ago"
As a long-term NetWorker user, this question seems to come up fairly frequently. The output appears broken – rather than being savetime less than or equal to two weeks ago, we instead get all backups for the client balder where the savetime is greater than or equal to two weeks ago.
NetWorker stores and works with times as seconds since the(/an) epoch. When you supply dates to NetWorker – either in the fuzzy format above, or as a literal date string, it converts that date into a timestamp of seconds since the(/an) epoch. (You can if you want find out what a savetime is in seconds, rather than an interpreted date any time you wish in mminfo by choosing a report specification of nsavetime.)
You’re actually asking NetWorker:
- Convert 2 weeks ago into seconds offset from now. Let’s call that Z.
- Give me all the backups for the client balder where the savetime is less than or equal Z.
If you don’t like to think of it as all referring to seconds since an epoch, there’s another, perhaps simpler way of thinking about it – that being:
- Treat < as meaning before.
- Treat > as meaning after.
How can I find out what files were backed up?
This is actually fairly easy, particularly if you’re prepared to use the command line. You need to run two commands – mminfo, and nsrinfo.
The command mminfo accesses the NetWorker media database, and is used to pull out details of the saveset whose files you want to view. The nsrinfo command is then used to retrieve the relevant information from the client file index. The nsrinfo command does take a filename argument.
For example, consider the following situation – there’s two backups of the “/db2backup/<nodename>/” directory on the storage node “balder”, and we want to know what was backed up in each backup. First, run mminfo to retrieve the nsavetime, which we use in nsrinfo. The mminfo command might resemble the following:
# nsrinfo -t `mminfo -q "name=/db2backup/<nodename>/" -r nsavetime` <storage_node_name>
The most common invocation format of nsrinfo is: nsrinfo -t nsavetime clientName
Having retrieved the nsavetime field, we can then feed that into nsrinfo in order to get the list of files for that backup:
Like most NetWorker commands, nsrinfo will also accept a -v option for verbosity. Include this in your nsrinfo command and you get a whole lot more information.
If you’re wondering how NetWorker knows which saveset to retrieve based on the nsavetime, it’s simple – for any individual client, no two savesets will ever be generated with the same nsavetime.
Changing saveset browse/retention times
To change the browse or retention time, you’ll need to find out the saveset ID (SSID) of the given saveset. This can be done with mminfo.
For instance, say you had a backup done last night of a machine called balder that has now been rebuilt, but you want to keep the old backup for much longer than normal – e.g., ten years instead of the normal 3.
First, to find out what you need to change, get a list of the SSIDs:
# mminfo -q "client=balder,savetime>=24 hours ago" -r name,ssid name ssid / 4036558666 /Volumes/TARDIS/Yojimbo 4019781450 /Volumes/Yu 4003004234
Now, for each of those SSIDs that are returned, we’ll run a nsrmm command to adjust the browse and retention time*.
The basic nsrmm command for adjusting the browse and retention time is:
# nsrmm -S ssid -w browse -e retent
You can also do this against an instance of a saveset by using the SSID/Clone ID; to do that variant, request -r name,ssid,cloneid, then use the two numbers in the nsrmm command separated by a forward slash – (ssid/cloneid).
# nsrmm -S ssid/cloneid -w browse -e retent
Where the browse and retent values can be either one of the two following:
- A literal date in US date format ** – e.g., 12/31/2019 for 31 December 2019.
- A fuzzy english worded date – e.g., +10 years for 10 years from today.
Note that, your browse time cannot exceed your retention time, and generally its recommended that you set browse time to retention time.
So in this case, you’d run for each SSID or SSID/CloneID you want to affect:
# nsrmm -S ssid -w "+10 years" -e "+10 years"
Which will look like the following, based on my mminfo output:
# nsrmm -S 4036558666 -w "+10 years" -e "+10 years" # nsrmm -S 4019781450 -w "+10 years" -e "+10 years" # nsrmm -S 4003004234 -w "+10 years" -e "+10 years"
Labelling and Relabelling without Unmounting
Here’s a common scenario – you want to label a volume, or relabel a volume, and use it straight away. The default behaviour of NetWorker after labelling or relabelling a volume is to then unmount it, which means having to then manually mount the volume after it has been (unnecessarily) ejected.
Getting around this behaviour is quite easy, and just requires a bit of typing on the command line.
Let’s look first at relabelling, since this is arguably the most common scenario. Say you’ve got a volume in slot 21 of your tape library that you want to relabel and have it remain mounted so you can immediately start using it. For a normal relabel operation you’d consider something like:
# nsrjb -LRYvvv -S 21
Note 1: Always put in the -vvv option whenever dealing with a jukebox. These days I practically consider it to be best practices.
Note 2: In the examples we are using the -Y switch, which means NetWorker does not prompt for any confirmation on the operation (it assumes Yes in response to any question it may have); this is done only for the purposes of keeping example output simplified, and I don’t recommend you get in the habit of using it.
Instead of using the -L option here, we switch to -l (for load); thus the command becomes:
# nsrjb -lRYvvv -S 21 setting verbosity level to `3' Info: Preparing to load volume `BIG990S3' from slot 21 into device `/dev/nst0'. Info: Loading volume `BIG990S3' from slot `21' into device `/dev/nst0'. Info: Load sleep for 5 seconds. Info: Performing operation `Verify label' on device `/dev/nst0'. Info: Operation `Verify label' in progress on device `/dev/nst0' Info: Performing operation `Label' on device `/dev/nst0'. Info: Operation `Label' in progress on device `/dev/nst0' Info: Recycling volume `BIG990S3'
Those of you familiar with highly verbose nsrjb output will recognise that there’s no Unmount in progress style message; the volume remains mounted and instantly ready for use once the relabel operation is complete.
Now, moving on to a tape that hasn’t previously been labelled, we’d usually use a command such as:
# nsrjb -LYvvv -b poolName -S x
However, to keep the tape mounted after labelling, we need to include the -m option; thus, if we wanted to label the tape in slot 1 into the Default Clone pool and keep it mounted after labelling, our command would look like the following:
nsrjb -mLYvvv -b "Default Clone" -S 1 setting verbosity level to `3' Info: Preparing to load volume `800843S3' from slot 1 into device `/dev/nst0'. Info: Loading volume `800843S3' from slot `1' into device `/dev/nst0'. Info: Load sleep for 5 seconds. Info: Performing operation `Verify label' on device `/dev/nst0'. Info: Operation `Verify label' in progress on device `/dev/nst0' Info: Expected volume `800843S3' in slot `1'. The actual volume is `<NULL>'. Info: Cannot read the current volume label `no tape label found'. Info: nsrmmgd assumes the volume is unlabeled and will write a new label. Info: Performing operation `Label' on device `/dev/nst0'. Info: Operation `Label' in progress on device `/dev/nst0' Info: Label: `800843S3', pool: `Default Clone', capacity: `<NULL>'.
Don’t forget Note 2 above! It’s not wise to get into the habit of throwing a -Y into nsrjb commands; the examples only show it to keep the examples simpler.
mmpool command
The utility mmpool is one of those lesser used utilities in NetWorker that you may not necessarily know about, nor would you necessarily always need to use it, but it’s handy to know about it.
Similar to the more well known mmlocate utility, mmpool is designed to list pools on a NetWorker server, and for any pool, list the volumes in that pool. It also has some more dangerous options in that it can delete all volumes in a pool, but thankfully it will prompt you about each volume, so you can’t just go blindly destroying media database entries.
The two options I find most useful with mmpool are:
- -L – List all pools
- -l pool – List all volumes in the nominated pool.
For example:
# mmpool -L Staging Staged Clone PC Archive Clone Indexed Archive Indexed Archive Clone Default Full NonFull Offsite Default Clone Archive Clone PC Archive Archive
To review all the volumes in the pool Staged Clone, you would run:
# mmpool -l "Staged Clone" volume pool Clone.001 Staged Clone Clone.002 Staged Clone Clone.003 Staged Clone Clone.004 Staged Clone Clone.005 Staged Clone
Again, mmpool is not a utility you’ll find yourself running every day, but it is useful to have available.
Setting cleaning tape usage/registering a cleaning tape
If NetWorker is managing your cleaning, it’s typically a case of just telling NetWorker how many cleaning uses are left in the nominated slot(s) for cleaning.
I always prefer to do it from the command line. From there, the command is:
# nsrjb -U x -S y
Where:
- x is the number of uses of the cleaning cartridge left (e.g., 20)
- y is the slot number of the cleaning cartridge you want to register.



