FCIP Routers – A Best Practice Design Tip

Many years ago a Glaswegian friend of mine quoted someone as saying that the 1981 anti-apartheid protests in New Zealand (South African rugby tour) showed that New Zealand was not just a floating Surrey as some had previously suspected. While the Surrey reference might be lost on those not from England, I can tell you there are some distinct cultural and language differences between NZ and England.

For example, there was a (not very good) punk band called ‘Rooter’ back in the late 1970′s in New Zealand. They ended up having to change their name to The Terrorways because ‘Rooter’ was  considered too offensive by the managers of many pubs and clubs.

I guess that’s why in NZ we always pronounce ‘router’ to rhyme with ‘shouter’ even though we pronounce ‘route’ to rhyme with ‘shoot’. We’re kind of stuck in the middle between British and American English.

Pronunciation issues aside however, FCIP routers are a highly reliable way to connect fabrics and allow replication over the WAN between fibre channel disk systems. The price of FCIP routers seems to have halved over the last year or so, which is handy and live replicated DR sites have become much more commonplace in the midrange space in the last couple of years.

Apart from the WAN itself (which is the source of most replication problems) there are a couple of other things that it’s good to be aware of when assembling a design and bill of materials for FCIP routers.

1. When you’re using the IBM SAN06B-R (Brocade 7800) we always recommend including the licence for ‘Integrated Routing’ if you’re going out over the WAN. This prevents the fabrics at either end of an FCIP link from merging. If a WAN link bounces occasionally as many do, you want to protect your fabrics from repeatedly having to work out who’s in charge and stalling traffic on the SAN while they do that. Without IR your WAN FCIP environment might not really even be supportable.
2. Similarly I usually recommend the ‘Advanced Performance Monitoring’ feature. If you run into replication performance problems APM will tell you what the FC app is actually seeing rather than you having to make assumptions based on IP network tools.
3. The third point is new to me and was the real trigger for this blog post (thanks to Alexis Giral for his expertise in this area) and that is if you have only one router per site (as most do) then best practice is to connect only one fabric at each site as per the diagram below.

The reason for this is that the routers and the switches all run the same FabricOS and there is a small potential for an error to be propagated across fabrics, even though Integrated Routing supposedly isolates the fabrics. This is something that Alexis tells me he has explored in detail with Brocade and they too recommend this as a point of best practice. If you already have dual-fabric connected single routers then I’m not sure the risk is high enough to warrant a reconfiguration, but if you’re starting from scratch you should not connect them all up. This would also apply if you are using Cisco MDS922i and MDS91xx for example, as all switches and routers would be running NXOS and the same potential for error propagation exists.

Easy Tier is even better than we thought!

IBM storage architects and IBM Business Partners are encouraged to use Disk Magic to model performance when recommending disk systems to meet a customer requirement. Recently v9.1 of Disk magic was released and it listed nine changes from v9. This little gem was one of them:

“The Easy Tier predefined Skew Levels have been updated based on recent measurements.”

Knowing that sometimes low-key mentions like this can actually be quite significant, I thought I’d check it out.

It turns out that v9 had three settings

• low skew (2)
• medium skew (3.5)
• heavy skew (7)

While v9.1 has

• very low (2)
• low (3.5)
• intermediate (7)
• high (14)
• very high (24)

If I take a model that I did recently for Storwize V7000 customer:

• 40 x 450GB 10K 2.5″ drives RAID5
• 5 x 200GB SSDs RAID5
• plus hot spares
• 16KB I/O size
• 70/30 read/write ratio

The v9 predictions were:

• 12,000 IOPS at light skew (2)
• 13,000 IOPS at medium skew (3.5)
• 17,000 IOPS at heavy skew (7)

I have generally used medium skew (3.5) when doing general sizing, but the help section in Disk Magic now says “In order to get a realistic prediction, we recommend using the high skew (14) option for most typical environments.  Use the intermediate skew level (7) for a more conservative sizing.”

The v9.1 predictions are now:

• 12,000 IOPS at very low (2)
• 13,000 IOPS at low (3.5)
• 17,000 IOPS at intermediate (7)
• 28,000 IOPS at high (14)
• 52,000 IOPS at very high (24)

So what we can see from this is that the performance hasn’t changed for a given skew, but what was previously considered heavy skew is now classed as intermediate. It seems that field feedback is that I/Os are more heavily skewed towards a fairly small working set as a percentage of the total data. Easy Tier is therefore generally more effective than we had bargained on. So apparently I have been under-estimating Easy Tier by a considerable margin (the difference between 13,000 IOPS and 28,000 IOPS in this particular customer example).

The Disk Magic help also provides this graph to show how the skew relates to real life. “In this chart the intermediate skew curve (the middle one) indicates that for a fast tier capacity of 20%, Easy Tier would move 79% of the Workload (I/Os) to the fast tier.”

For more reading on Easy Tier see the following:

• How to configure IBM Storwize V7000 Easy Tier with SSD for SAP
• IBM Easy Tier on DS8000, SVC and Storwize V7000 Deployment Considerations Guide
• Performance benefits of IBM Storwize V7000 with Easy Tier for Oracle 11g workload
• Implementing the IBM Storwize V7000 V6.3

Hu’s on first, Tony’s on second, I Don’t Know’s on third

This post started life earlier this year as a post on the death of RAID-5 being signaled by the arrival of 3TB drives. The point being that you can’t afford to be exposed to a second drive failure for 2 or 3 whole days especially given the stress those drives are under during that rebuild period.

But the more I thought about RAID rebuild times the more I realized how little I actually knew about it and how little most other people know about it. I realized that what I knew was based a little too much on snippets of data, unreliable sources and too many assumptions and extrapolations. Everybody thinks they know something about disk rebuilds, but most people don’t really know much about it at all and thinking you know something is worse than knowing you don’t.

In reading this so far it started to remind me of an old Abbot and Costello sketch.

Anyway you’d think that the folks who should know the real answers might be operational IT staff who watch rebuilds nervously to make sure their systems stay up, and maybe vendor lab staff who you would think might get the time and resources to test these things, but I have found it surprisingly hard to find any systematic information.

I plan to add to this post as information comes to hand (new content in green) but let’s examine what I have been able to find so far:

1. The IBM N Series MS Exchange 2007 best practices whitepaper mentions a RAID-DP (RAID6) rebuild of a 146GB 15KRPM drive in a 14+2 array taking 90 minutes (best case).

Netapp points out that there are many variables to consider, including the setting of raid.reconstruct.perf_impact at either low, medium or high, and they warn that a single reconstruction effectively doubles the I/O occurring on the stack/loop, which becomes a problem when the baseline workload is more than 50%.

Netapp also says that rebuild times of 10-15 hours are normal for 500GB drives, and 10-30 hours for 1TB drives.

2. The IBM DS5000 Redpiece “Considerations for RAID-6 Availability and Format/Rebuild Performance on the DS5000” shows the following results for array rebuild times on 300GB drives as the arrays get bigger:

I’m not sure how we project this onto larger drive sizes without more lab data. In these two examples there was little difference between N Series 14+2 146GB and DS5000 14+2 300GB, but common belief is that rebuild times rise proportionally to drive size. The 2008 Hitachi whitepaper “Why Growing Businesses Need RAID 6 Storage” however, mentions a minimum of 24 hours for a rebuild of an array with just 11 x 1TB drives in it on an otherwise idle disk system.

What both IBM and Netapp seem to advise is that rebuild time is fairly flat until you get above 16 drives, although Netapp seems to be increasingly comfortable with larger RAID sets as well.

3. A 2008 post from Tony Pearson suggests that “In a typical RAID environment, say 7+P RAID-5, you might have to read 7 drives to rebuild one drive, and in the case of a 14+2 RAID-6, reading 15 drives to rebuild one drive. It turns out the performance bottleneck is the one drive to write, and today’s systems can rebuild faster Fibre Channel (FC) drives at about 50-55 MB/sec, and slower ATA disk at around 40-42 MB/sec. At these rates, a 750GB SATA rebuild would take at least 5 hours.”

Extrapolating from that would suggest that a RAID5 1TB rebuild is going to take at least 9 hours, 2TB 18 hours, and 3TB 27 hours. The Hitachi whitepaper figure seems to be a high outlier, perhaps dependent on something specific to the Hitachi USP architecture.

Tony does point out that his explanation is a deliberate over-simplification for the purposes of accessibility, perhaps that’s why it doesn’t explain why there might be step increases in drive rebuild times at 8 and 16 drives.

4. The IBM DS8000 Performance Monitoring and Tuning redbook states “RAID 6 rebuild times are close to RAID 5 rebuild times (for the same size disk drive modules (DDMs)), because rebuild times are primarily limited by the achievable write throughput to the spare disk during data reconstruction.” and also “For array rebuilds, RAID 5, RAID 6, and RAID 10 require approximately the same elapsed time, although RAID 5 and RAID 6 require significantly more disk operations and therefore are more likely to impact other disk activity on the same disk array.”

The below image just came to hand. It shows how the new predictive rebuilds feature on DS8000 can reduce rebuild times. Netapp do a similar thing I believe. Interesting that it does show a much higher rebuild rate than the 50MB/sec that is usually talked about.

5. The EMC whitepaper “The Effect of Priorities on LUN Management Operations” focuses on the effect of assigned priority as one would expect, but is nonetheless very useful in helping to understanding generic rebuild times (although it does contain a strange assertion that SATA drives rebuild faster than 10KRPM drives, which I assume must be a tranposition error). Anyway, the doc broadly reinforces the data from IBM and Netapp, including this table.

This seems to show that increase in rebuild times is more linear as the RAID sets get bigger, as compared to IBM’s data which showed steps at 8 and 16. One person with CX4 experience reported to me that you’d be lucky to get close to 30MB/sec on a RAID5 rebuild on a typical working system and when a vault drive is rebuilding with priority set to ASAP not much else gets done on the system at all. It remains unclear to me how much of the vendor variation I am seeing is due to reporting differences and detail levels versus architectural differences.

6. IBM SONAS 1.3 reports a rebuild time of only 9.8 hours for a 3TB drive RAID6 8+2 on an idle system, and 6.1 hours on a 2TB drive (down from 12 hours in SONAS 1.2). This change from 12 hours down to 6.1 comes simply from a code update, so I guess this highlights that not all constraints on rebuild are physical or vendor-generic.

~

In 2006 Hu Yoshida posted that “it is time to replace 20 year old RAID architectures with something that does not impact I/O as much as it does today with our larger capacity disks. This is a challenge for our developers and researchers in Hitachi.”

I haven’t seen any sign of that from Hitachi, but IBM’s XIV RAID-X system is perhaps the kind of thing he was contemplating. RAID-X achieves re-protection rates of more than 1TB of actual data per hour and there is no real reason why other disk systems couldn’t implement the scattered RAID-X approach that XIV uses to bring a large number of drives into play on data rebuilds, where protection is about making another copy of data blocks as quickly as possible, not about drive substitution.

So that’s about as much as I know about RAID rebuilds. Please feel free to send me your own rebuild experiences and measurements if you have any.

XIV Gen3 Sequential Performance

Big Data can take a variety of forms but what better way to get a feeling for the performance of a big data storage system than using a standard audited benchmark to measure large file processing, large query processing, and video streaming.

From the www.storageperformance.org website:

“SPC-2 consists of three distinct workloads designed to demonstrate the performance of a storage subsystem during… large-scale, sequential movement of data…

• Large File Processing: Applications… which require simple sequential process of one or more large files such as scientific computing and large-scale financial processing.
• Large Database Queries: Applications that involve scans or joins of large relational tables, such as those performed for data mining or business intelligence.
• Video on Demand: Applications that provide individualized video entertainment to a community of subscribers by drawing from a digital film library.”

The Storage Performance Council also recently published its first SPC-2E benchmark result. ”The SPC-2/E benchmark extension consists of the complete set of SPC-2 performance measurement and reporting plus the measurement and reporting of energy use.”

It uses the same performance test as the SPC-2 so the results can be compared. It does look as though only IBM and Oracle are publishing SPC-2 numbers these days however and the IBM DS5300 and DS5020 are the same LSI OEM boxes as the Oracle 6780 and 6180, so that doesn’t really add a lot to the mix. HP and HDS seem to have fled some time ago, and although Fujitsu and Texas Memory do publish, I have never encountered either of those systems out in the market. So the SPC-2 right now is mainly a way to compare sequential performance among IBM systems.

XIV is certainly interesting, because in its Generation 2 format it was never marketed as a box for sequential or single-threaded workloads. XIV Gen2 was a box for random workloads, and the more random and mixed the workload the better it seemed to be. With XIV Generation 3 however we have a system that is seen to be great with sequential workloads, especially Large File Processing, although not quite so strong for Video on Demand.

The distinguishing characteristic of LFP is that it is a read/write workload, while the others appear to be read-only. XIV’s strong write performance comes through on the LFP benchmark.

Drilling down one layer deeper we can look at the components that make up Large File Processing. Sub-results are reported for reads, writes, and mixed read/write, as well as for 256 KiB and 1,024 KiB I/O sizes in each category.

So what we see is that XIV is actually slightly faster than DS8800 on the write workloads, but falls off a little when the read percentage of the I/O mix is higher.

NAS Robot Wars

The new Storwize V7000 Unified (Storwize V7000U) enhancements mean that IBM’s common NAS software stack (first seen in SONAS) for CIFS/NFS/FTP/HTTP/SCP is now deployed into the midrange.

Translating that into simpler language:

IBM is now doing its own mid-range NAS/Block Unified disk systems.

Anyone who has followed the SONAS product (and my posts on said product) will be familiar with the functions of IBM’s common NAS software stack, but the heart of the value is the file-based ILM capability, now essentially being referred to as the Active Cloud Engine.

The following defining image of the Active Cloud Engine is taken from an IBM presentation:

What the file migration capability does is place files onto a specific tier of disk depending on the user-defined policy.

e.g. when disk tier1 hits 80% full, move any files that have not been accessed for more than 40 days to tier2.

Importantly these files keep their original place in the directory tree.

The file-based disk to disk migration is built-in, and does not require any layered products or additional licensing.

Files can also be migrated off to tape as required without losing their place in the same directory tree, using HSM which is licensed separately.

Another important feature that IBM’s competitors don’t have is that although there are two file services modules in every Storwize V7000U operating in active/active configuration they present a single namespace to the users e.g. all of the storage can be presented to a single S: drive.

And the final key feature I wanted to mention was the unified management interface for file and block services, another feature which some of our competitors lack.

Naturally there are many other features of the Storwize V7000U, most of which you’ll find mentioned on the standard Storwize V7000 product page and the Storwize V7000 Unified infocenter.

Today IBM also announces SONAS 1.3, as well as a 243TB XIV model based on 3TB drives, SVC split cluster up to 300Kms, Block replication compatibility between SVC and Storwize V7000, Snapshot-based replication option for SVC and Storwize V7000 and an assortment of Tivoli software enhancements.

Check out IBM bloggers Tony Pearson, Barry Whyte and Rawley Burbridge who have more details.

Meanwhile talking about Active Cloud Engine as a kind of robot reminded me of another robot. Although I have never really been at ease with the ugly competitiveness of capitalism, I do hate losing, so perhaps this is a more apt image to show how we see the Active Cloud Engine ‘robot’ stacking up against the competition.

And here are some other Killer Robots:

The Big Bang Theory “The Killer Robot“

Hypno-Disc Vs Pussycat

Razer Vs Onslaught

Jamie Hyneman’s (MythBuster) robot Blendo in action against DoMore

A Small Challenge with NAS Gateways

SAN Volume Controller

Late in 2010, Netapp quietly announced they were not planning to support V Series (and by extension IBM N Series NAS Gateways) to be used with any recent version of IBM’s SAN Volume Controller.

This was discussed more fully on the Netapp communities forum (you’ll need to create a login) and the reason given was insufficient sales revenue to justify on-going support.

This is to some extent generically true for all N Series NAS gateways. For example, if all you need is basic CIFS access to your disk storage, most of the spend still goes on the disk and the SVC licensing, not on the N Series gateway. This is partly a result of the way Netapp prices their systems – the package of the head units and base software (including the first protocol) is relatively cheap, while the drives and optional software features are relatively expensive.

Netapp however did not withdraw support for V Series NAS gateways on XIV or DS8000, and nor do they seem to have any intention to, as best I can tell, considering that support to be core capability for V Series NAS Gateways.

I also note that Netapp occasionally tries to position V Series gateways as a kind of SVC-lite, to virtualize other disk systems for block I/O access.

Anyway, it was interesting that what IBM announced was a little different to what Netapp announced “NetApp & N Series Gateway support is available with SVC 6.2.x for selected configurations via RPQ [case-by-case lab approval] only“

Storwize V7000

What made this all a bit trickier was IBM’s announcement of the Storwize V7000 as its new premier midrange disk system.

Soon after on the Netapp communities forum it was stated that there was a “joint decision” between Netapp and IBM that there would be no V Series NAS gateway support and no PVRs [Netapp one-off lab support] for Storwize V7000 either.

Now the Storwize V7000 disk system, which is projected to have sold close to 5,000 systems in its first 12 months, shares the same code-base and features as SVC (including the ability to virtualize other disk systems). So think about that for a moment, that’s two products and only one set of testing and interface support – that sounds like the support ROI just improved, so maybe you’d think that the original ROI objection might have faded away at this point? It appears not.

Anyway, once again, what IBM announced was a little different to the Netapp statement “NetApp & N Series Gateway support is available with IBM Storwize V7000 6.2.x for selected configurations via RPQ only“.

Whither from here?

The good news is that IBM’s SONAS gateways support XIV and SVC (and other storage behind SVC) and SONAS delivers some great features that N Series doesn’t have (such as file-based ILM to disk or tape tiers) so SVC is pretty well catered for when it comes to NAS gateway funtionality.

When it comes to Storwize V7000 the solution is a bit trickier. SONAS is a scale-out system designed to cater for 100′s of TBs up to 14 PBs. That’s not an ideal fit for the midrange Storwize V7000 market. So the Netapp gateway/V-series announcement has created potential difficulties for IBM’s midrange NAS gateway portfolio… hence the title of this blog post.

Hierarchical Storage Management (HSM)

HSM is essentially a way to push disk files to lower tiers, mainly tape, while leaving behind a stub-file on disk, so that the file maintains it’s accessibility and its place in the directory tree.

I say tape because there are other ways to do it between disk tiers that don’t involve stub files. e.g. IBM’s SONAS uses it’s built-in virtualization capabilites to move files between disk tiers, without changing their place in the directory tree, but SONAS can also use Tivoli Space Management to migrate those files to tape using HSM.

HSM started life as DFHSM [DFSMShsm] on IBM mainframe and I use it most weeks in that context when I log into one of IBM’s mainframe apps and wait a minute or two for it to recall my database query files to disk. That’s some pretty aggressive archiving that’s going on, and yes it’s bullet-proof.

I know of a couple of instances in the early 2000′s when companies got excited about file-based Information Lifecycle Management, and implemented HSM products (not IBM ones) on Microsoft Windows. Both of those companies removed HSM not long after, having experienced blue screens of death and long delays. The software was flaky and the migration policies probably not well thought out (probably too aggressive given the maturity of open systems HSM at the time). Being conservative, IBM came a little late to the game with Open Systems HSM, which is not necessarily a bad thing, but when it came, it came to kick butt.

Tivoli Space Management is a pretty cool product. Rock solid and feature rich. It runs on *NIX and our customers rely on it for some pretty heavy-duty workloads, migrating and recalling files to and from tape at high speed. I know one customer with hundreds of terabytes under HSM control in this way. TSM HSM for Windows is another slightly less sophisticated product in the family, but one I’m not so familiar with.

One could argue that Space Management has been limited as a product by its running on *NIX operating systems only, when most file servers out in the world were either Windows or Netapp, but things are changing. HSM is most valuable in really large file envionments – yes, the proverbial BIG DATA, and BIG DATA is not typically running on either Windows or Netapp. IBM’s SONAS for example, scalable to 14 Petabytes of files, is an ideal place for BIG DATA, and hence an ideal place for HSM.

As luck would have it, IBM has integrated Space Management into SONAS. SONAS will feed out as much CIFS, NFS, FTP, HTTP etc as you want, and if you install a Space Management server it will also provide easy integration to HSM policies that will migrate and recall data from tape based on any number of file attributes, but I guess most typically ‘time last accessed’ and file size.

Tape is by far the cheapest way to store large amounts of data, the trick is in making the data easily accessible. I have in the past tried to architect HSM solutions for both Netapp and Windows environments, and both times it ended up in the too hard basket, but with SONAS, HSM is easy. SONAS is going to be a really big product for IBM over the coming years as the BIG DATA explosion takes hold, and the ability to really easily integrate HSM to tape, from terabytes to petabytes, and have it perform so solidly is a feature of SONAS that I really like.

Tape has many uses…

The Anatomy of a Purchase

Working in a sales-oriented part of IBM, it’s interesting for me to be occasionally on the buying side of the equation and note my own reactions to different criteria, brands and situations.

Recently I bought a second-hand X-Type Jaguar 2.1L SE (Singapore import), after considering a BMW 320i 2.2L E46 and a Nissan Skyline V35 2.5L (that’s Infiniti G35 for our American friends). My criteria setting out was for a compact 2005+ 6-cylinder vehicle with low mileage. I do about 26,000 Kms a year and want to keep the car for 3-5 years and my experience suggests a 6-cyl is good for 200,000 Kms.

I can imagine an IT buyer setting out to buy a storage solution with criteria that might parallel this.

Fuel consumption (think elements of TCO) on the Jag and the beamer were similar, with the Skyline being a bit better even though it is a larger vehicle with a larger engine. Also there are a lot of V35 Skylines around, quite a lot of BMW 320i’s around, and not quite so many X-type Jags around.

How much weight do you give to leadership in your market? How much weight do you give to TCO over purchase price? Both of these turned out to be considerations for me, but not big enough to swing the final decision.

I did my homework on the technology, and the reputation, and the prices and availability of each. I looked briefly also at Nissan Maxima/Teana, and Holden/Chevrolet Epica (Daewoo Tosca) but they were both a bit bland for my taste [in the words of the Suburban Reptiles "Told what to do by the Megaton, so we may as well die while we're having fun"].

So I’m relating this to how an IT buyer might go about drawing up a shortlist of vendors. A lot of buyers want a bit of sizzle with their sausage.

My personal preference was for the Skyline, but the Jag I finally test drove was very tidy, and my wife loved the leather seats, and maybe I was influenced by memories of riding in my uncle’s XJ6 as a child. Also the Skyline I wanted was going to take another week to arrive, and I’m not really a patient guy. I had sold my 2005 Suzuki Swift Sport within two days of deciding to sell it and I was ready to buy again. Also worth noting is that the Skyline was my wife’s third choice of the three, partly because it was the biggest of the three. The Skyline’s Nissan 350z technology and it’s name link to the GTR Skylines that cleaned out the big V8′s back in ’91 & ’92 at Bathurst also make it more of a boys’ car I suppose.

So more parallels with my mythical IT buyer taking the opinions of other influencers and circumstances into account, and do you take into account what’s around the corner, or just what’s immediately on the table?

The BMW was there mainly out of curiosity – I have always associated BMW’s with people who wanted to impress others with their success : ) e.g. Real Estate Agents. Now I know that isn’t fair on either BMW or Real Estate Agents, which is why I wanted to include the beamer in my eval, but the prejudice is still embedded somewhere deep in my mind.

I know that some IT buyers carry unfair prejudices about storage companies also, and sometimes include vendors or products on their shortlist more out of curiosity than out of any real intention of buying.

One friend warned me about Jaguar unreliability, but I did my homework. X-type (with it’s Ford Mondeo heritage) seemed a pretty safe choice. I wanted to get an AA check done, but I realised that would be a hassle and would add days to the purchase, so instead I negotiated 3 years mechanical insurance into the purchase. So either I get points for being flexible about the best way to manage risk, or I lose points for quickly abandoning my original plan when it started to look inconvenient.

As it turned out the Skyline and the Jag were the same price, and the beamer was about 15% more, which made it easy to eliminate the beamer, seeing as I’d never really wanted it in the first place. Its one nice feature was that it was the smallest of the 3 vehicles, so technically it was the best fit for my core criteria. Also the Jag I wanted was pulled from sale, and I had to go to a 2004 model, which was older than my starting criterion, but it was the best example of an X-type I could find so I made an exception for it.

I am sure IT buyers sometimes re-define their business requirements to accommodate their desires or the convenience of the moment.

All in all I’m happy with my X-type Jag. Slightly concerned about fuel consumption, but surprised how many X-types I have seen in the last two days. I’ve also been surprised that most people over-estimate the value of the car. It probably only cost me 15% more up-front than buying a much lower spec 4 cylinder Toyota Corolla for example, which in my book is definitely a sausage without any sizzle.

My concrete contractor brother did call me a wanker when he saw the Jag (again probably based on an instant over-estimation of what I’d paid) but I didn’t feel like a wanker. Strangely I knew I would have felt like a wanker if I’d gone with the beamer though (no slur intended on other beamer owners) and I probably would have felt cooler if I’d gone with the Skyline, but the X-type Jag won the day.

So the winner was not the cheapest, or the coolest, or the best technical fit, but on balance the most convenient, the easiest to buy, and the best overall fit.

Is that how people buy IT storage solutions?

The Joys of OEM Co-op-etition

I was recently mulling over some examples of OEM co-op-etition in our industry:

• During the early 00′s IBM and Compaq OEM’d each others disk systems, the MA8000 from Compaq (sold as the MSS by IBM) and the ESS from IBM (sold as the CSS by Compaq) to give each other coverage in midrange and high-end storage. The fact that so few people know this even happened tells you something about how successful it was. I know that among some IBM sellers, the MSS was certainly considered ‘last cab off the rank’ when it came to solutioning.

• Dell has a long-standing OEM arrangement to sell EMC CLARiiON and VNX products, which compete with their own Compellent and Equallogic disk systems. In fact the OEM arrangement with Dell goes right back to the Data General CLARiiON days. Dell’s acquisition of Compellent must have decreased the value of the relationship from EMC’s point of view. Sure Dell has helped EMC to penetrate the SMB market, but now Dell has a foothold, skills and credibility which they can exploit with Compellent going forward.

• Netapp had a brief OEM agreement with Dell between ’98 and ’00. I don’t know what happened there, but I do know that Netapp tries to sell value, technology, integration and innovation. Back in the late 90′s Dell was all about price and urgent delivery. That’s a pretty big culture divide. I’m guessing that Dell simply didn’t sell much of the high-priced Netapp kit.

• Again, Netapp had an OEM agreement with Hitachi between ’02 and ’04, but it was just for gateways.  A gateway-only OEM agreement doesn’t really work for Netapp as a glance at their list prices will tell you that they make a lot of their margin from disk drives. I expect the agreement failed because most of the benefits fell on Hitachi’s side of the ledger.

• Most major vendors OEM low end tape products from ADIC/Quantum or similar. This has worked well for years because there is relatively minimal competition between the big vendors and their other own-branded channels. Occasionally there is disruption e.g. when Sun bought STK and then Oracle bought Sun, the STK OEMS were naturally a bit unsettled.

So what we learn from co-op-etition is that it’s designed to benefit both parties and their customers, but if it works it sometimes leads to changes in the dynamics between the three. If the relationship lasts only a couple of years it may be a sign that the dynamics weren’t right in the first place and the setup and tear-down costs are unlikely to have been recovered. If it lasts 5 or 10 years then I think you’d have to consider that a big success.

The IBM OEM agreement with Netapp dates from 2005 and continues to benefit both parties. IBM has provided Netapp with entry into large enterprises around the world and contributes about 10% of Netapp’s revenues. Netapp has leveraged IBM’s channel and benefited from the credibility endorsement. These days Netapp is on a roll fueled by VMware but they weren’t such a high profile contender back in 2005. One long-term benefit to IBM is that it now has a worldwide workforce experienced with NAS.

An example of the competition side of co-op-etition is that IBM has never taken Netapp’s Spinnaker/GX/Cluster-Mode product. Instead IBM was busy developing its own Scale-Out NAS offering which in 2010 was refined into SONAS, targeted at customers who have plans to grow to hundreds of terabytes or petabytes of file storage. In large environments the file-based ILM features of SONAS (including integration of HSM to tape) can be quite compelling.

While co-op-etition sometimes looks like  a strange vendor dance to an outside observer, as long as the customers get value from the arrangements then it’s really just a practical way of doing business.

xkcd: Password Strength

I just thought this one was worth highlighting…

World’s most affordable high-function 500TB+ block I/O disk solution

Gotta love this price-optimized solution for two tier disk… (plus Easy Tier automatic SSD read/write tiering).

This is possibly the most affordable high-function 500TB+ disk solution on the planet… and it all fits into only 32u of rack space!

Yeah I know it’s a completely arbitrary solution, but it does show what’s possible when you combine Storwize V7000′s external virtualization capability with DCS3700′s super high density packaging which perfectly exploits the “per tray” licensing for both Storwize V7000 and for TPC for Disk MRE. The Storwize V7000 also provides easy in-flight volume migration between tiers, not to mention volume striping, thin provisioning, QoS, snapshots, clones, easy volume migration off legacy disk systems, 8Gbps FC & 10Gbps iSCSI.

Check out the component technologies:

Storwize V7000 at www.ibm.com/storage/disk/storwize_v7000 

DCS3700 at www.ibm.com/storage/disk/dcs3700

and TPC for Disk at  www.ibm.com/storage/software/center/disk/me

XIV Gen3 at full speed

Don’t try this at home on your production systems… but it’s nice to see the XIV flying at 455 thousand IOPS. It actually peaked above 460K on this lab test but what’s 5,000 IOPS here or there…

Thanks to Mert Baki

 

XIV Gen3 & MS Exchange 2010 ESRP

So here’s a quick comparison of XIV Gen3 and Gen2 with some competitors. Note that ESRP is designed to be more of a proof of concept than a benchmark, but it has a performance component which is relevant. Exchange 2010 has reduced disk I/O over Exchange 2007 which has allowed vendors to switch to using 7200 RPM drives for the testing.

The ESRP reports are actually quite confusing to read since they test a fail-over situation so require two disk systems, but some of the info in them relates to a single disk system. I have chosen to include both machines in everything for consistency. The XIV report may not be up on the website for a few days.

Once again XIV demonstrates its uniqueness in not being a just another drive-dominated architecture. Performance on XIV is about intelligent use of distributed grid caches:

• XIV Gen 3 returns 2.5 times the IOPS from a NL-SAS drive that a VNX5700 does.
• XIV Gen 3 returns 1.8 times from NL-SAS 7200RPM what a CX4 can get out of FC 10KRPM drives.
• Even XIV Gen2 with SATA drives can get 25% more IOPS per SATA drive than VMAX.

And to answer a question asked on my earlier post. No these XIV results do not include SSD drives, although the XIV is now SSD-ready and IBM has issued a statement of direction saying that up to 7.5TB of PCIe-SSD cache is planned for 1H 2012. Maybe that’s 15 x 500GB SSDs (one per grid node).

XIV Gen3: Both Hands Clapping

xiv

Pronunciation:/zɪv/

noun

1. the sound storage makes as it zooms past its competitors:

                 there was a loud xiv as the new IBM system arrived and the other vendors’ disk systems all collapsed under the weight of their own complexity

XIV Generation 3 is here and XIV Generation 2 remains in the family. Here is a quick sampler of Gen3 Vs Gen2 performance:

For more information on today’s announcements check out the XIV product page on ibm.com and the general overview on youtube.

Some of you might also consider that XIV Gen3′s use of Infiniband interconnect and NL-SAS drives brings new relevance to my two recent blog posts on those subjects : )

To Infiniband… and Beyond!

Nearline-SAS: Who Dares Wins

Which HP storage product names are more effective?

 

Nearline-SAS: Who Dares Wins

Maybe you think NL-SAS is old news and it’s already swept SATA aside?

Well if you check out the specs on FAS, Isilon, 3PAR, or VMAX, or even the monolithic VSP, you will see that they all list SATA drives, not NL-SAS on their spec sheets.

Of the serious contenders, it seems that only VNX, Ibrix, IBM SONAS, IBM XIV Gen3 and IBM Storwize V7000 have made the move to NL-SAS so far.

First we had PATA (Parallel ATA) and then SATA drives, and then for a while we had FATA drives (Fibre Channel attached ATA) or what EMC at one point confusingly  marketed as “low-cost Fibre Channel”. These were ATA drive mechanics, with SCSI command sets handled by a FC front-end on the drive.

Now we have drives that are being referred to as Capacity-Optimized SAS, or Nearline SAS (NL-SAS) both of which terms once again have the potential to be confusing. NL-SAS is a similar concept to FATA – mechanically an ATA drive (head, media, rotational speed) – but with a SAS interface (rather than FC) to handle the SCSI command set.

When SCSI made the jump from parallel to serial the designers took the opportunity to build in compatibility with SATA via a SATA tunneling protocol, so SAS controllers can support both SAS and SATA drives.

The reason we use ATA drive mechanics is that they have higher capacity and a lower price. So what are some of the advantages of using NL-SAS drives, over using traditional SATA drives?

1. SCSI offers more sophisticated command queuing (which leads directly to reduced head movement) although ATA command queuing enhancements have closed the gap considerably in recent years.
2. SCSI also offers better error handling and reporting.
3. One of the things I learned the hard way when working with Engenio disk systems is that bridge technology to go from FC to SATA can introduce latency, and as it turns out, so does the translation required from a SAS controller to a SATA drive. Doing SCSI directly to a NL-SAS drive reduces controller latency, reduces load on the controller and also simplifies debugging.
4. Overall performance can be anything from slightly better to more than double, depending on the workload.

And with only a small price premium over traditional SATA, it seems pretty clear to me that NL-SAS will soon come to dominate and SATA will be phased out over time.

NL-SAS drives also offer the option of T10 PI (SCSI Protection Information) which adds 8 bytes of data integrity field to each 512b disk block. The 8 bytes is split into three chunks allowing for cyclic redundancy check, application tagging (e.g.RAID information), and reference tagging to make sure the data blocks arrive in the right order. I expect 2012 to be a big year for PI deployment.

I’m assured that the photograph below is of a SAS engineer – maybe he’s testing the effectiveness of the PI extensions on the disk drive in his pocket?

To Infiniband… and Beyond!

Not here this time… over there >>>

This week I’m doing a guest blogging spot over at Barry Whyte’s storage virtualizatiom blog, so if you want to read this week’s post head over to:  https://www.ibm.com/developerworks/mydeveloperworks/blogs/storagevirtualization/entry/infinity_and_beyond?lang=en

p.s. Infiniband is the new interconnect being used in XIV Gen3

 

 

Storwize V7000 four-fold Scalability takes on VMAX & 3PAR

IBM recently announced that two Storwize V7000 systems could be clustered, in pretty much exactly the same way that two iogroups can be clustered in a SAN Volume Controller environment. Clustering two Storwize V7000s creates a system with up to 480 drives and any of the paired controllers can access any of the storage pools. Barry Whyte went one step further and said that if you apply for an RPQ you can cluster up to four Storwize V7000s (up to 960 drives).

Am I boring you? Full stripe writes and other complexity…

In 1978 IBM employee Norman Ken Ouchi was awarded patent 4092732 for a “System for recovering data stored in failed memory unit.” Technology that would later be known as RAID 5 with full stripe writes.

Hands up who’s still doing that or its RAID6 derivative 33 years later?

I have a particular distaste for technologies that need to be manually tuned.

You can’t always get what you want

There have been a raft of new storage efficiency elements brought to market in the last few years, but what has become obvious is that you can’t yet get it all in one product.

Netapp Insight December 2010

I was invited to Netapp insight 2010 in December and I didn’t get a chance to write much about that at the time being end of year rush and all. So here are some thoughts. IBM N Series and Netapp are essentially the same thing so I will use either term generically. I’m not mentioning presenters names as I’m not 100% sure the names on the slide decks I have were the actual presenters in Macau. Disclosure here is that not only do I work for IBM, but Netapp funded my trip to Macau. Even though I booked my 3 days solid there were still a lot of good sessions I couldn’t get to because of conflicts.

Maximum Fibre Channel Distances

Just a quick hit and run blog post for today… This table authored by Karl Hohenauer just came into my inbox. With the changes in cable quality (OM3, OM4) the supported fibre channel distances have confused a few people, so this will be a good reference doc to remember.

Favourite Product of 2010 that Never Was…

With everyone announcing best-of type choices for 2010 I thought I’d take a slightly less serious approach and announce my favourite product of 2010 that never was – a product so cool that either no-one but me thought of it, or more likely, it somehow doesn’t stack up technically or cost-wise.

Where Should I Shove This Solid State Drive?

Everyone agrees that enterprise-class SSDs from companies like STEC Inc are fast, and cool, and pretty nice. Most people also realise that SSDs are an order of magnitude more expensive than SAS drives, and that there is no expectation that this will change dramatically within the next 5 years. This means we have to figure out how to leverage SSDs without buying a whole lot of them.

Storwize V7000 Vs the Rest – a Quick SPC-1 Performance Roundup

This post is in response to the discussion around my recent Easy Tier performance post.

Storwize V7000 Easy Tier: SATA RAID10 Vs SAS RAID6

When IBM released it’s SPC-1 Easy Tier benchmark on DS8000 earlier this year, it was done with SATA RAID10 and SSD RAID10, so when we announced Storwize V7000 with Easy Tier for the midrange, the natural assumption was to pair SATA RAID10 and SSD RAID10 again. But it seems to me that 600GB SAS RAID6 + SSD might be a better combination than 2TB SATA  RAID10 + SSD.

Exploiting the Intelligence of Inventors

In Tracey Kidder’s book “Soul of a New Machine” I recall Data General’s Tom West as saying that the design that the team at Data General came up with for the MV/8000 minicomputer was so complex that he was worried. He had a friend who had just purchased a first run Digital Equipment Corp VAX, and Tom went to visit him and picked through the VAX main boards counting and recording the IDs of all of the components used. He then realised that his design wasn’t so complex after all, compared to the VAX and so Tom proceeded to build the MV/8000 with confidence.

In this example, deconstruction of one product helped Tom to understand another product, and sanity check that he wasn’t making things too complicated. It didn’t tell him if MV/8000 would be better than VAX however.

I have many times seen buyers approach a storage solution evaluation using a deconstructionist approach. Once a solution is broken down into its isolated elements, it can be compared at a component level to another very different solution. It’s a pointless exercise in most cases.

Quality of Service on SAN Volume Controller & Storwize V7000

I learned something new recently. SVC has QoS, and has had it for quite some time (maybe since day 1?).

IBM’s New Midrange with Easy Tier & External Virtualization

Yes, IBM has announced a new midrange virtualized disk system, the Storwize V7000. A veritable CLARiiON-killer : )

Does my midrange look big in this?

IDC defines three categories of external disk. The midrange market leaders are EMC, Netapp and IBM (followed by Dell and HP with both slipping slightly over the last 12 months). Netapp is almost entirely a midrange business, while EMC and IBM are the market leaders in highend. Over the last 4 quarters midrange has accounted for almost half of the spending in external disk (cf just over a quarter on highend) so clearly midrange is where the action is.

Fair Play and the Profit Motive

Over at Techcrunch Michael Arrington has been talking about alleged illegal collusion amongst angel investors in Silicon Valley.

It always amuses me that people expect an economy based on competition and maximising one’s profits to provide a basis for fair play.

A pedant’s rant on “Data Reduction”

I am starting to see the term ‘data reduction’ cropping up all over the place and being used to mean either compression or deduplication. I have a couple of objections to this.

1. It’s not an accurate descriptor
2. It’s bad manners to commandeer an existing term from another discipline and redefine it to mean something completely different.

ALL YOUR BASE ARE BELONG TO US

There are four reasons I can think of why a company wants to buy another:

1. To take a position in a market you didn’t expect to be in but has suddenly become important to you (e.g. EMC buying VMware)
2. To take a position in a market you did expect to be in, but the internal projects to get you where you wanted have failed (e.g. HP buying 3PAR)
3. To gain mass in a market in which you already play successfully (e.g. Oracle buying JDE and PeopleSoft)
4. To prevent your competitor gaining an asset that they could use to attack your market (e.g. Oracle buying Sun/MySQL)

One size does not necessarily fit all…

IBM SAN Volume Controller & HDS USP

It’s been 7 years since IBM released SAN Volume Controller and brought multi-vendor storage virtualization and volume mobility to the mainstream market. SVC provides virtualization in the storage network layer, rather than within a disk system, and IBM has shipped more than 10,000 I/O groups (SVC node pairs).

HDS meanwhile took a different tack. They followed SVC by about 12 months, and have delivered virtualization in the disk system but with the ability to manage external disk systems just as SVC does.

SVC arguably has some advantages in ease of use around data migration, flexible object naming and optimizing performance from external systems (especially when using thin provisioning) but there is no doubt that USP/V and USP/VM are both very solid players in the storage virtualization space.

Both approaches (virtualization-in-the-network and virtualization-in-the-disk-system) are valid. It would be nice to think that one design could address all segments of the market, but it seems to me that each has its sweet spot.

Choice or Clutter?

Vendors often struggle to be strong in all market segments and address the broad range of customer requirements with a limited range of products. Products that fit well into one segment don’t always translate well to others, especially when trying to bridge both midrange and enterprise requirements.

When Space, Time & Vendor Charges Collide…

Well the whole snapshot and replication thing got me thinking about vendor licensing. Licensing is a way to get a return on one’s R&D, it doesn’t really matter whether customers pay x for hardware and y for software, or x+y for the hardware ‘solution’ and zero for software functions etc, as long as the vendor gets the return it needs to keep its investors happy.

Vendor charges are like taxes, most of us appreciate that they are needed, but there are many different ways to levy the tax: e.g. flat tax rate, progressive, regressive, goods and services (GST/VAT/SalesTax).

I suspect that charging large licence fees for snapshot and replication functions has held IT back and IMHO the time has now come to set these functions free.

Bow ties are cool – When time and space collide

Every storage vendor has sales slides that tell us that data growth rates are accelerating and the world will explode soon unless you buy their product to manage that…

…and yet the average IT shop is still mostly doing backups the old fashioned way, with weekly fulls and daily incrementals, and scratching their heads about how they are going to cope next year, given that the current full is taking 48 hours. They probably have a whole bunch of SATA disk somewhere that acts as the initial backup target, but it doesn’t go faster than tape, which is something they probably assumed it would do when they bought it, but somehow they feel that their backups to disk are probably a good thing anyway even though they’re more expensive…

Less is More – it’s a dedup vendor party

Dedup is happening fast all around us and the vendors are lining up, but it’s not always easy to compare what’s going on.

Is it time for the Enterprise Linux Server?

IBM’s Z10 Enterprise Linux Server is an interesting alternative to a large-scale VMware deployment. Essentially, any Linux workload that is a good fit for being virtualised with Vmware is a good fit for being virtualised on Z10.

Hey this Gibibyte stuff is really taking off!

So you know we’re making progress on the binary units thing (see my post entitled “How many fingers am I holding up“) when Piratebay.org starts using GiB…

7,368,671,232  Bytes   =    7.37 GB     or    6.86 GiB

Now if we can only get the IT vendor community to consistently follow Piratebay’s excellent example  : )

XIV Async (Snapshot) Replication

Snapshot-based Replication/Mirroring:

I thought it might be worth taking a quick look at async (snapshot) replication/mirroring which was released for XIV earlier this year with 10.2.0.a of the firmware. XIV async is similar in concept to Netapp’s async SnapMirror, both are snapshot based and both consume snapshot space as a part of the mirroring process. One difference of course is that with XIV both async and sync replication are included in the base price of the XIV, there is no added licence fee or maintenance fee to pay. I’d call it ‘free’ but I’d just get another bunch of people on twitter telling me they still haven’t received their free XIVs yet…

6 ordinary things I really like about IBM N Series

I seem to have been doing a lot of work recently on solutions that involve IBM N Series (Netapp) products. There are a few annoying things about the product (e.g. the price, fractional reserve) but there are some things I really like, and they’re not necessarily exciting things or things that we make a big deal about in sales presentations, but they’re the kind of solid features that make a storage architect’s life that bit easier and the pursuit of elegance that little bit more achievable.

How many fingers am I holding up?

The base2 Vs base10 nett capacity question is an interesting one. It remains a place of confusion for customers and that’s not surprising as it remains a place of confusion for vendors also.

IBM N Series (Netapp) Capacity Sizing

One thing I left off this post is a discussion of fractional reserve. This can be a major and I should have covered it. Some people allow 100% extra space when provisioning LUNs out of ONTAP. FR is about guaranteeing that you have space to write changed blocks in your active filesystem. It’s hard to explain it clearly – I’ve seen many try and fail. I myself find it confusing and complicated and just when I think I understand it, I end up with more questions. So I will just issue a general warning that if you are creating LUNs under ONTAP and you have snapshotting enabled, then discuss with your installer how much space needs to be set aside for the FR.

[Now updated to include base2 results]

I thought a quick post on calculating nett capacity with IBM N Series might be in order, since we have been caught out once or twice with this in the past. Hopefully this post will help others avoid problems of accidental under-capacity.

IBM Easy Tier with SATA and SSD

IBM has just published a very cool 33,000 IOPS SPC-1 benchmark result for the DS8000 using 96 x SATA and 16 x SSDs (not a FC drive in sight!) and with a max latency well under 5ms.

I’m impressed. This is a great piece of engineering.

Easy Tier was left to automatically learn the SPC-1 benchmark and respond (again, automatically). I won’t waffle on about it, but will just show you the graph of the various results seeing as the doc I took this from doesn’t say IBM Confidential anywhere : )

[Update: confirmed that the 192 drives in green are indeed 15KRPM drives]

I guess what we’d all like to see now is a significant drop in the cost of SSDs. I’m sure it’s coming.

More info on Easy Tier here.

Barry Whyte is on record as saying that Easy Tier will makes its way into SAN Volume Controller later this year. XIV does something vaguely analogous using distributed caches. Storage is fun!

What Happens When a Controller Fails

Whether XIV is a visionary way to reduce your storage TCO, or just a bizarre piece of foolishness as some bloggers would have you believe, is being tested daily, and every day that passes with large customers enjoying the freedom of XIV ease of use, performance and reliability, is another vote for it being a visionary product.

XIV has been criticised because there is a chance that it might break, just like every other storage system that has ever been invented, yet because XIV is a little different, the nay-sayers somehow feel that non-perfection is a sin.

So let’s talk about non-perfection in an old-style storage architecture.

Layered Storage Monitoring Tools

If you’re a big XIV fan, one of the things you might love about it is the built-in (i.e. ‘free’) monitoring tools that are really easy to use.

Also the xivtop utility which will be immediately familiar to anyone who has used ‘top’ on linux or UNIX systems.

But for many others in the non-XIV world, layered monitoring tools are a pain in the wallet and also a pain in the administrative butt.

Analysis always leads to truth

The xkcd webcomic is at http://www.xkcd.com

Application-aware snapshots for IBM Storage

Something strange has happened. IBM’s Tivoli group has produced some low-priced high-value storage software that’s easy to understand and easy to use! FlashCopy Manager provides fast application-aware backups and restores, leveraging the snapshot features of IBM storage systems.

Some quotes from the web about XIV

There are of course the official IBM references but these below are are a few unofficial public comments from customers and analysts that I found after a quick sweep of the web. I was looking for something else and started stumbling across these, so I thought I would post them.

Low-Cost DR with Split Cluster SVC

Ever since IBM’s SAN Volume Controller was first delivered back in 2003 folks have been looking at the 2n cluster nodes and wanting to separate them physically to achieve a degree of disaster recovery. This is generally referred to as  ‘split i/o group’ or ‘split cluster’. For this to be a good idea, two additional features were needed. Vdisk mirroring, which was delivered with SVC 4.3 and the ability to manually place the quorum data wherever you want, which was delivered in SVC 5.1.

XIV & MS Exch 2007 Replicated Performance

Vendors typically only benchmark their fastest systems in any one class, which means that a bit of careful reflection is required to get a good understanding of things from a few results. The usual “nyah nyah ours is faster” kind of analysis and comment that seems to permeate the blogosphere doesn’t really achieve anything that’s for sure.

Let’s talk about benchmarking more generally…

SONAS Screenshots

One of the key figures in the open source world over the last decade or so has been Andrew Tridgell. An Australian famous as being the primary author of both Samba and rsync among other things. Andrew has been an IBM employee for the last 5 years and I’m told he was originally the architect behind SAN File System (a project that was effectively merged into gpfs) which brings us right back to Samba again. For those who want more background take a look at his summary presentation “Clustered NAS meets gpfs” at samba.org.

xkcd on Security

xkcd is here

SONAS Part 1 – Philosophy & Architecture

In 1997 IBM launched what it called the Seascape architecture, which essentially was about building storage systems out of snap-together technology rather than building individually hand-crafted monoliths. This architecture has been attributed to Michael Hartung, who was appointed an IBM Fellow in 2002.

A ramble through my personal NAS history

Think of this post as a pre-amble to my promised SONAS post…

I guess most people have some experience with Microsoft file server technology, personally at home I use ftp for file centralization and backup, I find it simpler, but then I’m not a Windows server geek by any means. Others I know use OpenFiler, but are not necessarily very complimentary about it.

I remember the original Netware Vs LAN Manager Vs Banyan Vines debate from I guess it was the early 90′s.

Poll results are in SONAS wins

The poll results are in and SONAS has come in as the product you most want to hear about. Not suprising seeing as it’s our newest storage product. I will be working on a SONAS post over the next week or so as time permits.

Meanwhile check out the xkcd webcomic.

Thanks for voting.

Survival in the Blogosphere

Hey here we are a few days in and so far I hope I haven’t rubbished anyone else’s product. I’m even trying to be more respectful of XIV’s denigrators : )

That second post was a marathon of detailed research I can tell you.

The third had a lot more research in it than it looks on the surface, but because the essence of the debate was always going to be around product positioning I left the maths out. Anyone can add up numbers of vendors brochures and get KVA and BTU/Hr results.

The aim of those two posts was to get a ‘fair suck of the sav’ (as we say in A/NZ) for XIV. It works really well in the field, and it could do with just a little more respect out in the blogosphere.

Comparing XIV Power Consumption

XIV relies on lots of Intel cores and distributed caches to deliver performance. People who get hung up on disk systems being all about disk drives have trouble understanding XIV in so many ways, including power consumption.

XIV Drive Management

One issue that urgently needs accuracy and clarity is the disk management technology behind XIV.

Evidence-based opinions

Twitter I have found is not a great medium for bringing clarity to a situation, so I have returned to blogging and I will try to have something useful and accurate to say at least once a month. If I occasionally get stuff wrong or repeat misinformation, let me apologise in advance.