Hoy les contaré cómo surgió y se implementó la idea de crear una nueva red interna para nuestra empresa. La posición de la dirección es que es necesario realizar el mismo proyecto completo para usted y para el cliente. Si lo hacemos bien por nosotros mismos, podemos invitar al cliente y mostrarle lo bien que funciona y funciona lo que le ofrecemos. Por lo tanto, abordamos muy a fondo el desarrollo del concepto de una nueva red para la oficina de Moscú, utilizando el ciclo de producción completo: análisis de las necesidades departamentales → selección de una solución técnica → diseño → implementación → pruebas. Vamos a empezar.
Seleccionar una solución técnica: Santuario de mutantes
El procedimiento para trabajar en un sistema automatizado complejo se describe mejor actualmente en GOST 34.601-90 “Sistemas automatizados. Etapas de la Creación”, así trabajamos de acuerdo a ello. Y ya en las etapas de formación de requisitos y desarrollo de conceptos, nos topamos con las primeras dificultades. Organizaciones de diversos perfiles (bancos, compañías de seguros, desarrolladores de software, etc.) para sus tareas y estándares necesitan ciertos tipos de redes, cuyas características específicas sean claras y estandarizadas. Sin embargo, esto no funcionará con nosotros.
¿Por qué?
Jet Infosystems es una gran empresa de TI diversificada. Al mismo tiempo, nuestro departamento de soporte interno es pequeño (pero orgulloso) y garantiza la funcionalidad de los servicios y sistemas básicos. La empresa contiene muchas divisiones que realizan diferentes funciones: se trata de varios equipos poderosos de subcontratación, desarrolladores internos de sistemas comerciales, seguridad de la información y arquitectos de sistemas informáticos, en general, quienquiera que sea. En consecuencia, sus tareas, sistemas y políticas de seguridad también son diferentes. Lo cual, como era de esperarse, generó dificultades en el proceso de análisis y estandarización de necesidades.
Aquí está, por ejemplo, el departamento de desarrollo: sus empleados escriben y prueban códigos para un gran número de clientes. A menudo existe la necesidad de organizar rápidamente los entornos de prueba y, francamente, no siempre es posible formular requisitos para cada proyecto, solicitar recursos y crear un entorno de prueba separado de acuerdo con todas las regulaciones internas. Esto da lugar a situaciones curiosas: un día, su humilde servidor miró en la sala de desarrolladores y encontró debajo de la mesa un clúster Hadoop de 20 escritorios que funcionaba correctamente, que inexplicablemente estaba conectado a una red común. No creo que valga la pena aclarar que el departamento de TI de la empresa desconocía su existencia. Esta circunstancia, como muchas otras, fue la responsable de que durante el desarrollo del proyecto naciera el término “reserva mutante”, que describe el estado de la sufrida infraestructura de oficinas.
O aquí hay otro ejemplo. Periódicamente se instala un banco de pruebas dentro de un departamento. Este fue el caso de Jira y Confluence, que fueron utilizados de forma limitada por el Centro de Desarrollo de Software en algunos proyectos. Después de un tiempo, otros departamentos conocieron estos útiles recursos, los evaluaron y, a finales de 2018, Jira y Confluence pasaron del estado de "juguete de programadores locales" al estado de "recursos de la empresa". Ahora se debe asignar un propietario a estos sistemas, se deben definir SLA, políticas de acceso/seguridad de la información, políticas de respaldo, monitoreo, reglas para enrutar solicitudes para solucionar problemas; en general, todos los atributos de un sistema de información completo deben estar presentes. .
Cada una de nuestras divisiones es también una incubadora que cultiva sus propios productos. Algunas de ellas mueren en la etapa de desarrollo, otras las usamos mientras trabajamos en proyectos, mientras que otras echan raíces y se convierten en soluciones replicadas que comenzamos a usar nosotros mismos y a vender a los clientes. Para cada uno de estos sistemas, es deseable tener su propio entorno de red, donde se desarrollará sin interferir con otros sistemas y, en algún momento, podrá integrarse en la infraestructura de la empresa.
Además del desarrollo, tenemos una gran con más de 500 empleados, formados en equipos para cada cliente. Están involucrados en el mantenimiento de redes y otros sistemas, monitoreo remoto, resolución de reclamos, etc. Es decir, la infraestructura del SC es, de hecho, la infraestructura del cliente con el que están trabajando actualmente. La peculiaridad de trabajar con esta sección de la red es que sus estaciones de trabajo para nuestra empresa son en parte externas y en parte internas. Por lo tanto, para SC implementamos el siguiente enfoque: la empresa proporciona al departamento correspondiente red y otros recursos, considerando las estaciones de trabajo de estos departamentos como conexiones externas (por analogía con sucursales y usuarios remotos).
Diseño de carreteras: somos el operador (sorpresa)
Después de evaluar todos los obstáculos, nos dimos cuenta de que teníamos la red de un operador de telecomunicaciones dentro de una sola oficina y comenzamos a actuar en consecuencia.
Creamos una red central con ayuda de la cual cualquier consumidor interno, y en el futuro también externo, recibe el servicio requerido: VPN L2, VPN L3 o enrutamiento L3 normal. Algunos departamentos necesitan un acceso seguro a Internet, mientras que otros necesitan un acceso limpio sin firewalls, pero al mismo tiempo protegiendo nuestros recursos corporativos y nuestra red central de su tráfico.
Informalmente “concluimos un SLA” con cada división. De acuerdo con él, todas las incidencias que surjan deberán ser eliminadas en un plazo determinado y previamente acordado. Los requisitos de la empresa para su red resultaron ser estrictos. El tiempo máximo de respuesta ante una incidencia en caso de fallo telefónico y de correo electrónico fue de 5 minutos. El tiempo para restaurar la funcionalidad de la red durante fallas típicas no es más de un minuto.
Dado que tenemos una red de nivel de operador, solo puede conectarse a ella estrictamente de acuerdo con las reglas. Las unidades de servicio establecen políticas y brindan servicios. Ni siquiera necesitan información sobre las conexiones de servidores, máquinas virtuales y estaciones de trabajo específicos. Pero al mismo tiempo, se necesitan mecanismos de protección, porque ni una sola conexión debería desactivar la red. Si se crea accidentalmente un bucle, otros usuarios no deberían notarlo, es decir, es necesaria una respuesta adecuada de la red. Cualquier operador de telecomunicaciones resuelve constantemente problemas similares aparentemente complejos dentro de su red central. Brinda servicio a muchos clientes con diferentes necesidades y tráfico. Al mismo tiempo, diferentes suscriptores no deberían experimentar inconvenientes por el tráfico de otros.
En casa, resolvimos este problema de la siguiente manera: construimos una red troncal L3 con redundancia total, utilizando el protocolo IS-IS. Se construyó una red superpuesta sobre el núcleo basada en tecnología. /, utilizando un protocolo de enrutamiento . Para acelerar la convergencia de los protocolos de enrutamiento, se utilizó la tecnología BFD.
Estructura de red
En las pruebas, este esquema demostró ser excelente: cuando se desconecta cualquier canal o conmutador, el tiempo de convergencia no supera los 0.1-0.2 s, se pierde un mínimo de paquetes (a menudo ninguno), las sesiones TCP no se interrumpen, las conversaciones telefónicas no son interrumpidos.
Capa base: enrutamiento
Capa superpuesta: enrutamiento
Como conmutadores de distribución se utilizaron conmutadores Huawei CE6870 con licencias VXLAN. Este dispositivo tiene una relación calidad-precio óptima, lo que le permite conectar suscriptores a una velocidad de 10 Gbit/s y conectarse a la red troncal a velocidades de 40 a 100 Gbit/s, dependiendo de los transceptores utilizados.
Conmutadores Huawei CE6870
Se utilizaron conmutadores Huawei CE8850 como conmutadores centrales. El objetivo es transmitir el tráfico de forma rápida y fiable. No tienen conectados ningún dispositivo excepto switch de distribución, no saben nada de VXLAN por lo que se optó por un modelo con 32 puertos 40/100 Gbps, con licencia básica que proporciona enrutamiento L3 y soporte para IS-IS y MP-BGP. protocolos.
El de abajo es el conmutador central Huawei CE8850.
En la etapa de diseño, surgió una discusión dentro del equipo sobre las tecnologías que podrían usarse para implementar una conexión tolerante a fallas a los nodos centrales de la red. Nuestra oficina de Moscú está ubicada en tres edificios, tenemos 7 salas de distribución, en cada una de las cuales se instalaron dos conmutadores de distribución Huawei CE6870 (en varias salas de distribución solo se instalaron conmutadores de acceso). Al desarrollar el concepto de red se consideraron dos opciones de redundancia:
- Consolidación de conmutadores de distribución en una pila tolerante a fallos en cada sala de conexiones cruzadas. Ventajas: simplicidad y facilidad de configuración. Desventajas: existe una mayor probabilidad de falla de toda la pila cuando ocurren errores en el firmware de los dispositivos de red (“pérdidas de memoria” y similares).
- Aplique tecnologías de puerta de enlace M-LAG y Anycast para conectar dispositivos a conmutadores de distribución.
Al final nos decidimos por la segunda opción. Es algo más complicado de configurar, pero en la práctica ha demostrado su rendimiento y alta fiabilidad.
Primero consideremos la conexión de dispositivos finales a conmutadores de distribución:
Cruz
En dos conmutadores de distribución se incluye un conmutador de acceso, un servidor o cualquier otro dispositivo que requiera una conexión tolerante a fallos. La tecnología M-LAG proporciona redundancia a nivel de enlace de datos. Se supone que dos interruptores de distribución aparecen ante el equipo conectado como un solo dispositivo. La redundancia y el equilibrio de carga se llevan a cabo mediante el protocolo LACP.
La tecnología de puerta de enlace Anycast proporciona redundancia a nivel de red. Se configura una cantidad bastante grande de VRF en cada uno de los conmutadores de distribución (cada VRF está diseñado para sus propios fines: por separado para usuarios "normales", por separado para telefonía, por separado para varios entornos de prueba y desarrollo, etc.), y en cada uno VRF tiene varias VLAN configuradas. En nuestra red, los conmutadores de distribución son las puertas de enlace predeterminadas para todos los dispositivos conectados a ellos. Las direcciones IP correspondientes a las interfaces VLAN son las mismas para ambos conmutadores de distribución. El tráfico se dirige a través del interruptor más cercano.
Ahora veamos cómo conectar conmutadores de distribución al kernel:
La tolerancia a fallos se proporciona a nivel de red mediante el protocolo IS-IS. Tenga en cuenta que se proporciona una línea de comunicación L3 separada entre los conmutadores, a una velocidad de 100G. Físicamente, esta línea de comunicación es un cable de Acceso Directo; se puede ver a la derecha en la foto de los conmutadores Huawei CE6870;
Una alternativa sería organizar una topología de doble estrella "honesta" y totalmente conectada, pero, como se mencionó anteriormente, tenemos 7 habitaciones interconectadas en tres edificios. En consecuencia, si hubiéramos elegido la topología de "doble estrella", habríamos necesitado exactamente el doble de transceptores 40G de "largo alcance". Los ahorros aquí son muy significativos.
Es necesario decir algunas palabras sobre cómo funcionan juntas las tecnologías de puerta de enlace VXLAN y Anycast. VXLAN, sin entrar en detalles, es un túnel para transportar tramas Ethernet dentro de paquetes UDP. Las interfaces loopback de los conmutadores de distribución se utilizan como dirección IP de destino del túnel VXLAN. Cada crossover tiene dos conmutadores con las mismas direcciones de interfaz loopback, por lo que a cualquiera de ellos puede llegar un paquete y de él se puede extraer una trama Ethernet.
Si el conmutador conoce la dirección MAC de destino de la trama recuperada, la trama se entregará correctamente a su destino. Para garantizar que ambos conmutadores de distribución instalados en la misma interconexión tengan información actualizada sobre todas las direcciones MAC que “llegan” desde los conmutadores de acceso, el mecanismo M-LAG es responsable de sincronizar las tablas de direcciones MAC (así como ARP tablas) en ambos pares de conmutadores M-LAG.
El equilibrio del tráfico se logra debido a la presencia en la red subyacente de varias rutas hacia las interfaces loopback de los conmutadores de distribución.
En lugar de una conclusión
Como se mencionó anteriormente, durante las pruebas y el funcionamiento, la red mostró una alta confiabilidad (el tiempo de recuperación en caso de fallas típicas no supera los cientos de milisegundos) y un buen rendimiento: cada conexión cruzada está conectada al núcleo mediante dos canales de 40 Gbit/s. Los conmutadores de acceso de nuestra red están apilados y conectados a conmutadores de distribución a través de LACP/M-LAG con dos canales de 10 Gbit/s. Una pila suele contener 5 conmutadores con 48 puertos cada uno, y en cada conexión cruzada se conectan hasta 10 pilas de acceso a la distribución. Por lo tanto, la red troncal proporciona aproximadamente 30 Mbit/s por usuario incluso con la carga teórica máxima, que en el momento de escribir este artículo es suficiente para todas nuestras aplicaciones prácticas.
La red le permite organizar sin problemas el emparejamiento de cualquier dispositivo arbitrario conectado a través de L2 y L3, proporcionando un aislamiento completo del tráfico (que le gusta al servicio de seguridad de la información) y de los dominios de falla (que le gusta al equipo de operaciones).
En la siguiente parte te contamos cómo migramos a la nueva red. ¡Manténganse al tanto!
Maxim Klochkov
Consultor senior del grupo de auditoría de redes y proyectos complejos
Centro de soluciones de red
"Jet Infosistemas"
Fuente: habr.com