HP StorageWorks NAS 8000 - Version 1.6.X Release Note page 6

•
On an HA system, users may run into difficulty deleting a volume group if they delete the failover
package containing the volume group without first deleting any file volumes on that volume group.
A volume group cannot be deleted without first removing all file volumes that it contains.
However, once a package has been removed, any associated file volumes will not be
visible/deletable. This may lead to some confusion, since the volume group will appear to be
empty, but the user will get an error message stating that file volumes must be removed before
the volume group can be deleted. A workaround is to create a package that includes the volume
group in question and then delete any file volumes that will now become visible. Then the
package and the volume group may be deleted.
•
If the heartbeat path between the two cluster nodes is broken (cable removed, one of the nodes
shut down, etc.), the Command View NAS interface will become unresponsive.
•
When configuring a bond in an HA cluster, do not choose individual NICs that are participating in
a bond as heartbeat NICs. Instead, include the bond and/or other network cards. Choosing a
NIC that is participating in a bond will cause the cluster to be misconfigured and could cause
unintentional package failover.
•
There is a known issue regarding bonding. When a bond is created, the administrator can add
NICs in any order. However, this order is not preserved when the system boots. The NICs are
added to the bond in alphanumeric order. The practical implications to this are twofold:
•
Any browsers that support the Sun Microsystems Java Plug-in (version 1.3.1 or later) should be
able to run the Command View NAS interface. Tested configurations include:
•
Any browsers that support the Sun Microsystems Java Plug-in (version 1.3.1 or later) should be
able to run the Command View NAS interface. Tested configurations include:
1. You cannot specify the primary NIC.
- If you bond a 100-Mbit eth0/1 with a 1-Gbit eth2/3, the primary NIC will always be the
lower-numbered (slower) NIC upon booting. This is probably not the intended behavior,
but it cannot be controlled.
2. Creating a bond in the wrong order can cause the system to fail booting.
- If you create the bond as described above, it inherits the configuration data from the
higher-numbered NIC at creation time. However, upon boot it will try to bond the lower-
numbered NIC first, and that could contain bogus configuration parameters (e.g. zeros)
which will cause unpredictable behavior (potentially a kernel panic/crash).
- The correct procedure for creating a bond is to configure the lowest-numbered NIC (e.g.
eth0) that will be used in that bond, and enslave it FIRST; then enslave any additional
NICs as desired, in numeric order. This will match the behavior at creation time
•
There is a known issue when using bonded ethernet interfaces in a clustered environment. The
issue only comes up when using (setNetworkCardChannelBondEnabled T) channel
bonding and all the slave interfaces fail. Normally in an environment where a failover bond is
used, when all the slave interfaces fail, all packages that are using the bond failover to the other
node. However, when the environment uses a channel bond and all the slave interfaces fail, the
packages that are using the bond do not failover to the other node.
•
On an HA system, if CIFS is configured to use "shared mode" and a password is applied to a
share, the password will not be mirrored automatically on the other node in the cluster. To
ensure future access to the share when a failover occurs, set passwords ahead of time as
follows:
1. Start the failover package on the first cluster node.
2. Set the share password on that node.
3. Fail the package over to the second cluster node.
4. Set the share password on that node.
5. Fail the package back to the first cluster node.
HP StorageWorks NAS 8000
Version 1.6.3 Release Notes 6