The Promise X30 and beyond have been out for some time. I find that as the older X10 units reach the next phase of their lifecycle, removing LUNs and RAIDs from the units is a necessity. While many are put back into production as near-line or backup storage (with new drives even) these RAIDs still need to be cleaned off. As such, an example of doing so might be creating one large LUN each of an E+J pair.
First, let’s delete our spare drives. To do so, click on Spare Drives in the sidebar.
Then click on the Delete tab.
Check all of the boxes and then click on the Submit button.
When prompted, type the word CONFIRM and press Enter.
Next, let’s delete our arrays. To get started, click on the Disk Arrays button in the explorer sidebar.
Click on the Delete tab.
Check the box for each array that you’d like to delete, noting that this step is irrecoverable and if you don’t mean to, you will end up loosing all of the data on these LUNs forever and ever and ever (unless of course you immediately call Promise and get them to help you restore them, by reconstructing the array – which of course can’t be guaranteed nor considered an option – but I’ve seen it happen as long as you don’t do anything else).
Click Submit. When prompted, type the word CONFIRM.
Click OK and viola, you can now upload a new script to config the unit. Enjoy.
The Promise Vtrak requires 3 IP addresses. There are two controllers and each has an IP for maintenance. There’s also a 3rd, virtual IP. When you initially setup the devices, they pull a DHCP or APIPA address and then you typically use Bonjour to log into the WebPAM for the first time. Once in, you configure the addresses and then viola, you’re good.
However, what if something happens? What if you configure the virtual IPs and something happens before you get the maintenance IPs configured. Or what if you never set the maintenance IPs in the first place and always relied on the virtual? Well, the Vtrak used to come with those configured to a default 10.0.0.2 and 10.0.0.3 IP address. You could simply give your laptop 10.0.0.4 and use one of those to tap in. Or put the device in maintenance mode, then tap in that way. However, the devices now ship with the maintenance IPs set to DCHP. For some reason, they don’t always grab an IP properly.
Therefore, you have to log in using a serial adapter, as I described yesterday. Once logged in, you can configure the virtual IP using the command line, using the net command, along with information about the settings to use, using 10.0.0.10 in this example:
administrator@cli> net -a mod -t mgmt -s "primaryip=10.0.0.10, primaryipmask=255.255.255.0, gateway=10.0.0.1"
To set the management ports, use -m and -c followed by the controller number you’ll be configuring (let’s say we’re gonna’ use 10.0.0.2 as used to be the default):
net -a mod -t mgmt -m -c 1 -s "primaryip=10.0.0.2, primaryipmask=255.255.255.0, gateway=10.0.0.1"
To then do the second controller, use -c 2 (let’s say we’re gonna’ use 10.0.0.3 as used to be the default):
net -a mod -t mgmt -m -c 1 -s "primaryip=10.0.0.3, primaryipmask=255.255.255.0, gateway=10.0.0.1"
Once set the IPs should be immediately accessible. View information that’s configured using the net command with no options:
Many of us use a Keyspan Serial adapter to manage devices with serial ports on them. Those who find you need to console into devices but hate the fact that you have to either use Zterm (which is no longer maintained) or boot a Windows Virtual Machine will find an application called goSerial pretty handy. GoSerial makes a Keyspan serial to usb adaptor, connected with a null modem cable, useful. You will be in CLI heaven in moments. goSerial can be downloaded here.
You can also use the screen command. The screen command will open a virtual terminal and provide the functionality of an old DEC VT100 terminal. Screen is one of the more useful tools when dealing with several servers concurrently, or several VT sessions as the case may be.
To open a screen session into an APC:
screen /dev/tty.KeySerial1 2400
To open a screen session into a Qlogic:
screen /dev/tty.KeySerial1 9600
To open a screen session into a Promise RAID:
screen /dev/tty.KeySerial1 115200
To see your active screens:
The output will show screens similar to the following:
When you list the screens you’ll note that some can be detached. You can also start a screen detached. To do so, use the -d flag when invoking the screen (or -D if you don’t want to fork the process. To attach to a detached screen, use the -r option:
screen -r 6077.ttys001.krypted2
Or if you only have one active screen that has been detached, -R will automatically reconnect to it. It can be useful to have more friendly names when working with multiple screen sessions. To attach to an attached screen session, use -x:
screen -x 6077.ttys001.krypted2
To provide an easy-to-remember name, use the -s option. To initiate a screen called simply Qlogic, using the above Qlogic rate:
screen -s Qlogic /dev/tty.KeySerial1 9600
By creating a .screenrc file in your home directory you can also set many of the options for screen.
While the screen command is useful in connecting to external devices via the command line, that’s only a small part of what screen can do. Those using the Terminal application that comes with Mac OS X have been using an environment that acts like screen for some time. You invoke tabs and new terminal windows in order to leave, for example, a session tailing logs or editing a configuration file open, while using a separate session to read a man page or start a process. Screen takes all of this and packs it into one terminal screen for environments without such an interactive command line management tool. For example, if you ssh into a Linux host in a data center, you would have to initiate 2 sessions into hosts in order to have 2 concurrently running screens, whereas you would only need to invoke one ssh session (and you may be limited to one) and still have the flexibility you have with the Terminal screen, albeit in a single window perhaps.
For example, let’s say you ssh into a RHEL box and you want to invoke an emacs editor:
screen emacs prog.c
Now let’s say that you type a few lines of a new samba config file and you want to tail the samba logs to make sure you’re augmenting the correct options:
screen tail -f /var/log/samba/log.smbd
To then switch back to emacs:
There’s lots more you can do with screen, but this should get ya’ started!
Updating the firmware on Promise arrays is straight forward enough from the WebPAM. But what happens if a firmware update goes funky and you can’t get into the WebPAM any longer (ah, the joys of beta testing)? Well, you can always download an older firmware and reload it provided you can ssh or telnet into the host. Download from http://www.promise.com/support/download.aspx?m=93®ion=en-global for your given model.
Then, you need the firmware accessible to the Promise chassis via tftp. A simple tftp GUI tool is available at http://ww2.unime.it/flr/tftpserver. Once configured, log into the Promise array and then use the ptiflash command to update the firmware. In the following command we’ll use the -s option to identify the IP address of our tftp server and then the -f option to identify the name of the file (note that I’ve shortened the ptif file for this X30 to be just fw.ptif so I don’t fat finger the multiple hyphens in a ridiculously long file name that I can’t autocomplete):
ptiflash -t -s 192.168.69.30 -f fw.ptif
If the server can’t access the file note that you have a tftp client binary that works much like the ftp binary built into OS X to test that you can access the server and the file from the IP address the X30 is using. If the file is accessible, when prompted to update the flash, enter y and press enter.
The update process is going to take about 15 to 20 minutes. If running the latest versions of the X30 firmware I recommend using Firefox.
The Promise Vtrak is the only officially supported platform that can be used to provide LUNs to an Xsan. Having said that, there are a number of other storage vendors that are supplying LUNs at this point. And while I don’t really want to speak to that it is worth noting that it brings me joy to watch the ever-expanding number of vendors testing their products for and then marketing to the Xsan community. One that I came across recently is Dot Hill, who did a video showcasing their speedy 2U product at NAB.
If you are installing a Vtrak from Apple on Microsoft Windows you can download the drivers from Promise here:
Having said this, you can use the Promise drivers or generic drivers if you’re using the Promise as targets and connecting to those LUNs via StorNext that are managed by Xsan. The reason for this is that StorNext will manage the LUNs. To see the LUNs, check Windows Device Manager.
Promise announced that they’ll now be offering 1TB drives in their Vtrak RAIDs. While it’s great to have the additional space, the darn things are just a tiny bit faster too. If bigger drives means faster, why? Doesn’t it seem like bigger drives, and thus more storage density, would make for slower speeds, not faster…
Well, storage density is a measure of the number of bits that can be stored on a track, area of surface, or in a given volume. Areal density is the amount of data that can be placed onto a piece of storage, generally measured in bits per square inch. Higher density is typically better as it gives you more data to store in a limited amount of physical space. With all things computer related, density typically has a direct relationship with capacity obviously, but also with performance and of course price.
Increasing storage density improves transfer speeds because the same amount of data takes up less space on the surface of larger disks, given the fact that the data is packed in there so much more tightly. Given the small amount of surface space that a drive head needs to access, there is less movement of the head, arguably one of the slower components of the drive and therefore higher density means more data per movement of the drive head. And of course, less movement of anything in a computer means less power is being used, which makes the power bills go down noticeably if you’ve got a whole lot of hard drives.
So if you can improve the performance for one drive slightly then the performance is compounded a little more over an entire RAID, where you are writing data to a number of drives to increase performance. In most SAN environments you have multiple RAIDs where you are round robining data. This makes a small performance increase for one drive compound greatly to hundreds of drives provided that the medium with which your hosts are communicating with the SAN can handle the speed.
To wrap all of this up, if you can upgrade your drives, it can’t hurt, but won’t just increase your available capacity by 30%, it will theoretically also increase your speed, although only benchmarking the new drive modules will tell a good compelling story about how much it will do so, or whether the fibre channel has already been saturated and it won’t show much of a difference.
Promise announced a new firmware, support for terabyte drive modules and a new sleeker chassis design at MacWorld. While the chassis design and the terabyte drive module support are self explanatory you might be asking what’s up with the ‘ole firmware upgrade.
To upgrade the firmware start off by going to the Promise website for the firmware updater, read the agreement and click on I Agree to download the AppleMultifw_v10.05.2270.01.zip file. Extract the file and grab the AppleMultifw_v10.05.2270.01.img file. Now make sure that any media being stored on the SAN has been backed up to a secure location.
Now for the easy part, log in to the web portal for the Promise RAID and click on Administrative Tools and then click on Firmware Update. On the resulting screen, click on the Choose File button and browse to the AppleMultifw_v10.05.2270.01.img file. Once selected, click on Choose and then Submit. Once the file has been uploaded, click on Next and then OK. When it’s done, click on Administrative Tools again and then click on Shutdown. Follow the prompts to go ahead and completely shut the thing down. Then log out and power the unit down.
Next, fire it back up and log back into the web portal when it’s finished booting. Click on each controller and check the firmware version. All-in-all this whole process took less than 5 minutes of downtime. However, it took about 20 minutes to get the file into the RAID and to get the firmware up-to-date. Once rebooted, the RAID showed up using Bonjour Browser immediately; however, the PIO HiPriWr didn’t show any changes.
Finally, all of the controllers need this firmware update. So if you have a spare parts kit, make sure to update all of your controllers. That’s it, have fun. Make sure you back up before you start this process, and if you’re not having any immediate issues, you might want to hold off for a little while and track whether anyone has any issues on the Xsanity Promise forum.
Using the Promise RAID it is possible to split up an Array into multiple LUNs, which would then be presented to the OS and able to be formatted at will. These do not have to correspond to a Physical segmentation as was the case with the Apple Xserve RAID but instead can be as small or as large as the actual disk array allows. Once split up you can run the LUNs through a fibre channel switch and mount them at will on various servers (although unless the file system supports clustering on only one at a time). If you are using HFS+ for the file system you will then want to enable LUN masking to keep multiple servers from trying to mount up the same volume. To enable LUN masking on the Promise RAID, from the web GUI click on Storage Services and then click on the LUN Map tab. Here, check the box for Enable LUN Masking. From this point forward you will need to enable a mask in able to be able to see a LUN from a given controller.