...
This deployment means that MediationZone is deployed as a VNF in an NFV Infrastructure, provided by an NFV-I vendor.<picture>
...
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.
...
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.<picture>
...
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.
...
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.