En este artículo, examinaremos por qué el enfoque tradicional para combinar redes locales en el nivel L2 es ineficaz con un aumento significativo en la cantidad de equipos, y le diremos qué problemas pudimos resolver en el proceso de combinar proyectos ubicados en diferentes sitios.
Circuito L2 normal
A medida que la infraestructura de TI crece en el centro de datos, los clientes deben combinar servidores, almacenamiento, firewalls en una sola red. Para esto, Selectel inicialmente sugiere usar una red de área local.
La red local está organizada como una red clásica de "campus" dentro del mismo centro de datos, solo los conmutadores de acceso se encuentran directamente en los bastidores con los servidores. Los conmutadores de acceso se combinan en un solo conmutador de capa de agregación. Cada cliente puede
solicitar una conexión a la red local para cualquier dispositivo que alquile o coloque con nosotros en el centro de datos.
Para organizar una red local, se utilizan conmutadores de acceso y agregación dedicados, de modo que los problemas en la red de Internet no afecten a la red local.
No importa en qué rack se encuentre el próximo servidor: Selectel combina los servidores en una sola red local y no tiene que pensar en los conmutadores o la ubicación del servidor. Puede
solicitar un servidor cuando sea necesario y se conectará a la red local.
L2 funciona muy bien, mientras que el tamaño del centro de datos es pequeño, cuando no todos los bastidores están llenos. Pero a medida que aumenta el número de bastidores, servidores en bastidores, conmutadores, clientes, el circuito se vuelve mucho más difícil de mantener.
Los servidores de un cliente se pueden ubicar en varios
centros de datos para garantizar la tolerancia a desastres o si es imposible colocar el servidor en un centro de datos existente (por ejemplo, todos los bastidores y todos los lugares están ocupados). Entre varios centros de datos, también es necesaria la conectividad, entre servidores en una red local.
A medida que crece el número de centros de datos, bastidores y servidores, el circuito se vuelve más complicado. Al principio, la conectividad entre los servidores de diferentes centros de datos se llevó a cabo simplemente a nivel de conmutadores de agregación utilizando tecnología VLAN.
Pero el espacio de identificación de VLAN es muy limitado (4095 ID de VLAN). Entonces, para cada centro de datos, debe usar su propio conjunto de VLAN, lo que reduce la cantidad de identificadores posibles que se pueden usar entre los centros de datos.
Problemas L2
Cuando se usa un esquema en el nivel L2 usando VLAN, la operación incorrecta de uno de los servidores en el centro de datos puede provocar interrupciones en la provisión de servicios en otros servidores. Los problemas más comunes incluyen:
- Problemas con STP (Protocolo Spanning-Tree)
- Problemas con tormentas de difusión
- Problemas con el procesamiento incorrecto de multidifusión
- Factor humano (transferencia de enlace, transferencia de VLAN)
- Problemas con la organización de la reserva para L2
- Problemas con el tráfico de unidifusión desconocida
- Problemas con la cantidad de direcciones MAC
Los problemas con STP a menudo se relacionan con la configuración de los servidores del cliente o del equipo del cliente. A diferencia de los puntos de intercambio de tráfico populares, no podemos filtrar completamente el STP en los puertos de acceso y los puertos de enfriamiento cuando llega una PDU STP. En STP, varios fabricantes de equipos de red implementan la funcionalidad básica de los conmutadores del centro de datos como la detección de bucles en la red.
Si STP no funciona correctamente en el lado del cliente, el dominio STP completo de al menos un conmutador de acceso puede verse afectado. El uso de extensiones STP, como MSTP, tampoco es una solución, porque la cantidad de puertos, VLAN y conmutadores a menudo excede la escalabilidad arquitectónica del protocolo STP.
Broadcast
La red en el centro de datos se puede construir en dispositivos de diferentes fabricantes. A veces, incluso las diferencias en la versión del software del conmutador son suficientes para que los conmutadores manejen el STP de manera diferente. Entonces, por ejemplo, en el centro de datos de
Dubrovka 3 hay 280 bastidores, que exceden el número máximo posible de conmutadores en un dominio STP.
Con el uso generalizado de STP en dicha red, el tiempo de respuesta a cualquier cambio, en particular, simplemente al encender o apagar el puerto, excederá todos los umbrales de espera. ¿No desea que cuando uno de los clientes encienda el puerto, su conectividad de red desaparezca durante varios minutos?
Los problemas con el tráfico de difusión a menudo surgen tanto por acciones incorrectas en el servidor (por ejemplo, creando un puente entre varios puertos del servidor) como por la configuración incorrecta del software en los servidores. Tratamos de nivelar posibles problemas con la cantidad de tráfico de transmisión que llega a nuestra red. Pero podemos hacer esto en un puerto de conexión de servidor, y si se incluyen 5 servidores en un conmutador, cada uno de los cuales no excede los umbrales establecidos, entonces juntos pueden generar suficiente tráfico para activar el control en el conmutador de agregación. Según nuestra propia práctica, los problemas con una tormenta de transmisión desde el lado del servidor pueden ser causados por una falla específica de la tarjeta de red del servidor.
Al proteger toda la red, el conmutador de agregación "colocará" el puerto en el que se produjo la anomalía de la red. Desafortunadamente, esto conducirá a la inoperancia de los cinco servidores que causaron este incidente, así como a la inoperancia de otros servidores (hasta varios bastidores en el centro de datos).
Multidifusión
Los problemas con el procesamiento incorrecto del tráfico de multidifusión son problemas muy específicos que surgen en el complejo debido al funcionamiento incorrecto del software en el servidor y el software en el conmutador. Por ejemplo, Corosync se configura en modo multidifusión entre varios servidores. Regularmente el intercambio de paquetes de saludo se realiza en pequeños volúmenes. Pero en algunos casos, los servidores con Corosync instalado pueden reenviar una gran cantidad de paquetes. Este volumen ya requiere una configuración especial de los conmutadores o el uso de los mecanismos de procesamiento correctos (combinación IGMP y otros). En caso de funcionamiento incorrecto de los mecanismos o cuando se activan los umbrales, puede haber interrupciones del servicio que afecten a otros clientes. Por supuesto, cuantos menos clientes en el switch, menos probable es que ocurran problemas de otro cliente.
El factor humano es un tipo de problema bastante imprevisto que puede surgir al trabajar con equipos de red. Cuando el administrador de la red está solo y construye su trabajo de manera competente, documenta las acciones y reflexiona sobre las consecuencias de sus acciones, entonces la probabilidad de un error es bastante pequeña. Pero cuando la cantidad de equipos en funcionamiento del centro de datos está creciendo, cuando hay muchos empleados, cuando hay muchas tareas, se requiere un enfoque completamente diferente para la organización del trabajo.
Algunos tipos de acciones típicas están automatizadas para evitar errores humanos, pero muchos tipos de acciones no pueden automatizarse en este momento, o el precio de la automatización de tales acciones es irrazonablemente alto. Por ejemplo, el cambio físico de los cables de conexión en un panel de conexión, la conexión de nuevos enlaces, la sustitución de enlaces existentes. Todo lo relacionado con el contacto físico con SCS. Sí, hay paneles de conexión que permiten la conmutación remota, pero son muy caros, requieren mucho trabajo preparatorio y tienen capacidades muy limitadas.
Ningún panel de conexión automático colocará un nuevo cable si es necesario. Puede cometer un error al configurar un conmutador o enrutador. Indique el número de puerto incorrecto, el número de VLAN, que se sellará al ingresar un valor numérico. Al especificar cualquier configuración adicional, no tenga en cuenta su influencia en la configuración existente. Con la complejidad creciente del esquema, lo que complica el esquema de redundancia (por ejemplo, debido a que el esquema actual alcanza el límite de escala), aumenta la probabilidad de errores humanos. Cualquiera puede tener un error humano, independientemente de si el dispositivo se encuentra en la etapa de configuración, un servidor, un conmutador, un enrutador o algún tipo de dispositivo de tránsito.
Organizar copias de seguridad L2 a primera vista parece una tarea sencilla para redes pequeñas. El curso de Cisco ICND cubre los conceptos básicos del uso de STP como protocolo originalmente diseñado para proporcionar redundancia L2. STP tiene muchas restricciones que se denominan "por diseño" en este protocolo. No debemos olvidar que cualquier dominio STP tiene un "ancho" muy limitado, es decir, el número de dispositivos en un dominio STP es bastante pequeño en comparación con el número de bastidores en el centro de datos. El protocolo STP en su versión original divide los enlaces en usados y de respaldo, lo que no proporciona una utilización completa de los enlaces ascendentes durante el funcionamiento normal.
El uso de otros protocolos de reserva L2 impone sus limitaciones. Por ejemplo, ERPS (Ethernet Ring Protection Switching): para la topología física utilizada, para el número de anillos en un dispositivo, para la utilización de todos los enlaces. El uso de otros protocolos, por regla general, implica cambios de propiedad de diferentes fabricantes o limita la construcción de la red a una tecnología seleccionada (por ejemplo, TRILL / SPBm-factory usando el equipo Avaya).
Desconocido-unidifusión
Me gustaría destacar especialmente el subtipo de problemas con tráfico de unidifusión desconocido. Que es esto El tráfico destinado a una dirección IP específica a través de L3, pero se transmite en la red a través de L2, es decir, se transmite a todos los puertos que pertenecen a esta VLAN. Esta situación puede surgir por varias razones, por ejemplo, al recibir DDoS en una dirección IP desocupada. O si durante un error tipográfico en la configuración del servidor se especificó una dirección que no existe en la red como respaldo, y en el servidor históricamente hay un registro ARP estático en esta dirección. La unidifusión desconocida aparece cuando todas las entradas en las tablas ARP están presentes, pero en ausencia de la dirección MAC del receptor en las tablas de conmutación de los conmutadores de tránsito.
Por ejemplo, el puerto detrás del cual se encuentra el host de red con la dirección dada a menudo pasa al estado desactivado. Este tipo de tráfico está limitado por los conmutadores de tránsito y, a menudo, se sirve de la misma manera que la difusión o la multidifusión. Pero a diferencia de ellos, el tráfico de unidifusión desconocida puede iniciarse "desde Internet", y no solo desde la red del cliente. El riesgo de tráfico de unidifusión desconocida es especialmente alto cuando las reglas de filtrado en los enrutadores fronterizos permiten la falsificación de direcciones IP desde el exterior.
Incluso la gran cantidad de direcciones MAC a veces puede ser un problema. Parece que con un tamaño de centro de datos de 200 bastidores, 40 servidores por bastidor, es poco probable que la cantidad de direcciones MAC exceda en gran medida la cantidad de servidores en el centro de datos. Pero esto ya no es una declaración verdadera, ya que uno de los sistemas de virtualización se puede iniciar en los servidores, y cada máquina virtual se puede representar por su dirección MAC, o incluso varias (al emular varias tarjetas de red en una máquina virtual, por ejemplo). En total, podemos obtener más de varios miles de direcciones MAC legítimas de un rack en 40 servidores.
Tal cantidad de direcciones MAC puede afectar la plenitud de la tabla de conmutación en algunos modelos de conmutación. Además, para ciertos modelos de conmutadores, cuando se completa la tabla de conmutación, se utiliza el hashing y algunas direcciones MAC pueden causar colisiones de hash que conducen a la aparición de tráfico de unidifusión desconocido. La búsqueda aleatoria de direcciones MAC en un servidor arrendado a una velocidad de, por ejemplo, 4.000 direcciones por segundo, puede hacer que la tabla de conmutación se desborde en el conmutador de acceso. Naturalmente, los conmutadores aplican restricciones en la cantidad de direcciones MAC que se pueden aprender en los puertos del conmutador, pero dependiendo de la implementación específica de este mecanismo, los datos se pueden interpretar de diferentes maneras.
Nuevamente, enviar tráfico a la dirección MAC filtrada por este mecanismo conduce a la aparición de tráfico de unidifusión desconocido. Lo más desagradable en esta situación es que los interruptores rara vez son probados por el fabricante para la autocuración después de casos con desbordamiento de la mesa de conmutación. Un solo desbordamiento de la tabla, causado, por ejemplo, por un error de un cliente en los parámetros de hping o al escribir un script que monitorea su infraestructura, puede provocar el reinicio del conmutador y la interrupción de la comunicación para todos los servidores ubicados en el rack. Si se produce un desbordamiento de este tipo en el conmutador de nivel de agregación, reiniciar el conmutador puede provocar un tiempo de inactividad de 15 minutos de toda la red local del centro de datos.
Me gustaría transmitir que el uso de L2 está justificado solo para casos limitados e impone muchas restricciones. El tamaño del segmento, el número de segmentos L2: estos son todos los parámetros que deben evaluarse cada vez que agrega una nueva VLAN con conectividad L2. Y cuanto más pequeños son los segmentos L2, más simple y, como resultado, más confiable es la red en servicio.
Casos de uso típicos de L2
Como ya se mencionó, con el desarrollo gradual de la infraestructura en un centro de datos, se utiliza una red local L2. Desafortunadamente, este uso también está implicado en el desarrollo de proyectos en otro centro de datos o en otra tecnología (por ejemplo, máquinas virtuales en la nube).
Enlace frontal y back-end, respaldo
Como regla general, el uso de una red local comienza con la separación de la funcionalidad de los servicios front-end y back-end, asignando el DBMS a un servidor separado (para mejorar el rendimiento, para separar el tipo de sistema operativo en el servidor de aplicaciones y DBMS). Inicialmente, el uso de L2 para estos fines parece justificado, en el segmento solo hay unos pocos servidores, a menudo incluso se encuentran en el mismo rack.
Los servidores están incluidos en una VLAN, en uno o varios conmutadores. A medida que aumenta la cantidad de equipos, se incluyen cada vez más servidores nuevos en los conmutadores de nuevos bastidores en el centro de datos, desde los cuales el dominio L2 comienza a crecer en ancho.
Aparecen nuevos servidores, incluidos servidores de bases de datos de respaldo, servidores de respaldo y similares. Mientras el proyecto vive en un centro de datos, los problemas de escala, por regla general, no surgen. Los desarrolladores de aplicaciones simplemente se acostumbran al hecho de que en el próximo servidor de la red local, la dirección IP cambia solo en el último octeto, y no es necesario que escriba ninguna regla de enrutamiento por separado.
Se les pide a los desarrolladores que apliquen un esquema similar al crecimiento del proyecto, cuando los siguientes servidores ya se alquilan en otro centro de datos o cuando una parte del proyecto se traslada a máquinas virtuales
en la nube . En la imagen, todo se ve muy simple y hermoso:
Parece que solo necesita conectar dos conmutadores de agregación en DC1 y DC2 con una VLAN. Pero, ¿qué hay detrás de esta simple acción?
Reserva de recursos
Primero, aumentamos el ancho del dominio L2, por lo que todos los problemas potenciales de la red local de DC1 pueden surgir en DC2. ¿A quién le gustaría que sus servidores estén ubicados en DC2, y el incidente relacionado con la inaccesibilidad de la red local ocurrirá debido a acciones incorrectas dentro de DC1?
En segundo lugar, debe encargarse de hacer una copia de seguridad de esta VLAN. El conmutador de agregación en cada centro de datos es el punto de falla. El cable entre los centros de datos es otro punto de falla. Cada punto de falla debe ser reservado. Dos conmutadores de agregación, dos cables de conmutadores de agregación a conmutadores de acceso, dos cables entre centros de datos ... Cada vez que aumenta el número de componentes, y el circuito se vuelve más complicado.
La complejidad del esquema es causada por la necesidad de reservar cada elemento en el sistema. Para una copia de seguridad completa de dispositivos y enlaces, debe duplicar casi todos los elementos. En una red tan grande, ya no es posible usar STP para organizar la redundancia. Sería posible presentar todos los elementos de red, en particular los conmutadores de acceso, como componentes de la nube MPLS, luego se obtendría redundancia debido a la funcionalidad del protocolo MPLS.
Pero los dispositivos MPLS suelen ser dos veces más caros que los dispositivos que no son MPLS. Y debe tenerse en cuenta que el conmutador MPU en 1U, que tiene un buen grado de escalabilidad, la implementación de la funcionalidad MPLS completa en el plano de control, en la práctica, no existía hasta hace poco. Como resultado, deseo eliminar o minimizar el impacto de los problemas de L2 en la red existente, pero al mismo tiempo mantener la capacidad de reservar recursos.
Transición a L3
Si cada enlace en la red se representa como un segmento IP separado, y cada dispositivo como un enrutador separado, entonces no necesitamos redundancia en el nivel L2. La redundancia de enlaces y enrutadores se garantiza mediante protocolos de enrutamiento dinámico y redundancia de enrutamiento en la red.
Dentro del centro de datos, podemos guardar los esquemas de interacción del servidor existentes entre sí a través de L2, y el acceso a los servidores en otro centro de datos será a través de L3.
Por lo tanto, los centros de datos están interconectados por la conectividad L3. Es decir, se emula que se instala un enrutador entre los centros de datos (de hecho, varios, para respaldo). Esto le permite dividir dominios L2 entre centros de datos, usar su propia VLAN en cada centro de datos y comunicarse entre ellos. Para cada cliente, puede usar rangos repetidos de direcciones IP, las redes están completamente aisladas unas de otras y no puede acceder a la red de otro cliente desde la red de un cliente (excepto cuando ambos clientes acuerdan dicha conexión).
Recomendamos que utilice segmentos IP del direccionamiento 10.0.0.0/8 para redes locales. Para el primer centro de datos, la red será, por ejemplo, 10.0.1.0/24, para el segundo - 10.0.2.0/24. Selectel en el enrutador prescribe la dirección IP de esta subred. Por lo general, las direcciones .250-.254 están reservadas para los dispositivos de red Selectel, y una dirección .254 sirve como puerta de entrada a otras LAN. La ruta se asigna a todos los dispositivos en todos los centros de datos:
route add 10.0.0.0 mask 255.0.0.0 gw 10.0.x.254Donde x es el número del centro de datos. Debido a esta ruta, los servidores en los centros de datos se "ven" entre sí por enrutamiento.
La presencia de dicha ruta simplifica la escala del esquema en el caso, por ejemplo, la aparición de un tercer centro de datos. Luego, para los servidores en el tercer centro de datos, las direcciones IP del siguiente rango, 10.0.3.0/24, se registran en el enrutador, la dirección 10.0.3.254.
Una característica distintiva de la implementación de tal esquema es que no requiere reserva adicional en caso de falla del centro de datos o canales de comunicación externos. Entonces, por ejemplo, si el centro de datos 1 falla, la conexión entre el centro de datos 2 y el centro de datos 3 se conserva por completo, y al implementar el esquema con la alimentación L2 entre los centros de datos a través de uno de ellos, como en la figura:
La conexión entre el centro de datos 2 y el centro de datos 3 depende de la eficiencia del centro de datos 1. O bien, se requiere la organización de enlaces adicionales y el uso de esquemas de reserva L2 complejos. Y al guardar el esquema L2, toda la red sigue siendo muy sensible a la conmutación incorrecta, la formación de bucles de conmutación, varias tormentas de tráfico y otros problemas.
Segmentos L3 dentro de proyectos
Además de usar diferentes segmentos L3 en diferentes centros de datos, tiene sentido asignar una red L3 separada para servidores en diferentes proyectos, a menudo realizados con diferentes tecnologías. Por ejemplo, servidores de hardware en el centro de datos en una subred IP, servidores virtuales en el mismo centro de datos, pero en la nube VMware, en otra subred IP, algunos servidores relacionados con la organización en la tercera subred IP . Entonces, los errores aleatorios en uno de los segmentos no conducen a una falla completa de todos los servidores incluidos en la red local.
Reserva de enrutador
Todo esto es impresionante, pero hay un solo punto de falla entre proyectos: este es el enrutador. ¿Qué hacer en este caso? De hecho, el enrutador no está solo. Se asignan dos enrutadores para cada centro de datos, y para cada cliente forman Virtual IP .254 utilizando el protocolo VRRP.
El uso de VRRP entre dos dispositivos adyacentes con un segmento L2 común está justificado. Para los centros de datos que se distribuyen geográficamente, se utilizan diferentes enrutadores y MPLS se organiza entre ellos. Por lo tanto, cada cliente que se conecta a la red local de esta manera está conectado a un L3VPN separado hecho para él en estos enrutadores MPLS. Y el esquema, en aproximación a la realidad, se ve así:
La dirección de puerta de enlace para cada segmento .254 está reservada por VRRP entre los dos enrutadores.
Conclusión
Resumiendo todo lo anterior: cambiar el tipo de red local de L2 a L3 nos permitió mantener la capacidad de escalar, aumentó el nivel de confiabilidad y tolerancia a fallas, y también nos permitió implementar esquemas de redundancia adicionales. Además, esto eludió las restricciones existentes y las "trampas" de L2.
A medida que crecen los proyectos y los centros de datos, las soluciones estándar existentes alcanzan su límite de escalabilidad. Esto significa que ya no son adecuados para la resolución efectiva de problemas. Los requisitos de fiabilidad y estabilidad del sistema en su conjunto aumentan constantemente, lo que a su vez afecta el proceso de planificación. Es importante tener en cuenta el hecho de que deben considerarse pronósticos de crecimiento optimistas para que en el futuro no exista un sistema que no pueda escalarse.
Cuéntanos: ¿ya estás usando L3VPN? Nos vemos en los comentarios.