Migrando de storage con SRDF. Este documento no reemplaza la documentacion de SRDF ni explica como migrar storage, sino, es una breve guia, a modo de procedimiento para quienes tienen experencia en SRDF. Pasos a seguir:

0. Hacer las zonas entre los puertos de SRDF de los storage, si estos no estan DAS.

0. Estando en modo configuracion del switch, correr “zone name (nombre de zona) ; member (wwn del puerto del storage) ; member (wwn del host a conectar) NO habilitar las zonas. Ejemplo: zone name servename01_HBAp _VMAX_7G1_VSANxxx member 21:00:00:e0:8b:9a:24:39 member 50:00:09:74:C0:0D:4D:99

1. Establecer relacion entre cajas. Para eso, se conectaran ambos equipos mediante el vinculo SRDF, y se establecera una relacion logica. (utilizar adaptive copy)

1. symcfg -sid xyz list -rdfg all list

2. Armado de parejas SRDF. Para esto, se arma un documento xls con las parejas que incluye cada host y un archivo txt para la parte practica.

2. symrdf -sid xyz createpair -file pares.txt -type RDF1 -rdfg <Ragroup> -invalidate R2 -g <nuevogrupo>

3. Sincronizacion de SRDF (dejar todos los vinculos en SYNC)

3. symrdf -g nuevogrupo set mode acp_wp symrdf -g nuevogrupo establish -full symrdf -g nuevogrupo query al llegar al 80 o 90%, hacer sync symrdf -g nuevogrupo set mode sync

4. Bajar el sistema operativo del servidor a migrar (en windows 2xxx hacere un flush del

filesystem)

4. shutdown flushfs.vbs: BOOL WINAPI FlushFileBuffers( __in HANDLE hFile );

5. Hacer un query del estado de la copia (symrdf query) 5. # symntctl umount –drive “drive_letter” –fs symrdf -g nuevogrupo query

6. Split de la copia (corta la copia y pone los discos R2 destino en RW, los deja usables ya para el equipo migrado)

6. symrdf -g <grupoexistente> split

7. Deshabilitar zonas orginales contra el Storage origen y habilitar las zonas nuevas, contra el Storage destino.

7. deshabilitar las zonas viejas / habilitar las nuevas segun explicado en paso 0.

8. Hacer el masking correspondiente. (o symacl, segun corresponda). 8. symmask -sid xxx -wwn 210000e08b9a2439 -dir 8G -p 0 add devs 418 -noprompt -O- symaccess –sid xxx create –type……………. Etc. (solo en VMAX)

9. Inicializar los equipos (bootear) normalmente, los equipos deberian levantar normalmente, viendo los discos como veia los originales.

10. Luego de haber verificado la consistencia de datos y que todo levanto OK, sacar el

atributo R2 a los devices destino en el VMAX. 10. symrdf -g <grupoexistente> deletepair

1) Verify that SRDF is properly configured on both the local and remote hosts. a) Use the following SYMCLI commands to list and verify the device groups you created in

the previous exercise. # symdg list (on both the local and remote hosts) # symdg show mysrcdg (on the local host) # symdg show mytgtdg (on the remote host)

b) Check the environment variables for SYMCLI and if necessary set the SYMCLI_DG variable to your device group. # symcli –def # SYMCLI_DG=mysrcdg (on the local host) # set SYMCLI_DG # SYMCLI_DG=mytgtdg (on the remote host) # set SYMCLI_DG

c) Verify the status of the devices in your device group. The local host should have RW access to the source (R1) volumes, the remote host should see the target (R2) volumes as being WD, the SRDF link should be enabled (RW), and there should be no invalid tracks. # symrdf query (on the local host)

2) Verify that drive letters are assigned and available for use. Perform this step on the

local host. a) Add more data files to your filesystems in Windows Explorer.

3) Pass control of the SRDF volume and associated data to the remote host. Before

we test disaster failover, we will do a normal failover to verify the procedure. This step not only involves passing control of the SRDF volumes to the remote host, it also requires that the remote host understand how the volumes are configured. If the local host has created volume partitions and filesystems on the SRDF source volumes, then the Volume information must be imported to the remote host, after a failover. In Windows 2000 drive letter assignments to Basic disks should be automatic after a failover. a) While in a disaster situation it is not possible to ”gracefully” shutdown applications and

unassign drive letters, it is always less risky to do so when ever possible. Before passing control of the SRDF volume to the remote host, we will first unassign the drive letters on the local host to deactivate the Volume. i) Unassign the drive letters in “Disk Management” by right clicking on the correct

disk and selecting the option to “change drive letter and path”, then click on the drive and select “remove”. If you have the SIU/CLI then use the following command strings:

# symntctl openhandle –drive “drive_letter” (on the local host) - to verify that no processes are using the R1 volume # symntctl umount –drive “drive_letter” –fs (to dismiss cache buffers) # symntctl umount –drive “drive_letter”

b) Initiate failover of the SRDF volumes by executing the following command from the remote host. The failover command can be executed from the local host. How ever, in a true disaster situation, we may not have access to the local host. # symrdf failover (on the remote host) Note the verbose output from the failover command. Each step is displayed as it is executed. The output could be piped to a file and saved for future study or reference. More detailed information is logged in the /var/symapi/log directory.

c) View the status of both the R1 and R2 volumes. # symrdf query (on the remote host) What level of access does the local host have to the source (R1) volumes? _________________________________________ What level of access does the remote host have to the target (R2) volumes? _________________________________ The source volumes should be Write Disabled (WD) and the target volumes Read/Write (RW). Even though the local host has read access to the source volumes, use caution when accessing it as integrity cannot be guaranteed.

d) Before the remote W2K host can use the data on the SRDF target volumes, the Volume definition information must be ”imported”. At the remote host, find the drive letters assigned to the R2 copies. In the Windows Explorer program, select the assigned drive letters to verify that the copied data is available.

4) Resume activities on the target host. The remote host now has full access to the SRDF volumes and associated data. To simulate production after a failover, we will make some changes to the filesystem. a) While at the remote host, add some data on the R2 mirrored volumes at that server. b) While changes are being made to the SRDF (R2) volumes from the remote host, the

link between the source and target volumes is disabled. Check to see how many invalid tracks have accumulated, using the appropriate command. # symrdf query How many invalid tracks are there? ___________________________ How many MB does this represent? ___________________________ Are the invalid tracks on the R1 or R2 Volumes? ____________________

5) Pass control of the SRDF volumes and data back to the local host. a) The remote host should not have the drive letters of the R2 volumes mounted while

control is being passed back to the local host because the remote host’s access to the target volumes will change to Read Only (WD). Attempting to write to the filesystem while the volumes are Write Disabled will cause unpredictable results. i) Unassign the drive letters in “Disk Management” by right clicking on the correct

disk and selecting the option to “change drive letter and path”, then click on the drive and select “remove”. If you have the SIU/CLI then use the following command strings:

# symntctl openhandle –drive “drive_letter” (on the local host) - to verify that no processes are using the R1 volume # symntctl umount –drive “drive_letter” –fs (to dismiss cache buffers) # symntctl umount –drive “drive_letter”

b) Make the source volumes active by executing the following command. # symrdf failback (on the remote host)

c) View the status of both the source (R1) and the target (R2) volumes. # symrdf query (on the remote host) What level of access does the local host have to the source volumes?

b) Change mode of operation to enable adaptive copy-disk mode for all devices in the device group. Verify that the mode change occurred and then disable adaptive copy.

# symrdf set mode acp disk

# symrdf query

# symrdf set mode acp off

# symrdf query Once You upgrade RDF to Dynamic RDF the syntax for removing RDF attribute from the devices would be as follows: 1)symrdf -file <filepath.txt> -sid [SYMMid] -rdfg [rdf_group_number] split This will split the RDF relationship. Then run: 2)symrdf -file <filepath.txt> -sid [Local_SYMMid] -rdfg [rdf_group_number] deletepair Where the content of the config (filepath.txt) file is : R1_Symmdev R2_Symmdev This will remove RDF attributte from both source and target device, reverting them back to their original configuration.

Adicionales, software no-EMC MS/SQL Clusters: The quorum disk is located on a shared bus in the cluster. Use the following procedure to designate a different drive for the quorum device: NOTE: I f you cannot start Cluster service because the quorum disk is unavai lable, use the /FIXQUORUM switch to start Cluster service. You are then able to change the quorum disk designation.

1. Start Cluster Administrator (CluAdmin.exe). 2. Right-click the cluster name in the upper-left corner, and then cl ick Properties. 3. Click the Quorum tab. 4. In the Quorum resource box, click a di fferent disk resource. 5. If the disk has more than one partition, click the partition where you want the cluster-

specific data to be kept, andthen click OK.

NOTE: I f you cannot start Cluster service because the quorum disk is unavai lable, use the /FIXQUORUM switch to start Cluster service. You are then able to change the quorum disk designation. When you change the quorum disk designation, Cluster service does not remove the /Mscs directory from the old drive. For administrative purposes, you may want to delete this old di rectory, or keep it as a backup. Do not continue running Cluster service with the /FIXQUORUM switch enabled. When the new quorum disk is established, stop the service and restart it without a switch. Then it is safe to bring other nodes online. It is recommended that you increase the quorum log size to 4,096 KB.

Se detalla aqui el procedimiento normalizado por EMC para Storage Vmotion. 1. Bajar Remote Command-line Interface e instalarlo. http://www.vmware.com/download/download.do?downloadGroup=VI-RCLI. Abrir un command line en c:\program files\vmware\vmware vi remote CLI\bin. Ejecutar: svmotion.pl – -interactive. 2. Aparece el siguiente mensaje: “ Enter the VirtualCenter service url you wish to connect to (e.g. https://myvc.my corp.com/sdk, or just myvc.mycorp.com): ” Ingresar la dirección del Virtual Center al que se quiere conectar. 3. Ante los siguientes command prompts ingresar usuario y passwords válidos en el Virtual Center. 4. Una vez que svmotion se conectó al Virtual Center, aparece el siguiente mensaje: “ Connected to server. ” 5. Ante el siguiente mensaje “ Enter the name of the datacenter:” ingrese el nombre del datacenter donde se encuentra el ESX server. 6. Ante el mensaje “ Enter the datastore path of the virtual machine (e.g. [datastore1] myvm/myvm.vmx):” ingrese los datos solicitados siguiendo el siguiente formato: [datastorename] VM name/VM name.vmx. 7. Ante el siguiente mensaje “ Enter the name of the destination datastore:” ingrese el nombre del datastore de destino. 8. Ante el siguiente mensaje “ You can also move disks independently of the virtual machine. If you want the disks to stay with the virtual machine, then skip this step. " “ Wo u l d y o u l i k e t o i n d i v i d u a l l y p l a c e t h e d i s k s (yes/no)? ” seleccionar No si se desea que todos los discos virtuales de esta VM sean almacenados en el mismo datastore junto con la misma VM. 9. A continuación, los datos de la máquina virtual indicada serán migrados de manera online hacia el nuevo datastore.

Se detalla aqui el procedimiento normalizado por EMC para AIX LVM. • Add the new disk to the volume group (for example, hdisk1): # extendvg AIXTSM hdiskX • If you use one mirror disk, be sure that a quorum is not required for varyon: # chvg -Qn AIXTSM Add the mirrors for all AIXTSM logical volumes: # mklvcopy hd1 2 hdisk1 ; # mklvcopy hd2 2 hdisk1 ; # mklvcopy hd3 2 hdisk1 ; # mklvcopy hd4 2 hdisk1 ; # mklvcopy hd5 2 hdisk1 ; # mklvcopy hd6 2 hdisk1 ; # mklvcopy hd8 2 hdisk1 ; # mklvcopy hd9var 2 hdisk1 ; # mklvcopy hd10opt 2 hdisk1 OR # mirrorvg -s –c’x’ AIXTSM; smit or: mirrorvg –m datavg hdiskX hdiskY If you have other logical volumes in your rootvg, be sure to create copies for them as well. An alternative to running multiple mklvcopy commands is to use mirrorvg. This command was added in version 4.2 to simplify mirroring VGs. The mirrorvg command by default will disable quorum and mirror the existing LVs in the specified VG. To mirror AIXTSM, use the command: mirrorvg -s –c ‘x’ AIXTSM • Now synchronize the new copies you created: # syncvg -v AIXTSM

Listado de comandos SRDF. Step 1

Create SYMCLI Device Groups. Each group can have one or more Symmetrix devices specified in it.

SYMCLI device group information (name of the group, type, members, and any associations) are maintained in the SYMAPI database.

In the following we will create a device group that includes two SRDF volumes.

SRDF operations can be performed from the local host that has access to the source volumes or the remote host that has access to the target volumes. Therefore, both hosts should have device groups defined.

Complete the following steps on both the local and remote hosts.

a) Identify the SRDF source and target volumes available to your assigned hosts. Execute the following commands on both the local and remote hosts.

# symrdf list pd (execute on both local and remote hosts)

or

# syminq

b) To view all the RDF volumes configured in the Symmetrix use the following

# symrdf list dev

c) Display a synopsis of the symdg command and reference it in the following steps.

# symdg –h

d) List all device groups that are currently defined.

# symdg list

e) On the local host, create a device group of the type of RDF1. On the remote host, create a device group of the type RDF2.

# symdg –type RDF1 create newsrcdg (on local host)

# symdg –type RDF2 create newtgtdg (on remote host)

f) Verify that your device group was added to the SYMAPI database on both the local and remote hosts.

# symdg list

g) Add your two devices to your device group using the symld command. Again use (–h) for a synopsis of the command syntax.

On local host:

# symld –h

# symld –g newsrcdg add dev ###

or

# symld –g newsrcdg add pd Physicaldrive#

On remote host:

# symld –g newtgtdg add dev ###

or

# symld –g newtgtdg add pd Physicaldrive#

h) Using the syminq command, identify the gatekeeper devices. Determine if it is currently defined in the SYMAPI database, if not, define it, and associate it with your device group.

On local host:

# syminq

# symgate list (Check SYMAPI)

# symgate define pd Physicaldrive# (to define)

# symgate -g newsrcdg associate pd Physicaldrive# (to associate)

On remote host:

# syminq

# symgate list (Check SYMAPI)

# symgate define pd Physicaldrive# (to define)

# symgate -g newtgtdg associate pd Physicaldrive# (to associate)

i) Display your device groups. The output is verbose so pipe it to more.

On local host:

# symdg show newsrcdg |more

On remote host:

# symdg show newtgtdg | more

j) Display a synopsis of the symld command.

# symld -h

k) Rename DEV001 to NEWVOL1

On local host:

# symld –g newsrcdg rename DEV001 NEWVOL1 On remote host:

# symld –g newtgtdg rename DEV001 NEWVOL1

l) Display the device group on both the local and remote hosts.

On local host:

# symdg show newsrcdg |more

On remote host:

# symdg show newtgtdg | more

Step 2

Use the SYMCLI to display the status of the SRDF volumes in your device group.

a) If on the local host, check the status of your SRDF volumes using the following command:

# symrdf -g newsrcdg query

Step 3

Set the default device group. You can use the “Environmental Variables” option.

# set SYMCLI_DG=newsrcdg (on the local host)

# set SYMCLI_DG=newtgtdg (on the remote host)

a) Check the SYMCLI environment.

# symcli –def (on both the local and remote hosts)

b) Test to see if the SYMCLI_DG environment variable is working properly by performing a “query” without specifying the device group.

# symrdf query (on both the local and remote hosts)

Step 4

Changing Operational mode. The operational mode for a device or group of devices can be set dynamically with the symrdf set mode command.

a) On the local host, change the mode of operation for one of your SRDF volumes to enable semi-synchronous operations. Verify results and change back to synchronous mode.

# symrdf set mode semi NEWVOL1

# symrdf query

# symrdf set mode sync NEWVOL1

# symrdf query

b) Change mode of operation to enable adaptive copy-disk mode for all devices in the device group. Verify that the mode change occurred and then disable adaptive copy.

# symrdf set mode acp disk

# symrdf query

# symrdf set mode acp off

# symrdf query

Step 5

Check the communications link between the local and remote Symmetrix.

a) From the local host, verify that the remote Symmetrix is “alive”. If the host is attached to multiple Symmetrix, you may have to specify the Symmetrix Serial Number (SSN) through the –sid option.

# symrdf ping [ -sid xx ] (xx=last two digits of the remote SSN)

b) From the local host, display the status of the Remote Link Directors.

# symcfg –RA all list

c) From the local host, display the activity on the Remote Link Directors.

# symstat -RA all –i 10 –c 2

Step 6

Create a partition on each disk, format the partition and assign a filesystem to the partition. Add data on the R1 volumes defined in the newsrcdg device group.

Step 7

Suspend RDF Link and add data to filesystem. In this step we will suspend the SRDF link, add data to the filesystem and check for invalid tracks.

a) Check that the R1 and R2 volumes are fully synchronized.

# symrdf query

b) Suspend the link between the source and target volumes.

# symrdf suspend

c) Check link status.

# symrdf query

d) Add data to the filesystems.

e) Check for invalid tracks using the following command:

# symrdf query

f) Invalid tracks can also be displayed using the symdev show command. Execute the following command on one of the devices in your device group. Look at the Mirror set information.

On the local host:

# symdev show ###

g) From the local host, resume the link and monitor invalid tracks.

# symrdf resume

# symrdf query

Happy SRDF’ing!!!!!