A nuvem é uma ilusão

As empresas podem se concentrar em produtos incríveis sem ter que se preocupar com o gerenciamento de data centers, servidores, equipamentos de rede e todas as complexidades neles.

Mas a nuvem é uma ilusão, apenas uma abstração. Por trás de cada nuvem, há data centers cheios de inúmeros racks de servidores, roteadores, firewalls e engenheiros que os projetam, implantam e gerenciam. Existe uma infraestrutura física que alimenta a tecnologia que desfrutamos todos os dias e, no Avance Network, executamos a maioria de nossas cargas de trabalho em infraestrutura bare metal. Somos, por esse motivo, nosso próprio provedor de nuvem. Este post é um pico por trás da cortina de como fazemos isso, em grande escala.

Era uma vez ...

Em, nosso novo data center entrou em operação, juntamente com nossa primeira implantação de rede 10G totalmente automatizada . Foi um grande sucesso, razão pela qual queríamos lançá-lo também em nossos outros data centers. A nova missão era migrar todos os servidores da nossa rede 1G herdada para a nova e brilhante rede 10G. Essencialmente, isso significava instalar placas de rede 10G e executar novos cabos twinax para um bom número de milhares de servidores. Nada demais ... exceto:

• A grande maioria desses servidores executa cargas de trabalho de produção
• Muitos deles executam aplicativos com estado, como armazenamentos de dados (mysql, elasticsearch etc.)
• Muitos desses aplicativos stateful podem tolerar apenas uma quantidade limitada de tempo de inatividade antes de começarem a embaralhar (muitos) dados
• Os servidores precisam ser migrados o tempo todo, sem tempo de inatividade para nenhum cluster
• Os engenheiros de aplicação e rede estão em Israel
• Os engenheiros de servidores físicos estão em Nova York
• Há uma diferença horária de 7 horas entre Nova York e Israel (a semana de trabalho também se sobrepõe apenas aos 4 dias da semana)
• Os técnicos no local que trabalham em nossos servidores não podem fazer login neles para reinicializações, verificações de integridade etc.

Quantos engenheiros são necessários para ...?

Vamos dar uma olhada em tudo o que ocorre na migração manual de um servidor, para que possamos entender melhor a tarefa em questão. Vamos restringir o foco a um caso específico: migrar um nó mysql para a nova rede.

O processo:

1. Remove o servidor mysql do cluster e garante que o cluster ainda esteja íntegro.
2. desliga adequadamente o servidor e envia os detalhes do local para a equipe de mãos remotas. Com base na localização do servidor no rack, ele também informa quais portas de switch usar.
3. Abre o servidor, instala a placa de rede 10G e executa cabos twinax redundantes nos comutadores 10G. Ele o liga de volta, conectado às redes legadas e 10G. 
4. Prepara o servidor para ingressar na rede 10G e a reinicializa para que as alterações finais entrem em vigor. Após a reinicialização, ele verifica se o servidor realmente faz parte da nova rede e se as duas conexões twinax estão ativas e estáveis.
5. Adiciona o servidor de volta ao cluster mysql e garante que tudo pareça íntegro.  
6. Remove os cabos RJ-45 antigos e aguarda que preparem e desliguem o próximo servidor (para evitar o desligamento de vários nós no mesmo cluster).

*  Esta é uma explicação simplificada do processo e assume que tudo é o mais suave possível. Envolve 4 cientistas da computação do Avance Network. São 4 cientistas para migrar um único nó.

E agora que terminamos, existem apenas alguns milhares de servidores para migrar, rodando em vários tipos de hardware, com diferentes versões do Linux, diferentes aplicativos e operando sob diferentes restrições de disponibilidade.

O que suscita a pergunta - será que vai escalar?

Como Construímos

Quando o iPad está conectado ao servidor, ele é reconhecido por uma regra do udev. Isso aciona um script de wrapper que contém toda a lógica de migração. Aqui está uma visão mais profunda das etapas e componentes individuais:

Rundeck  é usado para colocar os servidores desejados no modo de manutenção. Isso é feito tocando nos arquivos vazios nos servidores que indicam que eles estão no modo de manutenção e estão no primeiro estágio do processo de migração de rede.

O Chef  contém todos os scripts necessários para executar a migração. Isso inclui as regras do udev e os scripts específicos do wrapper, da rede e do aplicativo. A receita do Chef escolhe os scripts adequados de pré e pós-migração, com base na função do servidor.

As regras UDEV  são muito poderosas e nós as usamos para definir o que acontece quando o dispositivo é conectado a um servidor:

SUBSISTEMA == "usb",AÇÃO == "adicionar", ENV {ID_SERIAL} == "A_Inc._i_averylonguniqueserialnumber",EXECUTAR + = "/ caminho / para / wrapper_script.sh"

Esta regra se traduz aproximadamente em: "Quando um dispositivo USB com este número de série estiver conectado ao servidor, execute o seguinte script de wrapper"

Um  script de inicialização personalizado é o que aciona o script do wrapper quando o servidor é inicializado novamente após um encerramento ou reinicialização para executar a próxima etapa de migração.

O script do wrapper contém toda a lógica e funcionalidade do processo.

• É executado apenas se houver um arquivo de manutenção neste servidor.
• Ele verifica se há um arquivo de estado e, dependendo do que encontrar, entende qual parte do processo de migração será executada a seguir.
• Ele envia os logs de eventos (para o painel do Kibana), e-mails (para as equipes apropriadas que gerenciam este servidor) e mensagens do Slack (via webhooks).
• Ele lida com reinicializações e desligamentos.
• Quando ele executa um script de migração anterior / posterior à aplicação, espera obter um status de saída 0 (caso contrário, permitirá que todos os envolvidos saibam que algo deu errado).
• Quando executa o script de preparação da rede (que é digno de sua própria postagem no blog), ele pode tomar algumas decisões com base no status de saída. Ele pode tocar os alarmes, passar para a próxima etapa ou até informar ao técnico de mãos remotas que um dos cabos twinax parece solto e deve estar totalmente encaixado.
• Ele limpa removendo todos os arquivos relacionados à migração, inclusive a si próprio.

Mais tempo para criar mais automação =]

Agora podemos definir vários servidores para o modo de manutenção, entregar a lista de locais de servidores para mãos remotas e continuar nosso trabalho diário enquanto eles são migrados.

E como isso funciona tão bem usando a abordagem atual, está em andamento um trabalho para generalizar o conceito e disponibilizá-lo para muitos outros tipos de manutenção física.

Para que nossa nuvem possa continuar se construindo ... enquanto dormimos.

Máxima comunicação com proteção ao extremo? Avance Network: A verdadeira rede social junte-se a nós