Esquema de la LAN del centro
La red del centro se extiende por diferentes aulas, departamentos y espacios. Permite el acceso a Internet a los ordenadores del centro y a los dispositivos inalámbricos de los usuarios. Y permite la conexión a los servicios que se mantienen en el centro: cloud, puigmusic, web, moodle, centralita VoIP, etc...
El esquema de la red es:
En este esquema se puede observar:
- Que el acceso a Internet en el centro se realiza mediante un enlace de fibra óptica de la XTEC, el router tiene la IP 192.168.0.1.
- Que la red 192.168.0.0 es la DMZ en la que están las máquinas que mantienen nuestros servicios (192.168.0.101, 192.168.0.102, ...).
- Que la red está subdividida en subredes utilizando VLANs. Existe una VLAN diferente para cada aula y otra VLAN para los clientes WiFi.
- Que un equipo, Círdan, se interpone entre las diferentes VLANs en las que están los clientes y la DMZ.
- Que en la DMZ hay máquinas, se han representado dos (cloud y puigmusic) pero hay otras, que implementan servicios a los que se puede acceder desde Internet y/o las VLANs del centro.
Evidentemente en el esquema no se aprecian detalles sobre la implementación, esta no es la intención, pero aprovecho para comentar que todo está implementado con máquinas virtuales KVM/Libvirt utilizando software libre.
Sobre el router
El acceso a Internet se realiza mediante el mencionado enlace de fibra óptica de la XTEC. Se trata de un enlace simétrico de 100Mbps con la XTEC. Pero este enlace no puede alcanzar su velocidad nominal porque la conexión de la XTEC con Internet tiene un ancho de banda insuficiente y se encuentra completamente congestionada.
A continuación se puede ver el tráfico en el enlace de fibra, donde se aprecia cómo la velocidad obtenida es mucho menor que los 100Mbps.
En la interfaz externa el router tiene la IP estática 85.192.77.128 y permite el acceso desde el exterior mediante SSH, HTTP y HTTPS.
Para mejorar el acceso a Internet del centro sería necesario contratar alguna fibra comercial pero, lamentablemente, de momento ningún operador oferta el servicio en nuestra ubicación.
Sobre la DMZ y la implementación física
La subred 192.168.0.0/24 contiene a las máquinas que ofrecen servicios en nuestra red y/o Internet. En esta red se puede encontrar:
- Servidores web accesibles mediante HTTP/HTTPS. Algunos de estos servidores son: la propia web del centro, el moodle, el blog, la nube, etc...
- Servidores que sólo se utilizan desde nuestro centro. Como el servidor SAN que permite arrancar los ordenadores en red utilizando iPXE con iSCSI. O el que utiliza Ansible para administrar remotamente los equipos de las aulas y departamentos.
- Círdan, que ofrece la infraestructura de red (DHCP, DNS, NTP, gateway, proxy cache) necesaria para los equipos de cada VLAN.
Todas estas máquinas están implementadas con máquinas virtuales KVM que se ejecutan sobre un único host físico, Rohan. Rohan no tiene unas características desmesuradas, pero permite ejecutar con un magnífico rendimiento la docena de máquinas que utilizamos. Reduciendo los costes, proporcionando una gran flexibilidad y realizando backups de manera periódica y automática.
Rohan cuenta con:
- 2 discos SATA de 4TB WD Red WD40EFRX.
- 2 discos SATA SSD de 250GB Samsung 850 EVO.
- 32 GiB de RAM ECC Unbuffered 1600MHz (4 módulos Samsung PC3L-12800E M391B1G73QH0-YK0).
- Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz. Con Hyper-threading activado el SO ve 8 núcleos.
- Un par de interfaces de red gigabit ethernet.
- UPS monitorizado. APC Back-UPS 950U.
Pero la novedad de Rohan está en el lado del software, tiene instalado Ubuntu 16.04 LTS y utiliza ZFS para mantener el pool en el que se guardan las imágenes de las máquinas virtuales. El anterior servidor, Gondolin, en lugar de utilizar ZFS utilizaba mdadm + LVM + XFS para conseguir algo similar: almacenamiento con tolerancia a fallos de disco y posibilidad de realizar snaphots para facilitar los backups.
La solución basada en ZFS aporta varias ventajas pero la fundamental es el rendimiento. Antes la latencia en disco era un grave problema. Tuve que limitar la velocidad de acceso a disco para la máquina virtual que ejecuta OwnCloud, pues al subir ficheros grandes (esa es su función) hacía que las otras máquinas virtuales (como el Moodle) sufrieran un rendimiento pésimo. Esto ha cambiado completamente con la nueva solución. Es posible subir ficheros grandes a OwnCloud a unos 100MB/s efectivos (toda la LAN es Gigabit) mientras Moodle y otras aplicaciones no sufren problemas de rendimiento.
Aquí se puede ver cómo experimentó la máquina virtual que mantiene la web del centro (montada con Plone) la migración de Gondolin a Rohan con una substancial bajada de latencia en el acceso a disco.
Además ZFS aporta otra serie de ventajas:
- Es mucho más sencillo de montar y administrar.
- Utiliza un sistema de caché mucho más eficiente: ARC + L2ARC + ZIL/SLOG.
- Integridad de los datos.
- Snapshots y clones que no penalizan el rendimiento.
- Compresión transparente y muchas otras opciones independientes para cada dataset.
- Replicación de un snapshot a través de la red en otra máquina, permitiendo copias integrales o diferenciales.
En Rohan los discos se utilizan del siguiente modo:
- El SO está instalado sobre un RAID 1 (mantenido por Linux utilizando dos particiones de 50GB en los discos SSD).
- ZFS se utiliza para mantener un pool (con el nombre 'pool' y la opción ashift=12 pues todos los discos son Advanced Format) en el que se guardan las imágenes. Este pool está formado:
- Por los dos discos, completos sin particionar, de 4TB en mirror.
- Por dos particiones de 10GB, de los discos SSD, formando un mirror para el SLOG.
- Por dos particiones de 170GB, sin mirror pues aquí no es necesaria redundancia, como cache.
Además se dedican 8GB de RAM para ARC y está activa la compresión LZ4 en el pool pool/images que es donde se guardan las imágenes de las máquinas virtuales.
A continuación se pueden ver algunos detalles del pool, el dataset images y el snapshot backup que se mantiene constantemente (actualizado cada semana) por si hubiera algún problema en alguna máquina virtual y hubiera que recuperar su estado anterior.
root@rohan:~# zpool status
pool: pool
state: ONLINE
scan: scrub repaired 0 in 2h11m with 0 errors on Sun Jun 12 02:36:42 2016
config:
NAME STATE READ WRITE CKSUM
pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4E6PSKCY0 ONLINE 0 0 0
ata-WDC_WD40EFRX-68WT0N0_WD-WCC4E6ZKDR5X ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
ata-Samsung_SSD_850_EVO_250GB_S2R6NXAH370547N-part2 ONLINE 0 0 0
ata-Samsung_SSD_850_EVO_250GB_S2R6NXBH301707V-part2 ONLINE 0 0 0
cache
ata-Samsung_SSD_850_EVO_250GB_S2R6NXAH370547N-part3 ONLINE 0 0 0
ata-Samsung_SSD_850_EVO_250GB_S2R6NXBH301707V-part3 ONLINE 0 0 0
errors: No known data errors
root@rohan:~# zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
pool 721G 2,81T 96K /mnt/pool
pool/images 721G 2,81T 718G /mnt/pool/images
pool/images@backup 2,99G - 698G -
root@rohan:~#
También resulta de utilidad el comando zpool iostat -v 1 que muestra en tiempo real cómo se está utilizando el pool.
Se pueden consultar estadísticas de funcionamiento sobre Rohan y algunas de sus máquinas virtuales generadas por Munin en: http://valinor.iespuigcastellar.xeill.net/
Sobre las VLANs de acceso para los usuarios
La red del centro está segmentada utilizando VLANs 802.11Q. Existe una VLAN diferente para cada aula, para los departamentos, para la red WiFi o para la DMZ. En cada VLAN se utiliza una subred IP diferente.
Físicamente toda la red está montada con switches Gigabit Ethernet.
| VLAN | Función | Subred IP |
|---|---|---|
| 1 | DMZ | 192.168.0.0/24 |
| 6 | WiFi - XEiLL | 10.0.0.0/16 |
| 10 | Aula Torvalds | 192.168.10.0/24 |
| 11 | Aula Stallman | 192.168.11.0/24 |
| 12 | Aula Ada | 192.168.12.0/24 |
| 14 | Aula AIF | 192.168.14.0/24 |
| 15 | Aula TAC | 192.168.15.0/24 |
| 16 | Aulas ESO/BTX | 192.168.16.0/24 |
| 17 | Departamentos | 192.168.17.0/24 |
| 18 | Aula Turing | 192.168.18.0/24 |
| 19 | Aula Darwin | 192.168.19.0/24 |
En la DMZ únicamente hay equipos de infraestructura. Los ordenadores que se utilizan en las aulas y/o departamentos están en el resto de subredes. En todas estas subredes para los usuarios finales está presente Círdan ofreciendo sus servicios de infraestructura e imponiendo límites para garantizar el acceso a Internet de todo el centro.
Círdan, infraestructura para los clientes
Desde el punto de vista de los equipos que están en un aula, departamento o en la red WiFi, hay un servidor que tiene un protagonismo central: Círdan. Esta máquina tiene una interfaz de red en cada subred (en todas es la 192.168.X.10, salvo en la red WiFi donde utiliza la 10.0.0.1). Y en esa subred ofrece servicios de red para los clientes.
Círdan ofrece a cada subred:
- Servidor DHCP. Ofrece concesiones de IP (desde la .101 hasta la .200 para las aulas, y desde la .0.101 hasta la .254.254 para el WiFi). Enviando su propia IP como servidor DNS, NTP y puerta de enlace por defecto.
- Servidor DNS. Básicamente actúa como servidor DNS cache para las consultas a Internet y mantiene algunos nombres en sus propias zonas (como munin.cirdan.elpuig.xeill.net o proxy.* en cada dominio) para la resolución de recursos propios.
- Servidor NTP. Se mantiene sincronizado con los servidores de pool.ntp.org y ofrece una referencia horaria a todas las estaciones.
- Servidor Proxy - Cache. Squid para HTTP/HTTPS, actuando en modo transparente para las conexiones HTTP. Puede configurarse cualquier equipo para que utilice como proxy el equipo 'proxy' (nombre que se resuelve a la IP de Círdan en la subred) en el puerto 8080.
- Puerta de enlace por defecto.
Al actuar como puerta de enlace por defecto, se siguen las siguientes políticas:
- La política por defecto de la cadena FORWARD es DROP.
- Se reenvía el tráfico perteneciente a conexiones establecidas.
- Se permite establecer conexiones desde los clientes a los servicios de la DMZ (básicamente HTTP, HTTPS y algún otro puerto como el target iSCSI). El tráfico HTTP a servidores de la DMZ no es interceptado por Squid.
- Las conexiones HTTP hacia Internet son automáticamente interceptadas por Squid que funciona en modo transparente, las conexiones HTTPS pueden hacer uso de Squid si se configura el uso del proxy de manera manual. Cosa que no está recomendada pues con HTTPS no se producen aciertos de cache y en el centro Squid no se utiliza para bloquear el acceso a ninguna web.
- Se aceptan conexiones nuevas TCP desde los clientes a equipos de Internet, aplicando los siguientes límites:
- Un límite al número de conexiones globales por subred: 2000 desde las aulas, 10000 desde la red WiFi.
- Un límite al número de conexiones por dispositivo: 100 por host para las aulas y de 75 por host desde la red WiFi.
- Se realiza NAT MASQUERADE para el tráfico reenviado que sale a través de la interfaz que conecta con la DMZ.
El propósito de estos límites es evitar alcanzar la capacidad máxima de la tabla NAT del router, que de acuerdo a la última actualización ha quedado en 30000 entradas. A tal fin ha sido importante limitar el timeout para las conexiones TCP en /etc/sysctl.conf (net.netfilter.nf_conntrack_tcp_timeout_established = 8000).
La gráfica semanal de Munin respecto a conexiones retransmitidas por Cirdan tiene el siguiente aspecto:
Por si todo esto fuera poco, la máquina aún realiza algunas funciones añadidas:
- Cuenta con un alias, 192.168.0.5, a donde el router redirige los puertos 80 TCP y 443 TCP. De manera que las peticiones HTTP/HTTPS desde Internet a nuestros servicios llegan a esta interfaz de red. Alli se ejecuta un Apache que tiene los Virtual Hosts necesarios para redirigir las peticiones al servidor adecuado.
- Ejecuta Munin (munin.cirdan.elpuig.xeill.net) para poder monitorizar su estado y Calamaris (http://munin.cirdan.elpuig.xeill.net/proxystats.html) para obtener estadísticas sobre el uso del proxy.
- Ejecuta un servidor TFTP que ofrece la imagen de iPXE para el arranque en red de los equipos.