Geschichten aus der Cryp^H^H^H^H^H^H^H Cloud¶

Hier finden Sie eine Auswahl von Geschichten von OpenStack-Cloud-Betreibern. Lies und lerne aus ihrer Weisheit.

Doppel-VLAN¶

Ich war vor Ort in Kelowna, British Columbia, Kanada, beim Aufbau einer neuen OpenStack-Cloud. Die Bereitstellung wurde vollständig automatisiert: Cobbler stellte das Betriebssystem auf dem blanken Metall bereit, bootstrapte es, und Puppet übernahm von dort aus. Ich hatte das Deployment-Szenario in der Praxis so oft ausgeführt und war davon ausgegangen, dass alles funktionierte.

An meinem letzten Tag in Kelowna war ich in einer Telefonkonferenz aus meinem Hotel. Im Hintergrund habe ich auf der neuen Cloud herumgealbert. Ich habe eine Instanz gestartet und mich angemeldet. Alles sah gut aus. Aus Langeweile lief ich den Befehl ps aux und plötzlich war die Instanz gesperrt.

Da ich dachte, es sei nur ein einmaliges Problem, beendete ich die Instanz und startete eine neue. Zu diesem Zeitpunkt endete die Telefonkonferenz und ich ging ins Rechenzentrum.

Im Rechenzentrum erledigte ich einige Aufgaben und erinnerte mich an das Lock-up. Ich habe mich in die neue Instanz eingeloggt und ps aux erneut ausgeführt. Es hat funktioniert. Puh. Ich beschloss, es noch einmal auszuführen. Es hat sich abgeschlossen.

Nachdem ich das Problem mehrmals reproduziert hatte, kam ich zu dem unglücklichen Schluss, dass diese Cloud tatsächlich ein Problem hatte. Schlimmer noch, meine Zeit war in Kelowna abgelaufen und ich musste zurück nach Calgary.

Wo fangen Sie überhaupt an, so etwas zu beheben? Eine Instanz, die einfach zufällig blockiert, wenn ein Befehl ausgeführt wird. Ist es das Abbild? Nein - es passiert auf allen Abbildern. Ist es der Compute-Knoten? Nope-all Knoten. Ist die Instanz gesperrt? Nein! Neue SSH-Verbindungen funktionieren einwandfrei!

Wir griffen nach Hilfe. Ein Netzwerkingenieur schlug vor, es sei ein MTU-Problem. Großartig! MTU! Etwas, um weiterzumachen! Was ist die MTU und warum sollte sie ein Problem verursachen?

MTU ist die maximale Übertragungseinheit. Es gibt die maximale Anzahl von Bytes an, die die Schnittstelle für jedes Paket akzeptiert. Wenn zwei Interfaces zwei verschiedene MTUs haben, können Bytes abgehackt werden und seltsame Dinge passieren - wie zufällige Session-Lockups.

Bemerkung

Nicht alle Pakete haben eine Größe von 1500. Die Ausführung des Befehls ls über SSH kann dazu führen, dass nur einzelne Pakete mit weniger als 1500 Bytes erstellt werden. Um jedoch einen Befehl mit starker Ausgabe auszuführen, wie z.B. ps aux, sind mehrere Pakete von 1500 Bytes erforderlich.

OK, woher kommt also die MTU-Problematik? Warum haben wir das bei keinem anderen Einsatz gesehen? Was ist in dieser Situation neu? Nun, neues Rechenzentrum, neuer Uplink, neue Switches, neues Switch-Modell, neue Server, erstes Mal mit diesem Server-Modell…. also war im Grunde alles neu. Wunderbar. Wir haben mit der Erhöhung der MTU an verschiedenen Stellen herumgespielt: die Switches, die NICs auf den Compute-Knoten, die virtuellen NICs in den Instanzen, wir haben sogar das Rechenzentrum die MTU für unsere Uplink-Schnittstelle anheben lassen. Einige Änderungen funktionierten, andere nicht. Diese Art der Fehlersuche fühlte sich jedoch nicht richtig an. Wir sollten in diesen Bereichen nicht die MTU wechseln müssen.

Als letztes Mittel setzten sich unser Netzwerkadministrator (Alvaro) und ich mit vier Terminalfenstern, einem Bleistift und einem Stück Papier hin. In einem Fenster liefen wir Ping. Im zweiten Fenster haben wir tcpdump auf dem Cloud-Controller ausgeführt. Im dritten Fall tcpdump auf dem Compute-Knoten. Und der vierte hatte tcpdump auf der Instanz. Im Hintergrund war diese Cloud ein Multi-Node, Non-Multi-Host-Setup.

Ein Cloud-Controller fungierte als Gateway zu allen Compute-Knoten. Für die Netzwerkkonfiguration wurde der VlanManager verwendet. Das bedeutet, dass der Cloud-Controller und alle Compute-Knoten für jedes OpenStack-Projekt ein anderes VLAN hatten. Wir haben die Option -s von ping verwendet, um die Paketgröße zu ändern. Wir beobachteten, wie manchmal Pakete vollständig zurückkehrten, manchmal schafften sie es nur heraus und nie wieder hinein, und manchmal hörten die Pakete an einem beliebigen Punkt auf. Wir haben tcpdump geändert, um den Hex-Dump des Pakets anzuzeigen. Wir haben zwischen jeder Kombination von außen, Controller, Compute und Instanz gepingt.

Schließlich bemerkte Alvaro etwas. Wenn ein Paket von außen auf den Cloud-Controller trifft, sollte es nicht mit einem VLAN konfiguriert werden. Wir haben dies als wahr bestätigt. Wenn das Paket vom Cloud-Controller zum Compute-Knoten ging, sollte es nur dann ein VLAN haben, wenn es für eine Instanz bestimmt war. Das war immer noch so. Wenn die Ping-Antwort von der Instanz gesendet wurde, sollte sie sich in einem VLAN befinden. Stimmt. Wenn es zurück zum Cloud-Controller und auf dem Weg ins Internet kam, sollte es kein VLAN mehr haben. Falsch. Uh oh oh. Es sah so aus, als ob der VLAN-Teil des Pakets nicht entfernt wurde.

Das ergab keinen Sinn.

Während ich diese Idee in unseren Köpfen herumwirbelte, gab ich zufällig Befehle auf dem Compute-Knoten ein:

$ ip a
…
10: vlan100@vlan20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br100 state UP
…

„Hey Alvaro, kannst du ein VLAN auf einem VLAN betreiben?“

„Wenn du das tätest, würdest du zusätzliche 4 Bytes zum Paket hinzufügen….“

Dann machte alles Sinn…

$ grep vlan_interface /etc/nova/nova.conf
vlan_interface=vlan20

In nova.conf, vlan_interface gibt an, an welche Schnittstelle OpenStack alle VLANs anschließen soll. Die richtige Einstellung hätte sein müssen:

vlan_interface=bond0

Da dies die gebundene NIC des Servers wäre.

vlan20 ist das VLAN, das uns das Rechenzentrum für den ausgehenden Internetzugang zur Verfügung gestellt hat. Es ist ein korrektes VLAN und wird auch an bond0 angeschlossen.

Versehentlich habe ich OpenStack konfiguriert, um alle Mandanten-VLANs an vlan20 statt an bond0 anzuschließen und so ein VLAN übereinander zu stapeln. Dadurch wurden jedem Paket zusätzliche 4 Bytes hinzugefügt und ein Paket von 1504 Bytes gesendet, was Probleme verursachen würde, wenn es an einer Schnittstelle ankam, die nur 1500 akzeptiert.

Sobald diese Einstellung behoben war, funktionierte alles.

„ Das Problem“¶

Ende August 2012 migrierte eine postsekundäre Schule in Alberta, Kanada, ihre Infrastruktur in eine OpenStack-Cloud. Wie der Zufall es wollte, verschwand innerhalb der ersten ein oder zwei Tage einer ihrer Server einfach aus dem Netzwerk. Blip. Weg.

Nach dem Neustart der Instanz war alles wieder einsatzbereit. Wir überprüften die Protokolle und sahen, dass irgendwann die Netzwerkkommunikation stoppte und dann alles untätig wurde. Wir haben das zu einem zufälligen Ereignis zusammengefasst.

Ein paar Nächte später geschah es wieder.

Wir haben beide Protokolle überprüft. Die eine Sache, die am meisten auffiel, war DHCP. Damals setzte OpenStack standardmäßig DHCP-Leases für eine Minute (jetzt sind es zwei Minuten). Das bedeutet, dass jede Instanz den Cloud Controller (DHCP-Server) kontaktiert, um seine feste IP zu erneuern. Aus irgendeinem Grund konnte diese Instanz ihre IP nicht verlängern. Wir haben die Logs der Instanz mit den Logs auf dem Cloud-Controller korreliert und ein Gespräch aufgebaut:

Die Instanz versucht, die IP zu erneuern.
Der Cloud-Controller empfängt den Verlängerungsantrag und sendet eine Antwort.
Die Instanz „ignoriert“ die Antwort und sendet die Verlängerungsanforderung erneut.
Die Cloud-Steuerung empfängt die zweite Anforderung und sendet eine neue Antwort.
Instance beginnt, eine Verlängerungsanfrage an 255.255.255.255 zu senden, da sie keine Rückmeldung vom Cloud-Controller erhalten hat.
Der Cloud-Controller empfängt die Anforderung 255.255.255.255 und sendet eine dritte Antwort.
Die Instanz gibt schließlich auf.

Mit diesen Informationen waren wir sicher, dass das Problem mit DHCP zu tun hatte. Wir dachten, dass die Instanz aus irgendeinem Grund keine neue IP-Adresse erhält und ohne IP-Adresse sich vom Netzwerk abschaltet.

Eine schnelle Google-Suche ergab dies: DHCP-Leasingfehler im VLAN-Modus, die unsere DHCP-Theorie weiter unterstützten.

Eine erste Idee war es, die Mietdauer einfach zu erhöhen. Wenn die Instanz nur einmal pro Woche erneuert würde, wären die Chancen, dass dieses Problem auftritt, enorm geringer als jede Minute. Das hat das Problem jedoch nicht gelöst. Es ging nur darum, das Problem zu vertuschen.

Wir beschlossen, tcpdump auf dieser Instanz laufen zu lassen und zu sehen, ob wir sie wieder in Aktion fangen können. Tatsächlich haben wir das getan.

Das tcpdump sah sehr, sehr seltsam aus. Kurz gesagt, es sah so aus, als ob die Netzwerkkommunikation gestoppt wurde, bevor die Instanz versuchte, ihre IP zu erneuern. Da es so viel DHCP-Chatter aus einer Minute Leasing gibt, ist es sehr schwierig, es zu bestätigen, aber selbst mit nur einer Millisekunden Differenz zwischen den Paketen, wenn ein Paket zuerst ankommt, kommt es zuerst an, und wenn dieses Paket Netzwerkprobleme meldet, dann muss es vor DHCP passiert sein.

Außerdem war diese fragliche Instanz jede Nacht für einen sehr, sehr großen Backup-Job verantwortlich. Während „Das Problem“ (wie wir es jetzt nannten) nicht genau zum Zeitpunkt des Backups passierte, war es nah genug (ein paar Stunden), dass wir es nicht ignorieren konnten.

Weitere Tage vergehen und wir sehen Das Problem immer öfter in Aktion. Wir stellen fest, dass dhclient nicht ausgeführt wird, nachdem das Problem aufgetreten ist. Jetzt denken wir wieder, dass es sich um ein DHCP-Problem handelt. Der Neustart von /etc/init.d/networking bringt alles wieder in Gang.

Hatten Sie jemals einen dieser Tage, an denen Sie plötzlich die Google-Ergebnisse erhalten, nach denen Sie gesucht haben? Nun, das ist es, was hier passiert ist. Ich suchte nach Informationen über dhclient und warum er stirbt, wenn er seinen Mietvertrag nicht verlängern kann, und plötzlich fand ich eine Reihe von OpenStack- und dnsmasq-Diskussionen, die mit dem Problem identisch waren, das wir sahen!

Problem mit Heavy Network IO und Dnsmasq.

Fälle, in denen die IP-Adresse während des Betriebs verloren geht, da kein DHCPOFFER.

Im Ernst, Google.

Dieser Fehlerbericht war der Schlüssel zu allem: KVM-Bilder verlieren die Verbindung zum überbrückten Netzwerk.

Es war lustig, den Bericht zu lesen. Es war voll von Leuten, die ein seltsames Netzwerkproblem hatten, es aber nicht ganz auf die gleiche Weise erklärten.

Es war also ein qemu/kvm Bug.

Gleichzeitig mit dem Auffinden des Fehlerberichts konnte ein Mitarbeiter Das Problem erfolgreich reproduzieren. Wie? Er benutzte iperf, um eine Tonne Bandbreite in einer Instanz auszuspucken. Innerhalb von 30 Minuten verschwand die Instanz einfach aus dem Netzwerk.

Bewaffnet mit einem gepatchten Qemu und einer Möglichkeit der Reproduktion, machten wir uns auf den Weg, um zu sehen, ob wir das Problem endlich gelöst haben. Nach 48 Stunden, in denen wir die Instanz mit Bandbreite gehämmert haben, waren wir zuversichtlich. Der Rest ist Geschichte. Sie können den Fehlerbericht nach „joe“ durchsuchen, um meine Kommentare und aktuellen Tests zu finden.

Verschwindende Abbilder¶

Ende 2012 implementierte Cybera (ein gemeinnütziger Verein mit dem Auftrag, die Entwicklung der Cyberinfrastruktur in Alberta, Kanada, zu überwachen) eine aktualisierte OpenStack-Cloud für ihr DAIR-Projekt. Ein paar Tage nach der Produktion schließt ein Compute-Knoten. Beim Neustart des Knotens überprüfte ich, welche Instanzen auf diesem Knoten gehostet wurden, damit ich sie im Namen des Kunden starten konnte. Glücklicherweise nur eine Instanz.

Der Befehl nova reboot funktionierte nicht, also benutzte ich virsh, aber er kam sofort mit einem Fehler zurück, der besagt, dass er die Backup-Disk nicht finden konnte. In diesem Fall ist die Backup-Disk das Glance-Abbild, das bei der ersten Verwendung des Abbildes nach /var/lib/nova/instances/_base kopiert wird. Warum konnte sie es nicht finden? Ich habe das Verzeichnis überprüft und bin sicher, dass es weg ist.

Ich habe die nova-Datenbank überprüft und den Eintrag der Instanz in der Tabelle nova.instances gesehen. Das Bild, das die Instanz verwendete, entsprach dem, was virsh berichtete, also keine Inkonsistenz dort.

Ich überprüfte Glance und bemerkte, dass dieses Abbild eine Schattenkopie war, die der Benutzer erstellt hatte. Zumindest das waren gute Nachrichten - dieser Benutzer wäre der einzige betroffene Benutzer gewesen.

Schließlich habe ich StackTach überprüft und die Ereignisse des Benutzers überprüft. Sie hatten mehrere Schattenkopien erstellt und gelöscht - höchstwahrscheinlich experimentierend. Obwohl die Zeitstempel nicht übereinstimmten, war meine Schlussfolgerung, dass sie ihre Instanz gestartet und dann die Schattenkopie gelöscht haben und er irgendwie aus /var/lib/nova/instances/_base entfernt wurde. Nichts davon machte Sinn, aber es war das Beste, was mir einfiel.

Es stellt sich heraus, dass der Grund, warum dieser Compute-Knoten gesperrt war, ein Hardwareproblem war. Wir haben es aus der DAIR-Cloud entfernt und Dell angerufen, um es warten zu lassen. Dell kam an und begann mit der Arbeit. Irgendwie oder anders (oder ein dicker Finger) wurde ein anderer Compute-Knoten gestoßen und neu gestartet. Großartig.

Als dieser Knoten vollständig gestartet wurde, durchlief ich das gleiche Szenario, um zu sehen, welche Instanzen ausgeführt wurden, damit ich sie wieder einschalten konnte. Es waren insgesamt vier. Drei wurden gebootet und einer gab einen Fehler. Es war derselbe Fehler wie zuvor: Die Backup-Disk konnte nicht gefunden werden. Im Ernst, was?

Auch hier stellt sich heraus, dass das Abbild eine Schattenkopie war. Die drei anderen Instanzen, die erfolgreich gestartet wurden, waren Standard-Cloud-Abilder. War es ein Problem mit Schattenkopien? Das ergab keinen Sinn.

Ein Hinweis zur Architektur von DAIR: /var/lib/nova/instances ist ein gemeinsames NFS-Mount. Das bedeutet, dass alle Compute-Knoten Zugriff darauf haben, was das Verzeichnis _base beinhaltet. Ein weiterer zentraler Bereich ist /var/log/log/rsyslog auf dem Cloud-Controller. Dieses Verzeichnis sammelt alle OpenStack-Protokolle von allen Compute-Knoten. Ich fragte mich, ob es irgendwelche Einträge für die Datei gibt, die virsh berichtet:

dair-ua-c03/nova.log:Dec 19 12:10:59 dair-ua-c03
2012-12-19 12:10:59 INFO nova.virt.libvirt.imagecache
[-] Removing base file:
/var/lib/nova/instances/_base/7b4783508212f5d242cbf9ff56fb8d33b4ce6166_10

Ah-hah! Also löschte OpenStack es. Aber warum?

In Essex wurde eine Funktion eingeführt, um regelmäßig zu überprüfen, ob es _base Dateien gibt, die nicht verwendet werden. Wenn ja, würde OpenStack Compute sie löschen. Diese Idee klingt unschuldig genug und hat einige gute Eigenschaften. Aber wie kam es dazu, dass dieses Feature aktiviert wurde? Es wurde in Essex standardmäßig deaktiviert. So wie es sein sollte. Es wurde beschlossen, in Folsom eingeschaltet zu werden. Ich kann das nicht genug betonen:

Aktionen, die Dinge löschen, sollten standardmäßig nicht aktiviert werden.

Festplattenspeicher ist heutzutage billig. Datenrettung ist es nicht.

Zweitens trug das gemeinsame Verzeichnis /var/lib/nova/instances von DAIR zu dem Problem bei. Da alle Compute-Knoten Zugriff auf dieses Verzeichnis haben, überprüfen alle Compute-Knoten regelmäßig das Verzeichnis _base. Wenn es nur eine Instanz gibt, die ein Abbild verwendet, und der Knoten, auf dem sich die Instanz befindet, für einige Minuten nicht aktiv ist, kann er das Abbild nicht als noch in Gebrauch markieren. Daher scheint das Abbild nicht verwendet zu werden und wird gelöscht. Wenn der Compute-Knoten wieder online ist, kann die auf diesem Knoten gehostete Instanz nicht gestartet werden.

The Valentine’s Day Compute Node Massacre¶

Obwohl der Titel dieser Geschichte viel dramatischer ist als das eigentliche Ereignis, denke oder hoffe ich nicht, dass ich die Gelegenheit haben werde, „Valentinstag-Massaker“ wieder in einem Titel zu verwenden.

An diesem vergangenen Valentinstag erhielt ich eine Warnung, dass ein Compute-Knoten im Sinne der Cloud nicht mehr verfügbar war,

$ openstack compute service list

zeigte diesen speziellen Knoten in einem heruntergefahrenen Zustand an.

Ich habe mich in den Cloud-Controller eingeloggt und konnte sowohl ping als auch SSH in den problematischen Compute-Knoten einbinden, was sehr seltsam erschien. Normalerweise, wenn ich diese Art von Warnung erhalte, hat sich der Compute-Knoten vollständig blockiert und wäre unzugänglich.

Nach ein paar Minuten der Fehlersuche sah ich die folgenden Details:

Ein Benutzer hat kürzlich versucht, eine CentOS-Instanz auf diesem Knoten zu starten
Dieser Benutzer war der einzige Benutzer auf dem Knoten (neuer Knoten).
Die Load schoss auf 8, kurz bevor ich den Alarm erhielt
Das gebundene 10gb Netzwerkgerät (bond0) befand sich in einem DOWN-Zustand
Das 1gb NIC war noch am Leben und aktiv

Ich betrachtete den Status der beiden NICs im gebundenen Paar und sah, dass keiner von beiden in der Lage war, mit dem Switch-Port zu kommunizieren. Als ich sah, wie jedes NIC in der Verbindung mit einem separaten Switch verbunden ist, dachte ich, dass die Chance, dass ein Switch-Port gleichzeitig an jedem Switch stirbt, ziemlich unwahrscheinlich war. Ich kam zu dem Schluss, dass das 10gb Dual-Port NIC gestorben war und ersetzt werden musste. Ich habe ein Ticket für die Hardware-Supportabteilung im Rechenzentrum erstellt, in dem der Knoten gehostet wurde. Ich hatte das Glück, dass dies ein neuer Knoten war und niemand sonst auf ihm gehostet wurde.

Eine Stunde später erhielt ich den gleichen Alarm, aber für einen anderen Compute-Knoten. Mist. OK, jetzt gibt es definitiv ein Problem. Genau wie der ursprüngliche Knoten konnte ich mich per SSH anmelden. Die bond0 NIC war DOWN, aber die 1gb NIC war aktiv.

Und das Beste: Der gleiche Benutzer hatte gerade versucht, eine CentOS-Instanz zu erstellen. Was?

Ich war an dieser Stelle völlig verwirrt, also schrieb ich unserem Netzwerkadministrator eine SMS, um zu sehen, ob er für Hilfe zur Verfügung stand. Er loggte sich bei beiden Switches ein und sah sofort das Problem: Die Switches erkannten Spanning-Tree-Pakete, die von den beiden Compute-Knoten kamen, und schlossen sofort die Ports, um Spanning-Tree-Schleifen zu verhindern:

Feb 15 01:40:18 SW-1 Stp: %SPANTREE-4-BLOCK_BPDUGUARD: Received BPDU packet on Port-Channel35 with BPDU guard enabled. Disabling interface. (source mac fa:16:3e:24:e7:22)
Feb 15 01:40:18 SW-1 Ebra: %ETH-4-ERRDISABLE: bpduguard error detected on Port-Channel35.
Feb 15 01:40:18 SW-1 Mlag: %MLAG-4-INTF_INACTIVE_LOCAL: Local interface Port-Channel35 is link down. MLAG 35 is inactive.
Feb 15 01:40:18 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-Channel35 (Server35), changed state to down
Feb 15 01:40:19 SW-1 Stp: %SPANTREE-6-INTERFACE_DEL: Interface Port-Channel35 has been removed from instance MST0
Feb 15 01:40:19 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet35 (Server35), changed state to down

Er aktivierte die Switch-Ports wieder und die beiden Compute-Knoten erwachten sofort zum Leben.

Leider hat diese Geschichte ein offenes Ende…. wir untersuchen immer noch, warum das CentOS-Abbild Spanning-Tree-Pakete verschickt hat. Darüber hinaus erforschen wir einen geeigneten Weg, wie wir das verhindern können. Es ist ein größeres Problem, als man meinen könnte. Während es für Switches äußerst wichtig ist, Spanning-Tree-Schleifen zu verhindern, ist es sehr problematisch, einen ganzen Compute-Knoten aus dem Netzwerk zu entfernen, wenn dies geschieht. Wenn ein Compute-Knoten 100 Instanzen hostet und eine von ihnen ein Spanning-Tree Paket sendet, hat diese Instanz die anderen 99 Instanzen effektiv DDOS’d .

Dies ist ein ständiges und aktuelles Thema in Netzwerkkreisen - insbesondere mit der Zunahme von Virtualisierung und virtuellen Switches.

Down the Rabbit Hole¶

Benutzer, die in der Lage sind, Konsolenprotokolle von laufenden Instanzen abzurufen, sind ein Segen für den Support - viele Male können sie herausfinden, was in ihrer Instanz vor sich geht und beheben, was vor sich geht, ohne Sie zu stören. Leider kann die manchmal übereifrige Protokollierung von Fehlern zu eigenen Problemen führen.

Ein Bericht kam rein: VMs starteten langsam oder gar nicht. Cue the standard checks - nichts auf den Nagios, aber es gab einen Anstieg im Netzwerk zum aktuellen Master unseres RabbitMQ-Clusters. Die Untersuchung begann, aber bald leckten die anderen Teile des Warteschlangenclusters wie ein Sieb. Dann kam der Alarm - der Master Rabbit Server ging aus und die Verbindungen zum Slave fielen aus.

Zu dieser Zeit wurden unsere Kontrolldienste von einem anderen Team gehostet, und wir hatten nicht viele Debugging-Informationen, um festzustellen, was mit dem Master vor sich ging, und wir konnten ihn nicht neu starten. Dieses Team bemerkte, dass es ohne Warnung fehlgeschlagen war, konnte es aber neu starten. Nach einer Stunde war das Cluster wieder in den Normalzustand zurückgekehrt und wir fuhren für den Tag nach Hause.

Die Fortsetzung der Diagnose am nächsten Morgen wurde durch einen weiteren identischen Fehler ausgelöst. Wir haben schnell die Nachrichtenwarteschlange wieder in Betrieb genommen und versucht herauszufinden, warum Rabbit unter so viel Netzwerkverkehr litt. Die Aktivierung der Debug-Protokollierung auf nova-api brachte schnell Verständnis. Ein tail -f /var/log/nova/nova/nova-api.log scrollte schneller als wir es je zuvor gesehen hatten. STRG+C daraufhin und wir konnten den Inhalt eines Systemprotokolls, das Fehler aufwies, immer wieder deutlich sehen - ein Systemprotokoll aus einer der Instanzen unserer Benutzer.

Nachdem wir die Instanz-ID gefunden hatten, gingen wir zu /var/lib/nova/instances, um die console.log zu finden:

adm@cc12:/var/lib/nova/instances/instance-00000e05# wc -l console.log
92890453 console.log
adm@cc12:/var/lib/nova/instances/instance-00000e05# ls -sh console.log
5.5G console.log

Tatsächlich hatte der Benutzer die Konsolenprotokollseite auf dem Dashboard regelmäßig aktualisiert und die 5G-Datei durchquerte den Rabbit-Cluster, um zum Dashboard zu gelangen.

Wir riefen sie an und baten sie, für eine Weile anzuhalten, und sie waren froh, die schrecklich kaputte VM aufzugeben. Danach begannen wir mit der Überwachung der Größe der Konsolenprotokolle.

Bis heute hat die Frage keine dauerhafte Lösung, aber wir freuen uns auf die Diskussion beim nächsten Szmmit.

Havana Haunted by the Dead¶

Felix Lee vom Academia Sinica Grid Computing Centre in Taiwan hat diese Geschichte geschrieben.

Ich habe gerade OpenStack von Grizzly auf Havana 2013.2-2 mit dem RDO-Repository aktualisiert und alles lief ziemlich gut, außer der EC2-API.

Ich bemerkte, dass die API unter einer hohen Last leidet und langsam auf bestimmte EC2-Anfragen wie „RunInstances“ reagiert.

Ausgabe von /var/log/nova/nova/nova-api.log auf Havana:

2014-01-10 09:11:45.072 129745 INFO nova.ec2.wsgi.server
[req-84d16d16-3808-426b-b7af-3b90a11b83b0
0c6e7dba03c24c6a9bce299747499e8a 7052bd6714e7460caeb16242e68124f9]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&Action=RunInstances&ClientToken=[something]&ImageId=ami-00000001&InstanceInitiatedShutdownBehavior=terminate...
HTTP/1.1" status: 200 len: 1109 time: 138.5970151

Diese Anfrage dauerte über zwei Minuten, wurde aber schnell bei einer anderen koexistierenden Grizzly-Bereitstellung mit der gleichen Hardware- und Systemkonfiguration ausgeführt.

Ausgabe von /var/log/nova/nova/nova-api.log auf Grizzly:

2014-01-08 11:15:15.704 INFO nova.ec2.wsgi.server
[req-ccac9790-3357-4aa8-84bd-cdaab1aa394e
ebbd729575cb404081a45c9ada0849b7 8175953c209044358ab5e0ec19d52c37]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&Action=RunInstances&ClientToken=[something]&ImageId=ami-00000007&InstanceInitiatedShutdownBehavior=terminate...
HTTP/1.1" status: 200 len: 931 time: 3.9426181

Während der Überwachung der Systemressourcen bemerkte ich einen signifikanten Anstieg des Speicherverbrauchs, während die EC2-API diese Anfrage verarbeitete. Ich dachte, es handhabt den Speicher nicht richtig - möglicherweise wird der Speicher nicht freigegeben. Wenn die API mehrere dieser Anfragen erhielt, wuchs der Speicherverbrauch schnell, bis dem System der Arbeitsspeicher ausging und Swap zu verwenden begann. Jeder Knoten verfügt über 48 GB RAM und der „nova-api“-Prozess würde ihn innerhalb von Minuten vollständig verbrauchen. Dann würde das gesamte System unbrauchbar langsam werden, bis ich den nova-api-Dienst neu gestartet habe.

So fragte ich mich, was sich an der EC2-API auf Havanna geändert hat, was dies bewirken könnte. War es ein Fehler oder ein normales Verhalten, das ich jetzt umgehen muss?

Nachdem ich in den nova (OpenStack Compute) Code gegraben hatte, bemerkte ich zwei Bereiche in api/ec2/cloud.py, die sich auf mein System auswirken könnten:

instances = self.compute_api.get_all(context,
                                     search_opts=search_opts,
                                     sort_dir='asc')

sys_metas = self.compute_api.get_all_system_metadata(
    context, search_filts=[{'key': ['EC2_client_token']},
                           {'value': [client_token]}])

Da meine Datenbank viele Datensätze enthielt - über 1 Million Metadatensätze und über 300.000 Instanzensätze in „gelöschten“ oder „fehlerhaften“ Zuständen - dauerte jede Suche sehr lange. Ich entschied mich, die Datenbank zu bereinigen, indem ich zuerst eine Kopie zur Sicherung archivierte und dann einige Löschungen mit dem MySQL-Client durchführte. Beispielsweise habe ich den folgenden SQL-Befehl ausgeführt, um Zeilen von Instanzen zu entfernen, die über ein Jahr lang gelöscht wurden:

mysql> delete from nova.instances where deleted=1 and terminated_at < (NOW() - INTERVAL 1 YEAR);

Die Leistung wurde nach dem Löschen der alten Datensätze stark verbessert, und meine neue Bereitstellung verhält sich weiterhin gut.

Geschichten aus der Cryp^H^H^H^H^H^H^H Cloud