| PRIMECLUSTER Global Disk Services Configuration and Administration Guide 4.1 (Solaris(TM) Operating System) |
|
Contents
|
| Appendix G Frequently Asked Questions (FAQ) |
Questions regarding system operation design are explained.
Is operation possible without using GUI (GDS Management View)?
Is it possible to perform GDS Snapshot operations through the GUI (GDS Management View)?
Can disks with different performance specifications, such as size and revolution speed, be mirrored?
Do I need to specify certain settings in order to perform a hot swap?
Are the mirrored disks differentiated as "primary" and "secondary" disks?
I want to know GDS resident daemons to monitor resident processes.
Yes. Two types of operation management interfaces are available: the GUI (Graphical User Interface) and the CLI (Command Line Interface).
Proxy object operations are possible. To operate shadow objects, use the CLI (Command Line Interface).
Yes. However, when mirroring disks of different sizes, you will only be able to use the capacity of the smaller disk. For example, if a 4 GB disk and a 9 GB disk are mirrored, only 4 GB out of the 9 GB disk will be accessible.
Also, when mirroring disks with different specifications such as revolution speed, the read performance becomes unbalanced and the write performance will depend on the slower disk's performance. Therefore, it is recommended to mirror disks with the same specifications.
See "Guidelines for Mirroring" also.
You can relate disks as master and proxy even if they have different attributes, such as size and revolution speed. However, it will result in that the read performance becomes unequal and the write performance depends on the slower disk's performance. Therefore, it is recommended to relate disks with the same attributes wherever possible.
For details see also "Exception to Proxy Configuration."
You can mirror stripe groups. However, you cannot stripe across multiple mirror groups, using them as stripe columns.
No. As long as the disk you are using supports hot swap, no special settings are required.
For procedures, see "Disk Swap" and "sdxswap - Swap disk."
GDS is a software which improves availability and manageability of the disk data. Single volume is used when users need to improve manageability, rather than availability. For details, see "Centralized Disk Management."
For example, if availability is already realized by using disk arrays, the user will benefit by using the physical disk as a single volume excluded from mirroring, to improve its manageability.
Using GDS to manage the volume as a single volume not only ensures consistent management, but also allows you to include the volume in the mirroring configuration without stopping the service application, when the need arises.
No. The messages are in English only.
There are no restrictions on LUN RAID level or size.
No. Disks mirrored with GDS are handled in the same way. Both the user and the application do not differentiate between the two.
However, the only exception is the system disk. The system disks may be differentiated as the primary and the secondary disks to initially be booted with OpenBoot. For details, see "System Disk Abnormality."
When a read is issued to a volume, the last access block number of each disk in the volume will be checked. The slice with the value closest to the read block number will be read. In other words, disk with the shortest seek distance will be read first.
When a write is issued to a volume, it will write to all slices in the volume (except from slice in ACTIVE status) and will return the write results after completing the write request on all slices.
Generally, using the spare disk of the disk array is recommended.
Generally, the following messages given in the "GDS Messages" should be monitored.
PANIC or WARNING level messages and Internal error messages shown in "Driver Messages"
HALT, ERROR, or WARNING level messages and Internal error messages shown in "Daemon Messages"
For details, see "GDS Messages."
The following table contains GDS resident daemons and the description.
|
Name |
ps -ef command's CMD |
Description |
|---|---|---|
|
sdxmond |
/usr/sbin/sdxmond |
Monitors GDS daemons |
|
sdxservd |
/usr/sbin/sdxservd |
Required daemon |
|
sdxlogd |
/usr/sbin/sdxlogd |
Required daemon |
|
sdxexd |
/usr/sbin/sdxexd |
Required daemon |
|
sdxclc |
/usr/sbin/sdxclc -W |
Cooperates with PRIMECLUSTER CF |
|
sdxcld |
/usr/sbin/sdxcld -W |
Cooperates with PRIMECLUSTER CF |
|
sdxcle |
/usr/sbin/sdxcle -f n |
Cooperates with PRIMECLUSTER CF |
If any resident daemon other than sdxmond terminates abnormally, sdxmond automatically restarts the daemon and outputs a message as follows to the GDS log file /var/opt/FJSVsdx/msglog/sdxservd.log.
When succeeded in restart
|
SDX:sdxmond: WARNING: respawned daemon daemon successfully |
When failed in restart
|
SDX:sdxmond: HALT: failed to respawn daemon daemon, osfunc=osfunc, errno=errno |
If sdxmond terminates abnormally, the OS init(1M) process automatically restarts the daemon. In that event, no message is output.
As described above, the GDS resident daemons are automatically restarted in the event of abnormal termination, and it is not necessary to monitor them.
In addition, GDS Snapshot has no resident daemon.
For the meanings of the messages and the resolutions, see "Daemon Messages."
Since GDS's message log file is managed so that it will not exceed a certain size, there are no effects that need to be considered.
|
Contents
|