Full decommisson of jdc-windows meta disk

This article basically contains all the steps and detailed commands:

First JDC and GDC decom are different as follows:

1) DataList directory is different, JDC in/etc/opt/omni/server/datalist,datalist with Jobcode name

GDC in/omni_shared/etc_opt_omni_server/datalist, DataList with host name command

2) JDC does not remove the IG PG SG, just rename it and change the fast policy to N/A. GDC is all deleted.

Again, the difference between Windows Server and Linux server

1) store n device to make 1 meta device to Windows, so if SYMDG Show [DG] name can only see a device, STD and BCV are one, but the actual storage is three, in virtual Volume on unbind volume after also need in Meta volume dissolve volume, will be decomposed back to the original N, in virtual volume can see that n, are empty.

2) There are gate keeper disks on Windows, several megabytes, 3, 4, and STD gate keeper need to be unmap from St's SG, but the BCV's Gate keeper disk cannot be unmap from the BCV's SG, because gate Keeper only need to remove the entire SG, the STD SG needs to be removed, so STD's GK is also removed, but the BCV SG is a large pool and cannot be removed, so the corresponding BCV's GK does not need to be remove.

Say a few small places:

1) SYMDG Show [DG name] output can see the BCV is Pathdevname, and STD is not, that is because the backup server is now logged in, the BCV is connected to backup server, so there is a path, STD does not have, if you want to see the STD Pdev to production server to see.

2) about Unmap and unbind,

Unmap is to remove the STD and BCV from the corresponding SG,

Unbind is to erase volume data from volume, for the new connection.

The order is to remove the volume from the SG first, regardless of any server, and then erase the data from the volume unbind.

****************************************************************************************

The full Decommisson operation is concentrated on three platforms,

1 Backup Server

2 VMAX GUI

3 FC Switch

Let's talk about the general idea:

Log collection:

Collect the following information on both backup servers:

1) Collect the device path information:

Command: ioscan-m lun-c disk-i 5833

The uppercase I, the other 5833 is the disk name/dev/rdisk/disk5833, not the 04BE type device name.

2) No_hw_bfore and No_hw_after

Command: IOSCAN-FNNKC disk |grep-i no_hw >/VAR/TEMP/EMC/SYMPD

Compare the NO_HW path after deletion;

3) SG IG PG information, compared during GUI operation

Command: Symaccess-sid 065 show Gni00101_ig-type Initiator

Symaccess-sid 065 Show Gni00101_sg-type Storage

Symaccess-sid 065 Show Gni00101_pg-type Port

4) The information of whether copy is successful

Command: SYMCLONE-G [DG name] que

5) JDC If Jobcode is not found in the table, use this command:

command: Find/etc/opt/omni/sever/datalists-exec grep-i-L (front is lowercase l)

6) If the server name is not found in the table, you can first go to the OS group to the WWN number, and then use the following command:

Command: Symaccess-sid list view-detail |grep-i [WWN], to use 65, 66 86 three vmax20k respectively, the output is the strorage of this server, and then:

Symaccess-sid list-type initiator-wwn Find the IG name, infer the SG name, and then:

Symsg-sid Jpyk02_sg, the name shows all GK and STD,BCV device information, and then:

Symdev-sid 074E, find DG Information.

7) Collect the BCV's SG information

Command: First with Symsg-sid list |grep-i bkj0d101/gepbkp101, the large poll of the BCV is backupserver command, the output will have a few large pool,* is BK01 BK02 BK03 BK04, display not all And then:

Symsg-sid 065 Show Bkj0s101_bkj0d201_bk*|grep-i 084A, see which output is which SG, this is for the BCV in the SG Remove BCV volume used, to find out which SG.

****************************************************************************************

Backup Server Operations

1) The clone relationship between STD and BCV must be aborted on Bankup server first;

SYMDG list |grep "server name" if the DG name display is incomplete, use the following two to check;

/home/work/./cs |grep "server name"

Omnidb-sess [Session ID]-report

SYMDG Show [DG Name] (Note that DG name is not device name, remove the _* behind device name)

SYMCLONE-G [DG name] Terminate que (check if it is copied)

SYMCLONE-G [DG Name] Terminate (if p and s are copied)

2) Delete masking view on the VMX GUI;

3) Remove the IG, PG from the MV under the VMX GUI;

4) Delete The fast policy on the VMX GUI, if assigned;

JDC is on the SG point detail, then rename SG, click Apply, and then change the fast policy to N/A, and then apply.

fast policy is a algorithm, capable of I/O between monitor and server, and LUNs from Pool,pool are made up of different disk, SATA is less, FC medium. Fast policy can allocate which disk is used.

5) volume under REMOVESG on the VMX GUI; (Point Remove,unmap, cut off Vlume and FA Port Association, but the data is still, utilization is constant, volume still with pool bound. )

volume from the SG is removed (unmap), in fact, and the pool bound, and the data inside can still exist, the usage rate has not changed, you can use the following command to check:

Symdev-sid 0055 Show 0b4a

The above command can view 0b4a information, and which disk bound.

6) Remove SG on the VMX GUI;

7) Unbind volume from pool on the VMX GUI; (volume data will be erased and utilization will be reduced to 0%)

Select volume on the volume virtual disk and select Unbind.

after unmap the data is still in, after Unbind is the usage rate is clear, the data all is erased.

8) Dissolve meta disk

This is the meta disk of Windows, unbind after the meta disk to melt, on the volume meta disk Select volume, and then dissolve, then the member will return to Virtual disk,

9) Re-bind the volume back to the original pool on the VMX GUI.

The above is the STD disk, for the BCV disk, except one step, all steps are the same:

The BCV disk SG is a large SG, do not delete.

To view the pool to which the BCV disk belongs, use the following command:

symsg-sid 0055 |grep-i gepbkp*

Symsg-sid 0055 Show [DG name] |grep-i 0b4a

BCV devices belongs to backup storage, backup storage altogether three, and the second command is to determine exactly which one.

9) Remove STD/BCV device, STD DG on Backupserver;

symclone-g [DG name] Remove DEV001

Note that the DEV001 here is obtained by SYMDG Show [], according to "Ldevname".

SYMBCV-G [DG name] Remove LD BCV001

Symdg-delete [DG Name]-force

10) After completing the previous step, the re-ioscan will appear with the new NO-HW path, deleting these paths;

IOSCAN-FNNKC disk |grep-i no_hw

Rmsf-h []

11) INSF-E Rebuilding the device table on Backupserver;

insf-e

12) Delete the server folder under/var/adm/dev/, delete the device soft link;

13) Delete the backup scripts under DataList and Conf on Backupserver01 02;

14) The DG content of sync/splitjob code under dummy JP folder on Backupserver07;

15) Dummy The backup job code on the Backupserver01;

16) Delete the Zoneset,zone,alias that the server belongs to on the fabric manager;

first select the core or edge SW on the FM

Zoneset's alias contains two members, one HBA for the server and one for the storage FA.

() active change;

18) on edge Switch's Device Manager, drop the server port and replace the zone where port belongs to Vsan1;

switch, Edge switch, core switch, storage

Storage FA port is also used by other servers and cannot be deleted.

) Save Configure

) Finish.

Full decommisson of jdc-windows meta disk