5.5 HP StorageWorks X9300 Network Storage Gateway Administrator Guide (AW539-96007, March 2011)
Table Of Contents
- X9300 Network Storage Gateway Administrator Guide
- Contents
- 1 Product description
- 2 Getting started
- 3 Configuring virtual interfaces for client access
- 4 Configuring failover
- 5 Configuring cluster event notification
- 6 Configuring system backups
- 7 Creating hostgroups for X9000 clients
- 8 Monitoring cluster operations
- 9 Maintaining the system
- Shutting down the system
- Starting the system
- Powering file serving nodes on or off
- Starting and stopping processes
- Tuning file serving nodes and X9000 clients
- Migrating segments
- Removing storage from the cluster
- Maintaining networks
- Viewing network interface information
- 10 Migrating to an agile managment console configuration
- 11 Upgrading the X9000 Software
- 12 Licensing
- 13 Upgrading firmware
- 14 Troubleshooting
- 15 Replacing components
- 16 Recovering a file serving node
- 17 Support and other resources
- A Component and cabling diagrams
- B Spare parts list
- C Warnings and precautions
- D Regulatory compliance and safety
- Glossary
- Index
Troubleshooting specific issues
Software services
Cannot start services on the management console, a file serving node, or a Linux X9000 client
SELinux might be enabled. To determine the current state of SELinux, use the getenforce command.
If it returns enforcing, disable SELinux using either of these commands:
setenforce Permissive
setenforce 0
To permanently disable SELinux, edit its configuration file (/etc/selinux/config) and set
SELINUX=parameter to either permissive or disabled. SELinux will be stopped at the next
boot.
For X9000 clients, the client might not be registered with the management console. For information
on registering clients, see the HP StorageWorks X9000 File Serving Software Installation Guide.
Failover
Cannot fail back from failover caused by storage subsystem failure
When a storage subsystem fails and automated failover is turned on, the management console will
initiate its failover protocol. It updates the configuration database to record that segment ownership
has transferred from primary servers to their standbys and then attempts to migrate the segments to
the standbys. However, segments cannot migrate because neither the primary servers nor the standbys
can access the storage subsystem and the failover is stopped.
Perform the following manual recovery procedure:
1. Restore the failed storage subsystem (for example, replace failed Fibre Channel switches or
replace a LUN that was removed from the storage array).
2. Reboot the standby servers, which will allow the failover to complete.
Cannot fail back because of a storage subsystem failure
This issue is similar to the previous issue. If a storage subsystem fails after you have initiated a failback,
the configuration database will record that the failback occurred, even though segments never migrated
back to the primary server. If you execute ibrix_fs -i -f FSNAME, the output will list No in the
ONBACKUP field, indicating that the primary server now owns the segments, even though it does
not. In this situation, you will be unable to complete the failback after you fix the storage subsystem
problem.
Perform the following manual recovery procedure:
1. Restore the failed storage subsystem.
2. Reboot the primary server, which will allow the arrested failback to complete.
X9000 client I/O errors following segment migration
Following successful segment migration to a different file serving node, the management console sends
all X9000 clients an updated map reflecting the changes, which enables the clients to continue I/O
Troubleshooting98