A high availability (HA) network gateway using Keepalived and Nginx

Here’s a sample configuration for establishing a high availability (HA) architecture using Keepalived and Nginx:

1. Install Keepalived and Nginx on each server.
2. Configure Keepalived on both servers:
   • Modify the Keepalived configuration file (e.g., /etc/keepalived/keepalived.conf) on each server.
   • Define the virtual IP (VIP) address for HA. For example, set virtual_ipaddress to “192.168.0.100”.
   • Set up the VRRP instance with VRRP authentication and priority settings.
   • Develop a health check script to monitor the main server’s availability.
3. Configure Nginx on each server:
   • Modify the Nginx configuration file (e.g., /etc/nginx/nginx.conf) on each server.
   • Identify the upstream servers for load balancing the traffic. For instance, set upstream backend with the IP addresses and ports of your application servers.
   • Configure the server block to listen on the VIP address and proxy requests to the upstream servers.
4. Activate and enable Keepalived and Nginx services on both servers.

After configuring Keepalived and Nginx on both servers, the primary server will utilize the VIP address and manage the incoming traffic. If the primary server becomes unavailable, Keepalived will automatically assign the VIP to the secondary server, which will assume control of the traffic using Nginx.

Remember that this is a simplified example, and the actual configuration may differ based on your specific needs and environment. It’s crucial to refer to the documentation and guides provided by Keepalived and Nginx to ensure a correct configuration for your HA setup.

Here’s a simplified example of a Keepalived configuration file (/etc/keepalived/keepalived.conf):

vrrp_instance VI_1 {
    state MASTER  # Set this to BACKUP on the secondary server
    interface eth0  # Specify the network interface to monitor
    virtual_router_id 51  # An arbitrary ID for the VRRP instance
    priority 100  # Set this to a lower value (e.g., 90) on the secondary server

    authentication {
        auth_type PASS
        auth_pass your_password  # Set a strong password for VRRP authentication
    }

    virtual_ipaddress {
        192.168.0.100  # The virtual IP address to be used for HA
    }

    track_script {
        chk_nginx  # Name of the health check script for monitoring Nginx
    }
}

In this example, the primary server is set as the MASTER with a higher priority, while the secondary server is set as BACKUP with a lower priority. The interface parameter determines the network interface to monitor for connectivity, and the virtual_router_id is a unique ID identifying the VRRP instance.

The authentication section outlines the authentication method and password for VRRP. It’s crucial to select a robust password to ensure secure server communication.

The virtual_ipaddress section specifies the virtual IP address (VIP), set to 192.168.0.100 in this case, used for the HA setup.

The track_script section allows the definition of a health check script, such as chk_nginx, to monitor Nginx’s availability.

Remember, this is a basic example, and you might need to adapt the configuration based on your specific setup, network interface, authentication requirements, and health check script. Be sure to refer to the Keepalived documentation and customize the configuration file as needed.

Here’s an expanded example of a Keepalived configuration file (/etc/keepalived/keepalived.conf) with extra directives:

! Configuration example for Keepalived

global_defs {
    router_id HA_Cluster  # An arbitrary unique identifier for the router
}

vrrp_script chk_nginx {
    script "/usr/local/bin/check_nginx.sh"  # Path to the custom health check script
    interval 10  # Check interval in seconds
    timeout 3  # Timeout in seconds
    fall 3  # Number of consecutive failures to consider a server as down
    rise 2  # Number of consecutive successes to consider a server as up
}

vrrp_instance VI_1 {
    state MASTER  # Set this to BACKUP on the secondary server
    interface eth0  # Specify the network interface to monitor
    virtual_router_id 51  # An arbitrary ID for the VRRP instance
    priority 100  # Set this to a lower value (e.g., 90) on the secondary server

    authentication {
        auth_type PASS
        auth_pass your_password  # Set a strong password for VRRP authentication
    }

    virtual_ipaddress {
        192.168.0.100  # The virtual IP address to be used for HA
    }

    track_script {
        chk_nginx  # Name of the health check script for monitoring Nginx
    }

    notify_master "/usr/local/bin/master.sh"  # Path to the custom script to execute when becoming the master
    notify_backup "/usr/local/bin/backup.sh"  # Path to the custom script to execute when becoming the backup
    notify_fault "/usr/local/bin/fault.sh"  # Path to the custom script to execute on a fault event

    smtp_alert  # Enable email alerts in case of state transition events
    smtp_server your_smtp_server  # SMTP server address for email alerts
    smtp_connect_timeout 30  # SMTP connection timeout in seconds
    smtp_interface eth0  # Specify the network interface for email alerts
    smtp_from your_email@your_domain.com  # Sender email address for email alerts
    smtp_to your_alert_email@your_domain.com  # Recipient email address for email alerts
    smtp_subject "Keepalived Notification"  # Subject line for email alerts
}

In this example, the global_defs section establishes a unique identifier for the router.

The vrrp_script section designates a health check script (chk_nginx) which monitors Nginx’s availability. Replace /usr/local/bin/check_nginx.sh with the path to your custom health check script. The parameters interval, timeout, fall, and rise determine the check interval, timeout, and the server’s state criteria.

The vrrp_instance section configures the VRRP instance. Set the state parameter to MASTER on the primary server and BACKUP on the secondary server. The interface parameter indicates the network interface to monitor, and virtual_router_id is an arbitrary ID identifying the VRRP instance. The server’s priority is determined by the priority parameter, with a higher value signifying higher priority.

The authentication section outlines the authentication method and password for VRRP communication.

The virtual_ipaddress block specifies the virtual IP address (VIP) for the HA setup.

The track_script section refers to the health check script monitoring Nginx availability.

The directives notify_master, notify_backup, and notify_fault stipulate custom scripts to run during state transition events.

The smtp_alert directive enables email alerts for state transition events, with the SMTP server and email addresses configured in the following lines.

This configuration is merely an example. You will need to tailor it to your specific setup, file paths, authentication requirements, and notification scripts. For more details on each directive, refer to the Keepalived documentation and adjust the configuration as needed.

Here’s an example of a Keepalived configuration file (/etc/keepalived/keepalived.conf) for the secondary server set as BACKUP:

! Configuration example for Keepalived (BACKUP)

global_defs {
    router_id HA_Cluster  # An arbitrary unique identifier for the router
}

vrrp_script chk_nginx {
    script "/usr/local/bin/check_nginx.sh"  # Path to the custom health check script
    interval 10  # Check interval in seconds
    timeout 3  # Timeout in seconds
    fall 3  # Number of consecutive failures to consider a server as down
    rise 2  # Number of consecutive successes to consider a server as up
}

vrrp_instance VI_1 {
    state BACKUP  # Set this to MASTER on the primary server
    interface eth0  # Specify the network interface to monitor
    virtual_router_id 51  # An arbitrary ID for the VRRP instance
    priority 90  # Set this to a higher value (e.g., 100) on the primary server

    authentication {
        auth_type PASS
        auth_pass your_password  # Set the same strong password used on the primary server
    }

    virtual_ipaddress {
        192.168.0.100  # The virtual IP address to be used for HA
    }

    track_script {
        chk_nginx  # Name of the health check script for monitoring Nginx
    }

    notify_master "/usr/local/bin/master.sh"  # Path to the custom script to execute when becoming the master
    notify_backup "/usr/local/bin/backup.sh"  # Path to the custom script to execute when becoming the backup
    notify_fault "/usr/local/bin/fault.sh"  # Path to the custom script to execute on a fault event

    smtp_alert  # Enable email alerts in case of state transition events
    smtp_server your_smtp_server  # SMTP server address for email alerts
    smtp_connect_timeout 30  # SMTP connection timeout in seconds
    smtp_interface eth0  # Specify the network interface for email alerts
    smtp_from your_email@your_domain.com  # Sender email address for email alerts
    smtp_to your_alert_email@your_domain.com  # Recipient email address for email alerts
    smtp_subject "Keepalived Notification"  # Subject line for email alerts
}

The script /usr/local/bin/master.sh, referenced in the Keepalived configuration file, is a custom script that you can tailor to your specific needs for when the server becomes the master in a high availability setup. This script enables you to execute any required actions or configurations upon the server’s transition to the master state.

Below is an example of a basic /usr/local/bin/master.sh script:

#!/bin/bash

# This script is executed when the server becomes the master in the high availability setup

# Add your custom actions or configurations here
echo "Server is now the master. Performing custom actions..."
# Example: Start additional services or update configurations

# Restart Nginx to ensure it's using the VIP
systemctl restart nginx

In this example, the script begins by printing a message that indicates the server’s transition to the master status. It then carries out any necessary custom actions or configurations. You can customize this script with your own logic, such as initiating additional services, updating configurations, or executing any other tasks required when the server assumes the master role.

Specifically, in this instance, the script restarts Nginx. This is to ensure that it utilizes the Virtual IP (VIP) address, which is now assigned to the master server.

Don’t forget to make the script executable by executing the following command:

chmod +x /usr/local/bin/master.sh

You can tailor the /usr/local/bin/master.sh script to your unique requirements, incorporating any additional commands or settings relevant to your high-availability configuration.

The /usr/local/bin/check_nginx.sh script, referenced in the Keepalived configuration file, is a custom health check script designed to monitor the availability of Nginx. Keepalived periodically runs this script to assess the server’s state and make decisions based on the health check outcomes.

Below is an example of a basic /usr/local/bin/check_nginx.sh script:

#!/bin/bash

# This script checks the availability of Nginx

# Perform a health check on Nginx
response=$(curl -s -o /dev/null -w "%{http_code}" http://localhost)

# Check the HTTP response code
if [ "$response" = "200" ]; then
    exit 0  # Nginx is healthy, exit with 0 (success)
else
    exit 1  # Nginx is down or not responding properly, exit with 1 (failure)
fi

In this example, we use the curl command in a script to send a request to http://localhost and retrieve the HTTP response code. If the response code is 200, indicating a successful response, the script exits with a status of 0. This status represents that Nginx is healthy. However, if the response code differs from 200, the script exits with a status of 1, indicating that Nginx is either down or not responding correctly.

You can modify the health check script to meet your specific needs and determine how you want to check Nginx’s health. For instance, you might want to check additional conditions such as response time, specific page content, or conduct more complex checks. Ensure your script exits with a 0 status when Nginx is healthy, and a 1 status when Nginx is down or not responding as expected.

Remember to make your script executable by executing the following command:

chmod +x /usr/local/bin/check_nginx.sh

Keepalived can execute a script and perform health checks at intervals specified in the configuration file.

The custom script, /usr/local/bin/backup.sh, mentioned in the Keepalived configuration file, can be created and defined based on your specific needs when the server transitions to the backup state in a high availability setup. This script enables you to execute any necessary actions or configurations on the backup server.

Below is an example of a simple /usr/local/bin/backup.sh script:

#!/bin/bash

# This script is executed when the server becomes the backup in the high availability setup

# Add your custom actions or configurations here
echo "Server is now the backup. Performing custom actions..."
# Example: Stop unnecessary services or disable certain functionalities

# Stop Nginx to prevent conflicts with the master server
systemctl stop nginx

In this example, the script begins by printing a message that indicates the server has transitioned to the backup state. It then performs any necessary custom actions or configurations. You can customize the script to meet your needs, such as disabling certain functionalities, stopping unnecessary services, or completing other tasks required when the server becomes the backup.

In this specific case, the script stops Nginx to avoid conflicts with the master server. This is because the backup server should not be serving traffic actively while in the backup state.

Don’t forget to make the script executable by executing the following command:

chmod +x /usr/local/bin/backup.sh

You can adjust the /usr/local/bin/backup.sh script to suit your unique needs, adding any commands or configurations relevant to your high availability setup.

The /usr/local/bin/fault.sh script, referenced in the Keepalived configuration file, is a custom script that you can create and tailor to your specific needs. It handles fault events in a high availability setup and is executed when a fault event signals an issue with the server or the high availability configuration.

Below is an example of a simple /usr/local/bin/fault.sh script:

#!/bin/bash

# This script is executed on a fault event in the high availability setup

# Add your custom actions or configurations here
echo "Fault event detected. Performing custom actions..."
# Example: Send notifications, log the event, or trigger failover procedures

# Restart Keepalived to initiate failover
systemctl restart keepalived

This script begins by printing a message that a fault event has been detected. It then carries out any required custom actions or configurations. You can incorporate your own logic into the script. This could include sending notifications, logging the event, initiating failover procedures, or executing any other necessary tasks when a fault event happens.

In this particular example, the script restarts Keepalived to start a failover process. This action can help rectify some types of faults and, if needed, trigger a shift to a new master server.

Don’t forget to make the script executable by executing the following command:

#!/bin/bash

# This script is executed when the server detects a fault in the high availability setup.

# Add your custom actions or configurations here
echo "Fault event detected. Performing custom actions..."
# Example: Send an alert or log the event for troubleshooting.

# Restart Nginx and Keepalived to attempt to rectify the issue.
systemctl restart nginx
systemctl restart keepalived

In this script, upon detection of a fault event, a message is printed and then any necessary custom actions or configurations are performed. In this particular

chmod +x /usr/local/bin/fault.sh

Feel free to tailor the /usr/local/bin/fault.sh script to your unique needs, incorporating any extra commands or configurations that are pertinent to managing fault events in your high availability setup.

Reference: https://www.strongd.net/?p=1703

Leave a message

Name

Email



Send