Novell's SLES 11 is packed to the gills and keeps moving at a decent clip

In our Clear Choice test of Novell's SUSE Linux Enterprise Server (SLES) 11, we found it to be packed with useful management tools, to have virtualization threaded though many of its processes, and to perform at rates close to the high bar set by past versions of the Linux bundle.

How we tested Asterisk

Archive of Network World tests

Installation is very similar to SLES 10, but included some new options. For example, there is a server scenario selection process and the choices include: Physical machine (also used for fully virtualized VMs), Virtual Machine (for paravirtualized environments like Xen) and Xen Virtualization Host (for use as a hypervisor host platform). These match the increasing number of choices allowed for Windows 2008 server editions, where VM substrates are now a part of the front-end, pre-install process.

The Xen hypervisor has been updated to Version 3.3.1. The default SLES 11 file system is now ext3. Although the previous default file system, reiserfs, is still supported, as are others including ext2, jfs, and NTFS.

The default local security policies in general seem to be a bit more restrictive. For example, when trying to shutdown the machine, the root/admin password is required by default.

There is an entirely new software management subsystem called ZYpp that is used in conjunction with the long-favored YaST setup tool to correlate the dependencies of applications with other system applications while upgrading software packages thereby helping to thwart incompatibility issues. In testing we found ZYpp speedier than previous tools, as it automated software dependency checks and delivered updated software more quickly than we've seen.

New stuff in the management and security realms for SLES 11 includes an open source program called Nagios -- a networking monitoring tool that watches network access activity for different workstations on your network.

Nagios Version 3.0.6 has a Web-based interface – so an Apache Web server must be installed as well. The default configuration needs a little fine-tuning but most of the options were pre-configured. Nagios can check whether different network services (for example SMTP, POP3, HTTP) are running, then create alerts by e-mail, cell phone or page if something stops responding. Also, Nagios has the capability to monitor basic host resources, processor load and disk usage. We turned off some services and Nagios detected it quickly and proceeded to send an e-mail to the appropriate place.

SLES 11 also includes an updated version of StrongSwan, which is an IPSec stack that can be used for creating either site-to-site or remote user VPN connections. StrongArm has been upgraded to support IPv6 tunneling. We did not test this VPN service.

Also there is a Web-based graphical management tool for IKEv2 encryption key management for various applications, including the IPV6 IPSec VPNs now permitted with StrongSwan.

And, finally, Novell has produced a YaST Security module, which consolidates a raft of formerly separate settings (file permissions, and login restrictions parameters, as a few examples) into a single and comprehensive (and finally usable) user interface. For instance, during testing we were able to make policy settings changes, and form user folder permissions without having to leap back and forth between formerly disparate user interfaces.

Novell also added Trusted Computing Platform capabilities for some encryption management capabilities, but we did not test these.

Developers arise

There are quite a number of new features in SLES 11 (although these items are missing from SLED 11) for developers, including updated versions of the application debugger gdb and the gcc application compiler. One nice new feature is the included .Net development framework dubbed Mono, which has partial compatibility with Microsoft .Net framework. Included is an application called Mono Analyzer that's used to check if your .Net application is compatible with Mono's .Net framework emulation. Novell claims about half of the .Net applications it tested worked without any changes.

Also included in the SLES 11 developer toolkit is ltrace, which is a useful command for debugging applications, similar to Sun's dtrace tool. The idea behind these two tools is to find application execution-time problems by monitoring what they do, how they branch, and most importantly, how long they take to do these things so that the application can be optimized for performance.

But unlike the Sun tool, which requires the source code to be available in order to debug the application, ltrace works by catching and retrieving the shared library calls made by the process of the application or signals received while it's running. The result is that both developers and even enlightened civilians with root-rights can watch application behavior to ascertain the nature of problems or optimizations.

Popping the kernel

SLES 11 uses the 2.6.28 Linux kernel (SLES 10 initially used 2.6.16). This new kernel is different in that it runs in a 'tickless' mode by default, which eliminates system ticks (timer events sent to the CPU at regular intervals) and therefore allows the CPU to potentially rest for long periods of time during inactivity — if applications support this conservation state, that is. This upgrade gives SLES 11 a greener side as 'tick-based' kernels are interrupted by convention a thousand times per second to see if there's work to do (see Green OS test for discussion of tickles Linux kernel).

Control groups (cgroups), comprise a new kernel feature that implements a minimal file system interface to create task groups, handle permissions and task assignments.

The cpuset system, which uses cgroups, is a new feature used to divide resources by partitioning CPU and memory resources into separate groups. Processes running inside one of the cpuset groups won't be able to run on other CPUs/cores not in the 'cgroup'. This lets administrators force applications to 'home' to a specific CPU core.

There is a command line tool, called cset, which is used to create and modify the cpuset groups. In our test, this mechanism did indeed restrict the usage to those administratively desired CPU's, when running a process inside one of the CPU sets. We could even move processes already running into a set to restrict their access to the target server CPU cores.

Another feature, 'Swap-over NFS' allows swap space (virtual memory) to be allocated onto an NFS share instead of on the local machine's hard drive. This allows one to utilize the vast storage of an NFS share, and increases our addiction to NFS (interestingly, developed by Sun).

Novell has also included some pre-release code in this bundle to give users a preview of things to come. The previews include ext4 (successor to ext3 filesystem), eCryptfs (a POSIX-compliant crytographic filesystem), iSNS (internet storage naming service), and Hot Add Memory (only applies to certain hardware, and sadly, none we had in the lab).

Gauging performance

In our business benchmark logic performance test we used the Java-based SPECjbb2005 tool. We ran tests on the native operating system running directly on the hardware server and we assessed performance in various virtualization scenarios.

For the native performance test, we had to downgrade SLES 11's Java version to 1.5 from the newer preinstalled Java 1.6 to get an equal playing field result to previous tests done with Java 1.5 running on SLES 10. After several test runs of SPECjbb2005, SLES 10.2 with Java 1.5 was able to complete an average of 33,396 Basic Operations/Sec (BOPs), while SLES 11 completed an average of 30,065 BOPs. The nominally slower performance is likely because SLES 11 uses ext3 as the default file system, which some claim is slower than reiserfs, the default files system with SLES 10.

To be fair, the Java 1.6 version supplied with SLES 11 did perform somewhat faster, hitting 42,581.5 Bops. We did not run a native test on SLES 10.2 with Java 1.6, so we have no comparative number there.

We also ran some virtualization performance tests to ascertain any changes when running both existing SUSE 10 and new SUSE 11 virtual machines (VM) on the Xen 3.3.1 hypervisor included with SUSE 11.

In this test, we ran three, SLES 10.2 VMs on a server running SLES 11 Xen 3.3.1 as the hypervisor. These VMs were the same ones used in the SLES 10.2 Xen testing. Again we had to run one set of tests of SUSE 11 with Java 1.5 in place to get the direct comparison with performance numbers gathered for SLES 10.

The overall average for the same VMs with SPECjbb2005 running under SLES 10.2 Xen 3.2 with Java 1.5 was 33,956 Bops on each VM compared with 33,264.17 bops on each VM under SLES 11 Xen 3.3.1. While these results are quite close, performance for the newer combination has decreased slightly.

In order to compare performance of SLES 10 VMs against performance of SLES 11 VMs when running on the new Xen 3.3.1 hypervisor we had to deploy Java 1.6 on both operating system versions before we could get apples-to-apples results from SPECjbb2005. The SLES 10 VMs yielded an average of 42,166 Bops/VM across test runs while SLES 11 VMs averaged 40,820.11 Bops. Based on these numbers, SLES 11 performance has decreased slightly. The overall bops count was likely higher across all VM measurements in these tests because Java 1.6 is faster than Java 1.5

We also ran tests with IOMeter to ascertain disk performance, based on test regimens we've used to test VM and native operating system performance. These tests showed very little difference between SLES 10.2 and SLES 11.

Conclusion

While many of the changes in SLES 11 are incremental, the inclusion of Mono tools and Solaris-like developer tools make us appreciate SLES 11 more as a server platform — especially as it's easier than ever to determine a server configuration and application build. Novell has paid attention to system installers that want up-front choices that are easily deployed and managed. There were a few rough edges, but Novell has done a lot to give especially busy system integrators and installers easily understood deployment configuration loads with virtualization in mind. It's their best yet.

Henderson and Allen are researchers for ExtremeLabs in Indianapolis. Contact them at kitchen-sink@extremelabs.com.

Henderson is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.networkworld.com/alliance.