Linux Virtual Server
Crear un cluster con LVS tiene varios detalles sutiles que hay que tomar en cuenta. Cuando termine este proyecto voy a juntar todas mis notas para publicarlas aquí.
Algo que ya me mordió es que (en LVS-NAT) la red de los servidores debe estar separada de la del cliente/ruteador, por lo menos lógicamente, para evitar que el servidor intente responder directamente al cliente, saltandose al director.
Eso significa que no puedo tener levantada la configuración para esto al mismo tiempo que una para hacer pruebas de rendimiento directas al servidor. Buuuu.
Actualización(24/ago/04): Ya terminé el proyecto. Las notas, a continuación.
________________________________________________________
Este archivo documenta los pasos tomados en la creación del cluster de
prueba para Ciudad Multimedia. Explica también las decisiones de
diseño tomadas y da su justificación.
El cluster se compone de las siguientes máquinas:
_director_
Recibe las peticiones de los clientes y las reparte a los servidores
que las atienden. Esta es la única máquina que necesita el software
de LVS.
_real servers_
Son los servidores que atienden las peticiones del cliente. El
requisito principal para ellos es que deben dar respuestas iguales a
peticiones iguales, puesto que un cliente puede conectar a cualquiera
de ellos en cualquier momento.
Además, el cluster de prueba instalado tiene otra máquina, un servidor
de base de datos.
La mayor parte de la configuración se lleva a cabo en el director.
* Instalación normal de un Debian/sarge: (20/jul/04)
o Usando el CD.
o Particionado genérico.
o Apuntado a un mirror y actualizado.
o Kernel 2.4.22-1 stock de Debian, que cambiará pronto.
* Paquetes modificados respecto a la configuración base
o Añadimos ssh, sudo, vim, less, grub, kernel-package,
kernel-source-2.4.26, fakeroot, libncurses5-dev, ntpdate,
netcat, tcpdump
o Eliminamos nvi, nano, pcmcia, lilo
* Configuración general, que no debería afectar.
o Instalamos grub en la partición de boot e install-mbr en
el sector de arranque del disco.
o Añadimos mi usuario a /etc/sudoers
o Activamos bash_completion
o Añadimos mi usuario al grupo src, para poder desempaquetar
y compilar el kernel con mi id.
o Cambios en la configuración de make-kpkg, para adaptarnos
a grub.
o Añadimos tulip y apm a /etc/modules
* Instalación de lvs.
o Compilamos un kernel 2.4.26, del paquete Debian
kernel-source-2.4.26-2. lvs viene como parte del kernel
oficial desde 2.4.23. Se configura como módulos. El paquete
de ipvsadm de Debian viene compilado para el kernel 2.4 lo
que nos obliga a usar este y no un 2.6, a menos que se esté
dispuesto a recompilar el paquete.
o Instalamos ipvsadm. Se quejó de que no hay soporte en el
kernel, hay que instalar el nuevo kernel y luego correr
dpkg-reconfigure ipvsadm. Una vez instalado el nuevo kernel
todo parece funcionar.
o Añadimos ip_vs a /etc/modules
* Configuración de LVS
o
+ Ponemos un servicio ‘dummy’ en el puerto 60600 que solo
responde con el nombre de la máquina. Creamos un servicio
virtual que balancea la carga de ese servicio.
+ La IP del servicio virtual debe ser un alias. LVS no
funciona si esta es la IP principal.
+ Los ?RealServers no deben tener IP en la red del
ruteador/cliente, por que en tal caso intentan
responder directamente, en ves de a travez del
director.
+ Es importante recordar encender ip_forward y apagar
send_redirects en /proc/sys/net/ipv4/conf/*. Configuro
esto en /etc/network/options y /etc/sysctl.conf
En los real servers no es necesario modificar la configuración del
kernel u otras. Sólo se debe asegurar la propiedad mencionada
anteriormente, de que respondan a peticiones iguales con respuestas
iguales. En particular eso significa que los servidores no deben
escribir nada en sistemas de archivos locales que modifique el
comportamiento de la aplicación.
* Adaptación de la aplicación para poder vivir en un cluster LVS.
Es importante que la aplicación no guarde estado en cada
servidor. La aplicación del club de compras, que usa el
soporte normal de PHP para sesiones hace esto, por lo que es
necesario modificarla. Haremos que las sesiones se guarden en
la base de datos. Notese que la aplicación incluye su propia
copia de PEAR. Los cambios realizados son
* Añadimos el script pear_session.php, que bajamos del
* proyecto pearsession en SourceForge.
* Modificamos /etc/php/apache/php.ini según las indicaciones
* del script:
o session.save_handler -> user
o session.save_path -> DSN de la base, en este caso la
misma de la aplicación.
o session.entropy_file -> /dev/urandom
o session.entropy_length -> 16
* Añadimos la tabla session a la base de datos. Es necesario
* otorgar permisos sobre la tabla al usuario que la aplicación
* usa para conectar. En este caso, y dado que no conozco la
* estructura de permisos de la aplicación, uso un GRANT ALL ON
* session TO pg_infocentro.
* Añadimos en ahqr/template.php, entre las lineas
* include_once(‘Permiso.inc.php’); y session_start(); la linea
* include_once(‘pear_session.php’);.
* Añadimos la linea anterior, justo antes del session_start a
* los siguientes archivos:
ahqr/admin/.depositos_cargado.php
ahqr/admin/hist_seguimiento.php
ahqr/admin/historico_empresa.php
ahqr/admin/prospectos_descarga.php
ahqr/admin/reportes.php
ahqr/centralcompradores/catalogo_proveedor.php
ahqr/centralcompradores/cotizacion_imprimir.php
ahqr/centralcompradores/email_contact_empresa.php
ahqr/centralcompradores/error.php
ahqr/centralcompradores/infobox.php
ahqr/centralcompradores/peticion_respuestasXLS.php
ahqr/centralcompradores/styles/template.php
ahqr/centralproveedores/.servicios_comprar.php
ahqr/centralproveedores/catalogo_descarga.php
ahqr/centralproveedores/cotizacion_imprimir.php
ahqr/centralproveedores/email_contact.php
ahqr/centralproveedores/email_contact_empresa.php
ahqr/centralproveedores/error.php
ahqr/centralproveedores/peticion_CSVcot.php
ahqr/centralproveedores/peticion_CSVpet.php
ahqr/centralproveedores/peticion_XLS.php
ahqr/debug.txt
ahqr/inicio/error.php
ahqr/logout.php
ahqr/pear_session.php
ahqr/print-new.php
ahqr/print.php
ahqr/template.php
ahqr/tools/_oferta_nueva.php