High Availability for SafeSquid Proxy server using Keepalived.
Posted: Wed Jul 12, 2023 1:18 pm
Your enterprise has deployed proxy servers for providing a secure and restrictive browsing sessions by adhering to organization employee internet policy.
Your enterprise complies to have an uninterrupted web experience, for mission-critical work.
However, at times due to various reasons can cause interruptions to your user’s web sessions, reasons such as proxy malfunction, hardware failure or a planned maintenance, etc.
Downtime results in lost revenue, decreased productivity, and damage to your company’s reputation.
If your enterprise works 24/7 and servers a larger number of users, depending on a single proxy will have a single point of failure.
which means if your active proxy server or service fails it will lead to connection failures throughout your organization.
If your enterprise participates in an online transaction, whether it's office purchases, electronic funds transfer, Purchase Order, etc, are carried out over the internet.
if your underlying proxy service goes down, all these transactions will be interrupted effecting your day-to-day business.
And with the increasing dependency to data, IT, and network services, companies are demanding a formal assurance from service providers such as your organization that services would be delivered at the level they expect.
One very common metric used in Service Level Agreements (SLAs) is uptime or availability.
Failure to deliver on the guaranteed uptime would result in financial penalties.
Availability can be measured relative to a system being 100% operational or never failing -- meaning it has no outages. Typically, an availability percentage is calculated as follows:
Availability = (minutes in a month - minutes of downtime) * 100/minutes in a month
What is High Availability?
High availability (HA) refers to a system’s ability to operate continuously without downtime or failure usually by using built in failover mechanisms.
High availability systems are designed to operate without fail even in the case of unexpected event
If one server in the HA cluster fails, a replicated server in another cluster can handle the workload designated for the failed server.
Benefits of HA
High availability (HA) can address a wide range of your problems that can impact the reliability, performance, and availability of proxy services.
High availability is a critical aspect to ensure continuous and reliable operation of your systems, applications, and services.
By addressing your various challenges, high availability solutions aim to minimize or eliminate downtime and provide uninterrupted access to your resources.
What is keepalived
Keepalived is a routing software written in C.
Keepalived monitors services / systems and executes automatic failover to a standby if problems occur.
Keepalived provides frameworks for both load balancing and high availability.
• Uses Virtual Redundancy Routing Protocol (VRRP) to ensure reliable fail-over and thus deliver service High-Availability.
• Uses Linux Virtual Server (IPVS) kernel module, which provides Layer 4 load balancing.
The Keepalived framework monitors the local host for process availability, and network connectivity of remote servers. Typically, Keepalived is setup on all the hosts in the cluster, and configured to communicate with the cluster participants.
The main goal of this project is to provide simple and robust facilities for high-availability to Linux system and Linux based infrastructures.
High-availability using Keepalived is achieved by VRRP (Virtual Router Redundancy Protocol) protocol.
VRRP is a computer networking protocol that provides for automatic assignment of available IP or the shareable IP address to participating hosts, based on the defined parameters.
In order to offer fastest network failure detection, Keepalived implements BFD (Bidirectional Forwarding Detection) protocol.
VRRP state transition can take into account BFD hint to drive fast state transition.
Keepalived frameworks can be used independently or all together to provide resilient infrastructures.
Implementation
Below is the network topology used for given example.
To achieve mentioned objective, proxy servers will have a virtual IP address, shared among the proxy servers.
Shared IP address will initially be assigned to master/active proxy server.
In case of proxy server/service failure the virtual IP will be assigned to the backup/passive proxy server.
Requirements
Keepalived requires an additional IP address which is unused in your network.
This IP address will be used as a virtual IP address for your proxy servers.
Implementing Keepalived with your SafeSquid proxy servers.
Procedure:
The command apt update is used to update the package index files on the system, which contain information about available packages and their versions.
The command apt install keepalived will install the latest version of keepalived package.
The configuration file for Keepalived is located at /etc/keepalived/keepalived.conf.
max_auto_priority to limit the maximum increased automatic priority, (-1 disables the warning message at startup). Omitting the priority sets the maximum value
vrrp_track_process can monitor whether other processes are running.
it uses pgrep to check for the process, 'pgrep safesquid will match safesquid process
vrrp_instance defines an individual instance of the VRRP protocol running on an interface.
state defines the initial state that the instance should start in.
Interface defines the interface that VRRP runs on.
virtual_router_id is the unique identifier for the Virtual Router instance.
priority is the advertised priority which is used to differentiate multiple instances of keepalived running on the same network interface.
The priority specifies the order in which the assigned interface takes over in a failover.
advert_int specifies the frequency that advertisements are sent at (1 second, in this case).
authentication specifies the information necessary for servers participating in VRRP to authenticate with each other.
virtual_ipaddress defines the IP addresses (there can be multiple) that VRRP is responsible for.
server A is considered as master/active proxy server.
and server B is considered as a backup/passive proxy server,
Check your network interface for IP addresses using command or
ServerA
Server B
and Server B is now a master/active proxy server
The virtual IP has been reassigned to backup/passive proxy server
Sever A
Server B
and Server B becomes backup/passive proxy server.
And the virtual IP address from server b has been reassigned to master/active server
Server A
Server B
Your enterprise complies to have an uninterrupted web experience, for mission-critical work.
However, at times due to various reasons can cause interruptions to your user’s web sessions, reasons such as proxy malfunction, hardware failure or a planned maintenance, etc.
Downtime results in lost revenue, decreased productivity, and damage to your company’s reputation.
If your enterprise works 24/7 and servers a larger number of users, depending on a single proxy will have a single point of failure.
which means if your active proxy server or service fails it will lead to connection failures throughout your organization.
If your enterprise participates in an online transaction, whether it's office purchases, electronic funds transfer, Purchase Order, etc, are carried out over the internet.
if your underlying proxy service goes down, all these transactions will be interrupted effecting your day-to-day business.
And with the increasing dependency to data, IT, and network services, companies are demanding a formal assurance from service providers such as your organization that services would be delivered at the level they expect.
One very common metric used in Service Level Agreements (SLAs) is uptime or availability.
Failure to deliver on the guaranteed uptime would result in financial penalties.
Availability can be measured relative to a system being 100% operational or never failing -- meaning it has no outages. Typically, an availability percentage is calculated as follows:
Availability = (minutes in a month - minutes of downtime) * 100/minutes in a month
- Picture3.png (32.7 KiB) Viewed 616 times
High availability (HA) refers to a system’s ability to operate continuously without downtime or failure usually by using built in failover mechanisms.
High availability systems are designed to operate without fail even in the case of unexpected event
If one server in the HA cluster fails, a replicated server in another cluster can handle the workload designated for the failed server.
Benefits of HA
High availability (HA) can address a wide range of your problems that can impact the reliability, performance, and availability of proxy services.
High availability is a critical aspect to ensure continuous and reliable operation of your systems, applications, and services.
By addressing your various challenges, high availability solutions aim to minimize or eliminate downtime and provide uninterrupted access to your resources.
What is keepalived
Keepalived is a routing software written in C.
Keepalived monitors services / systems and executes automatic failover to a standby if problems occur.
Keepalived provides frameworks for both load balancing and high availability.
• Uses Virtual Redundancy Routing Protocol (VRRP) to ensure reliable fail-over and thus deliver service High-Availability.
• Uses Linux Virtual Server (IPVS) kernel module, which provides Layer 4 load balancing.
The Keepalived framework monitors the local host for process availability, and network connectivity of remote servers. Typically, Keepalived is setup on all the hosts in the cluster, and configured to communicate with the cluster participants.
The main goal of this project is to provide simple and robust facilities for high-availability to Linux system and Linux based infrastructures.
High-availability using Keepalived is achieved by VRRP (Virtual Router Redundancy Protocol) protocol.
VRRP is a computer networking protocol that provides for automatic assignment of available IP or the shareable IP address to participating hosts, based on the defined parameters.
In order to offer fastest network failure detection, Keepalived implements BFD (Bidirectional Forwarding Detection) protocol.
VRRP state transition can take into account BFD hint to drive fast state transition.
Keepalived frameworks can be used independently or all together to provide resilient infrastructures.
Implementation
Below is the network topology used for given example.
- Picture1.png (17.39 KiB) Viewed 616 times
Shared IP address will initially be assigned to master/active proxy server.
- Picture4.png (10.74 KiB) Viewed 616 times
- Picture2.png (15.34 KiB) Viewed 616 times
Keepalived requires an additional IP address which is unused in your network.
This IP address will be used as a virtual IP address for your proxy servers.
Implementing Keepalived with your SafeSquid proxy servers.
Procedure:
- Install Keepalived
Code: Select all
apt update && apt install keepalived -y The command apt install keepalived will install the latest version of keepalived package.
- Slide1.PNG (258.68 KiB) Viewed 616 times
- Create/ Edit the keapalived.conf file
The configuration file for Keepalived is located at /etc/keepalived/keepalived.conf.
Code: Select all
vim /etc/keepalived/keepalived.conf- Slide2.PNG (11.95 KiB) Viewed 616 times
- Example configuration for server A (Master/Active Server):
Code: Select all
#Master Server
#The Global Definitions section
global_defs {
#To limit the maximum increased automatic priority, [<-1 to 99>], -1 disables the warning message at startup.
max_auto_priority -1
}
#Tracking a process on the server to determine the health of the host
vrrp_track_process safesquid {
#track process safesquid using pgrep
process safesquid
#add's to overall priority of vrrp_instance, <-254..254>
weight 10
}
#The vrrp_instance line details the virtual interface configuration for the VRRP service daemon, which creates virtual IP instances.
vrrp_instance SAFESQUID_HA {
#state tracks the state of the specified vrrp instance: MASTER/BACKUP
state MASTER
#Interface for sending and receiving VRRP packets. It is also the interface to configure the virtual IP address
interface enp1s0
#Used to differentiate multiple instances of vrrpd, arbitrary unique number from 1 to 255
virtual_router_id 51
#For electing MASTER, highest priority wins. [1-255]
priority 245
#VRRP advertisment interval in seconds
advert_int 1
#VRRP packets are transmitted using unicast from the current server
unicast_src_ip 192.168.2.138
#VRRP packets are sent using unicast to the peer
unicast_peer {
192.168.2.130
}
#For servers participating in VRRP to authenticate with each other; auth_type and auth_pass should be similar on both of the servers.
authentication {
auth_type PASS
auth_pass SsQu1d
}
#Virtual/floating IP address which will be shared among the participating host, this IP address should be an unused IP address from your network space.
virtual_ipaddress {
192.168.255.100/16
}
#process to monitor
track_process {
safesquid
}
}
- Example configuration for server B (Backup/Passive Server):
Code: Select all
#Backup server
#The Global Definitions section
global_defs {
#To limit the maximum increased automatic priority, [<-1 to 99>], -1 disables the warning message at startup.
max_auto_priority -1
}
#Tracking a process on the server to determine the health of the host
vrrp_track_process safesquid {
#track process safesquid using pgrep
process safesquid
#add's to overall priority of vrrp_instance, <-254..254>
weight 10
}
#The vrrp_instance line details the virtual interface configuration for the VRRP service daemon, which creates virtual IP instances.
vrrp_instance SAFESQUID_HA {
#state tracks the state of the specified vrrp instance: MASTER/BACKUP
state BACKUP
#Interface for sending and receiving VRRP packets. It is also the interface to configure the virtual IP address
interface ens160
#Used to differentiate multiple instances of vrrpd, arbitrary unique number from 1 to 255
virtual_router_id 51
#For electing MASTER, highest priority wins. [1-255]
priority 243
#VRRP advertisment interval in seconds
advert_int 1
#VRRP packets are transmitted using unicast from the current server
unicast_src_ip 192.168.2.130
#VRRP packets are sent using unicast to the peer
unicast_peer {
192.168.2.138
}
#For servers participating in VRRP to authenticate with each other; auth_type and auth_pass should be similar on both of the servers.
authentication {
auth_type PASS
auth_pass SsQu1d
}
#Virtual/floating IP address which will be shared among the participating host, this IP address should be an unused IP address from your network space.
virtual_ipaddress {
192.168.255.100/16
}
#process to monitor
track_process {
safesquid
}
}
- Explaining the keepalived configuration file.
max_auto_priority to limit the maximum increased automatic priority, (-1 disables the warning message at startup). Omitting the priority sets the maximum value
vrrp_track_process can monitor whether other processes are running.
it uses pgrep to check for the process, 'pgrep safesquid will match safesquid process
vrrp_instance defines an individual instance of the VRRP protocol running on an interface.
state defines the initial state that the instance should start in.
Interface defines the interface that VRRP runs on.
virtual_router_id is the unique identifier for the Virtual Router instance.
priority is the advertised priority which is used to differentiate multiple instances of keepalived running on the same network interface.
The priority specifies the order in which the assigned interface takes over in a failover.
advert_int specifies the frequency that advertisements are sent at (1 second, in this case).
authentication specifies the information necessary for servers participating in VRRP to authenticate with each other.
virtual_ipaddress defines the IP addresses (there can be multiple) that VRRP is responsible for.
- Using systemctl to enable keepalived on boot and start the services.
Code: Select all
systemctl enable keepalived.service && systemctl start keepalived.service- Slide3.PNG (52.23 KiB) Viewed 616 times
- Validating the functioning of keepalived using log file.
server A is considered as master/active proxy server.
- Slide4.PNG (273.04 KiB) Viewed 616 times
- Slide6.PNG (58.76 KiB) Viewed 616 times
- Check your network interfaces on your host’s machine.
Check your network interface for IP addresses using command
Code: Select all
ip aCode: Select all
ifconfig- Slide5.PNG (135.46 KiB) Viewed 616 times
- Slide7.PNG (109.33 KiB) Viewed 616 times
- When SafeSquid proxy service on server A is offline/down.
- Slide8.PNG (110.6 KiB) Viewed 616 times
- Slide10.PNG (136.4 KiB) Viewed 616 times
Sever A
- Slide9.PNG (116.28 KiB) Viewed 616 times
- Slide11.PNG (124.65 KiB) Viewed 616 times
- SafeSquid proxy service on server A is back online/up.
- Slide12.PNG (100.15 KiB) Viewed 616 times
- slide14.png (11.62 KiB) Viewed 616 times
Server A
- Slide13.PNG (130.34 KiB) Viewed 616 times
- slide15.png (17.12 KiB) Viewed 616 times