Los clusters: Tendencia en Linux<br/><br/>1<br/><br/><br/>Qué es un cluster<br/>El concepto de cluster Tipos de clusters<br/><br/><br/><br/><br/><br/><br/><br/><br/>Clusters de alto rendimiento Clusters de alta disponibilidad Cluster tolerante a fallos<br/><br/>2<br/><br/><br/>Clusters de alta disponibilidad<br/><br/><br/>Qué son los clusters de alta disponibilidad &quot;Que el servicio nunca pare&quot; Casos de uso de los clusters de alta disponibilidad. Tipos de clusters de alta disponibilidad.<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>Clusters de alta disponibilidad de Apache Clusters de alta disponibilidad de samba Clusters de alta disponibilidad de (ponga aquí su servicio favorito)<br/><br/>3<br/><br/><br/>Clusters tolerantes a fallos<br/><br/><br/>Qué son los clusters tolerantes a fallos &quot;Que si hay fallos, no se pierda nada&quot; Casos de uso de los clusters tolerantes a fallos Tipos de clusters tolerantes a fallos.<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>Clusters tolerantes a fallos de disco Clusters tolerantes a fallos de red Clusters tolerantes a fallos del procesador Clusters tolerantes a fallos de (ponga aquí su recurso hardware favorito)<br/><br/>4<br/><br/><br/>Alta disponibilidad vs. Tolerancia a fallos<br/><br/><br/>En un mundo ideal, los dos vendrían juntos El mundo real es muy duro, no hay soluciones completas<br/><br/><br/><br/>Si queremos tener alta disponibilidad en algo, debemos tener algún tipo de tolerancia a fallos, y viceversa.<br/> <br/><br/>Es un problema de enfoque.<br/><br/>5<br/><br/><br/>Clusters de alto rendimiento<br/>Qué son los clusters de alto rendimiento &quot;Que el servicio sea lo más rápido que sea posible&quot; Casos de uso de los clusters de alto rendimiento. Usualmente buscamos el alto rendimiento en el recurso hardware que es el cuello de botella de nuestra aplicación. Tipos de clusters de alto rendimiento.<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>Clusters de alto rendimiento de disco Clusters de alto rendimiento de red Clusters de alto rendimiento de procesador Clusters de alto rendimiento de (ponga aquí su recurso hardware favorito)<br/><br/>6<br/><br/><br/>Alto rendimiento vs. Alta disponibilidad<br/><br/><br/>En algunos casos, se ha conseguido (LVS)<br/><br/>En otros, la solución depende de como se entienda el concepto de alta disponibilidad (OpenMosix)<br/> <br/><br/>En otros, hay que llegar a un compromiso (replicación de datos)<br/><br/>7<br/><br/><br/>Tecnologías libres de cluster, calidad de producción<br/>Heartbeat y IP-takeover  Linux Virtual Server (LVS)  Beowulf  Bibliotecas paralelas (PVM, MPI)  Repartidores de carga/gestores de colas batch  BPROC  OpenMosix  Sistemas de ficheros distribuidos  Soluciones por aplicación<br/><br/><br/>8<br/><br/><br/>Conclusión de la introducción<br/><br/><br/>No hay &quot;una solución para todo&quot;<br/><br/>Identificando el problema, muchas veces tendremos una solución.<br/> <br/><br/>Hay soluciones a muchos problemas con calidad de producción.<br/><br/>9<br/><br/><br/>Heartbeat, IP takeover Filosofía del heartbeat Filosofía del IP-takeover Funcionamiento local Dispara en la cabeza... Ventajas e inconvenientes:<br/><br/><br/>Todo en área de usuario Funciona... ... pero muy personalizado Y casi siempre necesita tocar código No resuelve la replicación de datos (y este es su talón de Aquiles)<br/>    <br/><br/>10<br/><br/><br/>Linux Virtual Server -LVSFilosofía del Linux Virtual Server Como funciona el LVS Modos de &quot;captura&quot; de paquetes y de &quot;enmascarado&quot; LVS+Heartbeat<br/><br/><br/>Ya en kernel 2.6 Años funcionando con calidad de producción sin problemas Se puede hacer LVS con casi cualquier cosa y servicio detrás... Mejor funcionamiento con muchos accesos cortos, mal funcionamiento con pocos accesos muy largos Los sockets no migran, solo se balancea la carga Un único balanceador Sensible a caidas de elementos de red<br/>      <br/><br/>11<br/><br/><br/>SUPERMICRO Full Fault tolerance module<br/><br/><br/>Todo replicado Tolerante ante caídas de hardware de red Algoritmo de decisión distribuido Cualquier máquina puede repartir carga No presenta brain-splits<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>12<br/><br/><br/>SUPERMICRO LVS Cluster<br/>· Alto rendimiento, alta disponibilidad y tolerancia a fallos para las<br/>aplicaciones orientadas a la red de sus clientes. · No hay ningún punto único de fallo. Ni siquiera en la lógica de red: se pueden poner varios switchs, los servidores enrutarán por los que funcionen. Tiempo de recuperación ante un fallo crítico, entre unos pocos segundos y menos de un minuto. Y no siempre el fallo es detectable por el programa cliente. ·Target: ISPs, grandes empresas, organismos públicos, universidades<br/><br/>13<br/><br/><br/>Soluciones finales de cluster Supermicro<br/>· Soluciones ya probadas, verificadas y empaquetadas.<br/>· Sin tiempo de desarrollo, bajo tiempo de implantación. · Garantía final de Supermicro Computer Spain. · Sin problemas de integración. · Con toda la experiencia y calidad del mejor fabricante de hardware del mercado.<br/><br/>14<br/><br/><br/>Supermicro Web cluster<br/>·<br/>Alto rendimiento, alta disponibilidad y tolerancia a fallos para el servidor web Apache de sus clientes. · Mejorará el rendimiento y la disponibilidad de las aplicaciones Web y sus CGIs, en PHP, Perl o Python de sus clientes. · No hay ningún punto único de fallo. Ni en la lógica de red: se pueden poner varios switchs, los servidores enrutarán por los que funcionen. · Tiempo de recuperación ante un fallo crítico: entre unos pocos segundos y menos de un minuto. Y no siempre el fallo es detectable por el navegador web. ·Target: ISPs, grandes empresas, organismos públicos, universidades<br/><br/>15<br/><br/><br/>Supermicro Java cluster<br/>· Compatible con J2EE 1.4, y con EJB -Enterprise Java Beans- 3.0.<br/>· Alto rendimiento, alta disponibilidad y tolerancia a fallos para el servidor web Apache, el servlet container y el Enterprise Java Bean (EJB) Container de sus clientes. · Mejorará el rendimiento y la disponibilidad de las aplicaciones en Java de sus clientes, y para sus páginas web de apoyo. · No hay ningún punto único de fallo. Ni en la lógica de red: se pueden poner varios switchs, los servidores enrutarán por los que funcionen. · Tiempo de recuperación ante un fallo crítico: entre unos pocos segundos y menos de un minuto. Y no siempre el fallo es detectable por el navegador web. ·Target: ISPs, grandes empresas, organismos públicos, universidades<br/><br/>16<br/><br/><br/>Supermicro Mail cluster<br/>· Alto rendimiento, alta disponibilidad y tolerancia a fallos para el servidor de correo de sus<br/>clientes. · Mejorará el rendimiento y la disponibilidad del correo de sus clientes. · No hay ningún punto único de fallo. Ni en la lógica de red: se pueden poner varios switchs, los servidores enrutarán por los que funcionen. · Tiempo de recuperación ante un fallo crítico: entre unos pocos segundos y menos de un minuto. Y no siempre el fallo es detectable por el programa de correo. · Disponible en los MTA más populares del mercado: sendmail y qmail. ·Target: ISPs, grandes empresas, organismos públicos, universidades<br/><br/>17<br/><br/><br/>Supermicro Streaming cluster<br/>· Alto rendimiento, alta disponibilidad y tolerancia a fallos para el servidor de streaming de sus<br/>clientes. · Mejorará el rendimiento y la disponibilidad del streaming de sus clientes. · No hay ningún punto único de fallo. Ni en la lógica de red: se pueden poner varios switchs, los servidores enrutarán por los que funcionen. · Tiempo de recuperación ante un fallo crítico: entre unos pocos segundos y menos de un minuto. Y no siempre el fallo es detectable por el reproductor del stream de video. · Disponible para los servidores de streaming más populares del mercado: videoLAN, MPEG4IP/FFmpeg o icecast. ·Target: ISPs, cadenas de televisión y de radio<br/><br/>18<br/><br/><br/>Supermicro MySQL cluster<br/>· Alto rendimiento, alta disponibilidad y tolerancia a fallos para los servidores MySQL de sus clientes. · Cuantos más servidores incluya, más aumentará el rendimiento de las base de datos. · Funciona tanto con tablas MyISAM como con tablas InnoDB. Clusterización transparente a las aplicaciones: no es necesario reescribir su aplicación LAMP para emplear este cluster. ·Taret: ISPs, empresas, organismos públicos, universidades: cualquiera que emplee MySQL en el día a día.<br/><br/>19<br/><br/><br/>Supermicro LAMP cluster<br/>· LAMP es la plataforma más popular en la actualida de desarrollo de aplicaciones Web. · Alto rendimiento, alta disponibilidad y tolerancia a fallos para los servidores web Apache y para las base de datos MySQL de sus clientes. · Mejorará el rendimiento y la disponibilidad de las aplicaciones LAMP, estén basadas en PHP, en Perl o en Python. · No hay ningún punto único de fallo. Ni en la lógica de red: se pueden poner varios switchs, los servidores enrutarán por los que funcionen.<br/>20<br/><br/><br/>Supermicro LAMP cluster<br/>·Tiempo de recuperación ante un fallo crítico, entre unos pocos segundos y menos de un minuto. Y no siempre el fallo es detectable por el navegador web. ·Cuantos más servidores incluya, más aumentará el rendimiento de las bases de datos de sus clientes. · Funciona tanto con tablas MyISAM como con tablas InnoDB. · Clusterización transparente a las aplicaciones: no es necesario reescribir la aplicación LAMP para emplear este cluster. ·Target: ISPs, empresas, organismos públicos, universidades: cualquiera que emplee aplicaciones LAMP.<br/><br/>21<br/><br/><br/>Supermicro LAMJ cluster<br/>·Compatible con J2EE 1.4, y con EJB -Enterprise Java Beans- 3.0. · Alto rendimiento, alta disponibilidad y tolerancia a fallos para el servidor web Apache, el servlet container, el Enterprise Java Bean (EJB) Container y la base de datos MySQL de sus clientes. · Mejorará el rendimiento y la disponibilidad de las aplicaciones en Java de sus clientes, sus páginas web de apoyo y la base de datos MySQL empleada. · No hay ningún punto único de fallo. Ni en la lógica de red: se pueden poner varios switchs, los servidores enrutarán por los que funcionen.<br/><br/>22<br/><br/><br/>Supermicro LAMJ cluster<br/>·Cuantos más servidores incluya, más aumentará el rendimiento de su base de datos.<br/><br/>·Funciona tanto con tablas MyISAM como con tablas InnoDB.<br/><br/>· Clusterización transparente a las aplicaciones: no es necesario reescribir su aplicación LAMJ para emplear este cluster. · Tiempo de recuperación ante un fallo crítico, entre unos pocos segundos y menos de un minuto. Y no siempre el fallo es detectable por el navegador web. ·Target: ISPs, empresas, organismos públicos, universidades: cualquiera que emplee aplicaciones LAMP.<br/><br/>23<br/><br/><br/>B eo w u l f<br/>Cluster &quot;pon las máquinas juntas, y ya está&quot;  El mérito fue atreverse a hacer público que se utilizaba Linux en supercomputación.  Comunidad de desarrollo de gran cantidad de código para clustering.  Ventajas e inconvenientes:<br/><br/><br/>24<br/><br/><br/>Supermicro Beowulf clusters<br/>·El cluster de alto rendimiento más estandarizado y común. · Compatible con arquitecturas de 32 bits y 64 bits -AMD64, Itanium-. ·Compatible PVM y MPI. · Aún más rendimiento a las aplicaciones paralelas de sus clientes, a un precio muy competitivo. ·Target: grupos de investigación<br/><br/>25<br/><br/><br/>Clusters SSI<br/><br/><br/>El primer paso fue el soporte multiprocesador -SMPDespués el soporte NUMA Finalmente, el soporte SSI<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>OpenSSI (congelado) MOSIX (no libre) OpenMosix<br/><br/>26<br/><br/><br/>MOSIX<br/><br/><br/>Comenzado en 1977 por Amnon Barak para el PDP-11/45 Varias encarnaciones En 1999 es liberado A mediados del 2002, vuelve a ser código cerrado.<br/><br/><br/><br/><br/><br/><br/><br/>27<br/><br/><br/>El fork<br/><br/><br/>Moshe Bar (área de kernel) David Santo (herramientas de área de usuario) Colaboradores de muy alto nivel: Muli Ben-Yeruda (Mulix) Código con muchos errores. Herramientas de área de usuario inutilizable.<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>28<br/><br/><br/>Hoy en día<br/><br/><br/>Area del Kernel funcional Herramientas de área de usuario terminadas Nuevas características Miles de nuevas instalaciones. Soportado por consultoras de software.<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>29<br/><br/><br/>Hoy en día<br/><br/><br/>Único sistema SSI libre que funciona El cluster completo se comporta casi como un sistema NUMA Migración transparente de procesos<br/><br/><br/><br/><br/><br/>No es necesario reprogramar las aplicaciones para aprovechar el cluster<br/> <br/><br/>Algoritmo basado en cálculo de costos Ya es sólido y estable<br/>30<br/><br/><br/><br/><br/>Migración transparente de procesos<br/>Podemos mover a un proceso de un nodo a otro sin que se de cuenta.<br/> <br/><br/>El proceso nunca sabe en que nodo realmente se está ejecutando.<br/><br/>El proceso, cuando accede al sistema, lo hace en su nodo de lanzamiento original.<br/><br/><br/>Todo esto lo podemos hacer sin necesitar recompilar la aplicación: cambiar el kernel, y utilizar nuestras aplicaciones de siempre.<br/><br/><br/>31<br/><br/><br/>Equilibrado automático de carga<br/>Las aplicaciones se ejecutarán donde el aprovechamiento del cluster sea óptimo.<br/><br/><br/>Aunque una aplicación en especial no migre, el sistema intentará migrar las otras.<br/> <br/><br/>El algoritmo es dinámico, adaptativo y descentralizado. No hay un &quot;nodo maestro&quot; que reparte carga.<br/><br/><br/><br/>32<br/><br/><br/>Memory ushering<br/><br/><br/>No más &quot;trashing&quot;<br/><br/>Si una aplicación se queda sin memoria, migra a donde tenga memoria.<br/> <br/><br/>Lo lanza el gestor de memoria.<br/><br/>33<br/><br/><br/>Tecnología OpenMosix<br/><br/><br/>Alta y baja de nodos en caliente Control descentralizado Algoritmo basado en cálculo de costos (ejemplo) Migra el área de usuario, el área de kernel se queda en el nodo raiz El problema de los sockets y de la escritura en disco<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>34<br/><br/><br/>Tecnología OpenMosix limitaciones<br/><br/><br/>Hay que mantener tantas máquinas como nodos tenga el cluster.<br/><br/>Cada máquina da tanto trabajo de administrar como un servidor principal.<br/> <br/><br/>Calibración inicial compleja. Costo total de propiedad alto.<br/><br/><br/><br/>35<br/><br/><br/>SUPERMICRO OpenMosix cluster<br/><br/><br/>Nodo central en el que se lanzan todos los procesos.<br/><br/>Nodos satélite que ejecutan parte de las tareas el nodo principal, cuando este está saturado.<br/> <br/><br/>Nodo central: configuración estándar.<br/><br/>Nodos satélite: sin disco, traen un kernel de Linux y un miniproceso inicial.<br/> <br/><br/>Los nodos satélite no tienen bibliotecas instaladas. Todo lo necesario para funcionar lo tienen en RAM.<br/>36<br/><br/><br/><br/><br/>SUPERMICRO OpenMosix cluster - ventajas<br/><br/><br/>Hay que mantener una única máquina.<br/><br/>Los nodos satélite, al no tener nada más que un kernel que cargan por PXE, no tienen nada que mantener.<br/> <br/><br/>Precalibrado para hardware Supermicro.<br/><br/>Costo total de propiedad muy bajo -un cluster de 100 máquinas como una única máquina-.<br/> <br/><br/>Target: Universidades, grupos de investigación<br/><br/>37<br/><br/><br/>SUPERMICRO compiler cluster<br/>· Compilación a gran velocidad los proyectos en C o C++ de sus clientes, a pesar de ser muy grandes. · Sistema SSI: todo el cluster se ve como una única máquina. · Transparente al compilador: todo se realiza en área de kernel. · Migración de procesos: según se sobrecargue el servidor, las máquina satélite asumirán parte de la carga de cómputo. · TCO bajo: independientemente del número de nodos que tenga el cluster, todo el cluster se administra como una única máquina.<br/><br/>38<br/><br/><br/>SUPERMICRO compiler cluster<br/>· Compilación distribuida transparente: su cliente no tendrá que modificar nada en su programa o en sus Makefiles para paralelizar la compilación. · Disponible con varios programas de apoyo a la compilación distribuida: icecream/ccache o distcc/ccache. ·Target: Universidades, centros de investigación<br/><br/>39