High availability and business continuity are crucial to keep applications and services always operational.
High availability clusters allow critical services to keep running, even if servers or hardware components fail.
SUSE Linux offers a robust set of tools for creating and managing these clusters.
In this article, we explore the current state of clustering in SUSE Linux, with a focus on key technologies such as Pacemaker, Corosync, DRBD and others.
These, with minor differences are available on x86 and ppc64le.

Pacemaker: the brain of the cluster

Pacemaker is the engine that manages high availability clusters in SUSE Linux.
Its main function is to manage cluster resources, ensuring that critical services are operational and recover quickly in case of failure. Pacemaker continuously monitors resources (databases, web services, file systems, etc.) and, if it detects a problem, migrates those resources to other nodes in the cluster to keep them up and running.
Pacemaker stands out for its flexibility and ability to manage a wide variety of resources.
From simple services to more complex distributed systems, it is capable of handling most high-availability scenarios that a company may need.

Corosync: the cluster’s nervous system

Corosync is responsible for communication between cluster nodes.
It ensures that all nodes have the same view of the cluster status at all times, which is essential for coordinated decision making.
It also manages quorum, which determines whether there are enough active nodes for the cluster to operate safely.
If quorum is lost, measures can be taken to prevent data loss or even service downtime.

DRBD: the backbone of the data

DRBD (Distributed Replicated Block Device) is a block-level storage replication solution that replicates data between nodes in real time.
With DRBD, data from one server is replicated to another server almost instantaneously, creating an exact copy.
This is especially useful in scenarios where it is crucial that critical data is always available, even if a node fails.
Combined with Pacemaker, DRBD allows services to continue operating with access to the same data, even if they are on different nodes.

Other key technologies in SUSE Linux clusters

In addition to Pacemaker, Corosync and DRBD, there are other essential technologies for building robust clusters on SUSE Linux:

• SBD (Storage-Based Death): SBD is a fencing tool that isolates a misbehaving node from causing problems in the cluster.
  This is achieved by using a shared storage device that nodes use to communicate their state.
• OCF (Open Cluster Framework): OCF scripts are the basis of the resources managed by Pacemaker.
  They define how to start, stop and check the status of a resource, providing the flexibility needed to integrate a wide range of services into the cluster.
• Csync2: A tool for synchronizing files between nodes in a cluster.
  It ensures that configuration files and other critical data are always up to date on all nodes.

Current status and future trends

Clusters in SUSE Linux have matured and are adapting to new business demands.
With the growing adoption of containerized environments and with parts in different clouds, clusters in SUSE Linux are evolving to better integrate with them.
This includes improved support for container orchestration and distributed applications that require high availability beyond replicating two disks per DRBD and keeping a virtual IP alive :) Still, today, the combination of Pacemaker, Corosync, DRBD and other tools provides a solid foundation for creating high availability clusters that can scale and adapt to the needs of SAP HANA and other solutions that require high if not total availability. If you need help at SIXE we can help you.

Cheatsheet for creating and managing clusters with Pacemaker on SUSE Linux

Here is a modest cheatsheet to help you create and manage clusters with Pacemaker on SUSE Linux.
Sharing is caring!

Updated! No longer a rumor but officially supported as of July 19, 2024 (see annoucement)

A brief history of nested virtualization on IBM Hardware

Nested virtualization enables a virtual machine (VM) to host other VMs, creating a layered virtualization environment. This capability is particularly beneficial in enterprise scenarios where flexibility, scalability, and efficient resource management (if we save on CPU we do on $$$ licenses) are critical.

While it can be used for testing purposes with KVM on x86 or VMware, the performance is often suboptimal due to multiple translations and modifications of hardware instructions before they reach the CPU or I/O subsystem. This issue is not unique to these platforms and can affect other virtualization technologies as well.

On platforms like Z, although the performance impact of nested virtualization exists, improvements and optimisations in the hypervisor can mitigate these effects, making it 100% viable for enterprise use.

Virtualization layers on IBM Mainframe

Before delving into nested KVM on PowerVM, it’s essential to understand similar technologies. If the mainframe is the grandfather of current server technology, then logical partitioning (LPARs) and virtualization technologies (zVM) are the grandmothers of hypervisor solutions.

In this picture (taken from this GREAT article from Anbarasan Sekar) you can see up to 4 layers

Level 1 Virtualization: Shows an LPAR running Linux natively

Level 2 Virtualization: Shows VMs running on z/VM or KVM Hypervisor

Level 3 Virtualization: Shows nesting of z/VM Virtual Machines

Level 4 Virtualization: Shows Linux containers that can either run as stand-alone containers or can be orchestrated with kubernetes

Now have a look to this old (2010) image from the IBM Power platform architecture. Can you see anything similar? :) Let’s move on!

Deploying VMs on the top of a PowerVM Linux LPAR

If we have LPARs on Power where we can run AIX, Linux, and IBM i, and in Linux, we can install KVM, can we run VMs inside an LPAR?

Not quite; it will fail at some point. Why? Because KVM is not zVM (for now), and we need some tweaks in the Linux kernel code to support nested virtualization not just with IBM Power9 or Power10 processors, but also with the Power memory subsystem and I/O.

By examining the kernel.org mailing lists, we can see promising developments. Successfully running multiple VMs with KVM on a PowerVM LPAR means porting some fantastic mainframe virtualization technology to IBM Power, allowing us to run VMs and Kubernetes/OpenShift Virtualization on ppc64le for production purposes. This would make a significant difference if the performance penalty is minimal.CPU virtualization on Power and Mainframe systems simply allocates processor time without mapping a full thread as KVM or VMware do. Therefore, it is technically possible to add a hypervisor on top without significantly affecting performance as IBM does with LinuxOne.

Latest news for KVM on IBM PowerVM LPARs  (May 2024)

1) Add a VM capability to enable nested virtualization
Summary: This message discusses the implementation of nested virtualization capabilities in KVM for PowerPC, including module configurations and support on POWER9 CPUs.

2) Nested PAPR API (KVM on PowerVM)
Summary: It details the extension of register state for the nested PAPR API, the management of multiple VCPUs, and the implementation of specific hypercalls.

3) KVM: PPC: Book3S HV: Nested HV virtualization
Summary: A series of patches improving nested virtualization in KVM for PowerPC, including the handling of hypercalls, page faults, and mapping tables in debugfs.

For more detailed information, you can consult the following links:

• PPC KVM paravirtual interface
• lore.kernel.org/kvm-ppc
• Gautam’s Patch

Will we be able to install Windows on Power Systems (for fun)?

CAKE – Perhaps, Perhaps, Perhaps (Official Audio)

Stay tuned!!

Exiting an Oracle Unlimited License Agreement (ULA) contract and migrating to IBM Power systems can be a complex process, but executed well, it can offer significant savings and long-term benefits. In this article, we will explore how to make this transition effectively and without penalties, based on real examples.

Understanding Oracle ULA

First, it is essential to understand what an Oracle ULA entails. It’s a contract that Oracle bought from a third-party company and continues to scare and delight in equal parts. Allows unlimited use of certain Oracle software products for a specified period of time, usually between 3 and 5 years. At the end of the ULA contract, the company must declare the use of these products and this becomes their “certification” for future license audits. There is a famous saying that it is better to know the bad than to know the good. And another that the devil is in the details. In the case of Oracle, no two ULAs are the same. They are all based on the same premise “when Oracle believes it can get money from its customer”. But beyond that, there are rules of the game that, once understood, allow us to help our clients.

Steps to Exit the Oracle ULA

1. Initial audit: Prior to the completion of the ULA, we conduct an internal audit to fully understand your current usage of Oracle products. This includes identifying which products are essential and which can be replaced or discarded.
2. Future needs analysis: We evaluate the future needs of your company in terms of software and databases. This step is crucial to determine whether the transition to IBM Power is feasible and what the potential savings are.
3. Third-party licensing contract review: Since Oracle contracts can be complex, it is advisable to work with specialized Oracle licensing consultants. They can help you understand the implications of your ULA and how to get out of it without incurring penalties.
4. We negotiate with Oracle: We help you negotiate a new agreement that best suits your current and future needs.
5. Migration planning: Develop a detailed plan to migrate from Oracle to IBM Power.

Migration to IBM Power

Migrating to IBM Power involves moving Oracle database and application workloads to an IBM environment. This may include the use of IBM Db2, which is known for its high performance and security.

1. Compatibility assessment: We ensure that your current applications are compatible with IBM Power. Oracle is Oracle in all its current and future versions, but there can always be an application that requires some modification to change architecture (we do it every day and without problems).
2. Design of the new environment: Based on the previous audit, we design a new secure, simple, powerful and stable environment adapted to your needs and budget.
3. IBM Power Implementation: We help you acquire and deploy IBM Power. We configure the necessary databases and applications.
4. Data Migration: We move data from Oracle to IBM Power, ensuring that data integrity is maintained during the process.
5. Performance, HA and DR testing: Perform extensive testing to ensure that all applications and databases function correctly in the new environment.
6. Training and technical support: We train your team in the use of the new platform and if you need it, you can use our preventive maintenance and technical support services to help them.

More things to like about Oracle in Power

We have official and supported Ansible playbooks to automate all deployments and day 2 operations:

Lots of documentation:

And at SIXE, as an official IBM training provider, we ensure that your technical teams master the platform within weeks. As technicians ourselves, we guarantee that they will be very grateful for the change.

How much budget can I save by migrating Oracle to IBM Power?

In terms of costs, migrating from Oracle to IBM Power can result in significant savings, although these vary from customer to customer. Real-world examples have shown savings of 20% to 60% in total cost of ownership (TCO) by migrating from Oracle to alternative solutions such as IBM. These savings come from lower licensing costs, reduced need for high-performance hardware due to the efficiency of IBM Power, and lower maintenance and support costs.

But Oracle licenses for Power are more expensive!

True, but we have customers where we can do with 25 Power10 cores the same as with 100 in an Exadata, but IBM Power is not restricted to Oracle (although there are more than 80,000 installations worldwide). You can deploy OpenShift, SAP HANA or any other workload running on SUSE, Red Hat, AIX and IBMi. In reality, the most common use case is the consolidation of all Exadata and most x86 servers into one Power10 in each data center. Running everything on a hypervisor that is at another level, where instead of “mapping cpus” as KVM or VMWare does, the capacity of each one is shared in real time, gaining in overall system utilization as well as performance. Exadatas have been a great marketing achievement, but they are neither cheaper, nor do they deliver better performance or provide the security of IBM Power.

Conclusion

Exiting an Oracle ULA contract and migrating to IBM Power is perfectly feasible. By doing this correctly, not only can penalties be avoided but also considerable cost savings can be achieved, while improving the efficiency and technological adaptability of the company. It is essential to have the support of licensing experts and conduct a thorough analysis to ensure a successful transition.

We do not expect to have convinced you, but perhaps we could talk without obligation, discuss any questions and, if you find it interesting, perform a feasibility analysis free of charge . In the worst case, you renew the ULA as is. Just kidding (or not) :)