A typical Cisco ACI Multi-Site deployment requires a 3-node cluster of Multi-Site Orchestrators to manage all the sites' fabrics in your Multi-Site environment. You can choose to deploy the Orchestrator cluster in one of the following ways:

• Starting with Release 2.2(3), you can deploy the Multi-Site Orchestrator cluster in a Cisco Application Service Engine.

  Cisco Application Service Engine itself can be deployed using a number of different form factors, such as a Cisco Application Service physical appliance (.iso), in a VMware ESX virtual machine (.ova), in Amazon Web Services (.ami), or in Linux KVM (.qcow), all of which are supported for Multi-Site Orchestrator installations. Installing and configuring the Application Service Engine is outside the scope of this document and is described in Cisco Application Services Engine Documentation.

  We recommend this approach for all new ACI Multi-Site deployments, because it provides a common platform to streamline multi-product integrations, additional security through Cisco Secured Development Lifecyle (CSDL) and removal of root access to Orchestrator application, file system protection, and single click upgrades to future releases.

  Installing and configuring the Orchestrator cluster in an Application Service Engine is described in the Deploying in Cisco Application Services Engine chapter. Upgrading Service Engine Orchestrator deployments is described in the Upgrading or Downgrading Orchestrator Deployments in Application Service Engine chapter.

• Alternatively, you can deploy each Orchestrator node directly in VMware ESX VMs.

  When deploying in ESX VMs, you can choose one of the following 2 approaches:

  • Use Cisco-provided Python scripts to deploy the entire Multi-Site Orchestrator cluster. The scripts allow you to execute the deployment and later upgrades remotely, for example from your laptop, as long as you have access to the vCenter where the Orchestrator VMs are to be deployed.

    This is the preferred approach when deploying an Orchestrator cluster in ESX VMs as it automates a number of manual steps and allows remote execution of Cisco ACI Multi-Site Orchestrator installation and subsequent software upgrades.

  • Using an OVA image to deploy each Orchestrator VM individually. In this case you can also choose to deploy the image either using the vCenter or directly on the ESX server.

  Installing and configuring the Orchestrator cluster in VMware ESX VMs is described in the Deploying in VMware ESX chapter. Upgrading VMware ESX Orchestrator deployments is described in the Upgrading Orchestrator Deployments in VMware ESX chapter.

Single Node Lab Deployments

While production Multi-Site Orchestrator deployments require a 3-node high availability (HA) cluster, single node Orchestrator deployments are supported for lab and testing purposes. The installation and upgrade steps for single node Orchestrator differ slightly from the 3-node cluster deployments and are covered in detail in the Installing Single Node Orchestrator chapter.

Prior to Release 2.2(1), you were required to run the same APIC versions in all sites and the version of the Orchestrator that corresponded to that APIC release. During fabric upgrade you were also required to upgrade all the APIC sites first before upgrading the Multi-Site Orchestrator. For example, if you were upgrading the fabrics from APIC Release 4.0(1) to Release 4.1(1), you had to remain on Release 2.0(1) of the Orchestrator until all sites were on APIC Release 4.1(1).

Starting with Release 2.2(1), Multi-Site Orchestrator releases have been decoupled from the APIC releases. The APIC clusters in each site as well as the Orchestrator itself can now be upgraded independently of each other and run in mixed operation mode.

Mixed operation mode is supported for sites running any of the following APIC releases:

• 3.2(6) or later

• 4.0(1) or later

• 4.1(1) or later

• 4.2(1) or later

However, keep in mind that if you upgrade the Orchestrator before upgrading the APIC clusters in one or more sites, the new Orchestrator features may not yet be supported by an earlier APIC release. In that case a check is performed on each template to ensure that every configured option is supported by the target sites. The check is performed when you save a template or deploy a template. If the template is already assigned to a site, any unsupported configuration options will not be saved; if the template is not yet assigned, you will be able to assign it to a site, but not be able to save or deploy the schema if it contains configuration unsupported by the site. In case an unsupported configuration is detected, an error message will show, for example: This APIC site version <site-version> is not supported by MSO. The minimum version required for this <feature> is <required-version> or above.

The following table lists the features and the minimum required APIC release for each one: