Disk shows up as deported on both nodes, even thought the existing diskgroup is still imported. Causes erratic import behavior for that diskgroup
Article ID: 100020937
Updated On:
Resolution
In a clustered environment, vxdiskadm will allow you to initialize a disk and add it to an existing diskgroup that is imported to another node. This will result in a concurrency violation, and will immediately deport the disk.
The disk will show as deported on both nodes.
As you can see, we have a disk group resource, which is called testsg. This resource brings a diskgroup named tdg online.
We will initialize a disk and add it to the same diskgroup on the node where the service group isn't running.
Now on the other node, we see the tdg diskgroup as deported:
We will now use vxdiskadm to initialize sdg and observe the concurrency violation. After adding the disk to the tdg disk group we see that the disk is immediately deported:
On the other node:
The violation from the enigine_A.log:
Now the disk is in a sort of limbo state, not useable by anything at this point. Rather than deporting, or switching the service group, we will clear the private region.
Leaving this disk, and attempting to do a switch, or a deport/import on the other node, will result in only that newly added(and empty) disk being imported, or other unpredicatble import behaviors.
Here is what happens when I do the switch.
The vxdisk list from remus (notice that the new disk is the one that is imported):
We will run a vxdisk -f init instead, to zero out the private region:
You can now initialize the disk and add it to a (imported, or new) diskgroup.
The disk will show as deported on both nodes.
As you can see, we have a disk group resource, which is called testsg. This resource brings a diskgroup named tdg online.
We will initialize a disk and add it to the same diskgroup on the node where the service group isn't running.
[root@romulus ~]# vxdisk -o alldgs list DEVICE TYPE DISK GROUP STATUS sda auto:none - - online invalid sdb auto:none - - online invalid sdc auto:cdsdisk - (sharedg) online shared sdd auto:cdsdisk sdd tdg online sde auto:cdsdisk - (datadg) online sdf auto:cdsdisk - (datadg) online sdg auto:cdsdisk - - online [root@romulus ~]# hastatus -sum -- SYSTEM STATE -- System State Frozen A remus RUNNING 0 A romulus RUNNING 0 -- GROUP STATE -- Group System Probed AutoDisabled State B testsg remus Y N OFFLINE B testsg romulus Y N ONLINE Now on the other node, we see the tdg diskgroup as deported:
[root@remus ~]# vxdisk -o alldgs list DEVICE TYPE DISK GROUP STATUS sda auto:none - - online invalid sdb auto:none - - online invalid sdc auto:cdsdisk - (sharedg) online shared sdd auto:cdsdisk - (tdg) online sde auto:cdsdisk - (datadg) online sdf auto:cdsdisk - (datadg) online sdg auto:cdsdisk - - online We will now use vxdiskadm to initialize sdg and observe the concurrency violation. After adding the disk to the tdg disk group we see that the disk is immediately deported:
[root@remus ~]# vxdisk -o alldgs list DEVICE TYPE DISK GROUP STATUS sda auto:none - - online invalid sdb auto:none - - online invalid sdc auto:cdsdisk - (sharedg) online shared sdd auto:cdsdisk - (tdg) online sde auto:cdsdisk - (datadg) online sdf auto:cdsdisk - (datadg) online sdg auto:cdsdisk - (tdg) online <--------disk we just init-ed sdh auto:cdsdisk - (acsdg) online sdi auto:sliced - (acsdg) online On the other node:
[root@romulus ~]# vxdisk -o alldgs list DEVICE TYPE DISK GROUP STATUS sda auto:none - - online invalid sdb auto:none - - online invalid sdc auto:cdsdisk - (sharedg) online shared sdd auto:cdsdisk sdd tdg online sde auto:cdsdisk - (datadg) online sdf auto:cdsdisk - (datadg) online sdg auto:cdsdisk - (tdg) online <---Also deported here sdh auto:cdsdisk acsdg02 acsdg online sdi auto:sliced acsdg01 acsdg online The violation from the enigine_A.log:
2009/05/07 11:06:42 VCS INFO V-16-1-10299 Resource dgres (Owner: unknown, Group: testsg) is online on remus (Not initiated by VCS) 2009/05/07 11:06:42 VCS ERROR V-16-1-10214 Concurrency Violation:CurrentCount increased above 1 for failover group testsg 2009/05/07 11:06:42 VCS NOTICE V-16-1-10233 Clearing Restart attribute for group testsg on all nodes 2009/05/07 11:06:42 VCS NOTICE V-16-1-10447 Group testsg is online on system remus 2009/05/07 11:06:42 VCS WARNING V-16-6-15034 (remus) violation:Offlining group testsg on system remus 2009/05/07 11:06:42 VCS NOTICE V-16-1-10167 Initiating manual offline of group testsg on system remus 2009/05/07 11:06:42 VCS NOTICE V-16-1-10300 Initiating Offline of Resource dgres (Owner: unknown, Group: testsg) on System remus 2009/05/07 11:06:42 VCS INFO V-16-6-15002 (remus) hatrigger:hatrigger executed /opt/VRTSvcs/bin/triggers/violation remus testsg successfully 2009/05/07 11:06:46 VCS INFO V-16-1-10305 Resource dgres (Owner: unknown, Group: testsg) is offline on remus (VCS initiated) 2009/05/07 11:06:46 VCS NOTICE V-16-1-10446 Group testsg is offline on system remus Now the disk is in a sort of limbo state, not useable by anything at this point. Rather than deporting, or switching the service group, we will clear the private region.
Leaving this disk, and attempting to do a switch, or a deport/import on the other node, will result in only that newly added(and empty) disk being imported, or other unpredicatble import behaviors.
Here is what happens when I do the switch.
[root@romulus ~]# hagrp -switch testsg -to remus The vxdisk list from remus (notice that the new disk is the one that is imported):
[root@remus ~]# vxdisk -o alldgs list DEVICE TYPE DISK GROUP STATUS sda auto:none - - online invalid sdb auto:none - - online invalid sdc auto:cdsdisk - (sharedg) online shared sdd auto:cdsdisk - (tdg) online sde auto:cdsdisk - (datadg) online sdf auto:cdsdisk - (datadg) online sdg auto:cdsdisk tdg01 tdg online sdh auto:cdsdisk - (acsdg) online sdi auto:sliced - (acsdg) online We will run a vxdisk -f init instead, to zero out the private region:
[root@romulus ~]# vxdisk -f init sdg [root@romulus ~]# vxdisk -o alldgs list DEVICE TYPE DISK GROUP STATUS sda auto:none - - online invalid sdb auto:none - - online invalid sdc auto:cdsdisk - (sharedg) online shared sdd auto:cdsdisk - (tdg) online sde auto:cdsdisk - (datadg) online sdf auto:cdsdisk - (datadg) online sdg auto:cdsdisk - - online <---disk is free now sdh auto:cdsdisk acsdg02 acsdg online sdi auto:sliced acsdg01 acsdg online You can now initialize the disk and add it to a (imported, or new) diskgroup.
Issue/Introduction
Adding disks to a diskgroup imported on another node results in the disk being immediately deported (Concurrency Violation). Disk shows up as deported on both nodes, even thought the existing diskgroup is still imported. Causes erratic import behavior for that diskgroup.
Was this article helpful?
Yes
No
Powered by
