¿Cómo diseñar una arquitectura de red on-premise redundante?

Este artículo es conceptual, se pretende explicar todo lo que se debe tener en cuenta a la hora de diseñar una arquitectura como la indicada en el título. No será una entrada del blog técnica donde se vean ejemplos de configuraciones sino diseños y protocolos que debemos usar.

Con la imagen de cabecera ya queda bastante claro en que consiste esto pero, por si acaso, intentaré explicar que problema tenemos que solucionar tomando el siguiente ejemplo.

Problema

Supongamos que se nos plantea el siguiente problema: Necesitamos otorgar de comunicación a una serie de dispositivos que se encuentran en unas instalaciones de gran tamaño. Tenemos 5 edificios, en dos de ellos se encuentran las oficinas y en los otros 3, los dispositivos que deben de comunicar contra las aplicaciones y servicios que corren en una serie de servidores ubicados en los edificios de oficinas. En cada edificio tenemos dispositivos críticos, dispositivos sin importancia, dispositivos que conectan por WiFi, CCTV, etc. Los dispositivos críticos necesitan una baja latencia y la CCTV necesita buen ancho de banda para poder grabar y visualizar con fluidez todo lo que está pasando. Además, algunas de las cámaras son PoE. Dentro de cada edificio, los dispositivos están en varias localizaciones, separados en algunos casos por 120 metros. El número de elementos a comunicar por edificio está entre 20 y 70.

Hay que remarcar que la arquitectura debe soportar al menos un fallo, o dicho de otro modo, nuestra arquitectura de red no puede tener SPOF (single point of failure) para conseguir así un sistema de alta disponibilidad.

Un punto único de fallo o punto de fallo único¹​ (en inglés, single point of failure, abreviado SPOF²​) es un componente de un sistema que tras un fallo en su funcionamiento ocasiona un fallo global en el sistema completo, dejándolo inoperante. Un SPOF puede ser un componente de hardware, software o eléctrico.

¿Qué debo de tener en cuenta?

Todo. Debes tener en cuenta todo, pero mejor vamos viendo punto por punto…

Distancias y el medio a usar.

La distancia es de los puntos mas fundamentales ya que nos va a determinar que medio vamos a usar. No es igual solventar el problema en una oficina de 100m2 que en una situación como la planteada en el problema anterior. Tomando como referencia el dibujo posterior, descartamos completamente el uso de cualquier tipo de medio de cobre para interconectar edificios ya que superamos holgadamente el umbral de 100 metros y, estando en 2023, lo mínimo que necesitamos es conexión a 1GB.

Las distancias entre edificios oscilan entre 150 y 650m, por lo tanto, el medio óptimo sería fibra óptica. Dado que hay dos distancias que superar los 550m, debería de ser fibra óptica monomodo. Además, y esto se cumple siempre, las distancias sobre el papel siempre son muy inferiores a la realidad. Recomiendo encarecidamente hacer un replanteo para asegurarnos de las distancias con mayor precisión.

Dentro de cada edificio tenemos múltiples localizaciones y muchas de ellas vuelven a superar los 100 metros (hasta 120m), además, tenemos entre 20 y 90 dispositivos por edificio. Por lo tanto, tenemos comunicaciones fibra óptica multimodo y comunicaciones mediante cable ethernet.

Todo esto lo debo de tener en cuenta a la hora de la selección del hardware. Fibra óptica monomodo, fibra óptica multimodo (¿o mejor estandarizado todo a monomodo?), transceivers a ¿1GB o 10GB?, ¿Dónde se parchean las tiradas de cable?

Hardware

Evidentemente, es un punto muy importante y fundamental para la arquitectura. Necesitamos conocer el total de elementos para poder así dimensionar (y over-provisionar) nuestra arquitectura. Tenemos una estimación máxima de 70 dispositivos por cada edificio. Este punto ya nos da pistas sobre la magnitud de los switches del nivel de acceso.

Electrónica de red

Siendo el máximo 70 conexiones por edificio, y suponiendo switches en múltiplos de 24/48 (24/48 puertos). El número de conexiones por edificio podría ser de 96. En base a la ubicación de los elementos, podremos distribuir estos puntos en 2 switches de 48 puertos o en 4 switches de 24 puertos. En la situación dada, optaría por 4 switches de 24 puertos ya que nos da la posibilidad de alcanzar mayores distancias.

El objetivo de este grupo de switches es dar conectividad a los dispositivos finales. Desde estos switches se debe realizar una instalación de cableado de red hasta el dispositivo final. Dado que necesitamos mínimo 1GB, mínimo optaría por cableado CAT6 y a poder ser, S/FTP CAT6/6A LSZH.

En la búsqueda de la redundancia no podemos dejar pasar la parte eléctrica. Es obligatorio que todos los switches tengan al menos 2 fuentes de alimentación redundantes, y hot-swap. Cada fuente debe permitir el funcionamiento completo del switch si una de ellas falla.

Además, es posible que tengamos CCTV que hace uso de POE por lo tanto, deberíamos tener un conjunto de switches con puertos POE dónde conectar CCTV. Además, sería idóneo que la ubicación de estos switches sea diferente a los del resto de la red. Esto nos otorga una capa de seguridad física adicional.

Dispositivos finales

Por supuesto, el dispositivo final no es algo que debamos obviar, debemos saber que clase de dispositivo vamos a conectar. ¿De qué sirve una red completamente redundante si los dispositivos finales no lo son? Si hablamos de dispositivos que conectan por cable, lo idóneo sería tener al menos dos tarjetas de red conectadas a nuestros switches de acceso. Podríamos incluso realizar un NIC Teaming en el equipo final (sin olvidar LACP en switch de acceso) u otorgarle varias direcciones IP (aunque esto no es muy recomendable). Por otro lado, si tenemos un dispositivo WiFi podemos simplificarlo mucho ya que con puntos de acceso solapando las zonas a cubrir y, siendo gestionados por un Mobile Controller, la conexión es completamente transparente para el usuario final. Por otro lado, en entornos OT hay dispositivos que ya de por si integran un mecanismo de fail-over y puede darnos falsos positivos en cuanto a seguridad (MAC, ARPs… ). En definitiva, hay que estudiar y saber que tipo de dispositivo final se va a conectar y no omitir, bajo ningún concepto, este punto.

Los switches de acceso deben de comunicarse con otros switches para alcanzar el objetivo final que son las aplicaciones y servicios que corren en servidores pero, ¿Cómo los conecto?

Topologías y solución propuesta

Existen multitudes de topologías de red. No vamos a inventar nada nuevo en este artículo.

Personalmente, me gusta tener una arquitectura en estrella (o en árbol) en 2-3 niveles. Dependiendo de las necesidades, siempre optaría por un mínimo de 2 niveles. Un primer nivel de switches de acceso y un segundo nivel de switches de agregación.

El siguiente diagrama añade la electrónica de red al diagrama físico mostrado anteriormente.

Switches de acceso

Por un lado, tenemos un grupo de switches de acceso que serán el punto de entrada de todos los dispositivos finales. Además, y buscando de nuevo la redundancia (y simplificar la gestión), los switches deberían formar un stack de 2 unidades. Dicho de otro modo, tendríamos 2 dispositivos físicos pero solo 1 lógico. Existen muchas formas de llamar a esta tecnología según el fabricante (Aruba VSF, HPE IRF, Cisco VSS…) pero al fin y al cabo todo acaban haciendo lo mismo.

Comparación de estas tecnologías: Feature Comparison: Juniper VCF vs HP IRF vs Cisco VSS vs Cisco vPC

¿Por qué? ¿Por qué debemos aplicar estas tecnologías?

• Mayor capacidad de procesamiento. Al tener dos dispositivos para procesar el tráfico, nuestro arquitectura gana músculo y tiene mucha más capacidad de procesamiento.
• Simplificación. No es igual gestionar 8 que 16 switches. Si hay que aplicar cambios, si hay que resolver problemas, se simplifica la administración y la gestión.
• Evitamos problemas y evitamos loops. Si, con STP activo y bien configurado no deberíamos tener problemas pero cuanto mayor trabajo podamos evitar a los switches, mejor.
• Mejorar el ancho de banda: Los uplinks se pueden agregar y multiplicar el ancho de banda.

¿Todo es perfecto? No, no todo es perfecto. Debemos de tener en cuenta que tiene alguna peculiaridad. Si tenemos 2/3 dispositivos en un chasis virtual, cada uno de ellos tendrá una prioridad, en caso de desconexión, solo funcionará aquel que tenga mayor prioridad. Solo puede funcionar 1 ya que de lo contrario, tendríamos un dispositivo duplicado en la red. Esto no debería ser un problema ya que los dispositivos deberían estar enrackados en el mismo rack y no debería ser desconectado salvo error humano.

Switches de agregación

El propósito de estos switches es dar conexión a estos switches de campo. Con la situación planteada, plantearía unos switches de 24p SFP+ que conectaría mediante fibra óptica a los switches de campo. Por supuesto, al igual que en los switches de campo, aplicaría la tecnología de chasis virtual del fabricante que más nos guste. Por lo tanto, de la arquitectura física planteada en el punto anterior, pasaríamos a tener la siguiente arquitectura lógica:

De esta forma estamos simplificando la red a 1 switch lógico (virtual) de agregación que da acceso a 6 switches lógicos pero gracias a los protocolos usados, todo es redundante. En caso de necesidad de ampliación, solamente es añadir switches de acceso y conectarlos al switch de agregación principal. Esto nos permite tener una escalabilidad y no cerrarnos únicamente a lo que se plantea de inicio.

Switches Core, Firewalls y Routers ISP

El objetivo de los switches de CORE es el de realizar funciones de L2 y L3. Principalmente conectarán aquellos servidores o nodos de procesamiento que necesitemos con el resto de la red. Son el punto de procesamiento principal de la red. Deben de seguir la misma filosofía que siguen los switches de acceso y switches de agregación. Dicho de otro modo, dos switches físicos haciendo stack entre ellos y conectando a todos los servidores de forma redundante.

En caso de los firewalls es exactamente igual. Nuestros firewalls deben de disponer de HA a todos los aspectos y por supuesto, de nuevo estar conectados a ambos switches CORE (LACP, etc) para que en caso de 1 fallo, nuestra red no se vea afectada. Es idóneo que dicho firewall disponga de SDWAN para otorgar un poco de inteligencia a nuestra red.

Necesitaremos salir a Internet y para ello tendremos o bien un router de ISP o un router neutro o directamente conexión a nuestro Firewall. El modo no es lo importante, lo único importante es que al menos tengamos DUAL WAN. Debemos tener dos salidas a Internet y a ser posible, mediante dos ISPs diferentes. Esto nos permitirá no depender de forma exclusiva de 1 salida WAN ni tampoco de 1 ISP.

Subredes y VLANs

Segmentar la red, aislar dominios de colisión, controlar los accesos… es fundamental tener control y conocer que está ocurriendo en nuestra red. Por ello, debemos implementar VLANs y subredes que categorice el tráfico según lo que nos interese en cada caso.

En el problema propuesto, deberíamos crear VLAN para cada tipo de elemento final. Subred y vlan para usuarios finales, servidores, gestión, CCTV, WIFI, etc. Además, si hay diferencia entre cada grupo de usuarios, la propia subnet de usuarios debería estar segmentada según necesidades.

Este apartado de subredes y vlan daría para horas de lectura pero dado que este artículo solamente pretende hablar de redundancia, no entraré en mucho más detalle.

Conclusiones

A la hora de diseñar una arquitectura de red completamente redundante debemos de tener absolutamente todo en cuenta y nuestro objetivo es que no exista SPOF. Cada elemento, cada vínculo, cada detalle debe ser estudiado y asegurar que no hay SPOF.

Espero que os haya parecido entretenido este artículo. ¿Qué opinas? ¿Estás de acuerdo? El objetivo de este artículo es expresar mi opinión sobre lo indicado en el título. Si crees que estoy equivocado, si crees que algo se puede mejorar o si crees que está todo bien, se agradece un comentario.