Ver el código de «Alta dispoñibilidade en servidores Web»

Sempre que teñamos un servidor web replicado en varios equipos, podemos engadir varios rexistros tipo A apuntando aos diferentes enderezos IP, para que poidan respostar as peticións a unha URL referida a un host virtual.

Exemplo:

:Podemos ter o host virtual "exemplo.com" replicado nos equipos con enderezo 192.168.0.100 e 192.168.0.101. Se configuramos no servidor DNS dous rexistros tipo A
:{|
<syntaxhighlight lang="text">
 sitio.lan A 192.168.0.100
 sitio.lan A 192.168.0.101
</syntaxhighlight>
|} 
:conseguiremos que as peticións HTTP sexan atendidas por cadanseu equipo de forma alternada.  Se queremos, que as peticións estén balanceadas nun 50%, podemos engadir a maiores rexistros SRV
:{|
<syntaxhighlight lang="text">
 sitio.lan A 192.168.0.100
 sitio.lan A 192.168.0.101
_http._tcp SRV 10 60 80 sitio.lan
_http._tcp SRV 10 40 80 sitio.lan
</syntaxhighlight>
|}

Pero, nunca conseguiremos que se un equipo está caido, os demáis asuman as peticións HTTP, senón que os clientes seguirán esperando a que este responda.

Para solucionar este tipo de problemas, idearonse os '''Proxy'''.

==Proxy==
Un ''Proxy'' é unha porta de acceso para os usuarios, que actúa de intermediario entre estes e os servidores web que atenden as peticións HTTP. Os usuarios configuran o seu proxy nos seus axustes do navegador, e todas as peticións de HTTP son remitidas a ese proxy que se encargará de solicitar a petición HTTP ao servidor web correspondente, e retransmitirlla ao usuario. Podemos usar proxies para:
*acelerar o acceso a Web, facendo caché de páxinas, así as páxinas moi concorridas non teñen que ser descargadas de todas as veces.
*habilitar acceso controlado a web detrás dun firewall
*filtrar ou transformar condito web

Un '''Proxy inverso''' é unha porta de acceso para os servidores, e permite  que un servidor web provea contido para outro de forma transparente. Mediante proxies inversos, podemos aumentar o rendemento web, facendo caché de peticións HTTP, e tamén para permitir replicara servidores web facendo balanceo de carga, ou protexendo a outros que poden ser vulnerables. Pero o uso máis habitual é habilitar acceso controloado desde a Web a servidores que están detrás dun firewall.

[[Archivo:Reverse proxy.png|500px|centro|Proxy inverso]]

==Proxies (inversos) con Apache==
Os módulos de Apache que permiten o uso de proxies inversos, son:
*'''[http://httpd.apache.org/docs/current/mod/mod_proxy.html mod_proxy]''' para todo tipo de proxies (módulo base).
*'''[http://httpd.apache.org/docs/current/mod/mod_proxy_http.html mod_proxy_http]''' para proxies inversos co protocolo HTTP (require que ''mod_proxy'' esté activo.

Unha vez activados os dous módulos, xa podemos empregar as directivas '''[http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass ProxyPass]''' e '''[http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassreverse ProxyPassReverse]'''.

Vémolo cun exemplo:
<syntaxhighlight lang="apache">
<VirtualHost *:80>
ServerName www.example.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://foo.example.com/  #Ou enderezo IP
ProxyPassReverse / http://foo.example.com/ #Ou enderezo IP
</VirtualHost>
</syntaxhighlight>
Neste caso, sempre que accedamos a ''<nowiki>http://www.example.com/</nowiki>'' accederemos realmente a ''<nowiki>http://foo.example.com/</nowiki>''
e no exemplo
<syntaxhighlight lang="apache">
<VirtualHost *:80>
ServerName www.example.com
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.com/bar
</VirtualHost>
</syntaxhighlight>
sempre que accedamos a ''<nowiki>http://www.example.com/foo</nowiki>'' accederemos realmente a ''<nowiki>http://foo.example.com/bar</nowiki>''

A directiva ''ProxyRequests Off'' evita que o front-end sea empregado como proxy, é dicir, que os usuarios poidan saltar ao front-end y de ahí a cualquera outro enderezo. É moi importante deixalo deshabilitado para evitar problemas de seguridade ou incluso legais.

A directiva ''ProxyPreserveHost On'' permite que o salto do servidor de front-end ao de back-end sea transparente para o usuario. Se non estivera habilitada, o usuario dirixiríase a <nowiki>http://www.example.com</nowiki> pero inmediatamente vería como o enderezo cambia a <nowiki>http://foo.example.com</nowiki>. Ademáis, como neste suposto o servidor de back-end non é visible desde Internet o usuario vería un erro.

Por último, as directivas ''ProxyPass'' e ''ProxyPassReverse'' xestionan o salto e a volta do servidor de front-end ao de back-end.

===Proxy apache balanceado===
Se ademáis queremos que o proxy faga balanceo de carga entre varios servidores, entón teremos que habilitar o módulo '''[http://httpd.apache.org/docs/current/mod/mod_proxy_balancer.html mod_proxy_balancer]''' e tamén algún balanceador como pode ser '''[http://httpd.apache.org/docs/current/mod/mod_lbmethod_byrequests.html mod_lbmethod_byrequests]'''

O seguinte exemplo, amosa un proxy balanceado
<syntaxhighlight lang="apache">
ServerName www.example.com
ProxyRequests Off
ProxyPreserveHost On
<Proxy balancer://mycluster>
    BalancerMember http://eq1.example.com  
    #Ou enderezo IP
    BalancerMember http://eq2.example.com  
    #Ou enderezo IP
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</syntaxhighlight>
Neste caso, sempre que se acceda a example.com, as peticións serán repartidas entre eq1.example.com e eq2.example.com

Existen multitude máis de configuracións, para traballar con sesións e máis características. Recoméndase consultar a documentación oficial.

==Varnish==
Varnish é un proxy HTTP inverso, tamén coñecido como acelerador web ou acelerador HTTP. Almacena ficheiros e fragmentos de arquivos na memoria, permitindo que poidan ser servidos moi rápido. 

Pero a súa vez tamén é flexible, e sinxelo de configurar. É código aberto e software libre, con desenrolo público e licencia BSD.

O único punto negativo é que non soporta HTTP

===Instalación===
Varnish ven de serie nos repositorios de Ubuntu/Debian, pero a versión que se instala está un pouco desactualizada. Imos instalalo a partires dos repositorios.
'''Debian'''
<syntaxhighlight lang="bash">
apt-get install debian-archive-keyring curl gnupg apt-transport-https 
curl -L https://packagecloud.io/varnishcache/varnish60lts/gpgkey | apt-key add -
</syntaxhighlight>
'''Debian'''
<syntaxhighlight lang="bash">
echo 'deb https://packagecloud.io/varnishcache/varnish60lts/debian/ buster main' | tee /etc/apt/sources.list.d/varnish.list >/dev/null
apt-get update
apt-get install varnish
</syntaxhighlight>
'''Ubuntu 20.04'''
<syntaxhighlight lang="bash">

echo 'deb https://packagecloud.io/varnishcache/varnish60lts/ubuntu/ focal main' | tee /etc/apt/sources.list.d/varnish.list >/dev/null
apt-get update
apt-get install varnish
</syntaxhighlight>

===Configuración===
Varnish pode ser configurado para traballar en modo comando, ou mediante ficheiros de configuración (Ficheiros VCL). Sempre que se faga un cambio, é necesario reiniciar o servidor.

'''Equipos que funcionan con ''init.d'' '''
<syntaxhighlight lang="bash">
service varnish restart
</syntaxhighlight>

'''Equipos que funcionan con ''systemd'' '''
<syntaxhighlight lang="bash">
systemctl restart varnish.service
</syntaxhighlight>

Os ficheiros de configuración principais son:
*''/etc/varnish/default.vcl'': Ficheiro VCL principal. Contén toda a configuración do servidor.

Na configuración do ficheiro VCL, temos xa pre-configurado un servidor proxy, cara o propio equipo local, no porto 8080. Na terminoloxía varnish, un '''backend''' é un equipo cun servidor web do que este servidor varnish é proxy inverso.

<syntaxhighlight lang="text">
backend default {
    .host = "127.0.0.1";
    .port = "8080";
}
</syntaxhighlight>
Con esto, teremos definido o enderezo IP e o porto do equipo remoto. Falta o porto de escoita de varnish, que definimos de diferentes maneiras según o equipo funcione con ''init.d'' ou ''systemd'' en ''/etc/default/varnish'' ou ''/lib/systemd/system/varnish.service''

Para ''init.d'' '''Debian/Ubuntu (legacy)'''
<syntaxhighlight lang="bash">
#/etc/default/varnish
DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"
</syntaxhighlight>

Para ''systemd'' '''Debian (v8+) / Ubuntu (v15.04+)'''
<syntaxhighlight lang="bash" highlight="25,26">
#/lib/systemd/system/varnish.service
[Unit]
Description=Varnish Cache, a high-performance HTTP accelerator

[Service]
Type=forking

# Maximum number of open files (for ulimit -n)
LimitNOFILE=131072

# Locked shared memory (for ulimit -l)
# Default log size is 82MB + header
LimitMEMLOCK=82000

# On systemd >= 228 enable this to avoid "fork failed" on reload.
#TasksMax=infinity

# Maximum size of the corefile.
LimitCORE=infinity

# Set WARMUP_TIME to force a delay in reload-vcl between vcl.load and vcl.use
# This is useful when backend probe definitions need some time before declaring
# configured backends healthy, to avoid routing traffic to a non-healthy backend.
#WARMUP_TIME=0

ExecStart=/usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
ExecReload=/usr/share/varnish/reload-vcl

[Install]
WantedBy=multi-user.target
</syntaxhighlight>
No caso de que o equipo traballe con systemd, hai que activar o servizo para que arranque ao iniciar o equipo.
<syntaxhighlight lang="bash">
systemctl daemon-reload
systemctl restart varnish.service
</syntaxhighlight>

===Multiple Host virtuais===
Tamén podemos definir varios backend

<syntaxhighlight lang="text">
#/etc/varnish/default.vcl
backend foo {
    .host = "192.168.0.100";
    .port = "8080";
}

backend bar {
    .host = "192.168.0.101";
    .port = "8080";
}
sub vcl_recv {
    if (req.http.host ~ "foo.com") {
        set req.backend_hint = foo;
    } elsif (req.http.host ~ "bar.com") {
        set req.backend_hint = bar;
    }
}
</syntaxhighlight>

===Balanceo de carga===
Tamén podemos facer balanceo de carga
<syntaxhighlight lang="text">
#/etc/varnish/default.vcl


backend server1 {
    .host = "server1.example.com";
    .probe = {
        .url = "/test.html";
        .timeout = 1s;
        .interval = 5s;
        .window = 5;
        .threshold = 3;
    }
}

backend server2 {
    .host = "server2.example.com";
    .probe = {
        .url = "/test.html";
        .timeout = 1s;
        .interval = 5s;
        .window = 5;
        .threshold = 3;
    }
}
import directors;
sub vcl_init {
    new vdir = directors.round_robin();
    vdir.add_backend(server1);
    vdir.add_backend(server2);
}
</syntaxhighlight>
Se so temos un backend default, asignamoslle todas as peticións
<syntaxhighlight lang="text">
sub vcl_recv {
    # send all traffic to the bar director:
    set req.backend_hint = vdir.backend();
}
</syntaxhighlight>

E se temos máis dun "Virtual Host", asignamoslle o backend correcto dependendo do nome do servidor.

<syntaxhighlight lang="text" >
sub vcl_recv {
    if (req.http.host ~ "foo.com") {
        set req.backend_hint = foo;
    } elsif (req.http.host ~ "bar.com") {
        set req.backend_hint = vdir.backend();
    }
}
</syntaxhighlight>

Neste exemplo, conseguimos que a carga se reparta entre os dous servidores seguindo o algoritmo round-robin, anque debido a que garda os datos na caché, é probable que non poidamos testear como reparte as conexións. Simplemente veremos que atende as peticións pero que por un longo periodo de tempo, non lle fai peticións aos servidores "backend".

Se queremos eliminar a opción de manexo de sesións "''pegañentas''" podemos facelo seguindo esta [https://info.varnish-software.com/blog/sticky-session-with-cookies guía]:


Podemos ver o estado de "saúde" dos servidores backend co comando 

<syntaxhighlight lang="text" >
varnishlog -g raw
</syntaxhighlight>

==Nginx==
Nginx é un servidor HTTP caché lixeiro que tamén se pode empregar como proxy inverso. O máis usual é configuralo como proxy inverso de HTTPS.

Nginx é o mellor servidor web para servir arquivos estáticos, e ademais faio tendo un consumo de memoria considerablemente menor que Apache, dado que non precisa crear un proceso ou fío novo para cada pedido que lle chega, e tampouco necesitar analizar todos os directorios dun sitio buscando arquivos '''.htaccess''', xa que carga as regras de Rewrite directamente desde a súa configuración.

O primeiro paso é instalar o nginx
<syntaxhighlight lang="bash">
apt-get install nginx
</syntaxhighlight>

O seguinte paso será cambiar os portos de escoita de Apache

E por último, cremos un novo virtual host para nginx. Por exemplo '''/etc/nginx/sites-available/exemplo.com'''
<syntaxhighlight lang="bash">
#/etc/nginx/sites-available/exemplo.com
server {
    listen 80;
    server_name  www.exemplo.com;
    location / {       
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://eq1.exemplo.com:8080;  #Tamen podemos poñer o enderezo IP
    }
}
</syntaxhighlight>

Tamén o podemos facer con HTTPS:
<syntaxhighlight lang="bash">
#/etc/nginx/sites-available/exemplo.com

server {

    listen 443 default_server;
    server_name www.example.com;

    ssl on;
    ssl_certificate /usr/local/nginx/conf/server.pem;
    ssl_certificate_key /usr/local/nginx/conf/server.key;
    ssl_session_cache shared:SSL:10m;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://eq1.exemplo.com:8080;
    }

}
</syntaxhighlight>
===Balanceador de carga===
Se queremos facer un balanceador de carga con ''nginx'' podemos empregar unha configuración similar á seguinte:
<syntaxhighlight lang="bash">
    upstream myapp1 {
        server srv1.example.com; #Tamen podemos poñer o enderezo IP directamente.
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }

</syntaxhighlight>

Se non se expresa ningún método de balanceo, enténdese que por defecto se emprega ''round-robin''

Tamen podemos repartir a carga con pesos específicos:

<syntaxhighlight lang="bash">
    upstream myapp1 {
        server srv1.example.com weight=3; 
        server srv2.example.com;
        server srv3.example.com;
    }
</syntaxhighlight>
asignala ao servidor con menos conexións

<syntaxhighlight lang="bash">
    upstream myapp1 {
        least_conn;
        server srv1.example.com; 
        server srv2.example.com;
        server srv3.example.com;
    }
</syntaxhighlight>
E tamén podemos facer que as sesións sexan persistentes. Un mesmo cliente, namentres a sesión permaneza activa, sempre será atendido por un mesmo servidor backend. Enténdese que a sesión é deste xeito pegañenta.

<syntaxhighlight lang="bash">
    upstream myapp1 {
        ip_hash;
        server srv1.example.com; 
        server srv2.example.com;
        server srv3.example.com;
    }
</syntaxhighlight>

==Balanceador de carga de nivel de aplicación HAProxy==
HAProxy é un balanceador de carga específico de HTTP e HTTPS de nivel de aplicación (L7), anque tamén pode traballar a nivel de rede (L4). Traballar a nivel de aplicación abre novas posibilidades ó poder acceder á capa máis próxima ó usuario. Centrándonos na web, poderemos tomar decisións en funcións das cabeceiras http dos paquetes, insertar cookies, marcar paquetes, ...; e polo tanto, poderemos reenviar as solicitudes dos clientes a diferentes servidores en base ó contido da petición do cliente. Un dos usos máis interesantes é a posibilidade de correr diferentes aplicacións en diferentes servidores reais pero accesibles baixo o mesmo nome de dominio e porto. Entre outras cousas,tamén permite establecer os certificados para HTTP no frontend, permitindo que as comunicacións entre cliente e proxy, vaian encrintadas con HTTPS e entre o frontend e backend mediante HTTP.
[[Archivo:HAproxy.png|200px|sinmarco|centro]]
===Instalación HA Proxy===
O primeiro paso para instalr o HAProxy é engadir os repositorios:
'''Debian 10'''
<syntaxhighlight lang="bash">
apt update
apt install curl gnupg debian-archive-keyring apt-transport-https

curl https://haproxy.debian.net/bernat.debian.org.gpg | apt-key add -
echo deb http://haproxy.debian.net buster-backports-2.3 main | \
      tee /etc/apt/sources.list.d/haproxy.list
apt update
apt install haproxy=2.3.\*
</syntaxhighlight>
'''Ubuntu 18.04'''
<syntaxhighlight lang="bash">
apt-get install software-properties-common
add-apt-repository ppa:vbernat/haproxy-2.1
apt-get update
apt-get install haproxy
</syntaxhighlight>

===Configuración===
Teremos os ficheiros de configuración en ''/etc/haproxy/''

Para configurar HAproxy hai tres elementos fundamentais:

*ACLs (Acces Control List): permiten comprobar algunha condición e en base ó resultado realizarase unha acción.
*Seccións Backend: definen un conxunto de servidores que recibirán as solicitudes reenviadas por HAProxy.
*Seccións Frontend: definen como se reenvían as solicitudes ós backends.

<syntaxhighlight lang="bash">
frontend sitio_http
   bind 192.168.0.20:80
   acl host_www.proba.lan hdr(host) -i proba.lan
   acl host_www.proba.lan hdr(host) -i www.proba.lan
   use_backend proba_lan_back if host_www.proba.lan


backend proba_lan_back
   balance roundrobin
   server server01 192.168.1.41:80 check
   server server02 192.168.1.42:80 check
</syntaxhighlight>

No caso de querer establecer pesos entre os distintos backend, introducímolos da seguinte maneira, tendo en conta que o peso é un número entre 0 e 256
<syntaxhighlight lang="bash">
frontend sitio_http
   bind 192.168.0.20:80
   acl host_www.proba.lan hdr(host) -i proba.lan
   acl host_www.proba.lan hdr(host) -i www.proba.lan
   use_backend proba_lan_back if host_www.proba.lan


backend proba_lan_back
   balance roundrobin
   server server01 192.168.1.41:80 check weight 22  
   server server02 192.168.1.42:80 check weight 40 
</syntaxhighlight>




Unha vez feito isto e reinciado o servizo haproxy, aparecerán no ficheiro de log (''/var/log/haproxy.log'') todas as peticións que se fagan ao balanceador HAProxy.

===HAProxy e HTTPS===
Para configurar HAProxy con HTTPS necesitaremos que o certificado do sitio e a chave privada estén no mesmo ficheiro con extensión '''.pem'''.

So queda engadir unha sección frontend para empregar HTTPS:
<syntaxhighlight lang="bash">
frontend sitio_https
   bind 192.168.57.40:443 ssl crt /etc/ssl/private/proba.lan.pem
   acl host_www.proba.lan hdr(host) -i proba.lan
   acl host_www.proba.lan hdr(host) -i www.proba.lan
   use_backend proba_lan_back if host_www.proba.lan
</syntaxhighlight>

==Proxy e Balanceador a nivel de rede con Linux Virtual Server (LVS)==
O Linux Virtual Server é un servidor altamente scalable e altamente dispoñíbel construído formando un grupo de servidores reais ou cluster. A arquitectura do cluster de servidores é plenamente transparente para os usuarios finais. Estes, interactúan co sistema de cluster como se era só fose un so. Sirva coma exemplo a seguinte figura.

[[Archivo:Linux Virtual Server.png|500px|centro|Linux virtual Server]]

Os servidores reais e o balanceador de carga poden estar intercontectados mediante unha LAN de alta velocidade ou dispersos nunha WAN. Os balanceadores poden atender peticións para diferentes servidores e aparentar que funciona coma un servizo único nun único enderezo IP. Para atender as peticións pode empregarse un balanceo a nivel de rede ou a nivel de aplicación. A escalabilidade do sistema consíguese de xeito transparente engadindo ou quitando nodos no cluster. A alta dispoñibilidade conseguese detectando a caída de nodos e reconfigurando o sistea de xeito apropiado.

O [http://www.linuxvirtualserver.org Linux Virtual Server Project] (LVS) implementa balanceo a nivel 4 (tcp/udp) no kernel de Linux. LVS corre sobre Linux pero é capaz de balancear conexións procedentes de usuarios finais sobre calquera sistema operativo a servidores reais correndo en calquera sistema operativo. Mentres as conexións sexan tcp ou udp, LVS pode usarse. Esto significa nin máis nin menos, que se temos un sistema Linux temos a nosa disposición un balanceador.

Neste sistema destacamos dous compoñentes pola súa función:

*'''IPVS''' (IP Virtual Server): é  o compoñente integrado no kernel de Linux que se encarga do balanceo de carga.
*'''ldirectord''': é un servizo encargado de monitorar os servidores reais dun balanceador e no caso de fallo dalgún deles, encárgase de reconfigurar dinámicamente IPVS.
Nun sistema baseado en LVS adoitase a usar a seguinte terminoloxía:

*'''Linux Director''': equipo correndo Linux con LVS instalado que recibe paquetes dende usuarios finais e os reenvía cara ós servidores reais.
*'''End User''': equipo que orixina a conexión.
*'''Real Server''': equipo final que corre algún servizo tipo servidor web.
*'''Cliente IP Address (CIP)''': o enderezo IP do cliente que orixina a conexión.
*'''Virtual IP Address (VIP)''': o enderezo IP asignado a un servizo que xestiona o director.
*'''Real IP Address (RIP)''': o enderezo IP dun Real Server.
*'''Director IP Address (DIP)''': o enderezo IP do director na rede DRIP.

[[Archivo:Linux Virtual Server arquitectura.png|500px|centro|Esquema LVS]]

LVS ten varias formas diferentes de reenviar paquetes cara ós servidores reais sendo as principais:

*'''LVS Network Address Translations (LVS-NAT)''': Os paquetes recíbense dos usuarios finais e os enderezo IP/porto destino cámbianse polos do servidor real seleccionado. Os paquetes de resposta pasan a través do director e volven modificarse para que o usuario final reciba unha resposta desde a orixe esperada. Debido ó traballo a desempeñar polo balanceadore e á súa ubicación; este pode converterse nun problema, debido a carga de CPU que supón realizar o NAT e o ancho de banda real das nosas interfaces de rede; xa que, polo balanceador van pasar tanto as peticións cara ós servidores como as respostas cara ós clientes.
[[Archivo:Linux Virtual Server NAT.png|500px|centro|LVS NAT]]
:Nun caso práctico teriamos o seguinte:
[[Archivo:Linux Virtual Server NAT Exemplo.png|300px|centro|LVS NAT]]

*'''LVS Direct Routing (LVS-DR)''': Os paquetes dos usuarios finais reenvíanse directamente cara ó servidor real seleccionado sen modificar a IP (polo tanto os servidores reais deben configurarse para aceptar paquetes con destino á VIP). Os servidores reais responden directamente ós usuarios finais, polo que o director queda liberado desa función aforrándose CPU e ancho de banda.
[[Archivo:Linux Virtual Server DR.png|500px|centro|LVS Direct Routing]]
:Nun caso práctico teriamos o seguinte:
[[Archivo:Linux Virtual Server DR Exemplo.png|300px|centro|LVS Direct Routing]]

*'''LVS IP-IP Encapsulation (LVS-Tunneling)''': é semellante ó LVS-DR, pero os servidores reais poden estar en redes diferentes (mesmo en localizacións xeográficas diferentes), polo que os paquetes encapsúlanse dentro de paquetes IP no canto de tramas Ethernet.
[[Archivo:Linux Virtual Server DR.png|500px|centro|LVS Tunneling]]
:Nun caso práctico teriamos o seguinte:
[[Archivo:Linux Virtual Server Tunneling Exemplo.png|500px|centro|LVS Tunneling]]
===Implementación de LVS e NAT===
Partiremos do modo de funcionamento de LVS - NAT, na que o equipo frontend, tamén fará de router dos servidores reais ou equipos backend.
[[Archivo:Linux Virtual Server NAT Exemplo.png|300px|centro|LVS NAT]]

Para instalar ldirectord
<syntaxhighlight lang="bash">
apt-get install ldirectord
</syntaxhighlight>

Cando un usuario accede ó servizo proporcionado polo cluster, o paquete da solicitude vai destinado enderezo IP Virtual (VIP) e chega ao interface WAN do balanceador. O balanceador examina o enderezo IP/porto destino; e no caso de coincidir cun servizo configurado, procede a escoller un dos servidores reais e reescribir o enderezo IP/porto destino polos correspondentes valores asociados ó servidor real escollido. Esta conexión métese nunha táboa de conexións para facer o seu seguimento. Cando paquete de resposta procedente do servidor real chega ó balanceador, reescribirase o enderezo IP/porto orixe reemprazando os datos do servidor real polos do VIP.

O equipo LVS-NAT ademais de xestionar a reescritura dos paquetes ten que enrutalos; polo tanto, hai que activar o enrutamento IP asignando á variable do sistema ''net.ipv4.ip_forward''  o valor 1. Para asignarlle o valor 1 e facer o cambio persistente, resistinto polo tanto reinicios da máquina, editaremos o arquivo de configuración /etc/sysctl.conf e descomentados a liña correspodente:
<syntaxhighlight lang="bash">
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
</syntaxhighlight>

E para aplicar os cambios sen reiniciar
<syntaxhighlight lang="bash">
sysctl -p
</syntaxhighlight>

A continuación configuraremos ''ldirectord'', editando o arquivo '''/etc/ldirectord.cf'''. As opcións de configuración poden consultarse nas páxinas de manual de ''ldirectord'' e ''ipvsadm'':
====ldirectord como Proxy====
Configuración común:

<syntaxhighlight lang="bash">
checktimeout=3
checkinterval=5
failurecount=3
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
cleanstop=yes
</syntaxhighlight>

Configuración do proxy
<syntaxhighlight lang="bash">
virtual=172.17.60.207:80
    real=192.168.6.4:80 masq  
    protocol=tcp
    scheduler=rr
    # monitorización do servidor real
    service=http
    request="test.html"
    receive="OK"
</syntaxhighlight>

Como podemos comprobar, para saber se o servidor real está funcionando, realiza a descarga periódica do arquivo "test.html" esperando que como resposta apareza "OK" cada 5 segundos. Ao terceiro fallo, márcao como "non activo"

Reiniciamos o servizo ''ldirectord'':
<syntaxhighlight lang="bash">
service ldirectord restart
</syntaxhighlight>
Podemos comprobar no ficheiro de log indicado, que se consegui conectar co equipo remoto.

====ldirectord como Balanceador====
Podemos configurar o balanceador co número de servidores que queiramos empregando o algoritmo "round robin" para repartir a carga, e adicionalmente cun servidor "fallback" ao que reenviar os paquetes no caso de que non esté activo ningún dos servidores reais.
<syntaxhighlight lang="bash" highlight="2,3,4,6">
virtual=172.17.60.207:80
    real=192.168.6.4:80 masq  
    real=192.168.6.5:80 masq  
    fallback=192.168.6.100:80 masq
    protocol=tcp
    scheduler=rr
    # monitorización do servidor real
    service=http
    request="test.html"
    receive="OK"
</syntaxhighlight>

Tamén podemos asignar pesos á hora de repartir a carga:
<syntaxhighlight lang="bash" highlight="2,3,4,5,7">
virtual=172.17.60.207:80
    real=192.168.6.4:80 masq 4 
    real=192.168.6.5:80 masq 2 
    real=192.168.6.5:80 masq 1 
    fallback=192.168.6.100:80 masq
    protocol=tcp
    scheduler=wrr
    # monitorización do servidor real
    service=http
    request="test.html"
    receive="OK"
</syntaxhighlight>

Despois de facer unhas cantas conexións desde calquera cliente, podemos ver as estatísticas de conexións executando o comando '''ipvsadm -L -n''':
<syntaxhighlight lang="bash">
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port          Forward Weight ActiveConn InActConn
TCP  172.17.60.207:80 rr
  -> 192.168.6.4:80              Masq    1      0          2         
  -> 192.168.6.5:80              Masq    1      0          2         
  -> 192.168.6.6:80              Masq    1      0          2      
</syntaxhighlight>

===Implementaión de LVS e DR===
Partiremos do modo de funcionamento de LVS - DR, na que o equipo frontend, xa non fará de router dos servidores reais ou equipos backend. Neste caso, todos os equipos terán un enderezo virtual común para todos eles.
[[Archivo:Linux Virtual Server DR Exemplo.png|700px|centro|LVS NAT]]
Para poñer ese enderezo común a todos eles (frontend e backends), podemos facelo do seguinte xeito no ficheiro /etc/network/interfaces

<syntaxhighlight lang=bash>
auto eth0:0
iface eth0:0 inet static
    address 172.17.60.201/16
</syntaxhighlight>

A continuación configuramos o ldirectord
<syntaxhighlight lang=bash>
checktimeout=3
checkinterval=5
failurecount=3
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
cleanstop=yes

virtual=172.17.60.201:80
        # servidores reais balanceados en modo round-robin
        real=172.17.60.200:80 gate
        real=172.17.60.199:80 gate
        #    fallback=172.17.60.210:80 gate
        protocol=tcp
        scheduler=rr
        checktype=negotiate
        # monitorización dos servidores reais
        service=http
        request="test.html"
        receive="OK"
</syntaxhighlight>