Posts Tagged ‘storage devices’

IBM DS3400 expand Logical Drive (LUN)

Wednesday, May 6th, 2009

I have always liked IBM DS series management suite. I have claimed once that your first storage (and with it – your way of thinking about storage abstraction, I assume) is your favorite storage. I have been using the Storage Manager 9 for years now, even before it was 9 (I think that it was 7 then), and way before it has become 10-something version.

SM9 is the tool to manage the DS4xxx storage series (previously fastT series, if you can remember…), however, their “smaller” brothers, the DS3xxx series have arrived with something else claimed to be “Storage Manager” as well. It has began as SM2, and I was sure surprised to see it under the name “Storage Manager 10” today.

It seems as if someone wanted to make life easy, so everything is hidden behind some messy-looking dashboard. Finding the so-well-known abstraction logic is almost impossible for me, no matter how many times I will use this disaster of a product. Can’t complain about the storage devices – they are rather good, and although IBM has recently had some firmware issues and stability issues with some of its storage products – I can’t say I hate this device. Storage Manager 2 (or 10, today), however, is something I prefer to avoid.

After all this ranting and crying, I can share this piece of technical information. Storage Manager 10 (2, whatever) does not allow for Logical Drive to be expanded. You can expand the Raid Array – no problem. Just add some more disks to it, however, the free space created in that specific array will not be available for your reallocation pleasure – you cannot expand any of your existing Logical Drives with it.

Google has pointed me to that specific post which enlightened me with a new understanding of the DS series – the SM10, while being nothing more than a limited GUI for the storage-handicap IT persons, does not completely cancel the storage device’s abilities. The device can expand LUNs, so SM10 can allow it, secretly.

You need to know what you’re doing. I will copy/paste the contents of that blog entry for future use:

Expanding LUNs on a DS3000 series disk system:

First make sure you have enough space in your array. Next go to the script editor in the Storage Manager gui. Choose script editor. Type in a command like this:

set logicalDrive [“FINKOPAS01-BOOT”] addCapacity=50GB;

This would add 50GB’s to the disk “FINKOPAS01-BOOT”.

Now choose run command from the menu. After the disk system has expanded your LUN you should see the extra capacity in the disk management console window.

*NOTE*: This information was originally found here:

The target link is dead there, unfortunately, however, the “secret” information is available for all.

Do not forget the semi-comma at the end of the line. It won’t work otherwise. IBM… 🙂


Monday, July 14th, 2008

Linux works perfectly well with multiple storage links using dm-multipath. Not only that, but HP has released their own spawn of dm-multipath, which is optimized (or so claimed, but, anyhow, well configured) to work with EVA and MSA storage devices.

This is great, however, what do you do when mapping volume snapshots through dm-multipath? For each new snapshot, you enjoy a new WWID, which will remap to a new “mpath” name, or raw wwid (if “user_friendly_name” is not set). This can, and will set chaos to remote scripts. On each reboot, the new and shiny snapshot will aquire a new name, thus making scripting a hellish experience.

For the time being I have not tested ext3 labels. I suspect that using labels will fail, as the dm-multipath over layer device does not hide the under layered sd devices, and thus – the system might detect the same label more than once – once for each under layered device, and once for the dm-multipath over layer.

A solution which is both elegant and useful is to fixate the snapshots’ WWID through a small alteration to SSSU command. Append a string such as this to the snap create command:


Don’t use the numbers supplied here. “invent” your own 🙂

Mind you that you must use dashes, else the command will fail.

Doing so will allow you to always use the same WWID for the snapshots, and thus – save tons of hassle after system reboot when accessing snapshots through dm-multipath.

Fabric Mess, or how to do things right

Tuesday, May 29th, 2007

When a company is about to relocate to a new floor or a new building, that is the time when the little piles of dirt swept under the rug come back to hunt you.

In several companies I have been to, I have stressed the need of an ordered environment. This is valid to networking and hardware serial numbers as well as it is valid for FC hardware, but when it comes to FC, things always get somewhat more complicated, and when the fit hit the shan, the time you require for tracking down a single faulty cable, or a link led turned off is a time you need for other things.

I can sum it up to a single sentence – Keep you SAN tidy.

Unless you have planned your entire future SAN deployment ahead (and this can be planning ahead for years and years), your SAN environment will grow up. Unlike network, where short cable disconnections have only small influence on the overall status of a server (and this allows you to tidy up network cables on the fly after rush hours when traffic volume is low – without downtime), tidying up FC cables is a matter for a planned downtime, and let me see the high-level manager who would approve 30 minutes downtime (at least) with some risk (as there is always when changing cables) for "tidying up"…

So, your SAN looks like this, and this is the case, and this can be considered quite good:

Cables length is always an issue

You can track down cables, but it requires time, and time is an issue when there is a problem, or when changes are to take place. Wait – which server is connected to switch1 port 12? Donno?

The magic is, like most magic trick, non magical at all. Keep track of every cable, every path, every detail. You will not be sorry.

I have found out that the spreadsheet with the following columns would do the work for me, and I’ve been to some quire large SAN sites:

1. Switch name and port

2. Server Name (if server has multiple FC ports, add 0, 1, etc. Select a fixed convention for directions, for example – 0 is the leftmost, when you look directly at the back of the server). Same goes for storage devices.

3. SAN Zone of VSAN, if valid.

4. Patch panel port. If you go through several patch panels, write down all of them, one after the other.

5. Server’s port PWWN

On another spreadsheet I have the following information:

1. Server name

2. Storage ports accessible to it (using the same convention as mentioned above)

3. LUN ID on the storage described above.

If you keep these two spreadsheets up-to-date, you will be able to find your hands and legs anytime, anywhere in your own SAN. Maintaining the spreadsheet is the actual wizardry in all this.

Additional tip – If your company relocates to another building, and your SAN is pretty much fixed and known, hiring a person to manufacture by-the-length FC cables per device can be one of the greatest things you could do. If every cable has its own exact length, your SAN environment would look much better. This is a tip for the lucky ones. Most of us are not luck enough to either affort such a person, or to relocate with a never-changing SAN environment.

Fibre Cloud – Multi SAN Switch Configuration

Tuesday, April 18th, 2006

I’m not going to disclose now the method to do so, but I want to show off, so here’s a (real) screen-shot taken from my Cisco Fabric Manager. I have three MDS 9212, two Brocade SilkWorm 2800 and one Brocade SilkWorm 2400. All later three are old and slow, which is why I’ve used the Cisco MDS switches as my core switches. I’ve erased the names of the servers and the storage devices. Although it’s only my QA lab, I do not wish to disclose too many internal details. I believe this multi-path (well, mainly) environment will allow me dynamic configuration of storage ports and LUNs for the hosts, without the need to physically disconnect and reconnect fibre cables at an alternate location (such as another switch). This setup is both flexible, high-availabile, and well documented (in an Excell document I have in addition to this nice management software). That way I can track down devices per-port, per-switch, and/or per-PWWN.

Cisco Fabric Manager and my SAN. Click to enlarge