En nuestra agregación de red local había seis pares de switches Arista DCS-7050CX3-32S y un par de switches Brocade VDX 6940-36Q. No es que los switches Brocade nos causaran mayores problemas en esta red, funcionan y cumplen sus funciones, pero estábamos preparando la automatización total de algunas acciones, y no teníamos esas capacidades en esos switches. También queríamos cambiar de interfaces de 40GE a la posibilidad de utilizar 100GE, para tener margen para los próximos 2-3 años. Así que decidimos reemplazar los Brocade por Arista.
Estos switches son switches de agregación de red local para cada centro de datos. A ellos se conectan directamente los switches de distribución (segundo nivel de agregación), que ya agrupan los switches Top-of-Rack de la red local en los racks con servidores.
Cada servidor está conectado a uno o dos switches de acceso. Los switches de acceso están conectados a un par de switches de distribución (se utilizan dos switches de distribución y dos enlaces físicos desde el switch de acceso a diferentes switches de distribución para redundancia).
Cada servidor puede ser utilizado por su cliente, por lo que se asigna un VLAN separado al cliente. Este mismo VLAN se configura posteriormente en otro servidor de este cliente en cualquier rack. El centro de datos consta de varias filas de este tipo (PODs), y para cada fila de racks hay sus propios switches de distribución. Luego, estos switches de distribución se conectan a los switches de agregación.
Los clientes pueden pedir servidores en cualquier fila, predecir de antemano que un servidor será asignado o instalado en una fila concreta en un rack concreto no es posible, por lo que en los switches de agregación hay alrededor de 2500 VLAN en cada centro de datos.
El equipo para DCI (Interconexión de Centros de Datos) se conecta a los switches de agregación. Puede estar destinado para conectividad L2 (un par de switches que forman un túnel VXLAN hacia otro centro de datos), así como para conectividad L3 (dos enrutadores MPLS).
Como ya mencioné, para unificar los procesos de automatización de la configuración de servicios en el equipo de un mismo centro de datos, fue necesario reemplazar los conmutadores centrales de agregación. Instalamos nuevos conmutadores junto a los existentes, los configuramos en una pareja MLAG y comenzamos con los trabajos. Se conectaron de inmediato a los conmutadores de agregación existentes, por lo que compartieron el dominio L2 en todas las VLAN de los clientes.
Detalles del esquema
Para ser más específicos, llamaremos a los antiguos conmutadores de agregación A1 y A2, los nuevos — N1 y N2. Supongamos que en POD 1 y POD 4 están alojados los servidores de un cliente C1, la VLAN del cliente está marcada en color azul. Este cliente utiliza el servicio de conectividad L2 con otro centro de datos, por lo que su VLAN se presenta a un par de conmutadores VXLAN.
Cliente C2 alberga servidores en POD 2 y POD 3, la VLAN del cliente se indica en color verde oscuro. Este cliente también utiliza el servicio de conectividad con otro centro de datos, pero L3, por lo que su VLAN está conectada a un par de enrutadores L3VPN.
Las VLAN de los clientes son necesarias para entender en qué etapas del trabajo de reemplazo suceden las cosas, dónde hay una interrupción de la conexión y cuál puede ser su duración. El protocolo STP no se utiliza en este esquema, ya que el ancho del árbol para él resulta grande en ese caso, y la convergencia del protocolo aumenta de manera geométrica en relación con el número de dispositivos y enlaces entre ellos.
Todos los dispositivos que están conectados mediante enlaces dobles forman un stack, un par MLAG o una fábrica de Ethernet VCS. Para un par de enrutadores L3VPN no se utilizan tecnologías similares, ya que no es necesaria la redundancia L2, basta con que tengan conectividad L2 entre sí a través de los conmutadores de agregación.
Opciones de implementación
Al analizar las opciones de eventos futuros, nos dimos cuenta de que hay varias maneras de realizar estos trabajos. Desde una interrupción global en toda la red local, hasta pequeñas interrupciones de literal 1-2 segundos en partes de la red.
¡Red, detente! ¡Conmutadores, cámbiense!
La forma más sencilla es, por supuesto, declarar una interrupción global de la conexión en todos los POD y en todos los servicios DCI y cambiar todos los enlaces de los conmutadores A a los conmutadores N.
Además de la interrupción, el tiempo que no podemos predecir con certeza (sí, conocemos la cantidad de enlaces, pero no sabemos cuántas veces algo saldrá mal, desde un cable de parche roto o un conector dañado hasta una falla en el puerto o transceptor), tampoco podemos predecir de antemano si la longitud de los cables de parche, DAC, AOC conectados a los antiguos switches A alcanzará para llegar a los nuevos switches N, que aunque estén cerca, están un poco apartados, y si los mismos transceptores/DAC/AOC de los switches Brocade funcionarán en los switches Arista.
Y todo esto en medio de una fuerte presión por parte de los clientes y el soporte técnico ("¡Natasha, despierta! ¡Natasha, todo no funciona! ¡Natasha, ya hemos escrito al soporte técnico, ¡honestamente, honestamente! ¡Natasha, ya se ha caído todo! ¡Natasha, ¿cuánto más no funcionará? ¡Natasha, ¿cuándo funcionará?!"). Incluso a pesar de la interrupción anunciada de antemano y la notificación hecha a los clientes, el aflujo de consultas en ese momento está garantizado.
¡Espera, 1-2-3-4!
Y si no anunciamos una interrupción global, sino que anunciamos una serie de pequeñas interrupciones de conexión por POD y servicios DCI. En la primera interrupción, cambiar a los switches N solo POD 1, en la segunda — dentro de un par de días — POD 2, luego dentro de un par de días POD 3, luego POD 4…[N], después los switches VXLAN y luego los routers L3VPN.
Con esta organización del trabajo de conmutación, reducimos la complejidad de los trabajos simultáneos y nos damos más tiempo para resolver problemas si algo sale mal de repente. La conectividad del POD 1 después de la conmutación con otros POD y DCI no se pierde. Pero el propio trabajo se extiende por mucho tiempo, durante estas operaciones se requiere la asignación de un ingeniero en el centro de datos para realizar físicamente las conmutaciones, y durante las operaciones (que generalmente se realizan de noche, de 2 a 5 de la mañana) se necesita un ingeniero de red en línea de bastante alta calificación. Pero a cambio obtenemos cortas interrupciones de conexión, generalmente los trabajos pueden realizarse en un intervalo de media hora con un descanso de hasta 2 minutos (en la práctica, a menudo 20-30 segundos con un comportamiento esperado del equipo).
En el ejemplo proporcionado del cliente C1 o cliente C2 se deberá advertir sobre los trabajos con interrupción de la conexión al menos tres veces: la primera para realizar trabajos en un POD, en el que se encuentra uno de sus servidores; la segunda vez, en el segundo, y la tercera vez, al cambiar el equipo para los servicios de DCI.
Conmutación de canales de comunicación agregados
Por qué hablamos sobre el comportamiento esperado del equipo y cómo se pueden cambiar los canales agregados minimizando la interrupción de la conexión. Imaginemos la siguiente situación:
De un lado del enlace están los conmutadores de distribución del POD — D1 y D2, forman entre sí un par MLAG (stack, VCS-fábrica, par vPC), y del otro lado hay dos enlaces — Enlace 1 y Enlace 2 — incluidos en el par MLAG de los antiguos conmutadores de agregación A. Del lado de los conmutadores ataques se ha formado una interfaz agregada llamada Port-channel A, del lado de los conmutadores de agregación A — una interfaz agregada llamada Port-channel D.
Las interfaces agregadas en su funcionamiento utilizan LACP, es decir, los conmutadores de ambos lados intercambian regularmente paquetes LACPDU a través de ambos enlaces para asegurarse de que los enlaces:
- están operativos;
- están incluidos en un mismo par de dispositivos en el lado remoto.
Al intercambiar paquetes, en el paquete se transmite el valor system-id, que indica el dispositivo al que están conectados estos enlaces. Para un par MLAG (stack, fábrica, etc.), el valor de system-id para los dispositivos que forman la interfaz agregada es el mismo. El conmutador D1 envía en Enlace 1 valor system-id D, y el conmutador D2 envía en Enlace 2 valor system-id D.
Los conmutadores A1 y A2 analizan los paquetes LACPDU recibidos a través de una interfaz Po D y verifican la coincidencia de system-id en ellos. Si el system-id recibido a través de algún enlace resulta ser diferente del valor operativo actual, entonces este enlace se excluye de la interfaz agregada hasta que se resuelva la situación. Actualmente, en el lado de los conmutadores ataques el valor actual de system-id del socio LACP es — A, mientras que en el lado de los conmutadores A — el valor actual de system-id del socio LACP es — ataques.
En caso de necesitar cambiar la interfaz agregada, podemos proceder de dos maneras diferentes:
Método 1 — Simple
Desconectar ambos enlaces de los conmutadores A. En este caso, el canal agregado no funciona.
Conectar ambos enlaces secuencialmente a los conmutadores N, así se volverá a realizar la negociación de los parámetros de funcionamiento de LACP, la formación de la interfaz Po D en los conmutadores N y la transmisión en los enlaces del valor system-id N.
Método 2 — Minimización de la interrupción
Desconectar del conmutador A2 el enlace Link 2. De este modo, el tráfico entre A y ataques seguirá transmitiéndose simplemente a través de uno de los enlaces que permanecerá en la interfaz agregada.
Conectar Link 2 al conmutador N2. En el conmutador N ya está configurada la interfaz agregada Po DN, y el conmutador N2 comenzará a transmitir en LACPDU system-id N. En esta etapa, ya podemos comprobar que el conmutador N2 está funcionando correctamente con el transceptor que se utiliza para Enlace 2, que el puerto de conexión ha pasado al estado Up, y que durante la transmisión de LACPDU no se producen errores en el puerto de conexión.
Pero el hecho de que el conmutador D2 para la interfaz agregada Po A desde Link 2 recibe un valor system-id N, diferente del valor actual de trabajo system-id A, no permite a los conmutadores ataques introducir Enlace 2 en la interfaz agregada. Po AEl conmutador N no puede introducir Enlace 2 en funcionamiento, ya que no recibe confirmación de funcionamiento del socio LACP del conmutador. D2Al final, el tráfico a través de Enlace 2 no se transmite.
Y ahora apagamos Link 1 del conmutador A1, privando así a los conmutadores A y ataques de la interfaz agregada en funcionamiento. De este modo, en el conmutador ataques se pierde el valor actual de trabajo system-id para la interfaz. Po A.
Esto permite a los conmutadores ataques y N ponerse de acuerdo en el intercambio de system-id A-N en las interfaces, Po A y Po DNde forma que el tráfico comience a transmitirse a través del enlace Enlace 2. La interrupción en este caso es, en la práctica, de hasta 2 segundos.
Y ahora conectamos Link 1 al conmutador N1, restaurando la capacidad y el nivel de redundancia de las interfaces. Po A y Po DNDado que al conectar este enlace no se modifica el valor actual de system-id en ninguno de los lados, no se produce ninguna interrupción.
Enlaces adicionales
Pero la conmutación se puede llevar a cabo sin la presencia de un ingeniero en el momento del cambio. Para ello, necesitamos haber instalado previamente enlaces adicionales entre los conmutadores de distribución ataques y los nuevos conmutadores de agregación. N.
Instalamos nuevos enlaces entre los conmutadores de agregación N y los conmutadores de distribución de todos los POD. Esto requiere pedir y tender cables de parche adicionales, así como instalar transceptores adicionales tanto en N, así como en ataques. Podemos hacerlo, ya que en nuestros conmutadores ataques de cada POD hay puertos libres (o los desocupamos previamente). Al final, cada POD está físicamente conectado a los antiguos conmutadores A y a los nuevos conmutadores N mediante dos enlaces.
En el conmutador ataques se han formado dos interfaces agregadas — Po A con enlaces Enlace 1 y Enlace 2como Po N — con enlaces Link N1 y Link N2. En esta etapa, verificamos la correcta conexión de las interfaces y enlaces, los niveles de señales ópticas en ambos extremos de los enlaces (a través de la información DDM de los conmutadores), incluso podemos comprobar la operatividad del enlace bajo carga o monitorear el estado de las señales ópticas y la temperatura de los transceptores durante un par de días.
El tráfico todavía se transmite a través de la interfaz Po A, mientras que la interfaz Po N está sin tráfico. Las configuraciones en las interfaces son aproximadamente las siguientes:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneLos conmutadores D, por lo general, soportan el cambio de configuración por sesión, se utilizan modelos de conmutadores que tienen esta funcionalidad. Así que podemos cambiar la configuración de las interfaces Po A y Po N en una sola operación:
Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
CommitEntonces, el cambio de configuración ocurrirá bastante rápido, y la interrupción no será, en la práctica, mayor a 5 segundos.
Este método nos permite realizar todos los trabajos preparatorios con antelación, llevar a cabo todas las verificaciones necesarias, coordinar los trabajos con los participantes del proceso, prever detalladamente las acciones para la ejecución, sin improvisaciones, cuando 'todo salió mal', y tener un plan de retorno a la configuración anterior. Estos trabajos se llevan a cabo por un ingeniero de red sin la presencia en el sitio del ingeniero del centro de datos, quien realiza físicamente las conmutaciones.
Lo que también es importante en este método de conmutación es que todos los nuevos enlaces ya están previamente configurados para la monitorización. Errores, inclusión de enlaces en el agregado, carga de enlaces — toda la información necesaria ya está en el sistema de monitoreo, y esto ya se ha plasmado en los mapas.
D-Day
POD
Hemos elegido el camino menos doloroso para los clientes y menos propenso a alternativas 'algo salió mal' para las conmutaciones con enlaces adicionales. Así, en un par de noches, cambiamos todos los POD a los nuevos conmutadores de agregación.
Pero aún queda por cambiar el equipo que proporciona servicios DCI.
L2
En el caso de equipos que ofrecen conectividad L2, no pudimos realizar trabajos similares con enlaces adicionales. Hay al menos dos razones para esto:
- La falta de puertos libres a la velocidad necesaria en los conmutadores VXLAN.
- La falta de funcionalidad de cambio de configuración por sesión en los conmutadores VXLAN.
No realizamos el cambio de enlaces 'uno a uno' con un intervalo solo durante la sincronización de un nuevo par de system-id, ya que no teníamos 100% de confianza en que el procedimiento se llevaría a cabo correctamente, y la prueba en laboratorio mostró que, si 'algo sale mal', aún así experimentamos una interrupción de la conexión, y lo más preocupante es que no solo afecta a los clientes que tienen conectividad L2 con otros centros de datos, sino a todos los clientes de este centro de datos.
Con anticipación, realizamos un trabajo de concienciación sobre la transición de canales L2, por lo que el número de clientes afectados por los trabajos en los conmutadores VXLAN ya era varias veces menor que hace un año. En última instancia, decidimos realizar la interrupción de la conexión para el servicio de conectividad L2, con la condición de que mantuvieramos el funcionamiento normal de los servicios de red local en un centro de datos. Además, el SLA para este servicio prevé la posibilidad de realizar trabajos programados con interrupción.
L3
¿Por qué recomendamos a todos pasar a utilizar L3VPN al organizar servicios DCI? Una de las razones es la posibilidad de realizar trabajos en uno de los enrutadores que proporcionan este servicio, simplemente reduciendo el nivel de redundancia a N+0, sin interrumpir la conexión.
Veamos el esquema de prestación del servicio con más detalle. En este servicio, el segmento L2 va desde los servidores de los clientes solo hasta los enrutadores L3VPN de Selectel. En los enrutadores se termina la red del cliente.
Cada servidor del cliente, por ejemplo, S2 y S3 en el esquema presentado, tiene su propia dirección privada IP — 10.0.0.2/24 en el servidor S2 y 10.0.0.3/24 en el servidor S3. Las direcciones 10.0.0.252/24 y 10.0.0.253/24 son asignadas por Selectel a los enrutadores L3VPN-1 y L3VPN-2, respectivamente. La dirección IP 10.0.0.254/24 es la dirección VIP de VRRP en los enrutadores Selectel.
Más información sobre el servicio L3VPN se puede encontrar en nuestro blog.
Hasta el momento del cambio, todo se veía aproximadamente como en el esquema:
Los dos enrutadores L3VPN-1 y L3VPN-2 estaban conectados al antiguo conmutador de agregación A. El maestro para la dirección VIP de VRRP 10.0.0.254 es el enrutador L3VPN-1. Este tiene una prioridad para esta dirección superior a la del enrutador. L3VPN-2.
unidad 1006 {
descripción C2;
vlan-id 1006;
familia inet {
dirección 10.0.0.252/24 {
grupo-vrrp 1 {
prioridad 200;
dirección-virtual 10.100.0.254;
preempt {
tiempo-de-espera 120;
}
aceptar-datos;
}
}
}
}El servidor S2 para comunicarse con servidores en otras ubicaciones utiliza la puerta de enlace 10.0.0.254. Así, la desconexión de la red del enrutador L3VPN-2 (naturalmente, después de desconectarlo del dominio MPLS) no afecta la conectividad de los servidores del cliente. En este momento, solo disminuye el nivel de redundancia del esquema.
Después de eso, podemos reconectar el enrutador tranquilamente. L3VPN-2 a un par de conmutadores. N. Establecer enlaces, cambiar transceptores. Las interfaces lógicas del enrutador, de las que depende el funcionamiento de los servicios del cliente, estarán desconectadas hasta que se confirme que todo funciona correctamente.
Después de verificar los enlaces, transceptores, niveles de señal y niveles de errores en las interfaces, el enrutador se pone en funcionamiento, pero ya conectado a la nueva pareja de conmutadores.
Luego, disminuimos la prioridad VRRP del enrutador L3VPN-1, y la dirección VIP 10.0.0.254 se mueve al enrutador L3VPN-2. Estos trabajos también se realizan sin interrupción de la conexión.
La transferencia de la dirección VIP 10.0.0.254 al enrutador L3VPN-2 permite desconectar el enrutador L3VPN-1 sin interrupción de la conexión para el cliente y conectarlo ya a la nueva pareja de conmutadores de agregación. N.
Si devolver la VIP de VRRP al enrutador L3VPN-1 es una opción o no, es una cuestión diferente, y si se devuelve, se hace sin interrupción de la conexión.
Total
Después de todas estas acciones, realmente hemos reemplazado los conmutadores de agregación en uno de nuestros centros de datos, minimizando así las interrupciones para nuestros clientes.
A continuación, solo queda el desmantelamiento. Desmantelar los antiguos conmutadores, desmantelar los antiguos enlaces entre los conmutadores A y D, desmantelar los transceptores de esos enlaces, corregir la monitorización, corregir los esquemas de red en la documentación y la monitorización.
Los conmutadores, transceptores, cables de parcheo, AOC, DAC que quedan después de los cambios, podemos utilizarlos en otros proyectos o en otros cambios similares.
«Natasha, ¡hemos cambiado todo!»
Fuente: habr.com
