mundoGalynet

Siguiendo con las entregas sobre la tecnología que utilizamos en la plataforma de Galynet, damos el siguiente paso lógico:

Os explicamos qué es el cluster de servidores.

Esquema de cluster de servidores

Bien, ya sabemos con qué equipos de protección perimetral cuenta Galynet, y cómo distribuimos nuestros servidores en VPS o servidores virtuales. Pues además de esto, nuestros servidores están organizados en una plataforma de cluster de servidores.

Un cluster de servidores -siempre siguiendo el lenguaje cercano- es un grupo de servidores que están separados físicamente pero sincronizados entre sí, de manera que podamos repartir los servicios de un cliente entre dos o más servidores físicos. Esa “sincronización” se hace por medio de un software específico.
El hecho de ubicar un servidor en un rack (armario) y otro servidor en otro rack distinto, permite aumentar el nivel de seguridad y de disponibilidad de servicios, ya que para que un cliente (o grupo de clientes) se quede sin todos sus servicios, debería haber una caída en más de un armario, algo más que improbable.

Si observamos el esquema, vemos que los dos bloques inferiores nos describen la virtualización, mientras que los dos bloques centrales y el superior nos muestran el cluster en sí.

¿Qué ventajas tiene esta plataforma para mí como cliente?:

Pasemos a analizar el equema.
Vamos a definir dos grupos de clientes: el Grupo Alfa, y el Grupo Omega.

El Grupo Alfa tiene sus archivos web en el VPS1 del servidor ubicado en el rack 1. Sus bases de datos se encuentran en el VP2 de ese mismo servidor, y su servicio de correo en el VPS3 del servidor ubicado en el rack 2.

El Grupo Omega tiene sus archivos web en el VPS1 del servidor ubicado en el rack 2. Sus bases de datos en el VPS2 del servidor ubicado en el rack 2, y su servicio de correo en el VPS3 del servidor ubicado en el rack 1.

Venga, os dejo tiempo para asimilar todo este lío
¿Estamos?, ¿comprendido el reparto?.

Pues vamos a por los problemas:

• caso 1: sobrecarga en el VPS1 del servidor ubicado en el rack 1. ¿Qué consecuencias tiene?, pues que a los usuarios del Grupo Alfa se les habrá caído la web, pero seguirán teniendo operativas las bases de datos y el servicio de correo. ¿Y los del Grupo Omega?, pues ni se han enterado de que hay un problema.
• caso 2: sobrecarga en el VPS1 y en el VPS2 (ya es casualidad, también). ¿Qué consecuencias tiene?, pues que a los usuarios del Grupo Alfa se les habrá caído la web y las bases de datos, pero seguirán teniendo operativo el servicio de correo. ¿Y los del Grupo Omega?, pues ni se han enterado de que hay un problema.
• caso3: sobrecarga en el VPS1, en el VPS2 y en el VPS3 (¿meigas?, haberlas haylas).  ¿Qué consecuencias tiene?, pues que a los usuarios del Grupo Alfa se les habrá caído la web y las bases de datos, pero seguirán teniendo operativo el servicio de correo. ¿Y los del Grupo Omega?, pues se les habrá caído el servicio de correo, pero seguirán teniendo operativa la web y las bases de datos.
• caso 4: caída total del servidor 1 (muy poco probable, a pesar de las meigas). ¿Qué consecuencias tiene?: las mismas que en caso anterior
• caso 5: caída total del servidor 1 y del servidor 2: nos vamos para casa porque definitivamente estamos de mala suerte , porque que se caigan dos servidores situados en ubicaciones físicas distintas, con switches distintos…

Pero claro, todo esto lo estamos viendo en un cluster formado por 2 servidores; pero es que nuestros clusters están formados por más servidores.

Creo que con esto, se puede imaginar la estabilidad de que disponen nuestros clientes. Y más claro quedará si explico cómo funciona el hosting compartido de nuestros competidores: en un único servidor ofrecen todos los servicios a un grupo de clientes. ¿Qué pasa si uno de esos clientes satura los recursos del servidor?, pues que TODOS los clientes se quedarán sin servicio. ¿Y si se cae el servidor?, pues que TODOS los clientes se quedarán SIN TODOS los servicios.

Blanco y en botella…