Thursday, March 17, 2016

[LBaaS] The Load Balance as a Service trace records

A couple of days ago, my colleague imparts Load Balance as a Service (LBaaS) which is the Neutron Plugin to provide the load balancer functionality in OpenStack. Unavoidably, I still like to drill down how it works so that we won't only understand the surface of this function. This article is only focused on the trace record because I have studied the concept of LBaaS. For those who don't know about its concept and implementation, please check out other resources first, ex: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary 


  • If created a lb pool ready, you can see something like the following picture. My point is to trace subnet and network port.




  • From the "subnet" link, we can trace back to the its detail and also can go to its network detail by clicking the link of network id.  




  • Here we can find the vip port that is for our load balancer as follows.

Click it to see its details.



  • Now, we will use the first part of port id (70081ac2) to trace what happens in linux network space and tun/tap interface.




  • LBaaS agent will create a linux network space and the naming rule is "qlbaas-" with the pool's id. 

# ip netns exec qlbaas-13185f35-3f75-47e7-9fd7-301be7b28e88 ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tap70081ac2-6f Link encap:Ethernet  HWaddr fa:16:3e:16:c7:69
          inet addr:192.168.111.60  Bcast:192.168.111.255  Mask:255.255.255.0
          inet6 addr: fe80::f816:3eff:fe16:c769/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15963 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15762 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:958766 (958.7 KB)  TX bytes:1060728 (1.0 MB)

# ip netns exec qlbaas-13185f35-3f75-47e7-9fd7-301be7b28e88 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.111.1   0.0.0.0         UG    0      0        0 tap70081ac2-6f
192.168.111.0   0.0.0.0         255.255.255.0   U     0      0        0 tap70081ac2-6f

  • The tap interface is ported to OVS bridge: br-int
# ovs-vsctl show | grep 7008
        Port "tap70081ac2-6f"
            tag: 1
            Interface "tap70081ac2-6f"
                type: internal


  • I didn't cover the HAProxy software because my point is only on tun/tap interface and Linux network space. But, how do I find the HAProxy process running on this network space?

# netns=qlbaas-13185f35-3f75-47e7-9fd7-301be7b28e88
# find -L /proc/[1-9]*/task/*/ns/net -samefile /run/netns/"$netns" | cut -d/ -f5
19937 <== the process id

# ps aux | grep 19937
root     14216  0.0  0.0  10432   932 pts/0    S+   02:29   0:00 grep --color=auto 19937
nobody   19937  0.0  0.0  29176  1472 ?        Ss   Mar16   0:06 haproxy -f /var/lib/neutron/lbaas/13185f35-3f75-47e7-9fd7-301be7b28e88/conf -p /var/lib/neutron/lbaas/13185f35-3f75-47e7-9fd7-301be7b28e88/pid -sf 8433

# ip netns identify 19937
qlbaas-13185f35-3f75-47e7-9fd7-301be7b28e88 <== where the namespace the process id is in

Get it. Here we go. So, put all the information together and then we can more understand how LBaaS implements.

No comments: