Deployment Environments
- Sandra Dusic
This section details the different environments/ecosystems where MediationZone can be deployed.
For all High Availability deployments, external cluster management software (“orchestrators”) must be used to ensure failovers are executed. MediationZone provides HA monitor scripts, the results of which are sent to the cluster management software, interpreted by it, and results in actions being taken by it, such as starting failed nodes on other hosts or failing over from an active to a standby instance.
Which orchestrators to use depend on the environments. See the details below.
Physical Hardware Deployment
This is the traditional way to deploy MediationZone. EZ, CZ, and DZ can share hosts or be distributed on separate hosts, all according to the specific requirements of individual deployments.
The most commonly used cluster management software for HA in physical deployments is Veritas, Red Hat Cluster, SUN, and HP MC/ServiceGuard.
Virtual Deployment
Virtual Deployment allows more flexible HA and scaling options than physical hardware deployments.
Amazon EC2 Deployment
This deployment means that MediationZone is deployed in Amazon EC2 on Xen hypervisors. This scenario makes use of some Amazon-specific services for HA:
Amazon Instance Store (VM-local) should be used for any data that can be lost due to instance failure.
Amazon EBS should be used for HA block storage, for DZ.
Amazon EFS or GlusterFS should be used for HA clustered file systems, if required for a
particular use case, e.g. inter-site replication.
Amazon Oracle-as-a-Service should be used as MZDB, for DZ.
Auto scaling should be used to ensure the correct number of running instances in EZ. Note that
this is not applicable to all scenarios; individual use cases must be analyzed. MediationZone is running in production on Amazon EC2 since 2015.
OpenStack Deployment
This deployment means that MediationZone is deployed in OpenStack using either KVM or VMware hypervisors, which includes various NFV infrastructures based on OpenStack. This scenario makes use of some OpenStack-specific services for HA:
Ephemeral (VM-local) storage should be used for any data that can be lost due to instance failure.
Cinder should be used for persistent HA block storage for any data which cannot be lost due to failure. It is assumed Cinder volume data replication is provided by the OpenStack infrastructure.
Ceph or GlusterFS should be used for HA clustered file systems, if required for a particular use case; for example, inter-site data replication. It is assumed such clustering is provided by the OpenStack infrastructure.
HEAT and Ceilometer should be used to ensure the correct number of running instances in EZ, together with a HEAT policy template file in YAML format.
Corosync and Pacemaker should be used for HA orchestration. MediationZone has been verified on the Juno OpenStack release (2014.2.2).
VMware Deployment
This deployment means that MediationZone is deployed in VMware’s vSphere environment. This scenario makes use of some VMware-specific services for HA:
Ephemeral (VM-local) storage should be used for any data that can be lost due to instance failure.
VMFS should be used for persistent HA block storage for any data which cannot be lost due to failure. It is assumed VMFS volume data replication is provided by the vSphere infrastructure.
Ceph or GlusterFS should be used for HA clustered file systems, if required for a particular use case; for example, inter-site data replication. It is assumed such clustering is provided by the vSphere infrastructure.
vSphere HA Host Monitoring should be used to restart VMs if an ESXi host fails.
vSphere HA Isolation Response should be used to shutdown VMs that get isolated due to a
network partition.
vMotion should be used to ensure the correct number of running instances in EZ.
vSphere Replication can optionally be used for cross-site backups, as a disaster recovery
strategy.
VM High Availability and VM Fault Tolerance can optionally be used to provide even stronger
HA orchestration.
It is also possible to use non-VMware-specific technologies for storage, e.g. using NFS for persistent HA block storage. For this case, it is assumed that NFS volume data replication is provided by the NFS infrastructure.
Likewise, external cluster management software can be used for MediationZone application-specific failure detection and recovery procedure execution; typically the same ones used for physical hardware deployment.
MediationZone has been verified on vSphere 5.x and 6.x.
NFV Deployment
This deployment means that MediationZone is deployed as a VNF in an NFV Infrastructure, provided by an NFV-I vendor.
NFV deployments can be just as varied as non-NFV deployments, and it is not simple to capture every possible MediationZone product in a single diagram. The main difference from MediationZone’s perspective compared to the previously mentioned virtual deployment options is integration with the NFV MANO layer. MediationZone Common O&M APIs are used by the VNF Manager to collect, deploy, instantiate, scale and shutdown metrics.
A MediationZone VNF deployment descriptor describes topology and policies to be enforced by the MANO layer. This includes defining anti-affinity policies. EZ, CZ and DZ may consist of multiple VNFCs depending on the availability level chosen.
MediationZone is verified in HPE’s Helion OpenNFV 2.1 and Nokia’s Telco Cloud NFV Infrastructures, both of which are based on OpenStack.
NFV deployments must be done on any of MediationZone’s supported Linux distributions.
Hardware Independency
MediationZone does not directly depend on any specific hardware, being Java-based. Nor does it need to be aware of the specifics of any particular Hypervisor, VIM or NFV Infrastructure, except for details regarding deployment of virtual machines and the assignment of VM identity.
EMS
CZ takes the role of EMS in an NFV deployment. It is possible to run MediationZone in a programmatic- only mode where the MediationZone Desktop GUI is not used. It requires a case-by-case analysis to clarify integration requirements with external orchestrators.
Metrics and Statistics
Metrics and statistics are provided via the System Insight API. These are intended to inform the VNF Manager / NFV Orchestrator regarding scaling policy decisions.
Multi-Tenancy
MediationZone uses a single tenancy model. Each tenant should use a separate VNF instance.
Service Chaining
Workflow logic in MediationZone can make routing decisions dynamically based on any field in processed data, combined with external reference data. This enables programmatic control of north/southbound routing, making MediationZone highly service chain-friendly.
VNF Manager
While not the preferred way to deploy MZ in NFV infrastructures – MZ prefers to be managed by an external generic VNF-M - in case MediationZone is required to act a VNF Manager, it can be configured to assume this role. It is assumed it only manages a single VNF controlled by one MediationZone CZ; it’s further assumed that the Element Manager is hosted within the MediationZone VNF’s CZ. Note that for this kind of deployment, the VNF-M is installed as a separate MZ cluster. Procedures supported by the VNF Manager for its VNF are in accordance with the current support in the MediationZone VNF itself, see the following sections. The following lifecycle operations are in the scope of the VNF Manager:
Onboarding
Instantiation
Scaling
Configuration
All provisioning and processes needed for interaction with NFV-O, VIM, and other network elements needs to be scoped in an implementation project since these vary significantly between different NFV infrastructures, vendors, and environments. Interfaces towards EM and VNF are assume to be internal, while the external interfaces towards NFV Orchestrator (Or-Vnfm) and VIM (Vi-Vnfm) are assumed to be REST-based. It is preferred that resource requests towards VIM are done via the NFV-O, but it is also possible for the MZ-based VNF-M to implement the VI-Vnfm interface directly towards VIM if needed.
VNF Deployment and Instantiation
MediationZone is assumed to be delivered as a VM image in QCOW2 format. DigitalRoute assumes that a basic Linux image is provided by the customer, complying with customer environment-specific OS storage, networking, hardening and configuration policies, on which DigitalRoute then installs MediationZone, creating a new image which is the deliverable from DigitalRoute. A deployment descriptor containing topology information is also part of the VNF delivery.
MediationZone normally comes with two common images, one for CZ (Platform) and one for EZ (EC/ECSA/SC) VNFC types. However, when circumstances merit it multiple image types can be delivered – e.g. for deployments where CouchBase is part of DZ, or GlusterFS is used. These images do not contain any site-specific information, but must be configured during image bootstrapping using the NFV Infrastructure’s bootstrapping mechanisms. These are environment-specific and must be clarified during an implementation project.
Details on image Linux configuration need to be determined for each specific environment, as details tend to vary, in particular in the networking area. The configuration mechanism is environment- specific, e.g. in OpenStack the metadata service is assumed to be used; config-drive is also a valid option.
Virtual Networking
MediationZone images can be configured to use SR-IOV and/or virtio for increased virtual networking performance.
Note that using SR-IOV may interfere with capabilities such as VM live migration. It also creates coupling between VM OS and the physical hardware used to run VMs.
MediationZone supports IPv4 and IPv6.
It is expected that VM IP assignment is done during bootstrapping, e.g. for OpenStack using the metadata service or Neutron, and not using DHCP.
Virtual Compute
If NUMA is used, VM sizing is recommended to fit into a single CPU socket. This increases performance since memory access is kept local. The maximum number of vCPUs per VM varies according to the physical hardware used in each individual environment.
It is possible to exceed this limit, but memory access performance may suffer.
NUMA awareness is supported by Java since version 7; except for the above, the details are abstracted from MediationZone. However, System Topology Registry can be used to schedule certain pico processes on certain virtual hosts; the mapping of virtual hosts to physical hosts and sockets is beyond MediationZone’s control.
Virtual Storage
Refer to section 3.3. It is recommended that ephemeral local storage is kept as small as possible to facilitate VM snapshots and migration.
VNF Configuration Updates
MediationZone can be configured by CLI and scripting. In release 8.0, System Topology Registry (STR) and Dynamic Configuration Management (DCM) were introduced, enabling REST-based configuration from VNF-M for system topology, workflow instances and workflow instances tables as well as for Diameter agents. This particular configuration flow tends to vary a lot between different customer environments.
This will need to be evaluated per individual deployment.
VNF Scale Out
Also known as horizontal scaling. The new VM should be provided by the NFV Infrastructure and configured using the NFV-I environment-specific bootstrapping procedure. After that, MZ has to be reconfigured to make use of the new VM. The System Topology Registry (STR) and Dynamic Configuration Management (DCM) features in 8.0 enable scaling-out programmatically, but not for all cases – specifically not for Workflow Bridge and in-memory stateful workflows such as ones doing in- memory aggregation or file-based aggregation on local file storage; more scale-out coverage will be introduced in the 8.x releases but must be done manually until then. The interface is exposed in CZ and should be accessed by VNF-M.
This will need to be evaluated per individual deployment.
Scaling of Other VNFs
There is also the opposite aspect: reacting to surrounding systems scaling in or out. When hidden behind virtual IPs, this is not an issue. For non-hidden systems, MediationZone contains a Dynamic Configuration Management (DCM) REST API that can be used to update peer information programmatically. Creating or removing workflow instances, as well as modifying Diameter profiles, are supported in 8.0. More coverage will be introduced in the 8.x releases. The interface is exposed in CZ and should be accessed by VNF-M. This must be analyzed per use case.
VNF Scale In
Also known as horizontal scaling. The VNF-C should be gracefully shut down by the VNF-M. Then, the VM should be shut down by the NFV Infrastructure. After that, depending on the use case, MZ might need to be reconfigured to balance load across the remaining VMs. The System Topology Registry (STR) and Dynamic Configuration Management (DCM) features in 8.0 enable scaling-in programmatically, but not for all cases – specifically not for Workflow Bridge and in-memory stateful workflows; more scale-in coverage will be introduced in the 8.x releases but must be done manually until then. The interface is exposed in CZ and should be accessed by VNF-M.
This will need to be evaluated per individual deployment.
VNF Scale Up/Down
Also known as vertical scaling. If the infrastructure supports live VM migration, this is as simple as migrating a VNFC to another VM with the preferred characteristics.
If not, then this is typically done by a failover of a VM to another VM with the preferred characteristics. This operation is initiated by the VNF-M.
VNF Software Upgrade
It is assumed that a parallel cluster with updated VM images is deployed by the NFV-O and VNF-M, data is replicated from the old cluster, and then traffic is cut over. For most use cases rolling upgrades are possible. The exact procedure is use case dependent, in particular on persistent state management and data loss tolerance for the particular use case, and must be determined per individual deployment.
VNF Migration
It is assumed that VNF migration is handled much like a VNF upgrade. For some cases VIM tools may be used instead, e.g. vMotion on VMware VIMs if SR-IOV is not used.
VNF Decommissioning
It is assumed this is no more complicated than performing a graceful VNF shutdown and then deleting the VNF from the NFV-O catalogues.
Google Cloud Platform Deployment
MediationZone is not verified on Google Cloud Platform, though by deploying on Linux, treating VMs like physical servers, and using external orchestrators as outlined for a physical hardware deployment, a successful deployment with HA could be achieved.
If you are interested in using MediationZone in a Google Cloud Platform environment, contact us to discuss your particular circumstances.
Microsoft Azure Deployment
MediationZone is not verified on Microsoft Azure, though by deploying on Linux, treating VMs like physical servers, and using external orchestrators as outlined for a physical hardware deployment, a successful deployment with HA could be achieved.
If you are interested in using MediationZone in a Microsoft Azure environment, contact us to discuss your particular circumstances.
Other Public Clouds
MediationZone is not verified on other public clouds like e.g. RackSpace, though by deploying on Linux, treating VMs like physical servers, and using external orchestrators as outlined for a physical hardware deployment, a successful deployment with HA could be achieved.
Docker Deployment
MediationZone can of course be deployed in Docker images. Please refer to DigitalRoute Usage Engine Private Edition for a mediation engine based on Docker images and Kubernetes.
Kubernetes/Mesos
Please refer to DigitalRoute Usage Engine Private Edition for a mediation engine based on Docker images and Kubernetes.
Cloud Foundry Deployment
MediationZone can be exposed as a Service in Cloud Foundry using the Service Broker mechanism. It is not suited to running as a Cloud Foundry Application, since these can only communicate via HTTPS and WebSockets, while one of MZ’s main usages is to integrate systems using a wide range of different protocols. If you are interested in exposing MediationZone on Cloud Foundry, contact DigitalRoute to discuss your particular circumstances.