MDM site-level configuration
In the site-parameters, include the MDM credentials that you generated when installing MDM:
-
the CA certificate, static certificate, and static private key go into an
mdmsection of thesite-parametersunder the keysmdm:→ca-certificate,mdm:→static-certificateandmdm:→private-keyrespectively -
the public key from the SSH key pair goes into the
sshsection of thesite-parameters.
Include the option mdm: → ssl-certificate-management with the value static.
Copy certificates and keys to the SDF in their plain-text Base64 format,
including the BEGIN and END lines,
and as a multi-line string using YAML’s |- block-scalar style
that keeps all newlines except the final one.
Overall, it should look like this:
site-parameters:
mdm:
static-certificate: |-
---- BEGIN CERTIFICATE -----
AAAA.....
---- END CERTIFICATE -----
ca-certificate: |-
---- BEGIN CERTIFICATE -----
BBBB.....
---- END CERTIFICATE -----
private-key: |-
---- BEGIN PRIVATE KEY -----
CCCC.....
---- END PRIVATE KEY -----
ssl-certificate-management: staticMDM service group
Define one service group containing details of all the MDM VMs.
Networks for the MDM service group
MDM requires two traffic types: management and signaling, which must be on separate subnets.
|
MDM v3.0 or later only requires the management traffic type.
Refer to the MDM Overview Guide for further information.
|
Each MDM instance needs one IP address on each subnet.
The management subnet does not necessarily have to be the same
as the management subnet that the RVT VMs are assigned to,
but the network firewalling and topology does need to allow for communication
between the RVT VMs' management addresses and the MDM instances' management addresses,
and as such it is simplest to use the same subnet as a matter of practicality.
Product options for the MDM service group
For MDM product options, you must include the consul token and custom topology data.
-
The consul token is an arbitrary, unique string of up to 40 characters generated during MDM installation (for example, a UUID).
-
The custom topology data is a JSON blob describing which VNFCs in the deployment communicate with which other VNFCs. See the example below. You need to add an entry for group name
DNSwith no neighbours, and one for each node type in the deployment with the neighbourSAS-DATA.
|
|
The |
Use YAML’s |- block-scalar style for the JSON blob, which will keep all newlines
except the final one.
Overall, the product options should look like this:
vnfcs:
...
- name: mdm
product-options:
mdm:
consul-token: 01234567-abcd-efab-cdef-0123456789ab
custom-topology: |-
{
"member_groups": [
{
"group_name": "DNS",
"neighbors": []
},
{
"group_name": "RVT-<node type 1>.<site_id>",
"neighbors": ["SAS-DATA"]
},
{
"group_name": "RVT-<node type 2>.<site_id>",
"neighbors": ["SAS-DATA"]
},
...
]
}
...