Global Server Load Balancing
Cuando
el principal foco de negocio de una organización se encuentra en
Internet, donde en tan solo unos minutos de no disponibilidad de sus
servicios puede llegar a suponer pérdidas monetarias, reputación,
imagen, confianza, credibilidad, etc haciéndoles
perder clientes,
la disponibilidad de sus servicios para
mantener los
clientes,
cumplir
los acuerdos de nivel de servicio
(SLA) y mejorar la competitividad es una clave fundamental para la
continuidad del
negocio.
Los
balanceadores de carga
nos permiten crear cluster de servidores proporcionando alta
disponibilidad ante un fallo hardware en uno de los nodos del
cluster. Sin embargo, al encontrarse todos los nodos del cluster en
el mismo CPD o depender de una base de datos o SAN determinada, nos
limita la alta disponibilidad ante una catástrofe, un fallo
eléctrico, errores de mantenimiento o actos terroristas. Además,
si proporcionamos los servicios desde un CPD compartido entre varias
empresas, ante un Ataque DDoS
a cualquiera de las empresas, puede llegar a saturarse el ancho de
banda o sobrecargarse
los routers de core del proveedor, teniendo como resultado la no
disponibilidad de todos los servicios alojados en el CPD. Pocos
CPDs son capaces de soportar un ataque smurf de 300Gbps como el que
sufrió spamhaus el año pasado.
Una solución sería replicar el CPD proporcionando alta disponibilidad y balanceo de carga entre distintos CPDs, para ello podemos utilizar Global Server Load Balancing (GSLB) en modo Activo/Pasivo o Activo/Activo. La finalidad de una solución GSLB es asegurar la continuidad del negocio proporcionando alta disponibilidad incluso cuando un CPD no esté disponible, además de mejorar la experiencia de usuario ya que la solicitud la procesa el CPD más cercano disminuyendo considerablemente los tiempos de respuesta. Podemos diferencia cuatro escenarios de despliegue de GSLB:
Una solución sería replicar el CPD proporcionando alta disponibilidad y balanceo de carga entre distintos CPDs, para ello podemos utilizar Global Server Load Balancing (GSLB) en modo Activo/Pasivo o Activo/Activo. La finalidad de una solución GSLB es asegurar la continuidad del negocio proporcionando alta disponibilidad incluso cuando un CPD no esté disponible, además de mejorar la experiencia de usuario ya que la solicitud la procesa el CPD más cercano disminuyendo considerablemente los tiempos de respuesta. Podemos diferencia cuatro escenarios de despliegue de GSLB:
Balanceo
de carga basándonos en el DNS:
La mayoría de soluciones de GSLB utilizan esta técnica manejando la
resolución de nombres DNS, dependiendo del origen de la solicitud y
de la carga de los nodos (CPDs), el servidor DNS devolverá la IP de
un CPD u otro. Para ello será necesario bajar el TTL, así la cache
de los servidores de DNS de Internet olvidarán
inmediatamente el par Nombre-IP y todas las solicitudes siempre serán
redirigidas a nuestro servidor DNS. Como inconveniente tenemos que el
tráfico de DNS contra nuestros servidores se verá incrementado.
Redirección
a nivel de aplicación:
Protocolos como HTTP permiten redirigir las solicitudes, por ejemplo
si queremos acceder a www.davidromerotrejo.com
se nos puede redirigir a us.davidromerotrejo.com balanceando la carga
a un CPD alternativo.
Triangulación:
Con esta técnica un CPD recibe la petición y la reenvía a otro
CPD, existiendo dos escenarios:
- Balanceo en capa 4: Un CPD recibe la petición y se lo reenvía a otro CPD, este último es el que responde al cliente, por lo que se producen tres saltos.
- Balanceo en capa 7: Un CPD recibe la petición, se lo reenvía a otro CPD y este último se lo vuelve a reenviar al primero que es el encargado de contestar al cliente, por lo que se producen cuatro saltos.
La
técnica de triangulación,
balancea la carga pero no mejora los tiempos de respuesta, además
consume mucho ancho de banda.
Modificando
la tabla de rutas BGP:
Podemos mover bloques de direcciones IPs de un CPD a otro. Para ello
se requiere la intervención del ISP para que proporcione mecanismos
de failover. Esta última opción suele ser la más costosa.
Para
afrontar un proyecto de continuidad del negocio, además de redactar
las políticas y procedimientos y disponer de un CPD alternativo, hay
que tener muchas otras cosas en cuenta como la sincronización
de los datos y el balanceo de carga entre CPDs
o GSLB.
¿Te
puedes permitir apagar el CPD? ¿durante cuanto tiempo?
Hola David.
RépondreSupprimerAnte todo muchas gracias por este post y por toda la información aportada en general en tu blog, me es realmente útil.
Me surgen una serie de dudas en relación con el funcionamiento de GSLB. Supongamos el caso de una organización con dos CPDs. Si no he entendido mal, esta técnica puede ser empleada en configuraciones tanto activo-activo como activo-pasivo, tanto cuando ambos CPDs están en funcionamiento, como en caso de caída de uno de los dos CPDs, llevándose a cabo el balanceo de carga desde un CPD hacia el otro.
Imaginemos una configuración activo-pasivo. Supongamos que el CPD activo cae por completo. En ese momento el pasivo debe asumir las funciones del principal y pasar a modo activo. Aquí entraría en juego el GSLB para balancear la carga. ¿Cómo es posible entonces que se realice tal balanceo, si el primer CPD está caído?
Esta duda me surge especialmente en el caso del balanceo por triangulación, pues entiendo que no sería posible recibir la petición en el CPD caído para ser redirigida al que asume las nuevas funciones de activo.
Igualmente me surge la duda del funcionamiento de GSLB por DNS. No me queda muy claro si las funciones del balanceo son llevadas a cabo por el servidor DNS del proveedor de Internet, o bien si las realiza el servidor DNS de nuestra organización. De realizarse a través del DNS de nuestra organización, estaríamos ante el mismo problema planteado en el caso de la triangulación. ¿Cómo se llevaría a cabo entonces el balanceo?
Muchas gracias de antemano, y espero haber planteado correctamente mis dudas.
Buenas Jorge,
RépondreSupprimeren primer lugar muchas gracias por tu comentario y aportación.
Exacto, has entendido bien, esta configuración se puede emplear tanto en activo-activo entre CPDs como entre Activo-Pasivo.
En el caso que planteas, donde se cae por completo el CPD activo, dependerá dónde se aloje el servicio GSLB, si éste se encuentra solamente en el CPD que estaba como primario, lógicamente dejas de dar el servicio y tus peticiones nunca llegarán al CPD de respaldo. Te animo a que leas la siguiente entrada para que veas cómo lo hace Google, se ayuda del DNS:
http://www.davidromerotrejo.com/2014/10/dns-load-balancing.html
Dependiendo de la dimensión de tu organización puede que te interese externalizar el servicio de GSLB a un proveedor que te "garantice" la resolución de nombres y alta disponibilidad de los servicios, o implantarlo internamente en tu organización. Mira el datasheet de FortiDirector donde se explica cómo funciona su servicio de GSLB:
http://www.fortinet.com/sites/default/files/productdatasheets/FortiDirector.pdf
Con respecto al GSLB por DNS, el balanceo es llevado a cabo por tus servidores de DNS ya que debes bajarle el TTL para que el resto de servidores de DNS no cacheen tus nombres y siempre pidan la resolución de nombres a tus servidores. Al igual que el caso anterior, si apagas los servidores de DNS, tienes un problema.
Ten en cuenta que el servicio GSLB es útil, no solo ante catástrofes, sino también ante paradas planificadas, puedes apagar un CPD para realizar operaciones de mantenimiento mientras que otro ofrece el servicio, o también es útil para balancear la carga entre clientes de distintos países proporcionándoles mayor fiabilidad y menor retardo de respuesta.
Cualquier comentario adelante!!
Un saludo.
David.
Hola David,
RépondreSupprimerMuchas gracias por la respuesta y los enlaces, me han ayudado bastante. Dándole una vuelta más al asunto, me han surgido una serie de cuestiones:
1. Imaginemos un escenario activo-activo con CPDs separados unos 10Km, con balanceo por DNS y que ambos centros tienen un servidor DNS. Cuando un usuario solicita un servicio, su servidor DNS local no autoritativo consulta al de nuestra organización para la resolución.
¿A cuál de los dos servidores DNS se realiza la consulta, teniendo en cuenta que los CPDs están prácticamente en la misma zona geográfica?
¿Se realiza de manera indiferente, o establecen una comunicación entre sí nuestros servidores DNS para resolver la petición?
¿Tienen que contener ambos servidores DNS el conjunto de las direcciones IP de todos los equipos que ofrecen el servicio al que se desea acceder, o sólo las de las máquinas que se encuentran en su CPD?
2. En relación al primer enlace que has facilitado en tu respuesta, entiendo que en el balanceo por DNS sigue siendo necesario emplear un balanceador de carga para la granja de servidores web.
¿Qué papel juega en este escenario el balanceador, si el servidor DNS resuelve a la máquina adecuada en cada momento, lo que ya de por sí es realizar un balanceo? No acabo de ver el rol del balanceador para decidir el servidor que responderá a la solicitud.
3. Si sólo disponemos de un CPD, podríamos balancear haciendo uso, entre otras, bien de la técnica round robin o bien de la técnica NAT.
No acabo de ver la diferencia entre ambas, pues entiendo que al emplear round robin la consulta se realiza al balanceador, que contiene una IP virtual que es posteriormente traducida a la IP real del servidor que responderá a la petición, lo que en sí mismo ya consiste en realizar un nateo. Entonces, ¿cuál es la diferencia entre ambas técnicas?
4. ¿El balanceo por DNS se realiza únicamente en el caso de un balanceo global, o también en el caso de que sólo dispongamos de un único CPD? Esta duda me surge porque en otros blogs y foros, se habla de un único centro de datos en el que se realiza un balanceo de carga mediante un balanceador, aplicando la técnica DNS round robin, pero no sé si se trata de un mal uso de los términos, refiriéndose únicamente a un balanceo por round robin.
Personalmente, siempre he entendido que en este escenario de un único CPD, el servidor DNS de nuestra organización realiza un mapeo a una IP virtual del balanceador de carga, el cual redirige la solicitud a un servidor web en cada momento según una política de round robin. ¿Es correcto, o hay algo en lo que estoy equivocado?
5. Esta última duda no tiene tanto que ver con el balanceo, pero me ha surgido a raíz de un escenario con 2 CPDs pertenecientes a una misma organización.
¿Constituiría cada CPD un Sistema Autónomo independiente, o sería uno único al tratarse de la misma organización?
En caso de que estuvieran conectados los CPD según una LAN extendida, ¿serían en este caso un mismo Sistema Autónomo, o cada CPD tendría su propio Sistema Autónomo?
Muchísimas gracias por adelantado, y por todos los conocimientos que nos transmites en tu blog.
Un saludo,
Jorge.
Buenas Jorge,
RépondreSupprimer1 - La consulta DNS se realizará contra una sola IP, es decir, contra un solo servidor de DNS, otra cosa es que los tengamos replicados y en cluster por si cae uno de ellos.
2 - En este segundo caso, el balanceo por DNS podrá decidir qué CPD o balanceador responderá las peticiones, y este último balanceador distribuirá la carga entre los servidores reales. Este segundo balanceador tiene sentido cuando queremos "garantizar" la alta disponibilidad de los servicios en cada CPD. Imagina que tan solo tenemos un servidor real en cada CPD, no tendría mucho sentido enviar todas las peticiones al otro CPD cuando se caiga el nodo real, aunque técnicamente se podría hacer.
3- Round Robin se utiliza para balancear, pero NAT tiene otro cometido. Podría utilizar las dos técnicas en un solo escenario de balanceo.
4 - El balanceo por DNS lo podrías utilizar tanto a nivel global como si sólo dispones de un CPD. Por ejemplo, si el cliente solicita el dominio premium.x.com se le puede redirigir a una granja de servidores, mientras que si solicita el dominio gratis.x.com se le redirigirá a otra granja de servidores distintas.
5 - Dependiendo con quién y cómo tengas contratado el servicio de acceso a Internet tendrás un Sistema Autónomo o dos. Por ejemplo si tienes dos proveedores puedes pertenecer a dos Sistemas Autónomos fácilmente, en cambio si tan solo tienes un proveedor probablemente pertenezcas a un solo Sistema Autónomo. Otra opción es que tu organización tenga un Sistema Autónomo propio.
Muchas gracias por los comentarios y perdona por la brevedad.
Saludos.
David
Hola David.
RépondreSupprimerMuchas gracias por tus respuestas, me han aclarado aún más algunos conceptos.
Un saludo,
Jorge.