Cómo implementamos un PoP de red de forma remota durante la crisis de la COVID-19
Como parte de nuestro plano de control basado en SaaS, hemos construido y operado nuestra propia red troncal global (AS35280), utilizando múltiples enlaces de 100G y 400G entre nuestros PoP.
De esa manera, tenemos control total sobre la conectividad de extremo a extremo entre nuestros bordes regionales, pero también nos permite brindar la misma conectividad de alto rendimiento y baja latencia a nuestros clientes, en sus centros de datos privados, sitios de borde, VPC de nube pública (AWS, Azure, GCP), así como proveedores de SaaS.
El requisito
Nuestra presencia europea ya era bastante buena, con presencia en París, Londres, Ámsterdam y Frankfurt, pero los clientes existentes y nuevos requerían un nuevo PoP en Lisboa, Portugal.
Todo esto se acordó a principios de 2020 y el despliegue estaba previsto para el tercer trimestre de 2020. Por supuesto, esto fue antes del COVID-19 :)
Con la crisis, vimos mucho más tráfico (y también ataques DDoS, pero hablaremos más sobre eso en una futura publicación del blog) en nuestra red troncal, y nuestros clientes también.
Nos pidieron que lo implementáramos antes del tercer trimestre, porque necesitaban este PoP lo antes posible, más precisamente, antes de fines de mayo. Y como en Volterra somos gente maja, y además nos gustan los retos, hemos analizado con atención el tiempo necesario para satisfacer la demanda del cliente:
- Necesitábamos al menos dos semanas para implementarlo y probarlo,
- Y una semana para validar
Sabiendo que estábamos a principios de abril, esto parecía bien y decidimos seguir adelante y lanzar el proyecto, aunque realmente era el peor momento posible para hacerlo, debido a:
- Prohibición de viajar,
- Sin acceso al centro de datos,
- Escasez mundial de componentes,
- Sin contar los riesgos para la salud.
¿Qué se necesita?
Implementar un nuevo PoP no solo implica enrutadores, conmutadores y cables. También necesitarás:
- Realizar ingeniería de red para elegir la mejor ubicación y proveedores de ondas,
- llegar a un acuerdo/negociar con el centro de datos elegido (Equinix LS1 en ese caso),
- tratar con IXP para proteger los puertos de peering,
- y por supuesto pedir el hardware/material correspondiente (routers, switches, cables, firewalls, …)
Cómo lo hicimos
Con la crisis actual, disponer del hardware necesario a tiempo era imposible. Así que decidimos reutilizar algunos que teníamos disponibles, la mayoría de nuestro laboratorio. Este fue un compromiso aceptable (por ejemplo, los enrutadores utilizados serán Juniper QFX10K en lugar del MX10K planificado).
La puesta en escena, que normalmente hacemos obviamente en un centro de datos (debido a la energía y al espacio en rack necesarios, pero también… ¡al ruido!), tendría que hacerse en casa debido al confinamiento. Raphaël, nuestro CTO de Infraestructura, tenía una sala de oficinas lo suficientemente grande (incluido un contrato de 60 amperios, que puede resultar útil cuando se arrancan o alimentan equipos que consumen hasta 16 amperios), por lo que haría toda la puesta en escena él solo, lo que también evitaría tener que involucrar a otro personal o tener que salir.
Una vez que todo estuvo configurado y probado varias veces, enviamos a Lisboa:
Instalación de rack en Lisboa por Equinix con manos remotas
Aunque estábamos seguros de la configuración que hicimos (y teníamos acceso remoto a través de OOB o nuestra red troncal de todos modos), aún así, esta fue la primera vez que un nuevo PoP no sería implementado directamente por nosotros, sino por otra persona 😅
Utilizamos el mismo diseño de rack en todo el mundo y el objetivo era ser consistente y tener la misma configuración para este nuevo PoP de Lisboa.
Así que tuvimos que ser extremadamente precisos con las instrucciones que les dábamos a los operadores remotos de Equinix para que pudieran imitar y simplemente tuvieran que "seguir la guía".
A continuación se muestra una parte del procedimiento que enviamos a Equinix para que puedan montar y conectar todo fácilmente.
Hay muchos componentes con los que lidiar: no solo los dispositivos de hardware (enrutadores, conmutadores, firewalls, servidores), sino también el cableado y, lo que es más importante, los puertos del conmutador y del servidor a los que conectar los cables.
Como puedes ver a continuación, el procedimiento es lo más detallado posible, teniendo en cuenta que los técnicos de Equinix tienen muchas instalaciones que realizar, así que cuanto más precisos seamos, ¡mejor!
¿Eso funcionó?
¡Sí! La instalación comenzó el 5 de mayo, con todos los dispositivos en rack y encendidos, y sin fallos de hardware (hemos tenido suerte, o quizás gracias a nuestra experiencia, el envío y el embalaje se hicieron correctamente, o quizás ambas cosas), pero en cualquier caso, todo funcionó bien.
Al día siguiente, los técnicos de Equinix se encargaron del cableado (cobre/fibra) y a las 23:30 pudimos hacer ping a nuestro PoP de Lisboa desde París.
La instalación se completó el 7 de mayo, quedando pendientes las tareas finales como configuración de PDUs, Cross-connect de los puertos OOB, check end to end de puertos IXP. Incluso nuestra configuración de conmutadores y firewalls era completamente funcional; no tuvimos que pedirle a Equinix que realizara cambios de configuración.
La instalación final se ve así:
Como somos súper exigentes, no estamos 100% satisfechos, por ejemplo, el panel trasero del rack no está tan limpio como nos gustaría que estuviera, pero lo arreglaremos cuando la crisis se calme y podamos viajar nuevamente a Portugal.
“Post-mortem”: qué funcionó, por qué y qué se puede mejorar
Aunque estamos muy contentos y orgullosos de haber logrado superar el desafío, nos gusta dar un paso atrás y reflexionar sobre lo que funcionó, pero sobre todo sobre lo que se puede mejorar.
Lo que funcionó:
- Equinix: es importante informar a un proveedor cuando las cosas no van bien, pero es aún más importante hacerlo cuando las cosas van bien y más allá, y ese es el caso aquí. Desde el equipo de ventas y la alta gerencia hasta los técnicos del centro de datos, el apoyo y la reactividad que recibimos fueron simplemente increíbles, especialmente durante esos tiempos difíciles, así que realmente, ¡felicitaciones a Equinix!
¿Por qué funcionó eso?
- Volterra ya era principalmente una empresa distribuida y remota; en particular, nuestro equipo francés, responsable de NetOps, está repartido por toda Francia y está acostumbrado a trabajar de forma remota utilizando herramientas colaborativas.
- Tuvimos suficiente hardware de repuesto/de laboratorio para usar, lo que nos permitió llegar a tiempo.
- El procedimiento que explicamos brevemente arriba es el resultado de años de implementación y experiencia, con mejoras iterativas, y ha dado sus frutos.
- Tener una buena relación con nuestros proveedores es fundamental para nosotros: cuando algo sale mal, los llamamos y no dudamos en decírselo, pero, por otro lado, esto les permite mejorar, no solo para nosotros, sino para todos sus clientes.
- Necesidad de velocidad/precio/calidad: Debes tener expectativas altas, ¡y esto incluye invertir en recursos ANTES de necesitarlos!
¿Qué se puede mejorar?
- Nos dimos cuenta de que solo un puñado de personas (3 o 4) en la empresa podrían manejar tal implementación; necesitamos encontrar una manera de escalar
- Además, queremos mejorar la forma en que realizamos la puesta en escena, para evitar tener que hacer una puesta en escena completa primero.
- Por último, tal despliegue no es sólo una cuestión técnica: El equipo de ventas y preventa debe ser consciente de cuánto tiempo se necesita para todo el proyecto y sus pasos individuales, y no asumir que NetOps puede resolver cualquier cosa y, por lo tanto, descartar proyectos sin una calificación de tiempo adecuada.
Presentamos este despliegue durante la primera reunión remota de RIPE (RIPE 80), puedes ver la grabación aquí: