OpenStack: toda a verdade sobre o lançamento "real"

Woland em M. Bulgakov disse que "um tijolo sem motivo nunca cairá sobre a cabeça de ninguém". Talvez sim, mas quando me perguntaram há dois anos e meio se eu queria conhecer o OpenStack, era aquele tijolo muito bem velado (e nem mesmo um tijolo, mas uma laje de granito no início). Foi em 2016 que se tornou o chamado “ponto sem retorno” para mim, estabelecendo as bases para o rápido desenvolvimento dos conceitos de mundo aberto e influenciando significativamente a mentalidade, transformando minha vida futura em um feriado. "Holiday", que está sempre comigo.

2016 - hoje

O OpenStack não era amor à primeira vista. O primeiro lançamento que implantei para testes foi o Kilo, que rimava facilmente com a palavra "triste". Existindo por exatamente três semanas, esperava-se que ele fosse substituído por Liberty, que, sob um invólucro atraente - notas de versão - era incapaz de atender às altas expectativas. A Mitaka não trouxe tanto novas funcionalidades, pois continha muitas correções e "correções" e ainda é (!) Usada com sucesso em ambientes produtivos. Newton, de fato, foi um ponto de virada na história do OpenStack, fornecendo tantas alterações arquiteturais, lógicas e, como resultado, de configuração que bloquearam para sempre o caminho de atualização da versão anterior para muitas nuvens privadas. Mas foi com o lançamento da Ocata em 2017, de acordo com analistas , que começou a “era de ouro” do OpenStack, que inclui Pike, Queens e, sinceramente, espero que Rocky, que está em um começo baixo, entre.


Este artigo se concentrará na versão estável mais recente do OpenStack - Queens, em algumas inovações e deficiências - do ponto de vista de uma pessoa que estava automatizando sua implantação com base na distribuição Ubuntu 16.04 LTS (e continua a fazê-lo porque não há limite para a perfeição) .

Não há muito material sobre o Queens na rede (se você excluir a documentação e os relatórios oficiais do recente OpenStack Summit em Vancouver da amostra), e o número de análises de provedores de nuvem e integradores de sistemas pode ser contado com os dedos de uma mão. Não é de surpreender que seu antecessor - Pike, cujo suporte oficial durará mais oito meses - com centenas de usuários treinados e um procedimento de atualização bem documentado, pareça mais adequado para implementação. Nossa equipe, que acompanha de perto o processo de desenvolvimento do Queens desde o início, foi além de muitos e lançou com confiança o "novo" em produção. Então, quão profunda era a toca do coelho?

(a seguir, a terminologia do OpenStack será amplamente usada; pressupõe-se que o leitor esteja pelo menos familiarizado com a arquitetura típica)

Recursos úteis

1. Para mim, pessoalmente, um bom bônus no novo lançamento foi a expansão da funcionalidade do utilitário nova-manage: agora você pode excluir hosts de algumas células (Cells v2) e transferi-los para outros! Pike teve que escrever consultas separadas ao banco de dados e agora está disponível "pronto para uso".
2. A criação de uma função personalizada (_member_ por padrão) para o Keystone é "cortada" no estágio de inicialização. O motivo disso foi a transição final para a API v3, que possui outras formas de mecanismos de autorização e autenticação, o que também aumenta a segurança da infraestrutura (afinal, havia também um ID fixo para a função de usuário ...) No entanto, isso não significa que a função de usuário não seja necessária - antecipadamente ou você precisará criá-lo mais tarde.
   

   Previsão: a partir desta versão, a Identity API v2 foi preterida; é provável que seu apoio cesse completamente em um ano (pessimista no lançamento de Stein).

3. Os agentes nêutrons l3 e dhcp tiveram a oportunidade de realizar failover automático - comutação automática (reorganização) de redes e roteadores de agentes desligados para agentes ativos. A funcionalidade de alta disponibilidade do DVR é ativada por padrão ( [DEFAULT]/router_distributed , [DEFAULT]/l3_ha ). DVR / SNAT é alocado em um espaço para nome separado. Ao criar um roteador, o snat é criado por padrão, obtendo outro endereço IP da sub-rede interna:
   
   Esse pacote permite alternar rapidamente do roteador atual para o roteador de backup do agente l3 em execução em outro nó no caso de uma falha do serviço SNAT.
4. Toda a funcionalidade do Neutron vpn-agent é transferida para o l3-agent; em sua configuração, você precisa fazer a única edição:
   
   

    [agent]/extensions = vpnaas 

   
   Finalmente, a presença de um agente VPN deixou de interferir na construção da lógica de implantação automática no caso de inclusão de uma função (anteriormente, os agentes VPN e L3 eram mutuamente exclusivos: se você colocar um pacote, o outro será excluído).
5. O Glance-Registry (proxy para interagir com o banco de dados na API v1) foi declarado um serviço desatualizado, agora você pode configurar e precisar apenas do serviço glance-api. Sem surpresas, mas elas serão discutidas um pouco mais tarde.
6. Mamma mia! O painel de calor é entregue em um pacote separado (painel de plug-in) para o Horizon. O plugin passou por muitas alterações, mas a funcionalidade mais inesperada foi ... arrastar e soltar objetos no processo de geração de modelos. É mais fácil ver uma vez:
   
   
   
7. Adicionado suporte para conexão múltipla de volume no Cinder - a capacidade de conectar um único disco a várias máquinas virtuais. Até agora, essa funcionalidade foi implementada apenas para um número limitado de drivers suportados pelo serviço: LVM, NetApp / SolidFire, Dell EMC ScaleIO e Oracle ZFSSA - na verdade, este é um grande passo em frente para todo o projeto (a implementação do mecanismo levou mais de dois anos ).
   

   Previsão: para Ceph RBD, o suporte ao multi-anexo do volume Cinder ainda não foi anunciado; provavelmente, não deve ser esperado antes de um ano (otimista - no lançamento de Stein).

Bugs irritantes

(Os seguintes erros foram descobertos ao implantar o OpenStack Queens na distribuição Ubuntu 16.04.4 LTS (Xenial Xerus); há uma chance de que eles não apareçam em outras distribuições Linux)

1. Na comunidade Linux, existe um "mantenedor" - um especialista que mantém / mantém / lidera um determinado componente de software (em um caso específico, um pacote binário). Portanto, os mantenedores do Ubuntu novamente (um bug existia na versão Pike) forneceram pacotes para o serviço regular de banco de dados de séries temporais - Gnocchi. Instalando-os em um ambiente Python 2.7 por meio de apt "breaks", alguns dos serviços relacionados executados no libapache2-mod-wsgi: Keystone, Cinder, Nova Placement, Horizon. O caso triste é quando você deseja usar um único método de entrega de pacotes ao sistema. No entanto, enquanto no Gnocchi eles tentaram pelo menos compilar pacotes, para o Octavia apenas o pip e o git ainda existem.
2. Não pretendo dizer, mas talvez os mesmos mantenedores tenham ajudado a criar pacotes de computação nova. Pelo menos, isso explicaria por que quando eles são instalados no sistema (assemblies do kernel 116, 119 e 124; versões do pacote de 17.0.1 a 17.0.4) o instalador "cai" com um erro:
   
   

    Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user 'nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet. 

   
   A questão é a seguinte: durante a instalação, é executado um script que deve criar o grupo de sistemas nova e o usuário do sistema nova. O script falha com o erro, a instalação falha e a solução alternativa é adicionada à automação: faça os gestos mencionados antes de instalar os pacotes. A propósito, esse bug ainda não está fechado.
   

   UPD: no processo de redação do artigo, o bug foi finalmente confirmado e estabeleceu a prioridade média. Na hora de resolver o problema (as dependências cíclicas dos pacotes Nova), o mantenedor propôs outra solução alternativa: primeiro instale o pacote nova-common, depois o nova-computate. Num futuro próximo, podemos esperar a versão dos pacotes 17.0.5, sem essa desvantagem.

3. Testando a operação do serviço Neutron FWaaS, descobriu-se que, quando um firewall é removido de um roteador distribuído, nada acontece ... absolutamente. O firewall muda do status "online" para o status "exclusão pendente" eterna, e você pode resolver o problema usando consultas ao banco de dados ou excluindo o roteador inteiro (esse bug existia na versão do Pike). O principal problema no momento é que a correção (que realmente resolve!) Foi proposta há alguns meses, mas ainda não chegou à última versão estável.
4. Já na fase de teste de carga da infraestrutura, verificou-se que o "EATING CPU AAAAAAA do agente de nêutrons abertos - no modo inativo, o agente aberto carregava um dos núcleos do processador a 100%:
   
   

    $ ps aux | grep 16233 neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 0 95725 epoll_wait 0.00 0.000000 0 15 read 0.00 0.000000 0 6 open 0.00 0.000000 0 6 close 0.00 0.000000 0 6 stat 0.00 0.000000 0 15 fstat 0.00 0.000000 0 20 sendto 0.00 0.000000 0 79 41 recvfrom 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 94 epoll_ctl ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 95968 41 total real 0m10.300s user 0m0.324s sys 0m2.576s 

   
   A solução para o problema foi encontrada pelos desenvolvedores do serviço o mais rápido possível; A correção é fornecida na versão do pacote Neutron 12.0.1-0ubuntu1.1.

Royal Fakap

No OpenStack Queens, os desenvolvedores introduziram um novo método para baixar imagens - download na web, que permite ao usuário final "carregar" uma imagem por referência. Era uma vez, quando o Image API v1 ainda não era preterido e não foi substituído pelo API v2, essa funcionalidade existia. Parece que o que poderia ter dado errado?


Na configuração do serviço glance-api, ambos os métodos de carregamento de imagem - diretamente e por referência - são ativados por padrão ( [DEFAULT]/enabled_import_methods ). Em busca do objetivo simples de testar a opção, desativo um dos métodos, sobrecarrego o serviço e corro!

 CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple ERROR glance Traceback (most recent call last): ERROR glance File "/usr/bin/glance-api", line 10, in <module> ERROR glance sys.exit(main()) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main ERROR glance fail(e) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1 ERROR glance ValueError: tuple.index(x): x not in tuple 

Tendo mexido no patch, sobrecarreguei novamente o serviço:

 glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "[" systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: glance-api.service: Unit entered failed state. systemd[1]: glance-api.service: Failed with result 'exit-code'. 

Sério, ou o quê ?! A opção na configuração adquiriu o seguinte formato inadequado:

 [DEFAULT]/enabled_import_methods = [glance-direct] 

Claro, um bug foi cuidadosamente aberto por mim. Os desenvolvedores na hora de resolver o problema até postaram um anúncio sobre esses problemas conhecidos, conhecidos por eles e enviaram uma confirmação para a ramificação principal do projeto. Dois meses após a descoberta do bug, a correção "saiu" para uma versão futura; os proprietários sortudos do Queens terão que esperar pelos pacotes do Glance versão 16.0.2.
Tudo está bem quando acaba bem.

"Não perca a cabeça, balance os músculos"

Durante o trabalho de automação de implantação (também envolvendo as etapas de configuração e teste funcional), o Queens mostrou-se forte, não sobrecarregado com novos recursos, sem uma “muleta” saindo de todos os lugares, estabelecendo um padrão alto para seu sucessor.

No entanto, apesar do Queens ser o décimo sétimo (!) Lançamento do OpenStack, a tendência geral foi mantida por muitos anos: “o imprevisto não é previsível por intuição imprevista ”. Esta citação da faixa do Projeto Atlantida, na minha opinião, da melhor maneira, descreve toda a gama de sensações recebidas ao interagir com o produto. Por um lado, a implantação de serviços regulares (Keystone, Glance, Swift, Cinder, Nova, Neutron, Horizon) com configurações básicas há muito foi depurada e não causará problemas, mesmo para um engenheiro iniciante. Por outro lado, quando se trata de introduzir serviços relativamente jovens, o "feriado" mencionado acima começa: resolva-o como você deseja na documentação escassa, prepare-se para passar dias olhando o código e sentado no popular rastreador de erros.

No entanto, todo esse sofrimento é apenas um efeito colateral da síndrome de Estocolmo. Mas, de fato, o exercício de pilha aberta agita o cérebro mais rápido do que qualquer jogo lógico, desenvolve habilidades úteis exponencialmente, mantém-se constantemente em boa forma e certamente não deixa você ficar entediado. O OpenStack definitivamente não era meu amor à primeira vista, reduzido ao calor branco e desmaio, mas definitivamente merece um pouco de amor agora. E se você está pronto para quase tocar por toque através da escuridão dos consoles, impulsionado pela necessidade de se perceber (e tornar o mundo de código aberto um pouco melhor), talvez seja esse o seu caminho.