How to setup an msa1000 using the serial console
For RHEL and SLES, HP supplies a utility for configuring and setting up the msa1500/msa1000, delivered as an RPM. While it may be possible to convert this RPM using alien and run it (it seemed to run, I didn't risk trying to use it) the software installs a big managability daemon/stack that isn't really necessary for just setting things up. They also provide Debian packages, but upon examination they are just alien'd rpms with some by hand breakage. Fortunately there is a serial command-line interface that can be used from any OS. I read the "msa1500/msa1000 Command Line Interface User Guide" and figured out how to do the stuff I needed, maybe this will be of some use to others. Here is what I did:
- Use the special "RJ45Z" serial cable you got with the msa1000/1500 to connect it to a Linux box
- apt-get install minicom
- Connect to the serial console with minicom: 19200 8n1 and turn off both hardware and software flow control, this is the key.
- Confirm that the CLI prompt is responding to input and you can run help, etc.
Once you are connected there are a few useful command you can use to gather info
help - get the list of command verbs and nouns and specific info about commands
show version - show firmware info. Here are my instructions for how to update the msa1000/1500 firmware using the serial console, so you can do it on OSes they don't provide tools for (like Debian, the BSDs, etc).
show this_controller and
show other_controller - show info about the controllers including firmware versions and wwpn's
show disks - show mechs including the the box/bus thery are on, size, speed, and what LUNs they are assigned to
show units - show LUNs and all their config info
show connections - show all the other hosts that the msa can see, and their names if you've assigned them
OK you have a bunch of disks, probably across multiple SCSI busses, and multiple fiber channel connections. You have to figure out:
In a lot of cases you can only guess at answers to the above and just try it and see how well each works.
- What RAID level you want for each LUN: 0, 1, 0+1, 5, ADG
- Different RAID levels will require different multiples of disks: 0 and 1 need 2+, 0+1 needs an even number greater than four, 5 needs 3+, ADG needs 4+
- How much redundancy do you need: zero, one, two, more failures per LUN?
- Space, redundancy, performance: pick two
- How much space are you willing to trade off for better performance: 0, 1, and 0+1 give you less space than 5 and ADG
- How much redundancy are you willing to trade off for better performance: 0, 1, and 0+1 are faster than 5 and ADG
- How much space are you willing to trade off for redundancy: 1, 0+1 can give you better redundancy than 5 and even ADG (depending on setup)
- Your total amount of disks and answers to the other questions might influence your answers
- How many mechs you want to be in each LUN: the more that can serve requests for that LUN the better the I/O
- How many LUNs will be using the same mechs: the more you have the more contention can mess things up. This is at odds with the above, so it's a balancing act.
- How many SCSI busses each LUN is spread across: the more you can serve requests for that LUN, the better the I/O. The msa1000 chassis has two scsi busses with 7 disk each. If you have addition msa30s, it will depend on if you add a single dual-bus or two single-bus.
- How many LUNs will be using the same SCSI busses: the more you have the more contention can mess things up. This is at odds with the above, so it's a balancing act.
- What LUNs will used simultaneously and need to have isolated mechs/busses?
- What LUNs will used at different times and might be able to have shared mechs/busses?
- How many hot spares do you want and how do you want to assign them to LUNs? Spares can be shared across LUNs
- How many controllers and how to allocate the LUN across them and how redundancy is setup
Create the LUNs
My msa1000 has 14 disks on the internal two busses and a dual-bus msa30 with another 14 disks. So I have four busses of 7 disks each. I decided that performance was more important than space, and that most of my LUNs needed to be pretty isolated from each other. But I still wanted good redundancy, so I used RAID0+1 which meant my LUNs needed at least 4 disks each. Here is how I allocated the disks:
1 2 3 4
1: 6, 0, 0, 0
L 2: 0, 6, 0, 0
U 3: 0, 0, 6, 0
N 4: 0, 0, 0, 6
5: 1, 1, 1, 1
In the serial console I ran:
add unit 1 data="DISK101-DISK106" raid_level=1
add unit 2 data="DISK108-DISK113" raid_level=1
add unit 3 data="DISK201-DISK206" raid_level=1
add unit 4 data="DISK208-DISK213" raid_level=1
add unit 5 data="DISK107 DISK114 DISK207 DISK214" raid_level=1
For RAID0+1 you just specify "raid_level=1" and if the array has the right number of disks it does the right thing. In cases where you want to control how the redundancy and striping are done across the disk I don't know if the specified order is the way to do that or if it always does the same thing. (if anyone tests this and determines the result, let me know)
Setup the connections
You need to add a connection for each host. On my system this looked like:
add connection sneezy wwpn=500110a0-001a13c0 profile=Linux
add connection grumpy wwpn=500110a0-0019ef78 profile=Linux
add connection happy wwpn=500110a0-001a0a24 profile=Linux
add connection dopey wwpn=50060b00-006a7e38 profile=Linux
add connection sleepy wwpn=50060b00-006a8e50 profile=Linux
add connection doc wwpn=10000000-c95686fa profile=Linux
Setup the ACLs
You can use Access Control Lists to limit what hosts can access which LUNs. Even if you don't think you need this for security reasons, it's a good idea for safety reasons so you don't accidentially use the wrong disk and overwrite data. On my setup it looked like this:
add acl connection=sneezy unit=1
add acl connection=grumpy unit=2
add acl connection=happy unit=3
add acl connection=dopey unit=4
add acl connection=sleepy unit=5
My msa1000 has two controllers and I am running the active/active firmware. I decided to make different LUNs prefer different controllers, I did:
set preferred_path this_controller 1 2 3
set preferred_path other_controller 4 5
Setup the SAN switch
On my setup I have a SAN switch in the blade chassis I am using that is an HP rebranded Brocade switch. I setup "zones" to connect each host to the msa. Here's a short list of what I did:
- start the "switch explorer" java app
- go to "zone admin"
- setup aliases for all the hosts, you can get their wwpn from /sys/class/fc_host/host#/port_name or in my case from the blade chassis UI (HP Onboard Administrator).
- setup aliases for the two msa1000 controllers, you can get their wwpn from the serial console with "show this_controller" and "show other_controller"
- setup zones for each drive with the host and the msa1000 port that you want in them
- setup a zone config that contains all the zones
- save the zone config
- enable the zone config
- try rebooting the SAN switch to ensure that the config is still there
I also figured out how to update the msa1000/1500 firmware using the serial console, so you can do it on OSes they don't provide tools for (like Debian, the BSDs, etc).
Matt Taggart <firstname.lastname@example.org>