The Mainframe versus the Server Farm - A Comparison | SUSE Communities

The Mainframe versus the Server Farm – A Comparison

Share
Share

The following article has been contributed by Carla Schroder, Technical Writer at the SUSE Documentation Team. The original article has been published in German at DataCenter Insider. A big “Thank You” to chief editor Ulrike Ostler for the permission to publish the article in English at the SUSE blog.

 

 

Google, Facebook, and Twitter own giant data centers all over the planet, and they are built with racks of commodity hardware. If thousands upon thousands of small servers networked together are good enough for Google, Facebook, and Twitter, then shouldn’t they be good enough for you? Perhaps you remember IBM’s famous commercial “The servers, they stole all our servers!“. Consolidating all of that complexity into a mainframe might be just what you need. Let’s take a look at what the mainframe really is, and consider its use cases.

Mainframe Workloads

What do you use a mainframe for? Complex, data-intensive workloads, both batch and high-volume online transaction processing (OLTP). For example, banks do a lot of both. When customers access their accounts online that is OLTP. It is real-time and interactive. After hours banks typically run batch jobs: sending out customer statements, billing, daily totals, interest calculations, reminders, marketing emails, and reporting. This may mean processing terabytes of data in a short time, and that is what mainframes excel at. Health care, schools, government agencies, electric utilities, factory operations, enterprise resource planning, and delivering online entertainment are all good candidates for mainframes. The Internet of Things–PCs, laptops, smartphones, vehicles, security systems, “smart” appliances, and utility grids–are all well-served by mainframes.

What is a Mainframe?

What exactly is a mainframe? Is it just a big computer? Is it the same as a supercomputer? The IBM z Systems servers dominate the mainframe market, owning over 90% of it; for the purposes of this discussion we’ll say that a mainframe computer is an IBM z Systems server. Once upon a time the word “mainframe” described physical characteristics, a very large computer for handling very large workloads.

A mainframe computer is distinctly different from the x86/ARM hardware we use every day. The modern IBM z Systems servers are much smaller than earlier mainframes, though they are still large. They are rugged, dependable, secure, and use the most advanced hardware. It may be helpful to think of the mainframe as a style of computing: centralized data storage and resource administration, high-demand mission-critical services, high security, high availability, robust hot-swap hardware, dynamic re-configuration of hardware and software with no downtime, massive transaction processing, backward-compatibility with older software, and massive throughput. There are multiple layers of redundancy for every component: power supplies, cooling, backup batteries, CPUs, I/O components, and cryptography modules.

Mainframe’s Specialty

Throughput is a distinct mainframe characteristic, as it supports large numbers of simultaneous transactions and massive I/O without slowing down. An x86/ARM server loses efficiency at >20% total load, and will slow down when any single component is overloaded; for example when its CPU is running at 100%, or memory is exhausted, or the hard disk thrashes. This doesn’t happen on a mainframe, which maintains peak performance up to 90% load.

We can try to replicate this robust hardware in the x86/ARM server farm, but it’s not the same. Commodity hardware is always under intense downward price pressure, and on lower-end machines a lot of functionality is offloaded to software, such as encryption and networking, which places the load on the host CPU. In contrast, the mainframe is collection of specialized discrete components that supply their own resources. Networking interfaces, cryptographic processors, and device controllers have their own controllers, power supplies, redundant connectivity, self-diagnostics and reporting, and their own cooling systems.

In-box Communication

All of that massive throughput and efficient resource utilization is enabled by in-box communications. The fastest x86/ARM cluster is limited by its network. Mainframe components communicate with each other via backplanes and thousands of specialized high-speed channels. The z Systems channel subsystem (CSS) controls all I/O operations, both internal and external. The CSS is comprised of hardware and firmware: the central processor complex (CPC), main system memory, and at least one control unit (CU). A control unit can be a standalone device, or integrated into an I/O device, the channel subsystem, or onboard the server. A single channel subsystem has multiple channel paths, and supports multiple logical partitions. Then there are multiple subchannel sets, each of which supports thousands of subchannels. All of those channels are managed dynamically to adjust to changes in workload, and to provide multiple paths for every operation.

Flexible Resources

Mainframe hardware resources are extremely configurable. A mainframe computer is divided into multiple smaller systems, which are called logical partitions or LPARs. Each LPAR runs its own operating system, and you can allocate memory and CPU very flexibly: shared, exclusively, or weighted for different circumstances. For example, the IBM z13 can manage up to 85 LPARs, which is like having 85 highly powerful servers in one box.

Mainframes also support clustering. That’s right, you can cluster multiple mainframes just like x86/ARM servers. Mainframes have a high degree of high availability functionality built into their hardware and firmware. But clustering the individual instances offers additional advantages. The cluster stack provides hard consistency guarantees and coordinates access to shared resources. This is used by cluster-concurrent file systems such as OCFS2 and GFS2. It not only protects against hardware failures but also monitors the software and initiates recovery accordingly through restarts of the services or rebooting the instance. Geographically-dispersed clusters protect against disasters. Linux features one of the most advanced, comprehensive and fully open source high-availability cluster stacks which runs also on IBM z Systems.

Is a mainframe a supercomputer? No.  A mainframe and a supercomputer are built for completely different purposes: typically a supercomputer is tuned for maximum processing power and speed, and it excels at CPU-intensive tasks. The operative words for mainframes are throughput, reliability, and rapid processing of extremely large data sets.

Pets and Cattle

The server farm uses virtualization, containers, and cloud technologies to abstract the datacenter as a single pool of resources, in an extremely complex way, with hundreds or thousands of individual components to manage and monitor, and to replace on a regular basis. Perhaps you are familiar with the “cattle, not pets” metaphor. In the container-based server farm everything is disposable. If a process fails then start a new one. If a hardware component fails replace it, and work around the failure with some kind of automatic failover that transfers its workload to a different component. You don’t nurture your individual pieces like pets, but treat them like herds of cattle, a faceless mass of disposable units. Docker, Apache Mesos, Marathon, ZooKeeper, Chef, Puppet, DC/OS… all of these new technologies enable amazingly flexible service development and delivery, at the cost of an extremely complex system that is burdened with mitigating regular failures.

Containers, Microservices, Virtualization

Virtual machines, containers, and microservices are not exclusive to the x86/ARM server farm. A mainframe supports thousands of virtual machines, and supports all of your favorite software. You can run Linux natively on the z mainframes, but most installations run virtualized on z/VM, IBM’s hypervisor technology, as the base operating system, and z/OS (IBM’s proprietary operating system) or Linux in virtual machines. The VMs are connected to a high-performance physical memory backplane, which makes intra-VM communication very fast.

For Linux-savvy system administrators, virtualization on IBM z Systems servers is getting even easier with KVM, the Linux-native virtualization technology. IBM offered their own version of KVM for IBM z Systems, and SUSE recently announced full KVM support for IBM z Systems with their SLES12 SP2 product version.

Cloud technologies offer even more flexibility and rapid re-configuration of resources. z/VM supports OpenStack, the popular open source cloud stack which provides Infrastructure as a Service (IaaS). You could use a mainframe as the hub of your operations, and add additional capacity with x86/ARM servers and public clouds.

Hands-on Mainframe Experience?

Commodity hardware is cheap and easy, and if you are using open source software you can set up a test lab for the cost of the hardware. Then you can try it out and build your skills. A mainframe is not so easy, and definitely not a do-it-yourself project. You can’t order one from Amazon or Newegg, and it has specialized power and cooling requirements. (Though due to its size and complexity, the server farm has more complicated environmental requirements.) The mainframe itself is still large and heavy. The smallest IBM mainframe, the z13s, weighs around a ton, and is the size of a large restaurant refrigerator.

While Linux, and whatever software you want to run in your VMs is the same everywhere, there is a learning curve to administering the mainframe hardware and running z operating systems. The mainframe itself is blind and dumb, so you need support elements, which is a fancy name for laptops that are directly-connected, and you need a separate storage server.

There are a few ways to try out mainframe technologies. IBM’s LinuxONE Community Cloud offers a 120-day free trial to test installing and provisioning SUSE, Red Hat, and lately also Ubuntu Linux on a z Systems server. The drawback: this service does not provide the capability to install Linux in a bare metal environment, or in a virtual machine, nor does it provide for any access to hardware management.

You can also test a z server by arranging for a Proof of Concept trial. Loaner hardware is installed at your site. Obviously this is not a trivial exercise, and this is done only when there is a very good possibility that the customer will buy the installed hardware and software.

As a qualified IBM PartnerWorld Independent Software Vendor (ISV), you can check out the IBM System z® Personal Development Tool (zPDT).

It enables ISVs to develop software for IBM z Systems without the need for the hardware. The zPDT technology creates a z Systems architecture environment allowing mainframe operating systems (including Linux), middleware, and software to run unaltered on x86-compatible platforms.

Getting Started

Mainframe prices start at around $40,000 for an entry-level system. Pricing is based on CPU cores, hardware provisioning, and software licenses, and big systems can easily run over a million dollars.

IBM publishes a wealth of Redbooks, videos, and good technical documentation. This is a great starting point for learning about mainframes and Linux on IBM z Systems.

 

Share

Comments

  • Thank you for such a level headed and informative article. It would have been nice if this article could have done some actual numbers such as

    Z13 config-a replaces 200,000 XEON servers
    Z13 config-b replaces 400,000 x86 model J servers

    etc.

    People who have never worked on big-iron really cannot begin to comprehend the I/O capabilities of that platform. They inhale data like a black hole inhales matter. Lining up your biggest, baddest x86 servers to catch the output from one of these things is like throwing sponges into Niagra Falls.

    I’m not a fan of IBM, but, even I have to admit, on its best day the biggest, baddest x86 can achieve the throughput of a fire hose. On an average day big-iron has the throughput of 12 Chicago water mains.

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Avatar photo
    31,789 views
    Meike Chabowski Meike Chabowski works as Documentation Strategist at SUSE. Before joining the SUSE Documentation team, she was Product Marketing Manager for Enterprise Linux Servers at SUSE, with a focus on Linux for Mainframes, Linux in Retail, and High Performance Computing. Prior to joining SUSE more than 20 years ago, Meike held marketing positions with several IT companies like defacto and Siemens, and was working as Assistant Professor for Mass Media. Meike holds a Master of Arts in Science of Mass Media and Theatre, as well as a Master of Arts in Education from University of Erlangen-Nuremberg/ Germany, and in Italian Literature and Language from University of Parma/Italy.