Comportamento estranho observado no servidor Ubuntu MAAS Juju

2

Desculpe pela parede do texto. Eu observei um comportamento bem estranho em Juju e nosso Ubuntu MAAS OpenStack nas últimas semanas, aparentemente totalmente inesperado (eu estava fora do escritório por uma semana):

  • relatório de keystone errno 111 (HTTPConnectionPool Máximo de tentativas excedidas)
  • relatórios de keystone Falha na autorização: não é possível estabelecer conexão com link )
  • nova reporting errno 111 (ERRO: HTTPConnectionPool (host = '10 .10.5.5 ', porta = 5000): Max tentativas excedidas com url: /v2.0/tokens (Causado por: [Errno 111] Conexão recusada) )
  • Horizonte lançando um ConnectionError 111
  • da mesma forma com quase todo o resto dos serviços

As instâncias atualmente atualizadas ainda estão ativas, ainda SSH / VNC / RDPable e ainda em rede, devo adicionar.

Depois de ler o máximo possível sobre o erro, parece ser um problema com o Keystone e o banco de dados MySQL ao qual ele se conecta. Eu prontamente tentei me conectar manualmente ao banco de dados diretamente, e fiz isso com sucesso e, pelo menos à primeira vista, parece não haver corrupção de dados.

E fica ainda mais intrigante (e irritante). A desclassificação de juju charms ou a ativação do log resultaram em correções parciais e aleatórias da situação.

Por exemplo:

  • A ativação do registro no keystone resultou no funcionamento do keystone, mas nada mais.
  • Ativar o registro no relatório resultou no trabalho da nova em algum grau.
  • A Horizon continuou a não funcionar, mas a atualização da atualização fez com que algumas coisas funcionassem por um tempo.

Ativar / desativar o registro em log, salvar e confirmar alterações parece resultar em um comportamento imprevisível da rede OpenStack em geral, assim como na atualização e downgrade de juju charms.

Francamente, praticamente qualquer alteração que eu faça, salve & amp; commit em qualquer um dos juju charms, por menor que seja (p.ex. configurando debugging para Enabled), resulta em coisas diferentes funcionando e diferentes não funcionam, aparentemente de forma aleatória.

Os arquivos de log do OpenStack não são de muita ajuda, pois exibem os mesmos erros que os mencionados anteriormente + cargas de informações sobre qual parte do script em Python em questão falhou.

Alguém mais viu / experimentou este comportamento extremamente estranho antes? Alguma sugestão de como começar a investigar isso?

    
por gchl 10.02.2015 / 12:36

0 respostas