Wednesday 25 September 2019

Load Balancing Algorithms

A load balancing algorithm controls the circulation of approaching requests to your bunch of servers. There are various strategies utilized to finish this, contingent upon the unpredictability of load adjusting required, the sort of the main job, and the distribution of the requests coming in.

Some Common methods include:-
Round Robin:--

The most primitive load distribution technique. In a round robin scenario, the load balancer simply runs down the list of servers, sending one connection to each in turn, and starting at the top of the list when it reaches the end

Weighted Round Robin:--

It works on the same principle as Round Robin, but the number of connections that each machine receives over time is proportionate to a ratio weight predefined for each machine.
For example, the administrator can define that Server 1 can handle five times the traffic of Servers 2, and thus the load balancer should send five requests to Server 1 for each one request sent to Servers 2.

Least Connections
Transfers the latest session to the server with the least connections at the time of session initiation. To avoid latency, this method is advisable in an environment where server capacity and resources are uniform. Least Connections is considered problematic, as most implementations are challenged to accurately measure actual server workload.
In the above example Server 1 is handling only one request from (5) whereas Server 2 is handling 3 requests (2,4,6). Thus the subsequent requests will be handled by Server 1.

Weighted Least Connections
Identical to Least Connection, except that servers are selected based on capacity, not just availability. For each node, the admin specifies a Connection Limit value, and the system creates a proportional algorithm on which load balancing is based.

Least Pending Requests
The emerging industry standard, Least Pending Requests selects the server with the least active sessions based on the real-time monitoring. Requires assignment of both Layer 7 and TCP profile to the virtual server.
To achieve optimal load distribution and maximize performance, administrators must carefully weigh the pros and cons of their load balancing algorithms of choice.
                            


Virtual Server versus Virtual IP Address

load balancing intermediaries have long used the terms “virtual server” and “virtual IP address”. With the widespread adoption of virtualization these terms have become even more confusing to the uninitiated. Here’s how load balancing and application delivery use the terminology.
I often find it easiest to explain the difference between a “virtual server” and a “virtual IP address (VIP)” by walking through the flow of traffic as it is received from the client.
When a client queries for “www.yourcompany.com” they get an IP address, of course. In many cases if the site is served by a load balancer or application delivery controller that IP address is a virtual IP address. That simply means the IP address is not tied to a specific host. It’s kind of floating out there, waiting for requests. It’s more like a taxi than a public bus in that a public bus has a predefined route from which it does not deviate. A taxi, however, can take you wherever you want within the confines of its territory. In the case of a virtual IP address that territory is the set of virtual servers and services offered by the organization.
The client (the browser, probably) uses the virtual IP address to make a request to “www.yourcompany.com” for a particular resource such as a web application (HTTP) or to send an e-mail (SMTP). Using the VIP and a TCP port appropriate for the resource, the application delivery controller directs the request to a “virtual server”. The virtual server is also an abstraction. It doesn’t really “exist” anywhere but in the application delivery controller’s configuration. The virtual server determines – via myriad options – which pool of resources will best serve to meet the user’s request. That pool of resources contains “nodes”, which ultimately map to one (or more) physical or virtual web/application servers (or mail servers, or X servers).
A virtual IP address can represent multiple virtual servers and the correct mapping between them is generally accomplished by further delineating virtual servers by TCP destination port. So a single virtual IP address can point to a virtual “HTTP” server, a virtual “SMTP” server, a virtual “SSH” server, etc… Each virtual “X” server is a separate instantiation, all essentially listening on the same virtual
It is also true, however, that a single virtual server can be represented by multiple virtual IP addresses. So “www1” and “www2” may represent different virtual IP addresses, but they might both use the same virtual server. This allows an application delivery controller to make routing decisions based on the host name, so “images.yourcompany.com” and “content.yourcompany.com” might resolve to the same virtual IP address and the same virtual server, but the “pool” of resources to which requests for images is directed will be different than the “pool” of resources to which content is directed.  This allows for greater flexibility in architecture and scalability of resources at the content-type and application level rather than at the server level.


BIG-IP Upgrades Part 4 - Performing the Software Installation

On a Big-IP in the Standby state (if there are more than one Big-IP in the device group), perform the following:
  • -->Log in to the Configuration Utility as a user with administrator privileges.
     
  • --->Upload the necessary ISO files (two images if a Hotfix is being applied):
    • -Via the Configuration Utility, navigate to System/Software Management and click the Import button.
    • -Alternatively. ISO files can be uploaded directly via Secure Copy (SCP) transfer directly to /shared/images/ and will automatically appear in the Configuration Utility when complete
    • -If you are not already running the configuration to be upgraded, boot into a software volume containing the configuration to be copied to another volume.
       
  • -->In the Configuration utility, click System.
     
  • -->Click Software Management.
     
  • -->Click the Hotfix List tab. If no Hotfix is being applied, click the Images tab. (Note that even if a Hotfix ISO file is installed, two installation will happen in the background; the first will install the Final [larger] ISO and the second will install the Hotfix ISO. In the GUI, you will see two progress bars move from 0-100%).
     
  • -->Check the image name you want to install.
     
  • -->Click the Install button. The Install window opens.
     
  • -->Select an available disk from the Select Disk drop-down menu.
     
  • -->From the Volume Set Name menu, select an empty volume set from the Volume Set Name drop-down menu or type a new volume set name.
    Note: You can use any combination of lowercase alphanumeric characters (a-z, 0-9) and the hyphen (-) character for the volume set name. The volume set name can be 1 to 32 characters in length, but cannot be only one 0 (zero) character (for example HD1.0 or MD1.0). For example, if the HD1 disk is active and you type siterequest into the volume set name, the system will create a volume set named HD1.siterequest and install the specified software to the new volume set. HD1.3 is typical (which conforms to the old v9 limitation).
     
  • Click Install. If the string you type does not match an existing volume set, the system creates the volume set and installs the software.
     
  • -->In the Installed Images section, the Install Status column first shows the base image installation progress and then the Hotfix installation progress.
Once the installation process is complete:
  • -->Navigate to System > Software Management > Boot Locations and click the boot location containing the desired software version.
     
  • -->Click the Activate button to automatically reboot the system to the specified boot location.
The upgrade can take up to 30 or more minutes depending on the size of the configuration. If the installation fails, running the command tmsh load sys config may show an error which will aid troubleshooting.

Once the standby unit is upgraded:
  • -->Verify expected objects appear in the shared and non-shared portions of the configuration. For example, check that Local Traffic > Pools and Network > Vlans has the expected objects present.
     
  • -->Verify pool health status matches an Active unit's pool status.
     
  • -->Check the most recent logs (/var/log/ltm for example) for obvious signs of issues like repeating messages. Comparing logs to the active unit or to the logs prior to the upgrade can be helpful. In addition or alternatively, you can generate a qkview and review it in the iHealth Diagnostics section for currently known issues.
     
  • -->Force the Active unit to Standby (the upgraded system should take the Active role).
     
  • -->Test client traffic to the upgraded system's traffic objects (for example, virtual servers) to confirm the upgraded unit is processing traffic correctly.
Once the health of the upgraded unit is confirmed, repeat all the above upgrade steps on the peer Big-IP which is now in the Standby state and running the lower Big-IP version. Once all upgrades are complete, create a new set of UCS archives to retain backups of the new Big-IP version's configuration.

BIG-IP Upgrades Part 3 - Versions, Misconceptions and a Back-Out Plan

To What Big-IP Versions Can I Upgrade?

Big-IP 10.x can be upgraded to any version of 11.x given your hardware supports the new version. Big-IP 11.x can be upgraded to any version of 12.x given your hardware supports the new version. You cannot upgrade directly from 10.x to 12.x. For more information, refer to:
To What Big-IP Version Should I Upgrade?
The Latest Maintenance Release of each Long Term Stability Release are the best choices for security and sustainability. The lowest-numbered version in the Latest Maintenance Release column is generally considered the most stable while the highest number contains the newest features and security fixes.

Misconceptions and Perils

  • "It's a firmware upgrade"
    • Big-IP runs on either a physical or virtual disk with CentOS Linux installed as the base operating system. While there are also various internal firmware upgrades which take place between software versions, a Big-IP upgrade is at heart an operating system and tmos (Traffic Management Operating System) upgrade.
       
  • "It will take two minutes"
    • The fastest Big-IP upgrades will be around 15 minutes and up to an hour or more depending on the speed of the disk, CPU and size of the Big-IP configuration being upgraded. Be patient. Forcing a reboot during the installation process may lengthen recovery time and take more effort.
       
  • "I can install to the current, running software volume"
    • Engineers don’t often say this out loud but I have inferred some thinking this. Big-IP forces you to install to a software volume which is not currently in-use so that you are able to boot the old volume should there be a problem with the new one.
       
  • "No need to reactivate the license"
    • This is the #1 mistake made in regards to Big-IP upgrades. Assume a license reactivation IS necessary until you can explain exactly why it isn’t.
       
  • "Didn't run tmsh load sys config verify before the upgrade"
    • This is less common an issue but can be nasty if not caught early. Essentially, if the command does not succeed, not only should you expect upgrades problems but also config sync problems and possibly issues even reverting to the old software volume. Make sure this command completes without error before upgrading.
       
  • "No need for UCS backups"
    • What if you reboot your hardware and it never comes back up? Having a UCS archive will saves a lot of time should something go wrong and you need to restore a Big-IP quickly.
       
  • "Let's upgrade and reboot both Big-IPs at the same time to save time"
    • Again, you need to be sure one Big-IP is operational before risking losing both units in a high availability configuration. Just because a piece of electronics is running right now doesn’t mean it necessarily turn back on.
       
  • "I have serial console port access but no need to check that's it's working prior to the upgrade"
    • If you have easy access to a serial port connection to your Big-IPs, use it. A big advantage here is that you can still watch installation progress while the network ports are down.

Back out Procedure

If a Big-IP fails to upgrade and further troubleshooting cannot be performed due to time constraints, follow the below steps before reverting to the previous Big-IP version.
  • Run the tmsh load /sys config command to determine what may be causing a configuration load error.
     
  • Gather a qkview.
     
  • Once the above data is gathered, you can boot the previous Big-IP version by using the Configuration Utility (System/Software Management/Boot Locations/ and click the Activate button which will reboot the system. to change to another software volume via the command line.
Note: The above back out procedure does not apply if you have reset the Big-IP to default settings.
  • Alternatively, you can load your previously saved UCS archive

BIG-IP Upgrades Part 2 - Upgrade Behavior

In this section, I'll describe some of the basics behind Big-IP software upgrade operations.
  • Software images can be installed to any software volume except the running volume. This behavior ensures the running software volume is available should a need arise to revert to the prior Big-IP version and configuration.
     
  • It is recommended to install the Big-IP update to an empty software volume to avoid potential confusion should the configuration fail to push to the new software volume.
     
  • By default, the current running configuration is pushed to the new software volume automatically.
     
  • The 'Install Configuration' option in the Configuration Utility can be used to update the target software volume prior to booting/activating the volume if time has elapsed since the software was installed and some of the Big-IP configuration has changed in the interim. This is generally unnecessary if you install the software and immediately boot into it.
     
  • For a Big-IP instance, multiple Big-IP software installations can exist on disk. Use the tmsh show sys software command to view all software volumes. You can install directly over an existing software volume and the target volume will be overwritten. In order to delete a software volume, you can use the Configuration Utility or tmsh. Software installation can be performed via the Configuration Utility or tms
    •  
  • When a Hotfix ISO file is installed, two installations will happen in the background; the first will install the Final (larger) ISO and the second will install the Hotfix ISO. In the GUI, you will see two progress bars progress from 0-100%.
     
  • The first boot of the new Big-IP software volume will take extra time, compared to a reboot, in order to decompress packages and to import the running configuration for the first time. Installation progress can be monitored via the serial console port or via the vconsole command in the case of vCMP Guest upgrades.
     
  • For Big-IP 10.x to 11.x upgrades, the previous configuration will first appear in the /config/bigpipe/ directory in the new software volume. When the new software volume is first booted, the configuration in /config/bigpipe/ will be converted and copied to the /config/ directory. So, if there are no virtual servers in /config/bigip.conf after upgrading from v10.x, the conversion process from /config/bigpipe/ likely failed for some reason.
     
  • High Availability (HA) communication via network failover will function between major software branches but is only supported for the duration of the upgrade process. For example, a pair of Big-IPs running 11.5.3 and 12.1.1 can negotiate Active/Standby status via network failover. 
     
  • Configsync will not operate between different major software branches. For example, you cannot synchronize configurations from a unit running 11.5.3 unit to a unit running 11.5.4; you must wait for both units to be upgraded until configsync will operate
  • If a blank blank configuration is desired after the upgrade is complete
     
  • As an alternative method to install the desired software version, prepared USB media can be used to reinitialize the disk and Big-IP software to factory defaults. Once complete, a previously saved UCS archive can be loaded to restore configuration. This method will wipe all data on the system. For more information, refer to:

    •  
  • If the software installation completes and you are able to boot the new volume but the Big-IP configuration fails to be migrated, you may see an error in the Configuration Utility.
The configuration has not yet loaded. If this message persists, it may indicate a configuration problem.
To determine what may be causing the error, run the tmsh load sys config verify command.

vCMP considerations

  • While vCMP guests are their own operating system, they inherit their license from the vCMP host or hypervisor. Before any vCMP guest can be upgraded, the vCMP host license must be reactivated.
     
  • When a vCMP Host is upgraded, the Guests will go offline. A Host upgrade will not upgrade individual Guests.
     
  • Only upgrade one vCMP Guest at a time to avoid excessive disk and CPU usage.
     
  • For a vCMP Host, it is recommended but not required to run the same Big-IP version as the highest version Guest being hosted.
     
  • For F5 platforms with multiple blades, software image ISO files are shared between blades. In 11.6.0+, ISO files are also shared from Hosts to Guests.
     
  • Hosts and Guests utilize unique UCS configuration files. For instance, a Host UCS file does not contain Big-IP objects (for example, self IP addresses or virtual servers) for the Guests which are installed on the Host.

Virtual Edition Considerations

  • Just like Big-IP installed on a hardware platform, ISO files are used to upgrade. OVA files are only used to instantiate a Big-IP Virtual Edition.

BIG-IP Upgrades Part 1 - Preparation

The information is this series is meant to help a Big-IP administrator complete a software upgrade. I have assisted with hundreds of Big-IP upgrades and hope to help you complete the task as smoothly as possible.
For more information related to a specific Big-IP release, there are additional details in the release notes for each version. For more information, refer to the Release Notes page.
The information in this series applies to:
  • F5 platforms which support Big-IP version 10.x - 13.x
  • Big-IP Virtual Edition
  • vCMP Big-IP Host platforms
  • vCMP Big-IP Guest instances

    For information regarding upgrading from Big-IP 9.x to 10.x, refer to the following guide:
      Manual Chapter: Upgrading from Versions 93x and 94x.   

Procedures

Note: If you are familiar with Big-IP upgrade behavior and only need to review the actual steps, use the Performing the Software Installation section

Prerequisites

  • License reactivation is required prior to installing a newer Big-IP version. For more information, refer to
K7727: License activation may be required before a software upgrade for the BIG-IP or Enterprise Manager system

Generate a qkview diagnostics file and review iHealth for any triggered upgrade-related heuristics in the Diagnostics and Upgrade Advisor tabs. Each Big-IP product has its own set of requirements pertaining to software upgrades and iHealth is the best utility to find up to date heuristics governing successful Big-IP product migrations.
  • For more information, refer to:
  • Create a UCS archive of the Big-IP's configuration and save it remotely in case it is needed for recovery purposes. For more information, refer to K4423: Overview of UCS archives.
  • Verify your Big-IP system is running version 10.x, 11.x, 12.x or 13.x and is using the volumes formatting scheme (the command  lvscan should not be blank).
The command output should appear similar to the following example (the sizes may differ):
  • Check running configuration integrity by running one of the following commands. No errors should be returned (warnings may not hinder a software upgrade but should be corrected if possible).
    • In Big-IP version 10.x

           bigpipe verify load
       
    • In Big-IP version 11.x and 12.x

           tmsh load sys config verify
       
  • Navigate to https://downloads.f5.com and download the desired software:

    • Recommendations Prior to Installation

    • before you upgrade the BIG-IP software, review the release notes on AskF5 (support.f5.com) in the Documentation section for your product and version. Pay close attention to the following items:
        • Review the Known issues list.
        • Review the Behavior change section(s).
        • Review the Upgrading from earlier versions section.
        • Review the Upgrading from earlier configurations section.
        • Review the installation checklist.

        • Verify a connection to the serial console port is working. This not required but will allow monitoring of installation progress and provides additional recovery options. .
      • When you have a date for the upgrade, we recommend starting a proactive Service Request with your plan in case there are complications during your change window. For more information, refer to 
      • Testing the upgrade procedure on a lab environment using Big-IP Virtual Edition can be helpful to find potential issues before they are encountered in a production environment.
        1. Features:
          - Inexpensive compared to higher throughput Big-IP VE licenses.
          - LTM, GTM, DNS, AFM, ASM, AAM, CGN, APM Lite (10 users).
          - In Big-IP v11.4.1 - 11.6.x, you can import Big-IP 10.x - 11.x UCS archives. In Big-IP v12.x, you can import Big-IP 11.x - 12.x UCS archives. Copy the UCS file to /var/tmp and use the following command:
        2. tmsh load sys ucs /var/tmp/.ucs no-license no-platform-check

          Limitations:
          - May not be available in all countries
          - Total system throughput limited to 10Mbps​

      • Retain a UCS archive from every Big-IP in your network on a remote filestore to aid disaster recovery. Even if the archive has aged and does not contain all configuration objects, it will provide faster recovery time than completely reconfiguring the Big-IP.

      • For full planning and assistance during an upgrade, F5 Professional Services is a good resource. Support will answer specific questions regarding the upgrade but can't be used start to finish to perform upgrades




iRule

  iRule: -- o iRule is a powerful and flexible feature within the BIG-IP local traffic management (LTM). o IRule is a powerful & flexibl...