SUSE Linux 12 challenges Red Hat

It’s been more than five years since SUSE delivered a full release of its Enterprise Linux software, and a lot has happened to the company during that time. But in our testing we find that SUSE 12 has been worth the wait.

SUSE 12 is a set of Linux distributions ranging from desktop through enterprise level. We tested several instances and found them quite ready for enterprise use, be they persistent or randomly instantiated as virtual machines.

Even though SUSE took seemingly forever to leap from SLES 11 to SLES 12 (Canonical, as an example, had four “full” releases in this time frame), SUSE hasn’t been asleep. Every single day like clockwork, we’ve received a SUSE patch/fix notification email, dutifully reminding us of recommended changes, large and small.

And since our last review, the list of editions has expanded. Current editions include SUSE Linux Enterprise Server, Server for IBM System z, Server for IBM Power, Server for SAP Applications, Server for High Performance Computing, Server with Expanded Support, and (server for) Point of Sale. There are desktop versions, too.

+ ALSO ON NETWORK WORLD: RED HAT ANCHORS ENTERPRISE-FOCUSED ECOSYSTEM +

The server editions can be joined (where it makes sense) to options such as SLE High Availability Extension (with optional Geo Clustering), Enterprise Real Time Extension, VM Driver Packs, Microsoft System Center Management Pack, and/or a Workstation Extension.

In turn, most of these can be connected directly through OpenStack to VMware ESXi (although oddly, not recommended on ESX 5.5, according to SLES 12 docs), and managed through SUSE Cloud and with SUSE Manager, with payloads from SUSE Studio, perhaps deployed with SUSE Enterprise for Amazon EC2 (and compatibles) and/or SUSE Linux Enterprise Server for Windows Azure. Other extensions add management capability for VMs under Microsoft’s System Center. 

Like Red Hat, SUSE is all about ecosystem and added value tailored to varying existing infrastructures, with a heavy emphasis on private/public IaaS/PaaS cloud. And while the ecosystems are vast and interesting, we confine ourselves in this review to SLES 12, the enterprise-version on x86_64—although we could find no 32-bit version.

What took so long?

It’s been a long, strange trip for Germany-based SUSE, which was the first company to deliver an enterprise-grade version of Linux around 20 years ago. Novell bought SUSE in 2003, Attachmate bought Novell in 2010, and UK-based Micro Focus International bought Attachmate in 2014. In the interim, SUSE Enterprise Linux went through a metamorphosis, using numerous iterative SLES 11.x dot-revisions before SUSE Linux Enterprise Server reached version 12.

SLES 12 is a conservative edition in some ways, but otherwise bears all of the forethought and hardening of Red Hat, and rivals Red Hat’s business model, if in different ways. As an example, this is a Linux distribution that supports Docker containers, but does so haltingly, and with caveats.

What you get

We examined the x86_64 Server versions, just before and after the release of SLES 12. The beta version was, saving a few updates, the same as the production version. The docs weren’t quite finished, recommending hardware minimums of 512M in one place, 2G of memory in another, as an example. We recommend 2GB unless processes are stanched and swap files are optimized.

Under the hood, the x86_64 versions are driven by the same V-8 engine Linux kernel (with systemd driving) as Red Hat, Ubuntu, and several other recent Linux editions. Like the other popular distros, the value of SUSE’s edition surrounds its support infrastructure, and ecosystem.

SUSE’s SLES 12 distribution qualities are similar to prior versions, and use Yast2 to pilot administration. AutoYast can help build and silo versions for subsequent bare-metal or auto/netboot/wake-on-LAN loads of instance.

We could install SLES 12 via VNC, PXE, or by attended installations. We tried them all, and we found no issues. We found the PxE install via SSH especially compelling and not difficult. Attended or unattended, you get btfs as the root file system, which Red Hat is said to preview in its coming updates to Red Hat 7.

The desktop and server GUIs are Gnome-based as SUSE no longer supports KDE in this edition. SUSE now supports rsyslog, rather than syslog and syslog-ng, which might be more of a fight between their German and Hungarian authors, respectively. As rsyslog is less known, it’s no less simple as the open-source versions of syslog and syslog-ng and won’t affect many as either can be replaced if desired with the other at little time, trouble or even cost.

MariaDB is now the default bundled/supported relational database instead of Oracle’s MySQL. There’s no difference in terms of deployment or performance that we could find, especially when we brought up two LAMP stack versions to test.

Performance

We could find no meaningful performance differences between SUSE SLES 12 and Red Hat on our largest single system, which has four sockets and 60 cores. We lack sufficient hardware to truly pound the SLES 12 High Performance Computing/HPC version.

It’s possible, using SUSE developer resources, to make instances with optimized payloads to be distributed among bare metal, or PaaS/IaaS virtualized destinations. These, like other modern Linux distributions, can be tweaked for desired characteristics, be these web engines, database, embedded applications packages, etc., and so meaningful comparison in performance among current distributions is becoming a scientific discipline unto itself.

We’ve found historically that SUSE’s updates have arrived like clockwork, which imbues attention to quality and patches to security issues and CVE fixes fast. In this edition, auto-updating is possible, including kernel modules—which sends chills up and down our spine.

Real-time kernel patching might increase stability, and is already done in some parts of the kernel, where drivers and other modules are loaded in and out of kernel space. We pray that man-in-the-middle attacks don’t permit a destabilization, or surreptitious module load that amounts to a rootkit invasion, although in theory, protections already in place would make this unlikely.

The benefit of patching the kernel live would keep servers running and transaction integrity alive through the patching process. Now that server POST and boot times can now exceed 10 minutes, the live loading might prevent service interruption(s) along a chain of high-reliability/availability systems—where transactional integrity or state-machine integrity wouldn’t be sacrificed.

Overall

The long awaited SLES 12 plays well in the network operations center, and although a bit different than Red Hat, it’s definitely a viable competitor. Although we haven’t added ecosystems into the consideration for purposes of this review, our experience with SUSE support, now mostly bereft of ties to Novell, has been very good.

Gone is KDE and featured is Gnome, if a UI matters to you. The customization engineering potential of instance payloads satisfies our hunger for highly tailored and manufacturable fabrics. We wish the docs were as baked as the OS, but they’re still pretty usable.

How We Tested SUSE Linux 12

We downloaded the SUSE SLES 12 first as a beta, then the production versions. We made several different instance payloads, then sized them, noting the resulting application mixes. We installed these instances on bare metal servers, principally Dell servers, then VMs using principally VMware ESXi 5.1/5.5, and Microsoft Hyper-V 3.1 Hardware VM host platforms included Lenovo Thinkservers, HP DL580/560/380 Gen8s, VirtualBox on Mac Mavericks, and a Samsung i7-based notebook (KDE and Gnome installations).

Our lab network consisted of an HP Proliant MicroServer Gen8 (Windows 2012 with HyperV-3), and two Dell 1925 (VMware ESX 5.1) servers. Our NOC network consisted of two Lenovo ThinkServers (RD440 running ESX 5.5; RD630 running Microsoft 2012 R2/Hyper-V3.1), an HP DL580-G8 (ESX 5.5), HP DL560-G8 (ESX 5.1). All hosts were connected in the lab via a Gigabit Ethernet/10G Ethernet network, in turn to the NOC network at Expedient in Indianapolis which is connected via a Gigabit Ethernet and 10G Ethernet network switched L2/L3 via Extreme Networks Summit Series Switches onto Expedient’s core network.

Tom Henderson runs ExtremeLabs, in Bloomington, Ind. He can be reached at kitchen-sink@extremelabs.com.