Foundry Server Iron Server Load Balancer (SLB)

 I have recently had the pleasure of working with a few of the server irons that ev1 deploys as load balancers within the private racks and in the process of setting them up noticed the lack of easy to read documentation. The foundry website is full of great information but it takes a lot of reading and most of it is targeted at the telnet prompt and not the web interface. I have written this guide targeted at doing an initial setup of the slb as well as some more the more advanced configuration that clients may need. If you have purchased a load balancer inside of a private rack you will be dealing with the same hardware that this guide is targeted towards.

 Topics Covered:

Basic configuration
Configuring a single website
Layer 7 health checks
Advanced configuration
Layer 7 routing
Telnet
Help
Commands
General troubleshooting

 Basic Configuration

First and most important thing realize that if you do not save the settings to the flash they will NOT be present when the slb is rebooted. You would not want all your hard work to go to waste so make sure to click “Save to flash” which is located at the very bottom when you are done setting up something! The next important thing to realize is that there are 2 sections to the menus in the slb. The very top section deals with monitoring while the bottom section deals with the configuration. Though they look very similar they lack of ability to change settings in the monitoring can be very confusing if you forget where you are and click the wrong link.

 Everything that we will be doing is in the configuration menu which is half way down.  The Configuration > System section has a few menus that deal with stuff like QOS and the actual slb setup but for most people nothing needs to be changed here. The datacenter will do the initial configuration to get it online, which is obvious if you are able to login.  Under the Configuration > SLB > General section there are a few options that are worth looking at, I am not going to discuss them all as most are self explanatory but I will point out the primary settings.

Max session limit: Global limit for the slb
Ping retries: This is the number before the server is marked as failed and removed from the cluster
Ping interval: This is the interval between pings to the servers that are being sent requests
Sticky age: Number of minutes that an IP will be bound to a particular server, this setting is important if you use php sessions. You can use anything from 2-60 minutes.
Max URL switch: This is for the layer 7 routing
Load Balancing Metric: I would highly suggest you leave this on least connections as this will let the slb send the connections to the server with the lowest number of connections.

  Configuration for a single website Go to “Real Server” this is where you will physically add your servers. Every server that you intend to be controlled by the load balancer must be first placed here. Note that the network will only support servers on your rack or switch and not anywhere remote due to the limitations of the slb unless specifically configured.  Click on “Add real server”

Server name: This is any name you want and is for internal usage
Server IP – The server ip
Max Connections – This is the max connections at any one time the server can accept, I generally leave this at the default. The advantage of this setting is if you have a slower server you can still run it in the cluster and just set a low limit so after that the bigger servers get the traffic.
Least Connection Weight – 0 is best, this setting will make it favor or disfavor this particular server when looking where to put the next connection based on the lowest number of connections.

The other options are fine by default, click add

 Now click on “real server port” to add services to the server and click on the “add real server port”. If you want a server to respond to more then one service you will have to add another real server port.

Server name: the name you picked above
TCP/UDP port: This is the service that it is going to be serving. This is also how the system knows how to do the type of layer 7 health check.Very simply put the layer 7 health check is a way of verifying that the balanced system is in fact alive and does not simply have the port open. When the sld initiates a test it will perform a handshake with the load balancer and ensure that it is properly responding to requests.
Status: This is how you can temporarily turn off a server if you need to take it out of the cluster or do not want it in the cluster even if it is working.
DNS Parameters: This deals with DNS and I am not going to be covering that for now
HTTP Parameters: This is part of the layer 7 health check. Generally unless you know what you are doing the defaults are just fine
Method: Get is the most common and will probably be what you want for the method of how it requests the health check
URL: The url it performs the check on
Status code: This is the response that the server will want to make sure the server is online
**Group range: This setting is very important for the layer 7 routing; we will work with it later

Go ahead and click “add”

 Now click on “virtual server” this is where the configuration for the actual websites is made. From here we can setup on what ports and ips are listening for incoming connections as well setup. Click on the “Add virtual server”

Server name: This is the name for the group of servers that will be listening on the below ip
Server ip: This ip is what will be physically bound to the slb and listening for incoming connections. This is the ip that you will need your dns to resolve to for your websites
Leave the next few settings at the default
Load balancing metric: This is the core of the load balancer. Generally you want it to be least connections as this will choose the server with the least number of connections to send the next request. The least sessions option is also useful if you have a website that may have very long sessions that take awhile to clear out. Response time is just whichever is responding faster. Round robin will simply send them to a different server in an order. The weighted it used from the config above and will send the requests to the server with the greatest weight based on an internal logic. Generally the default is good here.

Go ahead and click “add”

Now click on the “Virtual server port” to configure which ports the above configured virtual server will listen. Go ahead and click on the add virtual server port. As with the real server ports you will have to add an additional virtual server port if you want the virtual server to listen for multiple services.

Server name: This is the group name configured in the last step
TCP/UDP port: This defines which service that will be listening.
Status: Turns off the entire virtual server port meaning this would kill all servers responding to this ip and port.
Sticky: You will probably want this enabled as it will let users “stick” to the server they start with, this is useful when they have some sort of a php session

The rest of the settings are just fine at the default. Click “add”

 Finally we are ready to take the last step and actually connect the virtual servers and the real servers. Go ahead and on the main menu click “bind” then add bind.

Virtual server name: This is the name of the virtual server and defines which external ip it is going to listen on
Virtual TCP/UDP port: What service it is going to server
Real server name: The physical balanced server that will be online
Real TCP/UDP port: The service that is bound on the real server

 Click bind and you are done! Now to make sure you keep all of your hard work click “Save to flash”!   

Advanced configuration

The major topic that I am going to cover in this section for now is the layer 7 routing which is very useful for redirecting requests to the correct server. In a basic sense what layer 7 routing does it is takes a request by a client and parses the request, and then it compares it with the rules and sees if it needs to be sent to a special server or if it can just go on to where it would normally go. The primary use of this would be if you have a single top level domain but want to run different parts of it on different servers for whatever reason.

The first step in setting up the layer 7 routing is to setup server groups. Each real server port can be a member of a range of groups which gives you a lot of variables to play with. The idea if a request matches one in the list it is sent to a given group of servers. A server will behave like a regular server even while in a group; it will just accept the additional requests it is sent on top of the normal ones.

Under configuration click the “real server port” and then modify one of the HTTP ports for a given server. There is going to be a group of boxes at the bottom that allow for a range of groups. Simple choose a range, say 1 to 5, then click modify.

The next step is to configure the ruleset which is surprisingly easy. On the main menu select “URL Map”

Name: This is what it is going to look for in the actual url that is being sent to the slb.
Method:
Pattern: The slb will search for the pattern anywhere in the url
Suffix: The slb will search for the pattern at the very end of the url
Prefix: The slb will search for the pattern at the very beginning of the url
  Default: Leave this at the default setting
TCP Port: This is just to set which port it is talking about, web servers use port 80  

Click “Add” and you have now added a rule for layer 7 routing! If you want to add more you can simply create more groups or more “url maps”. If you want you can simply add multiple url maps to a single group number as well as multiple servers to the same group.

 I will add more to the advanced configuration in time but the layer 7 routing is I imagine what most people are interested in.  

Telnet

I do not have intentions of making a very large telnet section for this guide but I do want to provide a very basic introduction to the interface as well as some of the valuable commands for troubleshooting. I prefer to use the web interface for simplicity when adding servers and rules but I prefer to use the telnet interface for live monitoring. To login the interface simply telnet to the same ip that you access the web gui with. Please note that you cannot telnet from a server that is behind the load balancer as it does not have direct access to the ip. The login and password is the same that is used for the web gui. The list of all commands can be printed out simply typing a ? and hitting enter. If you would like more information about a specific command use “command ?” and it will list the further options that are present.

 Some of my favorite commands for troubleshooting and just general knowledge of the network:

show server – This command gives a general overview of the entire slb and how it is operating. It provides an important look at how all of the servers are performing and how many sessions each has handled and is handling as well as errors. You will have to hit enter a few times to display everything

sh serv sessions – This command is similar to the above but it only lists the connection and session statistics instead of a lot of extra stuff.

enable – This command will enable even more functions, such as the clear below. You will need to login again in order for the command to authenticate you to have full write access

clear server tot-conn real – This command clears the total connection stats and is useful in troubleshooting

 
 

Troubleshooting

 This is a pretty broad topic but I am going to hit some quick important points. I have not been working with the slb for long but as I get more experience I will be adding more information and ideas. Please feel free to send some if you have any. The best thing that I have for now to suggest is to telnet into the server and run the “show server” command. This will show you which servers are offline and why as well as which are online and how many connections they are processing. Take a look at the current connections along with the current sessions. If one server has a lot more sessions then another then there is some sort of a problem causing the session to not end for too long. This can be because the server load is higher, apache timeouts are different, or maybe the website simply has some requests that take longer and the one server got more for a random reason.  At no time should the total connections be very different in number. We had trouble with an slb in that one server just would not be sent and requests. To fix it we saved all the settings to the flash and rebooted it, problem solved. Though these foundry load balancers are very stable do not rule out rebooting it if needed. The reboot function can be reached in the web gui via the “restart” function.   Conclusion This is all that I am going to write for now. Please do not post this guide on any internet forums or public websites without my express permission. I would love to know if you are using this guide for internal support! I do have intentions of adding on to this guide in time as I work with the slb more and figure out more tips and tricks.

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website