DoIT Network Services Knowledgebase


 ADVANCED

What to submit when asking for layer4 service.

This document will tell what to put in the request when asking layer4 services.

Things to keep in mind

Currently only specific submits can be load balanced with the layer4 switch. If your server is not on one of these subnets it will have to move to a load balanced subnet.

Load balanced subnets as of 10/27/2008 are:

  • 144.92.197.128/25 = Portal Public
  • 144.92.8.0/24 = Portal Private
  • 144.92.170.0/25 = Test (ITE) Public
  • 144.92.7.0/24 = Test (ITE) Private
  • 128.104.1.128/25 = General purpose server load balancing - Production network
  • 128.104.236.0/23 = D2L (desire to Learn)
  • 144.92.29.192/26 = VISA Proxy
  • 144.92.49.192/26 = General purpose server load balancing - Test network

    • Add/change/deletion examples

    Example #1
Please forward this case to Network Service.
I need the following L4 config created:

  VIP = 144.92.197.135 (my.wisc.edu)
    Server = 144.92.197.205 (unas.doit.wisc.edu)
    Server = 144.92.197.165 (djer.doit.wisc.edu)
    Server = 144.92.197.166 (sethos.doit.wisc.edu)
      TCP Port = 80, metric = hash
      TCP Port = 443, metric = hash
      TCP Port = 25, metric = roundrobin 

Date/Time when this can be done: anytime

Thanks,
sysadmin Chuck



Example #2
Please forward this case to Network Service.
I need the following server ADDED to an already existing VIP:

  VIP = 144.92.197.135 (my.wisc.edu)
    Server = 144.92.197.202 (den.doit.wisc.edu)
      TCP Port = 80
      TCP Port = 443

Date/Time when this can be done: anytime

Thanks,
sysadmin Chuck


Example #3
Please forward this case to Network Service.
I need the following server REMOVED from the layer4 switch:

    Server = 144.92.197.164 (darius.doit.wisc.edu)

Date/Time when this can be done: anytime

Thanks,
sysadmin Chuck



Example #4
Please forward this case to Network Service.
I need the following TCP port REMOVED from the followng VIP:

  VIP = 144.92.197.135 (my.wisc.edu)
      TCP Port = 25

Date/Time when this can be done: anytime

Thanks,
sysadmin Chuck

    Metric Descriptions

    Minimum Misses
    The minmisses metric is optimized for Application Redirection. It uses IP address information in the client request to select a server. The specific IP address information used depends on the application:

  • For Application Redirection, the client destination IP address is used. All requests for a specific IP destination address is sent to the same server. This metric is particularly useful in caching applications, helping to maximize successful cache hits. Best statistical load balancing is achieved when the IP address destinations of load-balanced frames are spread across a broad range of IP subnets.
  • For SLB, the client source IP address and real server IP address are used. All requests from a specific client are sent to the same server. This metric is useful for applications where client information must be retained on the server between sessions. With this metric, server load becomes most evenly balanced as the number of active clients with different source or destination addresses increases. When selecting a server, the switch calculates a score for each available real server based on the relevant IP address information. The server that scores the highest is assigned the connection. This metric attempts to minimize the disruption of persistency when servers are removed from service. This metric should be used only when persistence is a must.
    NOTE – The minmisses metric cannot be used for firewall load balancing, since the real server IP addresses used in calculating the score for this metric are different on each side of the firewall.

    Hash
    The hash metric uses IP address information in the client request to select a server. The specific IP address information used depends on the application:

  • For Application Redirection, the client destination IP address is used. All requests for a specific IP destination address will be sent to the same server. This is particularly useful for maximizing successful cache hits.
  • For SLB, the client source IP address is used. All requests from a specific client will be sent to the same server. This option is useful for applications where client information must be retained between sessions.
  • For FWLB, both the source and destination IP addresses are used to ensure that the two unidirectional flows of a given session are redirected to the same firewall. When selecting a server, a mathematical hash of the relevant IP address information is used as an index into the list of currently available servers. Any given IP address information will always have the same hash result, providing natural persistence, as long as the server list is stable. However, if a server is added to or leaves the mix, then a different server might be assigned to a subsequent session with the same IP address information even though the original server is still available. Open connections are not cleared.
    NOTE – The hash metric provides more distributed load balancing than minmisses at any given instant. It should be used if the statistical load balancing achieved using minmisses is not as optimal as desired. If the load balancing statistics with minmisses indicate that one server is processing significantly more requests over time than other servers, consider using the hash metric.

    Least Connections
    With the leastconns metric, the number of connections currently open on each real server is measured in real time. The server with the fewest current connections is considered to be the best choice for the next client connection request. This option is the most self-regulating, with the fastest servers typically getting the most connections over time.

    Round Robin
    With the roundrobin metric, new connections are issued to each server in turn; that is, the first real server in the group gets the first connection, the second real server gets the next connection, followed by the third real server, and so on. When all the real servers in this group have received at least one connection, the issuing process starts over with the first real server.

    Response Time
    The response metric uses real server response time to assign sessions to servers. The response time between the servers and the switch is used as the weighting factor. The switch monitors and records the amount of time it takes for each real server to reply to a health check to adjust the real server weights. The weights are adjusted so they are inversely proportional to a moving average of response time. In such a scenario, a server with half the response time as another server will receive a weight twice as large.
    NOTE – The effects of the response weighting apply directly to the real servers and are not necessarily confined to the real server group. When response time-metered real servers are also used in other real server groups that use the leastconns or roundrobin metrics, the response weights are applied on top of the leastconns or roundrobin calculations for the affected real servers. Since the response weight changes dynamically, this can produce fluctuations in traffic distribution for the real server groups that use the leastconns or roundrobin metrics.

    Bandwidth
    The bandwidth metric uses real server octet counts to assign sessions to a server. The switch monitors the number of octets sent between the server and the switch. Then, the real server weights are adjusted so they are inversely proportional to the number of octets that the real server processes during the last interval. Servers that process more octets are considered to have less available bandwidth than servers that have processed fewer octets. For example, the server that processes half the amount of octets over the last interval receives twice the weight of the other servers. The higher the bandwidth used, the smaller the weight assigned to the server. Based on this weighting, the subsequent requests go to the server with the highest amount of free bandwidth. These weights are automatically assigned. The bandwidth metric requires identical servers with identical connections.
    NOTE – The effects of the bandwidth weighting apply directly to the real servers and are not necessarily confined to the real server group. When bandwidth-metered real servers are also used in other real server groups that use the leastconns or roundrobin metrics, the bandwidth weights are applied on top of the leastconns or round-robin calculations for the affected real servers. Since the bandwidth weight changes dynamically, this can produce fluctuations in traffic distribution for the real server groups that use the leastconns or roundrobin metrics.

    Persistent Hash
    The phash metric provides the best features of hash and minmisses metrics together. This metric provides stable server assignments like the minmiss metric and even load distribution like the hash metric. When you select the phash metric for a group, a baseline hash is assumed based on the configured real servers that are enabled for the group. If the server selected from this baseline hash is unavailable, then the old hash metric is used to find an available server. If all the servers are available, then phash operates exactly like hash. When a configured server becomes unavailable, then clients bound to operational servers will continue to be bound to the same servers for future sessions and clients bound to unavailable servers are rehashed to an operational server using the old hash metric. With phash however, when more servers go down, then you will not have an even load distribution as you would with the standard hash metric.



    Keywords: l4 layer4 load balancing portal test VIP persistence server ITE hash metric roundrobin Doc ID: 4246
    Owner: Scott B.Group: Network Services
    Created: 2005-12-07Updated: 2009-10-29

    Did this document help you to answer your question?