Archive for application delivery

Deploy BIG-IP VE in Microsoft Azure Using an ARM Template

Posted in f5, big-ip, cloud, application delivery, devcentral, azure, access by psilva on April 12th, 2017

arm_logo1.jpgAzure Resource Manager (ARM) templates allow you to repeatedly deploy applications with confidence. The resources are deployed in a consistent state and you can easily manage and visualize resources for your application.

ARM templates take the guesswork out of creating repeatable applications and environments. Deploy and deploy again, consistently.

Let’s walk through how to deploy a simple, single-NIC configuration of BIG-IP VE in Microsoft Azure using an ARM template.

First, go to the F5 Networks Github site where we keep our supported templates. There are other community-based templates at www.github.com/f5devcentral if needed but for F5 supported templates, go to the F5 Networks site.

ave1.jpg

To view Azure templates, click f5-azure-arm-templates. In that folder you’ll see experimental and right under that is supported (the one you want).

ave2.jpg

Then click on the standalone folder and then the 1nic folder, which is the simplest deployment.

ave34.jpg

And as you scroll through and review the ‘Read Me,’ you’ll see the Deploy to Azure button under Installation. Select either Bring Your Own License (BYOL) or Pay As You Go (PAYG), depending on your situation.

ave5.jpg

This will launch the Azure Portal and the only thing you’ll really need is a license key if you chose BYOL. Then simply fill out the template.

In this case, we’re going to use an existing resource group that already contains an application.

ave7.jpg

Important: In the Settings section under Admin UN/PW, enter the credentials you want to use to log in to BIG-IP VE. The DNS Label (where you see REQUIRED) will be used to access your BIG-IP VE, for example, if you enter mybigip, the address will be something like  ‘mybigip.westus.cloudapp.azure.com.’ Give the Instance Name something familiar for easy finding.

ave9.jpg

There are different Azure Instance Types, which determine CPU and memory for your VM, and F5 licensing (Good/Better/Best), which determines the BIG-IP modules you can deploy. Then, if needed, enter your BYOL license key.

In addition, to be more secure, you should enter a range of IP addresses on your network in the Restricted Src Addresses field so it’s locked to your address range. This setting determines who gets access to the BIG-IP instance in Azure, so you’ll want to lock it down.

After the tag values, agree to the terms and conditions and click Purchase.

ave91.jpg

Next, you can monitor progress on the deploy status. Keep hitting refresh and you’ll start seeing resources getting populated along with the top blue ‘Deploying’ indicator. When the Deploying bar disappears, you know you’re done.

ave93.jpg

Once complete, you get the notification that the BIG-IP VE was deployed successfully. Next, we’ll navigate to the resource group we selected at the top and then the security group for the BIG-IP.

ave96.jpg

You can see that within the security rules we’ve allowed ports 443 (HTTPS) and 22 (SSH). 22 allows access to the management port; this is the way we’d connect to the BIG-IP to configure and administer.

ave97.jpg

Going back to the resources, the BIG-IP VE itself is listed at the top.

ave98.jpg

When we click on the Virtual BIG-IP we can get the IP address and using a browser through port 443, we can connect either with the DNS name or the IP address to the config utility.

ave97.jpg

Here you would enter the Azure credentials you specified in the template.

ave991.jpg

And that’s all there is to it. Now you can configure your virtual servers, pool, profiles and anything you’d normally do on BIG-IP VE for your unique requirements. Thanks to Suzanne Selhorn for the basis of this article and catch a video demo here.

ps

Related:

 

 




Lightboard Lessons: Service Consolidation on BIG-IP

Posted in f5, adc, silva, application delivery, lightboard, devcentral, infrastructure, consolidate by psilva on March 29th, 2017

The Consolidation of point devices and services in your datacenter or cloud can help with cost, complexity, efficiency, management, provisioning and troubleshooting your infrastructure and systems.

In this Lightboard Lesson, I light up many of the services you can consolidate on BIG-IP.

ps

 

Watch Now:



What is a Proxy?

Posted in Uncategorized, security, big-ip, silva, application delivery, devcentral, proxy by psilva on March 28th, 2017

devcentral_basics_article_banner.png

 

The term ‘Proxy’ is a contraction that comes from the middle English word procuracy, a legal term meaning to act on behalf of another. You may have heard of a proxy vote. Where you submit your choice and someone else votes the ballot on your behalf.

In networking and web traffic, a proxy is a device or server that acts on behalf of other devices. It sits between two entities and performs a service. Proxies are hardware or software solutions that sit between the client and the server and does something to requests and sometimes responses.

The first kind of proxy we’ll discuss is a half proxy. With a Half-Proxy, a client will connect to the proxy and the proxy will establish the session with the servers. The proxy will then respond back to the client with the information. After that initial connection is set up, the rest of the traffic with go right through the proxy to the back-end resources. The proxy may do things like L4 port switching, routing or NAT’ing but at this point it is not doing anything intelligent other than passing traffic.

halfvsfull.jpg
Basically, the half-proxy sets up a call and then the client and server does their thing. Half-proxies are also good for Direct Server Return (DSR). For protocols like streaming protocols, you’ll have the initial set up but instead of going through the proxy for the rest of the connections, the server will bypass the proxy and go straight to the client. This is so you don’t waste resources on the proxy for something that can be done directly server to client.

A Full Proxy on the other hand, handles all the traffic. A full proxy creates a client connection along with a separate server connection with a little gap in the middle. The client connects to the proxy on one end and the proxy establishes a separate, independent connection to the server. This is bi-directionally on both sides. There is never any blending of connections from the client side to the server side – the connections are independent. This is what we mean when we say BIG-IP is a full proxy architecture.

The full proxy intelligence is in that OSI Gap. With a half-proxy, it is mostly client side traffic on the way in during a request and then does what it needs…with a full proxy you can manipulate, inspect, drop, do what you need to the traffic on both sides and in both directions. Whether a request or response, you can manipulate traffic on the client side request, the server side request, the server side response or client side response. You get a lot more power with a full proxy than you would with a half proxy.

reverseproxy_thumb.jpgWith BIG-IP (a full proxy) on the server side it can be used as a reverse proxy. When clients make a request from the internet, they terminate on the reverse proxy sitting in front of application servers. Reverse proxies are good for traditional load balancing, optimization, server side caching, and security functionality. If you know certain clients or IP spaces are acceptable, you can whitelist them. Same with known malicious sources or bad ranges/clients, you can blacklist them. You can do it at the IP layer (L4) or you can go up the stack to Layer 7 and control an http/s request. Or add a BIG-IP ASM policy on there. As it inspects the protocol traffic if it sees some anomaly that is not native to the application like a SQL injection, you can block it.

forwardproxy_2.jpgOn the client side, BIG-IP can also be a forward proxy. In this case, the client connects to the BIG-IP on an outbound request and the proxy acts on behalf of the client to the outside world. This is perfect for things like client side caching (grabbing a video and storing locally), filtering (blocking certain time-wasting sites or malicious content) along with privacy (masking internal resources) along with security.

You can also have a services layer, like an ICAP server, where you can pass traffic to an inspection engine prior to hitting the internet. You can manipulate client side traffic out to the internet, server side in from the internet, handle locally on the platform or or pass off to a third party services entity. A full proxy is your friend in an application delivery environment.

If you'd like to learn more about Proxies, check out the resources below including the Lightboard Lesson: What is a Proxy?

Related:

 




Protecting API Access with BIG-IP using OAuth

Posted in security, f5, big-ip, application delivery, devcentral, api by psilva on March 21st, 2017

As more organizations use APIs in their systems, they've become targets for the not-so-good-doers so API Security is something you need to take seriously. Most APIs today use the HTTP protocol so organizations should protect them as they would ordinary web properties.

Starting in v13, BIG-IP APM is able to act as an OAuth Client, OAuth Resource Server and OAuth Authorization Server. In this example, we will show how to use BIG-IP APM to act as an OAuth Resource Server protecting the API.

In our environment, we’ve published an API (api.f5se.com) and we’re trying to get a list of departments in the HR database. The API is not natively protected and we want APM to enable OAuth protection to this API.

api1.jpg

 

First, let’s try an unauthenticated request.

api2.jpg

 

You can see we get the 401 Unauthorized response which is coming from the BIG-IP. In this instance we’re only sending 3 headers, Connection (close), Content Length (0) and WWW Authenticate (Bearer), indicating to the client that it wants Bearer Token authentication.

api3.jpg

 

So we’ll get that authorization and a new access token.

api4.jpg

 

Here the Getpostman.com (Postman toolchain for API developers) is preconfigured to get a new access token from the OAuth authorization server, which is a BIG-IP.

api5.jpg

 

We will request the OAuth token and will need to authenticate to the BIG-IP.

api6.jpg

 

After that, we get an authorization request. In this case, BIG-IP is acting as an Authorization server and is indicating to the resource owner (us) that there is a HR API application that wants to use certain information (about us) that the authorization server is going to provide.

api7.jpg

 

In this case, it is telling us that the resource server wants to get scope api-email.

We’ll click Authorize and now we have our auth token and is saved in the Postman client.

api8.jpg

 

Within the token properties we see that it expires in 300 seconds, it is a Bearer token and the scope is api-email and we get a refresh token as well.

api9.jpg

 

Now we can add this token to the header and try to make a request again. And this time, we get a much better response.

api91.jpg

We get a 200 OK, along with the headers of the application server. We’ll click on the Body tab within Postman, we’ll see the XML that the API has returned in response to the query for the list of departments that are available. There were no cookies being returned by the server if you were wondering about that tab. In the Headers tab we see the Authorization header that was being sent and the content of the Bearer token.

A simple way to easily protect your APIs leveraging OAuth 2.0 Resource Server capabilities in BIG-IP.

Special thanks to Michael Koyfman for the basis of the content and check out his full demo here.

ps

Related:

 

 

 

 

 

 

 

 

 

 

 

 

 




Lightboard Lessons: What is a Proxy?

Posted in security, f5, big-ip, silva, application delivery, lightboard, devcentral, proxy by psilva on March 15th, 2017

The term ‘Proxy’ is a contraction that comes from the middle English word procuracy, a legal term meaning to act on behalf of another.

In networking and web traffic, a proxy is a device or server that acts on behalf of other devices. It sits between two entities and performs a service. Proxies are hardware or software solutions that sit between the client and the server and do something to requests and sometimes responses.

In this Lightboard Lesson, I light up the various types of proxies.

 

 

 

Watch Now:



Shared Authentication Domains on BIG-IP APM

Posted in security, f5, big-ip, application delivery, authentication, AAA, devcentral, access by psilva on February 14th, 2017

How to share an APM session across multiple access profiles.

A common question for someone new to BIG-IP Access Policy Manager (APM) is how do I configure BIG-IP APM so the user only logs in once.

By default, BIG-IP APM requires authentication for each access profile.

domain_value.jpg

 

This can easily be changed by sending the domain cookie variable is the access profile’s SSO authentication domain menu.

Let’s walk through how to configure App1 and App2 to only require authentication once.

We’ll start with App1’s Access Profile.

dv1.jpg

 

Once you click through to App1’s settings, in the Top menu, select SSO/Auth Domains.

dv2.jpg

 

We’re prompted for authentication and enter our credentials and luckily, we have a successful login.

dv4.jpg

 

And then we’ll try to login to App2. And when we click it, we’re not prompted again for authentication information and gain access without prompts.

dv5.jpg

Granted this was a single login request for two simple applications but it can be scaled for hundreds of applications. If you‘d like to see a working demo of this, check it out here.

ps

 

 

 

 

 

 

 

 

 

 




What is DNS?

Posted in security, f5, big-ip, application delivery, devcentral, dns by psilva on February 2nd, 2017

devcentral_basics_article_banner.png

What is the Domain Name System (DNS)?

Imagine how difficult it would be to use the Internet if you had to remember dozens of number combinations to do anything. The Domain Name System (DNS) was created in 1983 to enable humans to easily identify all the computers, services, and resources connected to the Internet by name—instead of by Internet Protocol (IP) address, an increasingly difficult-to-memorize string of information. Think of all the website domain names you know off the top of your head and how hard it would be to memorize specific IP addresses for all those domain names. Think of DNS as the Internet's phone book. A DNS server translates the domain names you type into a browser, like www.f5.com, into an IP address (104.219.105.148), which allows your device to find the resource you're looking for on the Internet.

DNS is a hierarchical distributed naming system for computers, services, or other resources connected to the Internet. It associates various information with domain names that are assigned to each of the participating DNS entries.

How DNS Works

The user types the address of the site (www.f5.com as an example) into the web browser. The browser has no clue where www.f5.com is, so it sends a request to the Local DNS Server (LDNS) to ask if it has a record for www.f5.com. If the LDNS does not have a record for that particular site, it begins a recursive search of the Internet domains to find out who owns www.f5.com.

First, the LDNS contacts one of the Root DNS Servers, and the Root Server responds by telling the LDNS to contact the .com DNS Server. The LDNS then asks the .com DNS Server if it has a record for www.f5.com, and the .com DNS Server determines the owner of www.f5.com and returns a Name Server (NS) record for f5.com. Check out the diagram below:

dns1.jpg

 

Next, the LDNS queries the f5.com DNS Server NS record. The f5.com DNS Server looks up the name: www.f5.com. If it finds the name, it returns an Address (A) record to the LDNS. The A record contains the name, IP address, and Time to Live (TTL). The TTL (measured in seconds) tells the LDNS how long to maintain the A record before it asks the f5.com DNS Server again.

When the LDNS receives the A record, it caches the IP address for the time specified in the TTL. Now that the LDNS had the A record for www.f5.com, it can answer future requests from its own cache rather than completing the entire recursive search again. LDNS returns the IP address of www.f5.com to the host computer, and the local browser caches the IP address on the computer for the time specified in the TTL. After all, if it can hold on to the info locally, it won't need to keep asking the LDNS.

dns2.jpg

 

The browser then uses the IP address to open a connection to www.f5.com:80 and sends a GET /... and the web server returns the web page response.

dns3.jpg

DNS can get a lot more complicated than what this simple example shows, but this gives you an idea of how it works.

DNS Importance

As arguably the primary technology enabling the Internet, DNS is also one of the most important components in networking infrastructure. In addition to delivering content and applications, DNS also manages a distributed and redundant architecture to ensure high availability and quality user response time—so it is critical to have an available, intelligent, secure, and scalable DNS infrastructure. If DNS fails, most web applications will fail to function properly. And DNS is a prime target for attack.

The importance of a strong DNS foundation cannot be overstated. Without one, your customers may not be able to access your content and applications when they want to—and if they can't get what they want from you, they'll likely turn elsewhere.

Growing Pains

DNS is growing especially with mobile apps and IoT devices requiring name resolution.  Add to that, organizations are experiencing rapid growth in terms of applications as well as the volume of traffic accessing those applications.

In the last five years, the volume of DNS queries on for .com and .net addresses has more than doubled. More than 10 million domain names were added to the Internet in 2016 and future growth is expected to occur at an even faster pace as more cloud, mobile and IoT implementations are deployed.

Security Issues

If DNS is the backbone of the Internet—answering all the queries and resolving all the numbers so you can find your favorite sites—it is also one of the most vulnerable points in your network. Due to the crucial role it plays, DNS is a high-value security target. DNS DDoS attacks can flood your DNS servers to the point of failure or hijack the request and redirect requests to a malicious server. To prevent this, a distributed high-performing, secure DNS architecture and DNS offload capabilities must be integrated into the network.

Generally, DNS servers and DNS cloud services can handle varying amounts of requests per second with the costs increasing as the queries-per-second increase.

To address DNS surges and DNS DDoS attacks, companies add more DNS servers, which are not really needed during normal business operations. This costly solution also often requires manual intervention for changes. In addition, traditional DNS servers require frequent maintenance and patching, primarily for new vulnerabilities.

The Traditional Solution

When looking for DNS solutions, many organizations select BIND (Berkeley Internet Naming Daemon), the Internet's original DNS resolver. Installed on approximately 80 percent of the world's DNS servers, BIND is an open-source project maintained by Internet Systems Consortium (ISC).

Despite its popularity, BIND requires significant maintenance multiple times a year primarily due to vulnerabilities, patches, and upgrades. It can be downloaded freely, but needs servers (an additional cost, including support contracts) and an operating system. In addition, BIND typically scales to only 50,000 responses per second (RPS), making it vulnerable to both legitimate and malicious DNS surges.

Next Step

If you're ready to learn more or dig deeper into DNS, check out these more advanced articles

 

 

 

 

 

 

 

 




Q/A with itacs GmbH’s Kai Wilke - DevCentral’s Featured Member for February

Posted in f5, big-ip, application delivery, devcentral by psilva on January 31st, 2017

kai_wilke1.jpgKai Wilke is a Principal Consultant for IT Security at itacs GmbH – a German consulting company located in Berlin City specializing in Microsoft security solutions, SharePoint deployments, and customizations as well as classical IT Consulting. He is also a 2017 DevCentral MVP and DevCentral’s Featured Member for February!

For almost 20 years in IT, he’s constantly explored the evens and odds of various technologies, including different operating systems, SSO and authentication services, RBAC models, PKI and cryptography components, HTTP-based services, proxy servers, firewalls, and core networking components. His focus in these areas has always been security related and included the design, implementation and review of secure and high availability/high performance datacenters.

DevCentral got a chance to talk with Kai about his work, life and mastery of iRules.

DevCentral: You’ve been a very active contributor to the DevCentral community and wondered what keeps you involved?

Kai: Working with online communities has always been an important thing for me and it began long time ago within the good old Usenet and the predecessor of the Darknet. Before joining the F5 community, I was also once an honored member of the Microsoft Online Community and was five times awarded as a Microsoft MVP for Enterprise Security and Microsoft-related firewall/proxy server technologies.

My opinion is that if you want to become an expert for a certain technology or product, you should not just learn THE-ONE straight-forward method fetched from manuals, guides or even exams. Instead, you have to dive deeply into all of those edge scenarios and learn all the uncountable ways to mess the things up. And dealing with questions and problems of other peers is probably the best catalyst to gain that kind of experience.

Besides of that, the quality of the DevCentral content and the knowledge of other community members are absolutely astonishing. It makes simply a lot of fun for me to work within the DevCentral community and to learn every day a little bit more…

DC: Tell us a little about the areas of BIG-IP expertise you have.

KW: Over the years, I successfully implemented BIG-IP LTM, APM, ASM, and DNS Service deployments for our customers. Technologically, I internalized TMOS and its architecture very well and I pretty much learned how to write simple but also somewhat complex iRules to control the delivery of arbitrary data on their way from A to B in any possible fashion.

DC: You are a Principal Consultant for IT Security at itacs GmbH - a German consulting company. Can you describe your typical workday?

KW: Because of my history with Microsoft related infrastructures, my current workload is pretty versatile.

itacs_logo.jpgMany of my current projects are still settled in the Microsoft / Windows system environment and are covering the design and review of security related areas. Right now, I’m working with several DAX companies and also LaaS, PaaS and SaaS service providers to analyze their Active Directory and System Management infrastructures and to design and implement a very unique, fundamental and comprehensive security concept to counter those dreaded PtH (Pass-the-Hash) and APT (Advance Persistent Threat) attacks we are facing these days.

Over the last years, my F5 customer base has periodically grown so I would say my work is a 50:50 mix right now. I do F5 workshops, designs, implementations, second and third level support as well as configuration reviews and optimization of existing environments. I work with some big web 2.0 customers that have the demand to pretty much exhaust all the capabilities of an F5. This challenges me as a network architect and as an ADC developer.

I realize every day that working with F5 products makes so much more fun than any Microsoft product I have ever dealt with. So in the future, I will even more put my focus on F5!

DC: Describe one of your biggest BIG-IP challenges and how DevCentral helped in that situation.

KW: In my opinion, the F5 products themselves are not that challenging – but sometimes the underlying technologies and the detailed project requirements are. But as long as those requirements can be drawn and explained on a sheet of paper, I am somewhat confident that the BIG-IP platform is able to support the requirements – thanks to the F5 developers who have created a platform which is not purely scenario driven but rather supports a comprehensive list of RFC standards which can be combined as needed.

For an example, one of my largest customers operates an affiliate resource tracking system with three billion web requests per day with a pretty much aggressive session setup rate during peak hours. I have designed and implemented their BIG-IP LTM platform to offload SSL-encryption and the TCP-connection handling to various backend systems using well selected and performance optimized settings.

Other scenarios require slightly more complex content switching, the selective use of pre-authentication and/or combination with IDS/IPS systems. To support those requirements, I developed a very granular and scalable iRule administration framework which is able to simplify the configuration by using rather easy-to-use iRule configuration files (operated by non TCL developers) which will then trigger the much more complex iRule code (written and tested by TCL developers) as needed. The latest version of my iRule administration framework (which is currently under testing/development) will be able to support a couple thousand websites on a single Virtual Server, where each websites can trigger handcrafted TCL code blocks as needed, but without adding linear or even exponential overhead to the system as the regular iRule approaches would do. The core and the configuration files of the latest version are heavily based on TCL procedures to create a very flexible code base and also conditional control structures, but completely without calling any TCL procedures during runtime to boost the performance dramatically. Sounds interesting? Then stay tuned, I am sure I will publish this framework to the CodeShare once it’s stable enough… ;-)

DC: Lastly, if you weren’t an IT admin – what would be your dream job? Or better, when you were a kid – what did you want to be when you grew up?

KW: I was typing my first assembler code out of a C64 magazine at the age of 10, so I really wanted to be a developer and/or IT admin since then. But besides of my current job, I can also imagine being a racecar driver. I really have petrol in my blood and pretty much enjoy driving on the German Autobahn. As an alternative, I could also imagine being a cook. I really love cooking and enjoy awesome food!

DC: Thanks Kai! Just don't fire up that sterno while shifting gears!! Check out all of Kai’s DevCentral contributions and check out their blog websites: ops365.de, flow365.de and brandmysharepoint.de.

 




What is an Application Delivery Controller - Part II

Posted in f5, big-ip, availability, adc, load balance, application delivery, devcentral, infrastructure by psilva on January 26th, 2017

devcentral_basics_article_banner.png

Application Delivery Basics

One of the unfortunate effects of the continued evolution of the load balancer into today's application delivery controller (ADC) is that it is often too easy to forget the basic problem for which load balancers were originally created—producing highly available, scalable, and predictable application services. We get too lost in the realm of intelligent application routing, virtualized application services, and shared infrastructure deployments to remember that none of these things are possible without a firm basis in basic load balancing technology. So how important is load balancing, and how do its effects lead to streamlined application delivery?

Let’s examine the basic application delivery transaction. The ADC will typically sit in-line between the client and the hosts that provide the services the client wants to use. As with most things in application delivery, this is not a rule, but more of a best practice in a typical deployment. Let's also assume that the ADC is already configured with a virtual server that points to a cluster consisting of two service points. In this deployment scenario, it is common for the hosts to have a return route that points back to the load balancer so that return traffic will be processed through it on its way back to the client.

The basic application delivery transaction is as follows:

  1. The client attempts to connect with the service on the ADC.
  2. The ADC accepts the connection, and after deciding which host should receive the connection, changes the destination IP (and possibly port) to match the service of the selected host (note that the source IP of the client is not touched).
  3. The host accepts the connection and responds back to the original source, the client, via its default route, the load balancer.
  4. The ADC intercepts the return packet from the host and now changes the source IP (and possible port) to match the virtual server IP and port, and forwards the packet back to the client.
  5. The client receives the return packet, believing that it came from the virtual server or host, and continues the process.

how_lb_works.png

 

Figure 1. A basic load balancing transaction.

This very simple example is relatively straightforward, but there are a couple of key elements to take note of. First, as far as the client knows, it sends packets to the virtual server and the virtual server responds—simple. Second, the NAT takes place. This is where the ADC replaces the destination IP sent by the client (of the virtual server) with the destination IP of the host to which it has chosen to load balance the request. Step three is the second half of this process (the part that makes the NAT "bi-directional"). The source IP of the return packet from the host will be the IP of the host; if this address were not changed and the packet was simply forwarded to the client, the client would be receiving a packet from someone it didn't request one from, and would simply drop it. Instead, the ADC, remembering the connection, rewrites the packet so that the source IP is that of the virtual server, thus solving this problem.

The Application Delivery Decision

So, how does the ADC decide which host to send the connection to? And what happens if the selected host isn't working?

Let's discuss the second question first. What happens if the selected host isn't working? The simple answer is that it doesn't respond to the client request and the connection attempt eventually times out and fails. This is obviously not a preferred circumstance, as it doesn't ensure high availability. That's why most ADC technology includes some level of health monitoring that determines whether a host is actually available before attempting to send connections to it.

There are multiple levels of health monitoring, each with increasing granularity and focus. A basic monitor would simply PING the host itself. If the host does not respond to PING, it is a good assumption that any services defined on the host are probably down and should be removed from the cluster of available services. Unfortunately, even if the host responds to PING, it doesn't necessarily mean the service itself is working. Therefore most devices can do "service PINGs" of some kind, ranging from simple TCP connections all the way to interacting with the application via a scripted or intelligent interaction. These higher-level health monitors not only provide greater confidence in the availability of the actual services (as opposed to the host), but they also allow the load balancer to differentiate between multiple services on a single host. The ADC understands that while one service might be unavailable, other services on the same host might be working just fine and should still be considered as valid destinations for user traffic.

This brings us back to the first question: How does the ADC decide which host to send a connection request to? Each virtual server has a specific dedicated cluster of services (listing the hosts that offer that service) which makes up the list of possibilities. Additionally, the health monitoring modifies that list to make a list of "currently available" hosts that provide the indicated service. It is this modified list from which the ADC chooses the host that will receive a new connection. Deciding the exact host depends on the ADC algorithm associated with that particular cluster. The most common is simple round-robin where the ADC simply goes down the list starting at the top and allocates each new connection to the next host; when it reaches the bottom of the list, it simply starts again at the top. While this is simple and very predictable, it assumes that all connections will have a similar load and duration on the back-end host, which is not always true. More advanced algorithms use things like current-connection counts, host utilization, and even real-world response times for existing traffic to the host in order to pick the most appropriate host from the available cluster services.

Sufficiently advanced application delivery systems will also be able to synthesize health monitoring information with load balancing algorithms to include an understanding of service dependency. This is the case when a single host has multiple services, all of which are necessary to complete the user's request. A common example would be in e-commerce situations where a single host will provide both standard HTTP services (port 80) as well as HTTPS (SSL/TLS at port 443) and any other potential service ports that need to be allowed. In many of these circumstances, you don't want a user going to a host that has one service operational, but not the other. In other words, if the HTTPS services should fail on a host, you also want that host's HTTP service to be taken out of the cluster list of available services. This functionality is increasingly important as HTTP-like services become more differentiated with this things like XML and scripting.

To Load Balance or Not to Load Balance?

Load balancing in regards to picking an available service when a client initiates a transaction request is only half of the solution. Once the connection is established, the ADC must keep track of whether the following traffic from that user should be load balanced. There are generally two specific issues with handling follow-on traffic once it has been load balanced: connection maintenance and persistence.

Connection maintenance

If the user is trying to utilize a long-lived TCP connection (telnet, FTP, and more) that doesn't immediately close, the ADC must ensure that multiple data packets carried across that connection do not get load balanced to other available service hosts. This is connection maintenance and requires two key capabilities: 1) the ability to keep track of open connections and the host service they belong to; and 2) the ability to continue to monitor that connection so the connection table can be updated when the connection closes. This is rather standard fare for most ADCs.

Persistence

Increasingly more common, however, is when the client uses multiple short-lived TCP connections (for example, HTTP) to accomplish a single task. In some cases, like standard web browsing, it doesn't matter and each new request can go to any of the back-end service hosts; however, there are many more instances (XML, JavaScript, e-commerce "shopping cart," HTTPS, and so on) where it is extremely important that multiple connections from the same user go to the same back-end service host and not be load balanced. This concept is called persistence, or server affinity. There are multiple ways to address this depending on the protocol and the desired results. For example, in modern HTTP transactions, the server can specify a "keep-alive" connection, which turns those multiple short-lived connections into a single long-lived connection that can be handled just like the other long-lived connections. However, this provides little relief. Even worse, as the use of web and mobile services increases, keeping all of these connections open longer than necessary would strain the resources of the entire system. In these cases, most ADCs provide other mechanisms for creating artificial server affinity.

One of the most basic forms of persistence is source-address affinity. Source address affinity persistence directs session requests to the same server based solely on the source IP address of a packet. This involves simply recording the source IP address of incoming requests and the service host they were load balanced to, and making all future transaction go to the same host. This is also an easy way to deal with application dependency as it can be applied across all virtual servers and all services. In practice however, the wide-spread use of proxy servers on the Internet and internally in enterprise networks renders this form of persistence almost useless; in theory it works, but proxy-servers inherently hide many users behind a single IP address resulting in none of those users being load balanced after the first user's request—essentially nullifying the ADC capability. Today, the intelligence of ADCs allows organizations to actually open up the data packets and create persistence tables for virtually anything within it. This enables them to use much more unique and identifiable information, such as user name, to maintain persistence. However, organizations one must take care to ensure that this identifiable client information will be present in every request made, as any packets without it will not be persisted and will be load balanced again, most likely breaking the application.

Final Thoughts

It is important to understand that basic load balancing technology, while still in use, is now only considered a feature of Application Delivery Controllers. ADCs evolved from the first load balancers through the service virtualization process and today with software only virtual editions. They can not only improve availability, but also affect the security and performance of the application services being requested.

Today, most organizations realize that simply being able to reach an application doesn't make it usable; and unusable applications mean wasted time and money for the enterprise deploying them. ADCs enable organizations to consolidate network-based services like SSL/TLS offload, caching, compression, rate-shaping, intrusion detection, application firewalls, and even remote access into a single strategic point that can be shared and reused across all application services and all hosts to create a virtualized Application Delivery Network. Basic load balancing is the foundation without which none of the enhanced functionality of today's ADCs would be possible.

And if you missed What is an ADC Part 1, you can find it here.

ps

Next Steps

Now that you’ve gotten this far, would you like to dig deeper or learn more about how application delivery works? Cool, then check out these resources:

 




What is an Application Delivery Controller - Part 1

Posted in f5, big-ip, adc, application delivery, devcentral by psilva on January 24th, 2017

devcentral_basics_article_banner.png

A Little History

Application Delivery got its start in the form of network-based load balancing hardware. It is the essential foundation on which Application Delivery Controllers (ADCs) operate. The second iteration of purpose-built load balancing (following application-based proprietary systems) materialized in the form of network-based appliances. These are the true founding fathers of today's ADCs. Because these devices were application-neutral and resided outside of the application servers themselves, they could load balance using straightforward network techniques. In essence, these devices would present a "virtual server" address to the outside world, and when users attempted to connect, they would forward the connection to the most appropriate real server doing bi-directional network address translation (NAT).

network_lb_1_.png

Figure 1: Network-based load balancing appliances.

With the advent of virtualization and cloud computing, the third iteration of ADCs arrived as software delivered virtual editions intended to run on hypervisors. Virtual editions of application delivery services have the same breadth of features as those that run on purpose-built hardware and remove much of the complexity from moving application services between virtual, cloud, and hybrid environments. They allow organizations to quickly and easily spin-up application services in private or public cloud environments.

Basic Application Delivery Terminology

It would certainly help if everyone used the same lexicon; unfortunately, every vendor of load balancing devices (and, in turn, ADCs) seems to use different terminology. With a little explanation, however, the confusion surrounding this issue can easily be alleviated.

Node, Host, Member, and Server

Most ADCs have the concept of a node, host, member, or server; some have all four, but they mean different things. There are two basic concepts that they all try to express. One concept—usually called a node or server—is the idea of the physical or virtual server itself that will receive traffic from the ADC. This is synonymous with the IP address of the physical server and, in the absence of a ADC, would be the IP address that the server name (for example, www.example.com) would resolve to. We will refer to this concept as the host.

The second concept is a member (sometimes, unfortunately, also called a node by some manufacturers). A member is usually a little more defined than a server/node in that it includes the TCP port of the actual application that will be receiving traffic. For instance, a server named www.example.com may resolve to an address of 172.16.1.10, which represents the server/node, and may have an application (a web server) running on TCP port 80, making the member address 172.16.1.10:80. Simply put, the member includes the definition of the application port as well as the IP address of the physical server.  We will refer to this as the service.

Why all the complication? Because the distinction between a physical server and the application services running on it allows the ADC to individually interact with the applications rather than the underlying hardware or hypervisor. A host (172.16.1.10) may have more than one service available (HTTP, FTP, DNS, and so on). By defining each application uniquely (172.16.1.10:80, 172.16.1.10:21, and 172.16.1.10:53), the ADC can apply unique load balancing and health monitoring based on the services instead of the host. However, there are still times when being able to interact with the host (like low-level health monitoring or when taking a server offline for maintenance) is extremely convenient.

Most load balancing-based technology uses some concept to represent the host, or physical server, and another to represent the services available on it— in this case, simply host and services.

Pool, Cluster, and Farm

Load balancing allows organizations to distribute inbound application traffic across multiple back-end destinations, including cloud deployments. It is therefore a necessity to have the concept of a collection of back-end destinations. Clusters, as we will refer to them (also known as pools or farms) are collections of similar services available on any number of hosts. For instance, all services that offer the company web page would be collected into a cluster called "company web page" and all services that offer e-commerce services would be collected into a cluster called "e-commerce."

The key element here is that all systems have a collective object that refers to "all similar services" and makes it easier to work with them as a single unit. This collective object—a cluster—is almost always made up of services, not hosts.

Virtual Server

Although not always the case, today the term virtual server means a server hosting virtual machines. It is important to note that like the definition of services, virtual server usually includes the application port was well as the IP address. The term "virtual service" would be more in keeping with the IP:Port convention; but because most vendors, ADC and Cloud alike use virtual server, this article uses virtual server as well.

Putting It All Together

Putting all of these concepts together makes up the basic steps in load balancing. The ADC presents virtual servers to the outside world. Each virtual server points to a cluster of services that reside on one or more physical hosts.

 

 

adc_parts_1_.png

Figure 2: Application Delivery comprises four basic concepts—virtual servers, clusters, services, and hosts.

While the diagram above may not be representative of a real-world deployment, it does provide the elemental structure for continuing a discussion about application delivery basics.

Next Steps

Read What is Load Balancing? if you haven't already and check out ADC Part II coming January 26!

ps

 





« Older episodes · Newer episodes »