Deploying OpenStack is NOT Difficult

There are too many articles around at the moment claiming that OpenStack is difficult to set up, and too many vendors claiming the only answer is consulting.

Yes, consulting can be important to get the business side of your private cloud worked out, but setting up OpenStack doesn't need to be difficult, when you have a distribution that's main purpose is ease-of-deployment in enterprise environments.

Here are some factoids about SUSE OpenStack Cloud:

• It was the first enterprise OpenStack distro
• SUSE introduced the concept of "distro" for OpenStack
• It is actually a distro that can be set up by normal people - not just an invitation to a consulting engagement by a vendor
• It is the only distro to ever win Intel's "Rule the Stack" competition for ease-of-installation-and- management (3 times in a row, and sometimes when no-one else was able to complete the task)
• It is the only distro that supports KVM and Xen and VMware and HyperV and Docker and zVM – yes! you can even send workloads to mainframes!
• The deployment tool can deploy SUSE Linux Enterprise and HyperV/Windows Server as compute nodes.
• Installation of SUSE Enterprise Storage (powered by Ceph) is integrated into the deployment tool
• The deployment tool will communicate with your existing infrastructure if you want: plugins make it easy to include your favourite storage system or converged networking
• It is the distro used by some of the well-known OpenStack users
• HA deployment is included with a couple of extra clicks
• SUSE's fleet management tool, SUSE Manager, can be easily integrated into the cloud infrastructure so that new compute/storage/etc nodes automatically get patch/update/security/configuration management
• SUSE's template creation tool, SUSE Studio, can be used to set up the VM's to offer to end users & directly add them into the OpenStack image repository.

Given that ease-of-install has been the hallmark of SUSE OpenStack Cloud since day one, it seems a shame that everyone seems to think it's difficult when it doesn't have to be – it should be a piece of cake.

Some links:

FIS-ASP deploys in one day:  https://www.youtube.com/watch?v=aFdlUIdYwQU

BMW OpenStack + Ceph case study: https://www.susecon.com/doc/2015/sessions/CAS19964.pdf

SAP using SUSE including OpenStack: https://www.youtube.com/watch?v=mLkPzFB1m_w

More (including downloads) at: https://suse.com/cloud

Why SUSE Linux Is the Only Sensible Choice for HPE Superdome-X

Unlike other material herein, this is an unashamedly partisan post. It's here's to collect together mostly links, for reference.

In December 2014, HP (now HPE) announced the successor to its long line of proprietary enterprise class computer systems:  the Integrity Superdome X.

What was particularly interesting about this announcement is that the focus was not just on the Intel Xeon processor, or the scalability of the machine to 16 CPU's and 24 TB of RAM, but what Jeff Kyle, director of product management for mission-critical systems at HP said was most important: "It's all about the software," Kyle told eWEEK.

Superdome X was the first flagship system from HP to not ship with HPUX.  Instead its launch OS was Linux. SUSE Linux.

Why?  Well SUSE Linux was the launch OS for Superdome X. And yes, that article mentions our old friends from Raleigh, but the fact remains that at launch time, the only benchmarks provided by HP were those with SUSE Linux.

So how about now, 18 months later?   Well according to the SPEC website, as of today ALL of the SpecJBB and SpecCPU benchmarks published by HPE for Superdome X use SUSE Linux Enterprise Server:

http://www.spec.org/jbb2015/results/res2015q3/jbb2015-20150908-00012.html

http://www.spec.org/jbb2015/results/res2015q4/jbb2015-20151013-00025.html

http://www.spec.org/jbb2015/results/res2015q4/jbb2015-20151027-00029.html

https://www.spec.org/cpu2006/results/cpu2006.html

So there's a clear message here – when HPE is trying to get the best possible performance form their machines, they turn to SUSE Linux.

Why is this? well in terms of raw scalability, SUSE far exceeds RedHat linux:

	Max supported CPUs	Max supported RAM
SLES 12:	8192	1024 TB
RHEL 7.2:	288	12 TB

https://www.suse.com/products/server/technical-information/

https://access.redhat.com/articles/rhel-limits

At the very least, this means that to handle a fully-loaded Superdome X with 24TB of RAM you must use SUSE Linux or risk falling into the "experimental" or at best "unsupported" category.  And risk isn't really want you want when running a mission-critical system.

In particular, SUSE Enterprise Linux has actually tested scalability on other systems to 8192 CPU cores and 64TB RAM (no-one could supply a machine with more RAM;  the CPU count was qualified after that article was written). SUSE's numbers are therefore not theoretical when it comes to the demands of Superdome X: there is no risk that scaling will not follow the expected path.

This difference is likely to continue as well: both HPE and Intel spend a lot of effort developing code for the Linux to improve scalability, etc, and this is sent “upstream” to the latest kernel versions.  This means that you would normally expect the most recent kernel version would have the best performance, due to HPE & Intel contributions.  Typically SUSE leads its competitor in implementing the latest kernel features whilst maintaining application and kernel binary compatibility between major kernel releases (e.g. from SLES 11SP1 with 2.6 kernel to SLES 11 SP2 with 3.0 kernel).  Given this background it should not be surprising for SUSE to continue to make similar advances in its current SLES 12 major release. Historically Red Hat has not changed major kernel releases:  RHEL 5 & 6 were kernel level 2.6, with 3.10 introduced only in 2014 with RHEL 7.

In other words: as HPE continues to contribute performance & other features to Linux for all of its server platforms, these are most likely to appear (with full global enterprise-class support) on SUSE Enterprise Linux long before they are available on RHEL. 

https://wiki.microfocus.com/index.php/Kernel_versions

https://access.redhat.com/articles/3078

So it's no mistake that HP themselves chose SUSE Enterprise Linux when they migrated their internal systems from HP-UX.

Why Open Source Software Defined Storage Will Win

Last week NetApp posted it's first quarterly loss in many years. It's not something I take pleasure in, since I have many friends still working at that company and it still has some very interesting technologies. The storm clouds are gathering though, and I can't help but liken NetApp's situation to that of Sun Microsystems, another former employer, as the tech bubble burst in the early 2000's, especially when I look at some of the comments reported from the NetApp earnings call.

Back in the day, Sun was making a lot of money and good margins with high performance proprietary hardware

Then along came Linux running some simple tasks on commodity hardware. it was good enough to do the simple jobs, had a lot of the essential features & functionality that unix provided, and the hardware was at such a low price that the economics were impossible to ignore. Some of the first adopters were the same companies that been the early sun customers, those who had replaced mainframes & minicomputers with cheaper, yet effective Sun hardware.

Unfortunately the lesson of their  own early success wasn't remembered by Sun's senior management, who thought they could win customers back by offering Linux on Sun hardware. Of course, the software wasn't the point here – it was the low-cost hardware that was attracting attention. Some of us in the field & parts of engineering tried to convince Sun's management to put more effort behind Solaris for x86, but just at a critical juncture, Solaris 9 was released on SPARC, along with the message that x86  support would be put on the back-burner ... the die was cast and Sun's fate sealed as commodity hardware pushed the boundaries of performance and drove the need for proprietary hardware into an upper niche. I still contend that if Sun had instead fully committed support for x86 & embraced a software-first approach,  the Solaris would dominate the market & Linux would have been relegated to a similar position as FreeBSD occupies today.

What does this have to do with software defined storage & NetApp? Well it appears that there is a similar approach from NetApp's senior management:  they see that customers "want scale out and software defined storage functionality",  but seem to think that the only response is a solution running on NetApp hardware. Like Sun, they (and the other major storage vendors) are chained to their high-margin proprietary hardware. Breaking free of this kind of entanglement is at the crux of Christensen's Innovator's Dilemma.

Meanwhile open source, software-defined storage solutions running on commodity hardware, such as SUSE Enterprise Storage based on Ceph – the Linux of enterprise storage if you like – are starting to gain attention, especially for large bulk data stores facing exponential growth and price-sensitivity. For the moment these solutions are best suited to relatively simple (albeit large) deployments, but the technology is not standing still. Ceph already features high-end technologies like snapshots, zero-copy cloning, cache-tiering and erasure coding, and enterprises are finding that it is "good enough" and at a dramatically lower price-point.  The open source nature of the development means that progress is rapid, and the software-defined nature means that hardware costs are driven relentlessly down. This is the same dynamics as we saw with the transition of UNIX to Linux, and it likely to have the same impact on the proprietary enterprise storage vendors.

So, change is here: I hope NetApp can navigate the course better than Sun did, though it will be interesting to see how.

Meanwhile, enterprises looking to rein in the exponential costs of enterprise storage can now look to open source for answers, and take advantage of the power and economics of commodity hardware systems.