Ping mais SSH impossible à OpenStack VM Instance
Avoir une configuration multi-nœuds MAAS-JUJU-Openstack, c'est-à-dire, nova-cloud-controller, nova-compute et la passerelle quantum/neutron se trouvent sur des hôtes distincts. Dans cette configuration, MAAS et openstack partagent le réseau de gestion 10.0.0.0/24, tandis que Quantum Charm est connecté via eth0 au réseau public 10.0.10.0. Je suis capable de générer des instances et de leur attribuer des adresses IP flottantes. Je peux aussi faire un ping vers et depuis le réseau public. De plus, les 2 instances de cirros, qui sont sur le même sous-réseau, peuvent se connecter. Cependant, je ne suis pas en mesure de ssh aux instances par l’intermédiaire de l’espace de noms du routeur, c’est-à-dire ip netns exec qr-xxxx ssh -i <full path to key> cirros@privateipaddr, ou de l’extérieur. J'ai généré des paires de clés via le tableau de bord et nova, avec des résultats similaires. Aussi essayé chmod 0600 key, ssh-add key en vain. Un exemple de sortie est présenté ici http://Pastebin.ubuntu.com/7676660/ , qui expire éventuellement. Si vous vous connectez via vnc à cirros, l’image montre, sous/var/log, ce qui suit:
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
Des journaux similaires sont observés lorsque ssh-ing est issu d'un réseau public. Dans le cas d’un accès au réseau public, Wirehark affiche la retransmission répétée de ssh ACK de la source à l’adresse publique de la machine virtuelle, les appels ARP demandant à qui appartient la source ou l’adresse IP de la machine virtuelle, et enfin, VM envoi de [FIN, ACK ] et fermer la connexion.
J'ai configuré le serveur de méta-données et suivi la deuxième méthode, comme indiqué dans la section Les instances de cloud dans OpenStack ne peuvent pas importer de clé publique SSH , et je vois les informations suivantes lors du démarrage, http : //Pastebin.ubuntu.com/7676789/ . (Vous ne savez pas si elles sont significatives: échec d'obtention de http: // 169.254.169.254/2009-04-04/avertissement concernant les données utilisateur: aucune métadonnée ec2 pour les données utilisateur) Pour isoler les tests, j'ai créé un nouveau groupe de sécurité qui autorise toutes les plages de TCP dans les directions d'entrée et de sortie. Il me semble que ce n'est pas un problème de pare-feu ou de politique publique, car la connexion au port 22 est possible. Je me demande si des métadonnées incorrectes sont générées lors du démarrage. Toutes les suggestions sont appréciées. À votre santé,
Dans notre environnement multi-nœuds, le problème était la fragmentation des paquets. La solution consiste à augmenter le nombre de MTU à 1700 sur la gestion des noeuds de calcul et à neutrons, par exemple, ifconfig ethxxx mtu 1700
Dans mon instance openstack à 3 nœuds (ML2 - OpenVSwitch - tunnel GRE), je devais définir le MTU sur 1400. Le MTU par défaut était de 1500. Testez différentes tailles de MTU.
Problème: VM noeuds, ne peut pas passer en SSH vers des noeuds physiques et les noeuds physiques ne peuvent pas ssh en VM noeuds, mais le ping fonctionne entre tous. Les machines virtuelles sur physique peuvent ssh les unes avec les autres.
Solution:
Modifiez la valeur de la MTU VM NIC de 1500 à 1420.
Maintenant, les nœuds VM et les nœuds physiques peuvent se connecter mutuellement.
J'ai eu un problème similaire avec les métadonnées, ma solution a été de créer un fichier nommé dnsmasq-neutron.conf avec le contenu:
dhcp-option-force=26,1400
et pointez-le dans le /etc/neutron/dhcp_agent.ini en utilisant
dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf
Vérifiez également le auth_region = regionOne à l'intérieur du /etc/neutron/metadata_agent.ini, dans ma configuration, il s'agit de r et, dans la configuration par défaut des métadonnées, de R.