Network Design 101: Scratching the surface

Introducción

La mayoría de nosotros hemos pasado varias veces por esa posición, en la que - como ingenieros de redes - contemplamos un diagrama de red y varias preguntas caen sobre nosotros como relámpagos: “¿Es esta la mejor forma de hacerlo? - “¿Podría mejorarse de alguna manera?” - “¿Que tal si…?


En este documento se intenta dar una visión introductoria sobre diseño de redes y a su vez, se comparten situaciones y condiciones que podrían estar presentes en el proceso. Estas situaciones podrían afectar el resultado final de un diseño, y teniendolas en cuenta, junto con el enfoque mental correcto, podrían cambiar el marcador a su favor.


La meta de esta publicación es resaltar las consideraciones, beneficios y desventajas que pueden encontrarse cuando las arquitecturas son seguidas para crear un diseño, y qué podría suceder cuando las condiciones en el entorno cambian. No se trata de profundizar en una discusión acerca de tecnologías, desde un punto de vista de implementación, ya que el diseño (de redes) no es una ciencia exacta y los objetivos pueden ser logrados de varias formas y maneras.


Se emplearán algunos términos técnicos provenientes del idioma Inglés, muchos de ellos no poseen traducción literal al español, y para evitar algún tipo de confusión, se mantendrán de la misma manera en la que fueron concebidos.


Arquitectura de red y diseño de redes

En el proceso de escribir esta publicación, varios expertos dieron su aporte para revisar y validar la información vertida en las siguientes líneas. Pude encontrar un debate interesante con respecto del significado de las palabras “arquitectura” y “diseño” aplicado a las redes. Al ser un resultado de un proceso que incluye varias visiones, tecnologías y perspectivas, las definiciones correspondientes no tienen un significado exacto y claro para todo el mundo. Los mismos conceptos, claramente podrían variar dependiendo de los roles y las personas involucradas. Todos los colaboradores estuvieron en lo correcto desde sus puntos de vista, y los siguientes párrafos son un resultado de sus consejos, conocimiento y experiencia.


De acuerdo al Foro del Grupo Abierto de Arquitectura (TOGAF, por sus siglas en Inglés) el cual es un marco de referencia seguido para desarrollar arquitecturas empresariales. El término arquitectura está definido de las siguientes maneras (traducido del Inglés):


  1. Descripción formal de un sistema, o de un plan detallado del sistema al nivel de sus componentes, para guiar su implementación. (fuente: ISO/IEC 42010:2007).

  2. La estructura de sus componentes, las relaciones entre ellos. y los principios y directrices que gobiernan su diseño y evolución en el tiempo.


Y específicamente, refiriéndose a arquitectura de la tecnología. Es descrita de la siguiente manera:


La arquitectura de la tecnología describe el software lógico y las capacidades del hardware que son requeridas para apoyar el despliegue de la empresa, datos, y servicios de las aplicaciones. Esto incluye infraestructura de TI, middleware, redes, comunicaciones, procesamiento, estándares, etc.


Haciendo un cambio rápido en los términos usados, y tratando de hacerlo sencillo de digerir sin perder el objetivo principal detrás del concepto. Podríamos ver la arquitectura como “el panorama”o “the big picture” cuya meta principal es visualizar la red ser moldeada, esculpida, conformada, desde su estado actual hasta su estado final. Cuando se diseña una red, todo se reduce a crear algo que debe cumplir los requerimientos/necesidades del negocio, y los de las aplicaciones, dentro de las restricciones que existan. El proceso de tallar, moldear y crear la red, es lo que podríamos llamar diseño.


Enfoque ambiental

Hay dos escenarios posibles que podemos encontrar, y es importante resaltar el enfoque necesario cuando se trata con ellos. Esos escenarios podrían ser descritos de la siguiente manera:


Greenfield: Se refiere a un entorno que no posee restricción alguna impuesta por un trabajo previo. En otras palabras, es el entorno en el que se comienza desde cero y todo se construye desde el principio.


Brownfield: A diferencia del greenfield, brownfield es un entorno que sí posee restricciones impuestas por un trabajo previo. Es una red que se encuentra establecida de antemano y necesita ser modificada mientras se encuentra en producción. Este es el caso que comúnmente se puede hallar en el mundo real.


La diferencia en el enfoque para ambos escenarios yace en las condiciones a las que se encuentran expuestos. Siguiendo la terminología previa, en un brownfield, la red necesita ser esculpida para satisfacer los requerimientos, tanto del negocio como de las aplicaciones teniendo en cuenta que habían restricciones previas como parte de un diseño existente y una infraestructura operativa. En contraposición, cuando se trata de un greenfield, como la red es diseñada desde cero, la misma es tallada y luego entregada, ya habiendo satisfecho los requerimientos, tanto del negocio como de las aplicaciones, considerados desde el comienzo para su concepción


Como se indicó previamente, la manera en la que se esculpe la red solo es posible si se sabe cual es la forma que se desea obtener, en otras palabras, un artista no puede moldear una escultura sin una forma en su mente, sin una inspiración para seguir. Este es el momento en que se requiere interactuar con el negocio.


Para saber que modelo de diseño seguir, qué tecnologías y topologías implementar, y cómo hacerlo, es necesario interactuar con el negocio. Cualquiera que sea la implementación que se intente, debe estar clara desde el comienzo sobre cuales son las necesidades del negocio. Esta fase podría ser desafiante, ya que hay varias visiones o puntos de vista que la gerencia y el equipo técnico podrían tener.


Haciendo uso de analogías: si se fuese a consultar al equipo técnico acerca de que es necesario, se recibirían requerimientos similares a los de la compra de un Ferrari. Pero, al consultar a la gerencia con esos requerimientos recibidos del equipo técnico, tendría (muy probablemente) suficiente presupuesto para comprar un Kia. Aun cuando a todo el mundo (personas técnicas) le gustaría tener una red que va de 0 a 100Kmph en 3 segundos (quien no?), no es siempre la mejor decisión, o siquiera la posible o necesaria, de acuerdo al negocio. Sería un procedimiento prudente y acertado coordinar reuniones para obtener información y mezclar lo mejor de ambos mundos. Cuales son las necesidades del negocio y cómo se satisfacen desde la perspectiva técnica? Cual seria el resultado de implementar cierta tecnología sobre otra?


Con esos requerimientos en mente, se puede diseñar una red haciendo que ciertas tecnologías trabajen juntas para lograr una meta o metas, las cuales deben ser: permitir a la red que se está diseñando entregar los servicios necesarios para las aplicaciones y permitir al negocio generar dividendos.


Sucede muy frecuentemente que el negocio decide comprar el Kia, debido a razones de presupuesto, y luego, un fallo mayor sucede, y corregirlo cuesta igual que el Ferrari propuesto inicialmente, o aún más. Siempre es un asunto de proyección. La discusión debe realizarse con el presente y futuro en mente. Tecnologías que podrían adoptarse en el futuro y crecimiento esperado de la red son ejemplos de estas consideraciones.


Merece la pena mencionar que, como el diseño de redes no es una ciencia exacta, no se puede encontrar una solución perfecta que funcione impecablemente para todos los casos posibles, siempre se reduce a las necesidades y requerimientos específicos. El único diseño erróneo es aquel que es concebido sin considerar las necesidades y requerimientos del negocio y las aplicaciones. Por supuesto, así como requerimientos, también habrán restricciones. Ejemplos de esos elementos son: tecnologías antiguas implementadas que deben ser consideradas (compatibilidad/interoperabilidad entre tecnologías), entornos compuestos de equipos de uno o varios fabricantes (tecnologías específicas de un fabricante/estándares abiertos), restricciones económicas (presupuesto limitado), restricciones geográficas (donde se encuentran situados los equipos, proveedores de servicio disponibles localmente, disponibilidad de transporte WAN), requerimientos/restricciones de las aplicaciones (sensibilidad al retraso, reconecciones, TCP/UDP como transporte, transporte multicast/unicast requerido, encriptado de la información), y muchos otros detalles que deben ser de nuestro conocimiento, y afectarían el resultado del diseño.


Principios del diseño de redes

Adicionalmente, junto con los requerimientos y restricciones, un diseño ideal debería (no siempre lo hace) poseer los siguientes principios como las bases para su concepción:


Jerarquía: Siempre es ideal separar un gran diseño en áreas o capas más pequeñas, tener una segmentación clara entre áreas, asignarles funciones a las mismas y a los equipos que las componen. La función o las funciones que serán ejecutadas por cada dispositivo deben estar claramente definidas.


Modularidad: Implementar jerarquía también mejora la modularidad. Como la red y sus funciones están divididas en varios módulos o áreas, los dominios de falla están limitados a ciertas áreas. En otras palabras: un fallo (hardware/software/enlace) en un módulo/capa/enlace dado representaría un impacto que afecta a su propia área y podría o no, afectar otras partes o zonas de la red.


Escalabilidad: La capacidad que la red tendría para crecer sin afectar las funciones inherentes o pertenecientes a módulos específicos de una capa en cuestión u otra capa o módulo. Apoyándose en la modularidad, hacer crecer la red sería un asunto de agregar otro módulo a la infraestructura existente.


Resiliencia: Garantizar que la red será altamente disponible para satisfacer las expectativas de los usuarios o del negocio sobre un ofrecimiento del servicio permanente. La red debería ser capaz de trabajar bajo circunstancias normales o anormales (por ejemplo: fallo de hardware/enlace/software, enormes cantidades de tráfico, ataques DoS) y eventos esperados o programados (ejemplo: ventanas de mantenimiento). La acreción de la disponibilidad puede ser lograda de varias maneras, una de ellas es a través de la implementación de conexiones redundantes entre los dominios de falla (esas conexiones son llamadas choke points). Esto reduciría el tiempo que la red tomaría para recuperarse de una falla y reenviar tráfico alrededor de la misma para garantizar el ofrecimiento de los servicios bajo condiciones adversas.


Flexibilidad: Poder modificar secciones de la red, agregar nuevas tecnologías y módulos para lograr que los protocolos trabajen juntos, sin tener la necesidad de realizar una modificación mayor en el diseño de la misma..


Tenga en mente que el negocio puede decidir realizar un cambio repentino en el diseño, lo cual nos lleva a las siguientes preguntas: ¿es el diseno suficientemente flexible como esto? ¿Se pueden realizar los cambios sin rediseñar la red completamente?


Para prevenir estos giros inesperados, como el descrito anteriormente, es importante establecer el alcance y objetivos del diseño, junto con los requerimientos, lo más temprano posible. Si un requerimiento nuevo es anunciado luego de esto, debe existir un acuerdo con el cliente acerca de cómo integrarlo con el diseño actual y como este podría afectar el proceso acordado anteriormente. (la programación y el precio importan).


Consideraciones finales

Este blog fue destinado a explicar la actitud mental ante el diseño, el razonamiento involucrado y las razones detrás del mismo, a su vez con una probada de situaciones del mundo real y condiciones que realmente suceden y están presentes. La intención es difundir estas palabras, hacer que la gente sepa que diseño no es solo colocar cajas juntas para hacer que el tráfico fluya y las luces verdes enciendan. Es un proceso que requiere un pensamiento profundo, preparacion y analisis.


Espero que, de alguna manera, este blog contribuya a clarificar dudas. Luego de una extensa revisión de literatura relacionada, pensé que esta sería una forma de unir todas las piezas, dar una introducción breve, y ayudar a entender tópicos o términos que podrían ser confusos o difíciles de entender.

 

Puede encontrar la versión en inglés en el siguiente enlace: Network Design 101: Scratching the surface