Contents
1 Overview
Basic knowledge of OpenStack, Linux, and networking is mandatory for any user who wants to follow this document.
Read before SAPC VNF Network Configuration Guide.
1.1 General
The purpose of this document is to describe how to deploy and set up the SAPC in OpenStack, either with Ericsson Cloud Manager (ECM) on top of OpenStack or with OpenStack CLI. The following procedures are covered:
1.2 ECM-OpenStack/OpenStack CLI
OpenStack is installed and configured in all physical hosts in which the SAPC vAPP is deployed and properly connected to ECM/OpenStack CLI. The installation of OpenStack, ECM, and OpenStack CLI products are out of scope of this document, refer to their corresponding CPI documents.
1.3 Accesses
The following information is required to deploy the SAPC on ECM-OpenStack:
- Access to the Virtual Delivery Package through the SAPC software gateway.
- Access to ECM: a tenant must be available in ECM. Also, a Virtual Data Center connected to the target Virtual Infrastructure Manager (VIM) in this tenant where the SAPC is deployed must be available. Credentials to log in to ECM must be provided.
- Access to the OpenStack CLI server: credentials to login to the server with OpenStack CLI must be provided, for instance, credentials for Atlas server in case of Ericsson Cloud Execution Environment (CEE) or Director server in case of Red Hat OpenStack Platform (RHOSP).
- Administration user identities and default passwords for the SAPC can be found in SAPC Users and Passwords.
2 SAPC VNF Descriptor Generation
2.1 Download the SAPC Virtual Delivery Package
The required software is listed in Table 1 and can be downloaded from Ericsson Software Gateway under a unique ticket number. Refer to Release Notes for specific version information and ticket number. Make sure that the Software Package file for the SAPC is available on a preparation server where you access the ECM WEB GUI or OpenStack CLI server.
|
Software Package |
Filename |
|---|---|
|
SAPC Virtual Delivery Package |
vdp_sapc_qcow2_cxp9032849_<revision>.tar.gz |
2.2 Generate the SAPC VNF Descriptor
The SAPC OVF package file for ECM deployments, or the HOT template files for OpenStack CLI deployments are generated on the preparation server according to the instruction stated in SAPC VNF Descriptor Generator Tool.
3 Deploy the SAPC for Standalone
3.1 Deployment with ECM
3.1.1 Flavors Addition
In OpenStack, a flavor defines the compute, memory, and storage capacity of a virtual server that users can launch. A flavor is referred as Server Resource Template (SRT) in ECM.
Log in to ECM.
Select the Server Resource Templates option in the Resources menu.
Select Create and when Create Server Resource Template pops up, fill the boxes with proper information for the System Controller's flavor.
.
Repeat for SRTs required by the Processor Load (PL) and Virtual Router (VR) (optional) as shown below.
Once SRTs are created, transfer all SRTs to the VIM in which the SAPC will be deployed at a later stage. Therefore, after selecting the SRT, press the Transfer to VIM icon.
In the Transfer Template pop up window, select the VIM zone to which the SRT must be transferred to and press the Transfer button.
Transfer all the previously created SRTs to the VIM by repeating the previous steps.
3.1.2 Upload the SAPC Images
Log in to ECM.
Select the Images option in the Resources menu.
Select the Create > From File icon.
Select the Select File icon.
Select a qcow2 image file and click the Open button. This is an example.
Fill required information in the next window.
- Note:
- The image files can only be uploaded one by one. Make sure
that all qcow2 image files are uploaded.
After starting the upload, the ECM performs an MD5 checksum of the image inside the browser first and then starts the actual upload. This step takes long time for bigger images, depending on the capabilities of the host from where the browser is started.
Upload all the SAPC images and keep the default names to match the defined names. The VM image list looks like this:
sapc_sc_cxp9032849_<revision> sapc_pxe_cxp9032849_<revision> sapc_vr_cxp9032849_<revision> (optional)
After all the images are uploaded, do a final check to make sure that all the SAPC images are uploaded and that everything looks fine.
Use the 
icon in the upper left part of the ECM GUI and refresh the Images list to check that all the images are visible and uploaded.
Check that the correct virtual machine image names are chosen. Check
that the Image Format is of type qcow2 and Provisioning Status is Active.
Transfer all the previously created images to the VIM by repeating the previous steps.
In the Transfer Template pop up window, choose the VIM zone to which the image must be transferred to and press the Transfer button.
Transfer all the previously uploaded images to the VIM by repeating the previous steps.
3.1.3 Upload the SAPC OVF/HOT Package
Upload the generated Open Virtualization Appliance (OVA) or HOT file in Section 2.2 depending on the selected method for deploying the SAPC and keep the default names for simplicity. The OVF or HOT Packages describing the SAPC looks like this:
sapc_cxp9032849_<revision>.ova
sapc_cxp9032849_<revision>_ECM.zip
Select the Packages icon in the Resources menu in the main WEB GUI of ECM.
Select the Create > OVF Package or HOT Package menu item depending on the selected case.
Press Select File. Select the sapc_cxp9032849_<revision>.ova or sapc_cxp9032849_<revision>_ECM.zip description file from the directory where you saved it and click the Open button. Then fill the boxes with the required information as in the example below and select the Start icon.
After the descriptor file is uploaded, do a final check to make sure that everything looks fine.
Use the icon and refresh the Packages list to check that the
descriptor file is visible and uploaded. Check that the Format is of type OVF or HOT depending on the
used package and Provisioning Status is Active.
- Note:
- The last three windows show the case when the uploaded package is an OVF package, as an example. When the uploaded package is a HOT package, the windows are similar, although the displayed format type is HOT instead of OVF that is shown in the example.
3.1.4 Deploy the SAPC vAPP
The vAPP is an ECM concept that is used to logically group several virtual machines together in a logical entity. When creating a vAPP, the ECM instructs OpenStack to create all the virtual machines and other related objects in a specific order, as specified in the vAPP definition. In the case of the SAPC, the SC-1 is created first, and then the rest of the virtual machines. The vAPP provisioning status changes to Active when all virtual machines are started.
Select the Assets > Virtual Data Centers icon.
Select the desired VDC from the list.
Choose the Virtual Applications tab. Then press the Create button.
In the Search for Offers tab, select Package Offer as Offer Source and click Next.
In the Choose Offer tab, select the OVF or HOT package with the SAPC desired and click Next.
In the Set VIM Criteria tab, add VIM characteristics if any or leave it empty. Press Submit Order and click Next.
In the Choose VIM Zone tab, VIM is preselected, so click Next.
In the Enter Attributes tab, review the correct values for the virtual application. Press Submit Order.
An order is created. Click the blue number link in the Order Submitted pop-up window. Check the Order Details window until the order is Completed, as in the example below.
Check if the vApp has Provisioning Status Active.
Check in tab VMs that all vAPP virtual machines have the Provisioning Status and Operational Status columns set to Active status.
3.2 Deployment with OpenStack CLI
Follow this procedure to deploy the SAPC in OpenStack using the OpenStack CLI.
- Note:
- To execute the "openstack" command properly, set up the following environment variables:
- OS_AUTH_URL points to Keystone service
- OS_CACERT for the verification of the server certificate
- OS_TENANT_NAME contains the name of the tenant where the stack is to be created
- OS_USERNAME: user with appropriate rights
- OS_PASSWORD: password for OS_USERNAME
3.2.1 Upload the SAPC HOT Package
The generated yaml files in Section 2.2 must be uploaded to a machine where the OpenStack CLI is available (OpenStack_cli_server). The HOT package is named SAPC_cxp9032849_<revision>.zip.
Once the HOT package is transferred to the OpenStack_cli_server, it has to be extracted:
<OpenStack_cli_server># mkdir ~/<my_deploy_dir>
<PreparationServer># sftp <User@OpenStack_cli_server>
Transfer SAPC_cxp9032849_<revision>.zip> to ~/<my_deploy_dir>.
<OpenStack_cli_server># cd ~/<my_deploy_dir>
<OpenStack_cli_server># unzip SAPC_cxp9032849_<revision>.zip
3.2.2 Upload the SAPC Images CLI
Connect to the OpenStack_cli_server by ssh using the provided credentials, and change to the directory where the SAPC HOT template files are extracted.
Run the openstack image create command to upload the required images under ~/<my_deploy_dir>/Resources/Images to OpenStack:
sapc_sc_cxp9032849_<revision> sapc_pxe_cxp9032849_<revision> sapc_vr_cxp9032849_<revision> (optional)
The example below shows how to upload the SC image:
<OpenStack_cli_server># openstack image create --container-format bare --disk-format qcow2 --file Resources/Images/sapc_sc_cxp9032849_<revision>.qcow2 sapc_sc_cxp9032849_<revision>
Repeat the openstack image create command for each required image file.
- Note:
- After the images of the virtual machines are uploaded to OpenStack, it is recommended to remove the qcow2 images from the ~/<my_deploy_dir>/Resources/Images directory, to save time and disk space during the deployment phase.
3.2.3 Create Flavors
In OpenStack, a flavor defines the compute, memory, and storage capacity of a virtual server that the users can launch.
3.2.3.1 Create Flavors for OpenStack
During the VNF descriptor generation described in SAPC VNF Descriptor Generator Tool, a script to create flavors is automatically generated: openstack_flavors_sapc_cxp9032849_<revision>.sh.
These flavors are valid for deployments on OpenStack configured for CPU Pinning and Non-Uniform Memory Access (NUMA) Awareness, for example CEE.
- Transfer openstack_flavors_sapc_cxp9032849_<revision>.sh to OpenStack_cli_server.
- Log on to the OpenStack_cli_server.
- Enter the following command to execute the script and
create the needed flavors:
OpenStack_cli_server:# ./ openstack_flavors_sapc_cxp9032849_<revision>.sh
- Note:
- The output of the script describes the result of the creation, so no manual check is needed.
3.2.3.2 Create Flavors for OpenStack Not Configured for CPU Pinning and NUMA Awareness
- Log on to the OpenStack_cli_server.
- Enter the following commands to create the needed flavors:
OpenStack_cli_server:# openstack flavor create --ram 6144 --vcpus 2 --disk 40 2vcpu_6144MBmem_40GBdisk
OpenStack_cli_server:# openstack flavor create --ram 10240 --vcpus 2 --disk 0 2vcpu_10240MBmem_0GBdisk
OpenStack_cli_server:# openstack flavor create --ram 1024 --vcpus 2 --disk 4 2vcpu_1024MBmem_4GBdisk
- Note:
- The last command is valid only for deployments with VRs.
- Note:
- The output of each script describes the result of the creation, so no manual check is needed.
3.2.4 Deploy the SAPC Stack
The stack is a concept that is used to logically group several virtual machines and other resources together in a logical entity. When creating a stack, OpenStack is instructed to create all the virtual machines and other related objects in a specific order, as specified in the stack definition file. In the case of the SAPC, the SC-1 is created first, and then the rest of the virtual machines. The stack provisioning status changes to Create Complete when all virtual machines are started.
Execute the following steps:
- Connect to the machine running OpenStack CLI by SSH using
the provided credentials, and change to the directory where the SAPC
HOT template files are extracted.
<OpenStack_cli_server># cd ~/<my_deploy_dir>
- Execute the following command:
<OpenStack_cli_server># openstack stack create -t SAPC_cxp9032849<revision>.yaml -e Resources/EnvironmentFiles/SAPC_cxp9032849<revision>params.yaml <stack_name>
- Run the openstack stack list command. The status for the stack changes to CREATE_IN_PROGRESS until the operation is finished and the status changes to CREATE_COMPLETE.
3.3 Verify the SAPC Deployment
Even though the SAPC comes up properly after deployment with no manual interaction, a command is provided to perform a check of the SAPC health.
Log on with the root user to the SC-1 virtual machine, through the virtual console, either from within the ECM WEB GUI or from OpenStack available dashboard (for example Horizon or Atlas).
Once the virtual console has started, the logon prompt is displayed. If the console remains black, then hit any key on the keyboard.
Log on as the root user to the SC-1 virtual machine and execute the sapcHealthCheck command as is explained in the SAPC Advanced Troubleshooting Guideline document for getting the node state.
4 Install Additional SAPC Instances
4.1 Install Additional SAPC Instances from ECM
Additional SAPC instances can be deployed in the same VDC. The OVF or HOT package uploaded and used to deploy the first SAPC instance can also be used for the additional instance if the dimensioning (VM size and number of VMs) remains the same (details explained in this chapter). If not, a different OVF or HOT package must be generated following the previous chapters.
- Note:
- To permit the deployment of additional instances, the objects for each instance must be unique.
4.1.1 Customize the Additional SAPC Instance
Before the deployment of the additional instance, the configuration file for the SAPC customization (adapt_cluster.cfg) must be modified with the proper configuration, related to external VIPs for traffic and OAM, Diameter configuration, and so on, according to the SAPC VNF Descriptor Generator Tool document.
4.1.2 Deploy Additional SAPC Instances
Repeat the steps explained in Section 3.1.4 up to the point in which the Enter Attributes tab in the Create Virtual Application (vAPP) window is displayed.
To assign individual names to all objects within the OVF package for the additional instance, select the Manual Prefix option in the Enter Attributes tab. That option is in the Assign Prefix to Object Names dropdown menu and introduces a prefix for the vAPP.
Select the Configuration tab for the SC-1 and VR-1, VR-2, VR-3, and VR-4 (if applicable) virtual machines and choose the modified adapt_cluster.cfg file created in the previous section.
Click the Submit Order button. Repeat steps in Section 3.3 to validate the deployment of the additional instance.
If a HOT package is used for the additional instance, select the Enter Attributes tab, and introduce a Virtual Application Name that is different from the one that was used previously.
Select the Files tab and introduce a new adapt_cluster.cfg file for this specific instance by pressing the Replace File button.
Click the Submit Order button. Repeat steps in Section 3.3 to validate the deployment of the additional instance.
4.2 Install Additional Instances with OpenStack CLI
Similarly to Section 4.1, additional SAPC instances can be deployed with OpenStack CLI, although in this particular case to deploy a new SAPC instance it is much simpler than in the ECM case. To deploy a new SAPC instance, just proceed with the provided steps in Section 3.2.4 using a different stack_name, since OpenStack Heat does not allow stack name duplicity.
- Note:
- The HOT Environment file needs to be adapted accordingly to describe new VIPs to be applied for the new SAPC instance before the stack command is executed.
Follow steps in Section 3.3 to validate the deployment of the additional instance.
5 Deploy the SAPC for Geographical Redundancy
To perform the SAPC installation in the Geographical Redundancy scenario, deploy each of the SAPC nodes as stated in Section 3.
It is important to remark that the PREFERRED parameter is set to a different value on each node to be deployed. For more details, see Adapt Cluster Tool.
6 Configure the SAPC
6.1 SAPC Hardening after Deployment
For detailed information, refer to Security Hardening Guide.
6.2 Connectivity to External Networks
The SAPC application uses a predefined set of subnetworks that were set up during the installation process when the SAPC vAPP was created. This is just an example considering the basic configuration without traffic separation. In other configurations, additional external networks may exist, although the principle shown in this section would be the same including the additional external networks.
The External OAM and External Traffic networks are the ones used to connect the vApp to the external world while the remaining networks are mainly for the SAPC virtual machine inter-operability.
To ensure the SAPC accessibility from outside the cloud and from other nodes, such as EPG and MME, specific routes must be defined in Border Gateway Routers to guarantee access to the vApp VIPs (OAM and Traffic).
The following sections describe an example (four Border Gateway Routers) and just taking an Extreme Switch x460/x670 as a reference, the following routing must be set up.
6.2.1 Configuration Example of OAM Border Gateway Routers (Extreme x670)
Log in to the Border Gateway Routers:
PreparationServer:# ssh admin@<Extreme Switch>
Check if External-OAM VLAN exists and contains the suggested IP address (10.41.30.225 for External-OAM) and the required configuration.
BorderGatewayRouter:# show vlan
SAPC_Cloud_2004 2004 10.41.30.225 /29 -f------------------------- ANY 4 /4 VR-Cloud
If the VLAN does not exist, create it:
BorderGatewayRouter:# create vlan <Vlan Name 1, SAPC_Cloud_<tag 1>>
BorderGatewayRouter:# configure vlan <Vlan Name 1> tag <Tag 1>
BorderGatewayRouter:# configure vlan <Vlan Name 1> add ports <Switch Ports> tagged
Ensure the SAPC accessibility from outside the cloud and from other nodes, such as EPG and MME:
Configure IP addresses for the External VLANs and IP routing:
BorderGatewayRouter:# configure vlan <Vlan Name 1> ipaddress 10.41.30.225 255.255.255.248
BorderGatewayRouter:# enable ipforwarding vlan <Vlan Name 1>
BorderGatewayRouter:# configure iproute add <VIP_OAM> 255.255.255.255 10.41.30.226
Save the configuration changes done in the Border Gateway Router switch:
BorderGatewayRouter:# save configuration
The configuration file primary.cfg already exists. Do you want to save configuration to primary.cfg and overwrite it? (y/N) Yes Saving configuration on master ....... done! Configuration saved to primary.cfg successfully.
# save configuration secondary The configuration file secondary.cfg already exists. Do you want to save configuration to secondary.cfg and overwrite it? (y/N) Yes Saving configuration on master ....... done! Configuration saved to secondary.cfg successfully. The current selected default configuration database to boot up the system (primary.cfg) is different than the one just saved (secondary.cfg). Do you want to make secondary.cfg the default database? (y/N) No Default configuration database selection cancelled.
6.2.2 Configuration Example of Traffic Border Gateway Routers (Extreme x670)
Log in to the Border Gateway Routers:
PreparationServer:# ssh admin@<Extreme Switch>
Check if External-Traffic VLAN exists and contains the suggested IP address (10.41.70.225 for External-Traffic) and the required configuration.
BorderGatewayRouter:# show vlan
SAPC_Cloud_2005 2005 10.41.70.225 /29 -f------------------------- ANY 4 /4 VR-Cloud
If the VLAN does not exist, create it:
BorderGatewayRouter:# create vlan <Vlan Name 2, SAPC_Cloud_<tag 2>>
BorderGatewayRouter:# configure vlan <Vlan Name 2> tag <Tag 2>
BorderGatewayRouter:# configure vlan <Vlan Name 2> add ports <Switch Ports> tagged
Ensure the SAPC accessibility from outside the cloud and from other nodes, such as EPG and MME:
Configure IP addresses for the External VLANs and IP routing:
BorderGatewayRouter:# configure vlan <Vlan Name 1> ipaddress 10.41.70.225 255.255.255.248
BorderGatewayRouter:# enable ipforwarding vlan <Vlan Name 1>
BorderGatewayRouter:# configure iproute add <VIP_TRAFFIC> 255.255.255.255 10.41.70.226
Save the configuration changes done in the Border Gateway Router switch:
BorderGatewayRouter:# save configuration
The configuration file primary.cfg already exists. Do you want to save configuration to primary.cfg and overwrite it? (y/N) Yes Saving configuration on master ....... done! Configuration saved to primary.cfg successfully.
# save configuration secondary The configuration file secondary.cfg already exists. Do you want to save configuration to secondary.cfg and overwrite it? (y/N) Yes Saving configuration on master ....... done! Configuration saved to secondary.cfg successfully. The current selected default configuration database to boot up the system (primary.cfg) is different than the one just saved (secondary.cfg). Do you want to make secondary.cfg the default database? (y/N) No Default configuration database selection cancelled.
6.3 Set the SAPC Licenses Configuration
The configuration of the application is done logging into the SAPC through the OAM VIP. This can be done either directly from the OAM Border Gateway Router, or from outside the cloud (for example, Jumpstart Server) if proper routing was in place: ssh vr "VR-Default" root@<VIP_OAM>.
In case of problems logging into the SAPC VM through the VIP-OAM, connect through a virtual console reachable from ECM or the OpenStack dashboard, as it was specified in former sections.
Configure the licenses following these steps.
- Set the fingerprint with the value given during the license ordering. For more information, see LM User Guide for ELIM.
- Install the license key file following Install License Key File.
- Check the license information following View License Information.
6.4 Final Backup
Once the SAPC configuration is done, generate a system backup. Follow the instructions specified in Create Backup.