{"id":7064,"date":"2015-01-27T16:50:18","date_gmt":"2015-01-27T14:50:18","guid":{"rendered":"http:\/\/blog.zhaw.ch\/icclab\/?p=7064"},"modified":"2015-04-29T15:24:21","modified_gmt":"2015-04-29T13:24:21","slug":"how-to-install-a-multi-region-devstack-part-1","status":"publish","type":"post","link":"https:\/\/blog.zhaw.ch\/icclab\/how-to-install-a-multi-region-devstack-part-1\/","title":{"rendered":"How to install a multi region devstack Part-1"},"content":{"rendered":"

Introduction<\/strong>
\nI have introduced Disaster Recovery (DR) services in the tutorial of last ICCLAB\u00a0 newsletter<\/a> which also made an overview of possible OpenStack configurations. Several configuration options could be considered. In particular, in case of a stakeholder having both the role of Cloud provider and DR service provider, a suitable safe configuration consists in distributing the infrastructures in different geographic locations. OpenStack gives the possibility to organise the controllers in different Regions which are sharing the same keystone. Here<\/a> you will find the an overall specification using heat, I will simulate same configurations using devstack on Virtual BoX<\/a> environments. One of the scope of this blog post is to support\u00a0 the students who are using Juno devstack.<\/p>\n

There will be a second part of this tutorial to show a possible implementation of\u00a0 DR services lifecycle between two regions.<\/p>\n

<\/p>\n

Goals<\/strong>
\nThis post provides devstack (Juno release) support to intall OpenStack on two controllers in two separate regions. The second region, for example,\u00a0 might be used as a replica and backup infrastructure for DR services. A single keystone will be shared between the two controllers.\u00a0 In particular, following other tutorials<\/a>, I will use Virtual Box hosting the\u00a0 two VMs of the two controllers.<\/p>\n

It will be needed then to create endpoints in keystone with two different regions (RegionOne and RegionTwo). RegionTwo will always pass through the keystone of RegionOne. The\u00a0 Horizon dashboard will be only serving in RegionOne.<\/p>\n

I will split the tutorial in two parts, this first part will be dedicated to the two controllers.<\/p>\n

RegionOne controller<\/strong>
\nLet’s install and configure the first controller in RegionOne using Virtual Box. Therefore please install Virtual Box on your host system and Install Ubuntu Linux from www.Ubuntu.com\/download\/desktop on a Virtual Machine (VM)\u00a0 (storage 40GB and RAM 3GB (minimum). Call this VM “RegioneOne”.<\/p>\n

Install Guest additions for Linux.<\/p>\n

I suggest to start with a VM having initially a NAT Network attached to the Adapter 1 which allows to download all packages from the internet.<\/p>\n

Any line below starting with $ is a command line on the Ubuntu controller node all the others are comments to the following commands.<\/p>\n

Make all the updates and upgrades of Ubuntu then reboot:<\/p>\n

$sudo apt-get update\r\n$sudo apt-get upgrade\r\n$sudo apt-get dist-upgrade\r\n$sudo apt-get install virtualbox-guest-dkms\r\n$sudo apt-get install vim\r\n$sudo reboot<\/pre>\n
Virtual Box configuration (Figure -1) .<\/p>\n
The intention is to have two Virtual Machines having internal addresses 20.10.0.1 and 20.10.0.2. Therefore at Virtual Box settings\u00a0 (Control-G) configuration, Network tab: Create a Host-Only Ethernet Adapter #1 with IPv4 address 20.10.0.3 and IPv4 Network Mask\u00a0 255.255.255.0<\/p>\n
\"antonio<\/a><\/p>\n
Figure-1<\/p>\n
Then configure the interfaces of the Virtual Machine as follows:<\/p>\n
eth0: Host-only Adapter #1
\nIPv4=20.10.0.1 and IPv4 Network Mask\u00a0 255.255.255.0
\neth1: NAT<\/p>\n
Install git to allow cloning of the devstack from the repository<\/p>\n
$sudo apt-get install git<\/pre>\n
Retrieve devstack source (juno master branch):<\/p>\n
$git clone -b stable\/juno https:\/\/github.com\/openstack-dev\/devstack.git\r\n$cd devstack<\/pre>\n
I will use the configuration of devstack through the localrc file.<\/p>\n
I have found a very good tutorial made by best friend of mine Ian Y. Choi<\/a>\u00a0 who proposed a good localrc file stored on http:\/\/goo.gl\/OeOGqL and another\u00a0 on here<\/a><\/p>\n
The localrc file is read during the stack.sh phase of devstack installation.<\/p>\n
Please, play the video tutorials<\/a> of Ian to understand some of the syntax of localrc file and all the Ubuntu installation commands. I have used instead the Juno master branch which handles correctly the regions and keystone service host.<\/p>\n
The localrc file that i suggest to use is following (to be created with vim):<\/p>\n
REGION_NAME=RegioneOne<\/strong>
\nOFFLINE=False
\nGIT_BASE=https:\/\/github.com
\nHOST_IP=20.10.0.1
\n# Logging
\nLOGDAYS=1
\nLOGFILE=$DEST\/logs\/stack.sh.log
\nSCREEN_LOGDIR=$DEST\/logs\/screen
\nVERBOSE=TRUE
\n# Credentials
\nDATABASE_PASSWORD=password
\nADMIN_PASSWORD=password
\nSERVICE_PASSWORD=password
\nSERVICE_TOKEN=password
\nRABBIT_PASSWORD=password
\nRECLONE=yes
\n# Services
\nENABLED_SERVICES=rabbit,mysql,key
\nENABLED_SERVICES+=,n-api,n-crt,n-obj,n-cpu,n-cond,n-sch,n-novnc,n-cauth
\nENABLED_SERVICES+=,neutron,q-svc,q-agt,q-dhcp,q-l3,q-meta
\nENABLED_SERVICES+=,g-api,g-reg
\nENABLED_SERVICES+=,cinder,c-api,c-vol,c-sch,c-bak
\nENABLED_SERVICES+=,horizon
\nenable_service ceilometer-acompute ceilometer-acentral ceilometer-anotification ceilometer-collector
\nenable_service ceilometer-alarm-evaluator,ceilometer-alarm-notifier
\nenable_service ceilometer-api
\nenable_service heat h-api h-api-cfn h-api-cw h-eng<\/p>\n
In icehouse release keystone will not read the REGION_NAME=RegioneOne. It is hardcoded to RegionOne.<\/strong><\/p>\n
Let’s start stacking in RegioneOne. (We have used RegioneOne instead of the default RegionOne )<\/p>\n
$.\/stack.sh<\/pre>\n
After about 5 min on my I7 machine!, the stack displays:<\/p>\n
$Horizon is now available at http:\/\/20.10.0.1\/\r\n$Keystone is serving at http:\/\/20.10.0.1:5000\/v2.0\/\r\n$Examples on using novaclient command line is in exercise.sh\r\n$The default users are: admin and demo\r\n$The password: password\r\n$This is your host ip: 20.10.0.1<\/pre>\n
Let’s source the environment with openrc file as descibed in the readme.<\/p>\n
$source openrc admin\r\n$env | grep OS_<\/pre>\n
The results are:<\/p>\n
OS_<\/strong><\/span>REGION_NAME=RegioneOne\r\nOS_<\/strong><\/span>IDENTITY_API_VERSION=2.0\r\nOS_<\/strong><\/span>PASSWORD=password\r\nOS_<\/strong><\/span>AUTH_URL=http:\/\/20.10.0.1:5000\/v2.0\r\nOS_<\/strong><\/span>USERNAME=admin\r\nOS_<\/strong><\/span>TENANT_NAME=demo\r\nOS_<\/strong><\/span>VOLUME_API_VERSION=2\r\nOS_<\/strong><\/span>CACERT=\/opt\/stack\/data\/CA\/int-ca\/ca-chain.pem\r\nOS_<\/strong><\/span>NO_CACHE=1<\/pre>\n
Try now to Get the current endpoints from keystone:<\/p>\n
$keystone endpoint-list<\/pre>\n
\"antonio<\/a>You should\u00a0 get all the endpoints in RegioneOne on the IP: 20.10.0.1 controller one.<\/p>\n
The Horizon is also working fine on 20.10.0.1 (Figure-2)<\/p>\n
\"hor\"<\/a><\/p>\n
Figure-2<\/p>\n
RegionTwo controller<\/strong>
\nLet’s install and configure the second controller in RegionTwo using Virtual Box as well. Install Virtual Box on your host system and Install Ubuntu Linux from www.Ubuntu.com\/download\/desktop on a VM (called “RegionTwo”) in Virtual Box (storage 40GB and RAM 3GB (minimum). Install Guest additions for Linux.<\/p>\n
Start with a VM having initially a NAT Network attached to the Adapter 1 which allows to download all packages from the internet.<\/p>\n
Make all the updates and upgrades of Ubuntu then reboot.<\/p>\n
$sudo apt-get update\r\n$sudo apt-get upgrade\r\n$sudo apt-get dist-upgrade\r\n$sudo apt-get install virtualbox-guest-dkms\r\n$sudo apt-get install vim\r\n$sudo reboot<\/pre>\n
Then configure the interfaces of this second Machine as follows:
\neth0: Host-only Adapter #1
\nIPv4=20.10.0.2 and IPv4 Network Mask\u00a0 255.255.255.0
\neth1: NAT<\/p>\n
Install git to allow cloning of the devstack from the repository<\/p>\n
$sudo apt-get install git<\/pre>\n
Retrieve devstack source (juno master branch)<\/p>\n
$git clone -b stable\/juno https:\/\/github.com\/openstack-dev\/devstack.git\r\n$cd devstack<\/pre>\n
Use again the configuration of devstack through the localrc file, create it with vim.<\/p>\n
#Keystone service on controller 1
\nKEYSTONE_SERVICE_HOST=20.10.0.1
\nKEYSTONE_AUTH_HOST=20.10.0.1
\nREGION_NAME=RegionTwo<\/strong>
\nOFFLINE=False
\nGIT_BASE=https:\/\/github.com
\nHOST_IP=20.10.0.2
\n# Logging
\nLOGDAYS=1
\nLOGFILE=$DEST\/logs\/stack.sh.log
\nSCREEN_LOGDIR=$DEST\/logs\/screen
\nVERBOSE=TRUE
\n# Credentials
\nDATABASE_PASSWORD=password
\nADMIN_PASSWORD=password
\nSERVICE_PASSWORD=password
\nSERVICE_TOKEN=password
\nRABBIT_PASSWORD=password
\nRECLONE=yes
\n# Services
\nENABLED_SERVICES=rabbit,mysql,key
\nENABLED_SERVICES+=,n-api,n-crt,n-obj,n-cpu,n-cond,n-sch,n-novnc,n-cauth
\nENABLED_SERVICES+=,neutron,q-svc,q-agt,q-dhcp,q-l3,q-meta
\nENABLED_SERVICES+=,g-api,g-reg
\nENABLED_SERVICES+=,cinder,c-api,c-vol,c-sch,c-bak
\nenable_service heat h-api h-api-cfn h-api-cw h-eng<\/p>\n
Now stack it:<\/p>\n
$.\/stack.sh<\/pre>\n
We have almost the same results of the controller one:<\/p>\n
$Keystone is serving at http:\/\/20.10.0.1:5000\/v2.0\/\r\n$Examples on using novaclient command line is in exercise.sh\r\n$The default users are: admin and demo\r\n$The password: password\r\n$This is your host ip: 20.10.0.2<\/pre>\n
Let’s show the environment\u00a0 on RegionTwo:<\/p>\n
$source openrc admin\r\n$env | grep OS_<\/pre>\n
The results are now:<\/p>\n
OS_<\/strong><\/span>REGION_NAME=RegionTwo<\/strong>\r\nOS_<\/strong><\/span>IDENTITY_API_VERSION=2.0\r\nOS_<\/strong><\/span>PASSWORD=password\r\nOS_<\/strong><\/span>AUTH_URL=http:\/\/20.10.0.1:5000\/v2.0\r\nOS_<\/strong><\/span>USERNAME=admin\r\nOS_<\/strong><\/span>TENANT_NAME=demo\r\nOS_<\/strong><\/span>VOLUME_API_VERSION=2\r\nOS_<\/strong><\/span>CACERT=\/opt\/stack\/data\/CA\/int-ca\/ca-chain.pem\r\nOS_<\/strong><\/span>NO_CACHE=1<\/pre>\n
Let’s test the keystone now:<\/p>\n
$Keystone endpoint-list\"endpoint<\/a><\/p>\n
Fantastic!, keystone has been populated with all the endpoints of RegionTwo. This was done during the .\/stack.sh<\/strong> in RegionTwo.<\/p>\n
Let’s also utilise Horizon (Figure-3) from the web browser of the controller two: http:\/\/20.10.0.1\/<\/p>\n
\"horizon<\/a><\/p>\n
Figure-3<\/p>\n
Now the dashboard offers on the admin tab, on the left top corner, the possibility to select RegioneOne or RegionTwo. The second part of this tutorial will also make some use cases of the dashboard.<\/p>\n
Let’s now check the nova services with these commands, from Regiontwo CLI.<\/p>\n
$nova service-list\r\n$nova --os-region-name RegionTwo service-list<\/pre>\n
You can verify that all nova services are running on the two Hosts of\u00a0 RegionTwo and RegioneOne. TheHhost names being displayed are the Virtual Box VM names.<\/p>\n
\"antonio<\/a><\/p>\n
Let’s conclude this post with an example on how to boot VMs (OpenStack), from RegioneOne on RegionTwo and RegioneOne.<\/p>\n
Controller One:<\/p>\n
$nova image-list<\/pre>\n
\"antonio<\/a><\/p>\n
 <\/p>\n
$ nova --os-regione-name RegioneOne boot VMOne --flavor=m1.tiny --image c20bff4c-c874-4261-b954-c5aea90a603c<\/pre>\n
$nova list<\/pre>\n
\"nova<\/a><\/p>\n
The VM: VMOne is in Build status on RegioneOne. Let’s try to make the same command to boot an image on RegionTwo. In this case image id needs to be taken from the RegionTwo:<\/p>\n
Controller Two:<\/p>\n
$nova image-list<\/pre>\n
\"image<\/a><\/p>\n
If you make a $nova list on this secons controller, there will be no running VMs. You can verify this.<\/p>\n
Let’s boot from Controller One a VM called VMTwo (cirros-0.3.2-x86_64-uec) on controller two:<\/p>\n
$ nova --os-region-name RegionTwo boot VMTwo --flavor=m1.tiny --image d77dd539-f76f-4f50-b7a5-f62f657b0e25<\/pre>\n
$nova --os-region-name RegionTwo list\r\n$nova --os-region-name RegioneOne list<\/pre>\n
\"nova<\/a><\/p>\n
\"nova<\/a><\/p>\n
As you can verify we have two VMs (VMTwo, VMOne) running on RegionTwo and RegioneOne respectively.<\/p>\n
Conclusions<\/strong>
\nWe have seen how to install two controllers in two different OpenStack regions having the same keystone which is populated during the stacking phases. We have also made some example of booting servers on the two separate regions. The horizon dasboard is also centralised and allows to manage from a web interface the infrastructures by selecting a specific region. Make yourself further tests between the two controllers. The second part of this post will be again utilising the two regions\u00a0 together with a middleware that will be acting as a survaivibility manager implementing a simple Disaster Recovery lifecycle according last ICCLab newsletter<\/a>.<\/p>\n
Some improvemens of the network configurations will be needed, this will be also part of the next blog. Stay tuned.<\/p>\n
Tweets by ancibug<\/a>