SDF overview and terminology
A Solution Definition File (SDF) contains information about all Metaswitch products in your deployment. It is a plain-text file in YAML format.
-
The deployment is split into
sites
. Note that multiple sites act as independent deployments, e.g. there is no automatic georedundancy. -
Within each site you define one or more
service groups
of virtual machines. A service group is a collection of virtual machines (nodes) of the same type. -
The collection of all virtual machines of the same type is known as a
VNFC
(Virtual Network Function Component). For example, you may have a SAS VNFC and a MDM VNFC. -
The VMs in a VNFC are also known as
VNFCIs
(Virtual Network Function Component Instances), or justinstances
for short.
Some products may support a VNFC being split into multiple service groups. However, for custom Rhino application VMs, all VMs of a particular type must be in a single service group. |
The format of the SDF is common to all Metaswitch products, and in general it is expected that you will have a single SDF containing information about all Metaswitch products in your deployment.
This section describes how to write the parts of the SDF specific to the custom Rhino application product. It includes how to configure the MDM and custom VNFCs, how to configure subnets and traffic schemes, and some example SDF files to use as a starting point for writing your SDF.
Further documentation on how to write an SDF is available in the 'Creating an SDF' section of the SIMPL VM Documentation.
For the custom Rhino application solution, the SDF must be named sdf-rvt.yaml
when
uploading configuration.
Structure of a site
Each site in the SDF has a name
, site-parameters
and vnfcs
.
-
The site
name
can be any unique human-readable name. -
The
site-parameters
has multiple sub-sections and sub-fields. Only some are described here. -
The
vnfcs
is where you list your service groups.
Site parameters
Under site-parameters
, all of the following are required for the custom Rhino application product:
-
deployment-id
: The common identifier for a SDF and set of YAML configuration files. It can be any name consisting of up to 20 characters. Valid characters are alphanumeric characters and underscores. -
site-id
: The identifier for this site. Must be in the formDC1
toDC32
. -
fixed-ips
: Must be set totrue
. -
vim-configuration
: VNFI-specific configuration (see below) that describes how to connect to your VNFI and the backing resources for the VMs. -
services:
→ntp-servers
must be a list of NTP servers. At least one NTP server is required; at least two is recommended. These must be specified as IP addresses, not hostnames. -
networking
: Subnet definitions. See Subnets and traffic schemes. -
timezone
: Timezone, in POSIX format such asEurope/London
. -
mdm
: MDM options. See MDM service group.
Structure of a service group
Under the vnfcs
section in each site, you list that site’s service groups.
For custom VMs, each service group consists of the following fields:
-
name
: A unique human-readable name for the service group. -
type
: Must be one ofcustom
. -
version
: Must be set to the version of the CSAR.The version can be found in the CSAR filename, e.g. if the filename is
custom-4.0.0-12-1.0.0-vsphere-csar.zip
then the version is4.0.0-12-1.0.0
. Alternatively, inside each CSAR is a manifest file with a.mf
extension, whose content lists the version under the keyvnf_package_version
, for examplevnf_package_version: 4.0.0-12-1.0.0
.Specifying the version in the SDF is mandatory for custom Rhino application service groups, and strongly recommended for other products in order to disambiguate between CSARs in the case of performing an upgrade.
-
cluster-configuration:
→count
: The number of VMs in this service group. -
cluster-configuration:
→instances
: A list of instances. Each instance has aname
(the VM’s hostname) and, on VMware vSphere, a list ofvnfci-vim-options
(see below). -
networks
: A list of networks used by this service group. See Subnets and traffic schemes. -
vim-configuration
: The VNFI-specific configuration for this service group (see below).
VNFI-specific options
The SDF includes VNFI-specific options at both the site and service group levels.
At the site level, you specify how to connect to your VNFI
and give the top-level information about the deployment’s backing resources,
such as datastore locations on vSphere, or availability zone on OpenStack.
At the VNFC level, you can assign the VMs to particular sub-hosts or storage devices
(for example vSphere hosts within a vCenter),
and specify the flavor (as defined in your node-parameters.yaml
that you passed to VMBC) of each VM.
Options required for custom VMs
For each service group, include a vim-configuration
section with the flavor information,
which varies according to the target VNFI type:
-
VMware vSphere:
vim-configuration:
→vsphere:
→deployment-size: <flavor name>
-
OpenStack:
vim-configuration:
→openstack:
→flavor: <flavor name>
-
VMware vCloud:
vim-configuration:
→vcloud:
→deployment-size: <flavor name>
When deploying to VMware vSphere, include a vnfci-vim-options
section for each instance
with the following fields set:
-
vnfci-vim-options:
→vsphere:
→folder
May be any valid folder name on the VMware vSphere instance, or""
(i.e. an empty string) if the VMs are not organised into folders. -
vnfci-vim-options:
→vsphere:
→datastore
-
vnfci-vim-options:
→vsphere:
→host
-
vnfci-vim-options:
→vsphere:
→resource-pool-name
For example:
vnfcs:
- name: custom
cluster-configuration:
count: 3
instances:
- name: custom-1
vnfci-vim-options:
folder: production
datastore: datastore1
host: esxi1
resource-pool-name: Resources
- name: custom-2
...
vim-configuration:
vsphere:
deployment-size: medium
For OpenStack and VMware vCloud,
no vnfci-vim-options
section is required.