alotofpeople - stock.adobe.com
Cómo construir un diseño de red resiliente
Todo falla eventualmente, incluso en las redes. Las empresas pueden prepararse para fallas en la red si incorporan resiliencia y redundancia en el diseño de su infraestructura de red.
La resiliencia se define como la capacidad de recuperarse rápidamente de un revés u otra adversidad, literalmente, la capacidad de retroceder. Entonces, con las redes de computadoras, ¿cómo diseñamos la resiliencia en el medio ambiente?
Este artículo analiza cuatro factores a considerar al considerar la resiliencia de la red, así como la forma en que las empresas pueden crear redundancia en su infraestructura de red.
- Todo falla
El primer paso para diseñar una red resistente es comprender la realidad de que todo falla: enrutadores, conmutadores, circuitos, cables, conectores enchufables de factor de forma pequeño e incluso conexiones cruzadas. Es necesario realizar un mantenimiento regular de la red. Este mantenimiento mantiene los sistemas en los niveles de software apropiados, permite la aplicación de parches de seguridad e incluso proporciona mantenimiento y reemplazo de hardware.
- Horas de funcionamiento
En segundo lugar, los equipos de red deben pensar en las horas de funcionamiento del entorno. Por ejemplo, es posible que la red de una oficina no tenga usuarios fuera del horario de atención o los fines de semana. Este tipo de red puede tener requisitos estrictos de confiabilidad y disponibilidad durante el horario normal, pero se puede mantener fuera del horario laboral. Otros entornos, como los centros de datos o los sistemas de vida y seguridad, por ejemplo, los centros 911 y los hospitales, deben funcionar 24 horas al día, 7 días a la semana. Como resultado, un diseño adecuado para estas redes debe tener en cuenta tanto las fallas como la capacidad de funcionamiento durante el mantenimiento.
- Aplicaciones de virtualización, nube y SaaS
El siguiente paso es pensar en el efecto de las suites de aplicaciones de virtualización, nube y SaaS. Si bien puede parecer que las aplicaciones basadas en la nube están fuera del control de TI, nada podría estar más lejos de la verdad. Por ejemplo, AWS hace un esfuerzo significativo para asesorar a los clientes sobre la disponibilidad proporcionada por las aplicaciones. Las aplicaciones brindan acuerdos de nivel de servicio (SLA) sustancialmente diferentes a los usuarios según el lugar donde se alojan, como en zonas de disponibilidad únicas, en varias zonas de disponibilidad u operando entre regiones. También importa cómo las empresas y sus clientes se conectan a los proveedores de nube o de software como servicio (SaaS).
- Conectividad remota confiable
Finalmente, en la era de la pandemia de COVID-19, las empresas deben pensar en la confiabilidad de su conectividad remota. ¿La conectividad se ejecuta en concentradores VPN primarios o secundarios, o se equilibra la carga en un grupo de sistemas, lo que permite la escala necesaria para el mantenimiento?
Genere redundancia en todas las capas
Entonces, ¿cómo proceden los equipos a construir un diseño de red resistente? En última instancia, es importante comprender que la redundancia es solo una herramienta para crear resiliencia.
Docenas de libros están llenos de consejos sobre técnicas para construir un diseño de red resistente: les recomiendo Problemas y soluciones de redes informáticas de Russ White y Ethan Banks. Pero el resultado final de la resiliencia es que las empresas necesitan aplicar redundancia en todas las capas de su infraestructura. Esto significa diseñar con modularidad y mantener la separación física y lógica entre elementos funcionales.
Si bien la disponibilidad y la resistencia del sitio se pueden establecer con la redundancia de circuitos y componentes, las aplicaciones que requieren disponibilidad continua deben diseñarse para distribuirse en múltiples centros de datos y zonas de disponibilidad. Esto permite el funcionamiento de la aplicación durante las operaciones de mantenimiento de AWS, VMware u otro mantenimiento en cualquier ubicación.
El componente más importante de este paradigma es el concepto de automatización de redes. Así es como los equipos pueden asegurarse de que los cambios no sean susceptibles a errores humanos. Los conjuntos de secuencias de comandos necesitan una revisión rigurosa y todos los cambios requieren la documentación y las pruebas adecuadas. Cualquier cambio dado requiere un conjunto mínimo de scripts, que incluye un script para promulgar el cambio y otro para probar y validar el cambio. Finalmente, los equipos necesitan un plan para manejar las excepciones y tener un script de retroceso para devolver el entorno a su línea de base anterior al cambio.
