full decommisson of JDC- windows meta disk

cfsky

　　这一篇基本包含了所有步骤和详细命令：
　　首先JDC和GDC decom的不同如下：
　　1）datalist的目录不同，JDC在/etc/opt/omni/server/datalist,datalist 以jobcode命名
　　GDC在 /omni_shared/etc_opt_omni_server/datalist, datalist以host name 命令
　　2） JDC不删除IG PG SG, 只是重命名，fast policy 改为n/a。GDC则是都删除。
　　3）JDC在dummy code操作上与GDC不同：
　　在//prod/dss/run/bin 下的jobcode是control M调用的，例如调用了ZLF18A, 会进而使用
　　etc/opt/omni/server/datalist 下的ZLF18A, 这个路径下的jobcode里记载了备份哪个DG，用哪个driver，所以dummy job的操作如下:
　　在/prod/dss/run/bin下 cp ZlF18A  ZLF18A20161212
　　cp [dummy job] ZLF18A
　　在etc/opt/omni/server/datalist下 mv ZLF18A ZLF18A20161212
　　4) /opt/omni/lbin/SHELL/conf 下的ZHS04A.conf重命名，这个是配置文件，以jobcode命名，里面是该job备份的DG.
　　这个文件要看仔细，不一定非要dummy,因为有可能一个job备份多台不同的server.
　　GDC的操作方法如下：
　　在01 02的/omni_shared/etc_opt_omni_server/datalist
　　和/opt/omni/lbin/SHELL/conf/ 下删除server名字命名的job。
　　在 01 02/omni_shared/scripts/JP 下dummy jobcode
　　在07的/usr/local/admin/bc/JP 下面dummy sync/split job 内容。
　　再说一下windows server 与linux server的不同
　　1）存储上吧N个device做成1个meta device分给windows，所以如果symdg show [dg] 名字的话只能看到一个device, std和bcv都是一个，但是实际在存储上是三个，在virtual volume上unbind volume后还需要在meta volume上dissolve volume，就会分解回原来的n个，在virtual volume上能看到这n个，都是空的。
　　2）windows上有gate keeper磁盘，几兆一个，3，4个，std的gate keeper需要从ST的SG中unmap掉，但是bcv的gate keeper盘不能从BCV的SG中unmap，因为gate keeper只有在移除整个SG时才需要移除，STD的SG需要被移除，所以STD的GK也要被remove,但是BCV的SG是一个大pool，不能被移除，所以相应的BCV的GK也不需要被remove.
　　再说一下几个小地方：
　　1）symdg show [dg name]的输出结果能看到bcv是有pathdevname的，而std是没有的，那是因为现在登录的是backup server, bcv是与backup server相连的，所以是有路径，std没联就没有，如果要看std的pdev要去production server上去看。
　　2）关于unmap和unbind,
　　unmap就是把std和bcv从相应的SG中remove掉，
　　unbind是从volume中把volume的数据擦除，为了以后新的connection用。
　　顺序是把volume先从SG中remove，和任何server都无关了，然后在从volume中unbind 擦除数据。
　　3）每个volume 4条路径
　　一般一台production server两个wwn，storage上两个port, 所以每个volume与initiator有4条路径。
　　4) 怎么查找所有的jobcode
　　例如某台server有n个DG,这n个DG可能是有n个job在跑的，并不是一个，查表格有时不全，就会漏掉一些，这时如果知道server名字的话，可以这样做：
　　1，cd /opt/omni/lbin/SHELL/conf ，这里面是configuration file, 是以jobcode.conf命名的，里面有该job备份的DG信息。
　　2， find ./ -name "*.conf" | xargs grep IGM00101 ,输出的是所有和IGM00101相关的Jobcode.
　　一定要加xargs，因为find不支持管道，要加这个才能支持。
　　5）servera_serverb_SG,这种，servera和b是cluster,共用这个SG，但是他们的volume是单独分的，例如一个5个lun，一个10个，还有他们的GK不是共用的，自己有自己的，volume的数量中包含了GK盘的数量，所以容量不是简单的个数乘以13.5.
　　****************************************************************************************
　　full decommisson 的操作集中在三个平台，
　　1 backup server
　　2  VMAX GUI
　　3 FC switch
　　先说一下总体的思路：
　　log收集：
　　在两台backup server上收集如下信息：
　　1）symdg list |grep -i [server name ] 查看所有DG，datalist 里面也有dg信息但是那是备份的dg，分给server的DG全部信息，要看这个命令。这个目录下是dg。
　　2）收集device的路径信息：
　　命令: ioscan -m lun -C disk -I 5833  大写的i
　　大写的i，另外5833是/dev/rdisk/disk5833这个disk名字，不是04BE那种device名字。
　　3）NO_HW_bfore和NO_HW_after
　　命令：ioscan -fnkC disk |grep -i NO_HW > /var/temp/emc/sympd
　　对比删除后的NO_HW路径；
　　(不加k，k是扫描kernel，也就是启动的盘，扫描不到新盘)
　　4）SG IG PG信息，在GUI操作时对比
　　命令： symaccess -sid 065 show gni00101_IG -type initiator
　　注意：这个show出的WWN号是production server的，所以两台backup server上show 出的结果都是一样的，两个WWN
　　symaccess -sid 065 show gni00101_SG -type storage
　　symaccess -sid 065 show gni00101_PG -type port
　　5) copy是否成功的信息
　　命令：symclone -g [dg name] que
　　5)JDC的话如果在表中找不到jobcode的话，用这个命令：
　　命令：find  /etc/opt/omni/sever/datalists -exec grep -i -l <hostname > {}\; (前面是小写的L)
　　6）如果在表中找不到server名字的话，可以先到os组要WWN号，再用下面的命令：
　　命令：symaccess -sid 65  list view -detail |grep -i [wwn], 要用65 ,66 86这三个vmax20K分别试，有输出的那个就是此server所在的strorage,然后：
　　symaccess -sid 65 list -type initiator -wwn 找到IG名字，推断SG名字，然后：
　　symsg -sid 65 show JPYK02_SG, 这个名字显示所有GK和STD，BCV device信息，然后：
　　symdev -sid 65 show 074E, 找到DG信息。
　　查看某个device属于哪个dg，用symdev -sid 043 show 0780
　　7）收集BCV的SG信息
　　命令：首先用 symsg -sid 65 list |grep -i bkj0d101/gepbkp101, bcv的大poll都是以backupserver命令的，输出会有几个大pool,*是BK01 BK02 BK03 BK04，显示不全，然后：
　　symsg -sid 065 show bkj0s101_bkj0d201_BK*|grep -i 084A ,看哪个输出就是哪个SG, 这个是为了在bcv的SG中remove bcv volume用的，要找到是哪个SG. (注意，084A是BCV device)
　　****************************************************************************************
　　backup server操作
　　1）首先需要在bankup server上中止std 与 bcv的clone关系；
　　symdg list |grep "server name"   如果dg name显示不完整，用下面两条来查;
　　cd/var.adm/dev
　　ll |grep -i server name
　　这里面是bcv volume的symolic 链接，指向DG名字
　　2）在vmx GUI上删除masking view;
　　3)  在vmx GUI上删除MV下的IG, PG;
　　JDC是rename IG PG
　　4）在vmx GUI上删除fast policy, 如果分配了；
　　JDC 是在SG上点detail,然后->的第五行，disassociate, remove the selected SG from fast policy.
　　然后在SG上点detail,然后rename SG，点apply,然后把fast policy 改为N/A，再apply。
　　fast policy是一个algorithm，能够monitor与server之间的I/O, lun来自于pool，pool是由不同的disk构成的，sata is less, fc 中等。fast policy能够分配哪块disk被用。
　　5）在vmx GUI上removeSG下的volume; (点remove,unmap, 不要勾选unbind，会出bug,切断vlume 与 FA port的关联，但是数据还在,利用率不变，volume仍然与pool bound着。)
　　volume从SG中被remove之后(unmap)，其实还是和pool bound着的，而且里面的数据可还都存在,使用率没有变化，可以用下面的命令来查：
　　symdev -sid 0055 show 0B4A
　　上面的命令可以查看0B4A的信息，与哪块盘bound着，还可以看到meta volume下面的成员。
　　6）在vmx GUI上remove SG;
　　7）在vmx GUI上unbind volume from pool; (volume的数据会被擦除，利用率会降到0%)
　　在volume的virtual disk上选择volume，然后选择unbind。
　　unmap之后数据还在，unbind后是使用率就清零了，数据都被擦除。
　　注意：这一步有时会报错，说volume在map着，即使前面已经unmap成功了，所以这时只能手动先unmap掉，再执行unbind，方法是在->选择unmap, 点next执行。
　　注意2：如果没有terminate掉备份关系，这里也会报错，会报这个volume是copy target.、
　　只有unbind之后volume才会变成not ready的状态。
　　8）dissolve meta disk
　　这个是windows的meta盘才有的，unbind之后要把meta盘融化，在volume的meta disk上选择volume，然后dissolve，之后的member会回到virtual disk中，
　　注意：并不是所有分给windows的device都是meta，只有大于一个lun大小的才是，13.5G的都不是。
　　9）在vmx GUI上把volume重新bind回原来的pool。
　　以上是std盘，对于bcv盘，除了一步以外，所有步骤都是一样的：
　　bcv盘的SG是一个大的SG，不要删除, fast policy 也不需要disassociate,上面有解释。
　　查看BCV盘所属的pool，用以下命令：
　　symsg -sid 0055 list |grep -i GEPBKP*
　　symsg -sid 0055 show [dg name ] |grep -i 0B4A
　　BCV devices 属于backup storage, backup storage一共三个，第二个命令是确定究竟哪一个。
　　9）在backupserver上删除STD/BCV device, STD dg；
　　symclone -g [dg name] remove DEV001
　　注意这里的DEV001是由symdg show []得到的，根据“LDEVName”得出。
　　symbcv -g [dg name] remove ld BCV001
　　symdg delete [dg name] -force
　　10）完成上一步之后，重新ioscan的话会与新的NO-HW的path出现，删除这些path；
　　ioscan -fnNkC disk |grep -i NO_HW
　　rmsf -H []
　　如果没出现：insf -e 重建刷新，then symcfg disc
　　11）在backupserver上 insf -e重建device表；
　　insf -e
　　12）删除/var/adm/dev/下的server 文件夹，删除设备软链接；
　　13）在backupserver01 02上面删除datalist和conf下的备份脚本；
　　JDC是在etc/opt/omni/server/datalist下面MV掉jobcode名字。
　　14）在backupserver07上dummy JP文件夹下的sync/splitjob code的dg内容；
　　15）在backupserver01上dummy 备份的job code；
　　************************以下为zone delete******************************
　　16）先rename zone,对照WWWN别删错了，日本的zone设置也是alias(storage WWPN, initiator WWN)
　　17) remove zone member;
　　18)  save config
　　19) activate config 不再进行down port了。
　　某台server在删除前的配置应有3处：1) zoneset 2) zone 3) effevtice zone
　　删除后只有一处：zone