Desde nada hasta centro de datos con VXLAN / EVPN o cómo cocinar Cumulus Linux. Parte 1

En los últimos seis meses, logramos trabajar en un gran e interesante proyecto, que incluía todo: desde la instalación de equipos hasta la creación de un solo dominio VXLAN / EVPN en 4 centros de datos. Porque Tenía mucha experiencia y muchos obstáculos en el proceso, decidí que escribir algunos artículos sobre este tema sería la mejor solución. Decidí hacer la primera parte más general e introductoria. El diseño objetivo de la fábrica se revelará en la siguiente sección.

Presentamos Cumulus Linux. Instalación de hardware y configuración inicial

Introductorios al inicio del trabajo fueron los siguientes:

1. Equipo comprado
2. Racks alquilados
3. Colocación de líneas a antiguos centros de datos

La primera pieza de hardware que debió entregarse fue 4 x Mellanox SN2410 con Cumulus Linux preinstalado en ellos. Al principio, todavía no se entendía cómo se vería todo (se desarrollará solo en la etapa de implementación de VXLAN / EVPN), por lo tanto, decidimos plantearlos como simples switches L3 con CLAG (Analogue of MLAG from Cumulus). Anteriormente, ni yo ni mis colegas teníamos mucha experiencia con Cumulus, por lo que todo era hasta cierto punto nuevo, entonces solo eso.

Sin licencia, sin puertos

De forma predeterminada, cuando enciende el dispositivo, solo tiene 2 puertos disponibles: consola y eth0 (también conocido como puerto de administración). Para desbloquear puertos 25G / 100G, debe agregar una licencia. E inmediatamente queda claro que Linux en el nombre del software no es en vano, ya que después de instalar la licencia, debe reiniciar el demonio switchd a través de "systemctl restart switchd.service" (de hecho, la falta de una licencia simplemente evita que este demonio se inicie).



Lo siguiente que te hará recordar de inmediato que esto sigue siendo Linux, será actualizar el dispositivo usando apt-get upgrade, como en Ubuntu normal, pero no siempre es posible actualizar de esta manera. Al cambiar entre versiones, por ejemplo, de 3.1.1 a 4.1.1, debe instalar una nueva imagen, lo que implica restablecer las configuraciones a las predeterminadas. Pero guarda que DHCP está habilitado en la interfaz de administración en la configuración predeterminada, lo que le permite devolver el control.

Sistema de compromiso

Como persona que ha trabajado mucho con Juniper, para mí cosas como retrocesos, confirmación de confirmación, etc. no eran nuevos, pero lograron pisar un par de rastrillos.



Lo primero que encontré fue la numeración de retroceso de los cúmulos, debido al hábito de retroceder 1 == la última configuración de trabajo. Manejo este comando con gran confianza para revertir los últimos cambios. Pero cuál fue mi sorpresa cuando la pieza de hardware simplemente desapareció en control, y durante algún tiempo no entendí qué había sucedido. Luego, después de leer el dock de cumulus, quedó claro lo que había sucedido: al ejecutar el comando "net rollback 1" en lugar de retroceder a la última configuración, volví a la PRIMERA configuración del dispositivo (y nuevamente, DHCP salvó del fiasco en la configuración predeterminada)





La segunda cosa que tuve que enfrentar fue el algoritmo de confirmación de confirmación: a diferencia del habitual "confirmación de confirmación 10", donde en 10 minutos necesitas escribir "confirmación" de nuevo, Cumulus tenía su propia visión de esta función. Su "confirmación de confirmación" es simplemente presionar Enter después de ingresar un comando, lo que puede jugarle una broma cruel si la conectividad no se pierde inmediatamente después de la confirmación.

Primera topología

La siguiente etapa fue resolver la lógica de los conmutadores entre ellos, en esta etapa el hardware solo se instaló y probó, todavía no se habló de ningún esquema de destino. Pero una de las condiciones era que los servidores conectados a diferentes pares MLAG deberían estar en el mismo dominio L2. No quería que uno de los pares fuera simple L2 y, por lo tanto, se decidió aumentar la conectividad L3 sobre SVI, se eligió OSPF para el enrutamiento, ya que ya se ha utilizado en centros de datos más antiguos, lo que facilita la conexión de la infraestructura en el siguiente paso.







Este diagrama muestra el diagrama de física + la división de dispositivos en pares, todos los enlaces en el diagrama funcionan en modo Trunk.







Como se mencionó, toda la conectividad L3 se realiza a través de SVI, por lo tanto, solo 2 de los 4 dispositivos tienen una dirección IP en cada Vlan, lo que le permite hacer una especie de paquete L3 p2p.

Comandos básicos para los interesados

Conclusión

Espero que alguien encuentre interesante este artículo. Me gustaría ver comentarios: qué agregar y qué es completamente innecesario. En el próximo artículo, ya pasaremos a lo más interesante: el diseño de la red de destino y la configuración de VXLAN / EVPN. Y en el futuro, es posible un artículo sobre la automatización de VXLAN / EVPN usando Python.