You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


When you use Virtual Network Function Manager (VNFM) to deploy SBC SWe in an OpenStack cloud environment, you must provide it with a Cloud Service Archive (CSAR) package file that is appropriate for the type of deployment you want to create. The CSAR package includes a Virtual Network Function Descriptor (VNFD) file that defines the characteristics of your deployment.  

 

Unable to show "metadata-from": No such page "_space_variables"
 provides the script createVnfmCsar.py and a VNFD template file (vnfmSol001VnfdTemplate.yaml) to create a CSAR file for your deployment.

By default, from SBC 10.1.x onwards, the createVnfmCsar.py creates a 3.5.1 compliant VNFD. You can only use this with VNFM versions 21.2 onwards.

Two additional files are also supplied along with createVnfmCsar.py and vnfmSol001VnfdTemplate.yaml

vnfmSol001VnfdCustomTypes.yamltypes definition file needed for CSARs that are SOL001 3.5.1. compliant.

vnfm_pre_21_2_Sol001VnfdTemplate.yaml - VNFD template file for use with older VNFM versions.

Script Parameters

Important

The script creates one or more CSAR files based on the run-time parameters you specify. Note that the default value for several parameters is "all." If you run the script without specifying any parameters, the script uses its defaults and creates multiple CSAR files for all possible values and combinations for these parameters. Use the run-time parameters to restrict the output and create a CSAR file that is tailored to a specific deployment model.


The following tables describe the script run-time parameters. Help information for these parameters is also available by entering: createVnfmCsar.py --usage

Parameters

ParameterDescriptionDefault
-f <flavor size>
[dev | std]
Use this parameter to specify the flavor size for the SBC nodes in the deployment. For customer deployments, use the option standard (std).all sizes
-h <ha type>
[simplex | ha | n_1_ha]

Use this parameter to specify an HA model for the deployment. The options are:

  • ha to specify 1:1 HA redundancy.
  • n_1_ha – to specify an N:1 HA deployment. N can be up to 4 for S-SBC and M-SBC deployments. Use this parameter with the --num_instances parameter which specifies the number of instances in the deployment.
  • simplex – to specify a standalone instance for a test environment.
all HA models
-i <interface type>
[virtio | sriov | provider]

Use this parameter to specify the network interface type for your deployment. The options are:

  • provider to specify a provider network.
  • sriov to specify an SR-IOV (single root input/output virtualization) network.
  • virtio to specify a virtio network.
all interface types
-p <prod_version>Use this parameter to specify the SBC product version number. This parameter is required. Provide the full release number within quote marks. For example: -p "9.01.00" n/a
-q <qcow_image_file>Include this parameter to specify that you want to include the SBC software .qcow2 image file within the CSAR package. Including the image file greatly increases the size of the CSAR file and is not required by VNFM. If you use this option, specify the name of the image file following the -q parameter.no image file
-s <subversion>Use this parameter to specify the SBC release number. This parameter is required. Provide the release number within quote marks. For example: -s "R000"n/a
-v <vnfd_template>Include this parameter to specify the full path and the name of the VNFD template file. If the template file resides in the same directory as the script, the -v parameter is not needed.current directory
--cinder_boot

Include this parameter to specify that you want to create a bootable Cinder volume and copy the boot image (the .qcow2 image) to that volume before starting the VM. By default, no boot volume is created. Activating this option causes the initial boot time to increase significantly.

Use the --cinder_oam_DISK and --cinder_sbc_DISK options to specify the Cinder boot volume sizes.

Note: The ephemeral disk size is set to 0 by default when you enable creating a Cinder boot volume.

no Cinder boot volume
--cinder_log

Include this parameter to specify that you want to create a Cinder volume to use for /var/log. By default no Cinder log volume is created. You can use this option to re-associate the /var/log directory tree from a previous orchestration to a new orchestration, by specifying that boot volume during orchestration.

Note: Use the --cinder_log_DISK option to specify a size for the Cinder log volume.

no Cinder log volume
--cinder_log_DISK <disk_gb>
--cinder_oam_DISK <disk_gb>
--cinder_sbc_DISK <disk_gb>

Include these parameters to specify the disk sizes for the Cinder volumes if you specify to create a Cinder boot volume or a Cinder log volume.

If you are creating a log volume for storing log files and CDRs, consider the following formula to determine a minimum volume size to accommodate CDRs, and then add approximately 60GB for log and core files:
 (40% of peak CPS) * (records/call) * 86400 * (days) * 2K

where:

  • CPS is calls per second
  • records per call is typically one or two, and depends on your deployment
  • 86400 is the number of seconds per day
  • days is the number of days of CDR records to store

boot volume: default disk size based on specified flavor

log volume: 30 GB

--ha_io_type [virtio | sriov | provider]This parameter is deprecated. Use --ha0 [virtio | sriov | provider] to specify an interface type. See "Interface Rules" in the Specific Customer Parameters table for more information.n/a
--image_name <image_name>

Include this parameter to specify the name of the SBC software qcow2 image file you are uploading to the Glance image repository so that name appears in the VNFD file. By default a name is derived by joining the values you specify for the product (-p) and the version (-s). Note that the image name must exactly match the name of the image in Glance to allow VNFM to load the image.

make image name from product (-p) and version (-s) strings
--ipv6Include this parameter to specify that you want to use IPv6 addressing for the networks in your deployment.IPv4
--mgt_io_type [virtio | sriov | provider]This parameter is deprecated. Use --mgt0 [virtio | sriov | provider] to specify an interface type. See "Interface Rules" in the Specific Customer Parameters table for more information.n/a
--mgt_vip

Include this parameter if you want to add a virtual IP address to the management interface. Ensure the interface type is not "virtio".

no virtual IP address is added to the management interface
--num_oam_instances <num_oam_instances>

Include this parameter to specify the number of OAM node instances to create within an N:1 HA deployment that will use the OAM configuration model. For example, specify 2 to create a 1:1 HA pair of OAM nodes.

For deployments that use the Direct Single configuration model (standalone or 1:1 HA deployments), the default value of 0 applies because OAM nodes are not required. Refer to SBC SWe Configuration Management for descriptions of both models.

0
--num_instances <number>Use this parameter to specify the number of SBC instances to create within the redundancy groups in an N:1 HA deployment. The default value is 5 which creates a 4:1 HA deployment.5
--num_sbc_rg <num_sbc_rg> Use this parameter to specify the number of SBC redundancy groups to create within the VNF. The range allowed is 1 to 8. See Creating a CSAR Package File#Creating Multiple Redundancy Groups that Use the Same OAM Nodes for the procedure to create multiple redundancy groups.1
--personality
[isbc | msbc | ssbc | tsbc | mrfp | slb ]

Use this parameter to specify the type of deployment to create. The options are:

  • isbc integrated SBC deployment
  • msbc media SBC component of a distributed SBC deployment
  • ssbc signaling SBC component of a distributed SBC deployment
  • tsbc media/transcoding SBC component of a distributed SBC deployment
  • mrfp media resource function processor (MRFP) node
  • slb SIP-aware front-end load-balancer node
all types
--pkt_vipInclude this parameter to add a virtual IP addresses to the packet interfaces. Ensure the interface type is not "virtio".virtual IP addresses are not added to the packet interfaces
--pkt_oam_io_type [virtio | sriov | provider]Include this parameter to specify a type of interface for the packet ports on the OAM nodes. The options are:
  • provider to specify a provider network.
  • sriov to specify an SR-IOV (single root input/output virtualization) network.
  • virtio to specify a virtio network.

Note: SBC 9.0 and later releases do not include PKT interfaces on OAM nodes. This option should only be used to generate a VNFD that includes PKT interfaces to enable upgrading from an 8.x deployment that includes PKT interfaces on OAM nodes. 

not used
--sbc_tar
[<file> | omit]

Include this parameter to specify the path and file name for an input tar file, or use omit to not include a file. Specifying a tar file is currently not required.

omit
--sbc_public_key <file>Include this parameter to specify a path and name for a file containing a default public key to provide in the Cloud Config Init Data section during VNF instantiation. A public key is required to use SSH to access the deployed SBC. Specifying a key file with this parameter makes the key available as the default when a user deploys a VNF using the generated CSAR file. A user can still override the default with a different key during instantiation.Example: id_rsa.pub
--sriov_redundancy Include this parameter to add two additional packet interfaces if SR-IOV is the io_type. Refer to SBC SWe Port Redundancy and Link Detection in OpenStack Cloud Deployments for more information on packet port redundancy.not enabled
--userid <userid>[:<public key file>]

Include this parameter to specify an additional user ID to authorize during instantiation, along with a public key for the user.
Note: If you do not specify a <public key file>, the SBC uses the sbc_public_key value (described above).

This parameter can be repeated multiple times as necessary to authorize additional users.

n/a
--vCPU <num_vCPU>
--RAM <ram_mb>
--DISK <disk_gb>
The flavor you select for an SBC VM defines the default values for sizing the VM when it is instantiated. Include these parameters to override one or more of the default values for VM sizing with a different value that you specify. The --DISK option applies to the ephemeral disk size.various
--oam_vCPU <num_vCPU>
--oam_RAM <ram_mb>
--oam_DISK <disk_gb> 

Include these parameters to override one or more of the default sizing values for OAM nodes with different values. There are various default values for these sizes, depending on the options selected. The --oam_DISK option applies to the ephemeral disk size.

  • For std flavor deployments, OAM nodes have a size of vCPU=4, RAM=16 GiB, DISK=80 GB.
  • For dev flavor deployments, OAM nodes have the same size as other VMs: vCPU=4, RAM=10GiB, DISK=80 GB.
various
--affinity_across_rgs
  • Specifies whether two redundancy groups can be placed on the same server.
  • Possible values: true/false.
false
--max_sbc_rg

The number of redundancy groups that a single VDU can scale out to.

8
--dns_file
  • File path to JSON file containing DNS settings.
  • This functionality works only when the io type is virtio.
no file/disabled
--enable_scaling
  • Enables scaling in the VNFD.
  • Requires --num_oam_instances to work this functionality.
N/A.

--redundancy_ratio

  • The redundancy ratio of a N:1 setup, to be supplied in form n:m.
  • This value is used only when the ha_type is n_1_ha.
  • If this value is not supplied, a value is taken from num_instances where the ratio is num_instances-1:1.

num_instances-1:1

(in N:1 setup)

--old_vnfm

Creates an older version of the VNFD for use with VNFMs versions pre- 21.2

Possible values: false/true.

false
-t  <vnfd_custom_types>Include this parameter to specify the full path and the name of the VNFD custom types file. If the types file resides in the same directory as the script, the -t parameter is not needed.current directory

The following parameters address less commonly used instantiation options, but may be necessary to address specific requirements in some customer deployments.

Specific Customer Parameters

ParameterDescriptionDefault
Cinder Volumes
--cinder_disktype <name>Include this parameter to specify the type of disk on which to create the Cinder volume.no specific type
Interface Rules 
--mgt0 <options>
--ha0 <options>
--pkt0 <options>
--pkt1 <options>
--oampkt <options>

Interface rules set additional options for a specified interface  that you enter as a colon-separated list of options. Examples: 
--mgt0 ipv6:provider:rules
--pkt0 ipv6

The options can be a colon-separated list of values of the following:

ipv4  |  ipv6  |  ipvn: to specify an IP version for the interface.ipvn – indicates both IP versions are available and selected during
orchestration, 
except for the --oampkt interface, which has a default of ipv4
rules: Include this parameter to have the recommended security rules created automatically during orchestration for the specified interface. Refer to Creating Security Group Rules for the list.no rules are created automatically, unless --security_restrict is set (which adds the recommended rules to all interfaces)
rulesoam: Include this parameter to create separate sets of the recommended security rules for the OAM nodes mgt0 and ha0 interfaces (for customers who want separate security rules created for each VM type).the same rules apply to mgt0 and ha0 on both OAM and SBC nodes.
rip=n: to specify the number of remote IPs to add to rules. The range allowed for n is 0 to 2.2
ems_rip=n: to specify the number of remote IPs to add to rules for EMS IPs. The range allowed for n is 0 to 2.2

virtio | provider | sriov: to specify an interface type for ha0 or mgt0 interfaces. The options are:

  • provider to specify a provider network.
  • sriov to specify an SR-IOV (single root input/output virtualization) network.
  • virtio to specify a virtio network.
defaults to the type specified with the -i parameter
Placement Groups
--placement_sbc_name <name>Include this parameter to specify a placement group for the SBC nodes. Placement groups affect which affinity policies are assigned to nodes and the name selected affects the server group name.Sbc%VNFTYPE%VmPlacement
--placement_oam_name <name>Include this parameter to specify a placement group for the OAM nodes. Placement groups affect which affinity policies are assigned to nodes and the name selected affects the server group name.Oam%VNFTYPE%VmPlacement
General
--omit_ipv6 Include this parameter to explicitly remove support for IPv6 deployments and the choice of IP version. IPv6 uses additional security groups. not enabled
--security_restrictInclude this parameter to have the recommended security rules created automatically during orchestration for all interfaces. Refer to Creating Security Group Rules for the list. If you use this option, your tenant must a large enough quota for the supplied security rules. The quota requirement increases if your deployment includes OAM VMs and when it supports both IPv4 and IPv6. A basic IPv4 SBC deployment requires 54 rules, while a deployment that includes OAM VMs and supports IPv4 and IPv6 requires 196 rules.not enabled; by default all ports are allowed.
--timeout <seconds> Include this parameter to specify a timeout, in seconds, for the CLI /bash shell.300
--version_suffix <name>Include this parameter to specify a suffix to append to the package version in the CSAR's .mf file.no suffix

Note

The createVnfmCsar.py script supports additional run-time options that are not listed in the previous tables because they are generally not needed in customer deployments. These additional options are intended for debugging or development purposes. To display help information on the additional debug options, enter:

createVnfmCsar.py --help

Custom Naming Parameters

You have the option to include script parameters that modify the names assigned to the system and individual node instances when the system is deployed. Refer to System and Instance Naming in SBC SWe N:1 and Cloud-Based Systems for more information on the default naming conventions.

The following table summarizes the custom naming parameters.

Script Parameters for Custom Naming

ParameterDescriptionDefault
--custom_system_name <name>Include this parameter to specify a custom system name.
The specified name appears in the VNFM UI as the default in the SYSTEMNAME field.
 SystemName
--custom_oam_name <name>

Include this parameter to specify a custom name to use in naming OAM nodes.

The specified name is included in the actualCeName assigned to each OAM node.

OAM
--custom_sbc_name <name>

Include this parameter to specify a custom name to use in naming SBC nodes.

The specified name is included in the actualCeName assigned to each SBC node.

%VNFTYPE% (for a single redundancy group)

RG%rg_index%-%VNFTYPE% (for multiple redundancy groups)

--custom_oam_server_group_nameInclude this parameter to specify a custom server group name to use in naming OAM nodes.%orchname%-OAM-%VNFTYPE%-SG
--custom_sbc_server_group_nameInclude this parameter to specify a custom server group name to use in naming SBC nodes.%orchname%-SBC-%VNFTYPE%%rg_index%-SG
--custom_vmname_dash Include this parameter to manually insert a dash before the VM index.no dash is added

Tokens

The following tokens are allowed within the custom naming parameters:

%rg_index%  -- to include the redundancy group index.

%vnftype% or %VNFTYPE% -- to include the VNF type (for example: SSBC) in lower or uppercase.

VNFM tokens –  %orchname%, %basename%, %index%, %vmname%, %vmtype%, %get_param:parmname%
Refer to Using Customized Naming in a VNFD in VNFM documentation for more information on which VNFM tokens apply to which resources. 

Naming Syntax

To construct the SBC parameter actualCeName for each node it is deploying, VNFM begins with the the custom_system_name and appends either the custom_oam_name or custom_sbc_name (based on node type), followed by a VM index. That is:

<custom_system_name><custom_oam_name><VM index> or

<custom_system_name><custom_sbc_name><VM index>

The VM index is a unique instance number for the node type, up to 5 in a 4:1 HA deployment. For clarity, if either the custom_oam_name or custom_sbc_name ends in a digit or the %rg_index% token, VNFM automatically adds a dash before the VM index. Include the custom_vmname_dash parameter to manually include a dash before the VM index.

Custom Naming Example

The following custom naming parameters in a 4:1 HA deployment with two redundancy groups:

--custom_oam_name OAMX --custom_sbc_name GRP%rg_index% --custom_system_name EX-SSBC22

Yields the following node names:

EX-SSBC22-OAMX1, EX-SSBC22-OAMX2

EX-SSBC22-GRP1-1, EX-SSBC22-GRP1-2, EX-SSBC22-GRP1-3,EX-SSBC22-GRP1-4,EX-SSBC22-GRP1-5

EX-SSBC22-GRP2-1, EX-SSBC22-GRP2-2, EX-SSBC22-GRP2-3,EX-SSBC22-GRP2-4,EX-SSBC22-GRP2-5

Environment Variables

For deployments that require even greater flexibility in customizing the names of resources, prior to running the script, you can define environment variables to override the default naming conventions for different types of resources. The environment variables and their use in conjunction with the createVnfmCsar.py script are described in online command help provided with the script. To display the help information on custom naming options, enter:

createVnfmCsar.py --help_custom

Running the Script

Complete the following steps to generate a CSAR file:

  1. If you have not already done so, download the script and VNFD template files. The template and associated script are available in the file cloudTemplates.tar.gz.
  2. Copy the script and template files to a Linux environment where python is also both installed. Openssl must also be present if you want to sign the package files.  
  3. Review the options in the preceding table to determine which options are required for your deployment. The -p and -s parameters are required. All other parameters are optional, but including a specific value for the -f, -h, -i, and --personality parameters ensures you generate a single CSAR file for a single deployment type. 
  4. Switch to the directory location where the script and template file reside. 
  5. Referring to the syntax shown in the previous table, enter the script name followed by its parameters in a single statement. The location of the CSAR file(s) the script generates is shown in the screen output.
Important

The CSAR script enters a name for the SBC image file in the VNFD file that it derives using the values you specified for the -p and -s parameters. The name of the SBC image file (qcow2 file) you upload to Glance must match this name. Using the the values 9.01.00 and R000, the script concatenate these values and prepends the resulting string with sbc-V0. For this example, VNFM requires an image name of "sbc-V09.01.00R000" (unless you use the --image_name parameter to override this name).

Examples

The following command creates a single CSAR package file for a 1:1 HA S-SBC deployment that uses virtio interfaces:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h ha -i virtio --personality ssbc

The following command creates a single CSAR package file for a 3:1 HA M-SBC deployment that uses SR-IOV interfaces and includes a 1:1 HA pair of OAM nodes:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h n_1_ha --num_instances 4 -i sriov --personality msbc --num_oam_instances 2

The following command creates a single CSAR package file for a 1:1 HA I-SBC deployment that uses an IPv6 provider network:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h ha -i provider --ipv6 --personality isbc

The following command creates three CSAR packages file for 1:1 HA S-SBC deployments – one with virtio, one with SR-IOV, and one with provider interfaces:

 createVnfmCsar.py -p "9.01.00" -s "R000" -f std -h ha --personality ssbc

The following command creates a CSAR Package file for 4:1 HA M-SBC deployment that uses virtio interfaces, includes a HA pair of OAM nodes, and allows scaling up to 6 full Redundancy Groups:

createVnfmCsar.py -p "10.01.00" -s "R000" -f std -h n_1_ha -i virtio --personality ssbc --affinity_across_rgs true --enable_scaling --max_sbc_rg 6 --redundancy_ratio "4:1" --num_oam_instances 2

Creating Multiple Redundancy Groups that Use the Same OAM Nodes 

Note

Do not use --num_sbc_rg with --enable_scaling. Instead, you must scale the setup to the correct number of steps to create multiple setups.

The createVnfmCsar.py script provides an option to create multiple redundancy groups within the same cluster. These redundancy groups will share the same configuration and are managed by the same OAM nodes. When you set the num_sbc_rg option to a value greater than one, the script generates a VNFD file that includes additional sets of parameters for the number of redundancy groups specified. During instantiation, VNFM presents multiple sets of parameters where appropriate, enabling you to define the parameters that are specific to an individual redundancy group, such as its name. The redundancy groups are uniquely identified in the interface by prepending names with rg#_.

To create multiple SBC redundancy groups that are managed by the same OAM nodes:

  1. Run the createVnfmCsar.py script using the option num_sbc_rg to specify the number of SBC redundancy groups you want to create. 
    For example, the following command generates a CSAR package containing a VNFD file that creates two 4:1 HA M-SBC redundancy groups:
    createVnfmCsar.py -p 9.01.00 -s R000 -i virtio -f std -h n_1_ha --num_instances 5 --num_oam_instances 2 --personality msbc --omit_ipv6 --num_sbc_rg 2
  2. Onboard the resulting CSAR package file to VNFM.
  3. Instantiate the VNF using the CSAR package you generated. VNFM replicates any parameters needed to define each redundancy group. The following figure shows a part of the VNFM instantiation screen requesting SBC system names for two redundancy groups.  Similarly, VNFM replicates other instantiation parameters (Networks, Flavors, Manual IP) for each redundancy group. 

    Multiple Redundancy Groups - System Name Options


  • No labels