Presentación de trabajos de los alumnos. 7 de junio (prácticas)

"Ataques DDoS"

En este trabajo se explica qué son los ataques de denegación de servicio (DDoS) y los diferentes tipos que hay (que englobamos en 3 grandes ramas). Además se comentan algunos de los ataques más famosos y con más impacto, también se habla de las sanciones y las leyes que existen frente a estos ataques. Como curiosidad se muestra quienes pueden hacer estos ataques y cómo hacerlos. Por último, se hace una especie de reto para enseñar cómo defenderse contra estos ataques contratando un servicio para realizar ataques usándolo contra nuestro propio servidor configurando IPTABLES y modificando algunas configuraciones del kernel, y más adelante tras varios intentos fallidos configurando Cloudflare que finalmente consigue mitigar el ataque.

Repositorio:
https://github.com/ajpelaez/SWAP/tree/master/trabajo_final


"Seguridad sobre servidores web Apache"

Este trabajo se divide en tres partes: configuración de apache para reforzar su seguridad, partiendo desde otro punto de vista (el de los 'malos') y cómo reaccionar ante un ataque a nuestro servidor web. En la primera parte se citan unos consejos básicos antes de poner en marcha nuestro Apache y despleglarlo en producción. También se indican una serie de configuraciones sobre ciertas directivas de apache, que nos servirán para ocultar información relevante para posibles atacantes y denegar el acceso a directorios que especifiquemos. La segunda parte comienza definiendo una serie de conceptos relacionados con la seguridad informática que posteriormente se usarán en la presentación. Sabiendo la versión de un servidor web podemos encontrar una serie de bugs que nos permitan realizar una intrusión mediante exploits personalizados. Por último, algo que la mayoría de los administradores de sistemas han sufrido, un ataque sobre nuestras máquinas. Podemos intentar seguir la huella de éste mediante los logs, restablecer el servicio y solucionar la brecha de seguridad lo antes posible.

Presentación:
https://speakerdeck.com/jslirola/seguridad-en-servidores-web-apache
Repositorio:
https://github.com/jslirola/SWAP-UGR


"Configuraciones básicas de seguridad para Nginx y Apache"

En este trabajo se han configurado distintos tipos de seguridad que podemos aplicar a los servidores web nginx y apache. Para Nginx se ha centrado en el control de acceso de HTTP, ocultar la firma y versión del servidor, establecer límites para el buffer y el tiempo de espera, limitar el número de conexiones por IP, configurar la seguridad para PHP y, crear y configurar el certifcado SSL. Para Apache se muestra cómo ocultar la firma y la versión del servidor, deshabilitar el HTTP-Trace, y configurado el ModSecurity. Finalmente, en Apache se ha hecho una prueba para defendernos de ataques de SQL-Injection.

Repositorio:
https://github.com/Andresgp1991/Servidores-web-de-altas-prestaciones/tree/master/Trabajo


"Comparación entre servidores web en Android"

El trabajo ha consistido en realizar una comparación de varios servidores web instalados en móviles con sistema operativo Android. Se han instalado tres servidores web, dos gratuitos y uno de pago (aunque con cinco días de prueba) para analizar sus diferencias en cuanto al uso, ya sea, facilidad para manejar, amplitud de opciones a realizar en cada uno o interfaz más adecuada. Los servidores elegidos son: Palapa Web Server, kWS y KSWEB. Como resultado final del trabajo se han realizado pruebas con apache benchmark, similares a las realizadas en la práctica 4 de SWAP, para poder compararlos entre sí, mostrando gráficas de los resultados para que sea más fácil de visualizar, y usando de la aplicación PowerTutor se ha medido el consumo de las tres aplicaciones sobre la CPU.

Repositorios:
https://github.com/jqueror/SWAP/tree/master/trabajo
https://github.com/Jalg/SWAP/tree/master/Trabajo_exposicion


"node.js: Javascript for scalable web servers"

node.js es un nuevo competidor en el entorno de los servidores web. Esta nueva tecnología utiliza Javascript como lenguaje base para implementar software/servicios flexibles y asíncronos. En este trabajo se describen las etapas de instalación de un servidor Node.js, analizamos algunas plantillas de código, y comparamos las prestaciones con otros servidores web como Apache. Node.js escala a través de la librería Clustering para gestionar procesos con más hebras y permitir proporcionar el servicio a todavía más clientes.

Presentación: http://slides.com/davidegallitelli/deck/fullscreen#/
Repositorio GitHub: https://github.com/UGR2015IT/SWAP/tree/master/trabajo_final


"Modern Honey Network"

Este trabajo trata de los Honeypots, que son máquinas con software especializado en simular vulnerabilidades para atraer a atacantes y poder fijar su atención el este señuelo y poder evitar una intrusión, e incluso desvelar las intenciones de éste. Veremos MHN, el cual es posible tener como servidor para monitorizar toda la red de sensores que despleguemos y centralizar toda la información necesaria para saber qué está pasando en nuestras "trampas". Los sensores que instalaremos serán Dionaea y Suricata, aunque hay muchas más posibilidades.

Repositorio:
https://github.com/pablovilchezg/SWAP1516/tree/master/Trabajo_Honeypot

Presentación de trabajos de los alumnos. 7 de junio (teoría)

"Netflix OpenConnect Appliance"

Hemos hablado de Netflix y de como está montado sus servidores y como estos distribuyen su contenido multimedia. Hemos definido que era Netflix y en que está basado. Está basado en Amazon (su tecnología web) y el corazón de Netflix se encuentra ahí, en el centro de datos de Amazon. También hemos explicado lo que es OpenConnect y que gracias a esto, Netflix ha implementado sus propios servidores. Los llamado OCA (OpenConnect Appliance). Para que Netflix funcione, tiene asociaciones con proveedores de internet para cederle estos OCA. Tienen su red de distribución de contenido multimedia. Hemos explicado como Netflix transfiere el contenido entre servidores para que el archivo esté en el servidor adecuado en el momento adecuado. Y por último, hemos hablado de los OCA en sí. Tienen instalado el Nginx y también el FreeBSD. Hay varias versiones de los servidores OCA. Rev A, Rev B y Rev C y hemos estado comparando las características entre ellos.

Repositorio:
https://github.com/Maverick94/swap1516/tree/master/trabajos/trabajo_asignatura_netflix


"Bases de Datos Distribuidas"

Este trabajo presenta una pequeña introducción tanto a la parte teórica de las Bases de Datos Distribuidas como a la parte práctica de estas: ventajas y desventajas, y qué es un SGBD y para qué se utiliza. Se detallan los tipos de fragmentación posibles (Vertical, Horizontal y Mixta), y cuándo es conveniente utilizar una BDD u otro tipo de BD. También las configuraciones de red comunes en las Bases de Datos Distribuidas (Totalmente conectada, parcialmente conectada, estrella, árbol y anillo). Finalmente se explican las estructuras de datos útiles, con ejemplos de implementación de éstas, vistas, procedimientos, disparadores (Trigger) e índices.

Repositorio:
https://github.com/jmbarranco/SWAP1516/tree/master/TrabajoSWAP


"OSSEC (sistema de detección de intrusos)"

Este trabajo se presenta la herramienta open-source OSSEC. Es un HIDS, que básicamente es un IDS (Intrusion Detection System) con la arquitectura de cliente servidor. Las principales características de OSSEC son: monitorizar elementos del sistema (log, procesos, archivos, puertos, interfaces, etc); alertar, ya sea via log o via email, de las posibles amenazas que se detecten. Es multiplataforma (Linux, Windows, Mac, Solaris, AIX, etc), y ayuda a cumplir el estándar PCI DSS. En el trabajo explicamos las fases del proceso que sigue OSSEC para analizar un log, y vemos como es un decoder y una regla.

Repositorio:
https://github.com/fjfernandez93/swap1516/tree/master/trabajo


"Cloud Computing - Azure y Bluemix"

Este trabajo se ha centrado en un análisis de dos de las grandes empresas y servicios relacionados con el Cloud Computing. Se ha realizado una pequeña introducción sobre el cloud computing, su historia e implicaciones en la actual sociedad de la información. Tras esto, una breve presentación tanto de Azure como de IBM Bluemix, tras la cual pasamos al meollo de la cuestión, dando información sobre los precios, servicios ofrecidos, y  un pequeño "get started" sobre ambos sistemas, donde tras explicar los pasos necesarios para comenzar a trabajar con ellos, se despliegan un servidor web y dos pequeñas apps, una sobre Twitter y un chat. Ambos son funcionales y están accesibles a través de los enlaces que se encuentran más abajo.

Repositorio:
https://github.com/joseangeldiazg/SWAP_ugr/tree/master/Trabajo
Chat: http://chat-swap.mybluemix.net/chat
Servidor web: http://swapweb6667.cloudapp.net


"Balanceadores de Carga y Algoritmos de Balanceo"

Nuestro trabajo trata sobre Balanceadores de Carga. Recordamos qué es un Balanceador y las características que tienen, así como los algoritmos que usan para balancear la carga (Round Robin, Least Connections, Tiempo de Respuesta, por Prioridad, por Ponderación, etc.). Explicamos e intentamos la instalación de ZenLoadBalancer y Octopus, ambos balanceadores de carga, aunque de Octopus no lo conseguimos. Para ZenLoadBalancer explicamos cómo se instala y sobre todo exploramos la interfaz que tiene propia para poder asignar los parámetros y controlar el estado de la granja web, así como todo el proceso de configuración. Para Octopus damos información sobre la configuración, pero no está verificada con las nuevas versiones, ya que con las nuevas versiones no hemos conseguido instalarlo ni configurarlo.

Repositorio:
https://github.com/moulayrchid/swap1516/tree/master/TRABAJO-SWAP


"Convertir Equipo en Router (HostAPd)"

Este trabajo consiste en convertir un ordenador, con tarjeta de red wifi, en un router capaz de crear una red local que permita las conexión de otros equipos a la misma y su correspondiente suministro de servicio de internet a las ips pertenecientes a la red. Dicho trabajo será realizado con un "Raspberri Pi 3 Model B" con una tarjeta de red que sigue el modelo "IEEE 802.11", bajo el sistema operativo "Raspian", que es un sistema basado en Debian. También sería posible realizarlo con cualquier otro equipo con un sistema Debian y que disponga de una tarjeta de red con el modelo antes mencionado.

Repositorio:
https://github.com/josemi777/SWAP/tree/master/Trabajo


"Optimización, recomendaciones y herramientas de análisis de sitios webs"

En este trabajo se enumeran diferentes buenas prácticas para la optimización en la carga de sitios webs pesados, mostrando sus diferencias y progresos en tiempos de carga de la página web así como la experiencia del usuario.También se van a realizar algunas optimizaciones en el servidor apache que utilizaremos durante este trabajo. Aunque en las fechas en las que nos encontramos la velocidad de descarga de internet no tiene nada que ver con lo que era hace unos años, las webs de hoy en día cada vez tienen más contenido visual , lo cual hace que tenga una mayor demora a la hora de poder visualizar la página web. En este apartado se redactarán algunas de las buenas prácticas más utilizadas para que un sitio web sea más óptimo, y cargue más rápido. Como norma general un sitio web no puede tardar más de 5 segundos en cargar, una web lenta puede desesperar al usuario que la está visualizando y por lo cual la abandonará.

Repositorio:
https://github.com/pctmoreno/SWAP/tree/master/Trabajo

Presentación de trabajos de los alumnos. 6 de junio

"Sistema de archivos Lustre"

Lustre es un sistema de archivos distribuido capaz de aportar la escalabilidad, el rendimiento y la robustez que los mejores supercomputadores existentes exigen. Nacido como proyecto de investigación universitario, ha cambiado de manos varias veces de manos hasta ser, actualmente, opensource. Es la mejor opción, si consigues instalarlo...

Repositorio:
https://github.com/Loadge/SWAP1516/blob/master/Lustre-Memoria.pdf


"Configuración de un DMZ con IPCOP"

Mediante el cortafuegos IPCOP, se ha realizado la implementación de un DMZ simple usando 4 máquinas virtuales. Para la realización de esta práctica se ha necesitado la previa descarga del cortafuegos IPCOP y la instalación de 4 máquinas virtuales. Cada máquina virtual la adjudicamos a 4 zonas distinguidas.

Repositorios:
https://github.com/guillesiesta/swap_1516/tree/master/trabajos_clase
https://github.com/juanmartinquiros/swap1516


"Ataques a servidores WEB"

En este trabajo se detallan los ataques a servidores más comunes: DoS & DDoS, SQL Injection, Fuerza Bruta y Cross-SIte Scripting (XSS Attacks). De cada uno se han abordado los siguientes puntos: Tipo de ataque (breve descripción), cómo se realizan (métodos) y cómo protegernos (instrucciones de seguridad). Como último punto se han añadido los enlaces de los cuales se ha recabado y resumido la información, por si se desea obtener más información.

Repositorio:
https://github.com/ADoncel/SWAP/tree/master/trabajo_final_teoria


"Granja Web con Raspberry Pi"

En este trabajo se presenta la construcción de una Granja Web utilizando Raspberry-Pi. Para ello hemos configurado tres Raspberry-Pi para que actúen como servidores y otra cuarta Raspberry para usarla como balanceador de carga. Una vez configuradas las raspberrys, y comprobada la conexión entre ellas, hemos realizado diferentes medidas de rendimiento, usando para ello los benchmark vistos en prácticas (Siege, ApacheBenchmark y OpenWebLoad). Además hemos realizado réplicas de datos y de MySQL. Por último, para darle uso a nuestra Granja Web, hemos decidido usar WordPress y crear un ¡Hola Mundo!

Repositorios:
https://github.com/marlenelis/SWAP1516/tree/master/TrabajoFinal
https://github.com/espe90/swap/tree/master/TrabajoFinal

Presentación de trabajos de los alumnos. 3 de junio

"Ataques en servidores web"

En este trabajo se ha hablado sobre ataques a servidores web, en concreto, ataques DOS, DDOS, fuerza bruta, cross site scripting e inyección SQL. De los primeros se da una visión teórica debido a la dificultad para llevarlos a la práctica, y del último se realiza una demostración apoyada en la distribución Kali Linux y su herramienta sqlmap.

Repositorio:
https://github.com/FranGS/swap1516/blob/master/TrabajoFinal/trabajo.md


"websockets: Sockets en la Web"

Este trabajo está basado en el uso de WebSockets, siendo éstos una tecnología que nos permite abrir una comunicación bidireccional, con baja latencia, y basada en el protocolo TCP. Se trata de una solución ideal para juegos en tiempo real, notificaciones instantáneas de redes sociales, aplicaciones de monitorización, herramientas de trabajo colaborativo o incluso información meteorológica. En resumen, podemos tener en cuenta los WebSockets en aplicaciones que requieren una transferencia de datos segura y rápida. Se muestra un ejemplo de uso real como es el caso de WhatsApp Web, así como la implementación de un chat basado en una API de PHP. Los archivos de implementación y diseño del chat así como de la API en PHP se encuentran en el repositorio indicado, por si alguien lo quiere "tunear"

Repositorios:
https://github.com/NiKaJim/SWAP/tree/master/TRABAJO%20WEBSOCKETS
https://github.com/maribhez/SWAP_UGR/tree/master/Trabajo


"Memcached"

En este trabajo se detalla qué es la Memcached, su funcionamiento, así como los resultados que tiene su uso a través de una batería de pruebas. Para dichas pruebas se ha realizado un benchmark de un servidor local con la herramienta AB, primero sin hacer uso de la memcached, y posteriormente haciendo uso de ella. Se han realizado estás pruebas 10 veces. Posteriormente se ha calculado la media de los valores más importante de la herramienta AB, véase "Request per second" y "Time taken for tests". Una vez realizada esta batería de pruebas y tal y como se refleja en el trabajo, se concluye que el uso de la memcached hace que se reduzca el valor "Time taken for tests".

Repositorio:
http://github.com/josegob/swap1516


"HOSTING WEB, CLOUD COMPUTING"

Este trabajo, centrado en el "Hosting Web", consta de 3 partes: En 1º lugar, la definición y características de el "hosting web" incluyendo en esta parte también los distintos tipos de hosting , sus diferentes servicios, comparándolos entre sí, con sus ventajas e inconvenientes, además de una comparativa "práctica" en la que según sus necesidades necesitaría elegir un hosting u otro. En 2º lugar hemos estudiado el "Cloud Computing", diferenciando los distintos tipos y servicios que puede ofrecer el mismo, así como las ventajas y los inconvenientes que tiene este tipo de "hosting web". En 3º lugar hemos hecho una demostración práctica de cómo montar un servidor de "Cloud Computing" de almacenamiento en la nube con el software libre de OwnCloud.

Repositorio:
https://github.com/carlillostole/Carlillostole-swap/tree/master/TRABAJO_FINAL


"MEMCACHED"

Memcached es un sistema de memoria caché distribuida de objetos en memoria RAM para sistemas web.
En el trabajo se explica qué es y cómo se implementa memcached. También se explican las funciones básicas de su API. Mostramos los pasos necesarios para la instalación, para poder probar algunos ejemplos de uso. Y finalmente se comentan las ventajas o beneficios que se consiguen al añadir memcached a un sistema web.

Repositorios:
https://github.com/mapbatanero/swap/tree/master/trabajo_memcached
https://github.com/jomoca/swap1516/blob/master/Trabajo%20Memcached/Memcached.pdf

Presentación de trabajos de los alumnos. 2 de junio

"Proceso de creación y despliegue de una aplicación web completa en la plataforma OpenShift"

En nuestro trabajo hemos hablado sobre qué es openshift, un servicio PAAS de cloud computing que permite crear aplicaciones en la nube tales como Wordpress, PHP, etc. Mostramos sus ventajas e inconvenientes, de como crear aplicaciones en nuestra cuenta, así como que necesitamos tener en nuestra máquina instalado para poder editar dichas aplicaciones. Otro tema que hemos tratado ha sido el de la creación de un wordpress y como instalarlo.

Repositorios:
­https://github.com/accnono/SWAP1516
https://github.com/GinesNC/SWAP/tree/master/Trabajo%20SWAP


"NAS casero en una raspberry pi 3 raid 0"

Este trabajo consiste en la creación de un RAID 0 junto con su correspondiente configuración y la configuración de Samba para el NAS casero con una Raspberry-3. Se ha instalado y configurado SAMBA para terminar la configuración del NAS. En este caso, se ha permitido acceso público. La conexión se realiza mediante el acceso en el explorador de archivos a la URL  smb://IP-RASPBERRY

Repositorios:
https://github.com/antoniovj1/servidores_web_altas_prestaciones_ugr
https://github.com/viictorvm/Servidores-de-Altas-Prestaciones

Presentación de trabajos de los alumnos. 31 de mayo

"SEGURIDAD EN SERVIDORES HTTP EN APACHE. GENERACIÓN DE CERTIFICADOS SSL"

Este trabajo trabajo trata sobre la seguridad en los servidores HTTP Apache. Primero se habla de las características más importantes de Apache y de las de un servidor web en general, además de algunos problemas de seguridad que tuvo este servidor web en sus versiones más antiguas. También se habla sobre algunas de las muchas directivas que podemos usar y modificar para una correcta configuración del servidor y tener una alta seguridad. Por último se habla de los certificados SSL, como crearlos y su configuración.

Repositorio:
https://github.com/Manucall/SWAP15-16/blob/master/Presentacion/memoria.pdf
http://pavocejudo.github.io/#/

Presentación de trabajos de los alumnos. 30 de mayo

"Tipos de Servidores y cuál elegir"

En este trabajo se presentan diferentes tipos de alojamiento web (hosting) como alternativa a instalar, configurar y administrar un servidor web propio. Concretamente, se analizan los pros y contras de los servidores dedicados, servidores dedicados administrados, hosting compartido, VPS (Servidores Privados Virtuales), hosting gratuito y alojamiento Web en "la nube".

Repositorio:
https://github.com/pegons/swap2016/tree/master/trabajo%20final


"Granja web con balanceo de carga bajo Windows Server 2012"

En este trabajo explicaremos como montar una granja web con un balanceador de carga con tecnología de Microsoft en máquinas Windows Server 2012 así como los pros y los contras a los que hemos llegado llevando a cabo dicha instalación. Para ello, se explicará paso a paso como instalar y configurar los servidores IIS, como realizar la creación y configuración de un dominio web mediante un servidor de DNS, la configuración e instalación del Network Load Balancing (NLB) y la creación de la granja web así como la creación de un Sistema Distribuido de Archivos (DFS) con el cual replicar el contenido web.

Repositorio:
https://github.com/Koltharius/UGR_Servidores_Web_de_Altas_Prestaciones/tree/master/Trabajo_Final

Presentación de trabajos de los alumnos. 24 de mayo

"Certificados SSL"

Introducción al estándar SSL, qué son los certificados SSL y para qué sirven así como los distintos tipos que hay, qué son las entidades certificadores, en qué consiste el proyecto Let's Encrypt y como se puede instalar un certificado SSL gratuito en apache con unos sencillos pasos.

Repositorio:
https://github.com/erseco/ugr_servidores_web_de_altas_prestaciones/tree/master/trabajo_final


"Infraestructura de Spotify Music"

Spotify es un modelo de servicio moderno que ha ido de menos a más en el tiempo para convertirse en un servicio escalable y altamente disponible. Para mantener su nivel de calidad alto para todos sus tipos de clientes, ha transformado en muchas ocasiones su modelo de almacenamiento, pasando de servicios comunes a una tipología de red P2P y finalmente a la nube con servicios más fiables como Amazon y Google.

Repositorio:
https://github.com/JaviMancilla/swap/tree/master/Trabajo%20Final


"Servidor de Almacenamiento NFS"

En este trabajo se propone la instalación y configuración de un servidor de almacenamiento NFS usando un equipo Ubuntu 14.04 con el servidor NFS, otro equipo Ubuntu 16.04 con el cliente NFS, otro equipo Ubuntu 14.04 con el cliente NFS, y un equipo Windows 10 con el cliente NFS. Se llevó a cabo una demostración conectando los 4 equipos en una red local creada a partir de un router sin conexión al exterior para hacer una prueba de funcionamiento creando y eliminando ficheros y carpetas.

Repositorio:
https://github.com/franfermi/SWAP/blob/master/Trabajo/ServidorAlmacenamientoNFS.pdf


"Instalación y configuración de Active Directory en Windows Server 2003"

Instalación y configuración de Active Directory en Windows Server 2003, dónde se han instalado y configurado los servicios de Active Directory, DNS, DHCP y Terminal Server. Además se ha creado un dominio y añadido a él un host Cliente XP. Después se han configurado varios usuarios y grupos de prueba, para acceder desde el host, y se le han asignado distintos permisos.

Repositorios:
https://github.com/Chentaco/asignaturaswap/tree/master/trabajo_SWAP_final
https://github.com/MiguelGonzalezAguilera/swap1516/tree/master/TrabajoFinal

Presentación de trabajos de los alumnos. 17 de mayo

"Asegurando IIS, Apache y Nginx. Previniendo ataques de diccionario: Fail2ban"

El trabajo gira en torno a la seguridad de servidores web. En primer lugar se habla sobre el IIS de Windows y en concreto se muestra como permitir tráfico o bloquearlo desde determinadas IPs al servidor web. A continuación configuramos el IIS de tal manera que a determinadas páginas web solamente puedan acceder los usuarios  pertenecientes a un grupo en concreto y para afinar un poco más, también mostramos cómo solamente permitir que un usario en concreto pueda acceder a una determinada web.
En segundo lugar hablamos sobre  Nginx como servidor web y empezamos tocando su configuración para que al dar un mensaje de error no muestre información de más. Además lo configuramos para que solamente acepte los métodos más comunes de HTTP y explicamos un poco la justifación de todo esto.
Para acabar mostramos el funcionamiento de Fail2ban que nos sirve de defensa ante ataques de diccionario; en concreto hacemos que fail2ban detenga un ataque de diccionario generado con Hydra sobre ssh.

Repositorio:
https://github.com/LuisGi93/swap2016/tree/master/trabajo


"Cloud Center Andalucía (Trevenque)"

En este trabajo se presentan diferentes aspectos a tener en cuenta para convertir una nave industrial vacía en un Cloud Center. Para ello, se contactó con la empresa Grupo Trevenque. Empresa fundada en Granada, hará unos 20 años, que cuenta con uno de los mejores Cloud Center de España (el Cloud Center Andalucía, CCA). Ellos facilitaron información sobre el CCA, que ayudó a hacer una idea de cómo debe ser un Cloud Center, tras entrevistarlos y mostrarnos sus instalaciones.

Repositorios:
https://github.com/naujgs/SWAP1516/tree/master/Trabajo
https://github.com/manuelalonsobraojos/swap1516/tree/master/Trabajo

Tema 7 de teoría: Almacenamiento de datos (SWAP2016)

Un subsistema clave en una granja web de altas prestaciones es el de almacenamiento de datos.

Conviene diseñarlo con mucho cuidado para asegurarnos la escalabilidad del sistema. Como vimos en un tema anterior, se pueden mejorar las prestaciones de un sistema (de almacenamiento también) usando:

• ampliación vertical (adquirir un mejor hardware más rápido y actualizado).
• ampliación horizontal (replicar el almacenamiento entre varios servidores), que resulta más efectivo en cuanto a la escalabilidad.

Puesto que el almacenamiento de los datos se llevará a cabo en BD, es crucial diseñar la arquitectura de BD teniendo en cuenta los siguientes puntos:

• El número de sesiones concurrentes en la BD puede afectar al rendimiento de la granja web completa (conexiones costosas).
• Una gran cantidad de accesos a la BD por cada petición HTTP puede sobrecargar la conexión de red entre los servidores web y de BD.
• Las búsquedas que devuelvan resultados muy grandes afectarán al rendimiento de CPU, almacenamiento y red.
• El tamaño total de la BD determinará el espacio para almacenamiento, y el tiempo necesario para hacer copias de seguridad y restaurarlas.
• Conviene utilizar hardware redundante para los servidores.
• Una BD se podrá escalar en el futuro si desde el principio se instaló hardware con capacidad de ampliación (CPU, memoria, etc) y se configuró el software de forma adecuada. En ese sentido, se recomienda una arquitectura de BD basada en un cluster.

Hacia el final de este tema hemos repasado la configuración de discos en RAID, una configuración muy adecuada para disponer de almacenamiento robusto, de alta capacidad y altas prestaciones.

RAID significa "conjunto redundante de discos independientes" y es un sistema que usa varios discos duros para distribuir o replicar los datos, ofreciendo mayor integridad, mayor tolerancia a fallos, mayor rendimiento y mayor capacidad. Esta tecnología permite combinar varios dispositivos para formar un conjunto con mayor capacidad, fiabilidad y velocidad que un solo dispositivo de última generación más caro. Existen RAID por hardware y por software. El primero es mucho más rápido, pero el último es mucho más flexible.

Hay diversos métodos de almacenamiento, llamados niveles, con diferente complejidad:

• RAID 0: Conjunto dividido
• RAID 1: Conjunto en espejo
• RAID 5: Conjunto dividido con paridad distribuida
• RAID 10 o RAID 1+0: División de espejos

Finalmente, en el tema hemos visto tres tipos de sistemas de almacenamiento especializado: SSA, NAS, SAN.

Arrays de almacenamiento compartido: SSA

• Dispositivos con unas especificaciones y herramientas propietarias de cierta empresa.
• Posee una interfaz para conectar los discos a las controladoras (normalmente SCSI).
• Número limitado de puertos para hacer la conexión entre servidores y almacenamiento.
• Se suele usar para disponer del almacenamiento necesario para archivos y BD en clusters.

Área de almacenamiento en red: SAN

• Conjunto de dispositivos interconectados (discos, cintas, etc.) y servidores conectados a un canal de comunicación e intercambio de datos común (concentrador de alta velocidad).
• Algunos de los dispositivos pueden ser SSA y NAS.

Almacenamiento conectado a la red: NAS

• Conjunto de discos organizados en un dispositivo de red con IP y que puede conectarse a una red Ethernet.
• Utilizando algún protocolo, como Internetwork Packet Exchange (de Microsoft), NetBEUI (de Microsoft), Network File System (NFS, de Sun) o IPE (de Novell).
• Aparece como otro servidor más en la red.

Nota:
En la siguiente entrada del blog se ofrecen diversos tutoriales para aprender a configurar dispositivos RAID bajo Linux, Windows y OS-X:
 http://swap-ugr.blogspot.com.es/2015/05/tema-7-de-teoria-almacenamiento-de-datos.html

Tema 6 de teoría: Asegurar el sistema web (SWAP2016)

La seguridad en un sistema web resulta de vital importancia para evitar posibles accesos a las máquinas y a los datos por parte de hackers malintencionados. En un sistema bien asegurado podremos determinar qué ocurre en cada momento y quién ha hecho cada cosa y en qué momento. Un sistema bien configurado nos asegurará los siguientes puntos:

• La confidencialidad, en el sentido de que las comunicaciones deben ser secretas.
• La integridad, de forma que los mensajes enviados deben ser exactamente los recibidos.
• La disponibilidad de los servicios del sistema (no deben verse afectados por posibles ataques).

En este tema tratamos varios conceptos: defensa en profundidad, políticas de seguridad, asegurar el servidor, configuración del cortafuegos, y prácticas de seguridad recomendadas.

El concepto de defensa en profundidad hace referencia a la configuración de varias capas de defensa para defender el sistema a varios niveles. De esta forma se dificulta el acceso último del hacker malicioso a los servidores, haciendo que sea más probable detectar un ataque, y así evitar que las últimas defensas se vean comprometidas.

El proceso de asegurar el servidor implica establecer políticas de seguridad, que definen cómo interaccionarán los usuarios con los servidores del sistema web. Las políticas de seguridad definen procedimientos de identificación y acceso, que comprueban si un individuo es reconocido por los sistemas de seguridad. También los privilegios de uso, que definen qué acciones puede llevar a cabo cada tipo de usuario correctamente identificado.

Hemos comentado que se deben establecer y aplicar políticas a diferentes niveles y así establecer seguridad a nivel físico (que no lleguen hasta los servidores para robarlos), a nivel de red (evitar el acceso a través de comunicaciones por la red), a nivel de administrador (creando las cuentas de administrador adecuadamente), y a nivel de cuentas de servicios (o aplicaciones).

En el proceso de asegurar el servidor debemos eliminar diversos servicios innecesarios y otras fuentes de posibles vulnerabilidades. Concretamente debemos eliminar: características no necesarias, servicios, configuraciones e información de seguridad del servidor. Sólo dejaremos las aplicaciones, servicios y puertos imprescindibles.

Finalmente, una parte importante del proceso de asegurar el servidor es la configuración del cortafuegos. Este elemento de la red protege el sistema de accesos indebidos, haciendo de guardián del sistema, filtrando el tráfico de red (permitiendo cierto tráfico y denegando el resto). El software de cortafuegos por excelencia es iptables.

Un cortafuegos bien configurado evita el consumo excesivo de recursos, reduciendo el tráfico global que un servidor recibirá, oculta los servidores finales a otras redes, protege los servidores de múltiples ataques, oculta información de los servidores a otras redes, y avisa de posibles ataques justo en el momento en que se producen.

Por último, es importante tener un equipo de ingenieros con dedicación exclusiva a investigar temas de seguridad del sistema a todos los niveles para estar preparados ante posibles ataques. Estas personas deben conocer los temas relativos a la seguridad así como las vulnerabilidades a nivel de red, de cortafuegos, de sistema operativo y de las aplicaciones en el sistema web. Además, cuando se identifique una vulnerabilidad, los administradores de seguridad deben tomar las medidas de prevención necesarias para evitar que los posibles atacantes la puedan aprovechar.


En clase planteamos los siguientes ejercicios:

• Ejercicio T6.1: Aplicar con iptables una política de denegar todo el tráfico en una de las máquinas de prácticas. Comprobar el funcionamiento.
  

Aplicar con iptables una política de permitir todo el tráfico en una de las máquinas de prácticas. Comprobar el funcionamiento.

• Ejercicio T6.2: Comprobar qué puertos tienen abiertos nuestras máquinas, su estado, y qué programa o demonio lo ocupa.
  

• Ejercicio T6.3: Buscar información acerca de los tipos de ataques más comunes en servidores web, en qué consisten, y cómo se pueden evitar.
  

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


Recursos adicionales

Tutoriales sobre cómo configurar el cortafuegos en Linux con iptables:
  http://www.cyberciti.biz/tips/linux-iptables-examples.html
  http://www.linuxtotal.com.mx/?cont=info_seyre_002
  https://openwebinars.net/como-configurar-en-linux-firewall-basico-con-iptables/
  http://es.tldp.org/Manuales-LuCAS/doc-iptables-firewall/doc-iptables-firewall-html/

Sitios web especializados en seguridad:
  http://www.securitybydefault.com/
  http://www.pentester.es/
  http://www.elladodelmal.com/
  http://www.hackhispano.com/
  http://thehackerway.com/2014/05/21/21-blogs-sobre-seguridad-informatica-que-deberias-conocer/
  https://www.youtube.com/watch?v=w0SB6eAnx4Q&list=PL7C849047272B22E0

Tema 5 de teoría: Medir prestaciones (SWAP2016)

Tras configurar un sistema, del tipo que sea, debemos comprobar que dará las prestaciones esperadas. En este tema hemos explicado qué procesos y herramientas debemos usar para llevar a cabo la medición de prestaciones.

Como comentamos, no se trata de detectar posibles caídas o errores de programación, sino los problemas de rendimiento y degradación de prestaciones que puedan darse en el sistema cuando esté en producción. Buscamos los posibles cuellos de botella e ineficiencias antes de ponerlo en marcha de cara a los usuarios finales.

Para llevar a cabo estas tareas debemos tener en cuenta la dificultad que supone hacer pruebas en un entorno de producción, así como la imposibilidad de simular el comportamiento de los usuarios.

Habitualmente se utilizan tres métricas:

• Conexiones por segundo: número de conexiones de entrada que cierto dispositivo puede manejar por segundo (transacciones por segundo o sesiones por segundo).
• Número total de conexiones concurrentes: sesiones de usuario TCP que puede manejar el balanceador al mismo tiempo.
• Rendimiento (en bits por segundo): velocidad a la que un dispositivo maneja el tráfico; se mide en bits por segundo y es la combinación del "tamaño del paquete" y de los "paquetes por segundo".

Hemos estudiado que existe un límite del tráfico de red que produce una degradación en las prestaciones. Si se alcanza ese límite en un sistema, los tiempos de respuesta en las conexiones HTTP se degradan completamente, haciendo imposible la conexión. Es importante monitorizar el sistema para detectar este comportamiento, que se ve claramente en gráficas como las que siguen:

Cuando se alcanza el límite y el sistema deja de responder como se espera, las prestaciones caen (el sistema deja de dar su servicio).


Finalmente, para determinar cómo evolucionan las prestaciones del sistema se suelen utilizar herramientas que generan carga al sistema (tráfico de red). Se suelen usar benchmarks como SPECweb o WebStone para simular un número determinado de clientes.

Existen otras herramientas de simulación de carga que podemos usar en cualquier máquina, como por ejemplo:

• Apache Benchmark
• httperf
• OpenWebLoad
• The Grinder
• OpenSTA
• Jmeter
• siege
• Webstone (Mindcraft)

 
Todas ellas permiten comprobar el rendimiento de cualquier servidor web (Apache, MS Internet Information Services -IIS-, nginx, Cherokee, Tomcat, lighttpd, thttpd, etc) para comprobar el rendimiento del hardware, software o de alguna modificación en la configuración que hayamos hecho.

También tenemos la opción de encargar a una empresa externa especializada la aplicación de estas cargas y el análisis de los resultados. Como ejemplos, cabe destacar:

• Micro Focus Intl. - Segue Software (SilkPerformer)
• HP (LoadRunner)
• Micro Focus Intl. - Compuware (QALoad)
• Rational (SiteLoad)
• Radview (WebLoad)

Lo que hacen son diferentes tipos de pruebas a los servidores para comprobar su funcionamiento en diferentes condiciones:

• Humo (Smoke): pruebas preliminares para comprobar que el sistema está listo para los siguientes tests.
• Carga (Load): cargas lo más parecidas a la real ejecutadas en periodos cortos (1h), para determinar los tiempos de respuesta que tendrán los usuarios.
• Capacidad (Capacity): actividad creciente hasta detectar el punto de saturación.
• Estrés (Stress): para analizar el efecto de aplicar de forma continuada una carga por encima de la capacidad del sistema.
• Sobrecarga (Overload): aplicar fuertes picos de carga durante cortos periodos.
• Estabilidad (Stability): cargas lo más similares posibles a la real, aplicadas durante 1 día o 1 semana.

Es importante recoger todos los datos posibles durante la ejecución de estas pruebas para poder determinar lo que está ocurriendo en el sistema en cada momento y cómo reacciona éste en función de la carga introducida, ya sean medidas de la calidad del servicio del sistema (estadísticas que calcula la herramienta de generación de carga) o medidas del consumo de recursos del sistema (utilizando herramientas del sistema operativo).


En clase planteamos los siguientes ejercicios:

• Ejercicio 5.1: Buscar información sobre cómo calcular el número de conexiones por segundo.
• Ejercicio 5.2: Instalar wireshark y observar cómo fluye el tráfico de red en uno de los servidores web mientras se le hacen peticiones HTTP.
• Ejercicio 5.3: Buscar información sobre herramientas para monitorizar las prestaciones de un servidor.

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 4: Comprobar el rendimiento de servidores web

En esta práctica vamos a usar varias herramientas para crear cargas HTTP sobre el sistema web. Hay sistemas en los que se usan herramientas como SPECweb o WebStone para simular un número determinado de clientes accediendo al sistema. En cualquier caso, las pruebas deben hacerse simulando accesos simultáneos de un gran número de usuarios, para lo cual, usaremos herramientas de generación del tráfico.

Existen herramientas para comprobar el rendimiento de servidores web basadas en interfaz de línea de comandos y también basadas en interfaz gráfica. Lo habitual es usar programas de línea de comandos que sobrecarguen lo mínimo posible las máquinas que estamos usando (tanto la que genera el tráfico como las del sistema servidor). Además, es importante usar siempre la misma máquina para generar el tráfico, y lo más importante, que esa máquina sea totalmente independiente de las que forman la granja web.

Entre las herramientas más utilizadas para generar tráfico HTTP destacan:

• Apache Benchmark
• Siege
• The Grinder
• OpenSTA
• JMeter
• httperf
• OpenWebLoad

Todas ellas nos permiten comprobar el rendimiento del servidor web, ya sea del hardware o software, o de alguna modificación/configuración que hayamos hecho.


En esta práctica proponemos usar las siguientes herramientas para comprobar el rendimiento de nuestra granja web recién configurada (aunque se pueden usar otras herramientas que encontremos):

• Apache Benchmark: http://httpd.apache.org/docs/2.2/programs/ab.html
• Siege: https://www.joedog.org/siege-home/

La idea de esta práctica es usar varias herramientas para comparar los resultados de rendimiento de tres configuraciones: (1) máquina sola, (2) granja con nginx, (3) granja con haproxy.

Se recomienda crear una cuarta máquina virtual o bien usar un terminal en nuestro ordenador anfitrión y desde ahí lanzar las herramientas para generar el tráfico. Es importante que la carga computacional y de red que supone la batería de peticiones no recaiga sobre ninguna de las máquinas que forman la granja web, tal y como se indica en el siguiente esquema:

Herramienta 1: Apache Benchmark

Apache Benchmark (ab) es una utilidad que se instala junto con el servidor Apache y permite comprobar el rendimiento de cualquier servidor web, por sencillo o complejo que sea. Con esta herramienta podemos analizar el rendimiento de servidores Apache, Internet Information Services (IIS), nginx, etc.

Para ejecutarla, entramos en un terminal en la máquina cliente y ejecutamos el comando:

ab -n 1000 -c 10 http://ipmaquina/test.html

Los parámetros indicados en la orden anterior le indican al benchmark que solicite la página con dirección http://ipmaquina/test.html 1000 veces (-n 1000 indica el número de peticiones) y hacer esas peticiones concurrentemente de 10 en 10 (-c 10 indica el nivel de concurrencia). Esos parámetros generan una carga muy baja; para hacer la práctica probablemente tengamos que usar valores mucho mayores en ambos casos.

ab no simula con total fidelidad el uso del sitio web que pueden hacer los usuarios habitualmente (en realidad, ninguna herramienta lo hará). Pide el mismo recurso (misma página) repetidamente. Sin embargo, va bien para testear cómo se comporta el servidor antes y después de modificar cierta configuración.

Con esta herramienta, de todas las medidas que nos ofrece, vamos a recoger: "Time taken for tests", "Failed requests", "Requests per second" y "Time per request".


Herramienta 2: Siege

Siege es una herramienta de generación de carga HTTP para benchmarking. Se trata de una utilidad de línea de comandos, similar en interfaz al Apache Benchmark, aunque las opciones de ejecución son ligeramente diferentes. Por ejemplo, permite realizar las baterías de tests contra varias URLs diferentes del mismo servidor, en lugar de usar la misma URL siempre.

Debemos usar la opción -b para ejecutar los tests sin pausas, con lo que comprobaremos el rendimiento general. Además, podemos indicar el tiempo exacto que queremos ejecutar Siege con la opción -t siguiendo el siguiente formato:
  -t60S (60 segundos)
  -t1H (1 hora)
  -t120M (120 minutos)

Como ejemplo, ejecutaremos la herramienta con el siguiente comando:

siege  -b -t60S -v http://ipmaquina

Lo que usará 15 usuarios concurrentes (el valor por defecto) y estará en ejecución durante 60 segundos.

Con esta herramienta, de todas las medidas que nos ofrece, vamos a recoger: "Availability", "Elapsed time", "Response time" y "Transaction rate".


Metodología: ¿Cómo realizar los tests con las herramientas?

Para realizar los tests debemos generar el tráfico ejecutando la herramienta correspondiente en la cuarta máquina (externa a la granja web), haciendo las baterías de ejecuciones a las siguientes configuraciones:

• una carga concreta a la IP de un servidor solo (puede ser la máquina final M1 o la M2)
• la misma carga a la IP del balanceador teniendo como software de balanceo el nginx
• la misma carga a la IP del balanceador teniendo como software de balanceo el haproxy
• Haremos un mínimo de 5 ejecuciones con ese nivel de carga y con cada configuración, y recogeremos los datos en una hoja de cálculo. Luego calculamos una tabla con medias y desviación estándar para cada uno de los tres casos, y representamos gráficamente estos valores de forma que podamos analizar y comparar adecuadamente los resultados obtenidos, ofreciendo unas conclusiones acerca de lo observado.

Nota 1: Las métricas obtenidas con las herramientas son muy diferentes entre sí, por lo que no debemos comparar lo obtenido con con las herramientas utilizadas. La idea es comparar los resultados de rendimiento entre las tres configuraciones (máquina sola, granja con nginx, granja con haproxy) con cada herramienta. Recordad que vamos a comparar configuraciones, y no herramientas.

Nota 2: Hemos propuesto dos posibles herramientas de las muchas que existen. Para subir la nota de la Práctica 4, buscad otra diferente y utilizadla siguiendo las indicaciones anteriores.

Tema 4 de teoría: Balanceo de carga (SWAP2016)

En este tema comenzamos viendo cómo hace años se usaban grandes mainframes como servidores de todo tipo. Sin embargo, eran máquinas muy caras, tanto para adquirirlas como para mantenerlas. Esto al desarrollo de la tecnología del balanceo de carga.

La idea es poner varias máquinas trabajando en paralelo en lugar de una sola máquina muy grande y cara. De esta forma, si una máquina del cluster (grupo o granja) se rompe, se puede sustituir fácilmente, lo que mejora la robustez, y además las tareas se pueden repartir entre grupos de servidores.

El funcionamiento se basa en el uso de un balanceador que reparte el tráfico web entre varios servidores finales.

Hay diversas opciones para configurar un balanceador, tanto en cuanto dispositivos hardware o software, realizando las siguientes tareas:
 - comprobar la disponibilidad de los servidores
 - protege de diversos ataques
 - derivar en función del tipo de tráfico

Existe software específico para configurar casi cualquier PC como balanceador, estableciendo diferentes algoritmos de reparto de carga. Como ejemplo de software para configurar el balanceo de carga, cabe destacar:
 - HAProxy
 - ngingx
 - Apache
 - Zen Load Balancer
 - Pirhana
 - Pound
 - Ultra Monkey
 - LVS
 - Local Director (cisco)
 - BIG-IP (F5)
 - NLB (Microsoft)

Entre los dispositivos tipo "caja negra", cabe nombrar aquellos que incluyen el hardware y software necesarios para el balanceo (una especie de PC con un software muy concreto y bien afinado), o bien procesadores específicos (ASIC, application specific integrated circuit) para realizar las tareas de modificación de paquetes. Destacan los fabricantes Cisco Systems, Foundry Networks, Nortel Networks, F5 Networks y Radware.

Todos estos balanceadores permiten el uso de varios algoritmos de balanceo de carga diferentes:
 - balanceo basado en turnos (round-robin)
 - balanceo basado en el menor número de conexiones
 - balanceo basado en ponderación
 - balanceo basado en prioridad
 - balanceo basado en tiempo de respuesta
 - combinación de los algoritmos de tiempo de respuesta y menor número de conexiones


Finalmente, existe una tecnología para realizar balanceo de carga global (GSLB, global server load balancing) de forma que se distribuya la carga entre varios centros de datos. La idea es minimizar los retrasos en las comunicaciones por las distancias entre el usuario y los servidores. Esto tiene la ventaja añadida de que si un centro falla, el tráfico se redirige a otro centro de datos (redundancia). Hay varias formas de implementar el GSLB:
 - Uso del sistema de DNS
 - Redirección HTTP
 - GSLB basado en DNS
 - GSLB usando protocolos de enrutamiento

A pesar de la alta disponibilidad que se obtiene usando GSLB, se trata de un sistema muy complejo de implementar. Un problema añadido es mantener el almacenamiento (BD, p.ej.) sincronizado entre los diversos centros de datos.


Como resumen, el balanceo de carga aporta diversos beneficios:

• Escalabilidad: El balanceador distribuye las peticiones de los usuarios entre varios servidores reales, haciendo que la capacidad global de proceso y servicio crezca respecto a un solo servidor.
• Disponibilidad: El balanceador monitoriza el estado de los servidores y las aplicaciones, de forma que si encuentra que uno de los servidores ha fallado, dejará de enviarle peticiones.
• Mantenimiento: El administrador puede apagar una máquina para actualizarla o repararla, y el resto del conjunto seguirá dando el servicio. Posteriormente, la máquina se puede añadir de nuevo cuando vuelva a estar operativa. Además, podemos tener grupos de máquinas configuradas para dar un tipo de servicio (FTP, HTTP, SMTP, etc).
• Seguridad: Puede ser una primera línea de defensa, rechazando varios tipos de ataques. Además, al hacer NAT, protege los servidores finales de accesos desde el exterior.
• Calidad de servicio: Nos referimos al tiempo de respuesta, a la disponibilidad o a la capacidad de ofrecer servicios en función del tipo de usuario.

En clase planteamos los siguientes ejercicios:

• Ejercicio T4.1: Buscar información sobre cuánto costaría en la actualidad un mainframe. Comparar precio y potencia entre esa máquina y una granja web de unas prestaciones similares.
• Ejercicio T4.2: Buscar información sobre precio y características de balanceadores hardware específicos. Compara las prestaciones que ofrecen unos y otros.
• Ejercicio T4.3: Buscar información sobre los métodos de balanceo que implementan los dispositivos recogidos en el ejercicio 4.2
• Ejercicio T4.4: Instala y configura en una máquina virtual el balanceador ZenLoadBalancer. Compara con la dificultad de la instalación y configuración usando nginx o haproxy (práctica 3).
• Ejercicio T4.5: Probar las diferentes maneras de redirección HTTP. ¿Cuál es adecuada y cuál no lo es para hacer balanceo de carga global? ¿Por qué?
• Ejercicio T4.6: Buscar información sobre los bloques de IP para los distintos países o continentes. Implementar en JavaScript o PHP la detección de la zona desde donde se conecta un usuario.
• Ejercicio T4.7: Buscar información sobre métodos y herramientas para implementar GSLB.

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

Tema 1: Introducción (SWAP2016)

Este primer tema, de introducción, lo hemos planteado como un caso en el que nos hubieran encargado montar un servidor web para una organización grande.

Aquí podemos optar por uno de dos caminos:

• o comenzar a montar un servidor e instalar el software que creemos necesario, sin un trabajo previo (que puede ser largo y costoso) de planificación
• o bien pararnos a analizar las necesidades reales de la organización, dimensionar el servidor adecuadamente, y solo entonces comenzar a trabajar en la configuración.

Si optamos por la primera opción, tras un trabajo inicial sencillo, luego con mucha seguridad acabaremos desarrollando un trabajo de mantenimiento muy grande... En el momento en que el tráfico crezca a cierto nivel, la máquina resultará insuficiente y no podrá servir a los usuarios como debe.

Si optamos por la segunda opción, tras un trabajo inicial (relativamente complejo), acabaremos configurando de un sistema completo, escalable y con alta disponibilidad que nos asegura dar el servicio que se espera.

Otra cuestión es disponer de una máquina en la que el equipo de desarrollo pruebe nuevos módulos, aplicaciones, etc, y sólo cuando estén bien probados se pasen al servidor de producción.

Así pues, la solución más adecuada cuando haya que hacer frente a un alto tráfico de red y dar servicio a millones de usuarios pasa por hacer una granja web. Puede suponer un trabajo y coste extra, pero tendremos un sistema escalable y con alta disponibilidad.

Finalmente, para terminar la clase, hemos comentado varios casos de desarrollo de sistemas web y los posibles problemas que pueden experimentar. De esos casos, algunos fueron sistemas mal planificados, y otros, aunque bien planificados, sufrieron algún grave problema inesperado (ver los siguientes artículos del Availability Digest:

• http://www.availabilitydigest.com/public_articles/0606/mizuho_bank.pdf
• http://www.availabilitydigest.com/public_articles/0312/simple_fault.pdf

Presentación de la asignatura "Servidores Web de Altas Prestaciones" (SWAP). Curso 2015-2016

Esta tarde hemos hecho la presentación de la asignatura "Servidores Web de Altas Prestaciones".

Para la gestión de la asignatura usaré varios medios electrónicos, de forma que quien no pueda asistir a clase (bien regularmente o algún día aislado), pueda seguir la asignatura sin problemas:

• Todos los días, tras cada clase, publicaré una entrada describiendo lo explicado en este mismo blog.
• En Twitter usaré el hashtag #SWAP_UGR para publicar noticias, comunicados, avisos, etc. No es necesario seguirme en Twitter; a través del hashtag podéis acceder a todo lo que publique sobre la asignatura. En cualquier caso, mi cuenta en Twitter es @pacastillo
  
• En Telegram he creado el grupo SWAP2016 para mantener el contacto con todos los alumnos que quieran unirse a dicho grupo (totalmente opcional, por supuesto).
• La entrega de prácticas y el trabajo final de la asignatura la debéis hacer en un repositorio en vuestra cuenta de GitHub https://github.com/   Así pues, si aún no tienes cuenta en esta plataforma, ábrela cuanto antes.