From e499bf4158e762779ab65a1cabee89e63dbd76da Mon Sep 17 00:00:00 2001 From: Adam Overa Date: Wed, 18 Sep 2024 19:03:23 -0400 Subject: [PATCH 1/6] Configure Failover for HAProxy on Akamai --- .../index.md | 147 ++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md diff --git a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md new file mode 100644 index 00000000000..a8479f77cda --- /dev/null +++ b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md @@ -0,0 +1,147 @@ +--- +slug: configure-failover-for-haproxy-on-akamai +title: "Configure Failover for Haproxy on Akamai" +description: "Two to three sentences describing your guide." +og_description: "Optional two to three sentences describing your guide when shared on social media. If omitted, the `description` parameter is used within social links." +authors: ["Tom Henderson"] +contributors: ["Tom Henderson"] +published: 2024-09-18 +keywords: ['list','of','keywords','and key phrases'] +license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' +external_resources: +- '[Link Title 1](http://www.example.com)' +- '[Link Title 2](http://www.example.net)' +--- + +HAProxy is an HTTP or TCP gateway server instance application that plays a key role as a reverse proxy between a public-facing IP address and servers behind them. The frontend input and backend traffic configuration rules manage traffic, repair http requests, and serve as a network load balancer. + +Services provided by HAProxy become a single point of failure, fully interrupting client connections with backend services. Rapid failover of HAProxy to a HAProxy backup instance re-establishes communications with clients. + +As an application, the FOSS version of HAProxy does not maintain failover instances where the failover server preserves the state of the failed HAProxy instance. However, this means that HAProxy newly active backup hosts relearn frontend-backend routing freshly upon assuming the role. The enterprise edition of HAProxy has allowance for state-save and restore, and other mechanisms that restore a failover with configuration data. + +## Initial Setup: Deploy HAProxy and Backend Instances + +This guide expands on the platform built in the Getting Started With HAProxy Load Balancing Guide so you should begin by building your platform as instructed in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks). In this guide, you use the FOSS version of HAProxy to create and demonstrate basic HAProxy host failover pairs. + +## Deploy A Second HAProxy Instance + +Test a primary/failover pair by generating a second instance. The second HAProxy Instance is based on the same OS compute instance in the same datacenter as the HAProxy server instance generated in Part One. This instance is synchronized with the configuration used in the primary/initial server. + +To mate the servers together, the pair receives a uniting IP address. Choose a Shared IP address in the data center where the HAProxy compute instances are located. Use a Shared IP address between both the primary and backup instance to create a private network. Your final step creating the private network uses a new network interface device in the primary and backup hosts. + +Install the software link for the private network, FRRouting. The FRRouting application connects the newly created network interfaces, and is configured for private connection between the initial primary server and the backup server built in this guide. The frr application configuration specifies the Border Gateway Protocol (BGP) protocol, establishing the roles of primary and backup server. + +The primary and backup server are two separate compute instances in this configuration. The networking interfaces are joined together to one IP address via IP Sharing. The protocol used to join them is BGP. The [FRRouting configuration establishes ROLES of primary and backup](https://www.linode.com/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr) in the HAProxy server instances. + +Using the BGP protocol and configuration information, the backup server recognizes failure in the primary, and allows the backup HAProxy server to accept traffic. The backup must pick up the same logic that the primary server does through its configuration. This requires that you synchronize the HAProxy configuration file from the primary to the backup server. Any changes made to the primary are subsequently pushed to the backup instance, replacing the backup instance /etc/haproxy/haproxy.conf file, as well as after each change in the HAProxy configuration. + +## Configure IP Sharing + +This guide uses Akamai’s IP Host Address Sharing. The TCP/IP protocol is built on unique IP/MAC address pairs, and IP Sharing is a method to permit two physical IP/MAC pairs in different host instances to share the same IP address where one host is active, and the other host is passive. IP Sharing is available in most Linode data centers. You need specific information for the datacenter you're using prior to undertaking failover testing, because both hosts must be instances within the same datacenter when using IP Sharing. + +Instructions for building either an Ubuntu 22.04 LTS server, a CentOS Stream 9, or OpenSUSE Leap server are shown in Part One. This demonstration uses a second server, that you build identically as you did the original HAProxy server compute instance, which you need to build within the same datacenter location. This instance shows the IP Sharing and failover settings. Create and deploy this instance, then configure [IP Sharing for the original primary host, and the newly created backup HAProxy host](https://www.linode.com/docs/products/compute/compute-instances/guides/manage-ip-addresses/#configuring-ip-sharing). + +The primary and backup HAProxy servers interact on their private network using the BGP protocol chosen in the FRRouting configuration file. The backup takes over from the primary using a "ping-like" test of the primary server, after recognizing failure which is when failover begins using the HAProxy reverse proxy service. + +## Configure Failover + +Use the FRRouting software daemon, and the BGP protocol to connect the HAProxy primary and backup hosts to each other. + +### Install and Configure FRRouting + +FRRouting is installed on the primary and backup server. Install IP Sharing onto both HAProxy server compute instances. Install the FRRouting application into each host, using the LISSH terminal. + +### Ubuntu 22.04 LTS FRRouting Installation + +Login to each HAProxy host, primary and backup, using the LISH console. Update the base software, then install frr: + +code: apt update && apt upgrade -y +code: apt install frr frrtools frr-pythontools + +Start the frr app after configuration: + +code: systemctl start frr + +then make frr survive restart: + +code systemctl enable frr + +### Install FRRouting on CentOS Stream 9 + +Login to each HAProxy host, primary and backup, using the lish console. Install the frr software using dnf: + +code: sudo dnf install frr frr-pythontools + +Start the frr app after configuration: + +code: systemctl start frr + +Then make frr survive restart: + +code systemctl enable frr + +### Installing FRRouting on OpenSUSE Leap + +For openSUSE Leap as an HAProxy instance, login using the LISH console for each instance, primary and backup. Install the frr software using zypper: + +code: sudo zypper frr + +Then make frr survive restart: + +code systemctl enable frr + +The FRRouting requires a [unique configuration in the primary and failover/backup server instance](https://www.linode.com/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr). The frr daemon checks the servers in its configuration list and begins to accept incoming traffic when the primary server fails. Using the BGP protocol, the configuration shown monitors the primary server for health. It does not failback to the primary server, once the primary server is restored to duty, in this test configuration. Pay special attention to the daemons file detail in /etc/frr/daemons and the frr configuration in the /etc/frr/frr.conf files. + +Restart the frr daemon after creating and editing these files: + +code: sudo systemctl restart frr + +## Ensure HAProxy Configuration Between Primary and Backup Servers + +The backup HAProxy server requires a correct HAProxy configuration file of the primary server. To accomplish this, login to the server designated as backup and copy the HAProxy configuration file from the primary server to the backup. After a primary failure, copy this file back to the primary server that is promoted to primary after the failure. From the backup server, login to it via the LISH console then copy the configuration file: + +code: scp @:/etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg + +Give the root password of the primary server, or substitute a sudo user and password for the scp copy. Verify that the configuration file is correct. + +## Configure The Secondary HAProxy Instance with Shared IP Address + +After you build the additional HAProxy server instance, [add an additional network interface](https://www.linode.com/docs/products/compute/compute-instances/guides/failover/#add-the-shared-ip-to-the-networking-configuration). This joins the two servers under one IP address, but only one HAProxy instance is active at once. + +Restart both host’s network services to recognize the shared IP address setting. + +code: systemctl restart networkd + +After the restart, the FRrouting daemon in the backup server starts to interrogate the primary host for a correct BGP routing path. Once the path fails to respond to the backup server, the backup server must accept traffic, and route the traffic as a gateway according to the copy of the HAproxy configuration rules from the primary server. + +During the initial startup of the backup server, latency occurs as pairs from frontend access from clients arrive at backend server compute instances. In a high-traffic network, the latency is noticeable. You may need to refresh user sessions, and some may encounter TCP or HTTP error messages. + +Programatically, client-side code should provide instructions in a browser or other client app access to trap the latency message and perform retries until the failover cycle normalizes traffic. + +## Test Failover + +Use the test setup for TCP health described in Part One. This consists of browser access to the three backend servers, backend1, backend2, and backend3, through the IP address set for the IP address represented by the IP Sharing address. + +To test failover, test initial access to the three servers with your browser to verify the HAProxy primary server is serving pages according to the correct configuration. + +Using the management console, power down the primary HAProxy server instance. + +As the primary server instance becomes unavailable, continue testing by refreshing the browser pages associated with your prior test access. Within a few seconds, the pages should re-appear, now proxied through the backup server. The test is complete. + +### Troubleshooting Test Failures + +If the failover test fails and browser refreshes do not restore page access from the backup server after several seconds, troubleshoot the failover logic: + +- Verify the IP Sharing steps were followed. +- Verify the backup server can be reached using the ICMP Ping command; if not, IP Sharing isn’t working. +- Check that the Roles section of the FRrouting frr.config was configured according to directions. +- Check that the backup server /etc/haproxy/haproxy.cfg file was correctly copied from the primary server. +- Using a browser access, point the browser at the direct IP address of the backend server backup1; if the server responds, the failover server configuration is incorrectly installed. + +Latency in the failover from primary to backup should never take more than a few seconds. The FRRouting daemon and configuration can use numerous settings to optimize detection and failover speed. + +## Conclusion + +This series of HAProxy guides show the basic TCP and HTTP backend network load balancing and failover mechanisms available. These examples only skim the surface of a sophisticated number of options that you can deploy. They work for the FOSS version, and more extensive and expansive options are available in the HAProxy non-FOSS Enterprise Edition. + +HAProxy is extremely popular for backend load balancing and reverse proxy services, including its ability to serve as an SSL/TLS processor. Akamai IP Sharing services glue high-traffic instances together, using FOSS tools such as FRRouting and HAProxy for higher reliability. \ No newline at end of file From 38612a24ff2d9f84c9cbb0aed06393e4a7879661 Mon Sep 17 00:00:00 2001 From: Adam Overa Date: Wed, 30 Oct 2024 17:29:59 -0400 Subject: [PATCH 2/6] Tech Edit 1 --- .../index.md | 90 ++++++++++++------- 1 file changed, 56 insertions(+), 34 deletions(-) diff --git a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md index a8479f77cda..4a9b1ca6cfc 100644 --- a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md +++ b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md @@ -13,7 +13,7 @@ external_resources: - '[Link Title 2](http://www.example.net)' --- -HAProxy is an HTTP or TCP gateway server instance application that plays a key role as a reverse proxy between a public-facing IP address and servers behind them. The frontend input and backend traffic configuration rules manage traffic, repair http requests, and serve as a network load balancer. +HAProxy is an HTTP or TCP gateway server instance application that plays a key role as a reverse proxy between a public-facing IP address and servers behind them. The frontend input and backend traffic configuration rules manage traffic, repair HTTP requests, and serve as a network load balancer. Services provided by HAProxy become a single point of failure, fully interrupting client connections with backend services. Rapid failover of HAProxy to a HAProxy backup instance re-establishes communications with clients. @@ -29,17 +29,17 @@ Test a primary/failover pair by generating a second instance. The second HAProxy To mate the servers together, the pair receives a uniting IP address. Choose a Shared IP address in the data center where the HAProxy compute instances are located. Use a Shared IP address between both the primary and backup instance to create a private network. Your final step creating the private network uses a new network interface device in the primary and backup hosts. -Install the software link for the private network, FRRouting. The FRRouting application connects the newly created network interfaces, and is configured for private connection between the initial primary server and the backup server built in this guide. The frr application configuration specifies the Border Gateway Protocol (BGP) protocol, establishing the roles of primary and backup server. +Install the software link for the private network, FRRouting. The FRRouting application connects the newly created network interfaces, and is configured for private connection between the initial primary server and the backup server built in this guide. The `frr` application configuration specifies the Border Gateway Protocol (BGP) protocol, establishing the roles of primary and backup server. The primary and backup server are two separate compute instances in this configuration. The networking interfaces are joined together to one IP address via IP Sharing. The protocol used to join them is BGP. The [FRRouting configuration establishes ROLES of primary and backup](https://www.linode.com/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr) in the HAProxy server instances. -Using the BGP protocol and configuration information, the backup server recognizes failure in the primary, and allows the backup HAProxy server to accept traffic. The backup must pick up the same logic that the primary server does through its configuration. This requires that you synchronize the HAProxy configuration file from the primary to the backup server. Any changes made to the primary are subsequently pushed to the backup instance, replacing the backup instance /etc/haproxy/haproxy.conf file, as well as after each change in the HAProxy configuration. +Using the BGP protocol and configuration information, the backup server recognizes failure in the primary, and allows the backup HAProxy server to accept traffic. The backup must pick up the same logic that the primary server does through its configuration. This requires that you synchronize the HAProxy configuration file from the primary to the backup server. Any changes made to the primary are subsequently pushed to the backup instance, replacing the backup instance `/etc/haproxy/haproxy.conf` file, as well as after each change in the HAProxy configuration. ## Configure IP Sharing This guide uses Akamai’s IP Host Address Sharing. The TCP/IP protocol is built on unique IP/MAC address pairs, and IP Sharing is a method to permit two physical IP/MAC pairs in different host instances to share the same IP address where one host is active, and the other host is passive. IP Sharing is available in most Linode data centers. You need specific information for the datacenter you're using prior to undertaking failover testing, because both hosts must be instances within the same datacenter when using IP Sharing. -Instructions for building either an Ubuntu 22.04 LTS server, a CentOS Stream 9, or OpenSUSE Leap server are shown in Part One. This demonstration uses a second server, that you build identically as you did the original HAProxy server compute instance, which you need to build within the same datacenter location. This instance shows the IP Sharing and failover settings. Create and deploy this instance, then configure [IP Sharing for the original primary host, and the newly created backup HAProxy host](https://www.linode.com/docs/products/compute/compute-instances/guides/manage-ip-addresses/#configuring-ip-sharing). +Instructions for building either an Ubuntu 22.04 LTS server, a CentOS Stream 9, or openSUSE Leap server are shown in Part One. This demonstration uses a second server, that you build identically as you did the original HAProxy server compute instance, which you need to build within the same datacenter location. This instance shows the IP Sharing and failover settings. Create and deploy this instance, then configure [IP Sharing for the original primary host, and the newly created backup HAProxy host](https://www.linode.com/docs/products/compute/compute-instances/guides/manage-ip-addresses/#configuring-ip-sharing). The primary and backup HAProxy servers interact on their private network using the BGP protocol chosen in the FRRouting configuration file. The backup takes over from the primary using a "ping-like" test of the primary server, after recognizing failure which is when failover begins using the HAProxy reverse proxy service. @@ -53,56 +53,76 @@ FRRouting is installed on the primary and backup server. Install IP Sharing onto ### Ubuntu 22.04 LTS FRRouting Installation -Login to each HAProxy host, primary and backup, using the LISH console. Update the base software, then install frr: +Login to each HAProxy host, primary and backup, using the LISH console. Update the base software, then install `frr`: -code: apt update && apt upgrade -y -code: apt install frr frrtools frr-pythontools +```command +apt update && apt upgrade -y +apt install frr frrtools frr-pythontools +``` -Start the frr app after configuration: +Start the `frr` app after configuration: -code: systemctl start frr +```command +systemctl start frr +``` -then make frr survive restart: +Make `frr` survive restart: -code systemctl enable frr +```command +systemctl enable frr +``` ### Install FRRouting on CentOS Stream 9 -Login to each HAProxy host, primary and backup, using the lish console. Install the frr software using dnf: +Login to each HAProxy host, primary and backup, using the LISH console. Install the `frr` software using `dnf`: -code: sudo dnf install frr frr-pythontools +```cmmand +sudo dnf install frr frr-pythontools +``` -Start the frr app after configuration: +Start the `frr` app after configuration: -code: systemctl start frr +```command +systemctl start frr +``` -Then make frr survive restart: +Then make `frr` survive restart: -code systemctl enable frr +```command +systemctl enable frr +``` -### Installing FRRouting on OpenSUSE Leap +### Installing FRRouting on openSUSE Leap -For openSUSE Leap as an HAProxy instance, login using the LISH console for each instance, primary and backup. Install the frr software using zypper: +For openSUSE Leap as an HAProxy instance, login using the LISH console for each instance, primary and backup. Install the `frr` software using `zypper`: -code: sudo zypper frr +```command +sudo zypper frr +``` -Then make frr survive restart: +Then make `frr` survive restart: +```command code systemctl enable frr +``` -The FRRouting requires a [unique configuration in the primary and failover/backup server instance](https://www.linode.com/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr). The frr daemon checks the servers in its configuration list and begins to accept incoming traffic when the primary server fails. Using the BGP protocol, the configuration shown monitors the primary server for health. It does not failback to the primary server, once the primary server is restored to duty, in this test configuration. Pay special attention to the daemons file detail in /etc/frr/daemons and the frr configuration in the /etc/frr/frr.conf files. +The FRRouting requires a [unique configuration in the primary and failover/backup server instance](https://www.linode.com/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr). The `frr` daemon checks the servers in its configuration list and begins to accept incoming traffic when the primary server fails. Using the BGP protocol, the configuration shown monitors the primary server for health. It does not failback to the primary server, once the primary server is restored to duty, in this test configuration. Pay special attention to the daemons file detail in `/etc/frr/daemons` and the `frr` configuration in the `/etc/frr/frr.conf` files. -Restart the frr daemon after creating and editing these files: +Restart the `frr` daemon after creating and editing these files: -code: sudo systemctl restart frr +```command +sudo systemctl restart frr +``` ## Ensure HAProxy Configuration Between Primary and Backup Servers -The backup HAProxy server requires a correct HAProxy configuration file of the primary server. To accomplish this, login to the server designated as backup and copy the HAProxy configuration file from the primary server to the backup. After a primary failure, copy this file back to the primary server that is promoted to primary after the failure. From the backup server, login to it via the LISH console then copy the configuration file: +The backup HAProxy server requires a correct HAProxy configuration file of the primary server. To accomplish this, log in to the server designated as backup and copy the HAProxy configuration file from the primary server to the backup. After a primary failure, copy this file back to the primary server that is promoted to primary after the failure. From the backup server, log in to it via the LISH console then copy the configuration file: -code: scp @:/etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg +```command +scp {{< placeholder "USERNAME" >}}@{{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}}:/etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg +``` -Give the root password of the primary server, or substitute a sudo user and password for the scp copy. Verify that the configuration file is correct. +Give the `root` password of the primary server, or substitute a `sudo` user and password for the `scp` copy. Verify that the configuration file is correct. ## Configure The Secondary HAProxy Instance with Shared IP Address @@ -110,17 +130,19 @@ After you build the additional HAProxy server instance, [add an additional netwo Restart both host’s network services to recognize the shared IP address setting. -code: systemctl restart networkd +```command +systemctl restart networkd +``` -After the restart, the FRrouting daemon in the backup server starts to interrogate the primary host for a correct BGP routing path. Once the path fails to respond to the backup server, the backup server must accept traffic, and route the traffic as a gateway according to the copy of the HAproxy configuration rules from the primary server. +After the restart, the FRRouting daemon in the backup server starts to interrogate the primary host for a correct BGP routing path. Once the path fails to respond to the backup server, the backup server must accept traffic, and route the traffic as a gateway according to the copy of the HAproxy configuration rules from the primary server. During the initial startup of the backup server, latency occurs as pairs from frontend access from clients arrive at backend server compute instances. In a high-traffic network, the latency is noticeable. You may need to refresh user sessions, and some may encounter TCP or HTTP error messages. -Programatically, client-side code should provide instructions in a browser or other client app access to trap the latency message and perform retries until the failover cycle normalizes traffic. +Programmatically, client-side code should provide instructions in a browser or other client app access to trap the latency message and perform retries until the failover cycle normalizes traffic. ## Test Failover -Use the test setup for TCP health described in Part One. This consists of browser access to the three backend servers, backend1, backend2, and backend3, through the IP address set for the IP address represented by the IP Sharing address. +Use the test setup for TCP health described in Part One. This consists of browser access to the three backend servers, `backend1`, `backend2`, and `backend3`, through the IP address set for the IP address represented by the IP Sharing address. To test failover, test initial access to the three servers with your browser to verify the HAProxy primary server is serving pages according to the correct configuration. @@ -134,9 +156,9 @@ If the failover test fails and browser refreshes do not restore page access from - Verify the IP Sharing steps were followed. - Verify the backup server can be reached using the ICMP Ping command; if not, IP Sharing isn’t working. -- Check that the Roles section of the FRrouting frr.config was configured according to directions. -- Check that the backup server /etc/haproxy/haproxy.cfg file was correctly copied from the primary server. -- Using a browser access, point the browser at the direct IP address of the backend server backup1; if the server responds, the failover server configuration is incorrectly installed. +- Check that the Roles section of the FRRouting `frr.config` was configured according to directions. +- Check that the backup server `/etc/haproxy/haproxy.cfg` file was correctly copied from the primary server. +- Using a browser access, point the browser at the direct IP address of the backend server `backup1`; if the server responds, the failover server configuration is incorrectly installed. Latency in the failover from primary to backup should never take more than a few seconds. The FRRouting daemon and configuration can use numerous settings to optimize detection and failover speed. From 67045cd9417c89dc1e1ca60ac529a16f3d17e7e8 Mon Sep 17 00:00:00 2001 From: Adam Overa Date: Fri, 1 Nov 2024 19:11:38 -0400 Subject: [PATCH 3/6] Tech Edit 2 --- .../index.md | 167 +++++++++--------- 1 file changed, 83 insertions(+), 84 deletions(-) diff --git a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md index 4a9b1ca6cfc..9e36e6e6066 100644 --- a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md +++ b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md @@ -13,154 +13,153 @@ external_resources: - '[Link Title 2](http://www.example.net)' --- -HAProxy is an HTTP or TCP gateway server instance application that plays a key role as a reverse proxy between a public-facing IP address and servers behind them. The frontend input and backend traffic configuration rules manage traffic, repair HTTP requests, and serve as a network load balancer. +HAProxy is an HTTP and TCP gateway server that functions as a reverse proxy between a public-facing IP address and backend servers. It manages incoming traffic using frontend rules and distributes it across backend servers, providing load balancing and repairing HTTP requests when needed. -Services provided by HAProxy become a single point of failure, fully interrupting client connections with backend services. Rapid failover of HAProxy to a HAProxy backup instance re-establishes communications with clients. +However, HAProxy introduces a single point of failure. If HAProxy goes down, client connections to backend services are interrupted. To mitigate this, rapid failover to a backup HAProxy instance re-establishes communications with clients. -As an application, the FOSS version of HAProxy does not maintain failover instances where the failover server preserves the state of the failed HAProxy instance. However, this means that HAProxy newly active backup hosts relearn frontend-backend routing freshly upon assuming the role. The enterprise edition of HAProxy has allowance for state-save and restore, and other mechanisms that restore a failover with configuration data. +The free and open source (FOSS) version of HAProxy does not preserve the state of the failed instance during failover. As a result, the backup server must relearn frontend-backend routing upon activation. In contrast, the enterprise edition offers state-saving and restoration capabilities, along with other features that restore a failover with configuration data. ## Initial Setup: Deploy HAProxy and Backend Instances -This guide expands on the platform built in the Getting Started With HAProxy Load Balancing Guide so you should begin by building your platform as instructed in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks). In this guide, you use the FOSS version of HAProxy to create and demonstrate basic HAProxy host failover pairs. +This guide builds on the setup covered in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks). Begin by following those instructions to establish your initial platform. This guide uses the FOSS version of HAProxy to create and demonstrate basic HAProxy failover pairs. ## Deploy A Second HAProxy Instance -Test a primary/failover pair by generating a second instance. The second HAProxy Instance is based on the same OS compute instance in the same datacenter as the HAProxy server instance generated in Part One. This instance is synchronized with the configuration used in the primary/initial server. +Deploy a second HAProxy instance located in the same data center and using the same configuration settings as the HAProxy server instance generated in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks). -To mate the servers together, the pair receives a uniting IP address. Choose a Shared IP address in the data center where the HAProxy compute instances are located. Use a Shared IP address between both the primary and backup instance to create a private network. Your final step creating the private network uses a new network interface device in the primary and backup hosts. +Link the two servers by assigning a shared IP address in the same data center where the HAProxy instances are located. This creates a new network interface on each instance and allows them to communicate over a private network. -Install the software link for the private network, FRRouting. The FRRouting application connects the newly created network interfaces, and is configured for private connection between the initial primary server and the backup server built in this guide. The `frr` application configuration specifies the Border Gateway Protocol (BGP) protocol, establishing the roles of primary and backup server. +Install FRRouting (FRR) to connect the newly created network interfaces and establishes a private connection between the instances. Configure FRRouting with the Border Gateway Protocol (BGP) protocol to designate the roles of primary and backup, thus enabling failover. Follow the instructions in our [Configure IP failover over BGP using FRR (advanced)](/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr) guide to designate these roles on your HAProxy instances. -The primary and backup server are two separate compute instances in this configuration. The networking interfaces are joined together to one IP address via IP Sharing. The protocol used to join them is BGP. The [FRRouting configuration establishes ROLES of primary and backup](https://www.linode.com/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr) in the HAProxy server instances. - -Using the BGP protocol and configuration information, the backup server recognizes failure in the primary, and allows the backup HAProxy server to accept traffic. The backup must pick up the same logic that the primary server does through its configuration. This requires that you synchronize the HAProxy configuration file from the primary to the backup server. Any changes made to the primary are subsequently pushed to the backup instance, replacing the backup instance `/etc/haproxy/haproxy.conf` file, as well as after each change in the HAProxy configuration. +In this setup, the primary and backup servers are two separate compute instances joined to a single shared IP address using BGP. If the backup HAProxy server detects failure in the primary it then begins to accept traffic. The HAProxy configuration file (`/etc/haproxy/haproxy.conf`) from the primary instance must be replicated verbatim on the backup server. Any subsequent changes made to the HAProxy configuration file on primary must be replicated on the backup instance. ## Configure IP Sharing -This guide uses Akamai’s IP Host Address Sharing. The TCP/IP protocol is built on unique IP/MAC address pairs, and IP Sharing is a method to permit two physical IP/MAC pairs in different host instances to share the same IP address where one host is active, and the other host is passive. IP Sharing is available in most Linode data centers. You need specific information for the datacenter you're using prior to undertaking failover testing, because both hosts must be instances within the same datacenter when using IP Sharing. +This guide uses Akamai’s IP Host Address Sharing. While the TCP/IP protocol requires unique IP/MAC address pairs, it does support IP sharing within the same data center. IP Sharing allows two distinct IP/MAC pairs on different instances to share the same IP address, with one being active and the other passive. + +The primary and backup HAProxy servers communicate over their private network using the BGP protocol chosen in the FRRouting configuration file. The backup server uses a "ping-like" test on the primary server to detect failure. If the primary server fails, the backup automatically takes over the duties of the primary, allowing HAProxy's reverse proxy service to continue operating. -Instructions for building either an Ubuntu 22.04 LTS server, a CentOS Stream 9, or openSUSE Leap server are shown in Part One. This demonstration uses a second server, that you build identically as you did the original HAProxy server compute instance, which you need to build within the same datacenter location. This instance shows the IP Sharing and failover settings. Create and deploy this instance, then configure [IP Sharing for the original primary host, and the newly created backup HAProxy host](https://www.linode.com/docs/products/compute/compute-instances/guides/manage-ip-addresses/#configuring-ip-sharing). +In order to use IP Sharing, both instances must be within the same datacenter, and IP Sharing is available in most Linode data centers. Follow the instructions in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks) to build an identical instance in the same data center as the original HAProxy server. Once deployed, [configure IP sharing](/docs/products/compute/compute-instances/guides/manage-ip-addresses/#configuring-ip-sharing) for both the original HAProxy server and the newly created instance. -The primary and backup HAProxy servers interact on their private network using the BGP protocol chosen in the FRRouting configuration file. The backup takes over from the primary using a "ping-like" test of the primary server, after recognizing failure which is when failover begins using the HAProxy reverse proxy service. +This additional instance demonstrates both IP Sharing and failover functionality. ## Configure Failover -Use the FRRouting software daemon, and the BGP protocol to connect the HAProxy primary and backup hosts to each other. +To establish failover, use the FRRouting software daemon (`frr`) with the BGP protocol to connect the primary and backup HAProxy instances. -### Install and Configure FRRouting +### Install FRRouting -FRRouting is installed on the primary and backup server. Install IP Sharing onto both HAProxy server compute instances. Install the FRRouting application into each host, using the LISSH terminal. +1. Follow the instructions for your distribution to install FRRouting on both the primary and backup HAProxy servers: -### Ubuntu 22.04 LTS FRRouting Installation + {{< tabs >}} + {{< tab "Ubuntu 24.04 LTS" >}} + Use `apt` to install `frr`: -Login to each HAProxy host, primary and backup, using the LISH console. Update the base software, then install `frr`: + ```command + apt install frr frrtools frr-pythontools + ``` + {{< /tab >}} + {{< tab "CentOS Stream 9" >}} + Use `dnf` to install `frr`: -```command -apt update && apt upgrade -y -apt install frr frrtools frr-pythontools -``` + ```command + sudo dnf install frr frr-pythontools + ``` + {{< /tab >}} + {{< tab "openSUSE Leap 15.6" >}} + Use `zypper` to install `frr`: -Start the `frr` app after configuration: + ```command + sudo zypper frr + ``` + {{< /tab >}} + {{< /tabs >}} -```command -systemctl start frr -``` +1. Use `systemctl` to start `frr`: -Make `frr` survive restart: + ```command + systemctl start frr + ``` -```command -systemctl enable frr -``` - -### Install FRRouting on CentOS Stream 9 - -Login to each HAProxy host, primary and backup, using the LISH console. Install the `frr` software using `dnf`: - -```cmmand -sudo dnf install frr frr-pythontools -``` - -Start the `frr` app after configuration: - -```command -systemctl start frr -``` +1. Enable `frr` to automatically run on startup: -Then make `frr` survive restart: + ```command + systemctl enable frr + ``` -```command -systemctl enable frr -``` +### Configure FRRouting for Failover -### Installing FRRouting on openSUSE Leap +FRRouting requires unique configurations for the primary and backup instances. Follow the **Configure FRR** section of our [Configure IP failover over BGP using FRR (advanced)](/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr) guide to set up the `frr` daemon. The `frr` daemon checks the servers in its configuration list and begins to accept incoming traffic when the primary server fails. The configuration shown monitors the primary server for health using the BGP protocol. -For openSUSE Leap as an HAProxy instance, login using the LISH console for each instance, primary and backup. Install the `frr` software using `zypper`: +After ensuring that the `frr` configuration files `/etc/frr/daemons` and `/etc/frr/frr.conf` files are updated correctly, restart the `frr` daemon: ```command -sudo zypper frr +sudo systemctl restart frr ``` -Then make `frr` survive restart: +{{< note >}} +In this example failover configuration, the primary server does not automatically become active once restored. +{{< /note >}} -```command -code systemctl enable frr -``` +## Sync HAProxy Configuration Between Primary and Backup Servers -The FRRouting requires a [unique configuration in the primary and failover/backup server instance](https://www.linode.com/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr). The `frr` daemon checks the servers in its configuration list and begins to accept incoming traffic when the primary server fails. Using the BGP protocol, the configuration shown monitors the primary server for health. It does not failback to the primary server, once the primary server is restored to duty, in this test configuration. Pay special attention to the daemons file detail in `/etc/frr/daemons` and the `frr` configuration in the `/etc/frr/frr.conf` files. +The backup HAProxy server must have an exact copy of the HAProxy configuration file from the primary server. To ensure this, copy the HAProxy configuration file from the primary server to the backup. -Restart the `frr` daemon after creating and editing these files: +Issue the following `scp` command from the backup server, substituting {{< placeholder "USERNAME" >}} for either `root` or a user with `sudo` access and {{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}} with the actual IP address of the primary HAProxy server: -```command -sudo systemctl restart frr +```command {title="Backup Instance"} +scp {{< placeholder "USERNAME" >}}@{{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}}:/etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg ``` -## Ensure HAProxy Configuration Between Primary and Backup Servers +When prompted, enter the primary server's `root` or `sudo` user password to complete the `scp` command. -The backup HAProxy server requires a correct HAProxy configuration file of the primary server. To accomplish this, log in to the server designated as backup and copy the HAProxy configuration file from the primary server to the backup. After a primary failure, copy this file back to the primary server that is promoted to primary after the failure. From the backup server, log in to it via the LISH console then copy the configuration file: +Before proceeding, verify that the configuration files on both of the servers are identical. -```command -scp {{< placeholder "USERNAME" >}}@{{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}}:/etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg -``` +{{< note >}} +After a failover event, copy this file back to the primary server from the backup server in order to restore it to active duty. +{{< /note >}} -Give the `root` password of the primary server, or substitute a `sudo` user and password for the `scp` copy. Verify that the configuration file is correct. +## Configure the Secondary HAProxy Instance with Shared IP Address -## Configure The Secondary HAProxy Instance with Shared IP Address +Once the additional HAProxy server instance is set up, [add an additional network interface](/docs/products/compute/compute-instances/guides/failover/#add-the-shared-ip-to-the-networking-configuration) to both servers. This allows both HAProxy servers to operate under the same IP address, though only one instance is active at a time. -After you build the additional HAProxy server instance, [add an additional network interface](https://www.linode.com/docs/products/compute/compute-instances/guides/failover/#add-the-shared-ip-to-the-networking-configuration). This joins the two servers under one IP address, but only one HAProxy instance is active at once. +Restart both host’s network services to apply the shared IP address setting: -Restart both host’s network services to recognize the shared IP address setting. - -```command +```command {title="Primary Instance & Backup Instance"} systemctl restart networkd ``` -After the restart, the FRRouting daemon in the backup server starts to interrogate the primary host for a correct BGP routing path. Once the path fails to respond to the backup server, the backup server must accept traffic, and route the traffic as a gateway according to the copy of the HAproxy configuration rules from the primary server. +After restarting, the FRRouting daemon on the backup server begins checking for an active BGP routing path from the primary. If the primary fails to respond, the backup takes over, routing traffic according to the HAproxy configuration rules copied from the primary server. -During the initial startup of the backup server, latency occurs as pairs from frontend access from clients arrive at backend server compute instances. In a high-traffic network, the latency is noticeable. You may need to refresh user sessions, and some may encounter TCP or HTTP error messages. +During the backup server's initial activation, some latency may occur as frontend client requests are directed to backend instances. This latency may be noticeable in high-traffic environments, potentially requiring users to refresh sessions or retry connections. Some users may also encounter temporary TCP or HTTP error messages. -Programmatically, client-side code should provide instructions in a browser or other client app access to trap the latency message and perform retries until the failover cycle normalizes traffic. +{{< note >}} +Client-side applications (such as web browsers or mobile apps) should include code that detects connection errors during failover. When latency or errors occur, the client app can automatically retry the connection until traffic normalizes on the backup server. +{{< /note >}} ## Test Failover -Use the test setup for TCP health described in Part One. This consists of browser access to the three backend servers, `backend1`, `backend2`, and `backend3`, through the IP address set for the IP address represented by the IP Sharing address. +Use the TCP health check setup described in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks) to confirm proper routing to the three backend servers (`backend1`, `backend2`, and `backend3`) through the shared IP address. + +Follow the steps below to test failover: -To test failover, test initial access to the three servers with your browser to verify the HAProxy primary server is serving pages according to the correct configuration. +1. **Verify Initial Access**: Ensure that the primary HAProxy server is serving pages correctly. Navigate to the shared IP address in a web browser and refresh until you can access all three backend servers. -Using the management console, power down the primary HAProxy server instance. +1. **Simulate Primary Failure**: In the Akamai Cloud Manager, power down the primary HAProxy server instance to trigger a failover. -As the primary server instance becomes unavailable, continue testing by refreshing the browser pages associated with your prior test access. Within a few seconds, the pages should re-appear, now proxied through the backup server. The test is complete. +1. **Confirm Failover**: After shutting down the primary server, refresh the browser. Within a few seconds, the pages should re-appear, now routed through the backup server. This indicates that failover is functioning correctly. ### Troubleshooting Test Failures -If the failover test fails and browser refreshes do not restore page access from the backup server after several seconds, troubleshoot the failover logic: +If the failover test fails and refreshing the browser does not restore page access from the backup server after several seconds, follow these troubleshooting steps: -- Verify the IP Sharing steps were followed. -- Verify the backup server can be reached using the ICMP Ping command; if not, IP Sharing isn’t working. -- Check that the Roles section of the FRRouting `frr.config` was configured according to directions. -- Check that the backup server `/etc/haproxy/haproxy.cfg` file was correctly copied from the primary server. -- Using a browser access, point the browser at the direct IP address of the backend server `backup1`; if the server responds, the failover server configuration is incorrectly installed. +- **Verify IP Sharing Configuration**: Ensure that all steps for setting up IP Sharing were followed correctly. +- **Check Network Connectivity**: Use the ICMP Ping command to verify that the backup server is reachable. If it isn't, there may be an issue with IP Sharing. +- **Review FRRouting Configuration**: Check the Roles section of`frr.config` to confirm that it is configured according to the provided directions. +- **Confirm HAProxy Configuration**: Ensure that the backup server's `/etc/haproxy/haproxy.cfg` file was correctly copied from the primary server. +- **Test Backend Server Accessibility**: Use a web browser to directly access a backend server (e.g. `backend1`) by its IP address. If the server responds, the failover server configuration may no be set up correctly. -Latency in the failover from primary to backup should never take more than a few seconds. The FRRouting daemon and configuration can use numerous settings to optimize detection and failover speed. +Latency during the failover from primary to backup should not exceed a few seconds. The FRRouting daemon's configuration offers several settings to optimize detection and failover speed. ## Conclusion From 5f90610fe2ee21b0b624c39d7cafcb0b2d52b6f2 Mon Sep 17 00:00:00 2001 From: Adam Overa Date: Tue, 12 Nov 2024 20:11:09 -0500 Subject: [PATCH 4/6] Tech Edit 3 --- .../index.md | 296 +++++++++++++----- 1 file changed, 212 insertions(+), 84 deletions(-) diff --git a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md index 9e36e6e6066..e7fe9a12622 100644 --- a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md +++ b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md @@ -1,168 +1,296 @@ --- slug: configure-failover-for-haproxy-on-akamai title: "Configure Failover for Haproxy on Akamai" -description: "Two to three sentences describing your guide." -og_description: "Optional two to three sentences describing your guide when shared on social media. If omitted, the `description` parameter is used within social links." +description: "Learn how to set up HAProxy load balancing with IP sharing, FRRouting, and BGP failover in this step-by-step guide." authors: ["Tom Henderson"] contributors: ["Tom Henderson"] published: 2024-09-18 -keywords: ['list','of','keywords','and key phrases'] +keywords: ['haproxy','load balancing','failover','ip sharing','frrouting','bgp','high availability'] license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' -external_resources: -- '[Link Title 1](http://www.example.com)' -- '[Link Title 2](http://www.example.net)' --- -HAProxy is an HTTP and TCP gateway server that functions as a reverse proxy between a public-facing IP address and backend servers. It manages incoming traffic using frontend rules and distributes it across backend servers, providing load balancing and repairing HTTP requests when needed. +[HAProxy](https://www.haproxy.org/) is an HTTP and TCP gateway server that functions as a reverse proxy between a public-facing IP address and backend servers. It manages incoming traffic using frontend rules and distributes it across backend servers, providing load balancing and repairing HTTP requests when needed. -However, HAProxy introduces a single point of failure. If HAProxy goes down, client connections to backend services are interrupted. To mitigate this, rapid failover to a backup HAProxy instance re-establishes communications with clients. +However, HAProxy introduces a single point of failure. If the HAProxy server goes down, client connections to backend services are interrupted. This guide demonstrates how to configure HAProxy with a shared IP address and [FRRouting](https://frrouting.org/) to manage failover. The IP Sharing setup enables two HAProxy instances (primary and backup) to operate under the same IP address. In this setup, one instance is always active and the other stands ready to take over in case of failure. FRRouting, configured with the Border Gateway Protocol (BGP), facilitates this automatic failover, maintaining service continuity. -The free and open source (FOSS) version of HAProxy does not preserve the state of the failed instance during failover. As a result, the backup server must relearn frontend-backend routing upon activation. In contrast, the enterprise edition offers state-saving and restoration capabilities, along with other features that restore a failover with configuration data. +This guide uses the free and open source (FOSS) version of HAProxy to create and demonstrate basic HAProxy failover pairs. With the FOSS version of HAProxy, the backup server doesn’t retain the connection states of the primary instance. Therefore, when the backup becomes active, clients may need to reconnect to re-establish sessions. In contrast, the enterprise edition offers state-saving and restoration capabilities, along with other features that restore a failover with configuration data. -## Initial Setup: Deploy HAProxy and Backend Instances +## Before You Begin -This guide builds on the setup covered in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks). Begin by following those instructions to establish your initial platform. This guide uses the FOSS version of HAProxy to create and demonstrate basic HAProxy failover pairs. +1. Follow the steps in [Getting Started with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks/) to create the example HAProxy instance and WordPress backend servers. -## Deploy A Second HAProxy Instance +1. Deploy a second HAProxy instance in the same data center, configured identically to the first HAProxy server. -Deploy a second HAProxy instance located in the same data center and using the same configuration settings as the HAProxy server instance generated in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks). +1. Disable Network Helper on both HAProxy instances by following the *Individual Compute Instance setting* section of our [Network Helper](https://techdocs.akamai.com/cloud-computing/docs/automatically-configure-networking#individual-compute-instance-setting) guide. -Link the two servers by assigning a shared IP address in the same data center where the HAProxy instances are located. This creates a new network interface on each instance and allows them to communicate over a private network. +1. Add an IP address to the first HAProxy instance by following the steps in the *Adding an IP Address* section of [Managing IP Addresses on a Compute Instance](/docs/products/compute/compute-instances/guides/manage-ip-addresses/#adding-an-ip-address). -Install FRRouting (FRR) to connect the newly created network interfaces and establishes a private connection between the instances. Configure FRRouting with the Border Gateway Protocol (BGP) protocol to designate the roles of primary and backup, thus enabling failover. Follow the instructions in our [Configure IP failover over BGP using FRR (advanced)](/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr) guide to designate these roles on your HAProxy instances. +1. Link the second HAProxy instance to the new IP address on the first instance by following the *Configuring IP Sharing* section of the guide linked above. -In this setup, the primary and backup servers are two separate compute instances joined to a single shared IP address using BGP. If the backup HAProxy server detects failure in the primary it then begins to accept traffic. The HAProxy configuration file (`/etc/haproxy/haproxy.conf`) from the primary instance must be replicated verbatim on the backup server. Any subsequent changes made to the HAProxy configuration file on primary must be replicated on the backup instance. +{{< note >}} +The steps in this guide require root privileges. Be sure to run the steps below as `root` or with the `sudo` prefix. For more information on privileges, see our [Users and Groups](/docs/guides/linux-users-and-groups/) guide. +{{< /note >}} + +## Configure the Shared IP Address + +Follow the instructions for your distribution to add the shared IP address to the networking configuration on both the primary and backup HAProxy servers: + +{{< tabs >}} +{{< tab "Ubuntu 24.04 LTS" >}} +Ubuntu 24.04 LTS uses `netplan` to manage network settings. + +1. Open the `/etc/netplan/01-netcfg.yaml` file in a text editor such as `nano`: + + ```command + nano /etc/netplan/01-netcfg.yaml + ``` + + Append the highlighted lines to the end of the file: + + ```file {title="/etc/netplan/01-netcfg.yaml" hl_lines="7-11"} + network: + version: 2 + renderer: networkd + ethernets: + eth0: + dhcp4: yes + lo: + match: + name: lo + addresses: + - {{< placeholder "SHARED_IP_ADDRESS" >}}/{{< placeholder "PREFIX" >}} + ``` + + Be sure to make substitute your actual values for the following placeholders: + + - {{< placeholder "SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. + - {{< placeholder "PREFIX" >}}: Use `32` for IPv4 addresses. For IPv6, use either `56` or `64`, depending on the range you're sharing. + + When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. + +1. Run the following command to apply the changes: + + ```command + sudo netplan apply + ``` +{{< /tab >}} +{{< tab "CentOS Stream 9" >}} +CentOS Stream 9 uses NetworkManager to configure network settings. + +1. Open the network configuration file for editing: + + ```command + sudo nano /etc/sysconfig/network-scripts/ifcfg-lo:1 + ``` + + Add the following configurations to set up the shared IP address: + + ```file {title="/etc/sysconfig/network-scripts/ifcfg-lo:1"} + DEVICE=lo:1 + IPADDR={{< placeholder "SHARED_IP_ADDRESS" >}} + NETMASK={{< placeholder "NETMASK" >}} + ONBOOT=yes + ``` + + Be sure to make substitute your actual values for the following placeholders: + + - {{< placeholder "SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. + - {{< placeholder "NETMASK" >}}: Use `255.255.255.255` for IPv4 addresses. + + When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. + +1. Restart `NetworkManager` to apply the settings: + + ```command + sudo systemctl restart NetworkManager + ``` +{{< /tab >}} +{{< tab "openSUSE Leap 15.6" >}} +openSUSE Leap 15.6 uses `wicked` to manage network configurations. + +1. Edit the loopback configuration file: + + ```command + sudo nano /etc/sysconfig/network/ifcfg-lo + ``` + + Append the shared IP address settings to the end of the file: + + ```file {title="/etc/sysconfig/network/ifcfg-lo"} + IPADDR={{< placeholder "SHARED_IP_ADDRESS" >}} + NETMASK={{< placeholder "NETMASK" >}} + LABEL=1 + ``` -## Configure IP Sharing + Be sure to make substitute your actual values for the following placeholders: -This guide uses Akamai’s IP Host Address Sharing. While the TCP/IP protocol requires unique IP/MAC address pairs, it does support IP sharing within the same data center. IP Sharing allows two distinct IP/MAC pairs on different instances to share the same IP address, with one being active and the other passive. + - {{< placeholder "SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. + - {{< placeholder "NETMASK" >}}: Use `255.255.255.255` for IPv4 addresses. -The primary and backup HAProxy servers communicate over their private network using the BGP protocol chosen in the FRRouting configuration file. The backup server uses a "ping-like" test on the primary server to detect failure. If the primary server fails, the backup automatically takes over the duties of the primary, allowing HAProxy's reverse proxy service to continue operating. + When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. -In order to use IP Sharing, both instances must be within the same datacenter, and IP Sharing is available in most Linode data centers. Follow the instructions in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks) to build an identical instance in the same data center as the original HAProxy server. Once deployed, [configure IP sharing](/docs/products/compute/compute-instances/guides/manage-ip-addresses/#configuring-ip-sharing) for both the original HAProxy server and the newly created instance. +1. Restart the network to activate the settings: -This additional instance demonstrates both IP Sharing and failover functionality. + ```command + sudo systemctl restart wicked + ``` +{{< /tab >}} +{{< /tabs >}} + +## Duplicate the HAProxy Configuration File + +To prepare for failover, the backup HAProxy instance must have an identical HAProxy configuration file to the primary instance. To ensure this, copy the HAProxy configuration file from the primary server to the backup server. + +Run this `scp` command on the backup server, replacing {{< placeholder "USERNAME" >}} with either `root` or another user with `sudo` access, and {{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}} with the actual IP address of the primary HAProxy server: + +```command {title="Backup Instance"} +scp {{< placeholder "USERNAME" >}}@{{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}}:/etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg +``` + +When prompted, enter the primary server's `root` or `sudo` user password to complete the transfer. -## Configure Failover +Once the command finishes, verify that the configuration files on both servers are identical. -To establish failover, use the FRRouting software daemon (`frr`) with the BGP protocol to connect the primary and backup HAProxy instances. +{{< note >}} +In this example failover configuration, the primary server does not automatically become active once restored. After a failover event, copy the configuration file back to the primary server from the backup server to restore active status. +{{< /note >}} + +## Install FRRouting -### Install FRRouting +With IP Sharing properly configured, you're ready to install FRRouting. 1. Follow the instructions for your distribution to install FRRouting on both the primary and backup HAProxy servers: {{< tabs >}} {{< tab "Ubuntu 24.04 LTS" >}} - Use `apt` to install `frr`: + Install `frr` and `frr-pythontools` using `apt`: ```command - apt install frr frrtools frr-pythontools + apt install frr frr-pythontools ``` {{< /tab >}} {{< tab "CentOS Stream 9" >}} - Use `dnf` to install `frr`: + Install `frr` and `frr-pythontools` using `dnf`: ```command sudo dnf install frr frr-pythontools ``` {{< /tab >}} {{< tab "openSUSE Leap 15.6" >}} - Use `zypper` to install `frr`: + Install `frr` using `zypper`: ```command - sudo zypper frr + sudo zypper install frr ``` {{< /tab >}} {{< /tabs >}} -1. Use `systemctl` to start `frr`: +1. Start the FRRouting service using `systemctl`: ```command systemctl start frr ``` -1. Enable `frr` to automatically run on startup: +1. Enable FRRouting to run on startup: ```command systemctl enable frr ``` -### Configure FRRouting for Failover - -FRRouting requires unique configurations for the primary and backup instances. Follow the **Configure FRR** section of our [Configure IP failover over BGP using FRR (advanced)](/docs/products/compute/compute-instances/guides/failover-bgp-frr/#configure-frr) guide to set up the `frr` daemon. The `frr` daemon checks the servers in its configuration list and begins to accept incoming traffic when the primary server fails. The configuration shown monitors the primary server for health using the BGP protocol. - -After ensuring that the `frr` configuration files `/etc/frr/daemons` and `/etc/frr/frr.conf` files are updated correctly, restart the `frr` daemon: - -```command -sudo systemctl restart frr -``` - -{{< note >}} -In this example failover configuration, the primary server does not automatically become active once restored. -{{< /note >}} +## Configure FRRouting -## Sync HAProxy Configuration Between Primary and Backup Servers +FRRouting must be configured on both the primary and backup HAProxy instances. -The backup HAProxy server must have an exact copy of the HAProxy configuration file from the primary server. To ensure this, copy the HAProxy configuration file from the primary server to the backup. +1. Open the FRRouting `/etc/frr/daemons` file to enable the BGP daemon: -Issue the following `scp` command from the backup server, substituting {{< placeholder "USERNAME" >}} for either `root` or a user with `sudo` access and {{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}} with the actual IP address of the primary HAProxy server: + ```command + nano /etc/frr/daemons + ``` -```command {title="Backup Instance"} -scp {{< placeholder "USERNAME" >}}@{{< placeholder "PRIMARY_SERVER_IP_ADDRESS" >}}:/etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg -``` + Locate the `bgpd` line and change its value to `yes` to activate the BGP daemon: -When prompted, enter the primary server's `root` or `sudo` user password to complete the `scp` command. + ```file {title="/etc/frr/daemons"} + # The watchfrr and zebra daemons are always started. + # + bgpd=yes + ``` -Before proceeding, verify that the configuration files on both of the servers are identical. + When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. -{{< note >}} -After a failover event, copy this file back to the primary server from the backup server in order to restore it to active duty. -{{< /note >}} +1. Open the FRRouting configuration file located at `/etc/frr/frr.conf`: -## Configure the Secondary HAProxy Instance with Shared IP Address + ```command + nano /etc/frr/frr.conf + ``` -Once the additional HAProxy server instance is set up, [add an additional network interface](/docs/products/compute/compute-instances/guides/failover/#add-the-shared-ip-to-the-networking-configuration) to both servers. This allows both HAProxy servers to operate under the same IP address, though only one instance is active at a time. + Append the following content to the end of the file to configure BGP settings: + + ```file {title="/etc/frr/frr.conf" hl_lines="1,11-14,16,17"} + hostname {{< placeholder "HOSTNAME" >}} + + router bgp 65001 + no bgp ebgp-requires-policy + coalesce-time 1000 + bgp bestpath as-path multipath-relax + neighbor RS peer-group + neighbor RS remote-as external + neighbor RS ebgp-multihop 10 + neighbor RS capability extended-nexthop + neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::1 peer-group RS + neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::2 peer-group RS + neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::3 peer-group RS + neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::4 peer-group RS + + address-family {{< placeholder "PROTOCOL" >}} unicast + network {{< placeholder "SHARED_IP_ADDRESS" >}}/{{< placeholder "PREFIX" >}} route-map {{< placeholder "ROLE" >}} + redistribute static + exit-address-family + + route-map primary permit 10 + set community 65000:1 + route-map secondary permit 10 + set community 65000:2 + + ipv6 nht resolve-via-default + ``` -Restart both host’s network services to apply the shared IP address setting: + Substitute the following placeholders for your actual information: -```command {title="Primary Instance & Backup Instance"} -systemctl restart networkd -``` + - {{< placeholder "HOSTNAME" >}}: Your instance's hostname. + - {{< placeholder "DC_ID" >}}: The data center ID where your instances are located. Reference our [IP Sharing Availability table](https://techdocs.akamai.com/cloud-computing/docs/configure-failover-on-a-compute-instance#ip-sharing-availability) to determine the ID for your data center. + - {{< placeholder "PROTOCOL" >}}: Either `ipv4` for IPv4 or `ipv6` for IPv6. + - {{< placeholder "SHARED_IP_ADDRESS" >}}: Your shared IP address. + - {{< placeholder "PREFIX" >}}: Use `32` for IPv4 addresses. For IPv6, use either `56` or `64`, depending on the range you're sharing. + - {{< placeholder "ROLE" >}}: Set as `primary` on the primary instance and `secondary` on the backup instance. -After restarting, the FRRouting daemon on the backup server begins checking for an active BGP routing path from the primary. If the primary fails to respond, the backup takes over, routing traffic according to the HAproxy configuration rules copied from the primary server. + When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. -During the backup server's initial activation, some latency may occur as frontend client requests are directed to backend instances. This latency may be noticeable in high-traffic environments, potentially requiring users to refresh sessions or retry connections. Some users may also encounter temporary TCP or HTTP error messages. +1. Restart `frr` to apply the configuration changes: -{{< note >}} -Client-side applications (such as web browsers or mobile apps) should include code that detects connection errors during failover. When latency or errors occur, the client app can automatically retry the connection until traffic normalizes on the backup server. -{{< /note >}} + ```command + sudo systemctl restart frr + ``` ## Test Failover -Use the TCP health check setup described in [Getting Stated with HAProxy TCP Load Balancing and Health Checks](/docs/guides/getting-started-with-haproxy-tcp-load-balancing-and-health-checks) to confirm proper routing to the three backend servers (`backend1`, `backend2`, and `backend3`) through the shared IP address. +FRRouting on the backup server monitors the primary server’s status using a "ping-like" test. If the primary does not respond, the backup automatically takes over, providing continuous access to backend services. -Follow the steps below to test failover: +To test failover, follow these steps: -1. **Verify Initial Access**: Ensure that the primary HAProxy server is serving pages correctly. Navigate to the shared IP address in a web browser and refresh until you can access all three backend servers. +1. **Verify Initial Access**: Ensure the primary HAProxy server is actively serving pages. Open the shared IP address in a web browser and refresh until all three backend servers respond successfully. -1. **Simulate Primary Failure**: In the Akamai Cloud Manager, power down the primary HAProxy server instance to trigger a failover. +1. **Simulate Primary Failure**: Use the Akamai Cloud Manager to power down the primary HAProxy instance, triggering a failover to the backup server. -1. **Confirm Failover**: After shutting down the primary server, refresh the browser. Within a few seconds, the pages should re-appear, now routed through the backup server. This indicates that failover is functioning correctly. +1. **Confirm Failover**: Refresh the browser after powering down the primary HAProxy instance. Within a few seconds, the pages should load again, now served through the backup HAProxy instance. This indicates that failover is working as expected. ### Troubleshooting Test Failures -If the failover test fails and refreshing the browser does not restore page access from the backup server after several seconds, follow these troubleshooting steps: - -- **Verify IP Sharing Configuration**: Ensure that all steps for setting up IP Sharing were followed correctly. -- **Check Network Connectivity**: Use the ICMP Ping command to verify that the backup server is reachable. If it isn't, there may be an issue with IP Sharing. -- **Review FRRouting Configuration**: Check the Roles section of`frr.config` to confirm that it is configured according to the provided directions. -- **Confirm HAProxy Configuration**: Ensure that the backup server's `/etc/haproxy/haproxy.cfg` file was correctly copied from the primary server. -- **Test Backend Server Accessibility**: Use a web browser to directly access a backend server (e.g. `backend1`) by its IP address. If the server responds, the failover server configuration may no be set up correctly. - -Latency during the failover from primary to backup should not exceed a few seconds. The FRRouting daemon's configuration offers several settings to optimize detection and failover speed. - -## Conclusion +If failover does not occur and refreshing the browser does not restore page access through the backup server after several seconds, follow these troubleshooting steps: -This series of HAProxy guides show the basic TCP and HTTP backend network load balancing and failover mechanisms available. These examples only skim the surface of a sophisticated number of options that you can deploy. They work for the FOSS version, and more extensive and expansive options are available in the HAProxy non-FOSS Enterprise Edition. +- **Verify IP Sharing Configuration**: Double-check that all steps for configuring IP Sharing were followed correctly. +- **Check Network Connectivity**: Use the ICMP `ping` command to test if the backup server is reachable. If the backup server is not reachable, there may be an issue with the IP Sharing configuration. +- **Review FRRouting Configuration**: Ensure that the FRRouting `frr.config` file is correctly configured, especially the Roles section, which should be set according to the provided instructions. +- **Confirm HAProxy Configuration**: Verify that the backup server's `/etc/haproxy/haproxy.cfg` file matches the configuration of the primary server by comparing the two files directly. +- **Test Backend Server Accessibility**: Try accessing a backend server directly (e.g. `backend1`) by its IP address. If the backend server responds correctly, the issue may lie with the failover configuration rather than the backend services. -HAProxy is extremely popular for backend load balancing and reverse proxy services, including its ability to serve as an SSL/TLS processor. Akamai IP Sharing services glue high-traffic instances together, using FOSS tools such as FRRouting and HAProxy for higher reliability. \ No newline at end of file +Failover latency should be minimal, ideally within a few seconds. If failover takes longer, the FRRouting daemon's configuration offers several settings to optimize detection and failover speed. \ No newline at end of file From 98de28e6d89d64de184e8861465edbcf1a7185f3 Mon Sep 17 00:00:00 2001 From: Adam Overa Date: Tue, 19 Nov 2024 13:59:34 -0500 Subject: [PATCH 5/6] Tech Edit 4 --- .../index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md index e7fe9a12622..f47867cdcb1 100644 --- a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md +++ b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md @@ -42,7 +42,7 @@ Ubuntu 24.04 LTS uses `netplan` to manage network settings. 1. Open the `/etc/netplan/01-netcfg.yaml` file in a text editor such as `nano`: ```command - nano /etc/netplan/01-netcfg.yaml + sudo nano /etc/netplan/01-netcfg.yaml ``` Append the highlighted lines to the end of the file: @@ -166,14 +166,14 @@ With IP Sharing properly configured, you're ready to install FRRouting. Install `frr` and `frr-pythontools` using `apt`: ```command - apt install frr frr-pythontools + sudo apt install frr frr-pythontools ``` {{< /tab >}} {{< tab "CentOS Stream 9" >}} Install `frr` and `frr-pythontools` using `dnf`: ```command - sudo dnf install frr frr-pythontools + sudo dnf install frr ``` {{< /tab >}} {{< tab "openSUSE Leap 15.6" >}} @@ -188,13 +188,13 @@ With IP Sharing properly configured, you're ready to install FRRouting. 1. Start the FRRouting service using `systemctl`: ```command - systemctl start frr + sudo systemctl start frr ``` 1. Enable FRRouting to run on startup: ```command - systemctl enable frr + sudo systemctl enable frr ``` ## Configure FRRouting @@ -204,7 +204,7 @@ FRRouting must be configured on both the primary and backup HAProxy instances. 1. Open the FRRouting `/etc/frr/daemons` file to enable the BGP daemon: ```command - nano /etc/frr/daemons + sudo nano /etc/frr/daemons ``` Locate the `bgpd` line and change its value to `yes` to activate the BGP daemon: @@ -220,7 +220,7 @@ FRRouting must be configured on both the primary and backup HAProxy instances. 1. Open the FRRouting configuration file located at `/etc/frr/frr.conf`: ```command - nano /etc/frr/frr.conf + sudo nano /etc/frr/frr.conf ``` Append the following content to the end of the file to configure BGP settings: From 922a4907178288358eaf7473c12271370bd48c9a Mon Sep 17 00:00:00 2001 From: Nathan Melehan Date: Tue, 17 Dec 2024 13:36:02 -0500 Subject: [PATCH 6/6] Copy edits --- .../index.md | 70 +++++++++---------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md index f47867cdcb1..fbf4f1712f2 100644 --- a/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md +++ b/docs/guides/uptime/loadbalancing/configure-failover-for-haproxy-on-akamai/index.md @@ -1,19 +1,19 @@ --- slug: configure-failover-for-haproxy-on-akamai -title: "Configure Failover for Haproxy on Akamai" +title: "Configure Failover for HAProxy on Akamai" description: "Learn how to set up HAProxy load balancing with IP sharing, FRRouting, and BGP failover in this step-by-step guide." authors: ["Tom Henderson"] contributors: ["Tom Henderson"] -published: 2024-09-18 +published: 2024-12-17 keywords: ['haproxy','load balancing','failover','ip sharing','frrouting','bgp','high availability'] license: '[CC BY-ND 4.0](https://creativecommons.org/licenses/by-nd/4.0)' --- -[HAProxy](https://www.haproxy.org/) is an HTTP and TCP gateway server that functions as a reverse proxy between a public-facing IP address and backend servers. It manages incoming traffic using frontend rules and distributes it across backend servers, providing load balancing and repairing HTTP requests when needed. +[HAProxy](https://www.haproxy.org/) is an HTTP and TCP gateway server that functions as a reverse proxy between a public-facing IP address and a set of backend servers. It manages incoming traffic using frontend rules and distributes it across the backend servers, providing load balancing and repairing HTTP requests when needed. -However, HAProxy introduces a single point of failure. If the HAProxy server goes down, client connections to backend services are interrupted. This guide demonstrates how to configure HAProxy with a shared IP address and [FRRouting](https://frrouting.org/) to manage failover. The IP Sharing setup enables two HAProxy instances (primary and backup) to operate under the same IP address. In this setup, one instance is always active and the other stands ready to take over in case of failure. FRRouting, configured with the Border Gateway Protocol (BGP), facilitates this automatic failover, maintaining service continuity. +However, HAProxy introduces a single point of failure. If the HAProxy server goes down, client connections to backend services are interrupted. This guide demonstrates how to configure HAProxy with a shared IP address and [FRRouting](https://frrouting.org/) to manage failover. The IP Sharing setup enables two HAProxy instances (primary and backup) to operate under the same IP address. In this setup, the primary instance is always active and the backup instance stands ready to take over in case of failure of the primary instance. FRRouting, configured with the Border Gateway Protocol (*BGP*), facilitates this automatic failover and maintains service continuity. -This guide uses the free and open source (FOSS) version of HAProxy to create and demonstrate basic HAProxy failover pairs. With the FOSS version of HAProxy, the backup server doesn’t retain the connection states of the primary instance. Therefore, when the backup becomes active, clients may need to reconnect to re-establish sessions. In contrast, the enterprise edition offers state-saving and restoration capabilities, along with other features that restore a failover with configuration data. +This guide uses the free and open source (*FOSS*) version of HAProxy to create and demonstrate basic HAProxy failover pairs. With the FOSS version of HAProxy, the backup server doesn't retain the connection states of the primary instance. Therefore, when the backup becomes active, clients may need to reconnect to re-establish sessions. In contrast, the enterprise edition offers state-saving and restoration capabilities, along with other features that restore a failover with configuration data. ## Before You Begin @@ -23,9 +23,9 @@ This guide uses the free and open source (FOSS) version of HAProxy to create and 1. Disable Network Helper on both HAProxy instances by following the *Individual Compute Instance setting* section of our [Network Helper](https://techdocs.akamai.com/cloud-computing/docs/automatically-configure-networking#individual-compute-instance-setting) guide. -1. Add an IP address to the first HAProxy instance by following the steps in the *Adding an IP Address* section of [Managing IP Addresses on a Compute Instance](/docs/products/compute/compute-instances/guides/manage-ip-addresses/#adding-an-ip-address). +1. Add an IP address to the first HAProxy instance by following the steps in the *Adding an IP Address* section of [Managing IP Addresses on a Compute Instance](https://techdocs.akamai.com/cloud-computing/docs/managing-ip-addresses-on-a-compute-instance#adding-an-ip-address). -1. Link the second HAProxy instance to the new IP address on the first instance by following the *Configuring IP Sharing* section of the guide linked above. +1. Link the second HAProxy instance to the new IP address on the first instance by following the *Configuring IP Sharing* section of [Managing IP Addresses on a Compute Instance](https://techdocs.akamai.com/cloud-computing/docs/managing-ip-addresses-on-a-compute-instance#configuring-ip-sharing). {{< note >}} The steps in this guide require root privileges. Be sure to run the steps below as `root` or with the `sudo` prefix. For more information on privileges, see our [Users and Groups](/docs/guides/linux-users-and-groups/) guide. @@ -58,13 +58,13 @@ Ubuntu 24.04 LTS uses `netplan` to manage network settings. match: name: lo addresses: - - {{< placeholder "SHARED_IP_ADDRESS" >}}/{{< placeholder "PREFIX" >}} + - YOUR_SHARED_IP_ADDRESS/YOUR_PREFIX ``` Be sure to make substitute your actual values for the following placeholders: - - {{< placeholder "SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. - - {{< placeholder "PREFIX" >}}: Use `32` for IPv4 addresses. For IPv6, use either `56` or `64`, depending on the range you're sharing. + - {{< placeholder "YOUR_SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. + - {{< placeholder "YOUR_PREFIX" >}}: Use `32` for IPv4 addresses. For IPv6, use either `56` or `64`, depending on the range you're sharing. When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. @@ -87,15 +87,15 @@ CentOS Stream 9 uses NetworkManager to configure network settings. ```file {title="/etc/sysconfig/network-scripts/ifcfg-lo:1"} DEVICE=lo:1 - IPADDR={{< placeholder "SHARED_IP_ADDRESS" >}} - NETMASK={{< placeholder "NETMASK" >}} + IPADDR=YOUR_SHARED_IP_ADDRESS + NETMASK=YOUR_NETMASK ONBOOT=yes ``` Be sure to make substitute your actual values for the following placeholders: - - {{< placeholder "SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. - - {{< placeholder "NETMASK" >}}: Use `255.255.255.255` for IPv4 addresses. + - {{< placeholder "YOUR_SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. + - {{< placeholder "YOUR_NETMASK" >}}: Use `255.255.255.255` for IPv4 addresses. When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. @@ -117,15 +117,15 @@ openSUSE Leap 15.6 uses `wicked` to manage network configurations. Append the shared IP address settings to the end of the file: ```file {title="/etc/sysconfig/network/ifcfg-lo"} - IPADDR={{< placeholder "SHARED_IP_ADDRESS" >}} - NETMASK={{< placeholder "NETMASK" >}} + IPADDR=YOUR_SHARED_IP_ADDRESS + NETMASK=YOUR_NETMASK LABEL=1 ``` Be sure to make substitute your actual values for the following placeholders: - - {{< placeholder "SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. - - {{< placeholder "NETMASK" >}}: Use `255.255.255.255` for IPv4 addresses. + - {{< placeholder "YOUR_SHARED_IP_ADDRESS" >}}: The shared IP address you set for HAProxy failover. + - {{< placeholder "YOUR_NETMASK" >}}: Use `255.255.255.255` for IPv4 addresses. When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. @@ -157,9 +157,9 @@ In this example failover configuration, the primary server does not automaticall ## Install FRRouting -With IP Sharing properly configured, you're ready to install FRRouting. +With IP Sharing properly configured, you're ready to install FRRouting. Follow these instructions on both the primary and backup HAProxy servers: -1. Follow the instructions for your distribution to install FRRouting on both the primary and backup HAProxy servers: +1. Install FRRouting: {{< tabs >}} {{< tab "Ubuntu 24.04 LTS" >}} @@ -199,7 +199,7 @@ With IP Sharing properly configured, you're ready to install FRRouting. ## Configure FRRouting -FRRouting must be configured on both the primary and backup HAProxy instances. +FRRouting must be configured on both the primary and backup HAProxy instances. Follow these instructions on both instances: 1. Open the FRRouting `/etc/frr/daemons` file to enable the BGP daemon: @@ -226,7 +226,7 @@ FRRouting must be configured on both the primary and backup HAProxy instances. Append the following content to the end of the file to configure BGP settings: ```file {title="/etc/frr/frr.conf" hl_lines="1,11-14,16,17"} - hostname {{< placeholder "HOSTNAME" >}} + hostname {{< placeholder "YOUR_HOSTNAME" >}} router bgp 65001 no bgp ebgp-requires-policy @@ -236,13 +236,13 @@ FRRouting must be configured on both the primary and backup HAProxy instances. neighbor RS remote-as external neighbor RS ebgp-multihop 10 neighbor RS capability extended-nexthop - neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::1 peer-group RS - neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::2 peer-group RS - neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::3 peer-group RS - neighbor 2600:3c0f:{{< placeholder "DC_ID" >}}:34::4 peer-group RS + neighbor 2600:3c0f:{{< placeholder "YOUR_DC_ID" >}}:34::1 peer-group RS + neighbor 2600:3c0f:{{< placeholder "YOUR_DC_ID" >}}:34::2 peer-group RS + neighbor 2600:3c0f:{{< placeholder "YOUR_DC_ID" >}}:34::3 peer-group RS + neighbor 2600:3c0f:{{< placeholder "YOUR_DC_ID" >}}:34::4 peer-group RS - address-family {{< placeholder "PROTOCOL" >}} unicast - network {{< placeholder "SHARED_IP_ADDRESS" >}}/{{< placeholder "PREFIX" >}} route-map {{< placeholder "ROLE" >}} + address-family {{< placeholder "YOUR_PROTOCOL" >}} unicast + network {{< placeholder "YOUR_SHARED_IP_ADDRESS" >}}/{{< placeholder "YOUR_PREFIX" >}} route-map {{< placeholder "YOUR_ROLE" >}} redistribute static exit-address-family @@ -256,12 +256,12 @@ FRRouting must be configured on both the primary and backup HAProxy instances. Substitute the following placeholders for your actual information: - - {{< placeholder "HOSTNAME" >}}: Your instance's hostname. - - {{< placeholder "DC_ID" >}}: The data center ID where your instances are located. Reference our [IP Sharing Availability table](https://techdocs.akamai.com/cloud-computing/docs/configure-failover-on-a-compute-instance#ip-sharing-availability) to determine the ID for your data center. - - {{< placeholder "PROTOCOL" >}}: Either `ipv4` for IPv4 or `ipv6` for IPv6. - - {{< placeholder "SHARED_IP_ADDRESS" >}}: Your shared IP address. - - {{< placeholder "PREFIX" >}}: Use `32` for IPv4 addresses. For IPv6, use either `56` or `64`, depending on the range you're sharing. - - {{< placeholder "ROLE" >}}: Set as `primary` on the primary instance and `secondary` on the backup instance. + - {{< placeholder "YOUR_HOSTNAME" >}}: Your instance's hostname. + - {{< placeholder "YOUR_DC_ID" >}}: The data center ID where your instances are located. Reference our [IP Sharing Availability table](https://techdocs.akamai.com/cloud-computing/docs/configure-failover-on-a-compute-instance#ip-sharing-availability) to determine the ID for your data center. + - {{< placeholder "YOUR_PROTOCOL" >}}: Either `ipv4` for IPv4 or `ipv6` for IPv6. + - {{< placeholder "YOUR_SHARED_IP_ADDRESS" >}}: Your shared IP address. + - {{< placeholder "YOUR_PREFIX" >}}: Use `32` for IPv4 addresses. For IPv6, use either `56` or `64`, depending on the range you're sharing. + - {{< placeholder "YOUR_ROLE" >}}: Set as `primary` on the primary instance and `secondary` on the backup instance. When done, press CTRL+X, followed by Y then Enter to save the file and exit `nano`. @@ -273,7 +273,7 @@ FRRouting must be configured on both the primary and backup HAProxy instances. ## Test Failover -FRRouting on the backup server monitors the primary server’s status using a "ping-like" test. If the primary does not respond, the backup automatically takes over, providing continuous access to backend services. +FRRouting on the backup server monitors the primary server's status using a "ping-like" test. If the primary does not respond, the backup automatically takes over, providing continuous access to backend services. To test failover, follow these steps: