Charlas 29-11 Ummet'2000

Charlas del 29/11/2000

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia
[19:08] *** Now talking in #media
[19:12] (debUgo-) empezamos?
[19:12] (MJesus)yes.. as you like
[19:12] (DaniT) amos alla..
[19:13] (DaniT__) la charla se realizara en el canal #linux
[19:13] (DaniT__) las preguntas se realizaran en el canal #qc
[19:14] (DaniT__) los ponentes Mr. Riel y Mr. Tosatti
[19:14] (DaniT__) marcelo: bien.. lo primero explicar en que consiste la Alta disponibilidad
[19:15] (DaniT__) riel: hoy hablaremos de linux y alta disponibilidad
[19:15] (DaniT__) riel: si tienen alguna pregunta pueden realizarla a traves de #qc
[19:15] (DaniT__) riel: este canal debera permanecer en silencio excepto por marcelo y yo
[19:16] (DaniT__) riel: marcelo, puede explicar que es la Alta Disponibilidad?
[19:16] (debUgo-) marcelo: disponibilidad es la probabilidad que un sistema este operativo durante un tiempo dado
[19:16] (DaniT__) marcelo: ok vamos allla
[19:16] (DaniT__) marcelo: primero de todo, explicar el concepto de Alta Disponibilidad
[19:16] (DaniT__) marcelo: disponibilidad es la probabilidad de que un sistema este funcionando en un momento dado
[19:17] (DaniT__) un sistema sin ningun mecanismo para mantener su disponibilidad es considerado como de disponibilidad basica
[19:18] (DaniT__) este tipo de sistemas tienen, en teoria, una disponibilidad del 99,9%
[19:18] (DaniT__) asi que durante un año pueden estar 5 dias indisponibles
[19:18] (DaniT__) cuando un sistema tiene mas del 99,999% de disponibilidad es considerado de alta disponibilidad
[19:20] (debUgo-) #qt:riel: una pequeña corrección a los números de marcelo... 99.9% son 5 _horas_ de no disponibilidad cada año (pero eso no es muy importante)
[19:20] (DaniT__) por tanto, un sistema considerado de alta disponibilidad deberia, en teoria, tener un tiempo de indisponibilidad de 5 min en un periodo de un año
[19:22] (DaniT__) el modelo antiguo de alta disponibilidad como "tolerancia a fallos" solia estar basado en hardware
[19:22] (DaniT__) el fin del modelo antiguo consistia en mantener el equipo funcionando
[19:23] (DaniT__) riel: por tanto un solo ordenador es una pieza insustituible (relativamente hablando)
[19:25] (DaniT__) por tanto Alta disponibilidad es el conjunto de tecnicas usadas para hacer el trabajo del ordenador mas fiable
[19:25] (DaniT__) se puede hacer mejorando las estructuras de hardware o las estructuras de software
[19:26] (DaniT__) normalmente con una combinacion de ambas
[19:26] (DaniT__) el modelo de linux de alta disponibilidad esta basado en el sofware
[19:27] (DaniT__) marcelo: ahora dejenme explicar unos conceptos basicos de AD
[19:28] (DaniT__) antes de nada, es muy importante que no confiemos en un unico componente hardware en un sistema de AD
[19:29] (DaniT__) por ejemplo, puede tener dos tarjetas de red conectadas a una misma red
[19:29] (DaniT__) en caso de que una de ellas falle, el sistema intenta usar la otra
[19:30] (DaniT__) un componente hardware que no puede fallar porque el sistema entero depenede de el es llamado "Single Point of Failure" (SPOF para apreviar)
[19:31] (debUgo-) SPOF == Punto único de falla
[19:33] (DaniT__) otro concepto importante que debe ser conocido antes de continuar es "failover"
[19:37] (debUgo-) "failover" es el proceso en el cual una máquina toma el trabajo de otro nodo
[19:37] (debUgo-) "maquina" en este contexto, puede ser cualquier cosa, BTW...
[19:38] (debUgo-) si un disco falla, otro disco tomará su trabajo (hará 'take over')
[19:38] (debUgo-) si una máquina de un cluster falla, las otra máquinas tomarán su trabajo
[19:39] (debUgo-) pero para tener tolerancia a fallas (fail over), se necesita tener buen soporte en software
[19:39] (debUgo-) debido a que la mayoría del tiempo, se estarán usando componentes estándar de computadoras
[19:40] (debUgo-) marcelo: bueno, esta es toda la 'teoría' necesaria para explicar las siguientes partes
[19:40] (debUgo-) riel: dejame hacer entonces un pequeño resumen de esta introducción
[19:41] (debUgo-) 1. los computadores normales no son suficientemente fiables para algunas personas (como las tiendas de internet), asi que necesitamos un truco... ummm... método... para hacerlas más fiables
[19:41] (debUgo-) 2. alta disponibilidad es la colección de estos métodos
[19:42] (debUgo-) 3. se puede lograr alta disponibilidad usando hardware especial (muy costoso) o usando una combinación de hardware normal y software
[19:42] (debUgo-) 4. si un punto en el sistema falla y hace que todo el sistema falle, ese punto es un punto único de falla (SPOF)
[19:43] (debUgo-) 5. para lograr alta disponibilidad, no deben existir SPOFs, si una parte del sistema falla, otra parte del sistema debe tomar ese trabajo (esto es llamado 'failover')
[19:44] (debUgo-) ahora creo que debemos explicar algo sobre como trabaja la alta disponibilidad... el lado técnico
[19:44] (debUgo-) ummm momento... lo siento marcelo ;)
[19:45] (debUgo-) marcelo: ok, hablemos acerca de los componentes básicos para la alta disponibilidad (AD)
[19:45] (debUgo-) o al menos, algunos de ellos
[19:45] (debUgo-) un solo disco corriento un sistema de archivos es claramente un SPOF
[19:46] (debUgo-) si el disco falla, alguna parte del sistema que depende de los datos contenidos en el, se detendrán
[19:46] (debUgo-) para evitar que un disco se convierta en un SPOF del sistema, se puede usar RAID
[19:47] (debUgo-) RAID-1, que es una característica del kernel linux...
[19:47] (debUgo-) permite 'espejar' (duplicar) todos los datos de un dispositivo RAID en un número dado de discos
[19:48] (debUgo-) asi, cuando los datos se escriben en el dispositivo RAID, estos son replicados entre todos los discos que son parte del arreglo RAID
[19:48] (debUgo-) De esta manera, si un disco falla, el otro (o los otros) discos del arreglo RAID-1 serán capaces de continuar trabajando
[19:49] (debUgo-) riel: debido a que el sistema tenía una copia de los datos en cada disco
[19:49] (debUgo-) y puede simplemente usar las otras copias de los datos
[19:49] (debUgo-) este es otro ejemplo de "failover" (tolerancia a fallas)... cuando un componente falla, otro componente es usado para satisfacer esa función
[19:50] (debUgo-) y el administrador del sistema puede reemplazar (o reformatear/reiniciar/...) el componente que falló
[19:50] (debUgo-) esto parece realmente simple cuando no se observa con demasiada atención
[19:52] (DaniT__) pero hay un gran problema... cuando necesitas realizar un sistema a prueba de fallos?
[19:53] (DaniT__) en algunas situaciones, puede tener 2 maquinas funcionando simultaneamente y corromper datos.. si no se va con cuidado
[19:54] (DaniT__) piensen por ejemplo en 2 maquinas que sean servidores de ficheros para los mismos datos
[19:54] (DaniT__) en un momento dado, una de ellas esta funcionando y la otra eta a la espera
[19:54] (DaniT__) cuando la maquina principal falla, la otra retoma el control
[19:55] (DaniT__) y que pasa si la segunda maquina simplemente ha pensado que la pricipal ha fallado y las dos maquinas empiezan a realizar lo mismo con los datos?
[19:56] (DaniT__) cual de las copias de datos es la correcta? cual es la erronea?
[19:56] (DaniT__) o peor.. y si las dos copias son defectuosas?
[19:57] (DaniT__) para eso existen programas especiales llamados "heartbeating" (latido de corazon) que comprueban que partes del sistema estan "sanas"
[19:57] (DaniT__) para linux, uno de esos programas es el llamado "heartbeat".. marcelo y lclaudio han colaborado en el diseño de este programa
[19:58] (DaniT__) marcelo: puede explicarnos algunas de las tareas que realiza "heartbeat" ?
[19:58] (DaniT__) marcelo: claro
[19:58] (debUgo-) un programa de "heartbeating" es como un estetoscopio, pero de servicios =)
[19:58] (DaniT__) "heartbeat" es un fragmento de software que monitoriza la disponibilidad de nodos
[20:00] (DaniT__) envia "pings" a los nodos que quiere monitorizar, y en case de que uno no conteste, lo consideara "muerto"
[20:01] (Ricardo) cuando se considera que un nodo está muerto, es cuando se puede sustituir los servicios que estaba ejecutando
[20:02] (Ricardo) los servicios de los que tomamos control habrán sido configurados anteriormente en ambos sistemas
[20:02] (Ricardo) Ahora mismo, 'heartbeat' sólo funciona con dos nodos
[20:02] (Ricardo) Se ha venido usando en producción en multitud de situaciones
[20:02] (Ricardo) Hay un pequeño problema, sin embargo
[20:03] (Ricardo) ¿Qué pasa si la señora de la limpieza desconecta el cable de red que une el grupo de nodos accidentalmente?
[20:03] (Ricardo) ¿... y ambos nodos *creen* que es el único que queda vivo?
[20:04] (Ricardo) ... y ambos empiezan a destrozar los datos ...
[20:04] (Ricardo) desafortunadamente, no hay forma de prevenir esto al 100%
[20:04] (Ricardo) pero se puede aumentar la fiabilidad sencillamente con tener varios medios de comunicación
[20:05] (Ricardo) digamos, dos cables de red, y uno seria
[20:05] (Ricardo) serie
[20:05] (Ricardo) esto es lo suficientemente fiable para que el fallo de uno de los componentes no evite la buena comunicación entre los nodos
[20:06] (Ricardo) de manera que se pueda decir de forma fiable si el otro nodo está vivo o no
[20:06] (Ricardo) Esta fue la introducción a la HA (alta disponibilidad)
[20:06] (Ricardo) Ahora pondremos algunos ejemplos de HA con Linux
[20:06] (Ricardo) (de software HA)
[20:06] (Ricardo) y mostraremos cómo se usa
[20:07] (Ricardo) Tengan en cuenta que vamos a hablar de software libre para Linux
[20:08] (Ricardo) Como dijimos antes, el programa 'heartbeat' proporciona una manera de monitorizar y detectar fallos básicos de servicios
[20:08] (Ricardo) sólo para dos nodos
[20:08] (Ricardo) Como ejemplo práctico...
[20:08] (Ricardo) El servidor web de Conectiva (www.conectiva.com.br) tiene un servidor en 'suspenso' (stand by) ejecutando heartbeat
[20:10] (Ricardo) En caso de fallo del servidor primario, el nodo en espera lo detectará, y arrancará un servidor Apache
[20:12] (DaniT) dejando el servicio disponible nuevamente
[20:12] (Ricardo) Se puede monitorizar cualquier servicio (en teoría) con heartbeat
[20:12] (Ricardo) De manera que si nuestra máquina se estropea, todo el mundo puede seguir accediendo a nuestro sitio web ;)
[20:12] (Ricardo) La monitorización sólo depende del script de arranque del servicio
[20:13] (Ricardo) De manera que cualquier servicio que cuente con un script de arranque puede usar heartbeat
[20:13] (Ricardo) arjan preguntó si también se hace toma el control de la IP
[20:13] (Ricardo) Existe una IP virtual que es usada por el servicio
[20:14] (debUgo-) la cual es la dirección IP del "servidor virtual"
[20:14] (debUgo-) asi, en el caso de nuestro servidor web
[20:14] (debUgo-) la dirección IP real del primer nodo no es usada por el daemon de apache
[20:15] (debUgo-) pero la dirección IP virtual que será usada por el nodo en espera en caso de que ocurra un 'failover'
[20:16] (debUgo-) pero heartbeat, está limitado a dos nodos
[20:16] (debUgo-) esto es un gran problema para muchos sistemas grandes
[20:16] (debUgo-) SGI ha portado su sistema de AD FailSafe a Linux recientemente (http://oss.sgi.com/projects/failsafe)
[20:17] (debUgo-) FailSafe es un administrador de cluster completo que soporta hasta 16 nodos.
[20:17] (debUgo-) En estos momentos no está listo para ambientes de producción
[20:17] (Ricardo) Pero eso lo está llevando la gente del proyecto Linux HA ;)
[20:18] (Ricardo) El FailSafe de SGI es GPL.
[20:18] (Ricardo) Otro tipo de 'clustering' es LVS... El proyecto de Servidor Virtual de Linux
[20:18] (Ricardo) LVS utiliza otro enfoque diferente al clustering
[20:18] (Ricardo) Tenemos una (quizá dos) máquinas que realizan peticiones http (www)
[20:19] (Ricardo) pero esas máquinas no hacen nada, excepto enviar las peticiones a un montón de máquinas que hacen el trabajo real
[20:19] (Ricardo) también llamados "nodos de trabajo"
[20:19] (Ricardo) (working nodes)
[20:19] (Ricardo) si uno o más de los nodos de trabajo fallan, los otros harán el trabajo por ellos
[20:19] (Ricardo) y todos los rúters (las máquinas que están 'delante') harán esto:
[20:20] (Ricardo) 1) llevar la cuenta de las máquinas que están disponibles
[20:20] (Ricardo) 2) pasar las consultas http a los nodos de trabajo
[20:21] (Ricardo) el núcleo necesita un parche especial para el TCP/IP y un conjunto de utilidades en modo de usuario para que esto funcione
[20:22] (Ricardo) "Piranha", de Red Hat, es una herramienta de configuración para LVS, que la gente puede utilizar para configurar grupos LVS más sencillamente
[20:22] (Ricardo) en conectiva también estamos preparando un proyecto VA muy bueno
[20:22] (Ricardo) el proyecto en que están trabajando marcelo y Olive se llama "drdb"
[20:23] (Ricardo) el dispositivo distribuido de bloques redundantes (distributed redundant block device)
[20:23] (Ricardo) es casi lo mismo que RAID1, sólo que sobre la red
[20:23] (Ricardo) recordemos que RAID1 (mirroring) consiste en usar 2 (o más) discos para almacenar los datos
[20:23] (Ricardo) almacenando una copia en cada disco
[20:24] (Ricardo) drdb extiende esta idea para usar discos en máquinas diferentes en la red
[20:24] (debUgo-) asi, si un disco (en una máquina) falla, otras máquinas aún tendrán los datos
[20:24] (debUgo-) y si una máquina completa falla, los datos están en otra máquina... y el sistema completo, sigue funcionando
[20:24] (debUgo-) si usa esto junto a ext3 o reiserfs, la máquina que sigue funcionando puede rápidamente tomar el trabajo del sistema de archivos que había sido copiado a su propio disco
[20:24] (debUgo-) y sus programas pueden seguir corriendo
[20:25] (debUgo-) (con ext2, debe hacer primero fsck, que puede tomar mucho tiempo)
[20:25] (debUgo-) esto puede ser usado para servidores de archivos/ficheros, bases de datos, servidores web...
[20:26] (debUgo-) cualquier cosa donde se necesite los datos más recientes para trabajar...
[20:26] (debUgo-) este el fin de nuestra parte de la lectura, por favor haga las preguntas y nosotros intentaremos darle una buena respuesta
[20:27] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:27] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:27] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:27] (MJesus)4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:27] (debUgo-) btw, toda esta lectura fue improvisada por marcelo y por mi (riel)... perdón si fue un poco confusa a veces...
[20:27] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:27] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:27] (MJesus)4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:27] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:27] (MJesus)4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:28] (DaniT) fernando: preguntas aqui o en #qc ?
[20:28] (DaniT) riel: creo que solo hemos tenido una pregunta en #qc, asi que continuemos allí
[20:29] (DaniT) fernando: comentarios y preguntas en #qc
[20:30] (DaniT) arjan pregunta: los departamentos de IS estan realmente satisfechos con el "Failover" de IP ?
[20:30] (DaniT) marcelo: si
[20:31] (MJesus)a mi me gustaria tenerlo todo traducido, pero a ver...
[20:31] (avic) yo diría que os merecéis un descanso :)
[20:31] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:31] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:31] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:31] (MJesus)plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
[20:31] (MJesus)hala..... al #qc y cada uno que lea
[20:31] (MJesus)si acaso mañana se traduce, ya acabamos pues
[20:31] (debUgo-) jejeje
[20:32] (DaniT) ;)
[20:32] (Ricardo) :)
[20:32] (MJesus)4 GRACIAS A LOS TRADUCTORES!!!
[20:32] (MJesus)4 GRACIAS A LOS TRADUCTORES!!!
[20:32] (MJesus)4 GRACIAS A LOS TRADUCTORES!!!
[20:32] (Ricardo) :)
[20:32] (avic) grácias
[20:33] (debUgo-) :O)
[20:33] (MJesus)ATENCION EN EL CANAL #QC CONTINUA LA FASE DE DEBATE DE ESTA CHARLA
[20:33] (MJesus)LOS QUE QUIERAN SEGURLA QUE PASEN ALLA. Session Close: Wed Nov 29 22:07:23 2000
Y seguimos un buen rato más charlando...

Contact: