Deploying Virtual Network Functions on OpenStack
This section describes several deployment scenarios for Elastic Services Controller (ESC) and the procedure to deploy VNFs. The following table lists the different deployment scenarios:
Scenarios |
Description |
Resources |
Advantages |
---|---|---|---|
Deploying VNFs on a single VIM by creating images and flavors through ESC |
The deployment data model refers to the images and flavors created and then deploys VNFs. |
Images and Flavors are created through ESC using NETCONF/REST APIs. |
|
Deploying VNFs on a single VIM using out-of-band images, flavors, volumes, and ports |
The deployment data model refers to the out-of-band images, flavors, volumes, and ports in OpenStack and then deploys VNFs. |
Images, Flavors, Volumes, and Ports are not created through ESC. |
|
Deploying VNFs on multiple VIMs using out-of-band resources |
The deployment data model refers to out-of-band images, flavors, networks and VIM projects and then deploys VNFs. |
Images, Flavors, VIM projects (specified in the locators) and Networks are not created through ESC. They must exist out-of-band in the VIM. |
You can specify the VIM (to deploy VMs) that needs to be configured in ESC within a deployment. |
To deploy VNFs on multiple OpenStack VIMs, see Deploying VNFs on Multiple OpenStack VIMs.
Deploying VNFs on a Single OpenStack VIM
The VNF deployment is initiated as a service request either originating from the ESC portal or the northbound interfaces. The service request comprises of XML payloads. ESC supports the following deployment scenarios:
-
Deploying the VNFs by creating images, and flavors through ESC
-
Deploying the VNFs using out-of-band images, flavors, volumes, and ports
Before you deploy the VNFs, you must ensure that the images, flavors, volumes, and ports are available on OpenStack, or you must create these resources. For more details on creating images, flavors, and volumes see Managing Resources Overview.
In a deployment, the out-of-band port must be created by the same tenant as the deployment. For more details on configuring ports, see Interface Configurations in the Cisco Elastic Services Controller Administration Guide.
To deploy VMs on multiple VIMs, see Deploying VNFs on Multiple OpenStack VIMs.
During a deployment, ESC looks for the deployment details in the deployment data model. For more information on the deployment data model, see Cisco Elastic Services Controller Deployment Attributes. If ESC is unable to find the deployment details for a particular service, it uses the existing flavors and images under the vm_group to continue the deployment. If ESC is unable to find the image and flavor details, the deployment fails.
Important |
You can also specify the subnet that is used for a network. The deployment data model introduces a new subnet attribute to specify the subnet. See the Cisco Elastic Services Controller Deployment Attributes for more details.
|
Note |
When a SERVICE_UPDATE configuration fails, the minimum and maximum number of VMs change causing a scale in or scale out. ESC cannot rollback the minimum or maximum number of VMs in the configuration because of errors caused on OpenStack. The CDB (an ESC DB) would be out of synchronization. In this case, another SERVICE_UPDATE configuration must be performed to do a manual rollback. |
For deployments on OpenStack, the UUID or name can be used to refer to the image and flavor. The name has to be unique on the VIM. If there are multiple images with the same name, the deployment cannot identify the right image and the deployment fails.
<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2016-01-22T15:14:52.484+00:00</eventTime>
<escEvent xmlns="http://www.cisco.com/esc/esc">
<status>SUCCESS</status>
<status_code>200</status_code>
<status_message>VIM Driver: VM successfully created,
VM Name: [SystemAdminxyz_abc_NwDepMod1_0_5e6b7957-20e7-4df9-9113-e5fc8c047e91]</status_message>
<depname>test_NwDepModVmGrp1</depname>
<tenant>admin</tenant>
<tenant_id>62cd11f560b44bf5815eaad41fc94c80</tenant_id>
</event>
Reboot Time Parameter
A reboot time parameter is introduced in the deployment request. This provides more granular control to the reboot wait time of recovery in a deployment. In a deployment, when the VM reboots, the monitor is set with the reboot time. If the reboot time expires before receiving the VM ALIVE event, the next action such as VM_RECOVERY_COMPLETE, or undeploy is performed.
Note |
The bootup time is used, if the reboot time is not provided. |
The data model change is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants>
<tenant>
<name>tenant</name>
<deployments>
<deployment>
<name>depz</name>
<vm_group>
<name>g1</name>
<image>Automation-Cirros-Image</image>
<flavor>Automation-Cirros-Flavor</flavor>
<reboot_time>30</reboot_time>
<recovery_wait_time>10</recovery_wait_time>
<interfaces>
<interface>
<nicid>0</nicid>
<port>pre-assigned_IPV4_1</port>
<network>my-network</network>
</interface>
</interfaces>
<kpi_data>
<kpi>
<event_name>VM_ALIVE</event_name>
<metric_value>1</metric_value>
<metric_cond>GT</metric_cond>
<metric_type>UINT32</metric_type>
<metric_collector>
<nicid>0</nicid>
<type>ICMPPing</type>
<poll_frequency>3</poll_frequency>
<polling_unit>seconds</polling_unit>
<continuous_alarm>false</continuous_alarm>
</metric_collector>
</kpi>
</kpi_data>
<rules>
<admin_rules>
<rule>
<event_name>VM_ALIVE</event_name>
<action>ALWAYS log</action>
<action>TRUE servicebooted.sh</action>
<action>FALSE recover autohealing</action>
</rule>
</admin_rules>
</rules>
<config_data />
<scaling>
<min_active>1</min_active>
<max_active>2</max_active>
<elastic>true</elastic>
</scaling>
<recovery_policy>
<recovery_type>AUTO</recovery_type>
<action_on_recovery>REBOOT_ONLY</action_on_recovery>
<max_retries>1</max_retries>
</recovery_policy>
</vm_group>
</deployment>
</deployments>
</tenant>
</tenants>
</esc_datamodel>
Sample notification is as follows:
20:43:48,133 11-Oct-2016 WARN ===== SEND NOTIFICATION STARTS =====
20:43:48,133 11-Oct-2016 WARN Type: VM_RECOVERY_INIT
20:43:48,134 11-Oct-2016 WARN Status: SUCCESS
20:43:48,134 11-Oct-2016 WARN Status Code: 200
20:43:48,134 11-Oct-2016 WARN Status Msg: Recovery event for
VM [dep-12_CSR1_c_0_37827511-be08-4702-b0bd-1918cb995118] triggered.
20:43:48,134 11-Oct-2016 WARN Tenant: gilan-test-5
20:43:48,134 11-Oct-2016 WARN Service ID: NULL
20:43:48,134 11-Oct-2016 WARN Deployment ID: f6ff8164-fe6d-4589-84fa-f39d676e9231
20:43:48,134 11-Oct-2016 WARN Deployment name: dep-12
20:43:48,134 11-Oct-2016 WARN VM group name: CSR1_cirros
20:43:48,134 11-Oct-2016 WARN VM Source:
20:43:48,134 11-Oct-2016 WARN VM ID: 90d2066c-9a07-485b-8f72-b51026a62922
20:43:48,134 11-Oct-2016 WARN Host ID: 69c3fba0a5b5ffff211bd05b9da7e2130d98d005a9bef71ace7d09ff
20:43:48,134 11-Oct-2016 WARN Host Name: my-server
20:43:48,134 11-Oct-2016 WARN [DEBUG-ONLY] VM IP: 192.168.0.75;
20:43:48,135 11-Oct-2016 WARN ===== SEND NOTIFICATION ENDS =====
20:43:56,149 11-Oct-2016 WARN
20:43:56,149 11-Oct-2016 WARN ===== SEND NOTIFICATION STARTS =====
20:43:56,149 11-Oct-2016 WARN Type: VM_RECOVERY_REBOOT
20:43:56,149 11-Oct-2016 WARN Status: SUCCESS
20:43:56,149 11-Oct-2016 WARN Status Code: 200
20:43:56,150 11-Oct-2016 WARN Status Msg: VM [dep-12_CSR1_c_0_37827511-be08-4702-b0bd-1918cb995118] is rebooted.
20:43:56,150 11-Oct-2016 WARN Tenant: gilan-test-5
20:43:56,150 11-Oct-2016 WARN Service ID: NULL
20:43:56,150 11-Oct-2016 WARN Deployment ID: f6ff8164-fe6d-4589-84fa-f39d676e9231
20:43:56,150 11-Oct-2016 WARN Deployment name: dep-12
20:43:56,150 11-Oct-2016 WARN VM group name: CSR1_cirros
20:43:56,150 11-Oct-2016 WARN VM Source:
20:43:56,151 11-Oct-2016 WARN VM ID: 90d2066c-9a07-485b-8f72-b51026a62922
20:43:56,151 11-Oct-2016 WARN Host ID: 69c3fba0a5b5ffff211bd05b9da7e2130d98d005a9bef71ace7d09ff
20:43:56,151 11-Oct-2016 WARN Host Name: my-server
20:43:56,152 11-Oct-2016 WARN [DEBUG-ONLY] VM IP: 192.168.0.75;
20:43:56,152 11-Oct-2016 WARN ===== SEND NOTIFICATION ENDS =====
20:44:26,481 11-Oct-2016 WARN
20:44:26,481 11-Oct-2016 WARN ===== SEND NOTIFICATION STARTS =====
20:44:26,481 11-Oct-2016 WARN Type: VM_RECOVERY_COMPLETE
20:44:26,481 11-Oct-2016 WARN Status: FAILURE
20:44:26,481 11-Oct-2016 WARN Status Code: 500
20:44:26,481 11-Oct-2016 WARN Status Msg: Recovery: Recovery completed with errors