( 0 Votes )

The new rPerf document from IBM released on the 17th of Aug contains some big rperf numbers for the POWER7 795, and due to the dramatic leap in processor core count (64 on a 595, to 256 on a 795) they have paid some thought to the way they display the rPerf figures.

POWER7 in the smaller cheaper rack mount options have been announced making the new POWER7  chipset available to the SME market as of Sept. I'm looking forward to doing some costing against x86 solutions in this zone, the prices look competitive, especially if you take OS and virtualisation software into account.

http://www.channelregister.co.uk/2010/08/17/ibm_power7_low_high/page2.html 

Recently I have seen some strange behaviour with the later levels of firmware (around version 7.10 upwards) whereby a failed drive that has reconstructed to the hot spare does not automatically copyback when a new drive is inserted. The disk appears in storage manager as Optimal and Unassigned and logs indicate it has been picked up without error.

In later versions of IBM Storage Manager (versions 10.10 and up). There is a new function included "Replace Drives" that allows the user to select whether to replace a failed drive with any unassigned drive in the subsystem or the hot spare drive. It should be possible use this function to initiate the copyback. In some cases, I have seen that when the option "Replace Drives" is selected, the message is displayed "no drives available for replacement", despite the fact that unassigned drives are clearly available. In my investigations I have checked that the new drive was inserted correctly (leaving 30 seconds between the pull of the old and insertion of the new). I have seen that the new disk is of exactly the same type and brand and running the same level of firmware and that there do not appear to be any obvious problems within the event log,

The resolution so far has been simply to wait (even up to 2 days), and eventually, the "Replace Drives" option will recognise the available drive(s). So far, the only indication of what has occurred between these times has been that the regular media scan (scrub) has kicked off. Note that if a Storage Subsystem password is set, this is required to authorise the copyback.


The "Replace Drives" function does not appear to be clearly documented in the new Storage Manager client Redbooks so I will blog regards what I know of this function later.

( 2 Votes )

With today's news, IBM is expanding its portfolio and furthering its investments in information and analytics with:

The DS3000 subsystems become less of a range with the announcement of the DS3500, as it's a bit of a jack of all trades which outdoes all its smaller siblings. Available June 15th there are two versions, the DS3512 and DS3524 supporting either 3.5" and 2.5" disks, with 12 or 24 disks accordingly. There are also EXP3512 and EXP3524 expansion enclosures to match. Both units are 2U high, and this basically brings the DS range into line with the HP MSA2000 range in terms of spindle capacity and density, to the point that the only real difference is the GUI used to manage it.

Of most note with the DS3500 are the changeable host interfaces similar to the DS5020/DS3950, which means that the DS3500 can have a mix of four 6Gbps SAS and an optional four more SAS connections, eight 8Gbps FC or eight 1Gbit iSCSI ports. If you have the FC ports, unlike the smaller DS3000 units the DS3500 *will* support remote mirroring between the DS3500 and any other DS3500/DS4000 or DS5000 subsystem.

( 2 Votes )

IBM told the world that the new POWER7 range of servers were going to be fast.  We saw their benchmarks and read their white papers.  But I always reserve judgment until somebody else runs their own benchmark on a new piece of hardware.

LTO-5 has now been announced for the IBM tape range... well, the TS3100, TS3200, and TS3500 anyway. If you want LTO-5 for the TS3310 unfortunately you'll have to wait a little bit longer.

A quick technical summary, LTO-5 has a native data transfer of up to 140 MB/sec. and a 1.5 TB Data Cartridge uncompressed, or up to 3TB with the drive's 2:1 compression. It also continues to follow the LTO standard of writing back one generation and reading back two, ensuring that your LTO-3 and LTO-4 tapes still have some life in them. Finally  the drive also has a 8-Gbps Fibre Channel dual-ported interface on the back end, so you can finally have a more resilient connection through to the drive itself when connected to a SAN.

Be aware that unlike like DS4000 range, the cache batteries within the DS3000 Storage Subsystems (including DS3200, DS3300 and DS3400) are not covered under IBM warranty. This means that when they fail a replacement part must be purchased even if the unit is under standard or uplifted warranty.

IBM state in Retain Tip H194543 that "the battery is designed to have a life expectancy of two (2) years and to maintain the data in cache for up to three (3) days in the event of a power outage".

The replacement part can be requested from your IBM Sales Representative or an IBM Business Partner. The part required is:

DS3000 System Memory Cache Battery, Option 39R6519

Retain Tip H194543 also recommends that users upgrade the subsystem controller firmware to 07.35.41.00 or later to benefit from the Smart Battery Learn Cycle technology which monitors battery life and will override the "Battery Nearing Expiration" warning if it determines that the battery is still in good order.

Note that in order to calculate battery life, the "Smart Battery Learn Cycle" performs a discharge and charge every 13 weeks during which time write cache will be suspended and this could impact on the performance of the system. This Smart battery feature can be disabled if preferred.

*A small set of batteries may not support this Smart battery technology - see the Retain Tip for more information*

http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5079213&brandind=5000008

( 2 Votes )

Having checked out an implementation of TSM for Sharepoint, I was surprised to see that backup data was being retained for longer periods than set in the backup plan. I checked the usual places (Server copygroups, expiration processing, etc) but everything seemed in order. I then turned to google and user groups and after many searches I finally stumbled across an answer to the problem. 

This can be caused by two different TSM server settings for the DocAve node.
1.  The node does not have Del Backup set to Yes
2.  The node's txngroupmax is too low Diagnostics:
1. Check the following:
 Query Node F=D for the node in question and ensure the following is set :
      Backup Delete Allowed: Yes

2. Check the actlog for the following
ANR0445W Protocol error on session 1115630 for node nodename (DocAve) - maximum group transaction size exceeded. (SESSION: 1115630) In the case where the node's Backup Delete Allowed is set to No, update the node so that it is set to Yes. In the case where you are getting the delete errors due to maximum group transaction size exceeded, then you need to update the node's txngroupmax.

During a DocAve backup, the data is segmented into 50mb chunks. This is stored individually on TSM as an object. Because DocAve uses the TSM API, the deletion of the old data is done as a single transaction. If the number of objects it is trying to delete is greater than txngroupmax, then the deletion will fail.

( 2 Votes )

Earlier this week IBM announced its range of next generation x86 based servers lovingly named eX5.  The eX5 features a new range of Intel Xeon processors, which I'll cover in more detail after the official announcement by Intel on 20/3/2010.  As we are all well aware, IBM do not have exclusive rights to Intel Xeon processors, so these same processors will be springing up in all of IBM's competitors servers over the next few months.  The question is, what are IBM planning to do different, if anything.