High Availability HTTP Cluster Setup With Apache & Keepalived

by SLV Team 62 views
High Availability HTTP Cluster Setup with Apache & Keepalived

Hey guys! Today, we're diving deep into setting up a high availability (HA) HTTP cluster using Apache and Keepalived. This setup ensures that your web service remains online even if one of your servers goes down. We'll walk through each step, making it super easy to follow along. Let's get started!

Installing Apache and Keepalived

The first step in building your HA cluster is to install Apache and Keepalived on both of your servers. Apache will serve the web content, and Keepalived will manage the virtual IP address, ensuring seamless failover. Let's jump into the commands you'll need to run on both servers.

First off, update your package lists to make sure you're working with the latest versions. This is crucial for security and compatibility. Open your terminal and type:

sudo apt update -y

This command refreshes the package index files, ensuring your system knows about the newest packages available. The -y flag automatically answers 'yes' to any prompts, streamlining the process. Once that's done, it's time to install Apache and Keepalived:

sudo apt install apache2 keepalived -y

This command fetches and installs both Apache2, the web server, and Keepalived, which handles the failover. Again, the -y flag makes the installation smooth and automatic. Now that we have the necessary software installed, let's enable and start Apache on both servers.

To ensure Apache starts automatically on boot, use the following command:

sudo systemctl enable apache2

Enabling Apache means you don't have to manually start it every time your server restarts. It's a set-it-and-forget-it kind of deal. Now, let's get Apache running right away with:

sudo systemctl start apache2

This command fires up the Apache web server. With Apache up and running, we’re one step closer to our HA cluster. Next, we'll create a simple HTML page on each server to differentiate them during our testing. This will help us see the failover in action.

Creating HTML Pages for Each Server

To visually confirm that our high availability setup is working correctly, we'll create a simple HTML page on each server. These pages will display a message indicating which server is currently serving the content. This is a nifty trick to see the failover magic in action! So, let's dive into creating these pages.

First, let's create the HTML page on server1 (10.0.0.237). We'll use the echo command to write the HTML directly into a file. Open your terminal on server1 and type:

echo "<h1>Servidor 1 (10.0.0.237)</h1>" | sudo tee /var/www/html/index.html

This command writes an HTML heading containing the server's identifier to the index.html file in Apache's default web directory. The sudo tee command allows us to write to this protected directory with elevated permissions. Now, let's do the same for server2 (10.0.0.238):

echo "<h1>Servidor 2 (10.0.0.238)</h1>" | sudo tee /var/www/html/index.html

Just like on server1, this command creates an HTML page on server2, clearly labeling it as the second server. With these pages in place, we can easily distinguish between the servers when testing our HA setup. Before we move on, let's quickly test if Apache is serving these pages correctly. We can do this by accessing the servers directly through a web browser or using curl.

To test, you can use the curl command directly from your terminal. This command fetches the content of a URL, allowing you to see the HTML output. Run the following commands to test both servers:

curl http://10.0.0.237
curl http://10.0.0.238

You should see the HTML content we just created, confirming that Apache is serving the pages correctly. If you prefer using a web browser, simply enter the IP addresses (http://10.0.0.237 and http://10.0.0.238) in your browser's address bar. You should see the respective server's message displayed. With our HTML pages set up and verified, we're ready to configure Keepalived. This is where the real magic happens, enabling the failover functionality that makes our cluster highly available.

Configuring Keepalived

Now comes the heart of our high availability setup: configuring Keepalived. Keepalived is the tool that manages the virtual IP and ensures that if one server goes down, the other seamlessly takes over. We'll configure two servers: one as the MASTER and the other as the BACKUP. Let's start with the MASTER server.

Server1 (MASTER) Configuration

On server1 (which will be the MASTER), we need to edit the Keepalived configuration file. Open the configuration file using your favorite text editor. We'll use nano for this example:

sudo nano /etc/keepalived/keepalived.conf

This command opens the keepalived.conf file with administrative privileges. Now, paste the following configuration into the file:

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        10.0.0.239/24
    }
}

Let's break down this configuration:

  • state MASTER: This line declares this server as the MASTER.
  • interface ens33: This is the network interface Keepalived will use. Important: Check your interface name using ip a and change it if necessary. The interface names can vary (e.g., eth0, enp0s3).
  • virtual_router_id 51: This is a unique ID for the virtual router. It should be the same on both servers.
  • priority 100: The MASTER server has a higher priority than the BACKUP. This ensures it takes over the virtual IP when it's online.
  • advert_int 1: This sets the advertisement interval to 1 second, meaning the MASTER will announce its presence every second.
  • authentication: This section provides a simple password for authentication between the servers. Make sure the auth_pass is the same on both servers.
  • virtual_ipaddress: This is the virtual IP address that clients will use to access the service. It floats between the MASTER and BACKUP servers.

After pasting the configuration, save the file and exit the editor. Now, let's configure the BACKUP server.

Server2 (BACKUP) Configuration

On server2 (which will be the BACKUP), we follow a similar process. Open the keepalived.conf file:

sudo nano /etc/keepalived/keepalived.conf

Paste the following configuration into the file:

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        10.0.0.239/24
    }
}

Notice the key differences from the MASTER configuration:

  • state BACKUP: This line declares this server as the BACKUP.
  • priority 90: The BACKUP server has a lower priority than the MASTER. This ensures the MASTER takes precedence when available.

The rest of the configuration is the same, including the interface, virtual_router_id, advert_int, authentication, and virtual_ipaddress. Save the file and exit the editor. With both servers configured, we're ready to start Keepalived and see our HA setup come to life.

Starting Keepalived and Verifying the Floating IP

With Keepalived configured on both servers, the next step is to start the service and verify that the virtual IP is correctly assigned. This will confirm that our basic setup is working as expected. Let's get those Keepalived daemons running!

Starting Keepalived on Both Nodes

First, we need to enable Keepalived to start automatically on boot. This ensures that our HA setup remains active even after a server restart. Run the following command on both server1 and server2:

sudo systemctl enable keepalived

Now that Keepalived is enabled, let's start the service. On both servers, execute the following command:

sudo systemctl start keepalived

This command fires up the Keepalived daemon, which will begin managing the virtual IP address. To ensure everything is running smoothly, it's a good idea to check the status of the Keepalived service. Run this command on both servers:

sudo systemctl status keepalived

This will display the status of the Keepalived service, including any errors or warnings. Look for a line that says “active (running)” to confirm that Keepalived is operating correctly. With Keepalived running, let's verify that the virtual IP has been assigned to the MASTER server.

Verifying the Floating IP

To check which server currently holds the virtual IP, we'll use the ip a command. This command displays all network interfaces and their associated IP addresses. Run the following command on both server1 and server2:

ip a

Examine the output. You should see the virtual IP address (10.0.0.239/24 in our example) listed on only one of the servers. This server is the MASTER. The BACKUP server should not have this IP address assigned. For example, on the MASTER server, you might see output similar to this:

inet 10.0.0.239/24 scope global secondary ens33

This confirms that the virtual IP is active on the ens33 interface of the MASTER server. If the virtual IP is not assigned as expected, double-check your Keepalived configurations and ensure that the service is running on both servers. With the virtual IP verified, we're ready to test the high availability failover. This is the moment of truth where we see our setup in action!

Testing High Availability

Now for the exciting part: testing the high availability failover! This is where we see our hard work pay off as we simulate a server failure and watch the other server seamlessly take over. Let's dive into how we can test this.

Accessing the Virtual IP

First, let's access our service through the virtual IP address. This is the IP address that clients will use to connect to our highly available service. Open a web browser or use curl from your machine and access the virtual IP:

http://10.0.0.239

You should see the message from Server 1 (10.0.0.237), because it's currently acting as the MASTER. This confirms that traffic is being routed to the MASTER server via the virtual IP. Now, let's simulate a failure on the MASTER server and see if the BACKUP server takes over.

Simulating a Failure

To simulate a failure, we'll simply stop the Keepalived service on the MASTER server (Server 1). This will mimic a scenario where the server becomes unresponsive. On Server 1, run the following command:

sudo systemctl stop keepalived

This command stops the Keepalived daemon on Server 1, effectively disconnecting it from the virtual IP management. Now, we wait a few seconds for Keepalived on Server 2 to detect the failure and take over. Keepalived uses the advert_int setting in the configuration file to determine how frequently to check the status of the MASTER. After a few missed advertisements, the BACKUP server will assume the MASTER role.

Observing the Failover

After stopping Keepalived on Server 1, wait for about 10-20 seconds. Then, refresh your web browser or run the curl command again:

http://10.0.0.239

You should now see the message from Server 2 (10.0.0.238)! This confirms that the BACKUP server has successfully taken over the virtual IP and is now serving traffic. Our failover mechanism is working perfectly! To complete the test, let's bring Server 1 back online and observe the reverse failover.

Reverting the Failover

To bring Server 1 back into the cluster, simply restart the Keepalived service. On Server 1, run the following command:

sudo systemctl start keepalived

Because Server 1 has a higher priority (100) than Server 2 (90) in the Keepalived configuration, it will reclaim the MASTER role once it's back online. Wait a few seconds, and then refresh your web browser or run curl again:

http://10.0.0.239

You should once again see the message from Server 1 (10.0.0.237). This confirms that Server 1 has taken over the virtual IP again, and our HA cluster is functioning as expected. This test demonstrates the power and resilience of our high availability setup. Even in the face of server failures, our service remains accessible to users.

Configuration Summary

To wrap things up, let's review the key configurations we set on each server. This will serve as a handy reference for future troubleshooting or modifications. We'll focus on the /etc/keepalived/keepalived.conf file, as it's the heart of our HA setup.

Server1 (MASTER) Configuration

Here’s the keepalived.conf for Server 1, which acts as the MASTER:

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        10.0.0.239/24
    }
}

Key points to remember:

  • state MASTER: This declares Server 1 as the primary server.
  • priority 100: This higher priority ensures Server 1 takes over the virtual IP when available.
  • interface ens33: Make sure this matches your network interface name.
  • virtual_ipaddress 10.0.0.239/24: This is the virtual IP that clients will use.

Server2 (BACKUP) Configuration

And here’s the keepalived.conf for Server 2, our BACKUP server:

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        10.0.0.239/24
    }
}

Key differences from the MASTER configuration:

  • state BACKUP: This declares Server 2 as the backup server.
  • priority 90: The lower priority ensures Server 2 only takes over if Server 1 is unavailable.

Final Thoughts

And there you have it! A fully functional high availability HTTP cluster using Apache and Keepalived. By following these steps, you've created a resilient infrastructure that can withstand server failures and keep your services online. Remember to adapt these configurations to your specific environment, especially the network interface name and IP addresses. High availability is a critical aspect of modern infrastructure, and with tools like Apache and Keepalived, you can ensure your services remain accessible and reliable. Keep experimenting and building, guys! You've got this!