Moin,
leider hat’s auch 3 Hosts von uns erwischt. Unglücklicherweise sind es genau unsere drei dienstältesten Systeme, die aktuell nicht erreichbar sind — und dadurch fallen uns gerade einige Abhängigkeiten aus den Anfangstagen zusätzlich vor die Füße. Sie werden notiert und, sobald die Server wieder erreichbar sind/laufen, angegangen.
Danke für die Info.
Ist der Strom wieder da? 
… und wie kann man Euch unterstützen ohne zu nerven?
Gruß
Matthias
Hallo! Du (Kai ‘wusel’ Siering) hast geschrieben:
leider hat’s auch 3 Hosts von uns erwischt. Unglücklicherweise sind es genau unsere drei dienstältesten Systeme, die aktuell nicht erreichbar sind — und dadurch fallen uns gerade einige Abhängigkeiten aus den Anfangstagen zusätzlich vor die Füße. Sie werden notiert und, sobald die Server wieder erreichbar sind/laufen, angegangen.
Das Monitoring sieht ja noch nicht wieder gut aus.
Ich hab gerade versucht mal Spasshalber rt.4830.org über
opennebula zu verschieben, aber …
Cord
Strom ist wohl schon länger wieder stabil da; ein paar unserer Hosts haben neu gebootet gegen 5 Uhr (Strom weg, Strom wieder da: Heißa, los geht’s), ein paar (besagte drei betroffene) leider nicht, und die, die rebooteten, waren nur bedingt lauffähig.
Details im Post-Mortem-Blogeintrag im Laufe der Woche; nur soviel vorweg: während Spiegel Online gegen 11 Uhr wieder up and running war, kämpfen wir noch immer mit dem Fallout.
Uns hat’s unseren zentralen »Router« zerlegt — was, um der Wahrheit die Ehre zu geben, ein ca. 2006 als abgeschrieben ausgemusterter und nicht mehr aus der Ferne wartbarer Server war, der seitdem ein »gewachsenes Setup« zusammengehalten hat. Die Schmerzen, die ein Verlust der Kiste mit sich brächte, waren antizipiert, wofür auch die vormalige Uptime von ca. 1200 Tagen(!) spricht. Sprich: hierfür sind nur wir, und insbesondere yours truly, verantwortlich. Ja, Strom sollte ein einem Datacenter nicht ausfallen, aber weder dafür noch für unser »spezielles« IPv4-Setup kann unser Hoster was. (Hoster in diesem Falle != RZ-Dienstleister.)
That said: ein Großteil der Routingfunktionalität zur Wiederherstellung des Status Quo ist in einer virtuellen Maschine (susan-vm) mittlerweile umgesetzt. Jetzt geht’s um das klein-klein und die Prüfung aller alleine ~30 per OpenNebula ausgerollten VMs …
rt meckerte vorhin (~17h) über »wäh, ich kann nicht zugreifen auf mein Medium«. LizardFS sagt, alles wäre schick, aber wo genau die RT-VM läuft, habe ich auch nicht im Kopf.
Status ist: »susan« ist wohl Toast. »willikins« konnte ich gegen Mittag nicht per iLO (Web als auch CLI) einschalten, die Kollegen im RZ sind aber wohl durch die Reihen gegangen und haben Knöpfe gedrückt — seit ca. 14:30 spielt willikins wieder mit, mittlerweile auch auf’s »neue Routing« angepaßt. Nachdem »susan« nun wohl Geschichte ist, mache ich den clean cut und konfiguriere alles, ausnahmslos, auf VLAN171 — mit einer Ausnahme: susan-vm ist, bis es routingtechnisch auch im DC umgestellt wurde, die neuen, »klarere susan«: 192.251.226.128/25 wird via Layline-Infra angenommen und in VLAN 171 ausgespielt. 193.26.120.0/24 nimmt sie im VLAN 171 mit der 217er IP an und spielt es im VLAN 171 aus.
FTR, der Stand von Samstag war dieser:
susan:~# ip -4 route show | egrep '^19[23]'
193.26.120.24 dev eth1 scope link
192.251.226.114 dev eth1 scope link src 192.251.226.113
193.26.120.26 dev eth1 scope link src 193.26.120.132
193.26.120.18 via 195.71.106.48 dev eth0 metric 1
193.26.120.20 dev eth1 scope link
193.26.120.23 dev eth1 scope link
193.26.120.14 dev eth1 scope link
192.251.226.107 dev eth1 scope link
192.168.5.33 via 193.26.120.227 dev vdsl-193 metric 2
192.251.226.69 via 192.251.226.78 dev carrot
192.168.44.10 dev ksbounce-gsm proto kernel scope link src 192.168.44.11
192.168.78.4 dev dc3-brln proto kernel scope link src 192.168.78.3
192.168.44.12 dev ksbounce proto kernel scope link src 192.168.44.13
192.168.78.5 dev dc3-gtso proto kernel scope link src 192.168.78.6
192.168.78.5 via 193.26.120.227 dev vdsl-193 metric 2
192.251.226.4 dev eth1 scope link src 192.251.226.113
192.0.2.8 dev luggage-tcp proto kernel scope link src 192.0.2.7 metric 3
192.0.2.14 dev luggage-udp proto kernel scope link src 192.0.2.13
192.251.226.13 dev eth1 scope link
192.251.226.254 via 195.71.106.48 dev eth0
192.251.226.254 via 195.71.106.48 dev eth0 metric 1
192.251.226.229 via 192.251.226.125 dev eth1
192.251.226.224 via 192.251.226.125 dev eth1
192.251.226.225 via 192.251.226.125 dev eth1
192.251.226.226 via 192.251.226.125 dev eth1
192.251.226.193 via 195.71.106.48 dev eth0 metric 2
192.251.226.192 via 195.71.106.48 dev eth0 metric 2
193.26.120.215 dev tun-d1-2 proto kernel scope link src 193.26.120.214
193.26.120.211 dev congstar-b proto kernel scope link src 193.26.120.210
193.26.120.209 dev tun-o2 proto kernel scope link src 193.26.120.208
193.26.120.207 dev tun-d2 proto kernel scope link src 193.26.120.206
192.251.226.165 dev eth1 scope link
193.26.120.205 dev tun-d1 proto kernel scope link src 193.26.120.204
193.26.120.202 dev ysabell-u scope link src 193.26.120.201
192.251.226.161 dev ffue-exit proto kernel scope link src 192.251.226.160
192.251.226.174 dev alice-b proto kernel scope link src 192.251.226.173
193.26.120.194 dev ysabell-tcp scope link src 193.26.120.193
192.251.226.171 dev ffgt-gw04 proto kernel scope link src 192.251.226.170
192.251.226.169 dev ffgt-gw01 proto kernel scope link src 192.251.226.168
192.168.5.245 via 193.26.120.227 dev vdsl-193 metric 2
193.26.120.238 dev hex proto kernel scope link src 193.26.120.239
193.26.120.238 dev hex scope link metric 2
193.26.120.236 dev mob-144 proto kernel scope link src 193.26.120.237
193.26.120.232 dev vitro proto kernel scope link src 193.26.120.231
193.26.120.227 dev vdsl-193 proto kernel scope link src 193.26.120.228
193.26.120.227 dev vdsl-193 scope link metric 2
193.26.120.226 dev camp proto kernel scope link src 193.26.120.225
192.251.226.137 dev eth1 scope link
193.26.120.218/31 dev gre-de1-us1 proto kernel scope link src 193.26.120.218
193.26.120.216/31 dev gre-de-at proto kernel scope link src 193.26.120.216
193.26.120.212/31 dev rpi-nl proto kernel scope link src 193.26.120.212
192.0.2.2/31 via 192.251.226.78 dev carrot
193.26.120.234/31 dev gre-de1-fr1 proto kernel scope link src 193.26.120.234
193.26.120.136/31 dev uplink-bgp3 proto kernel scope link src 193.26.120.136
192.251.226.164/30 dev eth1 proto kernel scope link src 192.251.226.166
192.251.226.236/30 dev eth0 proto kernel scope link src 192.251.226.237
192.251.226.168/30 via 192.251.226.12 dev eth0
192.251.226.240/29 dev eth0 proto kernel scope link src 192.251.226.241
192.251.226.224/29 via 192.251.226.125 dev eth1
192.251.226.200/29 via 217.188.63.193 dev eth1
192.251.226.160/29 dev eth0 scope link
192.251.226.112/28 dev eth1 proto kernel scope link src 192.251.226.113
192.251.226.64/28 dev carrot scope link src 192.251.226.65
193.26.120.80/28 via 193.26.120.238 dev hex metric 2
193.26.120.240/28 via 192.251.226.4 dev eth1
192.251.226.144/28 via 193.26.120.236 dev mob-144
192.251.226.128/28 via 192.251.226.12 dev eth0
192.251.226.32/27 via 193.26.120.227 dev vdsl-193
192.251.226.32/27 via 193.26.120.227 dev vdsl-193 metric 2
193.26.120.0/27 dev eth0 proto kernel scope link src 193.26.120.1
193.26.120.32/27 via 193.26.120.227 dev vdsl-193
193.26.120.32/27 via 193.26.120.227 dev vdsl-193 metric 2
193.26.120.96/27 via 193.26.120.211 dev congstar-b
193.26.120.128/26 dev eth1 proto kernel scope link src 193.26.120.132
192.251.226.0/25 dev eth1 scope link
192.0.2.0/25 dev eth1 proto kernel scope link src 192.0.2.126
192.0.2.128/25 dev eth0 proto kernel scope link src 192.0.2.254
192.168.5.0/24 via 193.26.120.227 dev vdsl-193 metric 2
192.168.177.0/24 via 193.26.120.227 dev vdsl-193 metric 2
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.254
192.0.2.0/24 via 193.26.120.227 dev vdsl-193 metric 2
192.168.0.0/22 via 193.26.120.227 dev vdsl-193 metric 2
Stand heute gibt es nur noch 192.251.226.0/25, 192.251.226.128/25 und 193.26.120.0/24, die letzten beiden geroutet, jetzt neu über »susan-vm«. Ziel sind zwei /24 im VLAN 171 …
Hallo! Du (Kai ‘wusel’ Siering) hast geschrieben:
rt meckerte vorhin (~17h) über »wäh, ich kann nicht zugreifen auf mein Medium«. LizardFS sagt, alles wäre schick, aber wo genau die RT-VM läuft, habe ich auch nicht im Kopf.
Status ist: »susan« ist wohl Toast. »willikins« konnte ich gegen Mittag nicht per iLO (Web als auch CLI) einschalten, die Kollegen im RZ sind aber wohl durch die Reihen gegangen und haben Knöpfe gedrückt — seit ca. 14:30 spielt willikins wieder mit, mittlerweile auch auf’s »neue Routing« angepaßt. Nachdem »susan« nun wohl Geschichte ist, mache ich den clean cut und konfiguriere alles, ausnahmslos, auf VLAN171 — mit einer Ausnahme: susan-vm ist, bis es routingtechnisch auch im DC umgestellt wurde, die neuen, »klarere susan«: 192.251.226.128/25 wird via Layline-Infra angenommen und in VLAN 171 ausgespielt. 193.26.120.0/24 nimmt sie im VLAN 171 mit der 217er IP an und spielt es im VLAN 171 aus.
Ich warne mal weil dns-gut und librarian scheinbar offline sind. Ich
gehe davon aus das beide essentiell für die Funktion diverser
Domains sind. Ich kenne die Timeoutzeiten jetzt nicht, aber …
Cord Beermann
librarian war zwischenzeitlich erreichbar, warum jetzt wieder nicht, muß ich gucken. qouth wurde komplett umgestellt auf ‘alles in VLAN 171’, damit wäre auch diese VM frei umherziehbar.
RT habe ich heute Nacht noch mir angesehen, das Image ließ sich problemlos vom LFS auf einen NFS-Share rsynchen; ein fsck auf die gemountete virtuelle Partition schmiß aber I/O-Fehler, wie in der VM?! Dito mit NFS: kein Problem. WTF?! BTW, es sollte dringend die lokale MariaDB mind. täglich weggesichert werden. (Bei den auf Galera liegenden DBs auch, wie ich nach gestern finde :-)) -> RT
quoth ist weitgehend wieder oben, der bind9 (librarian) aber wohl noch zickig.
Routing sollte auch weitgehend wieder tun, allerdings scheint web01 borked zu sein (Blog-Aufruf hängt) 
Und Routing für Müritz ist ebenfalls noch defekt