Veritas Cluster Server Release Notes
Veritas⢠Cluster Server Release Notes: Linux - SORT - Symantec
Veritas⢠Cluster Server Release Notes: Linux - SORT - Symantec
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Veritas</strong> <strong>Cluster</strong> <strong>Server</strong> <strong>Release</strong> <strong>Notes</strong><br />
Software limitations<br />
82<br />
is in a leaving state and then removes the lock file. The agent’s monitor function<br />
declares that the resource is offline. After the node restarts, the disk group site still<br />
remains detached.<br />
Workaround:<br />
You must take the fire drill service group offline using the hagrp -offline command<br />
before you shut down the node or before you stop VCS locally.<br />
If the node has restarted, you must manually reattach the fire drill site to the disk<br />
group that is imported at the primary site.<br />
If the secondary node has crashed or restarted, you must manually reattach the<br />
fire drill site to the target disk group that is imported at the primary site using the<br />
following command: /opt/VRTSvcs/bin/hares -action $targetres joindg<br />
-actionargs $fdsitename $is_fenced -sys $targetsys.<br />
Limitations with DiskGroupSnap agent [1919329]<br />
The DiskGroupSnap agent has the following limitations:<br />
■<br />
■<br />
The DiskGroupSnap agent does not support layered volumes.<br />
If you use the Bronze configuration for the DiskGroupSnap resource, you could<br />
end up with inconsistent data at the secondary site in the following cases:<br />
■<br />
■<br />
After the fire drill service group is brought online, a disaster occurs at the<br />
primary site during the fire drill.<br />
After the fire drill service group is taken offline, a disaster occurs at the<br />
primary while the disks at the secondary are resynchronizing.<br />
Symantec recommends that you use the Gold configuration for the<br />
DiskGroupSnap resource.<br />
System reboot after panic<br />
If the VCS kernel module issues a system panic, a system reboot is required<br />
[293447]. The supported Linux kernels do not automatically halt (CPU) processing.<br />
Set the Linux “panic” kernel parameter to a value other than zero to forcibly reboot<br />
the system. Append the following two lines at the end of the /etc/sysctl.conf<br />
file:<br />
# force a reboot after 60 seconds<br />
kernel.panic = 60