Como implantamos um PoP de rede remotamente durante a crise da COVID-19
Como parte do nosso plano de controle baseado em SaaS, construímos e executamos nosso próprio backbone global (AS35280), usando vários links de 100G e 400G entre nossos PoPs.
Dessa forma, temos controle total sobre a conectividade de ponta a ponta entre nossas bordas regionais, mas isso também nos permite fornecer a mesma conectividade de alto desempenho e baixa latência aos nossos clientes — em seus data centers privados, sites de borda, VPCs de nuvem pública (AWS, Azure, GCP), bem como provedores de SaaS.
O requisito
Nossa presença europeia já era muito boa, com presença em Paris, Londres, Amsterdã e Frankfurt, mas clientes existentes e novos exigiam um novo PoP em Lisboa, Portugal.
Tudo isso foi acordado no início de 2020, e a implantação foi planejada para o terceiro trimestre de 2020. Claro, isso foi antes da COVID-19 :)
Com a crise, vimos muito mais tráfego (e também ataques DDoS, mas falaremos mais sobre isso em uma postagem futura do blog) em nosso backbone, e nossos clientes também.
Eles nos pediram para implantar antes do terceiro trimestre, porque precisavam desse PoP o mais rápido possível — mais precisamente, antes do final de maio. E como nós da Volterra somos pessoas legais, e também porque gostamos de desafios, analisamos cuidadosamente o tempo necessário para atender à demanda do cliente:
- Precisávamos de pelo menos 2 semanas para implantar e testar,
- E uma semana para validar
Sabendo que estávamos no início de abril, parecia tudo bem e decidimos continuar e lançar o projeto, mesmo sendo esse o pior momento possível para fazê-lo, devido a:
- Proibição de viajar,
- Sem acesso ao datacenter,
- Escassez global de componentes,
- Sem falar nos riscos para a saúde.
O que é necessário?
A implantação de um novo PoP não envolve apenas roteadores, switches e cabos. Você também precisa:
- realizar engenharia de rede para escolher o melhor local e provedores para ondas,
- fazer um acordo/negociar com o data center escolhido (Equinix LS1 nesse caso),
- lidar com IXP para proteger portas de peering,
- e, claro, encomendar o hardware/material relevante (roteadores, switches, cabos, firewalls, …)
Como fizemos isso
Com a crise em curso, era impossível ter o hardware necessário a tempo. Então decidimos reutilizar alguns que tínhamos disponíveis, a maioria do nosso laboratório. Essa foi uma troca aceitável (por exemplo, os roteadores usados serão o Juniper QFX10K em vez do MX10K planejado).
O staging, que normalmente fazemos obviamente em um data center (por causa da energia e do espaço em rack necessários, mas também... barulho!), teria que ser feito em casa por causa do bloqueio. Raphaël, nosso CTO de Infraestrutura, tinha um escritório grande o suficiente (incluindo um contrato de 60 A, o que pode ser útil quando você inicializa/alimenta equipamentos que consomem até 16 A!), então ele faria toda a preparação sozinho, o que também evitaria que outros funcionários se envolvessem/tivessem que sair.
Depois que tudo foi configurado e testado várias vezes, enviamos para Lisboa:
Instalação de rack em Lisboa pela Equinix remote-hands
Embora estivéssemos confiantes na configuração que fizemos (e tivéssemos acesso remoto via OOB ou nosso backbone de qualquer maneira), esta foi a primeira vez que um novo PoP não seria implantado por nós diretamente, mas por outra pessoa 😅
Usamos o mesmo design de rack em todo o mundo, e o objetivo era ser consistente e ter a mesma configuração para este novo PoP de Lisboa.
Então tivemos que ser extremamente precisos com as instruções que estávamos dando aos controles remotos da Equinix para que eles pudessem imitar e apenas tivessem que "seguir o guia".
Abaixo está uma parte do procedimento que enviamos para a Equinix - para que eles possam facilmente montar e conectar tudo.
Há muitos componentes para lidar — não apenas os dispositivos de hardware (roteadores, switches, firewalls, servidores), mas também o cabeamento e, mais importante, as portas do switch e do servidor para conectar os cabos.
Como você pode ver abaixo, o procedimento é o mais detalhado possível, tendo em mente que os técnicos da Equinix têm muita instalação para fazer, então quanto mais precisos formos, melhor!
Isso funcionou?
Sim! A instalação começou em 5 de maio, com todos os dispositivos instalados e ligados, e sem nenhuma falha de hardware — tivemos sorte, ou talvez graças à nossa experiência, o envio e a embalagem foram feitos corretamente, ou talvez ambos — mas, em qualquer caso, tudo funcionou bem.
No dia seguinte, os técnicos da Equinix cuidaram do cabeamento (cobre/fibra) e, às 23h30, conseguimos fazer ping em nosso PoP de Lisboa a partir de Paris!
A instalação foi concluída em 7 de maio, com as tarefas finais a serem realizadas, como a configuração de PDUs, conexão cruzada das portas OOB e verificação de portas IXP de ponta a ponta. Mesmo que a configuração dos nossos switches/firewall estivesse totalmente funcional, não precisávamos pedir alterações de configuração à Equinix.
A instalação final fica assim:
Como somos super exigentes, não estamos 100% satisfeitos, por exemplo, o painel traseiro do rack não está tão limpo quanto gostaríamos — mas consertaremos isso quando a crise passar e pudermos viajar novamente para Portugal.
“Post-Mortem” — o que funcionou, porquê e o que pode ser melhorado
Embora estejamos extremamente felizes e orgulhosos por termos conseguido enfrentar o desafio, gostamos de dar um passo para trás e refletir sobre o que funcionou, mas principalmente sobre o que pode ser melhorado.
O que funcionou:
- Equinix: é importante informar o provedor quando as coisas não estão indo bem, mas é ainda mais importante fazer isso quando as coisas vão bem e além — e esse é o caso aqui. Desde vendas e gerência sênior até técnicos de data center, o suporte e a reatividade que recebemos foram simplesmente incríveis — especialmente durante aqueles tempos difíceis — então, realmente, parabéns à Equinix!
Por que isso funcionou?
- A Volterra já era uma empresa principalmente distribuída e remota — especialmente nossa equipe francesa, responsável pelo NetOps, está espalhada pela França e está acostumada a trabalhar remotamente usando ferramentas colaborativas.
- Tínhamos hardware de laboratório/sobressalente suficiente para usar, o que nos permitiu chegar na hora certa
- O procedimento que explicamos brevemente acima é o resultado de anos de implantação e experiência, com melhorias iterativas, e valeu a pena.
- Ter um bom relacionamento com nossos fornecedores é essencial para nós: novamente, quando algo dá errado, atenderemos uma ligação e não teremos vergonha de contar a eles, mas, por outro lado, isso permite que eles melhorem, não apenas para nós, mas para todos os seus clientes.
- Necessidade de rapidez/preço/qualidade: Você precisa ter altas expectativas — isso inclui investir em recursos ANTES de precisar deles!
O que pode ser melhorado?
- Percebemos que apenas um punhado de pessoas (3 a 4) na empresa poderia lidar com tal implantação — precisamos encontrar uma maneira de escalar
- Além disso, queremos melhorar a forma como fazemos a preparação, para evitar ter que fazer uma preparação completa primeiro.
- Finalmente, tal implantação não é apenas uma questão técnica: Vendas/Pré-vendas devem estar cientes de quanto tempo é necessário para todo o projeto e etapas individuais — e não presumir que o NetOps pode resolver qualquer coisa e, portanto, lançar projetos sem a devida qualificação de tempo.
Apresentamos esta implantação durante a primeira reunião remota do RIPE (RIPE 80), você pode assistir à gravação aqui: