Siguiente: Conclusion Subir: Linux Virtual Server Anterior: Introduccion
La estructura de VS-NAT implementado, consta de lo siguiente:
Esta configuracion permite atender una mayor cantidad de solicitudes, respecto de una respuesta normal de un servidor standalone.
Para demostrar esto, se utilizo la misma implementacion de un servidor web, en este caso Apache, para todas las maquinas virtuales, obteniendose la siguiente respuesta.
|
|
La maquina virtual utilizada cumple las siguientes caracteristicas:
La maquina real posee:
La idea de tener 6 tarjetas de red, es permitir a cada maquina virtual que pueda administrar una interfaz de red independiente y ademas no usar un switch por software, para asi disminuir la carga de la CPU real; de esta forma se puede.
Ahora que conocemos los tiempo de respuesta promedio por maquina, observamos que no existe mucha diferencia entre 10.000 y 100.000 solicitudes. Eto indica claramente que un sistema es capaz de atender a 60 clientes por segundo, lo que para un sistema de alto rendimiento es bastante malo, por ello implementamos el Servidor virtual.
Considerando la estructura de la figura ![[*]](/usr/share/latex2html/icons/crossref.png){kind=icon}
, la puerta de enlace para nuestros servidores debe ser nuestro balanceador de carga; por ende, debe tener previamente instalado en el kernel el modulo Virtual Server, ipvsadm e iptables. A continuacion se muestra la configuracion del kernel 2.4 para esta implementacion
Networking options --->
[*] Network packet filtering (replaces ipchains)
[*] TCP/IP networking
IP: Netfilter Configuration --->
<M> IP tables support
(required for filtering/masq/NAT)
<M> Full NAT
<M> MASQUERADE target support
IP: Virtual Server Configuration --->
<M> virtual server support (EXPERIMENTAL)
[*] IP virtual server debugging
(12) IPVS connection table size
--- IPVS scheduler
<M> round-robin scheduling
<M> weighted round-robin scheduling
<M> least-connection scheduling scheduling
<M> weighted least-connection scheduling
<M> locality-based least-connection scheduling
<M> locality-based least-connection with
replication scheduling
<M> destination hashing scheduling
<M> source hashing scheduling
--- IPVS application helper
<M> FTP protocol helper
<M> IP tables support (required for filtering/masq/NAT)
<M> limit match support
<M> MAC address match support
<M> netfilter MARK match support
<M> Multiple port match support
<M> TOS match support
<M> Connection state match support
<M> Unclean match support (EXPERIMENTAL)
<M> Owner match support (EXPERIMENTAL)
<M> Packet filtering
<M> REJECT target support
<M> MIRROR target support (EXPERIMENTAL)
<M> Full NAT
<M> MASQUERADE target support
<M> REDIRECT target support
<M> Packet mangling
<M> TOS target support
<M> MARK target support
<M> LOG target support
< > ipchains (2.2-style) support
< > ipfwadm (2.0-style) support
Para no tener problemas con la configuracion de las IP de cada servidores real, es recomendable tener un servidor DHCP para estos; de esta forma, logramos un mayor control sobre los servidores desde el director (balanceador de carga).
Lo primero ha hacer, luego de compilar nuestro kernel2, es utilizar NAT para enrutar nuestros servidores reales, es por ello que ejecutamos
# iptables -t nat -A POSTROUTING -s <ip_real> -j MASQUERADEAhora que tenemos los servidores escondidos, debemos colocar reglas para la atencion a los requerimientos, es decir, como administrar la cola de requerimientos.
En LVS existen distintos tipos de administracion para colas, dependiendo de la estructura de los servidores reales. Dentro de ellas estan:
Para nuestro caso, usaremos weighted round-robin pues nos permite indicar cuanto podremos cargar nuestros servidores con solicitudes, dado que no necesitamos configurar estos.
Necesitamos que los servidores, puedan acceder a la red externa, para ello se debe tener como puerta de enlace la iIP privada del director.
rserver# route add default gw 10.0.100.1
O simplemente se puede utilizar un servidor de DHCP para configurar la puerta de enlace y la direccion de cada servidor
Ahora que el trafico es permitido, desde el servidor real hasta el cliente y del cliente hasta el director, debemos realizar el balance de carga, para ello usa administracion de colas. El scheduler seleccionado es round robin con pesos, es decir, que a cada cola se le asigna un nuero, y mientras mayor sea ese numero, menos solicitudes es capaz de procesar.
Para realizar esto usamos ipvsadm, aplicacion que administra el servidor virtual, tanto el tipo de colas como el tipo de arquitectura
Posterior a esto, habilitamos el redireccionamiento de IP
Al realizar mediciones sobre el cluster, obtenemos:
Al realizar una comparacion para distinta cantidad de solicitudes, obtenemos
Se observa un aumento de un 154% respecto de la cantidad de solicitudes atendidas por segundo. Esto demuestra que una buena forma de responder al aumento de requerimientos sin actualizar la maquina real.
El tiempo de respuesta, de este servidor, esta limitado a la cantidad de servidores reales de la red interna. Considerando que el ancho de banda real utilizado por cada servidor real, de acuerdo con el procesamiento de los datos, es promedio 300, y considerando paquetes de 1500, nuestro cuello de botella se forma acuerdo al tiempo de procesamiento en la traduccion de paquetes, para el caso de este el tiempo de procesamiento para paquetes es de aproximadamente 100 por lo que el ancho de banda es de 14.3 lo que permite hasta 48 servidores reales.
dir# ipvsadm -A -t 192.168.28.167:80 -s rr
dir# ipvsadm -a -t 192.168.28.167:80 -r 10.0.100.11:80 -m -w 1
dir# ipvsadm -a -t 192.168.28.167:80 -r 10.0.100.12:80 -m -w 1
dir# ipvsadm -a -t 192.168.28.167:80 -r 10.0.100.13:80 -m -w 1
dir# ipvsadm -a -t 192.168.28.167:80 -r 10.0.100.15:80 -m -w 1
dir# echo 1 >> /proc/sys/net/ipv4/ip_forward
Velocidad de transferencia
580.75
Solicitudes por segundo
131.60
Tiempo por
solicitud
7.60
Bytes solicitados
4100
