Skip to content

Commit

Permalink
Merge pull request #6812 from wildmanonline/rc-v1.297.0
Browse files Browse the repository at this point in the history
[Release Candidate] v1.297.0
  • Loading branch information
wildmanonline authored Jan 16, 2024
2 parents 863f3aa + f7ff898 commit 70687a2
Show file tree
Hide file tree
Showing 11 changed files with 238 additions and 10 deletions.
1 change: 1 addition & 0 deletions ci/vale/dictionary.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1370,6 +1370,7 @@ microsystems
microweb
Microweber
middlebox
middleboxes
middleware
mimikatz
minecraft
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ This guide walks you through how to install a new version of cloud-init on distr

The first step is to create a fresh Compute Instance running the distribution of your choice. If the selected distribution is already marked as cloud-init compatible, you do not need to follow the steps in this guide. If the distribution is not cloud-init compatible, continue with this guide to create a cloud-init compatible image for this distribution. For details on Metadata/cloud-init compatibility, review [Overview of the Metadata Service > Availability](/docs/products/compute/compute-instances/guides/metadata/#availability).

This instance forms the basis for a cloud-init deployment template. See our [Getting Started with Linode](/docs/guides/getting-started/) and [Creating a Compute Instance](/docs/guides/creating-a-compute-instance/) guides. The instructions in this guide cover Debian, Ubuntu, and RHEL-based systems (CentOS, Fedora, AlmaLinux, Rocky Linux, etc.). The steps have not been verified with other distributions but may be adaptable with some modifications.
This instance forms the basis for a cloud-init deployment template. See our [Getting Started with Linode](/docs/products/platform/get-started/) and [Creating a Compute Instance](/docs/products/compute/compute-instances/guides/create/) guides. The instructions in this guide cover Debian, Ubuntu, and RHEL-based systems (CentOS, Fedora, AlmaLinux, Rocky Linux, etc.). The steps have not been verified with other distributions but may be adaptable with some modifications.

## Install Cloud-Init

Expand Down Expand Up @@ -152,7 +152,7 @@ What follows is a summary of steps you can use to create a base image from the i
With a base cloud-init image ready, you can deploy a new instance of the Metadata service and cloud-init user data whenever you need. Refer to our guide on how to [Deploy an Image to a New Compute Instance](/docs/products/tools/images/guides/deploy-image-to-new-linode/) for image deployment. Refer to our guide on how to [Use Cloud-Init to Automatically Configure and Secure Your Servers](/docs/guides/configure-and-secure-servers-with-cloud-init/) for more on adding user data to new instances.
The steps that follow walk you through a simple new deployment from a base cloud-init image. This includes a simple cloud-init user data script modeled on our [Setting Up and Securing a Compute Instance](/docs/guides/set-up-and-secure/) guide.
The steps that follow walk you through a simple new deployment from a base cloud-init image. This includes a simple cloud-init user data script modeled on our [Setting Up and Securing a Compute Instance](/docs/products/compute/compute-instances/guides/set-up-and-secure/) guide.
{{< note >}}
Newly deployed Compute Instances do not have network access during boot. This prevents cloud-init from properly running. The last several steps below address this, restarting the cloud-init process after the initial boot.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -51,7 +51,7 @@ Update package lists and install all updates:

### Back Up Your Linode

It's a good idea to back up your Linode before performing a major upgrade. That way, you can restore from backup if anything goes wrong during the upgrade process. If you subscribe to the [Linode Backup Service](/docs/products/storage/backups/), we recommend that you [take a manual snapshot](/docs/products/storage/backups/#take-a-manual-snapshot) before upgrading to Ubuntu 20.04 LTS. If you use another backup service or application, we recommend that you make a manual backup before continuing.
It's a good idea to back up your Linode before performing a major upgrade. That way, you can restore from backup if anything goes wrong during the upgrade process. If you subscribe to the [Linode Backup Service](/docs/products/storage/backups/), we recommend that you [take a manual snapshot](/docs/products/storage/backups/guides/take-a-snapshot/) before upgrading to Ubuntu 20.04 LTS. If you use another backup service or application, we recommend that you make a manual backup before continuing.

### Check Your Kernel

Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
slug: application-http-vs-network-tcp-load-balancers
title: "Application (HTTP) vs Network (TCP) Load Balancers"
description: 'Explore the differences between application-layer (HTTP) and transport-layer (TCP) load balancers. Learn how each functions, their key features, and when to choose one over the other.'
keywords: ['load balancing protocols','http load balancing','tcp load balancing','application-layer load balancing','transport-layer load balancing']
license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)'
authors: ["Linode"]
published: 2024-01-16
modified_by:
name: Linode
---

Load balancing is the process of distributing client requests across multiple servers. Originally, load balancers were dedicated hardware appliances connected to physical servers in data centers. Today, software products such as [Akamai NodeBalancers](/docs/products/networking/nodebalancers/) perform the same role with cloud-based servers.

Whether hardware or software, the concept is the same. Load balancers act as a reverse proxy for client requests, parceling out requests across servers to avoid resource exhaustion. Load balancers take many forms and offer [many features](/docs/guides/load-balancing-fundamentals/). However, they all route client requests to back-end servers using either application-layer (HTTP/S) or transport-layer (TCP) criteria. Distributing the load in this way can help ensure the best performance, availability, scalability, and security. With Akamai NodeBalancers, it’s simple to take advantage of the features available at either layer.

Transmission Control Protocol (TCP) resides at the transport layer (L4) in the [seven-layer OSI model](/docs/guides/introduction-to-osi-networking-model/). Meanwhile, Hypertext Transport Protocol (HTTP) and secure HTTP (HTTPS) reside at the higher application layer (L7). Both TCP and HTTP have their place when it comes to load balancing.

If your application is a website or uses a web-accessible front end, it can be preferable to use application-layer (HTTP) load balancing. Using an HTTP load balancer allows you to view the contents of a client's HTTP request *before* you determine which back-end machine it is routed to. This enables you to make use of application-layer data in HTTP headers. Depending on the features of the load balancer, it may be able to read these headers to dynamically route the traffic (such as routing requests for `example.com/app` to a different set of back-ends than `example.com/blog`).

There are many applications that do not use HTTP traffic, such as email, instant messaging, and SQL databases. For these, TCP load balancing is the right choice. In addition to working with a wider range of applications, it also typically has faster performance as it is not terminating HTTP requests and analyzing those requests.

In this guide, learn what benefits each protocol offers, and which makes the most sense for common use cases.

## HTTP (Application/L7) Load Balancing Overview

With HTTP/S load balancing, the [NodeBalancer](/docs/products/networking/nodebalancers/guides/configure/) examines each packet's application layer HTTP headers to decide how to route client requests to back-end servers. Besides improving application performance, availability, and horizontal scalability for Web applications, HTTP load balancing also affords web-specific benefits not available from TCP load balancing.

### HTTP Load Balancer Benefits

HTTP load balancing works with unencrypted Web traffic, but also in HTTPS mode using Transport Layer Security (TLS). With TLS, the load balancer hosts the certificate and private key for a given web site. It then decrypts client requests and passes them along to back-end servers.

Some load balancers such as HAProxy can even make URL-based routing decisions. This can be helpful if your cloud infrastructure is set up for some servers to handle video or image requests, while others return text objects.

### HTTP Load Balancer Use Cases

Web-based load balancing makes sense for virtually any application that runs over HTTP/S. This is true whether it’s a static Web site or a complex multi-tier application that uses a Web front end.

E-commerce sites require an item directory and a shopping cart, along with financial and shipping functions to complete transactions. In this case, the application load balancer sends browsing requests that contain product images or video to servers that don’t maintain open connections. Meanwhile, shopping cart and checkout requests are sent to those servers who retain client connections and cart contents.

## TCP (Transport/L4) Load Balancing Overview

TCP load balancing algorithms use a client request’s destination TCP port number to make forwarding decisions. Optionally, a load balancer may compute a hash of TCP source and destination port numbers to ensure session persistence. This ensures that the same client always reaches the same server. This is useful for applications or services that employ unique tokens for each session.

### TCP Load Balancing Benefits

TCP load balancing is relatively simple to implement and operate. It’s useful for applications that run over TCP but not HTTP/S. It does work with HTTP/S traffic by pointing to port `80` or `443`, but without any HTTP-specific capabilities.

The level of a load balancer refers to how far up the network stack a communication has to travel before it reaches its destination. Since TCP operates in the OSI model's fourth level, an application load balancer route based on TCP has less latency. This is because the communication doesn’t have to go all the way up and down the network stack.

### TCP Load Balancing Use Cases

Websites that require extreme performance and high availability to handle latency-sensitive applications, spike-heavy workloads, and high-volume inbound TCP requests benefit from TCP load balancing. TCP load balancing is also a good option when you need to support a static or elastic IP address. Another appropriate use case is if you are using container services and want to support more than one port on a compute instance.

## Conclusion

Load balancing is one of the best and easiest ways to boost the performance, availability, and scalability of your applications. With just a few clicks, you can set up an Akamai NodeBalancer to use Web- or TCP-specific features to minimize downtime and maximize performance.
Loading

0 comments on commit 70687a2

Please sign in to comment.