Red Advance

The antics of Linux vendors in the enterprise environment conjures up pictures of an elephant race on the highway. Inch by inch, Ubuntu, Red Hat, and SUSE slowly squeeze past one another, each trying to anchor its market position with a new major release. Don't expect any giant leaps or rapid overtaking maneuvers, though – all the market players focus instead on demonstrating their robustness and efficiency through perseverance and consistency.

The long-term support (LTS) of enterprise distributions is a curiosity in the otherwise fast-moving FLOSS world. Canonical, Red Hat, and SUSE launch a product and commit to maintaining it over a period of years. This long-term commitment means admins can plan for long maintenance cycles of five years or more, instead of having a major update every two years; even long-term support is available at a premium [1].

Focus on Stability

In contrast to desktop distributions, enterprise versions primarily focus on stability. Red Hat and SUSE have their own test labs, in the form of the community editions of Fedora and openSUSE, where new features take a test run before making their way into the company's enterprise product.

Enterprise distros also set the bar higher for eliminating bugs, so each update requires more work than a community distro. Red Hat, for example, refuses to distribute kernel updates or even updated versions of the enterprise distribution's packages. A new feature might be added as a tech preview in later minor releases, but for the most part, users have to wait for a major release to find anything new.

All eyes thus watch expectantly for each new enterprise release. After all, whatever Red Hat gets wrong in version 7.0 will burden the company for a long time. In this article, I show what RHEL 7 [2] really can do, what has changed compared with the previous version, and whether the update is worthwhile.

Installation

Installing a Linux system is not really anything special, especially not in these times of colorful installation routines. Red Hat remains faithful to its Anaconda base in RHEL 7, garnishing it with a simple graphical interface (Figure 1).

Figure 1: The Red Hat Installer is still based on Anaconda and offers plain cooking in the best sense of the word.

Some pitfalls still await admins who rush in. If you guide the configuration according to the icons marked with a red exclamation mark in the installer, you will end up with a working RHEL 7 installation at the end of the day; however, it will also lack practically everything you need for effective work – such as a hostname, a proper network connection, Perl, and a graphical user interface, to name just a few (Figure 2).

Figure 2: Caution: If you opt for the minimal package selection, you end up with a system without Perl or a GUI. Installing a package set makes more sense.

To aggravate the situation, the keyboard layout settings at the command line are not those you set at the start of the GUI installer. Just imagine, for example, a French or German admin sitting in front of a TTY that has a US layout assigned to it trying to type in the non-standard characters they use for their passwords.

For a far easier time, you will probably want to opt for a GUI in the package selection phase of the RHEL 7 installer. After a reboot and after agreeing to the Red Hat EULA (Figure 3), you end up in a Gnome 3 desktop with your choice of language (Figure 4), running in the special "classic" mode and with the keyboard layout that you chose  – even though Gnome insists on asking you again if you really want that layout.

Figure 3: Linux, yes, open source, yes – but still with an EULA to confirm after the reboot. On first start, admins need to click their way through the Red Hat license before they can continue.

Figure 4: RHEL 7 comes with a Gnome classic desktop, which is strongly reminiscent of Gnome  2 but also includes some Gnome 3 elements. If you choose this desktop, you can also rely on having the correct keyboard layout.

XFS Instead of ext 4

Many changes go pretty much unnoticed by admins in distributions with long-term support. The change of the default filesystem in RHEL 7 is a good example, because only a call to mount at the command line reveals that RHEL 7 uses XFS. Thus, XFS replaces the previous default ext 4, although the latter is still available.

The reason for the change, Red Hat states, is that a default installation can now use a big storage device with up to 500TB, but this just appears to be an excuse. The red hats are not saying anything about other potential motives. It is conceivable, though, that Red Hat was long dissatisfied with ext 4 because of its known performance issues and actually wanted to switch to Btrfs with RHEL 7. However, because Btrfs is not ready, and nobody can say when it will be, Red Hat may just have switched to XFS instead, because it is viewed to be equally as well integrated and stable as ext  4.

Incidentally, Btrfs is available as an option in RHEL 7, and Red Hat supplies it with its own Snapper [3] snapshot tool. If you want to try Btrfs on Red Hat systems, you can simply activate it in RHEL 7.

Big Bang on the Network

The extended network capabilities of the system are far more apparent for RHEL admins than the new default filesystem. In fact, Red Hat has come up with a whole bouquet of innovations: support for 40Gb NICs, including the team driver framework as a replacement for classical bonding; several improvements in the TCP/IP stack; and low-latency sockets, which the modified RHEL kernel also supports.

The team driver [4] in particular is symptomatic of many of the innovations in RHEL 7. Basically, the framework does no more than the previous bonding driver in the kernel, but it does this as a daemon in userland and not in the kernel. The developers expect improved performance on the one hand and less overload in high-availability installations  – the classic targets for bonding setups  – on the other.

Additionally, admins will be able to keep time far more accurately with RHEL  7, which replaces the classic ntpd with the specially built Chrony [5] and with PPTv2 support thrown in. PPT (Precision Time Protocol) is a standard for more precisely synchronized clocks than is the case with NTP. Red Hat claims the deviation is just a few microseconds.

Cloud!

In the new version of RHEL, Red Hat is putting its money on the concept of "architecture for everything." Several new functions make it clear that Red Hat Enterprise Linux 7 wants to be a big player in the cloud.

One of the arguments is the official, factory support for Docker. In the cloud environment, the current focus is on the container manager itself [6]. Basically, Docker is an extension of the Linux container format that makes it easier to create and distribute application containers.

The fact that docker enjoys official support in the RHEL release is noteworthy, because Docker itself has not been around for a particularly long time, and Red Hat is usually very careful when it comes to new features. In the normal case, a project first has to prove its value before Red Hat decides to provide support for the product for many years.

The primary objective of Docker on RHEL is to operate virtual systems without the overhead of a fully virtualized computer. In other words: Docker containers require significantly less in terms of resources than KVM-based virtual machines.

Hypervisor Improvements

Red Hat also has much to offer admins who need classic virtualization. The vendor still gives Xen the cold shoulder and relies exclusively on KVM, which is not surprising given that Red Hat swallowed up the KVM inventor Qumranet.

This situation does restrict your options if you want to use Red Hat as a host. Things look better if you want to use RHEL 7 as a guest in a virtualization environment: It comes equipped with kernel drivers for various hypervisor suites. For use with VMware, there's now even a free equivalent of VMware's tools in the form of open-vm-tools, which should make running Red Hat guests on VMware hypervisors a smooth process.

More Entropy

Red Hat has also tackled an annoying problem with which many virtualization admins are familiar: lack of entropy in virtual machines. KVM gives you the option of passing any random number generator (RNG) on the host through to your VMs in the future. This means that the VMs have access to the same source of entropy as the host system.

Speaking of interoperability, Red Hat explicitly points out that the new RHEL version offers the possibility of joining an existing Active Directory infrastructure out the box. If you have an account in an Active Directory environment, you can log into Linux hosts in this kind of setup, depending on the assigned permissions.

The intent here is for the RHEL 7 system to integrate with existing Windows environments in a much better way, thus reducing migration overhead. This feature can be especially handy where consolidated setups achieve a high degree of heterogeneity in cloud computing. If you run a mix of many Windows and Linux hosts, you will appreciate this bridge between the operating system worlds.

Storage

The innovations that Red Hat 7 has implemented in terms of storage for RHEL are also likely to be interesting for virtual environments. For example, a host with the new version of the operating system can leverage new targets for iSCSI and Fibre Channel over Ethernet (FCoE) to export devices for both protocols; the implementation in RHEL 6 was far slower compared with the new version, says Red Hat. Whether or not the new driver in RHEL really pays dividends remains to be seen. Given that a current RHEL is always the basis for many other products from Raleigh – including the Red Hat Storage Server – it must at least be assumed that Red Hat has invested much time in this feature.

System Administration and Performance

Several delicacies await system administrators looking for ways to facilitate their work. One component contributing to this is the Performance Co-Pilot (Figure  5). This framework logs and monitors various values that are relevant to the performance of the system, which will help admins see more quickly whether changes affect the performance of the system. A graphical tool gives you access to all the relevant data and helps you search for troublemakers. If you have ever spent hours investigating a system to discover the cause of its poor performance, you will be very happy with this component.

Figure 5: The Performance Co-Pilot, PCP, helps the administrator come to grips with system performance, and it provides helpful information for troubleshooting.

Additionally, several tools help improve system performance, including Tuna. Tuna lets you edit various performance-related kernel parameters and even supports profiling of various services. In combination with tuned, this provides an overall picture. Tuned can automatically set certain system parameters with the preconfigured profiles supplied with RHEL 7.

By default, parameters are preset on the basis of the RHEL product variant the customer uses. Thus, a storage server will use a different profile than a node that takes care of virtual machines. Some basic tuning is already enabled in RHEL 7 out of the box; admins can take care of the details.

In-Place Upgrades

For LTS systems, continuity during upgrades is a factor that seems secondary at first glance. Many companies have synchronized the life cycle of their hardware with the software, so that a gradual transition is the rule after the typical five years when the old hardware is out of warranty. In addition to purchasing new hardware, admins will also immediately complete the OS upgrade.

Basically, the cycle works well if you are well prepared. If a company wants to update before the hardware warranty expires, however, the approach has restrictions. Ubuntu supports an update between LTS versions out the box, and Red Hat also had an equivalent function. It was always cumbersome, somewhat buggy, and often did more harm than good. RHEL 7 aims to fix this: A dedicated "In-place upgrade wizard" facilitates the ugprade from RHEL 6 to 7.

The prerequisite for this feature is that the admin previously used RHEL 6.5. Only then is a corresponding package available; it gives you an overview of the process. Along with details of which changes will happen automatically, the report also lists changes that admins have to do themselves.

Local Install Media

Red Hat has set a stiff target for competitors to beat in terms of deployment automation: Anaconda and Kickstart are generally viewed as robust and highly functional tools. In RHEL 7, you can also use them to create a modified boot medium for installing the system. Instead of using the standard medium, you then build your own custom installation CD or USB stick.

The modified settings are immediately deployed on new systems after installation in the local setup. Basically, the function is a middle ground between bare-metal deployment tools like Cobbler [7], Foreman [8], and Chef [9] and manual configuration after the install. The advantage of modified installation media is obvious: Admins can use their own setups without needing to install a separate service for the purpose.

Red Hat Enterprise Linux 7 is the first version of RHEL officially to use the successor to the legacy SysV init system: systemd. Very few other software components have caused so much fuss in the FLOSS community since their inception. All distributions also agree basically that the old SysV init system looks very outdated and needs to be replaced by a contemporary tool.

Ubuntu and Red Hat originally moved forward with different approaches: Ubuntu's Upstart was finished quickly and made its way into Ubuntu 12.04 more than two years ago. Red Hat wanted to replace the init system with a central hub for system administration  – that is, a control center that centrally manages important services and parameters. The implementation, systemd, has now found its way into RHEL via different versions of Fedora.

First Enterprise Distribution with systemd

RHEL 7 is the first enterprise release to include systemd [10], a modern replacement for the classic init daemon-starting daemon. Systemd is already standard on many community-based Linux distros, and the migration into the enterprise space seems inevitable. Ubuntu patron Mark Shuttleworth recently announced an end to Ubuntu's work on Upstart as an init alternative, opting instead for systemd as the new standard in future versions of Ubuntu. SUSE will also turn to systemd with SLES 12.

RHEL as a Desktop

A GUI is often considered secondary in enterprise systems, because these systems primarily end up on servers. Although the distributors no longer have enterprise desktops (like the one SUSE temporarily had in its portfolio), many companies still install RHEL and its competitors on desktops to ensure a certain continuity in the employees' workplaces.

This explains why RHEL 7 comes with three different desktops. In the standard configuration, Gnome classic is used, which strongly resembles Gnome 2 in terms of look and feel. Alternatively, KDE4 and Gnome 3 are available with the Gnome shell. Most of the typical desktop tools already look prehistoric: Firefox 24 is unlikely to impress anyone; the count had already progressed to number 30 on the desktop of our lab machine.

An office suite such as Libre or OpenOffice is missing and needs to be installed manually. Additionally, the ancient 3.10 kernel that RHEL uses will soon lack support for current desktop hardware. Again, you can easily see that Red Hat is primarily targeting servers with RHEL. A Fedora installation is advisable anyway for everyday use, even if you can add new features to the old kernel via backports.

High-Availability Drama

At the very end of the RHEL 7 changelog, you'll find some remarks on the topic of high availability. It almost looks as if the manufacturer did not want to advertise this feature, although RHEL 7 has changed more in terms of high availability than it has for several major RHEL versions. As of RHEL 7, Red Hat joins the Pacemaker camp as the last manufacturer to adopt the de facto standard for cluster management on Linux.

Although SUSE has invested a large sum in promoting the development of Heartbeat 1 and 2 in the past 15 years, Red Hat preferred to go its own way: Red Hat carved an HA solution from the Piranha backup software that was later renamed Red Hat Cluster Suite (RHCS) [11]. When many companies agreed on a common standard for cluster communication in the scope of the Service Availability Forum (SAF), even the red hats had to join the group.

Red Hat developers wrote the first FLOSS implementation of AIS, the application interface specification. Novell picked up the ball at the time and instructed its own developer, Andrew Beekhof, to rebuild Heartbeat 2 so that it worked with what was then called the openAIS suite. Pacemaker was born [12].

Red Hat would not be Red Hat if it had not found a unique way to integrate Pacemaker. Corosync [13], as a successor to open AIS and Pacemaker, works perfectly in this combination. Red Hat decided, however, to recycle cman from the RHCS and add Pacemaker as its sidekick. If you have already successfully built a Pacemaker setup on other distributions, you need to relearn for Red Hat.

This is also true of modifying the cluster configuration. Pacemaker still internally uses an XML file that contains all the resources. SUSE contributed a tool for editing the XML file via plain text files years ago, crmsh [14], which translates between text and XML formats.

However, Red Hat did not want the CRM shell and began to work on PCS, which is the standard tool for cluster configuration in RHEL 7. Most tutorials on the net, however, still refer to the CRM shell, which is clearly superior to PCS in terms of its feature set. If you use RHEL 7 to implement high availability, you get Pacemaker, but in a flavor that tastes like Red Hat (Figure 6).

Figure 6: RHEL 7 is the first version of RHEL to come with Pacemaker – a Red Hat-style Pacemaker.

Conclusions

Red Hat Enterprise Linux 7 is a solid upgrade that will not disappoint the expectations of passionate Red Hat admins. Some innovations are really smart; the performance profiles offer up to 40 percent speed advantage over older versions of RHEL, according to the advertising blurb from the Red Hat marketing department.

The core of the operating system, Linux 3.10, is a typical Frankenstein kernel – as usual for enterprise systems  – that has been dragged kicking and screaming over a huge pile of patches to support the current state of the art, Linux 3.15. If you were thinking of installing RHEL 6, there is no reason not to go straight for RHEL 7. Whether or not the features warrant a dedicated update can only be clarified by individual analysis. In my case, however, there is no urgent, across-the-board reason to update RHEL 6 to the new version.