Skip to content

Server Load Balancing

Jump to bottom
Luca Pollini edited this page Oct 19, 2015 · 5 revisions

Server Load balancing is another interesting use case where states are necessary to ensure consistency in forwarding decisions for packets of a same transport layer flow (identified by TP.src,IP.dst,TCP.src,TCP.dst). In current OpenFlow this is handled via group tables and "switch-computed selection algorithm" whose configuration and state management are external to OpenFlow. OpenState can be used to configure and execute the logic of forwarding consistency in the switches. In this tutorial we'll show how to realize the Forwarding Consistency application by leveraging OpenState features.

Before going further into this tutorial, you have to make sure you've already installed the OpenState softswitch in Mininet as explained here http://openstate-sdn.github.io/. The completeness of this step leads Mininet to use OpenState as its OpenFlow user space switch.

Server Load Balancing distributes the workloads across multiple replicas of the same server. The selection of the server is performed by means of a new group entry type that select randomly one of the action buckets of a group entry.

Server Load Balancing

Step-by-step Simulation Startup

  1. Launch server load balancing controller application in Mininet by typing the following command:

    $ ryu-manager ~/ryu/ryu/app/openstate/forwarding_consistency_1_to_many.py

  2. Start Mininet with a single topology with 4 hosts:

    $ sudo mn --topo single,4 --mac --switch user --controller remote

  3. To actually test the scenario we need to open 6 xterm (3 for h1 and one for h2, h3 and h4)

    mininet> xterm h1 h2 h3 h4

  4. Write inside the terminals of h2-h3-h4 the following commands to start the Echo Servers :

    h2# python ~/ryu/ryu/app/openstate/echo_server.py 200 h3# python ~/ryu/ryu/app/openstate/echo_server.py 300 h4# python ~/ryu/ryu/app/openstate/echo_server.py 400

  5. Type the following command in h1 terminal:

    h1# nc 10.0.0.2 80

Type something on stdin and then press return. In this case netcat will read from stdin and send the message to the server. It is possible to verify the forwarding consistency by looking at the H1 terminal output: the responding server is always the same (h2 or h3 or h4)!

h1#  nc 10.0.0.2 80
Hello
[from h3]: Hello
World!
[from h3]: World!    
...

  1. The selection of a new server can be tested by closing and re-opening the connection: press ctrl-c and repeat step 5

    h1# nc 10.0.0.2 80 Hello [from h2]: Hello World! [from h2]: World!
    ...

Furthermore, it is possible to test multiple parallel connections from H1 using the above command in each of H1 terminals. H1 believes to be in contact with a single server (10.0.0.2:80), but actually each netcat connection is directed to one of the h2-h3-h4 machines (10.0.0.2:200 | 10.0.0.3:300 | 10.0.0.4:400).

To debug flow entries:

$ sudo dpctl -c tcp:127.0.0.1:6634 stats-flow table=0

To debug group entries:

$ sudo dpctl -c tcp:127.0.0.1:6634 stats-group-desc

To debug group entries statistics:

$ sudo dpctl -c tcp:127.0.0.1:6634 stats-group

To debug state entries statistics:

$ sudo dpctl -c tcp:127.0.0.1:6634 stats-state
Clone this wiki locally