The Storwize V7000 and SVC release 6.1 introduced a new WEB GUI interface to assist with service issues, known as the Service Assistant. The Service Assistant interface is a browser-based GUI that is used to service your nodes. Much of what you traditionally did with the SVC front panel can all be done using the Service Assistant GUI. You can see a screen capture of the Service Assistant below:
While I would like to be optimistic and hope that you will never have to use the Service Assistant, you should always ensure your toolkit is equipped with every possible tool. I say this because one thing I have noted is that the majority of installs are not configuring the Service Assistant IP addresses. This is particularly apparent as clients upgrade their SVC clusters to release 6.1.
By default on Storwize V7000, the Service Assistant is accessible on IP addresseshttps://192.168.70.121 for node 1 and https://192.168.70.122 for node 2 (don't try and point your browser at them right now, as your network routing won't work - you would need to set your laptop IP address to the same subnet and be on the same switch. Details to do that are here). For SVC there are no default IP addresses, although we traditionally asked the client to configure one service address per cluster. The best thing for you to do is approach your network admin and ask for two more IP addresses for each Storwize V7000 and/or SVC I/O group. Once you have these two extra IP addresses, record them somewhere and then set them using the normal GUI.
Its an easy five step process as shown in the screen capture below. Go to the Configuration group and then choose Network (step 1). From there select Service IP addresses (step 2) and the relevant node canister (step 3). Choose port one or port two (step 4) and then set the IP address, mask and gateway (step 5).
You can also set them using CLI (replace the word panelname with the panel name of each node, which you can get using the svcinfo lsnode command).
satask chserviceip -serviceip 10.10.10.10 -gw 10.10.10.1 -mask 255.255.255.0 panelname
If you forget these IP addresses, you can reset them using the same CLI commands or using the Initialization tool as documented here.
Finally having set the IP addresses, visit the service assistant by pointing your browser at each address. This is just to confirm you can access it. You logon with your Superuser password. With the process complete, ensure the IP addresses are clearly documented and filed away. So now if requested, you will be able to perform recovery tasks (in the unlikely chance they are needed). If for some reason your browser keeps bringing you to the normal GUI rather than the Service Assistance GUI, just add /service to the URL, e.g. browse to https://10.10.10.10/service rather than https://10.10.10.10.
So what should you do now?
If your an SVC customer on SVC code version v5 and below, please get two IP addresses allocated for each SVC I/O group, so you can set them the moment you upgrade to V6. Do this once the upgrade is complete.
If your an existing Storwize V7000 client or an SVC client already on V6.1 or V6.2 code, then hopefully you should already have set the service IP addresses. If not, please do so and test them.
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:
- IBM released several alerts regarding how to handle the connection of 8 Gbps capable devices to 8 Gbps capable fibre channel switches.
- Brocade changed their firmware to better handle this situation.
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):
- Load the tape drive with firmware that has the access fairness algorithm fix for loop:
- LTO5 drives should be on BBN0 and beyond (you may need to contact IBM support to get this code.
- TS1140 drives should be on drive firmware 5CD or beyond.
- Change the Fibre Channel topology to point-to-point (N port) (as opposed to L or NL). This is my preferred option.
- Change the Fibre Channel speed to 4Gbps. This sounds slightly retrograde, but it is very rare for an individual drive to sustain a speed above 400 MBps (unless your data is very very compressible).
**** UPDATED 28 Feb 2012 - Added System z FICON and Tape info ****
I recently got a great email from an IBMer in the Netherlands by the name of Jack Tedjai. He sent me two screen shots, taken with the new performance monitor panel (that comes with the SVC and Storwize V7000 6.2 code). He wrote:
I am working on a project to migrate VMware/SRM/DS5100 to SVC Stretch Cluster and one of the goals is to prevent using ISL (4Gbps) and VMware Hypervisor/HBA load during the migration. For the migration we are using VMware Storage vMotion. To minimize the impact of the migration on production, we tested VAAI for Storage vMotion and template deployment and it worked perfectly.
So whats this all about? Well one of the improvements provided with VAAI support is the ability to dramatically offload the I/O processing generated by performing a storage vMotion. Normally a storage vMotion requires an ESX server to issue lots of reads from the source datastore and lots of writes to the target datastore. So there is a lot of I/O flowing from ESX to the SVC, and then from the SVC to its backend disk. What you get is something that looks like the image below. In the top right graph we have traffic from SVC to ESX (host to volume traffic). In the bottom right graph we have traffic from the SVC to its backend disk controllers (DS5100 in this case). This is SVC to MDisk traffic.
When we add VAAI support to the SVC, we suddenly change the picture. Suddenly VMWare does not need to do any of the heavy lifting. There is almost no I/O between VMWare and the SVC (no host to SVC volume traffic) related to the vMotion. The SVC is still doing the work, but it is happening in the background without burning VMWare CPU cycles or HBA ports (in that there is still SVC to MDisk traffic).
This difference translates to: Faster vMotion times, far less SAN I/O and far less VMware CPU being used on this process.
So do VMware support this? They sure do! Check this link here. It currently shows something like this (taken on June 23, 2011):
So what are your next steps?
- Upgrade your Storwize V7000 or SVC to version 6.2 code. Download details arehere.
- Download and install the VAAI driver onto your ESX servers. You can get it from here. If your already using the XIV VAAI driver you need to upgrade from version 126.96.36.199 to version 1.2. There is an installation guide at the same link.
And the blog title? It means friendly greetings in Dutch. So to Jack (and to all of you), vriendelijke groeten and please keep sending me those screen captures.
If your a user of XIV, or your considering purchasing an XIV, then there is one tool that you will truly love. It's called XIVTop. The XIVTop application comes packaged with the XIV GUI and is one of the handiest add-ons I have ever seen. It lets you monitor your XIV in real time, seeing exactly how much IO or throughput is being achieved and at what response time (in milliseconds). You can immediately answer questions like:
- Is poor application response time being caused by poor storage response time?
- What application is currently generating so much traffic on the SAN?
- What effect has performing file de-fragmentation had on performance?
- Are the backups running and how much traffic are they generating?
- What happens when I run multiple application batch jobs at the same time?
The ability to get this information in real time is what makes XIVTop so invaluable.
So in the tradition of always pushing my boundaries, I thought I would create a narrated video about XIVTop. What I discovered is just how terribly hard doing narrated videos are: You need to write a script... you need to stick to the script... you need to not fluff any words.... you need to speak slowly and clearly and not start talking in a strange accent. I had trouble with all of these, so I made take after take after take after take, until I was heartily sick of the process. I have now got a much greater respect for newsreaders and film actors. This narration stuff is hard!
So please check out my final take. It's still far from perfect, but all feedback is very welcome. The only other thing that is quite strange is Youtubes choice of videos to watch after mine. Its worth watching just to see the list. I think the term performance confuses the algorithm.
I joined IBM on June 26 1989, so this Sunday brings up my 22 year anniversary with the company. No small achievement, but I am still three years away from the mystical IBM Quarter Century Club. Of course for some: 22 years is nothing! I recently learned that Robert Neidig, who has been (and remains) a leading light in promoting IBM's Mainframe products, joined IBM on June 21, 1961. So this year bring up his 50th anniversary with the company!
For those with long memories, Bob has worked with the following IBM systems: 1401, 1410, S/360, S/370, 3031, 3032, 3033, 3081, 3083, 3084, 3090, ES9000, S/390, eServer zSeries, and System z. They have all been enhanced by Bob's contributions.
If you want to check out the history of some these world changing products, visit The IBM Mainframe Room. I particularly loved the Photo Album. There are some truly classic images of IBM products of old. If your forward looking, feel free to also visit the System z homepage.
So thanks Bob for your commitment and leadership on your half-centennial, truly a remarkable achievement!
- This is a Severity 1 issue at 2am
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:
- Air Traffic Controllers
- Train drivers
- Truck drivers
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:
It did not mention workers in the IT industry.
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...
At 2:40 AM PDT on April 21st, the team deployed a change...
By 5:30 AM PDT, error rates and latencies again increased ....
At 11:30AM PDT, the team developed a way to prevent....
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....
So please take the time to listen to the podcast. You will find it here and in places likeiTunes.
If your reading my blog, your probably interested in IBM Storage hardware (since apart from Bow Ties, thats all I talk about). So I would hope your already subscribed to IBM's notification service that you will find here. Rob Jackard from the ATS Group (an IBM Business Partner based in the USA) puts together a summary of these notifications which he sends to me on a regular basis. So I am bringing them to you here. Now hopefully none of these alerts are news to you... but please, have a read and if you have not done so already.... SUBSCRIBE!
DS3000 / DS4000 / DS5000:
(2011.06.09) IBM Retain Tip# H202771 – Expanding Dynamic Capacity Expansion (DCE) large arrays may fail due to out of memory conditions.
NOTE: The 7.xx firmware for the DS Storage Controller is affected. This is a permanent restriction. Possible workarounds are available.
(2011.05.27) Documentation: Instructions for opening the IBM System Storage DS Storage Manager interface are incorrect.
(2011.05.25) DS3950 / DS4000 / DS5000 Recommended Firmware Levels.
(2011.05.18) IBM Retain Tip# H202849 – Dynamic Volume Expansion is not possible on a LUN which is in an active mirror relationship with write-mode of ‘Asynchronous not write-consistent’.
NOTE: The DS Storage Controller is affected. A workaround is available.
(2011.05.10) IBM Retain Tip# H202771- Expanding (DCE) large arrays may fail due to out of memory conditions.
DS8000 / DS6000:
(2011.06.07) DS8800 Code Bundle Information.
(2011.06.03) EXN3500 (2857-006) Storage Expansion Unit Publication Matrix.
(2011.05.19) Excessive drive spinning up (0x2 – 0x4 0x1) messages on healthy EXN3000.
(2011.05.05) NEWS: Recommended Releases for IBM System Storage N series Data ONTAP.
(2011.04.28) DataFabric Manager (DFM) 4.0.2 Publication Matrix.
(2011.05.10) Cisco MDS Field Notice: FN-63416 – DS-C9124 & DC-C9148 have incorrect MAC Programming; UMPIRE Program in Place.
(2011.05.19) Intel has reported PAGE FAULT OR CORRUPTED DATA USING 64-BIT APP IN 64-BIT NOS (Fix is Now Available).
SVC / Storwize V7000:
(2011.06.10) IBM SAN Volume Controller Code V188.8.131.52.
(2011.06.10) IBM Storwize V7000 Code V184.108.40.206.
(2011.06.10) SAN Volume Controller and Storwize V7000 Software Upgrade Test Utility V6.5.
(2011.06.10) IBM Storwize V7000 Initialization Tool.
(2011.06.10) Storwize V7000 Concurrent Compatibility and Code Cross Reference.
(2011.06.10) IBM Storwize V7000 V6.2.0 – Installable Information Center and Guides.
(2011.06.10) IBM System Storage SAN Volume Controller and Storwize V7000 V6.2 – Command-Line Interface Guide.
(2011.06.10) IBM System Storage SAN Volume Controller and Storwize V7000 V6.2 – Troubleshooting Guide.
(2011.06.10) Incorrect Usage of Drive Upgrade Command May Cause Loss Of Access to Data.
NOTE: This issue was resolved by APAR IC74636 in the V220.127.116.11 release of the Storwize V7000 software.
(2011.06.10) Storwize V7000 and SAN Volume Controller FlashCopy Replication Operations Involving Volumes Greater Than 2 TB in Size Will Result in Incorrect Data Being Written to the FlashCopy Target Volume.
NOTE: This issue is fixed by APAR IC76806 in the 18.104.22.168 and 22.214.171.124 PTF releases.
(2011.06.08) IBM SAN Volume Controller Code V126.96.36.199.
(2011.06.08) IBM Storwize V7000 Code V188.8.131.52.
(2011.05.27) IBM SAN Volume Controller Code V184.108.40.206.
(2011.05.27) IBM Storwize V7000 Code V220.127.116.11.
(2011.05.27) Storwize V7000 Systems Running V18.104.22.168-V22.214.171.124 Code May Shut Down Unexpectedly During Normal Operation, Resulting in a Loss of Host Access and Potential Loss of Fast-Write Cache Data.
NOTE: If a single node shutdown event does occur when running V126.96.36.199, this node will automatically recover and resume normal operation without requiring any manual intervention. IBM Development is continuing to work on a complete fix for this issue, to be released in a future PTF, however customers should upgrade to V188.8.131.52 to avoid an outage.
(2011.05.09) SVC V4.3.x End of Service – April 30, 2012.
SSPC / TPC / TPC-R:
(2011.06.10) Administration of the TPC Environment: A Guide for TPC Administrators.
(2011.06.08) TPC4.2.x - Supported Storage Products Matrix.
(2011.06.08) TPC 4.1.x – Supported Storage Products List.
(2011.05.23) Shutdown sequence for TPC for Replication.
(2011.05.19) Fabric probe causes instability in Brocade DCFM server.
NOTE: Brocade Defect 332161 has been identified and is resolved in DCFM version 10.4.5.
(2011.05.19) Configuring Oracle for TPC for Databases.
(2011.05.17) TPC web browser support – Firefox 4.x and Internet Explorer 9.
(2011.05.06) TPC- Resolving Issues with Cisco Switches.
(2011.05.05) How to resolve TSPC Server service start problems when TIVGUID is mistakenly uninstalled.
(2011.04.29) Tivoli Storage Productivity Center v4.1.1 Fix Pack 6 (April 2011).
(2011.04.29) TPC database size increases after upgrade to 4.2.1.
(2011.06.09) IBM XIV Host Attachment Kit for AIX v1.6.
(2011.05.24) Potential Problem on XIV Storage System ranging microcode versions 10.2.2 thru 10.2.4.a that can be caused by changing system time via Network Time Protocol (NTP) or when changing the clock via XCLI.
(2011.05.10) IBM XIV Storage System Planning Guide.
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.
- The Storwize V7000 release of the 6.2 code is here.
- The SVC release of the 6.2 code is here.
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 184.108.40.206.
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?
- The top left hand quadrant is CPU utilization.
- The top right hand quadrant is volume throughput in MBps as well as current volume latency and current IOPS.
- The bottom left hand quadrant is Interface throughput (FC, SAS and iSCSI).
- The bottom right hand quadrant is MDisk throughput in MBps as well as current MDisk latency and current IOPS.
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).
I recently created a post about the XIV Host Attachment Kit (amusingly called the HAK). IBM has released an update to the HAK, taking us from version 1.5 to version 1.6. The updated versions, along with release notes and installation instructions can be found at the following links:
IBM XIV Host Attachment Kit for AIX, Version 1.6
IBM XIV Host Attachment Kit for HP-UX, Version 1.6
IBM XIV Host Attachment Kit for RHEL, Version 1.6
IBM XIV Host Attachment Kit for SLES, Version 1.6
IBM XIV Host Attachment Kit for Windows, Version 1.6
Whats changed you asked? Great question! Checking the Release Notes for each Operating System (which can be found in the links above), I found some common improvements to the HAK for every OS:
- The xiv_diag command now provides the HAK version number when used with the --version argument. This is handy to confirm what version of HAK you are currently running.
- More information is collected with the xiv_diag command.
- The xiv_devlist command can now display LUN sizes in different capacity units, by using the –u or --size-unit argument. I give an example below.
Usage: -u SIZE_UNIT, --size-unit=SIZE_UNIT
Valid SIZE_UNIT values: MB, GB, TB, MiB, GiB, TiB
- The xiv_devlist output can be saved to a file in CSV or XML format, by adding the –f or --file argument. I give an example below.
There are also several other fixes which are mainly common between Operating Systems. Given that a major part of the HAK are Python scripts such as xiv_attach, xiv_devlistand xiv_diag and given that the output and behaviors of these script are very similar for each OS, this is not surprising.
I installed the new version 1.6 HAK onto my 64-bit Windows 2008 server and found another pleasant surprise: When I ran the xiv_attach command it detected that my Qlogic driver was downlevel. In this example it detected I am running a Qlogic QLE2462 on driver version 9.18.25 and suggested I should instead run driver version 9.19.25.
I then tried out the xiv_devlist command, displaying volume sizes in both decimal (GB) and binary (GiB). Note the syntax I used to get the GiB output: xiv_devlist -u GiB
Finally I offloaded the output of the xiv_devlist command to a CSV file. Again please note the syntax as you may find it useful:
xiv_devlist -t csv -f devlist.csv -u GiB
You could use -t xml instead of getting CSV output. Clearly you could also change the file name devlist.csv to any filename you like.
You do not need to worry about which version of firmware your XIV is running. The release notes confirm HAK version 1.6 will work with XIV firmware 10.1.0, 10.2.0, 10.2.2, 10.2.4 and 10.2.4a, which should cover pretty well every machine in the world.
One final note: Under Known Limitations the release notes state that you should not map a LUN0 volume. This simply means leaving LUN0 disabled (which is the default). In the example below I start mapping volumes from LUN1 and have NOT clicked to enable mapping of volumes to LUN0. This should be the norm.
Any confusion or questions? You know where to find me.
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:
With Brocade's recent announcement of a 16 Gbps capable Fibre Channel Switchand Director, the question of which cable type to purchase becomes even more relevant. Do you buy OM3 or OM4 cable over OM2?
Now if your saying... OM-what? Let me start at the beginning...
Back when fibre channel was fresh and new and ran at 1 Gbps, the common multi-mode fibre cable that we used had a glass core that was 62.5 microns in diameter. This became known as OM1 type fibre cable. We rapidly switched to 50 micron cores because you could get a reliable signal across a longer distance, say 500 meters maximum rather than 300 meters. The 50 micron cable became known as OM2 type cable.
What has happened since then is that fibre channel speeds have moved from 1 Gbps to 2 GBps to 4 Gbps to 8 Gbps to 16 Gbps. This is exciting stuff, but with every increase in speed, we suffer a decrease in maximum distance. This means that something else needs to change... and that something is the quality of the cables, or more specifically, the modal bandwidth (the signalling rate per distance unit).
With the evolution of 10 Gbps ethernet, the industry produced a new standard of fibre cable which the fibre channel world can happily use. Its called laser optimized cable, or more correctly: OM3. Since then OM3 has been joined by an even higher standard known as OM4.
Lets look at the distances we can achieve with different cable types. You can see in the table below that the modal bandwidth (given in MHz times kilometers), improves as we move to higher quality glass. You can also see that single mode fibre (with the 9 micron core) has not suffered the same issue with decreasing maximum distances as speeds have increased. These numbers come from Brocades SFP specification sheets found here andhere (so there may be slight variations if you view specs from other vendors).
I didn't fill in the table for 1 Gbps and 2 Gbps using OM4 cable, simply because I couldn't find it... but the distances would be very large indeed.
So how can you tell what sort of cable you have? The first hint is the colour, the second is the printing on the cable. Cables that are 50 micron and orange are almost certainly OM2. Cables that are aqua in colour (don't call them green!) are either OM3 or OM4. In the example below I can clearly tell which cable is OM3.
Pictured below is a roll of OM3 cable, all ready for deployment with standard LC connectors. Note you can also get OM3 cable with a smaller LC type connector used on the mSFPs in the high density 64 port blades in the Brocade DCX. You can find additional information on identifying cables here.
So should you be buying OM3 cable over OM2? Or even considering OM4?
The reality is that in many cases, server and storage hardware is often in the same or adjacent racks to the switch hardware. If this is true for your site, OM2 will satisfy the vast bulk of requirements, because the distances are quite short. The most common cable I add to configurations is either 5 or 25 meters long. This is why OM2 is still IBM's cable of choice, since either length would satisfy 16 Gbps connectivity. Checking with some local cable vendors, OM2 cable also remains the cheaper alternative.
Clearly if your computer room is large enough to need cable runs of over 35 meters, then serious consideration should be given to future proofing parts of your cable infrastructure with OM3 (or even OM4). There is nothing wrong with having a mix of cable types - just don't join them together.
I would be curious to know how many sites are choosing to move to OM3? Feel free to comment either way. I think there will be more to come on this subject, and remember.... OM3 and OM4 cables are aqua not green or blue. #.
Would love to hear about your sites recent cabling purchases.
And if the word Aqua reminds you of a late 90s Scandinavian pop group, look no further:
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.
There was a time when 32 bits was considered a lot. A hell of a lot.
With 32 bits, you can create a hexadecimal number as big as 0xFFFFFFFE (presuming we reserve one bit).
In decimal that's 4,294,967,295. Hey... imagine a bank account balance that big?
If you use 32 bits to count out 512 byte sectors on a disk, you could have a disk that's 4,294,967,295 times 512... or 2,199,023,255,040 bytes! That's sounds huge, right?
Well... actually...no... that's 2 TiB, which most people would refer to as 2 Terabytes. Mmm.. Suddenly I am less impressed (still wouldn't mind that as a bank account though).
Now there are plenty of running Systems that still cannot work with a disk that is larger than 2 TiB. One of the more common is ESX. I am presuming this limitation is going to disappear, so Storage susbsystems need to be ready to create volumes that are larger than 2 TiB.
The good news is that with the May 2011 announcements, IBM is removing the last 2 TiB sizing limitations from its current storage products. There appears to have been some confusion in the past, so I thought I would go through and be clear where each product is at:
Firmware version 07.35.41.00 added support to create volumes larger than 2 TB. The maximum volume size is limited only by the size of the largest array you can create. This capability has been available for some time and hopefully you are already on a much higher release.
DS4000 and DS5000
Firmware version 07.10.22.00 added support to create volumes larger than 2 TB. The maximum volume size is limited only by the size of the largest array you can create. This capability has been available for some time and hopefully you are already on a much higher release.
DS8700 and DS8800
The DS8700 and DS8800 will support the creation of volumes larger than 2 TB once a code release in the 6.1 family has been installed. With this release you will be able to create a volume up to 16 TiB in size. The announcement letter for this capability is here.
The volume size on an XIV is limited only by the soft limit of the pool you are creating the volume in. This allows the possibility of a 161 TB volume.
SVC and Storwize V7000
These two products have two separate concepts:
- Volumes (or VDisks) that hosts can see.
- Managed disk (or MDisks) that are presented by external storage devices to be virtualized. Within this there are two further categories:
- Internal MDisks created using the Storwize V7000 SAS disks.
- External MDisks created by mapping volumes from external storage (such as from a DS4800).
SVC and Storwize V7000 Volumes (VDisks).
Prior to release 5.1 of the SVC firmware, the largest volume or VDisk that you could create using an SVC was 2 TiB in size. With the 5.1 release this was raised to 256 TiB, as announced here. When the Storwize V7000 was announced (with the 6.1 release) it also inherited the ability to create 256 TiB volumes.
Storwize V7000 Internal Managed Disks (Array MDisks).
Because the Storwize V7000 has its own internal disks, it can create RAID arrays. Each RAID array becomes one Mdisk. This means the largest MDisk we can create is limited only by the size of the largest disk (currently 2 TB), times the size of the largest array (16 disks). This means we can make arrays of over 18 TiB in size (using a 12 disk RAID6 array with 2 TB disks). Thus internally the Storwize V7000 supports giant MDisks. We can also present these giant MDisks to an SVC running 6.1 code and the SVC will be able to work with them.
SVC and Storwize V7000 External Managed Disks.
When presenting a volume to the SVC or Storwize V7000 to be virtualized into a pool (a managed disk group) we need to ensure two things are confirmed. Firstly you need to be on firmware version 6.2 as confirmed here for SVC and here for Storwize V7000. Secondly that the controller presenting the volume has to be approved to present a volume greater than 2 TiB. From an architectural point of view, MDisks can be up to 1 PB in size as confirmed here, where it says:
|Capacity for an individual external managed disk|
|Note: External managed disks larger than 2 TB are only supported for certain types of storage systems. Refer to the supported hardware matrix for further details.|
I recommend you go to the supported hardware matrix and confirm if your controller is approved. The links for Storwize V7000 6.2 are here and for SVC here. As of this writing, the list has still not been updated, but I am reliably informed it will include the DS3000, DS4000, DS5000, DS8700 and DS8800. It will not initially include XIV, which will come later. Please also note the following:
- Support for giant MDisks (greater than 2 TiB) is firmware controlled. If the controller (e.g. a DS5300) presenting a giant MDisk is not on the supported list for your SVC/Storwize V7000 firmware version, then only the first 2 TiB of that MDisk will be used.
- If your already presenting a giant MDisk (and using just the first 2 TiB), then just upgrading your SVC/Storwize V7000 firmware won't make the extra space useable. You will need to remove the MDisk from the pool, then do an MDisk discovery and then add the MDisk back to the pool. All of this can of course be done without disruption, using the basic data migration features we have supported since 2003.
What to do in the meantime?
If your currently using an SVC or external MDisks with a Storwize V7000, then you need to work within the 2 TiB MDisk limit (except for Storwize V7000 behind SVC). The recommendation is a single volume per Array for performance reasons (so the disk heads don't have to keep jumping all over the disk to support consecutive extents on different parts of the disk). This can require careful planning. For instance using 7+P RAID5 Arrays of 450 GB drives makes an array that is over 3 TB. What to do in this example?
- Divide it in half? (by creating two 1.5TB volumes)
- Waste space? (a whole 1 TB)
- Use smaller arrays? (a 4+P array of 450GB disks is 1.8 TB)
The answer is that where possible, create single volume arrays using 4+P or larger. If the disk size precludes that, then create multiple volumes per array and preferably split these volumes across different pools (MDisk groups).
Anything else to consider?
Well first up, will your Operating System support giant volumes? Googling produces so much old material that it becomes hard to nail down exact limits. For Microsoft, read this article here. For AIX check out this link. For ESX, check out this link.
Second of course is the consideration of size. File systems that utilize the space of giant volumes could potentially lead to giant timing issues. How long will it take to backup, defragment, index or restore a giant file system based on a giant volume (the restore part in particular)? Outside the scientific, video or geo-physics departments, are giant volumes becoming popular? Are they being held back by practical realities or plain fear? Would love to hear your experiences in the real world.
And a big thank you to Dennis Skinner, Chris Canto and Alexis Giral for their help with this post.