It’s been a few weeks since RAID Admin (hereon known as RA) and firmware 1.5 was released. Now seems like a good time to go through the options, both old and new, explain a bit about them, and then discuss the best way to update your firmware, along with *why* you might need to. This article does not address Xserve RAIDs in an Xsan environment.Pre-Existing Features
Repair LUN map
Assigns LUN ID’s to slices after replacing a controller module, and repair entries with a missing LUN ID or more than one LUN ID. RAID Admin will normally tell you when this needs to be done – the array in question will be shown in RA indicating this on it. This is a quick procedure, unlike…
Verify/Repair Parity Data
Either of these procedures will take somewhere in the region of 5-8 hours to complete. It will also impact performance of your RAID while it’s going on. Typically you might need to run this after a failed drive has been replaced.
If you want multiple hosts to be able to access the RAID, then you will need to provision LUNs to each of them. Without a cluster filesystem like Xsan, having mutiple hosts access the same LUN is a bad idea. They’ll all assume they’re the only ones that have access to it and stomp all over one another. LUN masking allows you to allocate the storage out…you may create 2 3-disk RAID 5 LUNs on each side of an XSR and use LUN masking to share that out to 4 hosts. This is done through the World Wide Port Name, a unique address assigned to every fibre channel port – much like the MAC address on an ethernet card.
Not a great choice for Xsan or any solution that requires any degree of redundancy, but if you want to have indivdual drives that you can easily swap between XSR’s this is a great choice. Some databse applications can make use of individual drives too. LUN masking and hardware slicing are disabled if this option is selected. Also, this setting is per controller – so you can’t have a 3 disk RAID 5 LUN and 4 JBOD’s.
Particularly useful for video capture, this option reduces the overall bandwidth of the XSR at the benefit of sustained, guaranteed throughput. In an Xsan environment, this should not be used as getting the maximum throughput is usually the most important thing. This could also be used in a Disk-to-Disk-to-Tape setup to stream backup data off to tape in a steady stream.
Background Scan and Repair
Repair or map out bad blocks on a RAID set. Using Background Scan, you can set a load sharing priority allowing the background scan to operate without causing a significant degradation in overall RAID set performance.
Enable Host cache Flush
Setting this option will allow the host machine to request the RAID flush its cache and write the contents to disk. In an Xsan environment, this should be disabled.
Enable Write Cache
In most cases, you will want this on – performance is signifcantly higher than when it’s off. HOWEVER – without a UPS attached you should have this off. If the XSR were to lose power unexpectedly with no UPS and write caching enabled, data loss is likely as the contents would be lost. With a UPS attached, the XSR has time to flush the cache to disk before shutting down. It can also detect when main power lost and the UPS is being used and disable the write cache in favour of writing straight to disk to minimise data loss.
This is a great feature. Now when you insert a disk that is already (or previously had been) part of a RAID set, the XSR marks it as such and will not auto-rebuild until you tell it to recognise the drive. This gives a great safety net against accidental removal or insertion of drives while the RAID is on.
Drive and Unit Info
Lots of new info is provided in RA. Drive Power On Hours and spare drive indicator are listed, as well as the unit’s serial number and a whole bunch of fibre channel info (LUN masking settings, and the World Wide Node and Port Names).
So, first off – only update your firmware when you have a real need to. This might be a particular problem you’re experiencing has been addressed, or you need to put 500GB drives into a 1st generation RAID.
Secondly, once you’ve decided that you’re going to be doing an update, do a backup. (That’s in addition to the backups you’re already doing – you are doing regular backups, right?)
You shouldn’t (or in some cases, can’t) do an update while the XSR is busy. This includes array initialization, parity verifies or repairs and background scans.
So, Apple has a procedure for doing updates, included in the download as READ ME FIRST.txt but I’ll go through it here.
First, unmount the XSR from the client(s). Wait a little while. Wait a little bit more, have a coffee, find something to read. We’re waiting for the cache to flush out and write to the drive. The update is meant to force this too, but a little patience never hurt anybody. For the ultra paranoid among you, you can even go as far as restarting the XSR so that it comes up clean with no hosts connected.
Next you can actually update the firmware using the menu in RAID Admin. Be prepared for a wait of around 5 minutes. The screen will keep you up to date with what’s going on. It will take a while, so don’t panic and don’t close RAID Admin. Once its done, your XSR will reboot and everything should be as it was before. Do check the settings, though to make sure things like host cache flushing and the write cache are set correctly.
Replacing RAID Controllers
If you ever need to replace a RAID controller, first update the firmware as it’s unlikely to be at the same version as the other one. Next you may need to synchronize the settings in the new controller module with the other module. This is done by holding down the System Identifier button and momentarily pressing the reset button on the back of the new Controller module. Settings synchronized are the System Name, Location, and Contact settings, Monitoring and Management Passwords, Email notification list and server, audible alert, power failure, and SNMP settings.