| ... | ... | @@ -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 thinks 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 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.
|
|
|
|
|
|
|
|
**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. 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. 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,15 +14,15 @@ 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 ressources. OpenStack version should be at least Kilo, the template needs neutron, nova, glance, cinder and heat OpenStack services.
|
|
|
|
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.
|
|
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
* Ubuntu images with os-*config tools installed
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| ... | ... | @@ -46,31 +46,36 @@ diskimage-builder/bin/disk-image-create vm ubuntu os-collect-config os-refresh-c |
|
|
|
**2. Upload your created image to OpenStack**
|
|
|
|
|
|
|
|
Use the horizon GUI to upload the image you just created to your OpenStack cloud. Or have a look at the following example how to achieve that with the glance command-line client:
|
|
|
|
´´´
|
|
|
|
|
|
|
|
```
|
|
|
|
glance image-create --disk-format qcow2 --file ubuntu-$DIB_RELEASE-os-config.qcow2 ubuntu-$DIB_RELEASE-os-config
|
|
|
|
´´´
|
|
|
|
```
|
|
|
|
|
|
|
|
**3. Create or upload an SSH keypair for logging into instances**
|
|
|
|
|
|
|
|
You will need an SSH key 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 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 secret place.
|
|
|
|
* You can import the public part of an existing SSH key to OpenStack
|
|
|
|
* You can create a new SSH keypair directly in OpenStack. Keep in mind to keep the key file at a secret place.
|
|
|
|
* You can import the public part of an existing SSH key to OpenStack.
|
|
|
|
|
|
|
|
**4. Check tenant quotas**
|
|
|
|
|
|
|
|
Your almost done with your cloud setup, once again check the following on your OpenStack tenant:
|
|
|
|
You are almost done with your cloud setup, once again check the following on your OpenStack tenant:
|
|
|
|
|
|
|
|
* Remember the name of the external network you want to use to connect your OAI deployment to. (One neutron Router and one neutron Floating IP will be created)
|
|
|
|
* Remember the flavors you want to use for your instances (the template needs one flavor for building and one flavor for running)
|
|
|
|
* Check you have suffcient quotas an all cloud resources (volumes, RAM, CPU, instances, security groups, floating IPs, routers, networks...)
|
|
|
|
* Remember the name of the external network you want to use to connect your OAI deployment to. (One neutron Router and one neutron Floating IP will be created in that external network)
|
|
|
|
* Remember the flavors you want to use for your instances (the template uses one flavor for building and one flavor for running)
|
|
|
|
* Check you have sufficient quotas an all cloud resources (Volumes, RAM, CPU, instances, security groups, rules, floating IPs, routers, networks...)
|
|
|
|
* Check your heat service is running (e.g. by clicking on the Orchestration tab in horizon)
|
|
|
|
|
|
|
|
**5. Start the deployment**
|
|
|
|
|
|
|
|
* Get the heat template from here and save it locally.
|
|
|
|
* Go to horizons Orchestration tab and click on 'Launch Stack'.
|
|
|
|
* Provide the template file you downloaded before and click on next. No environment file is needed.
|
|
|
|
* Now adjust all the values your for your needs, and press on next.
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
Here you have a little video how it should look like:
|
|
|
|
|
|
|
|
|
|
|
|
|
