jtb.blog

Derzeit wird im öffentlichen Bereich viel saniert - Konjunkturpaket sei dank
Unter anderem wird hier der Serverraum des Fachbereichs einmal komplett verbessert. Statt herkömmlicher Klimaanlagen soll in Zukunft bei kalten Temperaturen mit Außenluft gekühlt werden. Dann gibt es noch Kleinigkeiten wie Brandschutz, vergrößerter Raum, Kabelführung über Trassen usw

Mit dem Blogeintrag werde ich das Projekt und die Probleme mit einigen Bildern erläutern. Die ganzen Bilder vom D10-Umbau finden sich in der Gallery der Fachschaft.

Da Bauarbeiten wie bekannt ein wenig staubig werden können, wurde also der Serverraum temporär geräumt (ein Hoch auf fahrbare Serverschränke ).
Zwischendrin stand dann nur noch ein angeblich gut eingepackter Netzwerkschrank in dem Raum:


Und es wurde staubig:



Nach einigem Ärger und etlichen Säuberungsversuchen mussten wir nun wieder in den Raum zurück - ein Serverraum für einen Fachbereich kann man halt nur mal in den Semesterferien umziehen.
Hier sieht man schön wie der Raum geputzt wurde und wie groß er nun wirkt.


Allerdings waren nicht wie nach Plan die Bauarbeiten in dem neuen altem Serverraum abgeschlossen. Neben dem Ärger mit dem zeitlichen Ablauf des Projekts kamen nun Bauarbeiten in einem produktiven Serverraum. Trotz Warnungen und Absprachen wurde weiterhin im Raum ohne oder mit wenig Staubschutz gearbeitet. Kurz vor Weihnachten ist das ganze dann eskaliert. Da wir im Nachbarraum mittlerweile unser Büro haben, bekommen wir es sofort mit wenn zum Beispiel eine Bohrmaschine im Serverraum benutzt wird. Kurz in den Serverraum reingeschaut steht dort ein Bauarbeiter mit der Bohrmaschine neben ihm, der gerade schnell versucht seine Spuren zu verwischen. Drauf angesprochen warum er keinen Staubsauger benutzt, hat er nur lamentiert und meinte es wäre ja nicht so wild...

Jetzt hat der Serverraum ein neues Schloss und wahrscheinlich müssen alle Server nun einmal gereinigt werden. Ich bin mal gespannt wer die Kosten dafür tragen muss.

Hier ein paar Bilder zur Verdeutlichung (der Raum war ja vorher komplett sauber):







Auch wenn ich in die Einteilung im IT-Grundschutz Katalog von "Staub, Verschmutzung" als "Höhere Gewalt" nicht teile, zeigt sich doch, dass man beim Betrieb eines Serverraums nicht nur die Server als Hard- und Software im Blick haben muss sondern auch das Umfeld. Mehr als Warnen und Absprachen treffen kann man als einfacher Angestellter aber auch nicht. So bleibt mir nur übrig zu hoffen, dass keine Festplatte oder gar ein Server ausfällt beziehungsweise stirbt.

Merke: auch heutzutage sollte man nicht nur den freien Speicherplatz einer Partition monitoren sondern auch die Anzahl freier Inodes..

Während auf dem einen Server mit über 700 GiB belegter Speicher "gerade mal" 7,6 Millionen Inodes in Verwendung sind, gingen auf einem anderen Server mit 100 GiB Partitionsgröße gerade die 6,5 Millionen Inodes aus.
Mir ist das in den letzten Jahren nicht mehr aufgetreten, so dass ich erstmal zweimal schauen musste warum keine Dateiuploads mehr funktionierten


Ab demnächst darf Nagios als Bigbrother nun auch die Inode-Anzahl überwachen...

In den letzten Tagen habe ich prototypisch eine neue Backbone-Struktur für den Fachbereich Informatik aufgebaut. Während früher pro Gebäude ein Backbone-Switch zuständig war und somit einen großen Single Point of Failure bot, soll in Zukunft ein redundantes System auch beim Ausfall eines Backbone-Switches den Betrieb am Laufen halten.

Während wir im Edge-Bereich allein durch die schiere Anzahl von benötigten Ports bzw Switches nur Linksys einsetzen, baut die neue Backbone auf "echten" Cisco Switches auf.
Jedes Labor und jeder Serverschrank wird dann später mit zwei 2 Gbit-Portchannel angebunden, so dass sowohl Redundanz als auch Durchsatz für zukünftige Anwendungen (ich sag nur Image-Verteilung) gegeben ist. Gleichzeitig sorgt RSTP bzw MSTP dafür, dass es zu keiner Schleife im Netz kommt.

Vereinfacht dargestellt:


Direkt nachdem der Prototype aufgebaut war, kamen aber die ersten Probleme:

%SW_MATM-4-MACFLAP_NOTIF: Host 001e.e500.ABCD in vlan 1234 is flapping between port PoX and port PoY

Der betroffene Host war die Managementschnittstelle des Linksys SRW2048 im passenden Management-VLAN. Dadurch konnte man den Switch nicht mehr erreichen... Alle anderen Hosts, die am Switch angeschlossen waren, funktionierenden allerdings weiterhin wunderbar.

In den da drauf folgenden Tagen nahm ich den Prototypen auseinander, baute von Port-Channel auf normale einfache Verbindung runter, bemühte Wireshark etc.
Gleichzeitig trat ich mit dem Linksys-Support in Kontakt und hoffte auf eine Lösung. Dieser erzählte mir dann erstmal, dass sie keine Catalyst zum Testen zur Verfügung haben - nur Linksys-Produkte...
Nach gut einem Moment wurde es mir zuviel mit dem Support und ich baute den gesamten Prototypen nochmal neu auf und bin kurz danach über die Ursache gestossen, die auch schon vorher per Wireshark-Trace zu sehen war: der Linksys schickt über ein vom Spanning-Tree blockiertes Interface ARP-Requests für seinen Standardgateway! Mit der Aussage festgenagelt, hat der Support dann endlich ein Dokument gefunden, dass dieses Problem beschreibt und mit einem Firmware-Update zu beheben ist.
Diese Firmware stand zwar schon vorher auf der Webseite zur Verfügung, aber kein Wort von dem Fehler. Obwohl dieser in der internen Datenbank aufgezeichnet war!

Mit einem Firmware-Upgrade läuft das Bäumchen jetzt korrekt und sobald unser Team Verstärkung durch mehr Personal bekommt, geht es ans Ausrollen