| ... | ... | @@ -2,11 +2,11 @@ |
|
|
|
|
|
|
|
**Introduction**
|
|
|
|
|
|
|
|
Swisscom Innovations was looking for a simple solution to deploy OpenAir-CN (the core network part) on an arbitrary OpenStack public cloud and having that procedure automated as much as possible. Therefore we created a Heat Orchestration Template which can be used for this task. The template does everything automatically from building the software directly from git and install and configure openair-cn as vEPC in the cloud. We think it might be useful for the community, thats why Swisscom shares it here. Feel free to ask questions to the openair-cn mailinglist or directly to @dbalsige.
|
|
|
|
Swisscom Innovations was looking for a simple solution to deploy OpenAir-CN (the core network part) on an arbitrary OpenStack public cloud and having that procedure automated as much as possible. Therefore we created a Heat Orchestration Template which can be used for this task. The template does everything automatically for you, from building the software directly from git master over installing and configuring openair-cn as vEPC in the cloud. We think it might be useful for the community, thats why Swisscom shares it here. Feel free to ask questions to the openair-cn mailinglist or directly to @dbalsige.
|
|
|
|
|
|
|
|
**Deployed Architecture**
|
|
|
|
|
|
|
|
Since generic OpenStack clouds do not support transporting SCTP packets over Floating IPs yet, we use a simple VPN setup for carrying the S1 traffic between eNBs and MME/SPGW instances. This has the cute side-effect that eNB can be placed everywhere in the Internet even behind NATs, and you do not have the need for a second external network in OpenStack, so in principle any public OpenStack cloud can be used. In addition, S1 traffic between eNB and MME/SPGW is encrypted and eNBs are authenticated. Have a look at the following picture to understand which networks and instance interfaces are used for which traffic:
|
|
|
|
Since generic OpenStack clouds do not support transporting SCTP packets over Floating IPs yet, we use a simple VPN setup for carrying the S1 traffic between eNBs and MME/SPGW instances. This has the cute side-effect that eNB can be placed everywhere in the Internet even behind NATs, and you do not have the need for a second external network in OpenStack, so in principle any public OpenStack cloud can be used to deploy the core. In addition, S1 traffic between eNB and MME/SPGW is encrypted and eNBs are authenticated. Have a look at the following picture to understand which networks and instance interfaces are used for which traffic:
|
|
|
|
|
|
|
|
|
|
|
|
|
| ... | ... | @@ -14,17 +14,18 @@ Since generic OpenStack clouds do not support transporting SCTP packets over Flo |
|
|
|
|
|
|
|
* Access to an OpenStack tenant
|
|
|
|
|
|
|
|
The template creates a router, a floating IP, a network, volumes, security groups, ports and instances on OpenStack. Keep in mind that your tenant has sufficient quotas to create those resources. OpenStack version should be at least Kilo, with keystone, glance, nova, neutron, cinder and heat services enabled.
|
|
|
|
Of course you need access to an OpenStack cloud. The template creates a router, a floating IP, an internal network, volumes, security groups, ports and instances in OpenStack. Keep in mind that your tenant has sufficient quotas to create those resources. The OpenStack version should be at least Kilo, with keystone, glance, nova, neutron, cinder and heat services enabled. We tested the template on Kilo, Liberty and Mitaka.
|
|
|
|
|
|
|
|
* The HOT (Heat Orchestration Template)
|
|
|
|
|
|
|
|
The heat template is in openair-cn git located here and can be uploaded to heat by command-line client or directly in horizon.
|
|
|
|
The heat template is in openair-cn git. I created a new branch called 52-swisscom-heat-templates. The template can be found here: https://gitlab.eurecom.fr/oai/openair-cn/blob/52-swisscom-heat-templates/heat/OpenAir-vEPC.yml
|
|
|
|
|
|
|
|
* Ubuntu image with os-*-config installed
|
|
|
|
|
|
|
|
Since the heat template uses OS::Heat::SoftwareDeployment the base image for the instances needs to have os-collect-config/heat-config/os-apply-config tools installed. Such images can be created manually and uploaded to your cloud easily.
|
|
|
|
Since the heat template uses OS::Heat::SoftwareDeployment, the base image for the instances needs to have os-collect-config/heat-config/os-apply-config tools installed. Such images can be created manually and uploaded to your cloud easily. Instructions for that are provided just at the beginning of the tutorial.
|
|
|
|
|
|
|
|
|
|
|
|
**TUTORIAL**
|
|
|
|
|
|
|
|
**1. Create custom Ubuntu images**
|
|
|
|
|
| ... | ... | @@ -42,7 +43,7 @@ export PATH="${PWD}/dib-utils/bin:$PATH" |
|
|
|
export ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/software-config/elements
|
|
|
|
diskimage-builder/bin/disk-image-create vm ubuntu os-collect-config os-refresh-config os-apply-config heat-config heat-config-script -o ubuntu-$DIB_RELEASE-os-config.qcow2
|
|
|
|
```
|
|
|
|
As a remark (12-12-2016), you can see above that we use trusty (14.04) version of Ubuntu ($DIB_RELEASE). In principle the heat template works with Ubuntu xenial (16.04), however we have problems connecting UEs to the core when using xenial. So please test with trusty (14.04) version of Ubuntu first.
|
|
|
|
As a remark (12-12-2016), you can see above that we use trusty (14.04) version of Ubuntu ($DIB_RELEASE). In principle, the heat template works with Ubuntu xenial (16.04), however we have problems connecting UEs to the core when using xenial. So please test with trusty (14.04) version of Ubuntu first.
|
|
|
|
|
|
|
|
**2. Upload your created image to OpenStack**
|
|
|
|
|
| ... | ... | @@ -54,7 +55,7 @@ glance image-create --disk-format qcow2 --file ubuntu-$DIB_RELEASE-os-config.qco |
|
|
|
|
|
|
|
**3. Create or upload an SSH keypair for logging into instances**
|
|
|
|
|
|
|
|
You will need an SSH key to be able to login to instances created by Heat. Therefore an SSH keypair needs to be defined for your tenant. There are several possibilities to achieve this:
|
|
|
|
You will need an SSH key to be able to login to instances created. Therefore an SSH keypair needs to be defined for your tenant. There are several possibilities to achieve this:
|
|
|
|
|
|
|
|
* You have already a keypair defined for your tenant. That is fine, you can use that one for your OAI deployment.
|
|
|
|
* You can create a new SSH keypair directly in OpenStack. Keep in mind to keep the key file at a secret place.
|
| ... | ... | @@ -73,17 +74,15 @@ You are almost done with your cloud setup, once again check the following on you |
|
|
|
|
|
|
|
* Download the heat template and save it locally.
|
|
|
|
* Go to horizons 'Orchestration' tab and click on 'Launch Stack'.
|
|
|
|
* As template provide the file you downloaded before and click on next. No environment file is needed.
|
|
|
|
* Now adjust the values your for your needs, and press on next.
|
|
|
|
* As template provide the file you downloaded before and click on 'Next'. No environment file is needed.
|
|
|
|
* Now adjust the values your for your needs, and press on 'Next'.
|
|
|
|
|
|
|
|
Here you have a little video how it should look like:
|
|
|
|
Here you have a little video how this look like:
|
|
|
|
|
|
|
|
* Depending on your clouds performance and the flavors selected it can take more than the normal timeout (60 minutes). with build flavor of 4 cores you should be fine in 30 minutes.
|
|
|
|
* When the stack was created successfully nodes need to be rebooted for using updated or custom (SPGW) kernels. TODO Rebooting instances by template.
|
|
|
|
* Depending on your clouds performance and the flavors selected it can take more than the normal timeout (60 minutes). With build flavor of 4 cores you should be fine in 30 minutes.
|
|
|
|
* When the stack is created successfully nodes need to be rebooted for using updated or custom (SPGW) kernels. TODO Rebooting instances by template.
|
|
|
|
* After reboot the three programs oai_hss, mme and spgw on the respective instances need to be started and the core is up. TODO Auto starting the services by template.
|
|
|
|
|
|
|
|
Here is the corresponding video for that:
|
|
|
|
|
|
|
|
**6. Connecting eNBs to the core**
|
|
|
|
|
|
|
|
TODO
|
| ... | ... | @@ -95,6 +94,3 @@ We are planning to create eNB images for different sample H/W directly in the cl |
|
|
|
|
|
|
|
TODO
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
