The IBM Storwize V7000 has a new stable mate: IBM’s hot new seller, the Storwize V3700. I recently got a chance to try one out and I liked what I saw. I have always tried to share useful information on this blog, so here are four things you may find useful about IBM’s new little midrange storage offering:
The Node Canisters (Controllers) are side by side and both right way up. I really like this change. Hopefully all future models will follow this pattern and avoid upside down components. One thing you will spot from the picture is that the Fibre Cards are optional. What you might think are Fibre Ports in this picture are actually SAS ports. The fibre card goes where that large black square is on the right hand side of each canister.
The Storwize V3700 can report power consumption and operating temperature via both the GUI and CLI. This is a great extra piece of information.
Being able to get this information via CLI is also critical as it allows you to script it for those shops where rack power consumption is constrained so check out the lsenclosurestats command.
IBM_2072:Cluster:anthonyv>lsenclosurestats enclosure_id stat_name stat_current stat_peak stat_peak_time 1 power_w 124 125 130128230402 1 temp_c 19 19 130128230707 1 temp_f 66 66 130128230707
I looked for the license tab…. but there isn’t one! This is because Flashcopy is included, external virtualization ( as a migration tool) is included and remote copy is not possible. This makes for very simple purchasing; all you need to do is decide what disks, RAM and adapters you want. Nice!
I did find one (tiny) bug that is easily corrected, but is stealing 40 MB of your cache! If you display the bitmap memory, you may find 20MB dedicated to remote copy, despite the fact that you cannot create remote copies.
IBM_2072:Cluster:anthonyv>lsiogrp 0 id 0 name io_grp0 node_count 2 vdisk_count 3 host_count 1 flash_copy_total_memory 20.0MB flash_copy_free_memory 20.0MB remote_copy_total_memory 20.0MB remote_copy_free_memory 20.0MB mirroring_total_memory 20.0MB mirroring_free_memory 20.0MB raid_total_memory 40.0MB raid_free_memory 39.3MB maintenance no compression_active no accessible_vdisk_count 3 compression_supported no
You can easily correct this by running the following command that drops that bitmap to zero. You can run this command at any time, there is no risk in doing so. You will get 40MB of cache back (20MB per node canister).
chiogrp -feature remote -size 0 io_grp0
I spotted two interesting things about the WWPNs for the Storwize V3700 ports. Firstly IBM has broken with the 1,2,3,4 pattern we found with Storwize V7000 and gone to 04,08,0C,10. Frankly this is not a big deal and given the Node Canisters are side by side, it is just a case of knowing the pattern. The WWPN is based on: 50:05:07:68:03:YY:xx:xx where xx:xx is unique for each node canister and the YY value is taken from the port position as per the image below. I suspect these values may go up to 05, 09,0D,11 over time as they exhaust the serial number range possibilities of 00:00 to FF:FF
I did spot what I think is a great new command in V6.4.1 that also lets you display the WWPNs. It is lsportfcid. Try it out on your machine.
IBM_2072:Cluster_1:anthonyv>lsportfcid fc_io_port_id port_id type port_speed node_id node_name WWPN nportid status attachment 0 1 1 fc 8Gb 1 node1 5005076803040046 010500 active switch 1 2 2 fc 8Gb 1 node1 5005076803080046 010000 active switch 2 3 3 fc N/A 1 node1 50050768030C0046 000000 inactive_unconfigured none 3 4 4 fc N/A 1 node1 5005076803100046 000000 inactive_unconfigured none 6 1 1 fc 8Gb 2 node2 5005076803040047 010400 active switch 7 2 2 fc 8Gb 2 node2 5005076803080047 010100 active switch 8 3 3 fc N/A 2 node2 50050768030C0047 000000 inactive_unconfigured none 9 4 4 fc N/A 2 node2 5005076803100047 000000 inactive_unconfigured none
I did spot one thing when displaying the FC ports in the GUI. They are currently listed back to front, just something to be aware of:
So are you running a V3700? How is it working out for you?