Episode 1 – The Misconception (An OpenStack Series)

We were introduced a few years ago. Like most other people in similar line of work as myself, I was content with what I had. Yes it had its ups and downs and I was spending way too much time trying to fix problems that were created by someone else, however the thrill of knowing that all was well at the end of the day was what kept me going.

In the beginning, I said to myself, this is too complicated. If I get in to this I would need to manage a much larger friend circle, the corresponding relationships, the ups and downs and not to forget the constantly changing behavior. Did I want to get in to something like this at this point in my life? Sometimes you just got to take a leap of faith. So I did, and boy has it been an exciting few years.

If you are still reading this article, then you are probably asking yourself, “What in the world is this guy rambling about!!!,” and rightly so. When you spend countless hours, day in and day out, working on something it becomes a part of your life. Obviously not as intimately as described above, but who said we can’t have a bit of fun. We have all seen a plethora of Installation, Configuration, Best Practices, Not so Best Practices books, guides, articles, blogs etc, etc, etc, etc on the topic of ……….. “OpenStack (AKA OS)” (Yay!! you guessed it.)

os-logo

I did not want to produce yet another installation guide. Rather, I wanted to share my experience of learning and understanding the OpenStack Platform. My fear is that by the time I am done with these articles they will inevitably turn in to yet another guide, but I will try to make the process a bit more fun and share my two cents in the process.

Reading Level: Intermediate

Environment: OpenStack (Newton) on Ubuntu 16.04

Let me start by saying, I feel that the OpenStack platform is sometimes misunderstood. It is not complicated, however like all magnanimous things, it is complex. So what do you do when you encounter something complex? You take a 180 degree turn and you run, run like your life depended on it. Just kidding. But seriously you run! However, if you are like me and adore the nerdy misery in your life you try to make some sense of the complexity. You will never understand it in its entirety, and attempting to do so is futile. Rather you need to ask yourself what you want from it? And then understand it accordingly. In these first few episodes we will go through the journey of introducing the basic components that form the whole (at least certain parts of it), what are their basic duties, do they get along well and how each of them are similar but with their unique subtle differences.

Before we get our hands dirty, it dawned on to me that some of you might have no clue as to what I am talking about. So like a good story teller let me introduce the main character of this series. I give to you OpenStack. What is it? Simply put, it is a software platform that will allow you to embrace the goodies of the Cloud revolution. In simpler terms, if you want to rent Servers, VMs, Containers, Development Platforms, Middleware, (and anything else you can imagine,) to customers and charge them for the usage, OpenStack will allow you to setup the platform for achieving this. There are more complicated questions like who are your customers, how are they paying, what are they getting etc, etc and all these will be answered in due time. OpenStack has a great community that meets not once but twice a year at wonderful locations world wide, to bring the best brains of the business together. They talk about technology and how it is changing the world. If you want detailed information just head to their website http://www.openstack.org

So like anything important in life, if you want something and you are serious about it, you have got to define your goal and do the ground work. The platform is no exception. Our goal is to perform a manual installation of OpenStack (not the all in one.)

For the record I think that all the different vendors that offer OpenStack are doing a wonderful job with their respective installers and in a production environment, you should in most cases use these installers. Besides being automated and simple to setup, they also take care of things like High Availability and upgrades. But if one day you have to troubleshoot an OpenStack environment, and believe me you will, you will be thankful that you did the manual install in your lab to understand how things are configured.) And that is precisely our goal here.

So lets explore the neighborhood. Go through the diagram below:

ose1-1
OpenStack Base Environment

The above setup describes where OpenStack will reside in our setup. Below are the details:

Server 1 controller
Comment Here is where it keeps all the important stuff
Server OS Ubuntu 16.04
Resources 1 CPU, 4GB RAM
IP Addresses 10.30.100.215
Technical Brief This is the main hub that hosts most of the fundamental services that form OpenStack
——————– —————————————————-
Server 2 neutron
Comment This is how it interacts with the outside world
Server OS Ubuntu 16.04
Resources 1 CPU, 4GB RAM
IP Addresses 10.30.100.216, 172.16.80.216
Technical Brief This is the networking component that handles all IP based communications for components and hosted guests
 ——————–  —————————————————
Server 3 compute1
Comment This is where it entertains all its guests
Server OS Ubuntu 16.04
Resources 1 CPU, 4GB RAM
IP Addresses 10.30.100.213
Technical Brief This is the server where you host the virtual machines that are rented to your customers.
 ——————–  —————————————————
Management Network (inner voice) Used for all internal communication within OpenStack. When one OS component wants to talk to the other.
Tenant Networks (chatty guests) Network used by customer virtual machines (When customers are rented virtual machines, they can also be given certain networks, in case they want to setup more than one machine and make them talk to each other. This network is used by such customer networks. )
External Network (Lets call overseas) Used by OS to talk to the outside world. (Lets say your customer machine needs internet, then this is the network used by the respective virtual machines to access the internet.)

If you have come so far and are wanting to follow along to setup this environment with me then the following will definitely help. On each of my three servers the /etc/hosts file looks like this:

A. Host file configuration: /etc/hosts

# ensure that the local hostname is resolvable especially on compute nodes
127.0.0.1       <localhostname> localhost

# controller 
10.30.100.215 controller 

# compute1 
10.30.100.213 compute1 

# neutron 
10.30.100.216 neutron

Note that I am assigning controller, compute1 and neutron as aliases. If you change these then make sure to use the changed references when you use them in the configuration files later.

Also networking seems to have given me some issues in the past so below is a sample /etc/network/interfaces file for each of the servers:

B. Interface file configuration: /etc/network/interfaces

@contoller
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The management1 interface
auto ens3
iface ens3 inet static
address 10.30.100.215
netmask 255.255.255.0

@neutron

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The management1 interface
auto ens3
iface ens3 inet static
address 10.30.100.216
netmask 255.255.255.0

# The Tunnel interface
auto ens9
iface ens9 inet manual
up ifconfig ens9 up

# The external interface
auto ens10
iface ens10 inet static
address 172.16.80.216
netmask 255.255.255.0
gateway 172.16.80.254
dns-nameservers 8.8.8.8

@compute1

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The management1 interface
auto ens3
iface ens3 inet static
address 10.30.100.213
netmask 255.255.255.0

# The tunnel interface
auto ens9
iface ens9 inet manual
up ifconfig ens9 up

I am not going to go in to the details of each of the interface, except one thing that you need to note. The Tunnel interface in both the neutron and compute node will NOT have any IP since it is used as a trunk for multiple Tenant (Customer) networks in OS. Also if you are using VLAN tagging, make sure that this particular interface is un-tagged.

From this point whenever you see @SERVERNAME it simply implies that the configuration that I am talking about needs to be done on that server. So @controller means ‘Please perform these configurations/installations on the controller server.

@controller

C. NTP configuration:

NTP for those who don’t know is network time protocol. Since our central character (namely OS) resides across 3 houses (servers), we need to make sure that the clocks in all these houses show the same time. What happens if they don’t? Ever get off a 15 hour flight? Your body is jet lagged and completely out of sync with the local time of where you have landed. Rendering you to be quite useless until you have taken some rest and the body has readjusted to the new timezone. Something similar happens to distributed software working across systems with out of sync clocks. The symptoms are sometimes quite erratic and it is not always straight forward to pin point the problem. So setup NTP as follows:

Configure @controller as the master clock:

  • Install the service
sudo apt install chrony

NOTE: Whenever I used sudo vi that means I want you to edit the file. The indented lines that follow are what need to be edited in the file

  • Configure a global NTP server in the configuration file
sudo vi /etc/chrony/chrony.conf
 server 0.asia.pool.ntp.org iburst
 allow 10.30.100.0/24
  • start the NTP service
sudo service chrony restart

Configure @neutron and @compute1 to sync time with the controller:

Install the service

 sudo apt install chrony

Configure controller as the master NTP server in the configuration file

 sudo vi /etc/chrony/chrony.conf
   server controller iburst  #(Comment all other pool or server entries)

Start the NTP service

sudo service chrony restart

D. OpenStack Packages

newton-logoSince we are performing the install on a Ubuntu linux system we need to add the corresponding repositories to get the OpenStack Software. For the record I am working with the Newton release of OpenStack.

On @controller, @neutron and @compute1 perform the following configuration:  

sudo apt install software-properties-common
sudo add-apt-repository cloud-archive:newton

sudo apt update && sudo apt dist-upgrade
sudo reboot #(This seems to be a good idea to avoid surprises)
sudo apt install python-openstackclient #(Just the OS client tools)

E. Maria DB

Like most distributed systems OS requires a database to store configuration and data. In our case it resides on the controller and almost all components will access it. Do note that the base configuration of most components resides in configuration files, however what you create inside OS is saved in the database. Consider this to be the intellectual capital of the OS environment. Perform the following steps on the @controller node:

Install the software

sudo apt install mariadb-server python-pymysql

Configure the database

sudo vi /etc/mysql/mariadb.conf.d/99-openstack.cnf
  [mysqld]
  bind-address = 10.30.100.215
  #The bind-address needs to be set to the Management IP of the controller node.
  default-storage-engine = innodb
  innodb_file_per_table
  max_connections = 4096
  collation-server = utf8_general_ci
  character-set-server = utf8

Restart ther service

sudo service mysql restart

Secure the installation

sudo mysql_secure_installation

(Answer the questions that follow with information relevant to your environment.)

F. RabbitMQ

By now you must have realized that our main character OS is not an ordinary organism. It does not have all its parts tightly knit together, rather it is composed of a number of autonomous/semi-autonomous modules that perform their respective functions to form the greater whole. However in order to do that they need to communicate effectively and efficiently. In certain cases a centralized Message Queuing system called RabbitMQ is used to pass messages between components with in OpenStack. Please do note that certain components sit on more than one system and perform different functions in different roles. But we will leave that for a later episode. For now perform the following configuration on the @controller node:

Install the software

sudo apt install rabbitmq-server

Create a master user. Replace MINE_PASS with your won password

sudo rabbitmqctl add_user openstack MINE_PASS

Allow full permissions for the user created above

sudo rabbitmqctl set_permissions openstack ".*" ".*" ".*"

G. Memchached:

Honestly I am not an expert at this one, but I do know that it helps with loading the web pages for the application a bit faster. One way of giving OS a better short term memory I guess.

Install the software on the @controller node

sudo apt install memcached python-memcache

Configure the IP for the controller management interface in the conf file

sudo vi /etc/memcached.conf
   -l 10.30.100.215

Start the service

sudo service memcached restart

RECAP:

  • You know the central character’s name.
  • You know its whereabouts.
  • You know what all things it needs to survive and how to set them up, if you wanted one for yourself.
  • You are EXICITED!! (hopefully)
ose1-2
What we have achieved so far

NEXT:

  • You will get to know more about what our main character is made of.
  • How to get an OS of your own.
  • Be more EXCITED!! 😛

If you have survived this reading till now, I thank you for your patience aand for reading this post. If you have any questions/comments please feel free to share below in the comments section so everyone from different sources can benefit from the discussion. . If you want to know what happens next please take a look at Episode 2: Getting to know her better.

For my latest posts please visit WhatCloud.

Advertisements

14 thoughts on “Episode 1 – The Misconception (An OpenStack Series)

Add yours

  1. For now, great!
    Questions:
    1) because I don’t have any lab environment, is there any place to setup this lab for free for some period of time?
    2) to get the latest release for example, is it enough to change “cloud-archive:newton” to “cloud-archive:ocata”?
    Thank you.

    1. Hi!

      Thank you for the appreciation.
      For your first question you could try out one of the Public Cloud Providers such a AWS, GCP or AlibabaCloud. They all give you free credit as a new user so you could set it up there. The compute though will be degraded since it will be virtualized
      For your second query, I wish it were that simple. There will be differences from version to version when deploying OpenStack however as per my past experience those differences are usually minor. I would suggest try out your approach and if you get stuck then refer to the official ocata guide

  2. Làm vậy nào xuể tóc lượm trường học và
    lượm thắng rất lắm chị em quãng trong suốt thời kì gấn đây, mà lại đả nạm nào đặt tóc
    tai sít trường học và mau hiệu quả, tiết kiệm thời kì và tiền nong cho chị em thời chửa nếu ai cũng biết.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Powered by WordPress.com.

Up ↑

%d bloggers like this: