-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <--- vertraulich, nur für den Dienstgebrauch ---> Hallo liebe Kollegen, die letzten zwei Tage waren wohl für alle Beteiligten sehr nervenaufreibend. Ich gehe davon aus, dass mit dem heutigen Feierabend das Thema durch ist und die größten Probleme behoben sind. Was war passiert: Am Donnerstag früh ist der Uplink des HLKomm-Anschluß ausgefallen. Dieser befindet sich hier vor Ort und hat erstmal nichts mit dem Betrieb im Rechenzentrum (RZ) zu tun. Dennoch ist er essentiell, da er die gesicherte Verbindung (VPN) zum RZ für uns herstellt. Sprich ist diese Leitung gekappt, so können die meisten von euch nicht mehr ihrer Arbeit nachgehen so lange interne Ressourcen aus dem RZ abgefragt werden (Logs,SSH/DB-Zugriffe usw.). Wir Admins haben da so unsere Tricks um das dennoch zu bewerkstelligen, was aber für euch nicht praktikabel ist. Die Gegenstelle dieser Verbindung ist eine der größten und folgenreichsten Fehlerquellen in unserem RZ-Netzwerk! Um nun wieder eine Verbindung zwischen dem Büro und dem RZ herzustellen, habe ich gestern entschieden dies über den zweiten (funktionierenden) Uplink der Telekom umzusetzen. Dazu musste aber auch besagte Gegenstelle angepasst werden. Da diese auch für die Kommunikation nach außen (Kundensystem zu Internet) und für die Anbindung an Provider wie TT & Sabre (VPN-Verbindung) zuständig ist, war hier davon auszugehen, dass es nicht einfach wird. Letztlich waren die Kundensysteme zeitweise nicht in der Lage nach außen zu kommunizieren. Dafür trage ich die Verantwortung. Die Gesamtlage hat sich erst heute mit Abschluß der Netzwerkumbauten (Routing, Firewalling) normalisiert. Die Ausfälle betrafen die Verbindung bzgl. Anfragen an andere Provider (Webzugriffe), Datenübermittlung (FTP) und den Mailversand, der aber nachträglich funktionierte (vorausgesetzt der Kunde hat eines unserer Mailgateways) nachdem die Verbindungen wieder möglich waren. Auch die Kommunikation der Kundensysteme zum HBD-Import/Scan via RabbitMQ war gestört. Hier ist aufgefallen, dass das Setup offensichtlich nicht robust genug ist. Das gleich für den Mailversand (Mailgateways), die DNS-Auflösung und das Nagios-Monitoring. Was haben wir erreicht: Das besagte Verbindungsglied im RZ ist nun für die Kommunikation der Kundensysteme weitesgehend umgangen, Ausnahmen betreffen hier die Verbindungen (Uploads,Webzugriffe) bei denen der jeweilige Partner eine bestimmte IP-Adresse voraussetzt - nämlich die des besagten Verbindungsglieds. Diese lässt sich durch organisatorische Maßnahmen aber leicht beheben. Der Ausfall dieser einen Maschine hat nun nicht mehr die Tragweite, wie es noch vorgestern der Fall gewesen wäre. Einen Teil der Auswirkungen haben wir die letzten beiden Tage erlebt. Was bleibt ist bei dem Szenario der Verlust der Anbindung an TT & Sabre. Auch dies werden wir in den nächsten Wochen angehen und diese Verbindungen auf die redundant ausgelegte Firewall umziehen. Wir wissen nun, dass wir einige infrastrukturellen Änderungen im RZ-Netzwerk bewerkstelligen müssen. Stichwort: RabbitMQ/HBD-Scan, Mailversand, DNS-Auflösung, Nagios-Monitoring. Es gibt darüber hinaus sicherlich noch anderer Baustellen. Des weiteren ist unsere gesamte Kommunikation zum RZ um Äonen schneller, da nun der sehr langsame HLKomm-Anschluß umgangen wird. Was z.B. auch bedeutet, dass der Kunde beim Login im xAdmin nicht mehr so lange warten muss bis die Jira-Tasks angezeigt werden. Die Entwickler wird es ebenso freuen, denn sämtlichen DB-Verbindungen, Deployments usw. usf. profitieren massiv von der schnelleren Verbindung. Auch muss nicht mehr ewig gewartet werden bis irgendwas aus dem RZ hoch-/heruntergeladen wurde. Das ganze Thema um die verdrehten MTUs (Netzwerktechnik) und den Zugriff der Server aus dem RZ auf den Chef-Server (Zentrale Konfiguration) sind nun Geschichte. D.h. wir können den Ausbau einer automatisierten Konfiguration der Kundensystem massiv vorantreiben. PXE -> Chef -> Deployment -> Kunde hat optimal funktionierendes System. Fazit: Die Maschine im RZ (Verbindungsglied) seiner zerstörerischen Funktion bei einem Ausfall zu berauben war der Plan vom letztem Jahr vorausgegangen die redundante Firewall und die Switche zu beschaffen. Geplant war das ganze sanft über die Bühne zu bekommen ohne das unsere Kunden davon negativ betroffen sind. Der gefasste Entschluss dies zu Teilen umzusetzen da der Uplink zum RZ kaputt war, war sehr riskant und bedarf keiner weiteren Erklärung, da die Auswirkungen allen bekannt geworden sind. Dennoch möchte ich zuversichtlich aus dem ganzen Drama auf die Zukunft blicken. Wir sind dem Thema PCI-Zertifizierung & Hochverfügbarkeit wieder einen Schritt näher gekommen. lg, Tilo PS: Vielen Dank an alle fleißigen Tester, Problembeheber, Kommnikatoren und Salatschnippsler :-) - -- Mit freundlichen Grüßen Tilo Werner - - Systemadministration - _______________________________________________ TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig E-Mail: t.werner@traso.de Internet: https://www.traso.de _______________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIbBAEBAgAGBQJT7mu+AAoJEFfjOJdKpi1ElScP91rLoGleWMRvEaz6xrsh2gtL px9PvtN6H0IUx6TLdesiwXkxxQ4NmImD88rkfrvQurUPCM/9xw9DYOh6sti1xCuf o2hDuvuZpL31QWOm6FwqqkPz9a5TGebvIcFWLM5H+f8gHQOSf+lPNItbTtTPzmtR pcdQcgXeEUg3O56MO4YIR7MCB8vo2L2B5SvMXM06qT3df8dQbUvvHpj2jtFl7kEI J2uSb08GsrTCvQo8e/BYrUhZkPJAfN1EC7qabXAyoBuIhBDUcBDNgscQGQ4uzRk0 qOX0ujxlbBRuE7SRjOc84vTXvN1IJsMQQnHiJArYYHG5nrb7/72j/6bIguXD0FwO 6d6v/scBLIu35adCCygmE0zgyvBHILyOSB8Iu1+5hhwnmOl53bOYNjYv85tEqV/K sw+z8mnk8Jb0gTp3orXjO2lOQpUrQwouTNW6mXHdw0E7R9k4anRxVGdkNwHKtsz5 uGBBFtAVoQuFRcHYquW+CMqeZ2TuDnViuM6iDTFwpioFBX0Xp4tRmIVBjb7NcJf+ TwirfIRyWV46Gue0nrDKFCwO9euwd9/WzeHc6K6JMcoNQdtdjVY2Ig/X79cyt7TH sDWvqShNT9HTvD1c0f836Cp/2eYwbgc8vcsDJa8C4jfPQQ558KOZRr/7kvFHo5M6 ekv5cb5d86H4FPiqLHQ= =zkac -----END PGP SIGNATURE-----