Skip to main content

Introduction to SoftLayer/IBM's Cloud Load Balancer.

IBM Cloud Load Balancer(CLB) Introduction.

They have couple of other LBaaS services but here we are going talk to about the Cloud Load Balancers.

IBM introduced a new Cloud Load Balancer, which is equal to Amazons AWS (elasticity, ssl termination and L7/Application load balancing, auto recovery etc etc). All these in one LBaaS unlike AWS.

IBM CLB offers couple of variations which user can apply at the time of CLB creation. For e.g.
  • Select which data center one wants to create the CLB in.
  • User can select a private CLB or Public CLB. Public CLB can be reached from the public networks where as private CLB can only reached within ones private network. 
  • For Public CLB one can select which public VLAN one can use. There is an option to use the IBMs public VLAN where customer doesn't have any control or user can select to get the public VAN from their own account, where customer have absolute control over it.
  • Which private VLAN to use.
  • Customize CIPHER for SSL HTTPS support (Can be only done as part of edit CLB)
IBM's CLB provides a domain name as the end point for using the CLB. It's highly recommended(or the only way it must be used) that one use the domain name instead of using the IP addresses associated with the domain name as IP address associated with the CLB domain name might change at the time of elastic operations.

CLB are billed in the following ways.
1. Service usage hours.
2. The outbound public bandwidth charges.(not applicable to private CLBs).
3. Total Data Processed (total of bytes in and bytes out).

Creating CLB

IBM's CLB can be created or managed though GUI or APIs. Here I am going to show how create/manage the CLBs through GUI.

1. goto https://control.softlayer.com/network/loadbalancing/cloud and click on Order IBM Cloud Load Balancer or directly goto https://control.softlayer.com/network/loadbalancing/cloud/create
you will land in the  following page.


2. Select data center in which you want to create the CLB. Please note based on the data center prices may vary. Click next.

3. In this page one can chose to create a public CLB or Private CLB, select the private VLAN and chose from where to get the public IPs. as shown below and click next.

Troubleshooting tip: If you decided to use your own public subnet for public IP make, sure you have opened the proper ports else creation will fail. Same thing with the private subnet.

4. In the next screen one is going to enter a name, a description and create front end and backend protocol. as shown in the image below.
Some points to be noted.
  1. Name has to fit a valid domain name as it's used in the returned CLB dns name.
  2. At the time of creation of CLB user can max add 2 protocols (i.e. 2 listeners and 2 backend pool). One can add more after CLB is create successfully. 
  3. In this below image I am creating 2 protocols, one with HTTP frontend protocol with port 80 and other one is a HTTPS with port 443. Please note if you want to create a HTTPS load balancer one must have a cert in the IBMs cert service.
  4. For the backends I am using HTTP protocol along with port 80.
  5. There are dropdown options for load balancing method, session stickiness(only SOURCE IP is supported) and one can enter max connection anywhere from 1-15k

So lets click next and see.

5. Managing health monitors. Health monitors are used to monitor the health of the members added to the backend pool(shown in next step).
As shown in the below image we can see there is only one health monitor created even though we added 2 backend protocols(pools). This is because both the backend protocols have same protocol and port so only one health monitor created for both.  If we had 2 different backend protocol or port then we will have 2 health monitors. To put it in the general term for every different backend protocol and port a new health monitor will be created.

One can edit following properties of the load balancer. I am just going to retain the original values.
  1. INTERVAL (SEC)
  2. TIMEOUT (SEC)
  3. MAX TRIALS
  4. PATH 
Some of the things to keep in mind to avoid problems.
  1. HTTP health monitor expects a status code of 200, there is no way to configure this.
  2. Make sure the backend members can respond with 200 status code for PATH provided here for backend protocol HTTP and backend port configured in above step.
  3. For TCP a hand shake will be attempted to determine if the backend member is health on configured  port.
Troubleshooting tip: Sometimes when the backend member's health is shown as unhealthy even though one made sure that the members are responding properly. In this case one can have any of the following problems.
  1. Backend member's private VLAN is different from the CLB's private VLAN, in this case if the VLAN spanning is not enabled there is no way for CLB to reach those members in the different private VLAN. https://knowledgelayer.softlayer.com/fr/procedure/enable-or-disable-vlan-spanning
  2. Firewall is blocking the traffic on your private network from CLB to backend members.

6. Time to add some backend members. One can add both bare metal and virtual servers as the backend members to the load balancer. All the members added here will be added to both the backend pools(in this example), in general term to all the backend pools created in step 4. If load balancing algorithm is  weighted round robin weight of members can be edited too.


7. Order verification page. Verify once and click create to create the CLB. Wait for it to take back to the CLB page, if you can't find the newly created CLB refresh the page, it sometimes takes some seconds to appear there. Wait for the LB to become active. 




8. CLB summary page.

9. Data flowing through the CLB. Since the load balancing algorithm is round robin request are sent to the members in one after the other.

  1. Request over HTTPS port 443

  1. Request over HTTP port 80



Please note that it's a personal blog. Any comments and questions are welcome. Happy to help :)
Labels:

Comments

Post a Comment

Popular posts from this blog

Enable stats GUI on haproxy.

Add bottom snippet to the haproxy.conf below the defaults section. listen  stats         bind 19.41.259.10:1234         mode            http         log             global         maxconn 10         clitimeout      100s         srvtimeout      100s         contimeout      100s         timeout queue   100s         stats enable         stats hide-version         stats refresh 30s         stats show-node         stats auth admin:password         stats uri  /haproxy?stats Make sure you are updating the IP address on the bind to your VIP and if you want, you can change the port also. One can even change the uri on the last line of the above snippet, like stats uri /haproxy_stats or whatever one wants. To make sure you have not done any mistake in the config file, one can use the following command to validate. haproxy -c -f haproxy.cfg Once everything looks good, restart the haproxy process and stats GUI should be available at 19.41.259.10:1234/hapro
Post a Comment
Read more

Sending a SIGHUP signal to some external process from Python script

Code : import psutil import os import signal pids = psutil.get_pid_list() for pid in pids: if psutil.Process(pid).name == "process_name": os.kill(pid,signal.SIGHUP) break Steps to follow. 1.Get the PID of the process, in this case  "process_name"   to which you want to send out a SIGHUP signal. 2.Use os.kill(pid,sig) command to send out the SIGHUP signal to that process. 1.Get the PID of the process to which you want to send out a SIGHUP signal. One has to install a package called psutil by the following command. easy_install psutil Check out the following links for more details https://code.google.com/p/psutil/ https://pypi.python.org/pypi/psutil use psutil.get_pid_list() to get all of the PIDs. psutil.get_pid_list() works in the following manner.  pids = [ int ( x ) for x in os . listdir ( '/proc' ) if x . isdigit ()] return pids once you get all the PIDs get the PID you are i
Post a Comment
Read more

How to enable Openstack Octavia, LBaaS V2 with devstack.

Little Intro to Octavia. Octavia is a service manager for Openstack Load balancer as a service. Neutron LBaaS V2 plugin talks to Octavia through Octavia driver. Octavia driver talks to Octavia api(o-api) and that in turn talks to Octavia control worker(o-cw). Neutron LBaaS V2 Plugin ----> Octavia plugin driver -----> o-api ----> o-cw Other than o-api and o-cw Octavia has 2 more components, housekeeping(o-hk) and health manager(o-hm). o-api Octavia api server which receives all the request from octavia LBaaS driver and passes it to o-cw. o-cw It's the main workhorse, it creates the load balancer VMs( amphorae ), configures them. o-hk keeps track of spare amphorae. o-hm Manages the health of the amphorae through heartbeats, collects the stats and takes care of fail over by creating a new amphora when it fails to get the heartbeat. How to enable Openstack Octavia, LBaaS V2 with Devstack. Since octavia uses a VM for loadbalancer its needs good a
Post a Comment
Read more