Hoy día el éxito de muchas empresas depende en gran medida de su presencia en internet y de que los usuarios tengan buena experiencia al visitarla (a través de la web, se entiende).
Así pues, nuestros servidores deben dar el mejor servicio a todos los usuarios y tener la máxima disponibilidad, a poder ser, estar todo el tiempo disponibles (24/7).
Cuando un sitio no está disponible se dice que se ha caído o sufre un problema de no-disponibilidad, que pueden ser de dos tipos:
- Tiempo de no-disponibilidad programado.
- Tiempo de no-disponibilidad no programado.
Sólo debería haber ”tiempos de no-disponibilidad programados” y lo más cortos posibles, debidos por ejemplo a actualizaciones del SO, de aplicaciones o de hardware, pero siempre algo que nosotros hayamos planificado y controlemos.
Existe una medida (porcentaje) de la disponibilidad de un sistema. Se llama escala “punto nueve” y se calcula como sigue:
100 – (tiempoCaido / periodoTiempo) * 100
Normalmente se suele referir al tiempo de un año. Actualmente, los sitios web se conforman con alcanzar un 99.9% (8.76 horas de caída al año) ó 99.99% (52.56 minutos de caída al año).
En la página http://www.edgeblog.net/2007/in-search-of-five-9s/ podemos encontrar un buen artículo ilustrando con un ejemplo detallado esta métrica. Recomiendo leerlo con atención.
¿Cómo podemos mejorar la disponibilidad?
Básicamente usando subsistemas redundantes y monitorizándolos. Casi cualquier elemento hardware del servidor puede fallar: CPU, memoria, discos, placas, etc. Por eso, existen productos específicos en el mercado con cualquier elemento duplicado.
Otra alternativa es configurar los servidores con redundancia mediante el software.
En cuanto a la escalabilidad, es un concepto que se refiere a la capacidad de un sistema de manejar la carga, y el esfuerzo para adaptarse al nuevo nivel de carga.
Esos cambios en el nivel de carga puede deberse a varios motivos, como por ejemplo:
- Cambios en las aplicaciones
- Fallos o caídas de algunas partes del sistema
- Incremento del número de máquinas
- Incremento repentino del número de usuarios del sitio
El incremento de peticiones o de usuarios puede ocurrir al ganar popularidad, o si llega una fecha señalada (campaña de ventas de Navidad, p.ej.).
Para manejar esos nuevos niveles de carga, podemos añadir más recursos al sistema web. En ocasiones, si la CPU del servidor está al 95% todo el tiempo (sobrecarga), cambiándola por otra mejor puede ser suficiente para cierto nivel de carga. Pero si más adelante hay más carga, acabará siendo insuficiente, y la solución finalmente será reestructurar la organización del sistema completo.
Vemos que hay dos tipos de escalado:
- Ampliación vertical: incrementar la RAM, CPU, disco de un servidor.
- Ampliación horizontal: añadir máquinas a algún subsistema (servidores web, servidores de datos, etc).
¿Cómo podemos analizar la sobrecarga?
Si la CPU está cerca del 100% todo el rato y el resto de subsistemas no está sobrecargado, sustituir por una CPU más potente. Por otro lado, si el uso de RAM es muy alto, veremos un uso alto de disco (por swapping). Incrementando la cantidad de RAM mejoraremos el rendimiento. Finalmente, un ancho de banda insuficiente afectará al rendimiento, y simplemente contratando una mejor conexión será suficiente.
Para escalar un sistema web, deberemos configurar una granja web balanceando la carga. Se trata de un proceso complejo (más que instalar y configurar un servidor solo, obviamente), en el que hay que preparar las aplicaciones para distribuir la carga entre las diferentes máquinas, configurar la red para soportar un tráfico creciente, y posiblemente configurar el balanceo de carga para formar un cluster web para cada servicio.
Finalmente, en este tema hemos planteado los siguientes ejercicios:
Ejercicio T2.1: Calcular la disponibilidad del sistema descrito en edgeblog.net si tenemos dos réplicas de cada elemento salvo para el centro de datos (en total 3 elementos en cada subsistema).
Ejercicio T2.2: Buscar frameworks y librerías para diferentes lenguajes que permitan hacer aplicaciones altamente disponibles con relativa facilidad. Como ejemplo, examina PM2: https://github.com/Unitech/pm2 que sirve para administrar clústeres de NodeJS.
Ejercicio T2.3: ¿Cómo analizar el nivel de carga de cada uno de los subsistemas en el servidor? Buscar herramientas y aprender a usarlas.
Ejercicio T2.4: En este ejercicio debemos buscar diferentes tipos de productos: (1) Buscar ejemplos de balanceadores software y hardware (productos comerciales). (2) Buscar productos comerciales para servidores de aplicaciones. (3) Buscar productos comerciales para servidores de almacenamiento.
Como comentaremos en prácticas, la entrega de los ejercicios de clase se realizará también en el repositorio personal que cada cual mantenéis en github.com, en una carpeta que podemos llamar "ejercicios_de_clase".
No hay comentarios:
Publicar un comentario