17.08.2015 Views

Veritas Cluster Server Release Notes

Veritas™ Cluster Server Release Notes: Linux - SORT - Symantec

Veritas™ Cluster Server Release Notes: Linux - SORT - Symantec

SHOW MORE
SHOW LESS
  • 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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!