Openstack Problemas de estabilidade de nêutrons

Question

Eu tenho uma configuração Openstack bastante simples para um PoC. 2 nós, ambos rodando o Nova, e tudo mais no nó 1. Ele está rodando o CentOS 6 e foi configurado usando o RDO. É importante que eu esteja usando o Neutron para a rede, com as redes de inquilino GRE configuradas a partir dos documentos RDO para uma rede existente .

Periodicamente (todos os dias, eu acho) perco toda a comunicação com o Openvswitch (e, portanto, minhas instâncias). Eu sei disso OVS, porque eu posso SSH no nó 2, em seguida, conecte-se ao nó 1 através de sua rede privada. A coisa mais reveladora que vejo nos logs é esta:

unix:/var/run/openvswitch/db.sock: database connection failed (Protocol error)

Além disso, o OVS está usando quantidades enormes de CPU (800% nas minhas caixas de 16 núcleos), e quando tento e faço um desligamento limpo, isso simplesmente nunca acontece porque ele não pode matar o servidor ovsdb.

Eu fiz algumas pesquisas e encontrei algumas sugestões antigas baseadas em versões mais antigas do Openstack, nas quais as pessoas tinham incompatibilidades na versão OVS / kernel. Como eu estou executando as versões do RDO, eu acho que posso descartar isso (a menos que a Red Hat tenha feito uma enorme confusão).

Alguém viu isso? tem alguma sugestão?

PS: Não me diga para recompilar Openvswitch, por várias razões que não estão acontecendo no futuro imediato.

    

Answer 1

Qual versão do OpenStack, qual versão do repositório RDO você está usando? Estou apenas adivinhando com tão pouco detalhe, mas parece que você indica algum tipo de problema com o OpenvSwitch e seu kernel, um processo OVS descontrolado. Provavelmente seria relacionado ao banco de dados ou ao agente de mensagens.

Verifique seus logs do qpid: / var / log / messages em busca de algo que mostre um motivo para a desconexão no momento da perda de comunicação da sua instância. Isso pode revelar o motivo pelo qual pode haver desconexões de mensagens e se elas são causadas por falha na conexão de mensagens (causa externa / terciária); ou o contrário, causado por desconexão de OVS (provável problema de criação de kernel / OVS).

Como o RDO é "... testado em um RHEL 6.4", eu usaria o mínimo do CentOS 6.4, em vez de 6, conforme você informa. Melhor ainda, use 6.5, pois há vários componentes incluídos no kernel, em vez de serem corrigidos conforme necessário com o RDO.

Solução de problemas adicional em seu nome é difícil sem registros e detalhes de sua configuração, mas depois de ter avaliado isso, basta dizer que há desafios conhecidos de configuração do Neutron a serem superados com as configurações de GRE e MTU.

Em qualquer caso, para uma compilação bem-sucedida do OpenStack (não importa o quão básico, é complicado), você precisa começar com uma compilação de SO, kernel e OVS com suporte e atualizada. Como você pode ter certeza de que você pode ignorar a "incompatibilidade de versão OVS / kernel", quais versões você está usando?

Eu sugiro que você configure com o mais recente CentOS 6.5 e RDO, depois re-postar se o problema persistir (com detalhes atualizados, arquivos de log, etc), adicionalmente no fórum RDO: link assim você terá os detalhes específicos da distro que você pode precisar.

EDIT: Verifique o dhcp.ini e a configuração do dnsmask por meio desses artigos para configurações de MTU. Aparentemente, 1454 deve ser o mais adequado para instâncias de convidados ao executar o GRE: link link

Não se esqueça que ainda pode haver problemas com o MTU e o GRE, dependendo das suas versões do kernel e do OVS. Por isso, informe quais versões você possui e atualize sua postagem, para ajudar com outras pessoas com problemas semelhantes. nós mostram resultados para:

uname -a

rpm -qpi | grep openvswitch

Veja também seus fluxos OVS GRE e execute alguns tcpdumps no namespace qrouter relevante quando você estiver fazendo sua grande transferência de 20G, este guia do RDO ajudará, dê uma olhada na grande depuração de GRE de Joe Talerico na explicação de dois nós aos 60 minutos em diante: link

E, finalmente, você também precisa verificar se não está sendo afetado pela configuração Generic Receive Offload, conforme a postagem 24: link