...
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.