À medida que você trabalha em TI, você começa a perceber que os sistemas têm características próprias. Eles podem ser flexíveis, silenciosos, excêntricos e severos. Eles podem atrair ou repelir. De uma forma ou de outra, é preciso “negociar” com eles, manobrar entre as “armadilhas” e construir cadeias de sua interação.
Portanto, tivemos a honra de construir uma plataforma em nuvem e, para isso, precisávamos “persuadir” alguns subsistemas a trabalharem conosco. Felizmente temos uma “linguagem API”, mãos diretas e muito entusiasmo.
Este artigo não será tecnicamente pesado, mas descreverá os problemas que encontramos durante a construção da nuvem. Decidi descrever nosso caminho na forma de uma leve fantasia técnica sobre como buscamos uma linguagem comum com os sistemas e o que resultou dela.
Bem-vindo ao gato.
Início de uma jornada
Há algum tempo, nossa equipe recebeu a tarefa de lançar uma plataforma em nuvem para nossos clientes. Tivemos suporte de gestão, recursos, stack de hardware e liberdade na escolha de tecnologias para implementação da parte de software do serviço.
Havia também uma série de requisitos:
- o serviço precisa de uma conta pessoal conveniente;
- a plataforma deve estar integrada ao sistema de cobrança existente;
- software e hardware: OpenStack + Tungsten Fabric (Open Contrail), que nossos engenheiros aprenderam a “cozinhar” muito bem.
Contaremos em outro momento como a equipe foi montada, a interface da conta pessoal foi desenvolvida e as decisões de design foram tomadas, caso a comunidade Habra esteja interessada.
As ferramentas que decidimos usar:
- Python + Flask + Swagger + SQLAlchemy - um conjunto Python completamente padrão;
- Vue.js para front-end;
- Decidimos fazer a interação entre componentes e serviços utilizando Celery sobre AMQP.
Antecipando dúvidas sobre a escolha do Python, vou explicar. A língua encontrou o seu nicho na nossa empresa e uma pequena, mas ainda assim, cultura, desenvolveu-se em torno dela. Portanto, decidiu-se começar a construir o serviço nele. Além disso, a velocidade de desenvolvimento de tais problemas é muitas vezes decisiva.
Então, vamos começar nosso conhecimento.
Conta Silenciosa - faturamento
Conhecemos esse cara há muito tempo. Ele sempre se sentava ao meu lado e contava alguma coisa em silêncio. Às vezes, ele nos encaminhava solicitações de usuários, emitia faturas de clientes e gerenciava serviços. Um cara comum e trabalhador. É verdade que houve dificuldades. Ele é silencioso, às vezes pensativo e muitas vezes pensando sozinho.
O faturamento é o primeiro sistema com o qual tentamos fazer amizade. E a primeira dificuldade que encontramos foi no processamento dos serviços.
Por exemplo, quando criada ou excluída, uma tarefa entra na fila de cobrança interna. Assim, é implementado um sistema de trabalho assíncrono com serviços. Para processar nossos tipos de serviço, precisávamos “colocar” nossas tarefas nesta fila. E aqui nos deparamos com um problema: falta de documentação.
A julgar pela descrição da API do software, ainda é possível resolver esse problema, mas não tivemos tempo de fazer engenharia reversa, então levamos a lógica para fora e organizamos uma fila de tarefas em cima do RabbitMQ. Uma operação em um serviço é iniciada pelo cliente a partir de sua conta pessoal, transforma-se em uma “tarefa” do Celery no backend e é realizada no lado do faturamento e do OpenStack. O aipo torna bastante conveniente gerenciar tarefas, organizar repetições e monitorar status. Você pode ler mais sobre “aipo”, por exemplo, .
Além disso, o faturamento não impediu um projeto que ficou sem dinheiro. Comunicando-nos com os desenvolvedores, descobrimos que ao calcular estatísticas (e precisamos implementar exatamente esse tipo de lógica), existe uma inter-relação complexa de regras de parada. Mas estes modelos não se adaptam bem à nossa realidade. Também o implementamos por meio de tarefas no Celery, levando a lógica de gerenciamento de serviços para o backend.
Ambos os problemas acima fizeram com que o código ficasse um pouco inchado e, no futuro, teremos que refatorar para mover a lógica de trabalho com tarefas para um serviço separado. Também precisamos armazenar algumas informações sobre os usuários e seus serviços em nossas tabelas para dar suporte a essa lógica.
Outro problema é o silêncio.
Billy responde silenciosamente “Ok” a algumas solicitações de API. Este foi o caso, por exemplo, quando efetuamos pagamentos prometidos durante o teste (mais sobre isso mais tarde). As solicitações foram executadas corretamente e não encontramos nenhum erro.
Tive que estudar os logs enquanto trabalhava com o sistema por meio da UI. Descobriu-se que o próprio faturamento realiza solicitações semelhantes, alterando o escopo para um usuário específico, por exemplo, admin, passando-o no parâmetro su.
No geral, apesar das lacunas na documentação e pequenas falhas na API, tudo correu muito bem. Os logs podem ser lidos mesmo sob carga pesada se você entender como eles estão estruturados e o que procurar. A estrutura do banco de dados é ornamentada, mas bastante lógica e, em alguns aspectos, até atraente.
Então, resumindo, os principais problemas que encontramos na fase de interação estão relacionados aos recursos de implementação de um sistema específico:
- “características” não documentadas que nos afetaram de uma forma ou de outra;
- código fechado (o faturamento é escrito em C++), como resultado - é impossível resolver o problema 1 de outra forma que não seja “tentativa e erro”.
Felizmente, o produto possui uma API bastante extensa e integramos os seguintes subsistemas em nossa conta pessoal:
- módulo de suporte técnico - as solicitações da sua conta pessoal são “procuradas” para o faturamento de forma transparente para os clientes do serviço;
- módulo financeiro - permite emitir faturas para clientes atuais, efetuar baixas e gerar documentos de pagamento;
- módulo de controle de serviço - para isso tivemos que implementar nosso próprio manipulador. A capacidade de expansão do sistema fez o nosso favor e “ensinamos” a Billy um novo tipo de serviço.
Foi um pouco complicado, mas de uma forma ou de outra, acho que Billy e eu nos daremos bem.
Caminhando por campos de tungstênio – Tecido de Tungstênio
Campos de tungstênio pontilhados por centenas de fios, passando por eles milhares de bits de informação. As informações são coletadas em “pacotes”, analisadas, construindo rotas complexas, como num passe de mágica.
Este é o domínio do segundo sistema com o qual tivemos que fazer amizade - Tungsten Fabric (TF), antigo OpenContrail. Sua tarefa é gerenciar equipamentos de rede, fornecendo uma abstração de software para nós, usuários. TF - SDN, encapsula a lógica complexa de trabalhar com equipamentos de rede. Há um bom artigo sobre a tecnologia em si, por exemplo, .
O sistema é integrado ao OpenStack (discutido abaixo) por meio do plugin Neutron.
Interação de serviços OpenStack.
O pessoal do departamento de operações nos apresentou esse sistema. Usamos a API do sistema para gerenciar a pilha de rede dos nossos serviços. Ainda não nos causou problemas ou inconvenientes graves (não posso falar pelo pessoal da OE), mas tem havido algumas estranhezas na interação.
O primeiro ficou assim: comandos que exigiam a saída de uma grande quantidade de dados para o console da instância ao conectar via SSH simplesmente “desligavam” a conexão, enquanto via VNC tudo funcionava corretamente.
Para quem não está familiarizado com o problema, parece bastante engraçado: ls /root funciona corretamente, enquanto, por exemplo, top “congela” completamente. Felizmente, já encontramos problemas semelhantes antes. Foi decidido ajustar o MTU na rota dos nós de computação para os roteadores. A propósito, este não é um problema de TF.
O próximo problema estava ao virar da esquina. Em um momento “lindo”, a magia do roteamento desapareceu, sem mais nem menos. TF parou de gerenciar o roteamento no equipamento.
Trabalhamos com Openstack desde o nível de administrador e depois passamos para o nível de usuário necessário. A SDN parece “sequestrar” o escopo do usuário por quem as ações são executadas. O fato é que a mesma conta de administrador é usada para conectar TF e OpenStack. Na etapa de mudança para o usuário, a “mágica” desapareceu. Foi decidido criar uma conta separada para trabalhar com o sistema. Isso nos permitiu trabalhar sem interromper a funcionalidade de integração.
Formas de vida de silício - OpenStack
Uma criatura de silicone de formato bizarro vive perto de campos de tungstênio. Acima de tudo, parece uma criança crescida que pode nos esmagar com um golpe, mas não há nenhuma agressão óbvia vinda dela. Não causa medo, mas o seu tamanho inspira medo. Assim como a complexidade do que está acontecendo ao redor.
OpenStack é o núcleo da nossa plataforma.
OpenStack possui vários subsistemas, dos quais atualmente usamos Nova, Glance e Cinder de forma mais ativa. Cada um deles possui sua própria API. Nova é responsável pelos recursos computacionais e pela criação de instâncias, Cinder é responsável por gerenciar volumes e seus instantâneos, Glance é um serviço de imagem que gerencia modelos de sistema operacional e metainformações sobre eles.
Cada serviço é executado em um contêiner, e o corretor de mensagens é o “coelho branco” – RabbitMQ.
Este sistema nos causou os problemas mais inesperados.
E o primeiro problema não demorou a surgir quando tentamos conectar um volume adicional ao servidor. A API Cinder recusou-se terminantemente a realizar esta tarefa. Mais precisamente, se você acredita no próprio OpenStack, a conexão foi estabelecida, mas não há dispositivo de disco dentro do servidor virtual.
Decidimos fazer um desvio e solicitamos a mesma ação da API Nova. O resultado é que o dispositivo se conecta corretamente e fica acessível no servidor. Parece que o problema ocorre quando o armazenamento em bloco não responde ao Cinder.
Outra dificuldade nos esperava ao trabalhar com discos. O volume do sistema não pôde ser desconectado do servidor.
Novamente, o próprio OpenStack “jura” que destruiu a conexão e agora você pode trabalhar corretamente com o volume separadamente. Mas a API categoricamente não queria realizar operações no disco.
Aqui decidimos não lutar particularmente, mas mudar a nossa visão sobre a lógica do serviço. Se houver uma instância, também deverá haver um volume do sistema. Portanto, o usuário ainda não pode remover ou desabilitar o “disco” do sistema sem deletar o “servidor”.
OpenStack é um conjunto bastante complexo de sistemas com sua própria lógica de interação e API ornamentada. Somos ajudados por documentação bastante detalhada e, claro, por tentativa e erro (onde estaríamos sem ela).
Execução de teste
Realizamos um lançamento de teste em dezembro do ano passado. A principal tarefa foi testar nosso projeto em modo de combate do lado técnico e do lado UX. O público foi convidado seletivamente e a prova foi encerrada. Porém, também deixamos a opção de solicitar acesso aos testes em nosso site.
O teste em si, claro, teve momentos engraçados, pois é aqui que nossas aventuras estão apenas começando.
Em primeiro lugar, avaliamos de forma um tanto incorreta o interesse no projeto e tivemos que adicionar nós de computação rapidamente durante o teste. Um caso comum para um cluster, mas também havia algumas nuances aqui. A documentação para uma versão específica do TF indica a versão específica do kernel no qual o trabalho com o vRouter foi testado. Decidimos lançar nós com kernels mais recentes. Como resultado, o TF não recebeu rotas dos nós. Tive que reverter urgentemente os kernels.
Outra curiosidade está relacionada à funcionalidade do botão “alterar senha” da sua conta pessoal.
Decidimos usar o JWT para organizar o acesso à nossa conta pessoal para não trabalhar com sessões. Como os sistemas são diversos e muito dispersos, gerenciamos nosso próprio token, no qual “embrulhamos” sessões de faturamento e um token do OpenStack. Quando a senha é alterada, o token, claro, “fica ruim”, já que os dados do usuário não são mais válidos e precisam ser reemitidos.
Perdemos este ponto de vista e simplesmente não havia recursos suficientes para terminar esta peça rapidamente. Tivemos que cortar a funcionalidade antes de iniciar o teste.
Atualmente desconectamos o usuário se a senha tiver sido alterada.
Apesar dessas nuances, os testes correram bem. Em algumas semanas, cerca de 300 pessoas passaram por aqui. Conseguimos observar o produto através dos olhos dos usuários, testá-lo em ação e coletar feedback de alta qualidade.
Para ser continuado
Para muitos de nós, este é o primeiro projeto desta escala. Aprendemos uma série de lições valiosas sobre como trabalhar em equipe e tomar decisões arquitetônicas e de design. Como integrar sistemas complexos com poucos recursos e colocá-los em produção.
Claro, há algo para trabalhar tanto em termos de código quanto nas interfaces de integração do sistema. O projeto é bastante recente, mas estamos cheios de ambições para transformá-lo num serviço confiável e conveniente.
Já conseguimos persuadir os sistemas. Bill lida obedientemente com contagem, cobrança e solicitações de usuários em seu armário. A “mágica” dos campos de tungstênio nos proporciona uma comunicação estável. E apenas o OpenStack às vezes fica caprichoso, gritando algo como “'WSREP ainda não preparou o nó para uso do aplicativo”. Mas essa é uma história completamente diferente...
Lançamos recentemente o serviço.
Você pode descobrir todos os detalhes em nosso .
Equipe de Desenvolvimento CLO
Links úteis
OpenStack
Tecido de tungstênio
Fonte: habr.com