Em nosso ambiente de vários nós, o problema acabou sendo a fragmentação de pacotes. A solução é aumentar mtu para 1700 em nics de gerenciamento de nós de computação e de nêutrons, por exemplo, ifconfig ethxxx mtu 1700
Ter uma configuração MAAS-JUJU-Openstack com vários nós, ou seja, nova-cloud-controller, nova-compute e gateway quantum / neutron estão em hosts separados. Nesta configuração, o MAAS e o openstack compartilham 10.0.0.0/24 como sua rede de gerenciamento, enquanto o Quantum charm é conectado via eth0 à rede pública 10.0.10.0. Eu sou capaz de gerar instâncias e atribuir endereços IP flutuantes para eles. Eu também posso ping de e para a rede pública. Além disso, as duas instâncias de cirros, que estão na mesma sub-rede, podem ssh entre si. No entanto, não sou capaz de enviar ssh para instâncias por meio do namespace do roteador, ou seja, ip netns exec qr-xxxx ssh -i <full path to key> cirros@privateipaddr ou de fora. Eu geramos pares de chaves através do painel e da nova, com resultados semelhantes. Também tentei chmod 0600 key , ssh-add key sem sucesso. Um exemplo de saída é mostrado aqui link ,
que eventualmente expira. Conectando via vnc a imagem de cirros mostra, sob / var / log mensagens, o seguinte:
Jun20 14:29:21 cir3 authpriv.info dropbear[364]: Child connection from GatewayPrivateIp:32818
Jun20 14:29:21 cir3 authpriv.info dropbear[364]: Exit before auth: Timeout before auth
Logs similares são observados, quando ssh-ing da rede pública. No caso de acesso de rede pública, o wireshark mostra repetidas retransmissões de ssh ACK da fonte para o endereço público da VM, com chamadas ARP perguntando quem é o proprietário ou o endereço IP da VM e, finalmente, VM enviando [FIN, ACK] e fechando a conexão.
Eu configurei o servidor de meta-dados e segui o segundo método, conforme mencionado em Instâncias de nuvem no OpenStack não podem importar chaves SSH públicas , e estou vendo o seguinte durante a inicialização, link . (Não tenho certeza se eles são significativos: falha ao obter http: // 169.254.169.254 / 2009-04-04 / user-data
aviso: nenhum metadado ec2 para dados do usuário)
Para isolar o teste, criei um novo grupo de segurança que permite todos os intervalos tcp nas direções de entrada e saída.
Parece-me que isso não é um problema de firewall ou política, como a conexão com a porta 22 é possível, estou querendo saber se meta-dados errados estão sendo gerados durante a inicialização.
Todas e quaisquer sugestões são apreciadas.
Felicidades,
Em nosso ambiente de vários nós, o problema acabou sendo a fragmentação de pacotes. A solução é aumentar mtu para 1700 em nics de gerenciamento de nós de computação e de nêutrons, por exemplo, ifconfig ethxxx mtu 1700
Na minha instância de openstack de 3 nós (ML2 - OpenVSwitch - túnel GRE) eu tive que configurar o MTU para 1400. O MTU padrão era 1500. Experimente vários tamanhos de MTU.
Eu tive um problema semelhante com os metadados, minha solução foi criar um arquivo chamado dnsmasq-neutron.conf com o conteúdo:
dhcp-option-force=26,1400
e aponte para dentro do /etc/neutron/dhcp_agent.ini usando
dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf
Verifique também o auth_region = regionOne dentro do /etc/neutron/metadata_agent.ini , na minha configuração está com r e na configuração padrão de metadados é com R .
Problema : nós de VM, não podem ssh para nós físicos e os nós físicos não podem ssh para nós de VM, mas o ping funciona entre todos. VMs em Physical podem ssh com sucesso um para o outro.
Solução :
Altere o valor da MTU da NIC da VM de 1500 para 1420 .
Agora os nós da VM e os nós físicos podem ssh uns aos outros.