ServerDepp
29.03.12, 22:40
Nicht für die neueren Modelle. Für Dauerläufer gibt es die schon noch ...
Routing-Problem gestern Nacht
PhilipM
28.03.12, 22:12
Zitat von uisge
uisge
28.03.12, 21:08
Zitat von oles@ovh.net
OVH könnte aber gerne zusätzlich einen Link einstellen, auf dem ich meine (eventuell existierenden) Ansprüche für einen gemeinwohlen Zweck irgendwo in der Welt zu Lasten OVHs spenden könnte.
oles@ovh.net
28.03.12, 19:50
Guten Tag,
wir hatten gestern Nacht ein Routing-Problem in Folge eines Software-Bugs, von dem
2 Haupt-Router in Roubaix betroffen waren. Diese Cisco ASR 9010 Router stellen die
Abnahme der Bandbreite der Datacenter in Roubaix (RBX1 RBX2 RBX3 RBX4 RBX5) und die
Verbindung Richtung Paris, Brüssel, Amsterdam, London und Frankfurt sicher. Sie
bilden also das Herz des Routings in Roubaix.
Dieser Bug ist bekannt und steht in Zusammenhang mit den neuen Karten, die wir Ende
Januar in Betrieb genommen haben (24x10G pro Slot). Aus zufälligen Gründen fängt
die Karte an, ECC RAM Fehler festzustellen, und routet keine Pakete mehr. Vor allem
aber meldet sich die Karte dann nicht als "ausgefallen" und bleibt im Router, als
ob alles in Ordnung wäre. Die anderen Router senden also weiter Pakete an sie, aber
auf der anderen Seite hört niemand zu. Alles fällt in ein schwarzes Loch und das
Netzwerk funktioniert nicht mehr richtig. Das ist der schlimmste Fall: ein nicht
klar definierter Fehler.
Letzte Nacht hatten 3 24x10G Karten auf 2 Routern fast gleichzeitig diesen Bug. Dies
hat das Netzwerk in 3 Teile aufgesplittet: USA/London/Amsterdam/Warschau, Roubaix
und Paris, Frankfurt, Madrid, Mailand, und die Pakete wurden in Roubaix "angesaugt".
Normalerweise wäre der Traffic automatisch umgeroutet worden, aber in diesem Fall
wurde er in Roubaix angesaugt und blockiert.
Dadurch konnten wir unser Netzwerk nicht verwenden, um dieses Netzwerkproblem zu
beheben und die Logs aller Router abzurufen, um die Ursache des Problems
festzustellen. Wir haben es dann auf die altmodische Art gemacht, mit Notfall-
Verbindungen von Aussen, um sich mit jedem Router zu verbinden und zu überprüfen,
ob der jeweilige Router die Ursache des Problems ist. Diese Operationen haben Zeit
benötigt, da ausserdem zwei Router ausgefallen waren und es ein Wenig gedauert hat,
bis wir verstanden haben, dass die Störung nicht nur den einen Router rbx-g2-a9
ausgelöst wurde, sondern auch durch rbx-g1-a9. Als wir dann die drei betroffenen
Karten neu gestartet hatten lief innerhalb von 5 Minuten alles wieder.
Vor etwa 3 Wochen hatten wir bereits ein Ticket bei Cisco bezüglich dieses ECC RAM
Problems geöffnet. Cisco hat an dem Problem gearbeitet und konnte uns... heute
Morgen einen Patch für die Router liefern, um dieses Problem zu beheben. Wir werden
diesen heute Nacht einspielen, dabei sind keine Unterbrechungen vorgesehen.
Wir prüfen auch, wie wir die Verwaltung unserer Router verbessern können, wenn das
ganze Backbone aus Gründen, die normalerweise niemals auftreten, down sein sollte.
Wir können das Problem in einem solchen Fall schon beheben, aber das ist langsam.
Sehr langsam.
Auf jeden Fall hat die Störung länger als die bei 99,9% "erlaubten" 43 Minuten
Downtime pro Monat gedauert, nämlich 1 Stunde und 22 Minuten. Es werden also
Rückerstattungen für die Überschreitung der erlaubten Zeit fällig. Beispiel: für die
dedizierten OVH Server sind dies 5% pro Stunde Nichtverfügbarkeit. Wir werden eine
URL einrichten, damit Sie die SLA Rückerstattung selbst anstossen können und uns das
Dokument zur Erstattung des 5% Zeitraums für Ihre Dienstleistung zuzusenden. Dieser
Link wird in der Störungsmeldung http://travaux.ovh.com/?do=details&id=6533 bzw.
http://status.ovh.net/?do=details&id=2571 gepostet.
Es ist nie angenehm, diese Art von E-Mail zu schreiben, aber wenn etwas nicht
richtig gelaufen ist, dann muss man auch dazu stehen und sich entschuldigen.
Mit freundlichen Grüssen
Octave
wir hatten gestern Nacht ein Routing-Problem in Folge eines Software-Bugs, von dem
2 Haupt-Router in Roubaix betroffen waren. Diese Cisco ASR 9010 Router stellen die
Abnahme der Bandbreite der Datacenter in Roubaix (RBX1 RBX2 RBX3 RBX4 RBX5) und die
Verbindung Richtung Paris, Brüssel, Amsterdam, London und Frankfurt sicher. Sie
bilden also das Herz des Routings in Roubaix.
Dieser Bug ist bekannt und steht in Zusammenhang mit den neuen Karten, die wir Ende
Januar in Betrieb genommen haben (24x10G pro Slot). Aus zufälligen Gründen fängt
die Karte an, ECC RAM Fehler festzustellen, und routet keine Pakete mehr. Vor allem
aber meldet sich die Karte dann nicht als "ausgefallen" und bleibt im Router, als
ob alles in Ordnung wäre. Die anderen Router senden also weiter Pakete an sie, aber
auf der anderen Seite hört niemand zu. Alles fällt in ein schwarzes Loch und das
Netzwerk funktioniert nicht mehr richtig. Das ist der schlimmste Fall: ein nicht
klar definierter Fehler.
Letzte Nacht hatten 3 24x10G Karten auf 2 Routern fast gleichzeitig diesen Bug. Dies
hat das Netzwerk in 3 Teile aufgesplittet: USA/London/Amsterdam/Warschau, Roubaix
und Paris, Frankfurt, Madrid, Mailand, und die Pakete wurden in Roubaix "angesaugt".
Normalerweise wäre der Traffic automatisch umgeroutet worden, aber in diesem Fall
wurde er in Roubaix angesaugt und blockiert.
Dadurch konnten wir unser Netzwerk nicht verwenden, um dieses Netzwerkproblem zu
beheben und die Logs aller Router abzurufen, um die Ursache des Problems
festzustellen. Wir haben es dann auf die altmodische Art gemacht, mit Notfall-
Verbindungen von Aussen, um sich mit jedem Router zu verbinden und zu überprüfen,
ob der jeweilige Router die Ursache des Problems ist. Diese Operationen haben Zeit
benötigt, da ausserdem zwei Router ausgefallen waren und es ein Wenig gedauert hat,
bis wir verstanden haben, dass die Störung nicht nur den einen Router rbx-g2-a9
ausgelöst wurde, sondern auch durch rbx-g1-a9. Als wir dann die drei betroffenen
Karten neu gestartet hatten lief innerhalb von 5 Minuten alles wieder.
Vor etwa 3 Wochen hatten wir bereits ein Ticket bei Cisco bezüglich dieses ECC RAM
Problems geöffnet. Cisco hat an dem Problem gearbeitet und konnte uns... heute
Morgen einen Patch für die Router liefern, um dieses Problem zu beheben. Wir werden
diesen heute Nacht einspielen, dabei sind keine Unterbrechungen vorgesehen.
Wir prüfen auch, wie wir die Verwaltung unserer Router verbessern können, wenn das
ganze Backbone aus Gründen, die normalerweise niemals auftreten, down sein sollte.
Wir können das Problem in einem solchen Fall schon beheben, aber das ist langsam.
Sehr langsam.
Auf jeden Fall hat die Störung länger als die bei 99,9% "erlaubten" 43 Minuten
Downtime pro Monat gedauert, nämlich 1 Stunde und 22 Minuten. Es werden also
Rückerstattungen für die Überschreitung der erlaubten Zeit fällig. Beispiel: für die
dedizierten OVH Server sind dies 5% pro Stunde Nichtverfügbarkeit. Wir werden eine
URL einrichten, damit Sie die SLA Rückerstattung selbst anstossen können und uns das
Dokument zur Erstattung des 5% Zeitraums für Ihre Dienstleistung zuzusenden. Dieser
Link wird in der Störungsmeldung http://travaux.ovh.com/?do=details&id=6533 bzw.
http://status.ovh.net/?do=details&id=2571 gepostet.
Es ist nie angenehm, diese Art von E-Mail zu schreiben, aber wenn etwas nicht
richtig gelaufen ist, dann muss man auch dazu stehen und sich entschuldigen.
Mit freundlichen Grüssen
Octave