[ English | Indonesia | Deutsch | 日本語 ]
Bestimmung, welche Komponente beschädigt ist¶
Die Sammlung der verschiedenen Komponenten von OpenStack interagiert stark miteinander. Das Hochladen eines Abbildes erfordert beispielsweise die Interaktion von nova-api, glance-api, glance-registry, keystone und möglicherweise swift-proxy. Daher ist es manchmal schwierig, genau festzustellen, wo die Probleme liegen. Dabei zu helfen, ist der Zweck dieses Abschnitts.
Nachlaufprotokolle¶
Der erste Ort, an dem Sie suchen müssen, ist die Protokolldatei, die sich auf den Befehl bezieht, den Sie ausführen möchten. Wenn beispielsweise die openstack server list fehlschlägt, versuchen Sie, eine nova-Protokolldatei zu beschneiden und den Befehl erneut auszuführen:
Terminal 1:
# tail -f /var/log/nova/nova-api.log
Terminal 2:
# openstack server list
Suchen Sie nach Fehlern oder Spuren in der Protokolldatei. Weitere Informationen finden Sie unter Protokollierung und Überwachung.
Wenn der Fehler darauf hinweist, dass das Problem mit einer anderen Komponente zusammenhängt, wechseln Sie zum Tailing der Protokolldatei dieser Komponente. Wenn nova beispielsweise nicht auf glance zugreifen kann, schauen Sie sich das Protokoll glance-api an:
Terminal 1:
# tail -f /var/log/glance/api.log
Terminal 2:
# openstack server list
Waschen, spülen und wiederholen, bis Sie die Kernursache des Problems gefunden haben.
Dämonen auf dem CLI ausführen¶
Leider ist der Fehler manchmal nicht aus den Protokolldateien ersichtlich. In diesem Fall wechseln Sie die Taktik und verwenden Sie einen anderen Befehl; vielleicht führen Sie den Dienst direkt auf der Befehlszeile aus. Wenn sich beispielsweise der Dienst glance-api weigert, zu starten und am Laufen zu bleiben, versuchen Sie, den Daemon über die Befehlszeile zu starten:
# sudo -u glance -H glance-api
Dies kann den Fehler und die Ursache des Problems ausgeben.
Bemerkung
Das -H Flag wird benötigt, wenn die Daemons mit sudo ausgeführt werden, da einige Daemons Dateien relativ zum Heimatverzeichnis des Benutzers schreiben, und dieses Schreiben kann fehlschlagen, wenn -H weggelassen wird.
Tipp
Beispiel für Komplexität
Eines Morgens konnte ein Compute-Knoten keine Instanzen ausführen. Die Protokolldateien waren etwas vage und behaupteten, dass eine bestimmte Instanz nicht gestartet werden konnte. Dies endete damit, dass es sich um einen roten Hering handelte, weil die Instanz einfach die erste Instanz in alphabetischer Reihenfolge war, also war es die erste Instanz, die Nova-Compute berühren würde.
Weitere Fehlerbehebungen zeigten, dass libvirt überhaupt nicht lief. Das machte mehr Sinn. Wenn libvirt nicht ausgeführt wurde, konnte keine Instanz über KVM virtualisiert werden. Beim Versuch, libvirt zu starten, würde es lautlos sofort sterben. Die libvirt Protokolle erklärten nicht, warum.
Als nächstes wurde der Daemon libvirtd auf der Kommandozeile ausgeführt. Schließlich eine hilfreiche Fehlermeldung: Es konnte keine Verbindung zum D-Bus hergestellt werden. So lächerlich es auch klingen mag, libvirt und damit nova-compute, verlässt sich auf d-bus und ist irgendwie d-bus abgestürzt. Durch den einfachen Start des D-Bus wurde die gesamte Kette wieder auf Kurs gebracht, und schon bald war alles wieder einsatzbereit.
