Sou a: Inici / Usuaris / Victor Carceler / Artículos / Esquema de la LAN del centro

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:

Esquema red.png

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.

Tráfico en el enlace de fibra de la XTEC.

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:

 

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.

latencia-plone.png

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.

VLANFunciónSubred 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:

conexiones-reenviadas.png 

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.
Navegació