1 Clustering de alta disponibilidad Cursos del GUL Universidad Carlos III de Madrid 26 de Marzo de 2007 Héctor Cordobés

2 De qué vamos a hablar... ● Qué quiere conseguir la alta disponibilidad ● A qué nos enfrentamos ● Cómo (intentar) vencer a la Naturaleza – Hardware – Software ● Soluciones completas (en vuestro S.O. favorito)

3 Objetivos ● Alta disponibilidad de servicios – Casi siempre servicios en red – Identificado por una dirección (IP, DNS) ● Transparencia – Si ha habido un fallo, que no se note ● ¿Cuánto es “alta disponibilidad”? – ¿Media hora al año? – Cinco nueves (99.999%)

4 Qué nos puede pasar ● Posibles fallos “naturales” – Almacenamiento (los discos duros fallan) – Conectividad (no tenías que quitar ese cable) – Aplicaciones defectuosas (sí, también) ● Posibles fallos de cluster – Incomunicación de nodos (peor el remedio) ● El “single point of failure” (SPoF) – Buscar y evitar

5 Ideas básicas ● Software: control – Comunicación entre nodos – Monitorización activa (de HW y SW) – (Sistemas de archivos) distribuidos ● Hardware: redundancia – RAID (o similares) – Elementos de red replicados – Interfaces de control sobre los equipos ● Medición y actuación

6 Linux-HA Un caso “sencillo” Gestor de recursos OS Gestor de recursos Ethernet Serie RAID HOST 2HOST 1 Re d STONITH IP1IP F1IP2IP F2 Controladora 1Controladora 2

7 La parte software

8 Recurso 1 ¿Qué es un servicio? ● Agrupando recursos – Puntos de montaje – Procesos – Dirección IP – Orden importa (¿no?) ● Mejor separar – Más pequeño, más rápido ● Tiempo total de failover IP 1 Punto de montaje 1 R/W Proceso servidor 1

9 Al empezar ● ¿El sistema está bien? – Comprobación del nodo local – Integración en el cluster (posible pausa) – Visibilidad desde el exterior ● Se decide dónde funciona cada cosa – Por servicio (charla A-B, A-A prohibida) – Manual o automatizado ● Nodos sincronizados – Estado total conocido por cada nodo (ACK)

10 Monitorización ● Comprobación constante del estado – Servicios disponibles (HTTP, puerto 80) – Respuestas válidas (GET /, 200 OK) – Sistema: disco, conectividad – Cluster: latido, compartición de recursos ● Automatizada ● Parte integrada en solución de cluster ● Habitualmente local ● Genera acciones

11 La parte hardware ● Almacenamiento ● La red (en los nodos) ● La red (en los equipos de conectividad)

12 Almacenamiento ● Los discos fallan. ¿Y si juntamos varios? – RAID ● réplica y reparto (RAID 1+0) ● todo mezclado (RAID 5) ● Disco extra – DRBD ● Para “pobres” (solución SW) ● Poco rendimiento (carga de red al replicar) ● Bloqueo software

13 Almacenamiento ● Acceso simultáneo a un disco común – Posiblemente uso exclusivo de servicios ● S.O. local a cada nodo – Problemas de sincronización ● Requerimiento de HW específico – SCSI doble controladora – SCSI compartido – NAS

14 La red (en el host) ● Bonding (en Linux) – N físicos, uno lógico – Funcionamiento ● Activo-respaldo ● Round-robin ● Mezcla – ¿Fallos? ● Portadora enlace ● Indicación de switch Bonding interface (bond0) eth0eth1 Switch 0Switch 1

15 La red (switches y demás) ● En caso de fallo – Indicación de actividad ● más eficiente uno activo – Interconexión ● VPPR ● Pérdida rendimiento ● En caso de fallo – Indicación de actividad ● más eficiente uno activo – Interconexión ● VPPR ● Pérdida rendimiento HHHHHHH SS

16 Las reacciones

17 Si algo falla... ● Alerta (correo electrónico, SNMP, IPMI...) ● Contramedidas para arreglar la situación – Fallo en el sistema propio ● ¿Recuperable? Si no, reinicio ● Dependiendo del caso, reinicio puede ser mejor – Sistema bloqueado ● Watchdog HW/SW (el antibloqueo)

18 Si algo falla ● Split brain (la bicha del clustering) – Un nodo no ve al otro – Cada uno se cree “el salvador” del cluster – Recursos de uso exclusivo ● Sistemas de ficheros destruidos ● Colisiones de IP ● Destrucción del universo conocido – Evitarlo a toda costa ● Reinicio ● Apagado remoto

19 Si algo falla... ● Contramedidas para arreglar la situación – Servicio ● Reiniciar o mover (ojo a los recursos) ● ¿Quién se hace cargo? Decisión ● Transición (¿se ha podido cambiar?) – Conclusión: estudio de casos, diagramas ● Problemas de estabilidad ● Granularidad – Mejor muchos servicios pequeños (rápidos)

20 Rompeduras de cabeza ● Temporización de pruebas y acciones ● Montajes en más de una máquina – A lo mejor no es necesario escribir – Tiempo ahorrado (y recurso “libre”) – Sistemas de archivo permisos escritura ● OCFS2 (multijournaling + distributed lock) ● GFS ● Seguridad (estado de cluster) – Comunicación intracluster cifrada ●... (the truth is out there)

21 Fallos típicos ● Agrupar servicios “inseparables” – A la larga deja de ser mantenible ● Actualizaciones en vivo – Problemas de rendimiento y escalabilidad – Los recursos, mejor separados ● Comprobaciones insuficientes – Ej: Arranque, nodo no responde: ¿apagado o aislado? STONITH (¿y luego al arrancar?). ● Sistemas no gemelos – Mantenibilidad, escalabilidad

22 ¿Y GPL, dónde? Linux-HA ● Compite con productos comerciales ● +30001 casos reales ( desde 1999) ● Estándares: LSB, FHS, CGL ● Incluye: – Implementación líder de OCF y SAF (v2) – Acepta scripts LSB de arranque – Robusto: latido redundante, STONITH, reinicios en fallos de recursos, monitor – Extensible

23 Ejemplo de configuración host01 Filesystem::/dev/sda3::/mount/webfiles::ext3 apache2 IPaddr::192.168.0.10 host01Filesystem::/dev/sda2::/mount/tomcat::ext3 tomcat5 IPaddr::192.168.0.9 host02 Filesystem::/dev/sda4::/mount/dbfiles::ext3 postgres IPaddr::192.168.0.11

24 ¿Qué se ve en el sistema? bond0Link encap:Ethernet HWaddr 00:0F:EA:C1:3A:61 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 bond0:0Link encap:Ethernet HWaddr 00:0F:EA:C1:3A:61 inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 bond0:1Link encap:Ethernet HWaddr 00:0F:EA:C1:3A:61 inet addr:192.168.0.9 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

25 Ejemplo de configuración (mon) service postgresql interval 5s monitor psql.monitor period wd {Mon-Sun} alert failover.alert "Fallo en PostgreSQL."

26 Linux-HA Ahora sí... Gestor de recursos OS Gestor de recursos Ethernet Serie RAID HOST 2HOST 1 Re d STONITH IP1IP F1IP2IP F2 Controladora 1Controladora 2

27 Resumen ● Requerimientos – Que no haya puntos de ruptura simples – Redundancia HW – Redundancia SW ● Gestión de recursos – Control distribuido de los servicios – Monitorización (sistema y servicios) – Recuperación ante fallos (siempre hay fallos)

28 Resumen ● Claves para un buen sistema – La granularidad es necesaria ● Hay que hacer un diseño pensando en el futuro – STONITH ● Hay que evitar split brain a toda costa – El HW de un buen cluster es caro ● RAID, SCSI, IPMI, UPS, alimentación múltiple, red... ● Se puede cambiar dinero por rendimiento

29 Algunas referencias La Biblia: Marcus, Evan, and Hal Stern. Blueprints for High Availability: Designing Resilient Distributed Systems. New York: Wiley, 2000. Mis preferencias: Bonding:.../linux/Documentation/bonding.txt Linux-HA: http://www.linux-ha.orghttp://www.linux-ha.org mon: http://www.kernel.org/software/mon/ http://www.kernel.org/software/mon/ OCFS2: http://oss.oracle.com/projects/ocfs2/ http://oss.oracle.com/projects/ocfs2/ Otras opciones: Red Hat Cluster Suite: http://www.redhat.com/software/rha/cluster/http://www.redhat.com/software/rha/cluster/ GFS (Red Hat): http://www.redhat.com/software/rha/gfs/ http://www.redhat.com/software/rha/gfs/ GFS (Google): http://labs.google.com/papers/gfs.html http://labs.google.com/papers/gfs.html Otros enlaces de interés: Open Cluster Framework:http://www.opencf.org/home.htmlhttp://www.opencf.org/home.html Service Availability Forum: http://saforum.orghttp://saforum.org

30 Contacto Héctor Cordobés hcordobes (en) gmail (punto) com

31 Cómo funciona esto (STONITH throu IPMI) IPMI BMC OS Sensor 0 Sensor 1 Sensor 2 Power LAN KCS SMBU S