• Servidor web de la ETSIIT (LAMP)
• Granja Uniweb (LAMP, alta disponibilidad)
• Servidores web Intelligenia (2, LAMP)
• Servidores intranet Intelligenia (LAMP)
• Otros servidores de clientes (IIS, LAMP)

• PHP
• PERL
• Python
• Javascript
• HTML5
• CSS3
• Bash (#!/)
• MySQL
• Oracle

• Gran número de peticiones simultáneas
• Tolerante a fallos (redundancia)
• Escalable
• Coherencia de datos

• Similar a servidores convencionales
• Curva de aprendizaje suave
• Tecnologías bien probadas
• Basado en sistemas Open Source
• Bajo coste (dentro de lo posible)

• Múltiples nodos (redundancia)
• Balanceo de carga

• Necesarios bastantes nodos, en previsión de fallos
• Fallo de nodo: Pérdida de 1/N capacidad
• Red de comunicación interna
• Sistema de almacenamiento común a todos los nodos
• Posibilidad de hetereogeneidad en nodos
• Nodos adicionales para pruebas de despliegue con uso de datos reales
• Balanceador hardware o software
• HAProxy

• Despliegue inicial a finales de 2008
• 5 nodos + balanceador
• Actualmente (julio 2013):
• 10 nodos + balanceador
• 7 servidores web
• 1 servidor BBDD
• 1 servidor vídeo
• 1 nodo para pruebas de despliegue
• Da servicio a 450 sitios web
• > 100K visitas / día
• 6M objetos servidos / día
• 80GB / dia

• 5 servidores Dell PowerEdge 2950
• 1 x Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
  
• 16GB RAM
  
• 2-3 x HDD SAS 147GB Fujitsu MBA3147RC en RAID1 / RAID5 por nodo
  
• 2 x HDD SATA 2TB para copias de seguridad
  
• Uso: 1 x servidor BBDD, 3 x servidor web + replica BBDD, 1 x servidor backup y pruebas

• 1 servidor Dell PowerEdge R710
  
• 2 x Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
• 16GB RAM
• 2 x HDD SAS 450GB SEAGATE ST3450857SS en RAID1
• 3 x HDD SATA 1TB en RAID5
• Uso: Servidor web + réplica BBDD + servidor BBDD secundario

• 1 servidor Sun Fire X2270
  
• 1 x Intel(R) Xeon(R) CPU E5504  @ 2.00GHz
• 12GB RAM
• 1 x HDD SATA 500GB HITACHI HUA7250SBSUN500G
• Uso: Servidor web + réplica BBDD
• 2 servidores Dell PowerEdge R710
  

• 2 x Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
• 16GB RAM
• 2 x SSD SATA 250GB OCZ AGILITY3 en RAID1
• Uso: Servidor web

• 1 servidor "custom"
  
• 1 x Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
• 8GB RAM
• 5 x HDD SATA 2TB en RAID5 (8TB útiles)
• Uso: Servidor vídeo
• 1 Balanceador de carga para tráfico HTTP
• Hardware (CISCO)

• Debian GNU/Linux 7.4 "Wheezy"
• Apache 2.2
• MySQL 5.5
• PHP 5.4
• Memcached

• Desarrollo propio 
• Orientado a la UGR
• CMS multisite
• Modular
• Distribuido
• Herencia de configuraciones y estilos
• Uso de recursos de CPU moderado
• ~2M LOC
• CSS personalizado por modelo + versión de navegador
  

• Equipo de desarrollo actual: 15 ingenieros
• Hay más de 50K revisiones del código.
• Al día se publican ~5 nuevas versiones
• Nuevos sites
• Personalizaciones
• Aplicaciones a medida
• Fixes
• Despliegue a medida para entorno distribuido

• Configuración master / slave
• Replicación "statement based"
• Un único nodo atiende todas las peticiones
• Dos réplicas sincronizadas de backup en caso de fallo
• Motor de almacenamiento MyISAM (más veloz)
• Total datos almacenados en BBDD ~110GB

• Copias de seguridad diarias de BBDD
• Almacenamiento de 20 copias en 2 servidores UGR
• Tiempo completo utilizado para copia: 4h
• Scripts de backup a medida

• Memcached

• Memcached + moxi-server

• Precompilación / compactación al vuelo de CSS y JS
• Minimiza tiempo de carga y nº de peticiones
• Facilita la modularidad en el desarrollo
• Requiere mucha CPU en los servidores
• Almacenamiento de objetos precompilados en cache
• Políticas de limpieza de cache de objetos sucios u obsoletos

• Generación de ficheros en disco con el HTML, CSS, JS "compilado"
• Según modelo y versión de navegador
• Estos ficheros precompilados se sirven directamente por Apache sin ejecutar PHP
• Implica tener listado de User-Agents etiquetados (>1500)
• Uso de índice "browscap"
• Se consigue mediante mod-rewrite de Apache y ETAG
• Políticas de expiración de cachés
• Coherencia de cachés en diferentes nodos mediante "pseudohash del fichero" en marcas de tiempo

1. El balanceador sondea periódicamente cada nodo
2. Detecta un nodo muy sobrecargado
3. Automáticamente se informa al balanceador
4. El balanceador deja de mandarle trabajo
5. Cuando se desestresa, se reincorpora a la granja

#!/bin/bash

## carga del sistema
loadavg=`cat /proc/loadavg`

## nº de procesadores
nprocessors=`cat /proc/cpuinfo | egrep processor | wc -l`
ht=`cat /proc/cpuinfo | egrep 'flags.+\bht\b'  | wc -l`

## En un sistema con HyperThreading el nº de procesadores es la mitad
if (( $ht > 0 ))
then
        nprocessors=$((nprocessors / 2))
fi

## carga máxima permitida
maxload=$((nprocessors * 2))

## carga media del último minuto
load1m=${loadavg%% *}
load1mint=${loadavg%%.*}

## ¿se supera la carga máxima tolerada?
if (( $load1mint < $maxload ))
then
        echo "Status: 200 OK"
        echo "Content-Type: text/plain"
        echo
        echo "OK"
else
        echo "Status: 503 Service Unavailable"
        echo "Content-Type: text/plain"
        echo
        echo "REJECT"
fi

• Excesiva latencia en la conexión
• Lentitud en las respuestas
• Muy mal soporte de BLOBs
• Sin soporte de serie para consultas FULLTEXT
• Mala integración con PHP

• Lecturas de BD en nodos web locales
• Encaminar escrituras al "master"
• En principio, funciona bien

• Con alta carga, la replicación llegaba tarde
• Se intentaban hacer lecturas tras escrituras de datos
• Esas lecturas había que encaminarlas al "master"
• Mucha E/S debido a BD en nodos web, mal rendimiento

• Los primeros días funcionan aceptablemente
• Con la fragmentación se degradan las prestaciones
• Tiempo de vida más corto
• Mal funcionamiento en picos de carga
• Bajo rendimiento en RAID5