Dan's Network: December 2014

Forget OpenStack, forget VMWare, Docker is the new kid on the block.

TL;DR

Docker and Linux containers result in more dense VMs per physical servers, increasing the network load per physical server and developers use it to run more VMs than ever before.

Also, there is no vSwitch (that is the most important peace of information).

What is Docker?

Docker is an echo system built on top Linux containers. To tell the tale, we need to start with Hypervisors.

Hypervisors

The "regular" virtualization is a hardware virtualization. That means that a hypervisor such as ESX, or even your laptop running vmware/vbox, emulates several virtualized physical servers running side by side on a single physical machine.

Notice that each virtual machine is running it own OS. That is wasteful. Especially because it is very rare to find two applications running inside a single server, so for each application, we run the OS too.

The plus side is that you can run any mix of OSes side by side on the same physical server.You can run Windows, Linux, Solaris, IOSv, ASAv, CSR1000v, vMX, Alteon VA, F5, Vyatta, etc.... concurrently on one physical server.

Linux Containers

It looks very similar to the previous diagram, isn't it? I just changed the text inside the blocks :)

Now everything is running on a single Linux kernel. The applications run on top LXCs. And here comes the big difference. LXCs are part of the Linux kernel. LXCs provide a lightweight VMs, all sharing the same OS. Only one OS is running for all containers.

LXC is to Linux containers/namespaces/layered filesystem as VMWare is to ESXi, vmtools, etc... LXC is an umbrella term for all what it takes to run Linux containers.

Notice the "all sharing the same OS". There is only one LXC per kernel. Each "VM" is called a container. Each container has its files, its users, and its networking.

It should ring a bell to us, networking engineers. It is just like VRFs. We do not need to run a full blown IOS per each VRF. Same goes with LXC. We do not run a full blown OS (Linux) for each VM; LXC just creates isolation same as VRFs.

LXCs compared to Hypervisors results not only that we can cram 10 times more "VMs" on the same hardware, not only that networking is much faster per CPU cycle, not only that containers save a lot of disk space, not only that containers saves memory (one OS) but that it takes less than 200ms to create and run a new container.

Docker

Docker is a set of tools, utilities and repositories:

Deploying and running Linux containers in a very easy way.
Ease the life of developers, QA, and Op teams. It allows all of them to use the same execution environment.

If you are little more interested in what Docker is, here is a short video to watch. It is very recommended!

What does Docker/LXC mean for networking engineers?

A lot more VMs

If Hypervisors brought us virtualization sprawl, imagine what LXC/Docker will do!

VMWare made it much cheaper and easier to create new servers, compared to physical servers. Docker/LXC make it even cheaper and easier.

That means more endpoints in the data centre.

More VMs per physical server

Being able to run more VMs per server, means that we will see more bandwidth consumed per physical server.

Dynamic DC

If it is so easy and fast to spawn and a new VM/container, we might start seeing more VMs created and destroyed on the fly.

No vSwitch

The default networking model for Docker is nothing but standard.

For network engineers, with VMWare nothing changed compared to the physical world. Servers (VM) are connected to switches (vSwitche). Server's switches (vSwitche) are connected to other switches (real switches) using Dot1Q uplinks.

With Docker the is no such concept as vSwitch (at least not by default, or even not built-in as an integrated option).

On part II of Docker networking, I'll explain the default Docker networking model.

AlteonOS has a reach REST API for monitor, operation, and configuration.

REST can be used/called with verity of programming languages, or even just using wget. However, since this blog was already using TCL for AppShape++ scripting, we may as well keep using TCL for REST too. However, RESTing with TCL is a bit pain in the ..., so this time I'll use python instead.

All most forgot to explain what REST is. Its a way to run remote procedures calls using HTTP. Example calls:

Read interface counters
Update real's weight
Bring down a real inside a group

I strongly recommend using a browser plugin for testing out REST calls. I use HttpRequest for firefox.

Here are two screenshots. The first is how I get the current status of real 1, and the second is how I disable real 1.

Lab goal

Using the base setup, create python script to toggle the status of real 1 from not enabled to enabled and from disable to enable.

Setup

I'll use my Loadbalancer Lab Setup.

The loadbalancer is Radware's Alteon VA version 29.5.1.0

The initial Alteon VA configuration can be found here.

Notice the group and hosts are preconfigured:

/c/slb/real 1
        ena
        ipver v4
        rip 10.136.85.1
/c/slb/real 2
        ena
        ipver v4
        rip 10.136.85.2
/c/slb/real 3
        ena
        ipver v4
        rip 10.136.85.3
/c/slb/group 10
        ipver v4
        add 1
        add 2
        add 3

Python script

I have used python 2.7 and the following modules: json and requests

Alteon's REST API is using json as its data format. Python's build in json module converts python dict to json format and vice-versa.

requests is a very easy python module to use for REST API.

Here is the source code for the python script. See the comments inside for explanations:

import requests
import json
import sys


# set Alteon and real parameters
ALTEON = "10.136.1.100"
REAL = "1"
USER = "admin"
PASSWORD = "admin"

# get the current status of real server
# ============================================================

# set authentication object
myAuth=requests.auth.HTTPBasicAuth(USER, PASSWORD)

# set request string with the ALTEON name/ip address and the 'real' we want to toggle
reqSTR =  "https://"+ALTEON+"/config/SlbOperEnhRealServerTable/" + REAL

# turn off SSL warning. Don't do this in production!
# see here how to deal with it http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification

requests.packages.urllib3.disable_warnings()

# send the request, use the auth object, don't verify certification and return a python dct out of json string
# The return is a one item dict with  'SlbNewCfgEnhRealServerTable' as key. 
# That item contains one item list, hence the [0]
# That list item is another dict with two entries: 'Status' and 'Index' we need the Status
r = requests.get(reqSTR, auth=myAuth, verify=False).json()['SlbOperEnhRealServerTable'][0]
state = r['Status']


# print current state and set the new requierd state
if state == 1:
    print "Real is enabled. Changing status to disabled"
    newStatus = "2" # disabled
elif state == 2:
    print "Real is disabled. Changing status to enabled"
    newStatus = "1" # enabled
elif state == 3:
    print "Real is disabled but waiting for cookies to timeout. Changing status to enabled"
    newStatus = "1" # enabled
elif state == 4:
    print "Real is disabled but waiting for sessions to timeout. Changing status to enabled"
    newStatus = "1" # enabled
elif state == 5:
    print "Real is disabled but waiting for sessions to timeout and for cookeis to timeout. Changing status to enabled"
    newStatus = "1" # enabled
else:
    # we should never get here
    print "error retrieving real status. return object:"
    print r
    sys.exit(0)

# set the new real status
# ============================================================

# create JSON data to be passed
myData = json.dumps({'Status' : newStatus})

# send the oper command to change the status. Notice that his time the method is PUT
r = requests.put(reqSTR, auth=myAuth, verify=False, data=myData).json()['status']

# print the return status of the command
print r

Test

Notice how the status is changing from one run to the other.

Summary

Alteon's REST API is easy to use and straight forward. It is way better then using expect scripts for automation.

Dan's Network

Sunday, December 28, 2014

Docker for network engineers. Part 1 - What is Docker?