Big Three Linuxes Refreshed Now That SLES 12 Enters The Field
In the early days of Linux, the software years were like dog years in that they packed a lot of change and growth into a relatively small amount of time. Linux has long since matured into a modern software platform, and as such the pace of change has slowed significantly. The other reason is that enterprises like a slow, steady pace for production technology even as other customers, such as hyperscale datacenter operators, like to do nearly continuous tweaking.
The fact that it has been since early 2009 since a major release of SUSE Linux Enterprise Server has been launched is what tells you that it is indeed an enterprise Linux distribution. And it joins Red Hat Enterprise Linux 7 and Canonical Ubuntu Server 10.04 LTS in the race for support contracts among companies that pay for support rather than try to do it on their own.
After a more than a five year development term and a nearly eight month beta testing cycle, SUSE Linux, the commercial Linux distributor that is in the process of being sold to Micro Focus along with the rest of the Attachmate conglomerate for $1.2 billion, is rolling out SLES 12, a major version that is tuned for X86, Power, and System z mainframe processors and that does not, unlike the prior SLES 11 version, support Intel's Itanium processors.
SLES 12, which went into beta testing in March of this year, is base don the Linux 3.12 kernel, and according to Matthias Eckermann, senior product manager for SUSE Linux Enterprise Server, the tested scalability of the new SLES 12 was pushed quite a bit higher than with SLES 11. The kernel is tuned to go well beyond the 4,096 logical processors and 64 TB of main memory that was tested in conjunction with SGI with its UV 2000 shared memory NUMA systems. The kernel in SLES 12 is expected to be tested with 8,192 logical CPUs (which can be a thread or a core, depending on whether you have HyperThreading turned on or off for Xeon chips). Eckermann does not expect for the main memory to be pushed to the physical limits of the memory controllers on the Intel Xeon and AMD Opteron chips, which both now top out at 48-bit physical memory addressing. That works out to 256 TB of physical memory, and thus far no one has built a shared memory machine that can have this much physical memory attached to it. (The SGI UV 2000s top out at 64 TB, which is the upper limit of the 46-bit memory addressing used in prior generations of Xeon chips.) Eckermann tells EnterpriseTech that SUSE Linux will be working with partners to test the upper limits of scalability in the next six months or so as new hardware comes out, but for the moment SUSE Linux is only promising a maximum of 128 TB memory on X86 machinery.
Here is a table of the scalability limits for SLES 12:
The increasing memory capacity is important because in-memory processing is becoming vogue again. Companies are beginning to realize that a NUMA interconnect and shared memory has advantages over even a high-speed, low-latency InfiniBand network in terms of performance and cost, and the programming model for a shared memory system is significantly easier, too. You have to pay a premium for NUMA-connected systems, to be sure, but if you do the math, the ease of programming and use often more than makes up for the hardware expense. While it is true that 256 TB sounds like a lot of main memory, it is not a lot when many datasets are larger than this. And while the SLES 12 kernel can, in theory, support up to 1 PB of main memory on X86 and Power architectures, it will probably be a long time before we get that much physical memory into a single machine.
SLES 12 only supports 64-bit kernels, but there is a 32-bit runtime environment that will allow 32-bit applications compiled for earlier generations of processors to run on the system. The KVM and Xen hypervisors embedded in SLES 12 are similarly able to host 32-bit versions of operating systems and 32-bit applications atop them should customers have applications they want to run without having to recompile them for a larger memory space.
Like other commercial Linuxes that have come out in recent weeks, SLES 12 supports the new little endian byte ordering that has been etched into IBM's relatively new Power8 processors. Up until now, Power chips supported big endian byte ordering, but now, with little endian support, applications that have been written for X86 processors, which have little endian byte ordering, can now be more easily ported to Power8 chips. (IBM's System z mainframes already supported a little endian mode, but in the early days of Linux on the mainframe fifteen years ago, they had only a 31-bit memory addressing. System z mainframes have been 64-bit for many generations now.)
The KVM and Xen hypervisors have their own limitations in SLES 12. For KVM, the number of virtual machines per host system is in theory unlimited, but practically speaking, the limit is that the total number of virtual CPUs can be no greater than eight times the number of processor cores in the host system. Each VM can address up to 256 virtual CPUs (which are threads or cores, depending on whether they have multithreading or not) and up to 4 TB of virtual memory. A virtual machine can have up to eight virtual network interface cards on the embedded KVM in SLES 12, and up to twenty virtual I/O block devices. The Xen hypervisor, which doesn't get as much love and attention as it used to but which is at the heart of the AWS, Rackspace Hosting, and SoftLayer public clouds, also was updated with SLES 12. But it has considerably less scalability for its VMs, with a maximum number of 64 virtual machines per host, 64 virtual CPUs per VM, and 512 GB of virtual memory per VM.
The Virtual Machine Driver Pack 2.2 add-on to SLES 12 adds support for SLES 12 drivers as well as for Microsoft's Windows Server 2012 R2 and Windows 8.1. This driver pack is intended to speed up the performance of unmodified operating systems running atop Xen or KVM hypervisors inside of SLES 10 SP4, SLES 11 SP3, and SLES 12. The driver pack also has tools for porting guest partitions from Xen to KVM, and it is not included in the base price for support contracts.
The one thing that SLES 12 does not support is the first wave of 64-bit ARM server processors coming from Applied Micro, AMD, Cavium, Broadcom, and Marvell. But don't get the wrong idea. That does not mean that SUSE Linux is ignoring the potential for an ARM rebellion in the datacenter. The OpenSUSE development release of the company's Linux does support 64-bit ARM architectures and the internal build system that controls both the OpenSUSE and SLES variants can roll up Linux stacks for ARM processors if need be.
"I am not 100 percent sure how that market will develop there," explains Eckermann. "I cannot foresee the future, but we are prepared for it."
Applied Micro is shipping its X-Gene1 and AMD is getting ready to ship its "Seattle" Opteron A series in products with partners soon. Broadcom and Cavium are expected to get their 64-bit server-class chips into the field early next year. There is no sense is rushing the operating system out there before the hardware is available.
With SLES 12, SUSE Linux is supporting Linux software containers, also known as LXC, as an alternative to full-scale, hypervisor-based virtual machines based on Xen or KVM. LXC was developed by the Linux community in conjunction with search engine giant Google, which has also opened up its Kubernetes project for managing LXC and now Docker containers on its Google Compute Engine public cloud. SUSE Linux has been supporting LXC for the past two years in SLES 11 SP3. Docker is in technical preview with SLES 12 and is interfaced with the KIWI – formerly known as SUSE Studio – Linux stack creation tool. Software containers are taking off like wildfire on Linux, and Microsoft has just confirmed that it is prepping container technology of its own for Windows Server and is committed to interfacing it with the Docker management tools used for Linux systems.
Within the SLES 12 stack, SUSE Linux has replaced the Oracle MySQL variant of that database with the MariaDB variant. In the release notes for SLES 12, the OpenJDK variant of the Java runtime and virtual machine environment is in tech preview, and SUSE Linux says that it will support IBM's Java 6 variant of the Java tools until September 2017 for X86 and System z platforms. The KVM hypervisor is in tech preview on Power-based systems. IBM is shipping a production version of its own, called PowerKVM, already for Power Systems machines and already has a System z variant of KVM in the field, too. So now shops mixing Power, mainframe, and X86 iron can have a consistent hypervisor across those platforms.
As for file systems, SUSE Linux has been supporting XFS for a dozen years now and continues to do so with SLES 12. But the default file system for the operating system functions for SLES 12 is not XFS, but the Btrfs "copy on write" file system. Btrfs was added toward the tail end of the SLES 11 service pack cycle as an approved file system, and has been the default file system for operating system files during the entire beta phase of SLES 12. By moving to Btrfs and the Snapper snapshotting tool created by the SUSE Linux team, SLES 12 can offer full system rollback or service pack rollback in the event a patch to the operating system goes awry. Eckermann says that SUSE Linux is recommending the use of XFS as the default for application data. The older ext4, Reiserfs, and OCFS 2 file systems are still included in the distribution, but are not recommended.
"It really depends on the workload," says Eckermann, referring to the file system choice. "If you need specific performance, you have to test the file systems. There are so many different variables that you have to test the full stack, including applications, to get the best performance. But the best average is to use Btrfs for the OS and XFS for the data."
In other previews, SUSE Linux is also talking about its KGraft live patching for the Linux kernel, but this feature has not been added as yet to SLES 12. It is reasonable to guess that KGraft will be launched at the SUSECon conference next month, but SUSE Linux is mum on the subject.
One other change that is coming with SLES 12 is a new packaging and updating of rapidly changing features in the SLES stack called modules:
The modules are distinct from the various extensions that SUSE Linux has for workstations, software development, and high availability clustering, which carry fees that are different from base SLES support contracts. The modules will not carry extra fees, but they will be tweaked at a rate that is distinct from the SLES 12 initial release and follow-on service packs. Eckermann says that the programs in these modules need to be updated at their own rate, distinct from the pace of the thirteen year cycle for support for a SLES version. The legacy module helps companies move from older SLES 10 and SLES 11 versions by moving ahead selected programs from these versions to SLES 12. The web and scripting module packages up a popular tools like PHP, Python, and Ruby on Rails and updates them every year and a half. The public cloud module wraps up a bunch of tools that have been created for deploying SLES on Google Compute Engine, Microsoft Azure, and Amazon Web Services and puts them all in one place and updates them as they change.
Pricing for SUSE Linux Enterprise Server 12 is the same as for the prior 11 version, and in fact a support contract allows customers to install either SLES 11 or SLES 12 as they see fit. A standard 9x5 support contract costs $799 per year for a two-socket X86 server and a priority 24x7 contract for the same machine costs $1,499. On Power Systems machines, the standard support costs $1,700 per year for a two-socket machine and priority support costs $2,000. SUSE Linux costs $15,000 per core per year on the System z mainframe for that standard support and $18,000 per core per year for priority support. You can see all of the extensions and discounts for three-year contracts on this price list.
