Ressources numériques en sciences humaines et sociales OpenEdition Nos plateformes OpenEdition Books OpenEdition Journals Hypothèses Calenda Bibliothèques OpenEdition Freemium Suivez-nous

KTCPVS – LVSKB

KTCPVS stands for Kernel TCP Virtual Server. It implements application-level load balancing inside the Linux kernel, so called Layer-7 switching. Since the overhead of layer-7 switching in user-space is very high, it is good to implement it inside the kernel in order to avoid the overhead of context switching and memory copying between user-space and kernel-space. Although the scalability of KTCPVS is lower than that of IPVS (IP Virtual Server), it is flexible, because the content of request is known before the request is redirected to one server.

LVS NAT + Keepalived HOWTO

"The main goal of the keepalived project is to add a strong & robust keepalive facility to the Linux Virtual Server project. This project is written in C with multilayer TCP/IP stack checks. Keepalived implements a framework based on three family checks : Layer3, Layer4 & Layer5. This framework gives the daemon the ability of checking a LVS server pool states. When one of the server of the LVS server pool is down, keepalived informs the linux kernel via a setsockopt call to remove this server entrie from the LVS topology. In addition keepalived implements a VRRPv2 stack to handle director failover. So in short keepalived is a userspace daemon for LVS cluster nodes healthchecks and LVS directors failover.

Failover and loadbalancer using keepalived (LVS) on two machines

Failover and loadbalancer using keepalived (LVS) on two machines
January 26th, 2009
28 comments

In this scenario, we have two machines and try to make the most of available resources. Each of the node will play the role of realserver, it will provide a service such as a web or a mail server. At the same time, one of the machines will loadbalance the requests to itself and to its neighbor. The node that is responsible of the loadbalancing owns the VIP. Every client connects to it transparently thanks to the VIP. The other node is also able to take over the VIP if it detects that current master failed but in nominal case only process requests forwarded by the loadbalancer.