Anthony's Blog: Using System Storage - An Aussie Storage Blog
Just a short update to say that Visio Cafe has some new IBM stencils.
IBM supply the stencils to Visio Cafe who make them available free of charge to all our customers.
You can use these stencils without acknowledgement or payment.
Clearly you still need to buy Visio from Microsoft.
The latest updates can be found here: http://www.visiocafe.com/ibm.htm
In part three of my series, AIX and XIV.... I will explore the recommended configuration changes you should make to AIX when attaching XIV disk.
So lets get started:
lsattr -El fcs0
Two of the attributes will look like this:
max_xfer_size 0x100000 Maximum Transfer
lsattr -El fscsi0
Two of the attributes will look like this:
Tracking of FC
I suggest you change these values as follows:
lsattr -El hdisk26
Two of the attributes will look like this:
TRANSFER Size True
I suggest you change these values as follows:
By increasing the max_transfer size, we allow the maximum LTG size on each volume group (VG) to be larger. The LTG size of a VG cannot be larger than the smallest max_transfer size of all the hdisks that make up that VG. When the LVM receives a request for an I/O, it breaks the I/O down into what is called logical track group (LTG) sizes before it passes the request down to the device driver of the underlying disks. The LTG is the maximum transfer size of an LV and is common to all the LVs in the VG.
You can display the LTG size by using the lsvg command against the relevant VG.
AIX XIV Utils
root@testserver [/home/anthonyv/aix_xiv_utils-2.0/bin] # ./lshba -x
We use the chhba commands to change fcs and fscsi attributes. We issue a single command to change all the HBAs at once. This command only changes the ODM. We need to reboot for the changes to take effect. Note we need to type yes when prompted, for the script to run.
root@testserver [/home/anthonyv/aix_xiv_utils-2.0/bin] # ./chhba -d
yes -f fast_fail -m 0x200000 -n 2048 -P
In this example we display the relevant attributes of all the XIV hdisks. The settings in this example are NOT correct (queue depth still 32 and max transfer size still 0x40000) so we need to use the chxiv command to correct them.
We use the chxiv command to change the attributes of every XIV hdisk. This command only changes the ODM for XIV disks. We need to reboot for the changes to take effect. Note we need to type yes when prompted, for the script to run.
[/home/anthonyv/aix_xiv_utils-2.0/bin] # ./chxiv -r 64 –m 0x100000 -P
Change algorithm to round_robin with a queue depth of 64 for these disks? yes
Getting new XIV disk information...
AIX_SIZE(MB) ALGORITHM Q_DEPTH SERIAL
Conclusions and gotchas
So at the conclusion of this process, you should have an AIX system with more ideal settings for XIV. There are a couple of gotchas.
1) HBAs being used for tape. The chhba command will not change HBAs in private loop mode. This is to prevent errors like this:
Date/Time: Thu Feb 4 11:59:08 2010
Sequence Number: 250846
Machine Id: 00CB6AC44C00
Node Id: us04od03
Resource Name: fscsi3
SOFTWARE DEVICE DRIVER
SOFTWARE DEVICE DRIVER
INCORRECT HARDWARE CONFIGURATION.
IDENTIFY OFFENDING SOFTWARE COMPONENT
VERIFY SYSTEM CONFIGURATION IS VALID
REFER TO PRODUCT DOCUMENTATION FOR ADDITIONAL INFORMATION
2) Your queue depth settings may still not be deep enough. Periodically run iostat -D 5 and if you consistently notice avgwqsz or sqfull consistently not zero then increase queue depth (you can go up to 256). Don’t be tempted to start at 256 and work down. You may flood the XIV with commands. For the vast majority of clients, 64 is a good number.
3) Do you need to use these scripts? No you don’t. You can use smit or command line to change attributes.
Do you always need to reboot? No you don’t. But you will need to change the relevant devices to
a defined state to change them. For
instance you could change the queue depth on an hdisk the commands below. But only if the hdisk in not part of an online volume group. It remains easier to just change the ODM and reboot for the changes to take affect.
rmdev –l hdisk25
IBM have offered Enterprise Storage Virtualization since June 2003 with the IBM SAN Volume Controller (SVC). October 2010 saw IBM releasing the Storwize V7000, taking the SVC code and packaging it into a midrange disk product. So now you have four possible choices:
The great thing is that all four choices are valid and all four choices work just fine.
The short answer: YES!
We have a great many customers happily doing this, so I thought I would share some common questions I get around configuration. Firstly there is an InfoCenter page on this which you will find here. Secondly there is a debate about whether we should create individual volume/arrays on the Storwize V7000 or just create a single pool on the Storwize V7000 (which equates to striping on striping). More bench marking is being done to see if one method is truly better than the other, so until then I recommend the method described below. If you have already done stripe on stripe, don't go changing anything until I update this post.
How many ports should I use for Zoning?
The Storwize V7000 has 8 Fibre Channel ports, 4 from each node canister. You need to zone at least two ports from each node canister to your SVC cluster. This is no different to how you would zone a DS5100 or an EMC VNX.
How will the SVC detect the Storwize V7000?
On the SVC you will see two storage controllers, one for each node canister. This is quite normal. The reason for this is that each node canister reports its own WWNN. This is not a problem and will not affect volume failover if one node canister goes offline.
In the example below the SVC has detected two new controllers. The confusing factor is that both report as 2145s, but they are a Storwize V7000. Rename them to reflect what they really are (something like StorwizeV7000_1_Node1 and StorwizeV7000_1_Node2).
How should I define the SVC on the Storwize V7000?
You need to create a new host on the Storwize V7000 and call it something like SVC_1. if the SVC WWPNs don't appear in the WWPN dropdown, you will need to manually add them as shown below:
You can get the SVC WWPNs from your existing zoning or by doing an svcinfo lsnodeagainst each SVC node or display them in the SVC GUI as shown below:
What size Storwize V7000 volumes should I create?
My recommendation is to do the following on the Storwize V7000
Hopefully all of this makes sense. Questions and comments very welcome.
Until the flash is updated showing how to avoid this issue, only update drive firmware when installing a new machine or if all hosts are offline.
IBM recently released new drive firmware for the Storwize V7000, so I thought I would share the process of how I update that firmware. You can download it from here. The details for this new package can be found here. I recommend you perform the drive update before you next update your Storwize V7000 microcode.
I want to be clear that one of the central goals of the Storwize V7000 is to ensure that performing drive firmware updates can be done online without host disruption. This is possible because each drive can be updated in less than around 4 seconds. The scripts I share below leave a 10 second delay between drives just to be safe. I would still prefer that you did the update during a quiet period.
We need to perform this procedure using the command line as there is no way to do this procedure from the GUI (yet).
There are four steps:
Step 1: Upload and run the upgrade utility
From the Putty folder we need to upload the test utility. You will need to change the key file name, userid and IP address (all highlighted in red) to suit your installation.
NOTE: The following command is being run in a Windows command prompt. You need to be in the C:\Program Files\Putty or C:\Program Files (x86)\Putty folder.
pscp -i anthonyv.ppk IBM2076_INSTALL_upgradetest_6.15 firstname.lastname@example.org:/home/admin/upgrade
Having uploaded the file, now start PuTTY and SSH to your Storwize V7000. Logon and issue the following two commands. You are using SSH commands now, not the Windows Command Prompt:
svcservicetask applysoftware -file IBM2076_INSTALL_upgradetest_6.15 svcupgradetest -f -d
If you get a warning window like the one shown below, indicating we have down-level drives, we need to proceed to the next step (note that the enclosure and slot numbers are not the same as drive IDs). If you have a lot of drives, you can drop the -d from the svcupgradetest command to get a summary list.
******************* Warning found ******************* +----------------------+-----------+------------+------------------------------------------+ | Model | Latest FW | Current FW | Drive Info | +----------------------+-----------+------------+------------------------------------------+ | HK230041S | 2920 | 291E | Drive in slot 24 in enclosure 1 | | | | | Drive in slot 23 in enclosure 1 | | ST9450404SS | B548 | B546 | Drive in slot 22 in enclosure 1 | | | | | Drive in slot 21 in enclosure 1 | | | | | Drive in slot 20 in enclosure 1 | | | | | Drive in slot 19 in enclosure 1 | | | | | Drive in slot 18 in enclosure 1 | | | | | Drive in slot 17 in enclosure 1 | | | | | Drive in slot 16 in enclosure 1 | | | | | Drive in slot 15 in enclosure 1 | | | | | Drive in slot 14 in enclosure 1 | | | | | Drive in slot 13 in enclosure 1 | | | | | Drive in slot 12 in enclosure 1 | | | | | Drive in slot 11 in enclosure 1 | | | | | Drive in slot 10 in enclosure 1 | | | | | Drive in slot 9 in enclosure 1 | | | | | Drive in slot 8 in enclosure 1 | | | | | Drive in slot 5 in enclosure 1 | | | | | Drive in slot 6 in enclosure 1 | +----------------------+-----------+------------+------------------------------------------+
Step 2: Upload the drive microcode package
Download the drive update package from here. Put it into the PuTTY folder.
pscp -i anthonyv.ppk IBM2076_DRIVE_20110928 email@example.com:/home/admin/upgrade
Step 3: Apply the drive software
I have written some scripts to help you list the drive IDs that need to be updated and perform the updates. You can upgrade the drives one at a time, or in bulk, depending on how you want to do this. All the remaining commands are all run in a PuTTY session.
Firstly run this script to list all the drive IDs and current firmware levels. We need the drive IDs if we want to update individual drives.
svcinfo lsdrive -nohdr |while read did error use;do svcinfo lsdrive $did |while read id value;do if [[ $id == "firmware_level" ]];then echo $did" "$value;fi;done;done
The output will look something like this, showing the drive ID and that drive's current firmware level. From step 1 we know what the latest firmware level is, so we can compare to the current firmware level:
0 291E 1 291E 2 B546 3 B546 4 B546 5 B546 6 B546 7 B546 8 B546 9 B546 10 B546 11 B546 12 B546 13 B546 14 B546 15 B546 16 B546 17 B546 18 B546 19 B546 20 B546 21 B546 22 B546 23 B546
Now we can update individual drives with this command, which will update drive ID 23. Just keep changing the drive IDs, using the list of down-level drives, until every drive has been updated:
svctask applydrivesoftware -file IBM2076_DRIVE_20110928 -type firmware -drive 23
However you may have a lot of drives and want to upgrade them in bulk. So you could use this command, which updates drive ID 19 and 20 (highlighted in red). You could change and also add extra drives to the list as required:
for did in 19 20;do echo "Updating drive "$did;svctask applydrivesoftware -file IBM2076_DRIVE_20110928 -type firmware -drive $did;sleep 10s;done
If we just wanted to upgrade every single drive in the machine (regardless of their level), we could run this command:
svcinfo lsdrive -nohdr |while read did name IO_group_id;do echo "Updating drive "$did;svctask applydrivesoftware -file IBM2076_DRIVE_20110928 -type firmware -drive $did;sleep 10s;done
When updating multiple drives, I have inserted a 10 second sleep between updates, just to ensure the process runs smoothly. This means each drive takes about 13-15 seconds.
Once we have upgraded every drive, it is time for a final check.
Step 4: Confirm all drives are updated
You have two ways to confirm this. Firstly run the following command to list the firmware level of each drive. Is each drive reflecting the levels reported in Step 1?
svcinfo lsdrive -nohdr |while read did error use;do svcinfo lsdrive $did |while read id value;do if [[ $id == "firmware_level" ]];then echo $did" "$value;fi;done;done
Now run the software upgrade test utility again:
svcupgradetest -f -d
Provided you receive no warnings about drives not being at the recommended levels, you are now finished with the drive updates. Of course you could now proceed to install 126.96.36.199 firmware, but you can do that from the GUI.
anthonyv 2000004B9K Tags:  heatmap ds8700 cmua00007e ds8800 easy tier storwize stat svc v7000 15 Comments 14,025 Views
The IBM Storage Tier Adviser Tool (known as STAT for short) is a clever piece of software that lets you predict how much business value you would get from adding SSDs to your Storwize V7000, SVC, DS8700 or DS8800. This is because you can add SSDs to all of these products and then have hot spots dynamically and automatically migrated to SSD using IBM's Easy Tier technology (which is offered as a no charge feature).
For clients who have not yet purchased SSDs, or who are unsure which Storage Pools to deploy them into, the STAT tool will help with decision-making.
I recently struck a rather simple problem with the STAT tool after installing it: I kept getting a CMUA00007E error. I downloaded the tool from here and installed it successfully onto my Windows 2008 64-bit lab machine (running on a IBM x3850). The install went fine so I then proceeded to download the heatmap from my Storwize V7000. The heatmap file is automatically generated by Easy Tier and is used as an input file for the STAT tool. You can see an example of where to find the heatmap file in the screen capture below:
I then placed the heatmap into the same folder as the STAT tool and tried to generate a report. It failed with this rather annoying message:
C:\Program Files (x86)\IBM\STAT>stat dpa_heat.78G01A6-2.110823.072309.data CMUA00007E The STAT.exe command failed to produce the heat distribution output.
I initially thought I had a bad heatmap, but since it is a binary file, opening it in a text editor did not tell me anything.
Actually the issue was simple: I did not have write authority to that folder. To get around this I instead started the command prompt as Administrator:
I then re-ran the command:
C:\Program Files (x86)\IBM\STAT>stat dpa_heat.78G01A6-2.110823.072309.data CMUA00019I The STAT.exe command has completed.
Having run the tool I was now able to open the index.html in the STAT folder and see much hot data I have in my lab. Turns out that I don't actually have any hot data right now! Don't tell my manager though, he might try to take my SSDs away. #
Having run the tool once, I did not need to use this trick again. It now runs without starting the command prompt as Administrator.
Once your SVC or Storwize V7000 is upgraded to version 6.3 you can start using LDAP for authentication. This means that when you logon, you authenticate with your domain user-id and password rather than a locally created user-id and password.
So why is this important?
So as an exercise I added my lab Storwize V7000 to our domain to show how it is done. This example also applies to an SVC so don't be confused if I only refer to Storwize V7000 from now on.
The first task is to negotiate with your Domain administrator to get a new group setup on the domain. In this example I use a group called IBM_Storage_Admins which lets me use this group for various storage devices (such as an XIV or a SAN Switch).
To create this group we need to logon to the Domain Controller and configure Active Directory. An easy way to do this from the AD controller is to go to Start → Run and type dsa.msc and hit OK. The Active Directory Users and Computers Management Console should open.
Select the groups icon to create a new group.
Enter your group name, in my case: IBM_Storage_Admins and hit OK.
Now right select relevant users who need access to the storage and add them to the IBM_Storage_Admins group. In this example I have selected Anthony (which uses anthonyv as a username).
In this example we are adding anthony into the IBM_Storage_Admins group:
Now it is time to configure the Storwize V7000 so start the Web GUI and logon as Superuser.
Firstly we go to Settings → Directory Services:
We choose the button to Configure Remote Authentication:
We choose LDAP and hit next.
We choose Microsoft Active Directory with no Transport layer Security. We then expand the Advanced Settings. My lab domain is ad.mel.stg.ibm so I use the Administrator ID on the Domain Controller to authenticate access. You could use any user that has authority to query the LDAP directory. We then hit Next.
We then add the domain controller which in this example is 10.1.60.50 and the base domain name chopped into pieces (so ad.mel.stg.ibm becomes dc=ad,dc=mel,dc=stg,dc=ibm ) and hit Finish.
Provided the command completes successfully we have defined the domain controller to the Storwize V7000. Now we need to add a group. Go to Access → Users.
Select the option to add a New User Group.
In this example we want to add a group for users allowed full admin access to the Storwize V7000. This matches the group we created on the Domain Controller. So we call the group IBM_Storage_Admins and we use the Security Administrator role (which is the most powerful role) and tick the box to enable LDAP for this group.
Now to test, I logon to the Storwize V7000 using the domain user-id anthonyv with that users domain password. Remember this user is not defined on the Storwize V7000 itself and that if it all goes wrong, we can still logon as Superuser.
Now I create a volume and delete it. Then I check the audit log from Access → Audit log.
Sure enough, we see exactly who did that command.
This is a great outcome for security,auditing and for easy access administration.
If you have issues, from the Settings → Directory Services menu, use the Global Actions dropdown on the right hand side to Test LDAP Connections and Authentication or re-configure LDAP.
If you already have existing users (what we call Local users), configuring remote authentication using LDAP does not disable or invalidate those local user-ids. This means you can either logon with a local user-id or logon with a Domain user-id. This is handy if the domain controller fails but can confuse you if your local user name and your domain user name are the same name (for example both anthonyv). The Storwize V7000 will look you up in the local user name list first. I suggest removing all local users (except superuser) as this will reduce confusion but still leave you a backdoor in case remote authentication stops working.
If you see any mistakes or have suggestions to improve the way I described this, please let me know.
One of the biggest challenges when working on such a wide variety of products is staying familiar with the GUIs used by each product.
So its worth remembering that there are simulators and demo modes in all of IBM's disk products.
The XIV GUI offers a demonstration mode that can be accessed by simply logging on with a user-id of p10demomode.
No password is needed.
While the demo mode does not let you change anything, the current GUI version lets you 'see' three XIVs including mirroring connections.
The current XIV GUI is version 2.4.3 which can be downloaded from here:
Why not download the GUI and check it out?
You can get a Simulator for the DS Storage Manager from this website:
The really nice thing with the current version is that offers not one but five simulated machines.
This is a great way to practice creating arrays and explore the menu options.
If you change your laptops IP address and the simulated machines won't 'connect', just right click on the Host object and 'Remove' it.
Then right click on the PC object (the top device) and choose 'Automatic Discovery'.
I probably use this simulator about once per week, so I can vouch for its value.
You can install the DS Web GUI and run it in Simulated mode by downloading the DS8000 Storage Manager. There are many versions to download. If you have an existing DS8000, try and match the version you download to the version of your running machine (the link gives details). Else download the latest version.
anthonyv 2000004B9K Tags:  mbps v7000 iops performance response times svc storwize 11 Comments 16,129 Views
With the 6.3 release of the Storwize V7000 and SVC code (which I blogged about here), there are so many new features and functions that I have plenty more to blog about!
The first new feature I blogged about was LDAP support, but an existing feature that has been enhanced is the performance monitor (brought in with release 6.2). When this first came out I put a video on You Tube showing what metrics could be displayed in that release. This is a sped up image with no voiceover:
Now with release 6.3 IBM has added separate graphs for reads and writes plus the ability to display IOPS or MBPS, plus the ability to display graphs of read and write latency. Nice! I got so excited I made another You Tube video, this one with narration. So now you can compare the new to the old:
anthonyv 2000004B9K Tags:  machine type brocade decoder silkworm converter ibm 11 Comments 125,200 Views
IBM has been selling IBM branded Brocade switches since 2001 when we announced the 8-port 2109-S08 and 16-port 2109-S16. These were classic switches that ran at 1 Gbps. They had a front operator panel with a small keypad (a feature which in the rush to fit in more SFPs, did not appear in future models). Since then IBM has gone on to sell many of Brocades switches and directors.
Sometimes you need to convert a Brocade model name to an IBM model name (or the other way around). One way to assure yourself with scientific accuracy which type of switch you are working on, is to telnet or SSH to a switch and issue a switchshowcommand. You will get a switchType value. In this example, my switch is a switchtype 27.2.
IBM_2005_H08a:admin> switchshow switchName: Switch01 switchType: 27.2
Or if you are using the Web GUI, you can also see the switch type on the opening screen. In this example the switch is a type 34.0.
Having scientifically determined the type of switch, we can now use my decoder ring to determine the IBM machine type, IBM model name and the Brocade model name. I have ordered the switches by Type number. There are three things to note:
TYPE SPEED IBM TYPE IBM MODEL NAME BROCADE MODEL NAME 2.x 1 Gbps 3534-1RU Brocade 2010 3.x 1 Gbps 2109-S08 Brocade 2400 6.x 1 Gbps 2109-S16 Brocade 2800 9.x 2 Gbps 2109-F16 Brocade 3800 (Cylon) 10.x 2 Gbps 2109-M12 Brocade 12000 (Ulysses) 12.x 2 Gbps 2109-F32 Brocade 3900 (Terminator) 16.x 2 Gbps 3534-F08 Brocade 3200 (Mojo) 21.x 2 Gbps 2109-M14 Brocade 24000 (Meteor) 22.x 2 Gbps IBM BladeCenter Module Brocade 3016 (Blazer) 26.x 2 Gbps 2005-H16 Brocade 3850 (Dazzler) 27.x 2 Gbps 2005-H08 Brocade 3250 (DazzlerJR) 32.x 4 Gbps 2005-B32 SAN32B-2 Brocade 4100 (Pulsar) 34.x 4 Gbps 2005-B16 SAN16B-2 Brocade 200E (Stealth) 37.x 4 Gbps IBM BladeCenter module Brocade 4020 (Blazer2) 38.x 2 Gbps 2109-A16 SAN16B-R Brocade AP7420 (Mars) 42.x 4 Gbps 2109-M48 SAN256B Brocade 48000 (Saturn) 43.x 4 Gbps HP BladeCenter Module Brocade 4024 44.x 4 Gbps 2005-B64 SAN64B-2 Brocade 4900 (Viking) 46.x 4 Gbps 2005-R18 SAN18B-R Brocade 7500 (Sprint) 46.x 4 Gbps 2005-R04 SAN04B-R Brocade 7500E (Sprint) 58.x 4 Gbps 2005-B5K SAN32B-3 Brocade 5000 (Pulsar2) 62.x 8 Gbps 2499-384 SAN768B Brocade DCX 64.x 8 Gbps 2498-B80 SAN80B-4 Brocade 5300 66.x 8 Gbps 2498-40E SAN40B-4 Express Brocade 5100 66.x 8 Gbps 2498-B40 SAN40B-4 Brocade 5100 67.x 8 Gbps 2498-E32 Encryption Switch Brocade Encryption Switch 71.x 8 Gbps 2498-24E SAN24B-4 Express Brocade 300 71.x 8 Gbps 2498-B24 SAN24B-4 Brocade 300 73.x 8 Gbps 10 port IBM BladeCenter module Brocade 5470 (Blazer3) 73.5 8 Gbps 20 port IBM BladeCenter module Brocade 5470 (Blazer3) 76.x CEE 3758-B32 IBM Converged Switch Brocade 8000 77.x 8 Gbps 2499-192 SAN384B Brocade DCX-4S 83.x 8 Gbps 2498-R06 SAN06B-R Brocade 7800 121.x 16 Gbps 2499-416 SAN384-2 Brocade DCX8510-4 120.x 16 Gbps 2499-816 SAN384-4 Brocade DCX8510-8 109.x 16 Gbps 2499-F48 SAN48B-5 Brocade 6510
If you use Data Center Fabric Manager (DCFM), it actually displays the Switch Type using Brocade model names. Here is an example report from the DCFM we are running in my lab. This level of information is very helpful.
anthonyv 2000004B9K Tags:  tomcat logical vasa ibm window number xiv unit vmware vsphere vcenter apache storage 10 Comments 21,635 Views
If you have combined vSphere 5.0 with XIV, then you may want to try out the new IBM Storage Provider for VMware VASA (vSphere Storage APIs for Storage Awareness). You can download the installation instructions, the release notes and the current version of the IBM VASA provider from here. Clearly because VASA is introduced in vSphere 5.0 your VMware vCenter also needs to be on version 5.0.
Now IBM have had a vCenter plugin for a very long time (which I have written about here, here and here) and while you still need that plugin if you want to do storage volume creation and mapping from within vCenter (as opposed to using the XIV GUI), the VASA provider makes storage awareness more native to vCenter. This is a very important step. It means instead of using vendor added icons and tabs (like the IBM Storage icon and the IBM Storage tab that are added by the IBM Storage Management Console for vCenter), you just use the default vCenter tabs.
Right now version 1.1.1 of the IBM VASA provider delivers information about storage topology, capabilities, and state, as well as events and alerts to VMware. This means you will see new additional information in three tabs: Storage Views, Alarms and Events.
After installing and setting up the VASA provider, in vCenter select your VMware cluster, go to the Storage Views tab and select the view Show all SCSI Volumes (LUNs) there are four columns with more information. The Committed, Thin Provisioned information, Storage Array and Identifier on Array (indicated with red arrows) comes straight from the XIV (hit the Update button at upper right if you are not seeing anything yet). This is really useful information as it lets you correlate the SCSI ID of a LUN to an actual volume on a source array. Here is a cut-down view of that extra information:
If you want a larger screen capture you can find one here.
The Task & Events and Alarms tabs will also now contain events reported by the VASA provider such as thin provisioning threshold alerts (although if you have just installed the provider you may see nothing new, as nothing has occurred yet to provoke an alert or event).
As usual I have some handy tips on the steps you will need to take to get VASA going:
Your setup tasks are now all completed. Now go and explore the panels I detailed above to see what new information you have available to your vCenter server.
Why a separate server for the VASA provider?
The IBM VASA provider uses Apache Tomcat, which by default listens on port 8443. However since vCenter already has a service listening on port 8443, it means we have a clash. I googled and found the Dell and Netapp VASA providers also listen on port 8443 and they also recommend separate servers. I noted Fujitsu's provider uses a different port but still requires a separate server. So it seems if you have multiple vendors you will either have to spin up a separate server for each vendors provider, or start playing with changing the port number. The installation instructions for the IBM VASA Provider explain how to change the default port number if you are truly keen.
I thought I would write a quick post about an issue that's not new, but is certainly worth being aware of....
One of the interesting tricks with the change to 8 Gbps Fibre Channel is that it required a change to the way the switch handles its idle time... the quiet time when no one is speaking and nothing is said. In these periods of quiet contemplation, a fibre channel switch will send idles. When the speed of the link increased from 4 Gbps to 8 Gbps, the bit pattern used in these idles proved to not always be suitable, so a different fill pattern was adopted, known as an ARB. All of this came to intrude on our lives when it became apparent that some 8 Gbps storage devices were having trouble connecting to IBM branded 8 Gbps capable Brocade switches because of this change. This led to two things:
An example of what was said?
"Starting with FOS levels v6.2.0, v6.2.0a & v6.2.0b, Brocade introduced arbff-arbff as the new default fillword setting. This caused problems with any connected 8Gb SVC ports and these levels are unsupported for use with SVC or Storwize V7000.
In 6.2.0c Brocade reintroduced idle-idle as the default fillword and the also added the ability to change the fillword setting from the default of idle-idle to arbff-arbff using the portcfgfillword command. For levels between 6.2.0c and 6.3.1 the setting for SVC and Storwize V7000 should remain at default mode 0.
From FOS v6.3.1a onwards Brocade added two new fillword modes with mode 3 being the new preferred mode which works with all 8Gb devices. This is the recommended setting for SVC and Storwize V7000"
So there are several tips that I will point you to, depending on your product of interest:
Brocade Release Notes
For most environments, Brocade recommends using Mode 3, as it provides more flexibility and compatibility with a wide range of devices. In the event that the default setting or Mode 3 does not work with a particular device, contact your switch vendor for further assistance. IBM publishes all the release notes for Brocade Fabric OS here.
Check out this link if your connecting an 8 Gbps capable DS3500, DS3950 or DS5000 to a 8 Gbps capable switch: http://www-947.ibm.com/support/entry/portal/docdisplay?brand=5000028&lndocid=MIGR-5083089
There is no tip for the DS8800 but the advice remains effectively the same as for the Storwize V7000. I can confirm that using a fill word setting of 3 works without issue.
SAN Volume Controller or Storwize V7000
Check out this link if your connecting a Storwize V7000 or CF8 or CG8 SVC node to an 8 Gbps capable switch: https://www-304.ibm.com/support/docview.wss?uid=ssg1S1003699&wv=1
The XIV Gen3 comes with 8 Gbps capable Fibre Channel connections. It does not support idle Fill Words meaning that the portCfgFillWord value should not be set to 0.
When an IBM System z server attaches an 8 Gbps capable FICON Express-8 CHPID to a Brocade switch with 8 Gbps capable SFPs, you should upgrade your switches or directors to Fabric OS (FOS) 6.4.0c or 6.4.2a and set the fill word to 3 (ARBff).
LTO5 and TS1140
IBM have two tape drives that are capable of 8 Gbps, the LTO-5 drive and the TS1140. Setting the fill word to 3 can actually cause issues with these drives. To avoid issues do one of the following (you only have to do one of these, not all three):
**** UPDATED 28 Feb 2012 - Added System z FICON and Tape info ****
IBM recently announced the new System Storage DS3500 Express. The DS3500 is an entry level storage system that can be easily serviced and managed by an end-user. It is a very worthy successor to the DS3200/DS3300/DS3400 product line. So I thought I would share with you 10 things I really like about the new IBM DS3500 (in no particular order).
1) Its small
The base unit is only 2U in size and can hold either 12 of the 3.5" disks or 24 of the smaller 2.5" disks (depending on model). Each expansion drawer can also hold 12 of the 3.5" or 24 of the 2.5" disks (depending on model) and you can have 3 of them. So thats a potential 96 disks in 8U of rack space.
2) Its all SAS
In my opinion, Serial Attached SCSI (SAS) is the future of disk attachment. Traditional parallel SCSI is so 20th century and FATA didn't work out too well. I think SATA and FCAL attached disk will eventually be replaced by SAS and the DS3500 is all SAS at the disk back end and SAS by default at the host front end as well.
3) Its got flashcopy
The DS3500 can create two flashcopies without any extra licenses. I really like the fact that if your doing an OS or application upgrade, you can give yourself a quick roll-back point by just reserving some space for a flashcopy repository. This is also a great way to test whether flashcopy is right for your business and if so, buy the license to create more than 2 copies at a time.
4) Its got remote mirror
The DS3000 range up until now did not offer remote mirror capability. This meant that if you wanted a DR solution you needed to buy something to go over the top such as IBM SVC or Softek Replicator. The DS3500 now offers its own native replication that not only fills a spot but is compatible with existing DS4000s and DS5000s that you may already have in your business.
5) Its got nearline
So FATA disk may not have worked out, by nearline SAS is a far better alternative. The 2.5" model offers a 500 GB 7.2 K RPM nearline SAS drive. Or how about a 2 TB drive in the 3.5" form factor? Want some archive disk using nearline where the spindle count will still deliver good performance? Heres the solution.
6) Its green
If we accept that MAID was not the solution for the masses, the better thing is to simply do more with less, which is exactly what the DS3500 does. We are talking around 500W of power usage for a 48 disk two drawer solution (with 2.5" disks). Thats around half the power consumption of the equivalent model with 3.5" disks. This means less power drawn in and less hot air blown out.
7) One model to rule them all
The DS3500 comes in one model: SAS. You want fibre channel? No problem, just add the card. You instead want iSCSI? Same deal, just add the card. All models retain the SAS adapters which are proving so popular in the rack and blade server space.
You need a point solution to provide data-at-rest encryption? Here it is with 300 GB and 600 GB Self Encrypting drives that protect your data with no performance impact. Even better is that the software to manage encryption is rolled into the DS Storage Manager. Talking of which...
9) Easy Management
The DS3500 continues to use an intuitive and easy to use GUI which now includes all the dynamic volume management. This is an improvement over previous models where this had to be done via command line.
10) Its cheap
Being entry level it is priced for that market. You could also place it behind the SVC for a quick encryption solution or as a VDisk mirror repository.
Want to know more? Go talk to your IBM Business Partner and check out the product page here:
anthonyv 2000004B9K Tags:  linux interface svc command-line uptime. ibm unified storwize kernel firmware v7000 8 Comments 30,935 Views
It is ironic that only days after I wrote that 497 is the IT number of the beast, I learn that Linux has another unfortunate number: 208.
The reason for this is a defect in the internal Linux kernel used in recent firmware levels of SVC, Storwize V7000 and Storwize V7000 Unified nodes. This defect will cause each node to reboot after 208 days of uptime. This issue exists in unfixed versions of the 6.2 and 6.3 level of firmware, so a large number of users are going to need to take some action on this (except those who are still on a 4.x, 5.x, 6.0 or 6.1 release). If you have done a code update after June 2011, then you are probably affected. This means that if you are an IBM client you need to read this alert now and determine how far you are into that 208 day period. If you are an IBMer or an IBM Business Partner, you need to make sure your clients are aware of this issue, though hopefully they have signed up for IBM My Notifications and have already been notified by e-mail.
In short what needs to happen is that you must:
To give you an example of the process, my lab machine is on software version 188.8.131.52 which you can see in the screen capture below. So when I check the table in the alert, I see that version 184.108.40.206 was made available on January 24, 2012, which means the 208 day period cannot possibly end before August 19, 2012.
Regardless, I need to know the uptime of my nodes, so I download the Software Upgrade Test Utility (in case you have an older copy, we need at least version 7.9) and run it using the Upgrade Wizard (NOTE! We are NOT updating anything here, just checking):
I Launch the Upgrade Wizard, use it to upload the tool and follow the prompts to run it, so that I get to see the output of that tool. The output in this example shows the uptime of each node is 56 days, so I have a maximum of 152 days remaining before I have to take any action. At this point I select Cancel. You can run this tool as often as you like to keep checking uptime.
Note if you are on 6.1 or 6.2 code you may see a timeout error when running the tool, especially for the first time. If you do see an error, please follow the instructions in the section titled "When running the the upgrade test utility v7.5 or later on Storwize V7000 v6.1 or v6.2" at the Test Utility download site.
As per the Alert:
*** Updated April 4, 2012 with links to fix levels ***
If you have any questions or need help, please reach out to your IBM support team or leave me a comment or a tweet.
*** April 10: The IBM Web Alert has been updated with new information on what to do if your uptime has actually gone past 208 days without a reboot. In short you still need to take action. Please read the updated alert and follow the instructions given there. ***
anthonyv 2000004B9K Tags:  ibm performance monitor svc storwize v7000 6.2 8 Comments 9,569 Views
As Barry Whyte pointed out in this blog post, the release 6.2 code is available for download and installation onto your SVC and Storwize V7000.
I thought I would quickly check out two of the announced features of the 6.2 release: the new Performance Monitor panel and support for greater than 2 TiB MDisks. So on Sunday I got busy and upgraded my lab Storwize V7000 to version 220.127.116.11.
Remember that in nearly every aspect the firmware for the SVC and Storwize V7000 are functionally identical, so while I am showing you a Storwize V7000, it equally applies to an SVC.
Firstly I tried the performance monitor panel, and what better way to show you what I saw than on YouTube? This is my first YouTube video so please forgive me if its not slick. I started the performance monitor and captured two minutes of performance data using Camtasia Recorder. Because it is fairly boring to stare at graphs slowly moving right to left, I then sped it up eight times, and this is the result:
The video is shot in HD, so if what your seeing is grainy or hard to read, change the display to 720p or 1080p. Now if you want to see the performance monitor at its actual speed, here is the original normal speed video. Remember this is the same video as above, just slower. It can also be viewed in 720p.
So what are you seeing?
You will note that each metric has a large number (which is the current metric in real time) and a historical graph showing the previous five minutes. You can also change the display to show either node in the I/O group.
I found the monitor to be genuinely real time: the moment I changed something in the SAN (such as starting or stopping IOMeter or starting or stoping a Volume Mirror), I immediately saw a change.
Greater than 2 TB MDisk support
Next I logged onto my lab DS4800 and created two 3.3TiB volumes to present to the Storwize V7000. I chose this size because I had exactly 6.6 TiB worth of available free space on the DS4800 and I wanted to demonstrate multiple large MDisks. On versions 6.1 and below, the reported size of the MDisks would have been 2 TiB (as I discussedhere). Now that I am on release 6.2 with a supported backend controller, I can present larger MDisks. In the example below you can clearly see that the detected (and useable size) is 3.3 TiB per MDisk.
What controllers are supported for huge MDisks?
The supported controller list for large MDisks has been updated. The links for Storwize V7000 6.2 are here and for SVC here. If your backend controller is not on the list, then talk to your IBM Sales Representative about submitting a support request (known as an RPQ).
anthonyv 2000004B9K Tags:  ibm netapp san srm tagged storage and esx vmware xiv. sra xiv svc v7000 vsphere storwize 7 Comments 17,076 Views
I always laugh when people say to me: I wouldn't know what to blog about!
When you work in pre-sales support, you constantly get asked questions and each one of them could be the subject of a new blog post. Right now the most common question I am getting is:
I am implementing VMware Site Recovery Manager (SRM). One of the components I need are vendor specific Site Recovery Agents (SRA). I have searched IBM's website but cannot find them. Where are they?
So the short answer is: you get them from the VMware SRM download site.
So where are the SRAs? On each of the pages below use the Show Details button to see what version SRAs are being shipped with that SRM (although sometimes the pages take a few days between an SRA being added and the page being updated):
There are a few more questions I routinely get asked:
Does IBM actually have an SRA download site?
The answer is yes, but it is an FTP site only for SRAs written by IBM. It is principally a repository for older SRAs and beta SRAs but you can also find the current SRAs on it. You can find the site here. Note however that it is NOT the official source. For that you need to use the VMware site.
What about the SRA for LSI/Engenio based products like the DS4800?
These used to also be found on the LSI site, but since LSI sold Engenio to NetApp, it is no longer available from the LSI or NetApp websites. You need to download the current version from the VMware sites listed above. There is a version for SRM 5 on the VMware download site.
What about nSeries SRAs?
If you need an nSeries SRA, again you should go to the VMware download pages. There are separate SRAs listed and available for IBM nSeries (as opposed to an SRA for NetApp branded filers).
What about an SRA for XIV with SRM version 5?
The answer: The SRA for XIV with SRM 5 (and 5.0.1) is now available from VMware. If you have access to download SRM, you will be able to download SRA version 2.1.0. It is the same SRA for both XIV Generation2 and Gen3.
What about an SRA for Storwize V7000 and SVC version 6.3 code?
The answer: It is coming. We are working to make it available as soon as possible. I will update this post as soon as I have a date for you (we are talking weeks, not months).
*** Update March 23, 2012 - Added details on SRM 5.0.1 ***
On Friday November 18, 2011, IBMers around the world engaged in the worlds first group therapy session held entirely in Twitter!
It focused entirely on tweeting classic lines heard in day to day life at IBM, using the hashtag #stuffibmerssay. The result was an amusing out-pouring that kept growing as the day went on (and has not stopped). Karl Roche did a great summary write-up here where he captured some of the more classic stuff. Holly Neilson also wrote a nice blog post on the subject here.
You will notice many of the tweets focus on phone conferences, which are without a doubt the greatest contributor to and destroyer of, productivity in IBM. Classics such as this one came up again and again (and it's a common problem for me):
Nicely counter-balanced by failures to mute like these:
Enjoy.... and if you're an IBMer, please feel free to contribute, it's all in good fun.
anthonyv 2000004B9K Tags:  iphone blog reader fingers rss twitter fat 6 Comments 9,104 Views
Shock horror, I am starting to question the value of my iPhone.....
Actually... I am pondering whether the iPhone is the ideal social media tool I thought it was.
So whats the problem?
The problem is that while using the iPhone for this purpose I rarely interact, I never create content, I rarely contribute to content. By this I mean I almost never comment on blogs and I hardly ever twitter. This is quite simply because I hate using the keyboard. More and more I leave both twitter and feed readers to when I have time to actually interact via a real keyboard.
So I am curious... does anyone else feel the same way? Are there better devices out there for interaction? Or is it just my fat fingers and slow brain getting in the way?
Its been a busy few weeks.
I just spent a week in RTP North Carolina, with the STG Education team.
We ran through our first "Implementing the Storwize V7000" course in a "Teach the Teacher" format.
It was a lot of fun and I met some great fellow IBMers.
It gave me a great opportunity to drive the Storwize V7000 GUI and explore all the new possibilities it opens up.
First up.... the GUI is fantastic. Don't be fooled by the XIV Icons, its the smarts behind what the GUI does that makes it so powerful.
Its a 21st Century GUI following very strong principles of usability and simplicity.
Talking to client after client about this product, I get lots of great questions.
Two questions I get asked on a regular basis about Storwize V7000 are:
1) What is the smallest number of SSDs I can purchase?
The answer is that you can purchase just one. However with one disk you don't get any RAID.
So its better to buy two SSDs for a RAID1 pair. If you buy three SSDs you can form a RAID5 array.
2) Will the Storwize V7000 enforce the creation of hot spares?
The answer is that the pre-sets that the GUI offers you, will suggest the creation of spares.
For every 23 array members with the same drive class on a single
SAS chain which are not RAID 0 members, a single spare is created.
However the GUI will also allow you great flexibility.
You can specify that a smaller or larger number of spares get created.
You can choose to create NO hot spares at all.
You can convert a hot spare drive into a candidate drive ( a 'free' drive).
You can convert a candidate drive into a hot spare drive.
You can set a 'spare goal' to set a minimum number of spares that need to exist (or an event will be logged).
So what you get is a great level of flexibility.
Either follow the pre-sets and get IBM best practice... or choose your own desired spare levels.
If you choose to create no spares using SSDs the Storwize V7000 will use spinning disks to rebuild a failed SSD.
Then when the failed SSD is replaced, the contents of that drive will be failed back.
I have previously blogged about two XIV report generation tools that you can download and start using. This is just a short update to let you know there are updated versions of both tools, plus a new one that has just been added. These tools are all on my files section at the IBM developerWorks site (where you can also find my Visios).
To sum up what these tools do:
XIV Capacity Report
This Script creates an XLS or CSV file that contains 4 very useful tabs: Systems, Pools, Hosts, Volumes. You can use this to report on your storage, find un-mapped or un-mirrored volumes, check your consumption, etc. Clients, Business Partners and Cloud providers love this nice and simple tool.
It is currently up to version 3.9 and you can find it here.
XIV Performance Report
This Script creates an XLS or CSV file that gives the same information as the XIV Top utility but for a range of days (so we are looking at historic versus current performance). You could for example see what were the most busy volumes for the past 3 days or for the previous week. You can easily spot if host HBAs are not being used or if XIV interface traffic is not being balanced.
It is currently up to version 3.9 and you can find it here.
XIV Usage Report - NEW!
This Script creates an Excel file that shows you the current and historic usage of your volumes and pools. It also gives a trend prediction that will help estimate when your pools or volumes will be full of data. This is great for trend and growth analysis.
It is currently on version 3.9 and you can find it here.
So get downloading! Although if you don't have an XIV, these tools will not be of much use to you.
More details on how to setup and use these tools can be found here.
On a side note, I have found some downloads from the developerWorks site fail if you are using the Chrome browser. If you are having issues, switch to Firefox (just for that task).
** updated March 8, Usage Report is now on Version 1.1 **
** updated 26 Nov 2013 to point to new combined version 3.9 **
I am getting this question on a very regular basis:
"We have just upgraded to ESXi 5.0 but we cannot find the VAAI driver on the IBM Website"
The answer? There is no vendor supplied driver because no driver is needed. ESXi 5.0 uses a SCSI T10 compliant set of commands that all vendors need to support for VAAI to work.
But of course in the tradition of all answered questions, it leads to another question:
"Once I have upgraded to ESXi 5.0 how can I tell if VAAI is really working?"
The good news is that it is very easy to spot if ESXi 5.0 has detected a VAAI capable LUN. The moment a new LUN is detected by ESXi 5.0 it tries out an Atomic Test and Set command. If that works, you will see that Hardware Acceleration shows as Supported in vCenter. In the screen capture below I have three datastores, two from XIV and one from Storwize V7000, all presented to an ESXi 5.0 server. I dragged the Hardware Acceleration column over from the right hand side to help with the screen capture (in case your vCenter looks different), but you can see the Hardware Acceleration column shows each DataStore as Supported (and did so the moment the volume was detected).
Of course having seen the Hardware Acceleration Supported message only proves that Atomic Test and Set works. To confirm if XCopy (Hardware Accelerated Move) is working, on SVC or Storwize V7000 we can use the Performance monitoring panel. In the example below I first performed a storage vMotion, moving a virtual machine between two Datastores located on the same Storwize V7000 (running 18.104.22.168 firmware). I then performed a clone of the same virtual machine, where the source was on one datastore and the target was placed on another (but both located on the same Storwize V7000). What you can clearly see is that both operations (storage vMotion and cloning) generated no volume traffic, only MDisk traffic. This means that the ESXi server is doing none of the work and the storage is doing all of the work.
For more examples of how to test VAAI, check out section 9.5.5 Testing VAAI, in the new XIV IBM Redbook draft, XIV Storage System: Host Attachment and Interoperabilty which you can find here:
It documents the following tests:
The tests can be performed regardless of whether you have an XIV (on code levels 10.2.4a and above) or a Storwize V7000/SVC (on code levels 22.214.171.124 and above).
If upgrading to ESXi 5.0 with IBM Storage, please also be aware of the following knowledge base articles regarding VAAI support with IBM Storage:
In you case you hear different, it's time for a few simple facts about XIV:
For those of you with Apple iPads, you might consider dropping by the Apple Store and picking up your free IBM XIV Mobile Dashboard.
The IBM XIV Mobile Dashboard application can be used to securely monitor the performance and health of your XIV over a Wi-Fi or 3G link. Having downloaded and installed the Mobile Dashboard you will get a lovely XIV Icon:
When you start the Mobile Dashboard you will have the choice to either run in Demo Mode or to connect to an actual XIV. Demo mode can be accessed by selecting the Demo Mode option deep in the lower right hand corner. So you don't actually need an XIV to give it a test drive.
Once connected you have the choice of viewing volume performance or host performance. If you view (hold) the iPad in portrait mode you get a list of up to 27 volumes or hosts ordered by performance metrics (it defaults to ordering by IOPS). If you view the iPad in landscape mode you will get a more graphical output (as per the examples below). There are no options to perform configuration, the dashboard is intended only for monitoring. This means each panel will show the performance and redundancy state of the XIV.
The volume performance panel is shown by default. The example below shows the output when the iPad is operated in landscape mode. From this panel you can see up to 120 seconds worth of performance for a highlighted volume. Use your finger to rotate the arrow on the blue volume icon to switch the display between IOPS, bandwidth (in megabytes per second or MBps) and latency (in milliseconds or MS). The data redundancy state of the XIV is shown in the upper right hand corner (in this example it is in Full Redundancy, but it could be Rebuilding or Redistributing).
The example above shows the output when the iPad is operated in landscape mode. If you instead rotate the iPad to portrait mode, you will get a list of the performance of up to 27 of your busiest volumes.
Now swipe to the left to navigate to the Hosts panel as shown below.
From this panel you can see up to 120 seconds worth of performance for a highlighted host. Use your finger to rotate the arrow on the purple host icon to switch the display between IOPS, bandwidth (in megabytes per second or MBps) and latency (in milliseconds or MS). The data redundancy state of the XIV is shown in the upper right hand corner (in this example it is in Full Redundancy, but it could potentially also be Rebuilding or Redistributing). Swipe to the right to navigate to the Volumes panel.
The example above shows the output when the iPad is operated in landscape mode. If you instead rotate the iPad to portrait mode, you will get a list of the performance of up to 27 of your busiest hosts.
From either the volumes or the hosts panels you can log off from the mobile dashboard using the icon in the upper right hand-most corner of the display. When you log back on, the last used XIV IP address and username will be displayed (but not the password which will need to be entered again).
I can see some nice use cases here. You get a call regarding performance but you are on the road. Are there any problems with the XIV? You can quickly logon with your iPad and confirm if response times are normal and the redundancy state is Full Redundancy.
A better use case... now you can ask your manager to buy you an iPad, so you can monitor your XIV! Let me know how that goes #
anthonyv 2000004B9K Tags:  aix svc sddpcm mpio ds8000 ds6000 pcm sdd 2105 ess 5 Comments 28,915 Views
SDDPCM (Subsystem Device Driver Path Control Module) is the multi-pathing plug-in for AIX 5.3 and 6.1.
Customers who use IBM SVC, DS6000, DS8000 and/or ESS800 use this package to allow the operating system to handle multiple paths from OS to storage.
The good news is that this plug-in is supplied free of charge. The bad news is that it is not included with AIX fixpacks.
What this means is that while you may be dilligent with keeping AIX up to date, you may miss SDDPCM in the process.
There are two good reasons to keep SDDPCM in mind when planning updates:
1) Planning an upgrade from AIX 5.3 to 6.1
When AIX offered MPIO, IBM then also offered a vendor plug-in (Path Contol Module) for native AIX MPIO which IBM called SDDPCM. This means you have two choices with AIX: SDD or SDDPCM. If your considering which is best, SDDPCM is my preference. This is because it is native to the operating system and also better supports the possibility of co-existence of multiple PCMs. Note that migrating from SDD to SDDPCM is not supported by the VIOS at this time, so if your running VIOS you will need to stay put for now.
Henry Ford has long been quoted as having said:
While there is some debate on what Mr Ford exactly said, it's clear that for some time now IBM has heartily embraced this philosophy with a succession of all black machines (occasionally graced with a coloured stripe). So I was rather excited to spot something new in the IBM Melbourne demo center: an IBM Netezza (pronounced net-ease-a) It's rack door is one of the coolest IBM covers I have seen in years!
Even the internal blades look cool (I love the big N).
In case your curious, IBM® Netezza® Analytics is a purpose-built advanced analytics platform that enables your enterprise to get the most out of its data, giving you quicker answers to increasingly complex questions. It is the simple appliance for serious analytics.
Of course while I should have been thinking about big data and smart analytics, instead I have been reminiscing about IBM machines with coloured covers. For instance the IBM 3350 (storage from the 1970s) could be ordered with covers that were red... (Actually I think the correct name was garnet rose).
As far as I can tell, IBM have not offered coloured panels on Enterprise kit since June 28, 2002.
Prior to this devices could be ordered with feature codes like:
#9060 Willow green
While it is easy to find pictures of machines with Classic Blue covers like these 3380s (with 3880 control unit)
And even visions of a red computer room (with an all white 3800 printer on the left hand side):
The only picture I have found so far that shows a yellow machine appears to have faded to orange over the years (I don't think IBM sold orange System/38s?).
I did some more digging and found this great Youtube video. You can see some old System 360 kit with red covers and at 00:46 there are some machines in custom bright yellow! The client literally ordered the machines painted with a custom tint. That takescase modding to a whole new level.
So should IBM be embracing the new cool and coming out with a bright orange XIV? How about a Storwize V7000 in fluorescent blue? A man can dream....
And if you want to see more about Netezza and it's incredibly cool rack (and even cooler architecture), check this video out:
For the next few weeks I may not blog as frequently. It's not that I am tired of writing, but I will be writing on a different subject: Helping to update the four XIV Redbooks.
IBM Redbooks are one of the many ways that IBM differentiates itself from its competitors. They are very detailed how-to guides that IBM gives away for free, you don't even need a userid to download them. IBMs customers and business partners use them extensively and IBMs competitors love them too (for different reasons).
With the General Availability date of XIV Gen3 rapidly approaching, the Redbooks of course need to be updated. We have assembled a great team of residents (which due to the timing of the residency, could not include non-IBMers) and have started our chapter updates. Some of the chapters I have already picked up include Monitoring, Volume Copies and SVC migration with XIV. I am re-learning the joys of Adobe FrameMaker and have actually had the pleasure of running I/O to an XIV Gen3 (in fact two of them).
So my only question to all of you is: What do you want to see in the next XIV Redbook?
anthonyv 2000004B9K Tags:  storwize v7000 xiv vmware vcenter svc plugin ibm 6.2 2.5 4 Comments 37,859 Views
The IBM Storage Management Console for VMware vCenter version 2.5.1 is now available for download and install. This version supports XIV, SVC and Storwize V7000 as per the versions on the following table (the big change being support for version 6.2):
The download link is here.
If you want to see a video showing the capabilities of the new console, check out this link.
After installing the console, you will get this lovely new icon:
Start it up and select the option to add new storage, you now get three choices:
If your using SVC or Storwize V7000 you need to specify an SSH private key. This key MUST be in Open SSH format. This caused me a problem as I kept getting this message when trying to add my Storwize V7000 to the plug-in:
Unable to connect to 10.1.60.107. Please check your network connection, user name, and other credentials.
I could use the same IP address, userid and SSH private key to logon to the Storwize V7000 using putty, so I knew none of these things were wrong.
I reread the Installation Instructions closely and realized my mistake. It clearly states:
Important: The private SSH key must be in the OpenSSH format. If your key is not in the OpenSSH format, you can use a certified OpenSSH conversion utility.
I pondered what conversion utility I could use when I realized I had the utility all the time:Puttygen. I opened PuttyGen, imported my private key (the .ppk file) and exported my SSH private key using OpenSSH format. You don't need to do anything with the public key.
I was then able to add the Storwize V7000 by specifying the private SSH key exported using OpenSSH format.
Now I have both IBM XIV and Storwize V7000 in the vCenter plug-in and can get detailed information about and manipulate both. In this example I have highlighted the Storwize V7000, revealing it is on 126.96.36.199 firmware.
I was tempted to detail all the many things you can do with the plug-in, but your better off watching the video via this link.
So are you using the plug-in? Have you upgraded to version 2.5.1 yet? Comments very welcome!
Storage IT offers up many choices, some of which provoke argument so heated, you could almost describe the adherents as religious. I think you might know the sort of arguments I am talking about:
OK.... so maybe that last one isn't quite in the same league. But it is still fascinating to see the variation in usage patterns from sites where every command (of any description) is run via a command line interface (a CLI), to sites where the CLI is viewed with either great fear... or even greater distaste. There are those who view the CLI as... well... so 1970s.....
But the reality is that the CLI will always be with us for one principal reason: scripting. If you cannot script it, you cannot automate it (well actually thats not true, but stick with me here, I am on a roll). Every single major implementation I have ever done (whether it be SVC, XIV, DS8000), I have automated with scripting. I regularly use the concatenatecommand in Excel to build large numbers of commands that I can then run as a script.
So its pleasing to see that all of our products are working towards making the scripters life even easier. For example the XIV has offered a command log in the GUI for some time. I blogged about it here. You simply do a command once in the GUI and then consult the log to find the syntax, making scripting very easy:
With last years release of SVC 6.1 and Storwize V7000, we added this level of smarts to those two products as well. Now every command you run in the GUI will offer you the exact CLI command that was used under-the-covers to do this work. Simply toggle the details tab on the completion panel to see the command (or toggle it back to hide it!).
This weeks announcement of release 6.2 of the SVC and Storwize V7000 firmware, has brought in two more important usability improvements:
And there are more improvements coming, so as always, watch this space....
.... and please... share with me... are you a GUI... or a CLI person? Whats your reasoning behind your choice?
For someone who blogs so frequently about the IBM XIV, I will let you in on a little pet hate of mine: The XIV uses decimal volume sizes.
The XIV GUI and CLI has the user create volumes using decimal sizing, meaning 1 GB = 1,000,000,000 bytes (1000 to the power of three).
This disparity has a quirky consequence. If the XIV says a volume is 17 GB, the host that uses that volume says it is 16 GiB (which the host often then mis-states as GB). This doesn't mean there is a loss of space, this isn't headroom or formatting - its just a different way of counting bytes. Its not a road block and its easy to understand and work with. But it is a little annoying. (Then again, so is my 32 GB iPhone reporting it has 29.3 GB of space).
The other point is that the IBM SVC, Storwize V7000, DS8000 and DS3000/DS4000/DS5000 families have always used binary sizing (even if their respective interfaces use the term GB as opposed to GiB - yet another pet hate of mine and the Storage Buddhist).
So whats the point of this rant?
The IBM XIV Storage System GUI (Version 3.0) will allow volume creation in both GiB and GB units. The IBM XIV Storage System management GUI version 3.0 will support the creation of volumes in Gigabyte (GB) or in Gibibyte (GiB) or Blocks (where each block is 512 bytes).
So this is a really good change.
The new GUI has not hit the download site yet... but I will be sure to tell you as soon as it has!
*** Update 08/09/2011 - corrected GUI version from 2.5 to 3.0, removed some confusing terms ***
After 3.5 years of reliable service, the 19" LCD monitor on my sons computer died... and
would not power back on. Warranty long since expired and replacement LCDs being
relatively cheap, I replaced his monitor with a 22" LCD and he happily updated his
Facebook status to suit.
Except there was a problem.... what to do with the dead monitor?
I had three choices:
But there was a further problem. This lovely sticker on the back made no mention ofROHS and made even more disturbing mentions of mercury!
What I found was this site at Sustainability Victoria, which took me to this site which told me all about a program called ByteBack. One trip to Officeworks in Dandenong later and my dead LCD was off to be recycled at no charge to myself. Not only was my shed less cluttered, but I might even have helped the environment.
I would be curious to know if other people have been able to find similar programs in their locations? If so... please let know, lets spread the word!
In my last post I talked about the versions of XIV code and XIV Management GUI needed for QoS.
It leads to the question of how to match the Management GUI version to the XIV code version.... which goes with which?
Many storage products have management software that is separate from the software that runs inside the box (more commonly known as the firmware).
So for XIV, is there a best practice? What if I have multiple XIVs.... do I need them all to be on the same firmware version?
The good news is that you can simply use the highest available version of Management GUI, regardless of what code versions the XIVs are on.
In other words, if you see a new version of XIV GUI on the download site.... just upgrade to it.
Check out the screen capture below. This was taken with version 2.4.4 of the Management GUI (which is the latest at February 2011):
The XIV on the left is running the GA XIV code, version 10.0.0.a (which came out well over two years ago).
So I am able to run one of the oldest versions of XIV code, with the latest Management GUI. This is very good.
But why is the right hand machine greyed out?
To mix things up. the XIV on the right is running a brand new development (and thus un-released) version of code.
Because I am running a (relatively) older GUI version against a (relatively) newer XIV code version, the GUI is protecting us from a potential mismatch.
This means the GUI is always backward compatible, but is not always forward compatible.
Now speaking of greyed out, we saw a bug on previous versions of the GUI code, where a read-only user id would be confronted with a similar sight.
The machine would be greyed out and thus unmanageable. The work around was to use the older 2.4.2b build 10 version of the GUI.
The good news is that 2.4.4 contains the fix for this bug (so its another reason to upgrade).
That is all for now. Don't forget you can always logon as p10demomode to get a demo mode view of the XIV GUI.
I have been exploring some of the new features added in XIV firmware version 10.2.4.
Today I look at QoS (Quality of Service).
This new feature allows you to restrict how much IO (in IOs per second or IOPS) or throughput (in megabytes per second or MBps) an individual host can generate.
We do this by creating a new construct called a Performance Class. We can create up to four different Performance Classes and assign different hosts to each of those classes.
You can spot the new menu item under Hosts and Clusters:
The new panel contains a list of all your hosts and a new button at the top of the GUI panel called Add Performance Class:
When you create the Performance Class, you can set either an IOPS or a Bandwidth Limit.
It is also possible in a single Performance Class to set both an IOPS limit AND a Bandwidth Limit.
In these examples we set just a bandwidth limit.
One small quirk is that the limits will be rounded to a multiple of the number of active interface modules.
So don't be surprised if the numbers you enter are not the numbers that then appear. In the example below I enter 100 (for 100 MBps).
However when the class got created, the value was rounded down to 96 MBps( since I have 6 active interface modules).
To prove a simple point, in this example we have created three Performance Classes, all of which limit bandwidth.
You can see by their names the limit they will impose on any host moved to that Performance Class.
The exercise I performed used an AIX LPAR with an Oracle workload generator, that generates a constant workload of 150 MBps.
The first step was to add the host to the 96 MBps Performance Class.
Then the fun began. Monitoring of the performance of the LPAR was done with XIV Top. We moved the LPAR between performance classes to see the
effect on throughput of each class. All of this was done concurrently with no host interruption.
You can see from the output of XIV Top, that as the performance class was changed, the throughput was gradually throttled back (or allowed up) to that level.
At the end of the process we then removed the LPAR from its Performance Class, returning it to an unrestricted state.
This effectively allowed it to move back up to 150 MBps.
So why is this important?
Some clients had a concern that non-production hosts (such as test and development servers), got an equal share of the XIV performance pie.
In general this is not as issue, as the grid architecture of the XIV works very well with competing IO from multiple sources.
However with the advent of very high performance machines, it is not outside the realms of possibility for an individual server to generate
over 80,000 IOPS or over 1,000 MBps. I have certainly achieved this during benchmarking. If you spin-up several of these runaway
hosts simultaneously, you could saturate the grid and impact more deserving hosts.
So adding this feature makes sense.
What is even more sensible? it is added at no extra cost via a non-disruptive code update.
I have been asked this question a few times now, so its worth a blog entry.
Clients love being able to easily view XIV performance statistics.
There is a simple panel that lets you display IOPS, throughput and response times for each host or volume or for the entire machine.
When viewing XIV performance statistics using the built in GUI panels, write I/Os are broken into two types: write hits and write misses.
The question that comes up is... what is the difference? And should I be worried about misses?
The use of the term miss can have negative connotations. To explain why:
So what about a write miss? Does it mean that the write I/O 'missed' the cache?
The answer is.... no!
To explain the difference:
A write hit is the situation where a host write generates less back end disk operations. This is because:
anthonyv 2000004B9K Tags:  storwize solid-state v7000 ibm unified xiv drive 3 Comments 13,551 Views
IBM has today announced a whole swag of planned new features across the entire IBM Storage product line. You can read the announcement letter here and I have also dropped the text at the bottom of this blog post (to save you clicking on the link).
It's a very impressive list, but to hone in on a few of the more exciting offerings:
There are plenty of other new features as well, so check out the announcement letter reproduced below:
IBM® intends to support a number of new enhancements to a variety of IBM storage systems in the future. These enhancements will leverage innovative research on intelligent algorithms, automation, and virtualization that is being incorporated into products in the IBM storage portfolio. The statements of direction highlighted here are intended to provide a glimpse into the IBM storage roadmap for selected product capabilities.
IBM intends to deliver:
IBM intends to extend IBM Active Cloud Engine™ capabilities to:
IBM intends to deliver Cloud features to SONAS and Storwize V7000 Unified to support:
IBM intends to support an increased scalability of capacity, performance, and host bandwidth by clustering IBM XIV® Gen3 systems together and providing the capability to migrate volumes across the cluster without disrupting applications. Management of the cluster will remain simple with consolidated views and shared configurations across the systems. These capabilities are intended to help clients address the scalability and management requirements for effective cloud computing.
IBM intends to extend NAS data retention enhancements for IBM Storwize V7000 Unified and IBM SONAS to provide file "immutability" to help support file integrity from the time the file is designated as immutable through its lifecycle. Immutability is intended to secure files from inadvertent or malicious change or deletion.
IBM intends to enable Real-time Compression for block and file workloads on Storwize V7000 Unified systems. This enhancement is designed to help clients experience the same high-performance compression for active primary block and file workloads on Storwize V7000 Unified that is being announced for block workloads on Storwize V7000. IBM Storwize V7000 Real-time Compression is designed to deliver enhanced storage efficiency with potential benefits including lower storage acquisition cost (because of the ability to purchase less hardware), reduced storage growth, and lower rack space, power, and cooling requirements.
All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. The information in the above paragraphs are intended to outline our general product direction and should not be relied on in making a purchasing decision. The information is for informational purposes only and may not be incorporated into any contract. This information is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at our sole discretion.
anthonyv 2000004B9K Tags:  v6.3 sra storwize vmware. ibm srm firmware svc 3 Comments 25,811 Views
One common question that I hear on a regular basis regards the availability of an SRA for VMware SRM 5.0 when using Storwize V7000 or IBM SVC running V6.3 firmware. This combination is currently unsupported as per the alert found here.
The good news is that there are now IBM SRAs available for clients running SRM in combination with V6.3 firmware. While this combination is still not listed on the VMware support matrix found here, you can download the SRAs direct from IBM if your need is urgent.
The IBM download site is here:
For SRM 4.0 with a Storwize V7000 or SVC on V6.3 you can use:
For SRM 5.0 with a Storwize V7000 or SVC on V6.3 you can use:
For both links please check the FTP site to see if there is a later version.
Please also keep checking the VMware support matrix for the official support statement. I can see at least one example of someone using the latest SRA here.
anthonyv 2000004B9K Tags:  2048 4096 npiv wwpns storwize v7000 aix 512 svc 3 Comments 12,588 Views
IBM recently released a new version of firmware for the SAN Volume Controller and Storwize V7000. This is known as release 6.3 and continues the tradition of two major updates per year, each adding significant new functions.
Since I blithely listed this feature in a recent post I have received lots of emails asking exactly what it means, so I thought I had better explain.
Most of these numbers are very high and few customers actually approach these maximums. The main issue I am seeing for some of our larger AIX customers is this one:
The reason this can become an issue is the combination of NPIV and AIX Live Partition Mobility. NPIV allows one physical HBA to be shared among multiple operating system instances, each one believing it has exclusive access to the HBA with each one allocated its own unique WWPNs. Suddenly a single HBA which used to present just one WWPN through the SAN to the SVC, can now present vast numbers of them. In addition AIX Live Partition Mobility (which lets you move AIX operating systems between LPARs on the fly) needs additional pre-configured WWPNs defined on the target LPAR to support the move. This further increases the quantity of WWPNs that need to be defined to the SVC (one easy way to spot NPIV generated WWPNs is they normally start with the letter C).
So the bottom line is that IBM needs to make this limit bigger and SVC and Storwize V7000 6.3 code contains the necessary architectural changes to allow this. The first phase is to start potentially supporting up to 2048 WWPNs per I/O group although clearly based on the initial version of the release notes, the long-term plan is to support 4096.
But there is a problem and it has nothing to do with the SVC or Storwize V7000. The problem is that there are certain SAN configurations which may have issues with these large numbers of WWPNs (mainly around older SAN switches not having the CPU power for the switch fibre channel name-server and login-server to handle vast numbers of WWPNs coming out of one HBA).
So what should you do if you need to push the limits?
Contact your IBM Pre-Sales support and ask for a SCORE request to be opened (also known as an RPQ). You will need to detail your current SAN configuration (especially switch models and firmware levels) so that SVC development can ensure you won't overwhelm your switches. It will also allow our development team to learn how many clients our there need this support. All approvals will include a requirement to upgrade to release 6.3, so you should include this in your planning.
Any questions? Feel free to leave a comment or send me a tweet or an email.
I recommend everyone who uses the XIV GUI, regardless of their XIV firmware level, to upgrade to this level. Don't forget that even if you don't have an XIV, you can download and install the GUI and run it in demo mode to see just what everyone is talking about.
Removing the XIV JRE Path statements
The path variable changes are not retrospective, meaning installing the v3.01 XIV GUI will not remove the offending JRE path statement. If you find this is needed (because you have some broken Java applets), here is what you have to do.
To give you a more detailed set of instructions:
After install is complete, check the PATH variable, you should see just one reference to XIV: C:\Program Files (x86)\IBM\Storage\XIV\XIVGUI
You are now complete.
The SVC and Storwize V7000 offers a command line interface that you access via SSH. You start your favorite SSH client (such as PuTTY or Mindterm) and then logon as adminor as your own user-id. Right now to do this you need to generate a private/public key pair, although with release 6.3 (which will be available November 2011), you will be able to logon via SSH using just a user-id and password.
Having logged on there are three categories of commands you can issue:
svcinfo: Informational commands that let you examine your configuration.
There are several CLI usability features that I routinely find users are not aware of, so I thought I would share some of them here:
1) Listing all possible commands
If you cannot remember a command, here is a simple trick to list them all.
svcinfo -h or svcinfo -? svctask -h or svctask -?
You can also type either svcinfo or svctask and then hit the tab key twice to get a full listing. With svctask you will need to type y to list them all, as per the example shown below:
IBM_2076:STG_V7000:admin>svctask (HIT TAB twice!) Display all 139 possibilities? (y or n) y
2) Getting help on a particular command
Having found the command you want, issue that command with either -? or -h to get help information. For instance:
svctask mkvdisk -? or svctask mkvdisk -h
You will be shown the same help information that you can find in the Infocenter, including examples of syntax.
3) Drop the svctask and svcinfo prefixes
In release 6.2 of the SVC and Storwize V7000 firmware, the requirement to prefix a command with svcinfo or svctask has been removed. However I tend to keep using them because I write a lot of example commands for clients and I cannot be sure which version of firmware they are running.
4) Use the shell
When we SSH to the SVC or Storwize V7000 we are connecting to a Linux operating system using a special restricted shell. Some of the common Unix commands don't work (such as ls or grep or awk), but any commands that are provided by the shell itself, will work, such as while, if, read, pipe and echo.
We can use this to construct some really clever commands.
For instance creating volume copies is very popular, but the default copy rate is rather slow (50, which equals 2 MBps). It is not unusual for end users to speed up the background copy and then forget to slow it down when they are finished. So I wrote two commands to help me out. Firstly I run a command to display the copy rate of every volume. Ideally I should see 50 alongside each volume. However I often find that some volumes are set to higher numbers, such as the maximum value of 100 (which is 64 MBps).
svcinfo lsvdisk -nohdr |while read id name IO_group_id;do svcinfo lsvdisk $id |while read id value;do if [[ $id == "sync_rate" ]];then echo $value" "$name;fi;done;done
Lets break down this command. The structure looks like this:
I then run the following command which sets the copy rate for every volume to the default value of 50 (2 MBps):
svcinfo lsvdisk -nohdr |while read id name IO_group_id;do svctask chvdisk -syncrate 50 $id;done
Clearly you could edit this second command to change the copy rate to any value between 0 and 100. In each case you just paste the entire command in, and hit Enter.
Lets break down this command. The structure looks like this:
There are lots of possible clever combinations and I will list a few more in upcoming posts.
I have also been getting lots of requests to write a post about updating drive firmware, so expect something on that very soon.
I see this comment occasionally and it makes me bristle:
"Disk and tape traffic must be in separate zones because they have different characteristics. If they are in the same zone this can cause performance problems or have other adverse affects."
True statement or totally wrong?
Well actually kinda wrong... If you have a single HBA with only one port, then separating disk and tape traffic into separate zones does NOTHING to get around the fact that both streams of traffic (random bursty disk traffic and sequential streaming tape traffic) are all coming from or going to the same HBA port. All zoning achieves in this case is stop the disk and tape devices from talking to each other (something that in general they are not interested in doing).
Separating disk and tape traffic is best done with separate HBA ports (whether thats a dual ported HBA or two single port HBAs).
So lets change the wording:
"Disk and tape traffic should ideally be handled by separate HBA ports, because they have different characteristics. If both traffic types use the same HBA port this can cause performance problems or have other adverse affects."
Guess what? This advice has not changed since 2001.
With all my blogging about the XIV Gen3, I am sure there are 2nd Generation XIV users out there thinking: Whats in it for me? I already bought an XIV! So for all of you, I have some really cool news: Release 3.0 of the GUI is coming and it will work with your machine.
The current XIV GUI (as of this writing) is version 2.4.4 Build 3:
When we start shipping Gen3 XIVs in September we will also release new GUI software at the same time. This new GUI (release 3.0) will work with both 2nd Generation XIVs as well as Gen3 XIVs. I currently have a pre-release (beta) version so the final release may look slightly different. Swish huh?
Any changes? Here are a few I have spotted so far (I am not going to list them all):
Binary volume sizes can now be selected at volume creation time. It even uses my preferred terminology (GiB as well as GB). In addition a re-sizable box shows the space being used in the pool by this new volume (or volumes).
Simplified access to demo mode (no need to know the quirky p10demomode userid):
You can now easily spot the interface modules as they are highlighted.
Improved module health display showing module temperature. I was initially not amused when the temperature came up in Fahrenheit, but all you do is click on the temperature and it changes to Centigrade (and remembers your preference). Which is cool.
Revamped pool creation and information displays. Check out the pool titled Thin Pool, it's wearing a bright yellow belt to show it's a thin provisioned pool. The wording used for pool usage has also been improved. Nice!
There are some clever changes to the statistics panel such as simplified sliders and cool changes to the way you can manage the displayed time scale in multiple windows.
There are lots of other subtle changes too, particularly around multi-systems management and alerting, including a separate Alerts panel and new pop-ups for hardware failures. I could keep going for some time.... You will not be disappointed. They have taken a great GUI and made it even better.
Now in case you're rushing to download it, let me be clear: This new GUI is not available yet and anything I have shown you is subject to change. As soon as you can download it I will let you know.
I was inspired by this article on CBC News regarding the 30th anniversary of the launch of the IBM PC. That's right, on Friday August 12, 2011 the IBM PC turned 30.
Of course there were plenty of alternatives out there, but the IBM PC set standards that changed the industry forever (and IBM!). There is some great material in the IBM archives. Check them out here.
My first computer? An Exidy Sorcerer that I purchased around 1982. There it is in my bedroom (checkout the wood paneling and macrame plant holder!). It had 32KB of RAM plus plugable cartridges and a cassette tape recorder for storage.
I sold it in 1984 to a Doctor who paid far more than I initially did. He was running his whole surgery on a Sorcerer and desperately needed another one for parts. Tells you something about the risks of writing software for a closed platform.
My next computer was a 512 KB Apple Macintosh that I bought in 1985 through the University of Western Australia (UWA). UWA was an all Apple campus with Macs and then Mac SEs in every faculty. The library had Macs you could rent by the hour.
I remember paying $400 Australian for an external floppy disk drive. There was no hard drive and definitely no web browser!
My second employer (also a High School) had IBM JXs running DOS.
And my first computer at IBM was not a PC at all. It was an IBM 3290 Gas Plasma terminal that gave you four mainframe logons at the same time. I still remember that console with great affection. I found an image in Flikr if you want to see what one looked like.
So... what was your first computer?
Last week IBM released Version 2 of the management plug-in for VMware vCenter. The main benefit of Version 1 (the previous release) was that it allowed you to map your datastores to XIV volumes (i.e. which XIV volume equates to which VMware datastore). This was very handy (especially if you were not paying attention as you allocated volumes to your VMware farm), but you still needed the (very easy to use) XIV GUI as well as (obviously) vCenter to manage your landscape end to end.
With the release of Version 2 of the XIV plug-in, we suddenly have the tantalizing possibility that the VMware administrator will not need to talk to their storage administrator or turn to the XIV GUI for day to day operations.
Well Version 2 offers a new and improved graphical user interface (GUI), as well as brand new and powerful management features and capabilities, including:
So from vCenter you can now for instance map yourself some new volumes to create data stores, or re-size existing ones. You can also confirm that each of your datastores is being mirrored.
You can get the plug-in free of charge from here:
There is a users guide here. I urge you to download it and have a read. The Users Guide contains lots of really good examples of how the plug-in can be used with some great screen captures. The release notes are here and also make for very good reading.
I honestly think every VMware installation should be using this plug-in. But I am curious about how it will affect the responsibility divide. If your a one-person shop, the chances are that you love your XIV quite simply because you don't need to administer it. The XIV leaves you free to focus on your VMware farm, rather than fret about hot spots or hot spares or RAID groups. For you, this plug-in just makes your life even easier.
But what about larger companies? Firstly, its important to understand that to perform storage administration, the vCenter plug-in will need an XIV userid that has Storage Admin privileges. Why is this significant? Well what if the team who manage the XIV and the team who manage VMware, are not the same people? What if they are different teams; who maybe have different managers; who may work in different buildings or different cities? What if they work for different companies? Do plug-ins like this one erode the lines and bring these teams together? Or are the functional divides still too strong?
I would love to hear your experiences, both in using the plug-in.... and tearing down the walls.
I have some great news regarding VAAI support for XIV.
Let me detail the current situation:
So what should your plan be?
If your considering a midrange storage solution, there are many choices and many vendors.
I often get asked: Why IBM? What makes your solution special?
So when considering Storwize V7000, consider this:
The 24 disk Storwize V7000 enclosure currently offers four different disk types:
Thats four choices and 24 slots per enclosure. But the questions are:
The answer is: There are no rules.
You can order drives in any quantity you like and you can mix drives in an enclosure in any order you like.
So this is a very flexible set of choices.
Now there are rules on RAID arrays, but these are equally flexible.
For instance a RAID10 array can be anywhere from 2 disks (with is practically RAID1) to 16 disks.
RAID5 arrays can use anywhere from 3 to 16 drives, RAID6 uses 5 to 16 drives.
So when making that evaluation, ask our competitors: What are your rules when ordering disks? How restrictive are you?
The Storwize V7000 answer is: There are no rules.
anthonyv 2000004B9K Tags:  storage v7000 svc ibm xiv ds8000 wwpn storwize 2 Comments 19,207 Views
I have updated my IBM Storage WWPN Determination Guide to version 6.5.
The main change is that new DS8800s are now presenting slightly different WWPNs, so I added three new pages to describe the changes.
If this guide is new to you, its purpose it to let you take a WWPN and decode it so you can work out not only which type of storage that WWPN came from, but the actual port on that storage. People doing implementation services, problem determination, storage zoning and day to day configuration maintenance will get a lot of use out of this document. If you think there is an area that could be improved or products you would like added, please let me know.
It is also important to point out that IBM Storage uses persistent WWPN, which means if a host adapter in an IBM Storage device has to be replaced, it will always present the same WWPNs as the old adapter. This means no changes to zoning are needed after a hardware failure.
I also host the book on slideshare, so you can also view and download it from there:
IBM Storage Systems WWPN determination version 6.5
View more presentations from Anthony Vandewerdt
anthonyv 2000004B9K Tags:  zoning ds800 svc channel storwize alias xiv fibre switch san simplify v7000 2 Comments 18,074 Views
Lets imagine a new rack server or a new blade server has been added to your Fibre Channel SAN. The first job for the SAN administrator is to zone it to the storage it requires access to. The task normally runs something like this:
The main trap here is that when creating a zone, you need to ensure you select all of the correct storage aliases for your selected storage device. For instance we could have a simple layout like this:
Fabric 1 contains our new server (in this example an IBM x3850) and three XIV ports:
This means when creating the zone I need to identify and select four separate aliases. What I could do instead is create an alias with all my XIV target ports in it. Now I only have two aliases to select in that fabric:
If this was a Storwize V7000 implementation I could do the same thing. A typical install often look like this, where fabric 1 contains our new server and two Storwize V7000 ports:
This means when creating the zone I need to identify and select three separate aliases. What I could do instead is create an alias with both my Storwize V7000 WWPNs in it. Now I only have two aliases to select in that fabric:
This method of amalgamating multiple storage port aliases works fine for devices like DS8000, SVC, Storwize V7000 and XIV. I use this method all the time to simplify zoning and I find it reduces both mistakes and the time required to complete zoning tasks.
The only exceptions are:
I would love to hear any techniques you have to make your (and my) life easier.
anthonyv 2000004B9K Tags:  ldap. mirror storwize firmware 6.3 svc global v7000 2 Comments 13,268 Views
The latest release of SVC and Storwize V7000 firmware is now available for download. The major new features that are added with this release are:
These are some great new features. The ability to use Global Mirror with Change Volumes means clients can now mirror across far smaller pipes, while the increase in host WWPNs is very welcome news for NPIV installations that are suffering from WWPN sprawl.
If you plan to upgrade, firstly grab the new Upgrade Test Utility from here. The links to the Storwize V7000 and SVC versions are both on that page. Remember you can run this test as many times as you want whenever you want, to check the health of your device for upgrade. When you run the upgrade test utility on a Storwize V7000 you may get a message that your disks have down-level firmware. The process to update them is documented here.
If you're using a Storwize V7000 you can grab the 188.8.131.52 code from here. If you're using an SVC you can grab the 184.108.40.206 code from here. I am sending you to the compatibility matrix page because you should always check that your from level is ok for your to level.
To run the upgrade go to Configuration (the spanner icon) → Advanced → Upgrade Software → Launch Upgrade Wizard
I have not shown all the panels you will see because it is very much a follow-your-nose task, but in essence, first we feed it the Upgrade Test Utility file and run that test.
Once the test passes or you're happy you understand the warnings, we now point it at the code package and wait for it to copy across and keep hitting Next.
The application of the code shuts down and reboots each controller, with a 30 minute gap in between. You will transition from this (both nodes down-level, node1 being upgraded):
To this (node1 upgraded, node2 still online but waiting for 30 minutes):
When node2 starts the upgrade the GUI will failover to node1 and be upgraded to the new version. You will notice the difference immediately, it has a different look and feel. Please don't be tempted to play with the new functions until both controllers are upgraded! Wait until you see this (note a slight change, the GUI flow is now Settings (the spanner icon) → General → Upgrade Software:
Now your complete it is time to start checking out what is new... but that's a whole different blog post!
anthonyv 2000004B9K Tags:  ds8300 wwpn ioport ds8100 pprc said ds8800 2 Comments 7,570 Views
For some time I have maintained a document that details how to determine a WWPN for most common examples of Fibre Channel storage sold by IBM. This document is really useful when you're staring at a WWPN being reported by a Fibre Channel switch or device and you're trying to work out which port on your IBM Storage it comes from. It's great for when you're performing zoning, creating a build document or setting up mirroring between .
Version 6.4 is now online and can be found here:
You can also find and download it from :
One of the changes referenced in the new WWPN determination document is a corner case you might encounter if setting up mirroring from a or to a new DS8800, but only where the DS8800 has 8 port host adapters and where the mirroring is to the lower ports of that adapter. If I have lost you already, then the following document will not interest you. However if you need to configure such an environment, check out my document detailing a variation in the way the adapter ID is reported, which you can find here.
Wordpress (where I mirror this blog) as a blogging platform has some very nice features. One of them is that you can find out what search terms led people to your blog. I have noticed that searches like these have become very common:
This suggest to me that people are having trouble finding these files, or more importantly: maybe Google is having trouble helping them to find them!
The reason is simple: They have been moved to IBM FixCentral rather than being posted on separate easily trawled web pages. The good news is that once you know about Fix Central, finding any file becomes very very easy.
First up you HAVE to bookmark this URL (Do it now! Yes NOW!):
Now open Fix Central and follow your nose.
When you hit Continue, it should take you to this URL:
This page contains every possible download for XIV including the XIV GUI, the HAK, the IBM Storage vCenter plugin and the ibm_vaaip_module VAAI driver.
Of course if you're looking for Storwize V7000 downloads you should hit the same site but choose the Storwize V7000 product instead of XIV. This should take you to a link like this one:
The good news is that every IBM Storage product is moving into Fix Central so you will be able to work off a central repository for all IBM Storage related downloads.
One of the many popular features of the XIV is the ability to replicate using iSCSI. On XIV Gen3 there are now at least 10 and up to 22 active iSCSI ports on each machine (depending on how many modules you order).
Implementation of the iSCSI connection between two XIVs is a piece of cake. If both XIVs are defined to the XIV GUI (which they should be), you just need to drag and drop links between XIVs to bring the iSCSI mirroring connections alive. If the network gods are with you, the link goes green. But... if the networking gods are against you... the links staysred and then the question is... what to do?
Old fashioned problem diagnosis leads us straight to the ping command. However I routinely find that the ping command works fine (all interfaces respond), but the link stubbornly remains red.
The first possible problem is that iSCSI uses TCP port 3260, so hopefully there are no firewalls blocking that port.
The second possible problem is the MTU size (Maximum Transmission Unit). When we define the iSCSI interfaces on the XIV we set the MTU as a value of up to 4500 bytes. When we establish connections between two XIVs, each XIV will send test packets that are sized to the MTU. If the intervening network does not support that packet size, the packets will be dropped by the network, because the XIV sets the don't fragment flag to ON.
So how to work out what the MTU is? Well the first thing to do is ask your friendly networking team member. But sometimes I find that the intervening networks are controlled by third parties, which means that getting a straight (and reliable) answer can prove difficult. Even worse, some of these third parties charge a fee every time you call them, so there may be hesitation to even get them involved!
One simple trick is to re-use the ping command but play with payload sizes. We can use a command that looks like this:
ping -f -l 1472 192.168.0.1
That command sends a ping with a payload of 1472 bytes to IP address 192.168.0.1. We add the -f parameter to prevent packet fragmentation. What you then do is slowly increase the payload until you no longer get a reply.
This process works fine and is great way to determine the maximum payload size the end to end network will support. However if you're using the payload size to determine the maximum transmission unit, there is a little trick. The MTU is the maximum packet size, but a ping sends a payload wrapped in 28 bytes of IP and ICMP headers. So our example:
ping -f -l 1472 192.168.0.1
sends a 1500 byte frame to the 192.168.0.1 IP address (1472 bytes of payload and 28 bytes of headers.
If this command succeeds, you can use an MTU of 1500 in the XIV GUI or XCLI (rather than an MTU of 1472, which is 28 bytes smaller).
For those who are wondering how I did the networking sniffing to get the screen captures above, I used a brilliant piece of freeware software called Wireshark. My only warning is that your corporate security policies may have rules on sniffing the network. Don't take my blog post as permission to use it # And for the networking geeks among you, yes I know that extra packets could actually be wrapped around our ethernet packet for things like VLAN tags or encapsulation, but hopefully this should not affect our mathematics.
Controlling the background traffic
Final pointer. Having finally gotten the link up and going, you are now free to start replicating volumes. But how much traffic can the cross site link support? The XIV can limit the background copy bandwidth with a parameter called max_initialization_rate. This is useful to stop you flooding the cross site link and annoying your link co-tenants. To display the current setting, open an XCLI window and issue the following command:
For each target you should see three parameters:
<max_initialization_rate value="100"/> <max_resync_rate value="300"/> <max_syncjob_rate value="300"/>
These three settings should be tuned to reflect the possible throughput of the cross site links.
To change the settings use a command like this (change the target name and the rates to suit):
target_config_sync_rates target="Remote_XIV" max_initialization_rate=120 max_syncjob_rate=240 max_resync_rate=240
If you want to see the current throughput rate, open XIV Top on the remote machine. You should see how much write I/O is being sent to the mirror target volumes in MBps.
So hopefully your now better positioned to diagnose iSCSI link issues, maximize your MTU and tune and monitor your link speed.
Questions? Fire away...
I just discovered that you can find freaky blue aliens wearing sun-glasses in release 3.0 of the XIV GUI.
Just go to the Users icon (the padlock) and take the option to Add User Group. I think you will find the new grouped users icon rather amusing. I don't know if I prefer the dude with sunglasses or the two faceless people behind him (or her... or it).
Here are two groups I created, inspired by the icon:
If your running in demo mode and you want to have a closer look, just go to the padlock icon on the XIV Demo2 machine.
You gotta love that icon... #
Actually.... the purpose of groups is to let you group together users in the Application Admin category who manage the same hosts. Application Admin users can only work with hosts that are assigned to them. This limits their access to only the volumes that are mapped to those hosts. A great (and safe) way to hand out user-ids to say SAP developers who want to snapshot as they go. With the added bonus of a cool spaceman icon.
When your buying a car it's worth opening the boot (that's the trunk for my American friends) and looking at the spare to see what kind it is. Car manufacturers sometimes choose to sacrifice a full spare to save space (or cost). I can understand the motivation, but there is nothing worse than having a flat and then finding that your spare is half the tyre you expected it to be.
With low end fibre channel switches there is a similar challenge when working to achieve the lowest cost and smallest footprint in a 1U form factor. The main way it expresses itself is with power supplies.
The IBM SAN24B-4 (a 24 port switch) is a case in point as it only has one fixed power supply. This of course means that if that power supply fails, then that switch will be down and the entire unit will have to be replaced. If you have dual fabrics (two switches) with dual pathed hosts, then this should not cause an application outage, but it may not be what you expected. You also need to ensure that each switch is connected to a different power rail (and/or UPS) to cater for building power issues.
How to avoid this? Purchase the slightly larger IBM SAN40B-4 (a 40 port switch) which comes with two hot swap power supplies as standard. It's a little more expensive (which makes sense as it has more ports and more hardware) but also offers redundant power and greater scaleability.
Of course in the end you need to select the switch which matches your budget. The SAN24B-4 starts at only 8 ports active while the SAN40B-4 starts at 24 ports active, so the SAN24B-4 will always be a cheaper purchase. The SAN24B-4 is also much smaller, lighter (it weighs 4.35 kg versus 9.34 kg) and uses less power (48 W versus 84 W).
My preference? Well I would always choose to use a switch with dual redundant hot-swappable power supplies, but then I am not the person signing the cheques. What I would suggest is that if you choose the SAN24B-4 then you need to ensure your backing up your switch config (especially if your running single switch fabrics). You could look atSimply-Save-Your-SAN as one way to do this.
And no... that is not my car. By shear synchronicity I was thinking about this issue when I spotted this car in the carpark at Southgate. Timing is everything.
Hopefully if your were in Melbourne last week you made it to the IBM Pulse 2011 conference at the Crown Promenade. It was a great success and with 850 attendees, the facilities were packed, especially the main hall.
My highlights? Well apart from visiting the IBM developerWorks stand and getting a free IBM floppy disk T-Shirt...
... it was listening to customers. There were 14 customer case study presentations where attendees could hear real world experiences from real world customers. For the storage track we were lucky to have Angus Griffin from Edith Cowan University talking about how they use IBM solutions including IBM SVC with VMware SRM, to build their Disaster Recovery solution. Angus is a great presenter who used a sort of Takahashi MethodPowerPoint deck where each slide was just one sentence. Below is an example. Can you guess what he was talking about?
I presented on Storage Virtualization and the Storwize V7000. You can check out my presentation on Slideshare. I have struggled for some time to match my presentation style to the sort of material that IBM produces. I am working to a more pared back approach. If you view this presentation on my Slideshare channel you will also get some speaker notes.
The other client who presented in the storage track, was Richard Whybrow from Hertz Australia. Richards presentation on how Hertz use IBM solutions to manage their backups and encryption requirements was short and to the point. But the highlight was Richard's movies. I want to point you to two of them which you can find on his Youtube channel. The first one is hilarious.... here is the SAL 9000 restoring 1.6 TB of data in seconds!
If your looking for something slightly more serious, here is Richard's winning entry to theIBM Tivoli Software Products Rock competition. Richard is sitting at Southbank, close to the IBM Building here in Melbourne. There is also a great shot of Melbourne's Flinders Street Station at the end (as well as a tribute to the film Minority Report)
I wrote a blog post recently about my favourite podcasts. One of those I listed wasBackground Briefing, a radio program broadcast by the Australian Broadcasting Corporation (Australia's ABC). A recent episode entitled Fatigue Factor really sparked my interest. It talked about the affects of fatigue on professions such as:
It contained some alarming facts about the potential affects of fatigue and is well worth taking the time to listen to. However in my opinion there was one major omission:
For many years I worked as the Account Engineer for several of IBM's System z customers, mainly banks. Most weekends I skipped Saturday night as a sleep night. If I was lucky I might get to sleep from 10pm to 1am and would then head off to vast, noisy, dehydrating air conditioned computer rooms to perform various system changes. If I did my job well, had no hardware issues and the client confirmed everything was running as expected, I got to head home about 7am on Sunday. So that night I would have slept somewhere between zero and three hours. I would then spend the rest of the week recovering, before doing it all over again the following weekend at a different customer.
I mention all of this because fatigue was something I learnt to live with. Even when I moved to a support role, I still occasionally worked through the night on critical situations (something IBM calls Crit Sits). I also worked on a support roster which could involve 3am callouts to assist my fellow IBMers across the Asia Pacific region. So when I later moved to a Pre-Sales role, it certainly did wonders in helping me re-establish normal sleep patterns.
Listening to this podcast really brought home to me that the IT industry is just as guilty of failing to deal with fatigue, as the other industries that the podcast discusses. Now if your thinking this means it's an IBM problem, think again. Most weekends I was working alongside representatives from EMC, HDS, Storagetek, etc. Plus of course there were the clients themselves, many of whom were also missing a nights sleep to satisfy their change and business requirements.
One of the major issues raised in the podcast is that there is no accepted way to measure how fatigued an employee actually is. This is a major problem. There are established tests to confirm how affected someone is by alcohol, or by drugs. But we cannot easily confirm how badly fatigued a worker is; plus many people are unwilling or unable to admit that they are suffering from fatigue
If we think about many of the major IT related outages that have occurred recently, I ponder what role fatigue played in each one. Even if it didn't cause the initial issue, did making your employees work around the clock to resolve an issue, actually extend the outage time? For example, have a read of Amazons explanation of its recent Service Disruption. Just picking on some of the lines in the report:
At 12:47 AM PDT on April 21st, a network change was performed...
Was the person doing the change working out of their usual sleep pattern? Was the team working to resolve the issue working out of their normal sleep pattern? Did fatigue compound the outage? Its an interesting idea. Now it may well be that fatigue hadNOTHING to do with this outage. It is pure speculation on my part. But I am certain that the root causes of many of the recent IT meltdowns and their extended after affects (such as Sony's ongoing issues), MUST include the debilitating affects of fatigue.
Plus here is another rather disturbing fact. To quote from the podcast:
... if you're sleep deprived, you're more likely to crave chips over lettuce, and feel less like climbing the stairs. And that can become a vicious cycle, because many people who are overweight are even more prone to sleep disorders....
Many months ago I set up my WordPress blog (this is not the one your reading now, but the mirror of this blog I maintain over at Wordpress). One of the configuration choices I had was to enable a mobile version of the site. This setting changes the user experience when using a mobile device. It was a very easy thing to set up:
The difference between the mobile version and the non-m0bile version is fairly stunning as can been seen below, both views from an iPhone 3GS. The mobile version is on the left and the non-mobile version is on the right. Note that there is no difference in the selected URL:
In March, WordPress added a new feature from Onswipe to allow Apple iPad users to have a more iPad friendly user experience. You can read the announcement on Onswipe's blog. Again for the content creator (me), the work to set to this up was practically non-existent, in fact I don't even recall having to turn it on.
And the result? If you visit my blog on an iPad, the look and feel is amazing. It grabs the first image from each blog post to build a really nice front page. It means I will have to take more care with my opening images!
Now the obvious question is: What about Android? If I check the WordPress FAQ found here, it says that support is coming.
So if you like the look of the mobile version, feel free to switch to using my Wordpress blog. It contains all the same posts and is found here:
I started my IBM career with very dirty hands.
Every day I would go to work and come home smeared with toner, ink, grease and oil.
No I didn't work for a newspaper or in a garage... I worked for IBM, fixing cheque sorters and printers. This was the late 1980s and early 1990s. The years I spent working on IBMs 3800 and 3825 printers and 3890 cheque sorters were great years. I loved working with my customers and I loved working on those big machines. It was lots of fun... but there were lots of ways to get dirty.
What were these machines? Well for one, the IBM 3800 was the worlds first commercial fan-fold laser printer (released in 1975!). Here is a picture, but I would point out that this 3800 looks remarkably clean:
The 3890 Cheque Sorter was an enormous document processor that could move 2400 cheques per minute. For even better clothing destruction, the 3890 has an ink jet printer that used a special ink that you could easily remove from any garment - provided you used a pair of scissors. As for the IBM 3825 Page Printer, it used Charged Area Development, which without very regular maintenance, could result in huge amounts of toner wandering around inside the machine. No wonder the acronym for that technology is CAD.
And yet in all of this... I wore a suit and tie to work... every day... and I always wore a white shirt. It was an IBM standard that had existed for a very long time. People who turned up for work in a non-white shirt had better be a top performer and only the most remarkable or safety conscious turned up for work wearing something that is now rare in the workplace: The Bow Tie.
The only other IT organization I knew that was just (if not more) obsessed with suit and tie? EDS.
As for the System 38 utopian image below.... thats not me on the right! I never wore tan trousers or short sleeves to work. (Check out the size of those monitors!).
Things changed in the mid 1990s. Suddenly we didn't need to wear a tie. Some of us started wearing corporate branded polo shirts. Times had changed and we changed with them. One irony is that I now regularly wear black business shirts to work, something that I would never have gotten away with in 1990. Yet today the closest I come to toner is when I go and get a printout from the printer.
If your interested in seeing some great photos of how IBMers used to dress, visit the IBM History exhibit here: "The way we wore: A century of IBM attire". You could also head over to IBM's 100 Icons of Progress and in particular visit The Making of IBM to see Thomas J Watson Snr looking very smooth indeed.
I was brought to reminiscing about this when visiting a client on a friday. Friday has become casual clothes day at many organizations. And yet given how far we have come... I am pondering why we bother? In comparison to 20 years ago, every day is casual clothes day. Perhaps its time to put aside the polo shirts and bring back the bow tie? As Dr Who says "Bow Ties are Cool"
So are you with me? Bow Tie Friday?
Comments always welcome.
Back from a short break (for Easter and the School Holidays) to three great pieces of news:
Ok... maybe the Royal Wedding has no place in my blog, but the VAAI link is very appreciated.
Two ways to get to the driver:
Remember, your XIV needs to be on 10.2.4a firmware, so you need to be talking to your IBM Service Representative to schedule a concurrent firmware update before you turn the VAAI functions on.
Now if your going, um... what is VAAI and how does it help? Check this blog post out:
If your asking, hey what else will 10.2.4a code bring me?
The XIV 10.2.4 release notes report performance improvements that are worth investigating. Two of the reported improvements listed are:
I visited a client running 10.2.4 to see if these could be detected in the XIV performance statistics. In this clients case, the upgrade occurred on Feb 14. First up I wanted to show that in the period I am examining there was no major variation in write IO. In other words, before and after the code load, I wanted to confirm the client performed the same level of IO.
Having confirmed that the write IOPS did not vary over the period in question, did the latency change? Here we have some good news. Firstly the latency for Write Hits improved (slightly). A write hit is a write into a 1MB partition that already has some data in cache. It is faster than a write miss because some of the address allocation work has already been done. Write hits and misses both hit cache as I explained here. You can see a change on Feb 14 (when the code was updated):
I then looked at the latency for write misses. Again the latency dropped. This suggests that cache operations in general are being handled faster.
I then started thinking.... are we getting more write cache hits? The answer was YES! This is curious because the client normally does not have much control over where they actual write data to... Clearly the XIV firmware is managing the write cache in a more efficient manner. This is good not only because write hits normally have lower latency than write misses, but also because a write hit can save us destaging a block of data to disk. This is because a write hit could involve over-writing data that had not yet been destaged to disk. So two writes to the same LBA would only result in one write to backend disk.
So in conclusion, the upgrade to 10.2.4 code resulted in a measurable improvement in write IO performance at a real world client. Nice!
A friend of mine sent me a direct message on Twitter that pointed out something interesting.... A blog post I had written on SDDPCM had been copied word for word by another site. A little bit of googling revealed that in fact it had been picked up by two sites. Here is the original, and the copies are here and here.
What bothered me was not that the content was copied without any obvious (well, obvious to me) attempt to acknowledge the original author. In fact in both cases, the copied text included a link to another blog entry I had written, so an alert reader would pick up that the content had come from someone else (still... a little acknowledgement doesn't hurt). To begin with, I was also not concerned with the re-use of my work. After all, I am writing this to be helpful, so if you think something I have written is helpful... and you spread the word... that work is even more helpful (but hey thats what Twitter is for... right?). But then it occurred to me....by copying the article without a link back to the original source (mine), if I find a mistake is made and I update my blog post, those corrections will not flow to the clones. So this potentially undermines my efforts to be helpful.
I also noticed that in each case, the clones had advertisments by Google. Does this mean Google and/or these other bloggers, are actually making money from copying my content?Hmmm... acknowledgement is one thing... a cheque is even nicer.
Still... message to Anthony... if you push content into the public domain you have to be prepared for this.
After tweeting about this, I did learn it is possible to insert sentences into your content that you could then monitor for with Google Alerts. I don't plan to do this myself, but its certainly worth being aware of. This of course also presumes the cloners don't detect these sentences and delete them.
I am very curious to know of similar experiences. Has this happened to you? Did you do anything about it? Were you happy with the result?
As I blogged previously, VAAI support for XIV has two dependencies:
Both of these things are very close to release....
And what is the affect?
VAAI dramatically reduces the amount of work that the vSphere 4.1 server needs to do to get things done.
The XIV implementation of VAAI provides the three fundamentals of VAAI:
To test VAAI with XIV, I did two things: a VMDK migration (a Storage Vmotion) and VMDK cloning. I used the vSphere client to time how long the operation took and XIV Top to see how much IO was being generated by the vSphere server. Now please understand, these numbers and timings are based on a lab environment. The speed and peaks will vary from client to client and install to install.
Firstly the migration: I performed a migration of a VMDK from one data store to another. The migration without VAAI took 42 seconds as can be seen from the screen capture below:
The migration generated a peak of 135 MBps of traffic being written to the target volume as can be seen from XIV Top:
I then turned on VAAI and did the same migration. I won't document the process to install the VAAI driver, as it will be different when the certified version is released. However after the driver is installed, I could turn VAAI on and off by toggling these settings from 0 1 and back again:
I we did another VMDK migration with VAAI enabled. This time the migration took 19 seconds (as opposed to 42 seconds), so an immediate improvement occurred.
When I checked XIV Top, there was no IO at all! In other words the vMotion was done with no apparent load on the vSphere HBAs or the SAN. I feel silly showing this screen capture, but this is what I saw.... nothing.
I then did a VMDK clone. The Data store was on XIV, VAAI was not enabled. There was no other IO running on the ESX server. The clone took 40 seconds (as reported by vCenter):
The clone generated a peak of 2 MBps for around 20 seconds (as reported by XIV Top). Almost no fibre channel IO was thus generated by the clone.
As I have blogged before, I will be repeating this whole exercise once I have real live customers running this configuration, so expect further updates.
Things have been pretty revolting lately, and I am not talking about Tunisia or Egypt or Libya (thought actually they could equally apply to my story).
What I am talking about is mother nature, and she is pretty angry with us right now.
In the last few months Australia and New Zealand have seen massive floods in Queensland, Victoria and Western Australia, destructive cyclones hitting Queensland and Western Australia, ferocious bush fires in Western Australia and most recently, a massive earthquake in New Zealand.
The personal loss of life and of property have been shocking and tragic. Each of these events have reminded me how quickly everything we hold dear can be taken away in an instant... by an event over which you have no control.
Which leads me to storage clouds....
If something can be stored electronically, then it can be stored in a cloud. A cloud that is hopefully well backed up, and far away from your own personal location. And no this is not an advertisement... its a suggestion....
Given the events of the last few months, I have started using a storage cloud provider to protect my photos, my music and my insurance information.
I looked for cloud storage providers who:
I considered the following uses:
Let me give you an example of a document I would never want to have to replace....
My son is practicing to get his drivers license. In Victoria you need 120 hours of driving experience recorded in a log book. This log book needs to be filled in every time he drives the car. If the log book is lost... those 120 hours would need to be driven again. I cannot tell you how hard it is to find 120 hours of driving opportunities (and I heartily support the 120 hours scheme!). Even if you did feel inclined to create fake entries to recreate the book (which is illegal), frankly creating 120 hours of fake driving log entires would be very hard work. To make things worse... where I am storing this booklet? In the car of course (which is the most convenient place to store it). So what happens if the car is stolen? There goes the logbook.... So the plan I work on is that every time a page is filled up, I scan that page as an image stored on my laptop. The image goes into a folder that is automatically backed up to the cloud. Yes it does depend on my being diligent, but the actual process of copying the file somewhere else is automatic. Now I have 3 copies... the original, the scanned image on my laptop and a third (automatically created) copy way off in the cloud somewhere.
As for personal recommendations:
1) Get 2 GB free on Dropbox. This is a great point solution and a great way to dip your toes in.
Have there been issues with storage cloud providers? A quick search reveals stories like: Flikr deleted a users data and Carbonite lost data due to hardware failure. Still... I have no plans to store my ONLY copy of data in the cloud. For me its a backup medium... not a primary storage location.
Are you convinced?
Oh... and my son? He is on 89 driving hours... 31 to go....
I am starting the week in Adelaide having travelle here to teach an XIV course:
I really enjoy teaching, particularly when the students are coming from a non-IBM background. It gives me the chance to better learn how IBM's products compare to our competitors, because the experiences and view points come from real end users. It also helps me to reconfirm my knowledge and understanding of our own products.
The course consists of a day of lectures and a day of labs (using the XIV Labs inMontpellier France). Here is the course layout.
The idea is to teach all the concepts on day one and then let the students hit real machines in a remote lab environment on day two. The hands on part is always the best bit as far as I am concerned (learning by doing always beats learning by listening). Students who have never touched the XIV GUI always enjoy this part.
A bigger challenge is when you have a student who already has lots of hands on experience. In those cases I work to consolidate what they have already learned.
I am curious, how often do you wait so long to do a course, that there was not much left to learn by the time you actually got to do it?
Its been a while since my last blog entry... but don't worry (if you were). I have not given up on my blog.
I took three weeks off for vacation: to recharge my batteries and reconnect with my family.
It was a great break which sadly had to come to an end.
I have three rules when I go on leave:
The first few days were hard ( without meaning to belittle the concept, its a bit like battling an addiction),
but by the second week I had stopped thinking about work altogether and really started to enjoy myself.
Not that I don't enjoy working for IBM (I love it), but we all need to take regular breaks to stay sane.
Of course there is a penalty for ignoring your email for 3 weeks..... about 1000 emails to go through on return.
The good news is... I am now ready for take off.
Lets have a great 2011!
And if your feeling like this guy, maybe its time for a break!
I was recently asked to travel to Taiwan to teach a Storwize V7000 class.
I have done a fair amount of travel with IBM, but this was my first visit to Taipei.
I must say I loved the energy and enthusiasm of the place.
While there I taught a new course: Storwize V7000 Implementation (SSE01)
For those who are familiar with IT education, IBM Systems and Technology Group (STG) Education comes in 4 forms:
1) Lecture Only
2) Lecture with simulated labs
3) Lecture with remote remote labs
4) Lectures with local labs
This particular course is the third type, meaning it consists of lectures combined with remote labs.
This means we connected via VPN to actual machines located in Raleigh, North Carolina.
We had access to multiple pods, where each pod has its own Storwize V7000, plus a DS3400, SAN switches and hosts running AIX and Windows.
In addition IBM Taiwan secured a demonstration Storwize V7000 for us to have in the classroom (to see and touch and do initial config on).
This was the first time the course had been offered in Taiwan and everyone was very excited to be part of it.
The agenda looked something like this:
• Unit 1 - Introduction to the IBM Storwize V7000
• Unit 2 – Enclosures and RAID Arrays
* Labs: initial config, accessing the GUI and CLI, configuring internal and external storage and defining attached hosts
• Unit 3 – Fabric Zoning
• Unit 4 – Thin provisioning and Volume Mirroring
• Unit 5 – Data Migration Facilities part 1
* Labs: Accessing storage from AIX and Windows hosts via fibre channel and iSCSI, Easy Tier Part 1, migration part 1
• Unit 5 – Data Migration Facilities part 2
• Unit 6 – Easy Tier
• Unit 7 – Managing IBM Storwize V7000
* Labs: Migration part 2, Thin provisioning, RAID options, Easy Tier part 2
By the conclusion of the course the students had had many hours enjoying the new GUI, which I thought was really important.
Hands on operation of a system is the best way to learn.
Those that already knew SVC found the course quite easy, but everyone felt that they had learnt a lot.
The chance to use Easy Tier and do a live migration was really important.
I certainly enjoyed teaching the course and look forward to teaching it again!
For those who live in Australia, yes we are going to offer the course locally.
As soon as I have dates I will share them with you.
I have noticed something suspicious on the developerWorks forum.
Updates are coming from new users where:
Their posts always come in one of three flavours.
1) They create posts with comments like "Thanks for sharing". Here are some examples:
2) They may instead complain about broken links (which are NOT broken), such as these two:
3) Finally, they may kind of ask a question, but without really referring to the material they reference, such as these:
I have sent messages to the majority of these 'people', but so far they have NOT responded, nor do I expect them to.
My long term plan is to simply delete their posts and ban their user ids.
What are they up to? I don't know.
But given that none of their posts ADD anything to the DW forum, I have no fear in REMOVING them.
So I have three requests from my audience:
It could be that I have become unnecessarily paranoid, but this pattern seems to be rather strong.
So the next challenge when connecting your XIV to your AIX LPAR is how to zone the SAN (or hopefully, each SAN fabric).
The XIV consists of a number of modules (from 6 to 15), of which a subset are Interface Modules (meaning they have fibre channel and iSCSI interfaces)
Zone the SAN so that each HBA in an LPAR has 3 paths to the XIV.
If an LPAR has two HBAs, then zone the first HBA to modules 4, 6 and 8 and the second HBA to modules 5, 7 and 9.
For the next LPAR, do the reverse and zone the first HBA to modules 5, 7 and 9 and the second HBA to modules 4, 6 and 8.
If we look at a typical dual fabric 15 module XIV, it would be cabled as pictured below.
Port 1 on each XIV module attaches to Fabric 1
Port 3 on each XIV module attaches to Fabric 2.
Ports 2 and 4 are reserved for replication and mirroring.
But look closely at the use of colours in this lovely Visio diagram I created.
Host 1 is zoned using the links in blue.
Host 2 is zoned using the links in red.
Notice how they round robin between the odd and even numbered interface modules.
Rules of thumb
Because there is some evidence that having excessive paths can slightly raise CPU utilisation.
The other reality is that having multiple duplicate paths won't make your system more reliable.
So your planning to attach your XIV at an AIX host?
Here are some best practices for you to follow.
1) Native XIV detection
The XIV uses a path control module (PCM) that plugs into AIX MPIO. Depending on your AIX level the XIV will be recognised natively by AIX without additional software.
This is nice because it means you can simply run cfgmgr and detect the XIV hdisks without doing any system changes.
If your on the following AIX levels (with TL and SP) then your AIX system will detect the XIV natively. Frankly its a good excuse to perform a system update.
AIX Release APAR Bundled in
AIX 5.3 TL 10 IZ69239 SP 3
AIX 5.3 TL 11 IZ59765 SP 0
AIX 6.1 TL3 IZ63292 SP 3
AIX 6.1 TL 4 IZ59789 SP 0
If your running VIOS, you need to be on VIOS v2.1.2 FP22 to recognise the XIV natively.
Natively detected XIV devices will look like this when displayed using the command:
lsdev -Cc disk