且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

full decommisson of JDC- windows meta disk

更新时间:2022-09-18 08:03:06

这一篇基本包含了所有步骤和详细命令:


首先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






    本文转自UVN2015  51CTO博客,原文链接:http://blog.51cto.com/10851095/1783583,如需转载请自行联系原作者