• Skip to main content
  • Skip to primary sidebar

Award Consulting

Metaswitch consultants

  • Home
  • About
  • Services
  • Articles
  • Contact

How to configure VMware anti-affinity rules for Metaswitch products

December 10, 2018 By Andrew

We sometimes work with service providers who are nervous about deploying their Metaswitch applications in a virtual environment – and one of the most common stumbling blocks is the implementation of anti-affinity rules.

In this article we will

  • explain what these are
  • provide step-by-step instructions for setting up these anti-affinity rules.

What is an anti-affinity rule?

An anti-affinity rule in VMware is a statement that keeps you from putting paired (redundant) applications on the same host.  If both applications are together and the host goes down, you lose service while VMware spins up the VMs on another host. This can all be avoided by adding an anti-affinity rule that says (for example): CFS A and CFS B cannot be on the same host at the same time.

To help explain better,  I’d like to introduce you to Eric.

Young Eric, with a short beard. Artwork courtesy of Rachel, aged 6

Eric is responsible for the IT infrastructure for a virtualized Metaswitch deployment – meaning he has to configure vSphere and VMware according to Metaswitch best practices.

Eric configures the deployment as best he can, but doesn’t set up any anti-affinity rules. Initially no-one notices a problem. Figure 1 shows Eric’s pristine new deployment of a CFS pair, where CFS A is placed on Host 1, CFS B is on Host 2 and Host 3 is a spare.

Figure 1: Normal Operation

This situation continues for years and everyone is happy. Eric’s gets married, has a daughter and grows his beard longer.

Eric at the park. Artwork: Rachel

Unfortunately Eric’s blissful ignorance won’t last. One Saturday morning Eric is at the park watching his daughter’s T-ball game when there’s a hardware failure and Host 1 goes down.

Since young Eric did not configure an anti-affinity rule, vSphere spins up a replacement for CFS A on the same host as CFS B (Host 2) as shown in Figure 2.

Figure 2: Bad placement after Host 1 failure

Can anyone see the problem here?

Luckily for Eric, there is no service disruption just yet, as CPU B took over seamlessly when CPU A went down… but now it’s just a matter of time. Eric’s not a total idiot, so he orders a new server to replace Host 1. The new server arrives and is installed, but the VMs stay running on their existing host machines (per Figure 2).

A couple of months later Eric takes a beach vacation with his family – they find a beautiful resort on a Caribbean island far away from the stresses of life and work and internet access.

Eric’s family on vacation at the beach. Artwork courtesy of Esther, aged 8.

While Eric is enjoying the Caribbean sun, Host 2 also has a hardware issue and fails. Since both CFS A and CFS B are running on Host 2 this results in a full service outage and some hard down time while the two VMs are restarted on the available hosts.

This makes everyone unhappy.

Everyone is mad at Eric. Artwork: Rachel

So how could this have been prevented? How could Eric’s beach holiday have been saved?

If young Eric had correctly implemented anti-affinity rules then vSphere would have known that CFS A and CFS B should never run on the same host, and therefore when Host 1 failed, CFS A would have been re-instantiated on Host 3, as shown in Figure 3.

Figure 3: Correct Placement after Host 1 Failure

As a result, any subsequent failure would have maintained service, which would have left Eric, Eric’s boss, and Eric’s whole family feeling happy.

Everyone is happy. Artwork: Rachel

And they all lived happily ever after.

Whatever. That’s enough about Eric. What you really want to know is… how do we set up anti-affinity?

How to configure anti-affinity for Metaswitch applications in vSphere

After all that, it’s actually pretty simple to set this up. We simply add a rule to vSphere that says, CFS A and CFS B are not allowed on the same host at the same time.

Here is a step-by-step example of how to do that using the vmWare vSphere 6.5.0 Web Client.

  1. First, find the cluster.  In this case it is named Metaswitch.  Then go to the Configure tab in the middle.
  2. Find the VMHost Rules section and click on Add.  You will then get a pop-up. Enter a name – in this case “CFS Pair”, Enable the rule and select Separate Virtual Machines as the Type.
  3. Next click on Add and it will supply a list of your VMs.  Select the two CFSs so that it ends up looking like this:
  4. Click on OK and you are done.  You now have a rule that will keep the CFSs from residing on the same host.

Which applications need anti-affinity rules?

Only paired applications (or N+K pooled applications) need anti-affinity rules.  The full list of affected applications is:

  • AMS, AGC/MGC, CFS, DCM, ESAP, Perimeta, MRS, MVD, OBS, RPAS, EAS SSS (this list can be found in the Metaswitch VMware Deployment Guide).

Other devices that rely on VMware’s own HA function to cope with failures, do not need anti-affinity rules. The list of these applications is:

  • MVS, SAS, EAS DSS, N-series.

Ultimately, once you know how to do it, creating anti-affinity rules for Metaswitch paired devices is simple.  A few simple mouse clicks in vSphere keeps your VMs on appropriate hosts in the future as your network has its ups and downs.

If you’re setting up Metaswitch in VMware for the first time and would like a second set of eyes to make sure you end up like “happy Eric” please contact us to set up a consultation.

About Andrew

Award Consulting is focused on helping ILECs and CLECs who use Metaswitch products to thrive as they improve their networks through migrations, strategic projects and improved service offerings.

Our goal is to create highly specific, highly valuable content targeted specifically at US regional service providers, and especially those who are running Metaswitch equipment. Join our email list to be notified of new content.

Primary Sidebar

Our goal is to create highly specific, highly valuable content targeted specifically at US regional service providers, and especially those who are running Metaswitch equipment. Join our email list to be notified of new content.



Articles by Theme

  • Hosted PBX (18)
  • Hosted Voice Platforms (8)
  • Interviews (1)
  • IP Networks (18)
  • Network Evolution (33)
  • Network Ops (68)
  • Product (20)
  • STIR-SHAKEN (30)
  • Strategy (25)
  • Technical (41)
  • TelcoBridges (1)
  • Uncategorized (1)

© Award Consulting 2026