Práctica 3: Balanceo de carga

La Práctica 3, que hemos comenzado esta semana, tiene como objetivo aprender a diseñar y configurar una granja web con balanceo de carga.

Para ello utilizaremos los servidores configurados en la práctica 2 a modo de servidores finales (los que quedan detrás del balanceador) y necesitaremos instalar una nueva máquina Linux M3 en la que inicialmente sólo instalaremos el servicio SSH (NO instalaremos el software Apache, ya que usaría el puerto 80, que debe estar libre para que el software de balanceo reciba las peticiones HTTP.

La estructura de la granja será la que vemos arriba a la derecha en la siguiente imagen:

Conviene tener en cuenta los cuatro puntos relativos a la M3 indicados a la izquierda.

Para esta práctica, como parte obligatoria, usaremos nginx y haproxy como software de balanceo.

Debemos tener en cuenta que sólo uno de ellos puede estar en ejecución en un momento dado (ocupando el puerto 80). Así pues, antes de instalar, configurar y lanzar el otro, debemos asegurarnos de que el primero está "apagado".

Una vez que tengamos configurado el software de balanceo en M3 podemos hacer peticiones desde la línea de comandos usando la herramienta curl a la dirección IP del balanceador (no a las IP de las máquinas servidoras finales). Realizando varias peticiones comprobaremos que el balanceador está reencaminando el tráfico a cada servidor final de acuerdo con el algoritmo de balanceo configurado.

Los pasos para llevar a cabo la configuración y pruebas de ambos programas se ofrecen en detalle en el guión de la Práctica 3.

Tema 3 de teoría: La red de una granja web (SWAP2016)

El diseño y construcción de una red segura y escalable es fundamental para cualquier servidor. Si la red no está bien estructurada, los servidores no podrán servir la información como deben. Así pues, el administrador del sistema debe analizar las opciones de conexión a Internet y diseñar la estructura de red, separando las subredes corporativas y también conectando a redes privadas de proveedores.

Todas estas decisiones de diseño implican un estudio del hardware (switch, hub, router, balanceador, etc) y aplicaciones software disponibles (sistema operativo, monitorización, balanceo, etc) para realizar una configuración de la red adecuada, eligiendo el modelo de red más adecuado, el hardware, estructurando la red aislando subredes, y definiendo los puntos de entrada a las diferentes subredes.

En este sentido, es importante configurar una zona restringida, aislada y totalmente controlada (llamada DMZ, demilitarized zone) para controlar los servicios y aplicaciones ofrecidos a otras redes externas. Aunque existen diversas configuraciones, la más adecuada es la de DMZ doble, cuya organización se muestra a continuación:



Esta configuración tiene las siguientes características:

• El DMZ tiene un front-rail y un back-rail.
• El delantero es un segmento de red conectado a Internet.
• Los servidores quedan protegidos con el cortafuegos.
• El trasero está conectado a la subred interna (segura), y protegido con otro cortafuegos.

En la figura anterior vemos que algunas máquinas están conectadas al fron-rail y back-rail (necesitan doble tarjeta de red para acceder a Internet y servidores internos). Otras están conectadas sólo al front-rail (necesitan sólo una tarjeta de red para ofrecer servicios sólo hacia Internet y sus servicios quedan aislados) o sólo al back-rail (necesitan sólo una tarjeta de red, no tienen acceso a Internet, y dan servicios a las redes corporativas/seguras).

Finalmente, hacia el final del tema hemos visto que la calidad de la conexión a Internet depende de varios factores: calidad del servicio y ancho de banda, filtrado y bloqueo de paquetes, y network address translation.


En clase planteamos los siguientes ejercicios:

• Ejercicio T3.1: Buscar con qué órdenes de terminal o herramientas gráficas podemos configurar bajo Windows y bajo Linux el enrutamiento del tráfico de un servidor para pasar el tráfico desde una subred a otra.

• Ejercicio T3.2: Buscar con qué órdenes de terminal o herramientas gráficas podemos configurar bajo Windows y bajo Linux el filtrado y bloqueo de paquetes.

La entrega de los ejercicios de clase se realizará en una carpeta llamada "trabajos_de_clase" que cada cual mantendréis en vuestro repositorio de la asignatura en github.com

Práctica 2: Clonar la información de un sitio web

Hemos comenzado la práctica 2, en la que queremos realizar el clonado de la información de un servidor web principal sobre otro secundario (p.ej. de respaldo). De esa forma, en caso de desastre, podríamos sustituir el servidor principal (de producción) por el secundario y continuar trabajando en pocos minutos.

Los objetivos concretos de esta segunda práctica son:

• aprender a copiar archivos mediante ssh
• clonar contenido entre máquinas
• configurar el ssh para acceder a máquinas remotas sin contraseña
• establecer tareas en cron

En esta práctica usaremos dos máquinas (virtuales): el servidor principal o M1, y servidor secundario o M2.

En ambas vamos a tener una instalación del sistema operativo similar, así como de los servicios, y lo que haremos será mantener idénticos los espacios web en ambas máquinas.

Hemos explicado varias formas de hacer el clonado y mantener actualizado el espacio web en ambas máquinas, aunque la solución final será usar la herramienta RSYNC con las claves SSH y una tarea CRONTAB para automatizar todo el proceso.

Como se ha explicado en la sesión de prácticas, la clave SSH se crea en M2 y se copia a M1 (esto es muy importante), y la tarea crontab se configura en M2 para que ejecute el rsync y acceda a M1 para copiar las posibles modificaciones.

El guión de la práctica detalla todos los pasos y configuraciones necesarias.

Trabajar con git y github para la entrega de prácticas, trabajos y ejercicios

Aunque en la primera sesión de prácticas hemos explicado cómo trabajar con git y github, os recuerdo que en las siguientes URLs tenéis sendos tutoriales de introducción a git-github y a markdown:

http://swap-ugr.blogspot.com.es/2015/03/trabajar-con-git-y-github.html

http://swap-ugr.blogspot.com.es/2015/03/trabajar-con-markdown-en-github.html

Comenzamos las prácticas (SWAP2016)

Para configurar las estructuras necesarias en las prácticas de la asignatura usaremos máquinas virtuales, de forma que en cada ordenador personal dispondremos de los recursos necesarios.

Las máquinas virtuales correrán el sistema operativo Linux, y aunque se puede elegir la versión preferida, se recomienda una versión "Server", sin entorno gráfico, por el ahorro de recursos que supone.

Como herramienta de virtualización se permite utilizar aquella con la que tengamos cada cual más experiencia de uso (vmplayer, virtualbox, qemu, xen, virtual-pc, parallels, etc).

La versión server de Ubuntu se puede bajar de:
  http://www.ubuntu.com/download/server

En las siguientes prácticas necesitaremos al menos dos máquinas preparadas con la configuración inicial por defecto (LAMP server y OpenSSH instalados) y con una configuración de red que les permita a las máquinas virtuales conectarse entre sí (y a poder ser, también con el anfitrión).

Tras la instalación de cada máquina virtual conviene anotar la dirección IP que el software de virtualización le ha asignado. También se recomienda activar la cuenta de root en los sistemas instalados y disponer de la herramienta cURL para realizar más adelante peticiones HTTP.

Finalmente, y como se indicó en la presentación de la asignatura, la entrega de las prácticas se realizará en un repositorio público en la cuenta personal en github, utilizando el software de control de versiones git.

Tema 2: Alta disponibiliad y escalabilidad (SWAP2016)

Esta semana hemos comenzado el segundo tema de la teoría (no lo llegamos a terminar en la sesión de teoría del martes), en el que centraremos el estudio en los conceptos de disponibilidad y escalabilidad.

Para casi cualquier empresa resulta de suma importancia mantener su presencia en internet para ofrecer diversos servicios a los usuarios. Es por esto que nuestros servidores deben estar disponibles todo el tiempo que podamos (24/7).

Sin embargo, ningún sistema, por bien administrado que esté, está libre de sufrir caídas. Ese tiempo en que la máquina no dará servicio supone lo que se llama un problema de no-disponibilidad, que puede ser de dos tipos: tiempo de no-disponibilidad programado  o  tiempo de no-disponibilidad no programado.

Lo ideal es que sólo hubiera "tiempos de no-disponibilidad programados" y además, lo más cortos posibles, y siempre planificados y controlados por los administradores (actualizaciones del SO, de aplicaciones o de hardware). Sin embargo, el sistema tarde o temprano acaba sufriendo "tiempos de no-disponibilidad no-programados", debidos a ataques o fallos.

La forma de calcular la disponibilidad de un sistema se basa en la "escala punto nueve":
     100 – (tiempoCaido / periodoTiempo) * 100

Lo habitual es referirlo al periodo de un año, y actualmente los grandes sitios web se conforman con tener un 99.9% (8.76 horas de caída al año) ó 99.99% (52.56 minutos de caída al año).

Para ampliar esta parte, merece la pena leer con atención el artículo disponible en:
  http://www.edgeblog.net/2007/in-search-of-five-9s/

Existen estrategias y mejoras del sistema para mejorar la disponibilidad. Básicamente se trata de usar subsistemas redundantes y monitorizarlos todo el tiempo. Otra opción es configurar los servidores con redundancia mediante el software (p.ej. balancear servidores).


Por otro lado, la escalabilidad es un concepto que hace referencia a cómo el sistema maneja la carga, así como al esfuerzo para adaptarse a nuevos niveles de carga, que pueden deberse a:
 - 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

Para manejar adecuadamente esos diferentes niveles de carga se pueden añadir más recursos al sistema web (actualizar o mejorar el hardware, p.ej.). Sin embargo, si tras mejorar el hardware (puede suponer un coste alto) más adelante llegan cargas mayores, puede quedarse pequeño de nuevo, teniendo finalmente que reestructurar el sistema completo.

Existen dos tipos de escalado:
 - Ampliación vertical, que supone mejorar o incrementar alguna parte del hardware (RAM, CPU, disco de un servidor, etc).
 - Ampliación horizontal, que supone añadir máquinas a algún subsistema (servidores web, servidores de datos, etc).


Finalmente, en cualquier sistema resulta primordial analizar continuamente la carga para detectar a tiempo posibles sobrecargas. Así, si la CPU está cerca del 100% todo el rato y el resto de subsistemas no está sobrecargado, puede ser suficiente con sustituir la CPU antigua por una más potente. Si el uso de RAM es muy alto, veremos un uso alto de disco (por swapping), por lo que incrementando la cantidad de RAM mejorará el rendimiento. Además, un ancho de banda muy bajo puede afectar al rendimiento, y simplemente incrementándolo (contratando una mejor conexión) será suficiente para mejorar las prestaciones del sistema.

Como se comentó en el Tema 1, el escalado más adecuado de un sistema web que debe aceptar altas cargas pasa por configurar una granja web con balanceo de carga. Será un proceso complejo y habrá que preparar las aplicaciones, configurar la red para soportar un tráfico creciente, y configurar el balanceo de carga entre diversos servidores, pero será la forma en que nuestro sistema será escalable y tendrá alta disponibilidad.


En clase planteamos los siguientes ejercicios:

Ejercicio T2.1: Calcular la disponibilidad del sistema descrito en edgeblog.net si en cada subsistema tenemos en total 3 elementos.

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: 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.

La entrega de los ejercicios de clase se realizará en una carpeta llamada "trabajos_de_clase" que cada cual mantendréis en vuestro repositorio de la asignatura en github.com