Unix tip: Monitor disk arrays with sccli commands
Clearly one of the best features of disk arrays is that they can continue working even when a disk has failed. One of the problems, however, is that you might not notice when a disk fails, and thus, fail to replace it in a timely manner. Let's take a look at what you can do to facilitate monitoring your storage (StorEdge) arrays so that a bad disk doesn't escape your notice.
First, there are two ways to determine that a disk in a StorEdge array has failed. You might notice that an amber LED on the front of the particular drive has lit up or you can use the sccli commands to view the disks contained in your array and their status.
To start sccli, log into the server to which the array is attached and type "sccli". You should connect to the device and find yourself sitting at the sccli> prompt. To view the state of the disks on your array, type "show disks". In the display below, one of the disks is reported to be "BAD". The particular system was still running and still had one disk in "STAND-BY" mode, so the failure was not an emergency. Still, it's a good idea to ensure that all disks in the array are working properly to steer clear of failures from which your array would not be able to recover without intervention.
|
In this array, we can see that all the disks are 72 GB Fujitsu drives. Drives in the same chassis can be different sizes, but should all be running at the same speed.
Depending on the nature of a disk failure, your disk array could be working at reduced speed in order to compensate for the missing data.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
jfruh
Apple syncing patent can't come soon enough
pasmith
New Twitter features borrow from 3rd party clients
Esther Schindler
Open Source Changes the Software Acquisition Process
mikelgan
How to set up continuous podcast play on the new iTunes
David Strom
Five important Windows 7 mobility features
sjvn
Guard your Wi-Fi for your own sake
Sandra Henry-Stocker
Grepping on Whole Words
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.
Bug?
It would seem that you have a bug in your script:sccli < /tmp/$$
show disks
show ld
exit
EOF
I suppose that "/tmp/$$" should contain
show disks
show ld
exit
Otherwise, the script will fail because "/tmp/$$" doesn't exist beforehand.
May I also suggest to refrain from using bash? bash is full of bugs and usually not found on traditional UNIX systems, making it a poor choice for scripts (programs) which are meant to be, or should be portable across systems. /bin/ksh is likely to be a good choice between usability and portability.
Also, may I suggest you trap SIGINT, so that if your script is ever ^Ced during execution/debugging, the self-defined Cleanup() function will clean up "/tmp/$$" automatically.
EXAMPLE
#!/sbin/sh
Rm="/bin/rm"
Self="`basename $0`"
TmpDir="/tmp"
TmpFile0="$TmpDir/${Self}.$$"
trap Cleanup 2
Cleanup()
{
$Rm -f "$TmpFile0"
}