Does scaling out bring TCO advantages over scaling up? The Reg offers advice

I usually tend to look at technology from a technical point of view, but when in the field talking to end users it often turns out they bought it for the same reason it was pitched ... only to realise later that actually they like it for totally different reasons. What I’m about to say was backed up for me a few days ago while …

[Anonymous Coward]

the technology costs are not always the killer

its how much it costs to run the upgrade project itself.

Managing multiple project managers, third parties, the datacenter access and cabling etc makes invasive upgrades uncharitably complex, even if the kit itself was completely free. All sorts of people with the word "analyst" and "consultant" get involved for their views and this costs money too. Even getting a budget submission to the point of approval can be costly and time consuming. Extra licences for databases, storage management, and monitoring solutions can also be inclurred.

Burning of internal costs is a far less obvious but very important to factor in beyond the more defined licencing and hardware costs directly associated with the scaling.

[Anonymous Coward]

1. Buy old disks at the cost of new ones

2. Buy larger disks and use only a portion of them to maintain the system balanced and easy to configure/maintain

3. Buy the same larger disks and start to mess with the configuration

Replace disk in the above statements with node for a scaleout system and you have pretty much the same issue, differing node types in the same cluster typically lead to compromises.

Not that I have anything against either option it's just when you get into the weeds, scaleout isn't always the Nirvana portrayed on powerpoint.

[abb2u]

Pure Physics

I concur. Talk about hyperconverged upgrade is somewhat naive and cavalier at this point. Think of an engine with pistons, balanced and tuned to work as whole. Can you add a larger piston or two or optimize the valving of the additional upgraded pistons? It is pure physics. The engine will run only as fast as the slowest piston. You wasted all the money it cost to upgrade.

Unfortunately even product managers and marketers are making these claims about ease of upgrade and heterogeniety of nodes. They ignore their own manuals like the VSAN Admin Guide that has a section on balance. If you are writing about things just based on product fliers you lose and mislead.

Then lets talk about inserting these upgrade nodes into a rack live and while in production. Is there enough power? Will it disturb power balance and redundancy? Network? Should I say more? -- None of this has been measured. Talk of TCO at this moment in time lacks empirical data.

Get it!! The data I mean. Run this stuff, upgrade it, change node balance and measure in between and let us all know what you get. It will be a nice physics science project.

[Anonymous Coward]

Worth a read

https://en.wikipedia.org/wiki/Scalability

"There are tradeoffs between the two models. Larger numbers of computers means increased management complexity, as well as a more complex programming model and issues such as throughput and latency between nodes; also, some applications do not lend themselves to a distributed computing model. In the past, the price difference between the two models has favored "scale up" computing for those applications that fit its paradigm,"

[Bcraig]

I would note that different vendors have very different caveats around "scale out". I buy two nodes of scale out today, can I expand that cluster to 3, 4,...8 nodes in 3-5 yrs? Unless a solution has the ability to scale out to different node types (compute, capacity, drive types) its not really a realistic "scale out" design and will end up in several pools of storage in different management domains.If I have to repurchase my cluster nodes I bought 2-3 years ago to maintain a scale out model, that seems expensive and cumbersome. But...to the point of the article. What model fits depends on what the customer realistically needs.

[vibhorgupta]

ScaleIO is the answer

Hi Bcraig,

I completly agree with you. In a nutshell, a scale-out system should have an ability

- to increase or decrease the size cluster on the basis of the requirements

- should be hardware agnostic; mainly drives

- should be OS/hypervisor agnostic.

ScaleIO is the answer for all these requirements. And the icing on the cake, its a free and frictionless software to play around.

I would highly recommend to visit ScaleIO website

http://www.emc.com/storage/scaleio/index.htm

thanks

[Anonymous Coward]

Re: ScaleIO is the answer

Maybe, maybe not.

100% uptime for 7 years with HPE StoreVirtual VSA? Check!

http://www.bitcon.be/?p=3255

[Bcraig]

Re: ScaleIO is the answer

I'm not sure another layer of abstraction is the answer technically or financially. I would prefer my cluster to have that ability natively. However the only ones I know of that can do that is Solidfire (and Netapp depending on how you define cluster).

[Anonymous Coward]

Vendor agnsotic

Scale Up simply means you can only buy from the same vendor later on. It's lock in and for precious little advantage.

No-one really knows what their growth or requirements will be 2 years down the line - they can only estimate. Better to build and plan scale out from the start and have total freedom to buy whatever the best kit/deal is at the time, when you need it.

[Bcraig]

Re: Vendor agnsotic

We probably need to be honest with ourselves on how long we will be keeping any array we currently sell right now. The technology is moving so fast, do we really think we will be scaling out OR up on any platform sold today in three years? Not likely, they will be dinosaurs. When I or one of my AM's go down that "no forklift upgrade road", we make sure to caveat the statement heavily.

[Anonymous Coward]

Re: Vendor agnsotic

Ah so you prefer to source vendor agnostic low cost hardware to avoid lockin...but you have to then accept software lockin anyway and the software only vendors margins are typically much bigger. Hardware at least is tangible needing to be designed, sourced and manufactured. Whereas you write software once and it's all gravy from there on in. Either way you're locked in.

[Dinsdale247]

Not so sure about that

Except I've seen lots of instances where the "scale out" nodes are no longer supported so "sorry, you're going to have to buy this $10,000 router to convert between the new and the old system". You've also not taken into account the added complexity that more networked gear inevitably entails. I've also seen vendors sell hobbled scale out systems for a slightly lower price to an unsuspecting manager and then gouge on the upgrade path. Don't think you're going to get away any cheaper. Just remember, regardless of the vendor or the scaling system, they want to make you part with as much money as possible and none are above back handed tricks to do so.

[PlinkerTind]

Scale-out can not replace scale-up

There are workloads that only big 16/32-socket scale-up servers can handle, typically enterprise business software workloads such as SAP, databases, etc. In those workloads, scale-out clusters can not replace scale-up servers. Scale-out clusters can only handle embarassingly parallel workloads, such as clustered HPC number crunching workloads, and not all problems are easily parallelizable. For instance, look at the official SAP benchmark list, there are not a single cluster. The top record spot is held by a Unix SPARC server with 32 sockets scoring 844.000 saps. (SAP Hana is a cluster, used for analyzing static read-only data in RAM, so it is great for clusters. It is not fit for normal SAP workload OLTP, it is only fit for analyzing static data).

Only recently (a couple of months ago) there has been new large 16/32 socket x86 servers offerings by SGI (UV300H) and HP (Kraken). Until then, the largest scale-up x86 server were ordinary 8-socket servers sold by Oracle, HP, etc. There is a new breed of x86 servers now out on the market, the first generation 16/32-socket server ever. All earlier large x86 servers out there has been scale-out clusters such as SGI UV2000 server with 10.000s of cores, resembles a small supercomputer cluster. And SGI UV2000 customers have used it for clustered workloads.

The first generation of x86 scale-up servers will perform very poorly, trying to get rid of bugs and identify bottle necks. It takes a couple of generations before the x86 scale-up servers will start to perform ok. They dont stand a chance to large Unix servers and Mainframes today. For instance, the SAP Hana is a clustered workload, and is certified with SGI UV300H. I want to see non-clustered workloads running on the scale-up UV300H - and expect it to perform very poorly compared to large Unix boxes on scale-up workloads such as SAP. The problem with SAP is it scales awfully bad, because it is a non clustered workload. So going from 500.000 saps to 600.000 saps is a huge and very difficult step. Because SAP scales bad, and the SGI UV300H is first generation, I expect SGI UV300H score quite bad on SAP compared to large Unix boxes.