Desktop or Server?

How closely SLE, SLED, and SLES are intertwined becomes clear when you look at the "Workstation Extension for SLES 12." This extension is basically just an additional repository that adds to SLES the SLED packages that are missing from the box. A real SLED license is required to use the workstation extension.

SUSE itself explains what this extension is good for: if you need the SLES features, but you would like to use the machine as a workstation, you can add all the necessary features with the SLES extension. Figure 9 shows the SLES 12 screen saver at work.

Figure 9: Although the UI only plays a subordinate role in SLES 12, the screen saver tells the admin that new updates are ready to install.

High Availability and Geo HA

SLES 12 offers add-ons for (geo) HA and public clouds. The HA plugin is an old acquaintance that already saw heavy use in SLES 11. The plugin includes components that admins need for high-availability clusters: Pacemaker and Corosync, as well as the glue that holds these components together.

SUSE has a traditionally close relationship to the HA stack: After all, Andrew Beekhof, the main Pacemaker developer, was with Chameleon services for several years before the Red Hats recruited him.

The HA extension is what admins are familiar with from SLES 11; the only new feature is a small tool designed to help set up a Pacemaker cluster, which should help to speed up deployment.

The more interesting feature is an add-on for the HA add-on that enables Geographic (geo) HA on SLES. Geographic high availability differs from legacy, local HA in several respects.

Key factors, such as replication, which are easy to handle on local networks, are real challenges on the WAN. When the network includes multiple datacenters, complicated questions arise. For example, which datacenter do you want to be the active component if two datacenters in an HA configuration lose eye contact? Who decides which dataset and which end is up to date?

Pacemaker itself does not include all the necessary functions to answer these kinds of questions, but SUSE delivers these features in the HA geo add-on: Booth [7] is a Pacemaker add-on that logically maps several data centers in the cluster and manages them accordingly. Booth works with internal tickets and uses the functionality provided by Pacemaker. A site can only operate a service if it has received a corresponding ticket from Booth (Pacemaker refers to this as a "location constraint").

The validity of tickets is limited; Booth has to regularly renew the ticket. If the site that had the current ticket goes down, Pacemaker automatically realizes that the service is no longer running and issues the remaining site a new ticket. For this principle to work, Booth has to run at a third location, which looks at both sites independently.

Although the entire process sounds complicated, much kudos goes to SUSE for Booth – geo-clustering with Linux is probably not implemented better anywhere than in SLES 12.

Conclusion

In SLE 12, SUSE has come up with a platform that is likely to please both SLED 12 and SLES 12 users. Apart from the aforementioned bugs in YaST, the system proved very robust in our lab. With regard to the YaST rewrite, I just need to reiterate that our editorial team only had a prerelease version SLE 12, not the finished product.

Anyway, SUSE seems to have learned from the feedback for SLES 11, and it is now putting SLES 12 through significantly more testing.

SLES 12 impresses as a product: The distribution scores points with meaningful and useful features. The Wicked network tool left our test team puzzled in some cases, although it does look ready to be usefully deployed and meaningfully controlled on the whole. The available add-ons, such as (geo) HA and the SLES Workstation Extension, contribute towards making SLES a solid computing platform.

The vote on SLED, which is also based on the SLE 12 platform, was less clear. A later test will reveal what is really hiding behind the SLED facade.

One thing is clear: The approach of building an enterprise desktop on a modified Gnome 3 is risky for SUSE, because its target audience has mostly used KDE in the past. We don't know yet whether this decision will prove good or bad, but it is certainly bold.

The Author

Martin Gerhard Loschwitz works as a Cloud Architect with Sys Eleven. where he focuses on OpenStack, distributed storage, and Puppet. In his spare time, he also maintains Pacemaker for Debian.