• Da wir in Zukunft einen eigenen kleinen Client mit grafischer Oberfläche in Betrieb nehmen wollen, muss der neue Switch die entsprechende Grafik-Leistung auch bieten. Mit 2048x1536 Pixel sind wir das auf der sicheren Seite. Derzeit werden die Server noch über die Konsole via SSH angesprochen.
• Besonders wichtig für uns: auch während des Bootens eines Servers, wird dessen Bildschirminhalt angezeigt, das ist bei dem CS1758 natürlich genauso gegeben wie beim alten CS14.
• Sehr aufwendig war die neue Verkabelung der Server: Beim alten KVM liefen die Kabel alle am Schreibtisch zusammen, nun führen sie nach ganz oben ihn den Schrank.
  Und: die Systemkabel sind nun mehrere Meter lang, wir benötigen also die alten VGA-, USB- und PS/2-Verlängerungen nicht mehr. Doch die müssen natürlich erstmal alle aus dem Schrank raus... Gender-Changer adé! :-)
• Der Einbau des Switches hat über drei Stunden gedauert, da zunächst erst alle alten Kabel aus dem Schrank raus und die neuen Systemkabel in den Schrank hineinmussten. Also ein erheblicher Auswand und reichlich Fummelarbeit, es hat sich aber auf jeden Fall gelohnt!
• Da hat wer mitgedacht: der Switch verfügt auf der Rückseite über eine Befestigungsmöglichkeit für Kabelbinder (siehe Bild). Man kann also sowohl das Stromkabel, wie auch die USB-Kabel mit einem Kabelbinder am Switch befestigen. Vorbildlich!
• Neu für uns: der KVM-Switch bringt sein eigenes Menü mit, d.h. eine Tastenkombination auf der Tastatur gedrückt (2x "Rollen") und es erscheint ein Menü auf dem Bildschirm, mit dem man einen anderen Rechner auswählen kann. Über das Menü kann den Switch auch konfigurieren. Beim alten KVM funktionierte die Standard-Tastenkombination nicht zuverlässig, so dass wir immer die Taste am Switch nehmen mussten, um zwischen den Servern zu wechseln. Und mit der Taste konnte man nicht zwischen den Servern springen, sondern die Server nur nach der Reihe durchgehen. Nun können wir problemlos von Server 1 zu Server 4 springen, ohne erst auf Server 2 & 3 gehen zu müssen. So muss das sein! :-)
• Sehr hilfreich: der Switch erkennt über USB, ob neue Server angeschlossen wurden. Das wird sowohl im Menü als auch an der Vorderseite des Switches angezeigt. Sowohl Tastatur als auch Maus funktionieren nach wenigen Sekunden. Selbst ein Aus- und Umstöpseln macht der Switch problemlos mit. Beim alten PS/2-Switch musste man manchmal den Server neu Booten, ehe Switch und Server die neue PS/2-Verbindung akzeptierten. Nun gehts hotplug :-)
• Und auch die maximale Länge der USB-Kabel von 5m macht der Aten KVM anstandslos mit, unser Händler hatte da Bedenken geäussert und wollte uns die 5m-Kabel zunächst garnicht verkaufen.
• Einige kleine Schönheitsfehler des KVM-Switches:
  • Unser alter HP-Server (aus 1998) bootet leider nicht richtig mit angeschlossenem KVM-Switch. Der Bootvorgang bleibt irgendwo nach dem BIOS hängen. Da die Tage des alten HP-Servers sowieso gezählt sind, ist dies nicht wirklich problematisch. Und notfalls stöpselt man halt kurz eine Tastatur an ;-)
  • Die blaue Power-LED (am Gehäuse rechts), die anzeigt, dass der KVM mit Strom versorgt wird, leuchtet extrem hell. Und zwar so hell, dass es blendet. Das nervt tierisch, inbesondere beim Verkabeln und Einbauen. Die LED ist sogar so hell, dass sie das obere Viertel des Schrankes im Dunkeln beleuchtet. Hier hätte es auch eine LED mit geringerer Lichtstärke getan. *Kopfschütteln*

Details zum neuen KVM-Switch Aten CS1758 auf den Bauseiten und den Technikseiten.

• Da die Server ausschliesslich über die Kommandozeile oder via SSH gesteuert werden, reicht die Grafikleistung des Switches vollkommen aus.
• Besonders wichtig für uns: auch während des Bootens eines Servers, wird dessen Bildschirminhalt angezeigt.
• Problematisch beim Einbau des KVM-Switches waren lediglich die verschiedenen Steckverbindungen. So waren wir gezwungen, Gender Changer zu verwenden, um den KVM-Switch anschliessen zu können. Hier lohnt es sich, vorher genau hinzusehen, welche Anschlüsse und Kabel ein KVM-Switch mitbringt.
• Der Einbau des Switches hat über eine Stunde gedauert, da ein Server zunächst die neue (englische) Tastatur nicht akzeptieren wollte. Es brauchte mehrere Versuche, die Tastaturbelegung auf englisch umzustellen, bis die Tastatur richtig angesteuert wurde. Dies war aber ein Problem auf Server-Seite, kann dem KVM-Switch also nicht angelastet werden.
• Der Einbau des KVM-Switch hat die Arbeit mit den drei Servern im Server-Raum erheblich vereinfacht. Es ist nun kein Umstecken mehr nötig. Ein Knopfdruck am KVM-Switch und man kann den nächsten Server bedienen. Die Umschaltung kann auch mittels einer Tastenkombination (Alt + Ctrl + Shift und A, B, D oder E + Enter) erfolgen.
• Einige kleine Schönheitsfehler des KVM-Switches:
  • die Beschriftungen der vier Anschlüsse für die Server besteht aus einer hyper-modernen Schrift mit kleiner Schriftgröße. Sie ist so schlecht zu lesen, dass wir mehrmals Anschlüsse verwechselt haben.
  • Unser alter HP-Server (aus 1998) bootet leider nicht richtig mit angeschlossenem KVM-Switch. Der Bootvorgang bleibt irgendwo nach dem BIOS hängen. Da die Tage des alten HP-Servers sowieso gezählt sind, ist dies nicht wirklich problematisch. Und notfalls stöpselt man halt kurz eine Tastatur an ;-)
  • Mit Hilfe einer Tastenkombination an der Tastatur kann man zwischen den einzelnen Servern umschalten. Erst schaltet man ihn mit einer Tastenkombination in eine Art "Auswahl-Modus" (Alt + Ctrl + Shift) und dann wählt man mit einem weiteren Tastendruck (A, B, D oder E + Enter) den Server aus. Wir hatten jedoch das Gefühl, als sei der KVM-Switch manchmal etwas begriffsstutzig, weil er den Rechnerwechsel erst nach mehrmaligem Drücken der Tastenkombinationen ausführte. Leider gibt der Switch selbst keine Rückmeldung, ob er im o.g. "Auswahl-Modus" ist oder nicht. Hier wäre ein OSD (On Screen Display) hilfreich.
  • was lernen wir: für uns lohnt sich derzeit kein KVM-Switch über 100,-EUR, wir müssen also mit den Einschränkungen leben...

Details zum alten KVM-Switch auf den Bauseiten und den Technikseiten.

Die Installation hat uns einige Nerven gekostet:

• So enthielt z.B. die Doku der IBM-SCSI-Karte keine Informationen über die eigentliche Karten-Technik (Chipsatz, Hersteller etc.). Zum Glück stand Adaptec auf der Karte und die Chips waren auch beschriftet. Dank Google fanden wir auch den entsprechenden Adaptec-Treiber, der die Karte unterstützte. Hier war die IBM-Doku wenig auskunftfreudig.
• Relativ unkompliziert verlief der Einbau und die Vergabe der SCSI-IDs. Da die IDs von 0-7 des IBM-Server bereits belegt waren, arbeiten Streamer und SCSI-Karte nun mit IDs ab 10 aufwärts. Die SCSI-ID des Streamers lässt sich problemlos an der Rückseite über Schalter einstellen.
• Wir haben derzeit (April 2008) ein wöchentliches Backup-Aufkommen von etwa 80GB. Dies beinhaltet ein Fullbackup zu Wochenanfang und sechs tägliche inkrementelle Backups.
  Derzeit werden nur der zentrale Wohnheim-Server mit den Nutzerdaten sowie der Vorstands-/Admin-Server automatisch gesichert. Die automatischen Backups des Web-Servers und des Routers ist in Vorbereitung, deren Daten werden derzeit noch manuell gesichert.
• Gesichert werden die Daten auf Band mit eine Durchschnittsgeschwindigkeit von 20MByte/s, was unsere Server deutlich zum Schwitzen bringt :-)

Unsere Erfahrungen mit der MessPC "Ethernetbox 1" von BetterNetworks.

Weitere Informationen zur Ethernetbox auf unserer Technik-Seite für Peripherie und auf den Bauseiten.

• Überraschend für uns waren die Werte der Luftfeuchte im Serverraum. Wir hatten vermutet, die Luft hätte einer Feuchte von mind. 60%, doch es stellte sich heraus, dass es nicht einmal 40% waren. Für einen Serverraum ist das eigentlich zu wenig (üblich sind zw. 40-60%, ideal 50%).
• Ebenfalls überraschend für uns waren die Klimaänderungen durch Menschen im Serverraum. 2 Personen über 2h im Serverraum erhöhten die Luftfeuchte um mehr als 5%, die Temperatur stieg um 1-2°C. Nach dem Verlassen des Raumes, sank die Temperatur in wenigen Stunden auf den Normalwert von etwa 25°C.
• Im Vergleich zur Temperatur brauchte die Luftfeuchte jedoch fast 2 Tage, um wieder auf 37% zurückzufallen. Grund ist sicherlich der fehlende Luftaustausch.
• Ein weitere überraschender Effekt: wir konnten Tag und Nacht kaum unterscheiden. Wir hatten vermutet, dass die Sonne den Serverraum am Tag aufheizen würde und er sich dann in der Nacht wieder abkühlen würde. Wir bemerkten jedoch keine größeren Schwankungen zwischen den Tag und Nacht, lediglich ein minimaler Temperaturanstieg in den Nachkommastellen. Der Grund wird vermutlich der Kellerraum sein, dessen Klima nur sehr langsam auf äußere Wettereinflüsse reagiert. Ausserdem fanden die ersten Messungen im April 2008 statt, wo sich Tages- und Nachttemperatur noch nicht so stark unterscheiden wie in den Sommermonaten.

Weitere Informationen zur Ethernetbox auf unserer Technik-Seite für Peripherie und auf den Bauseiten 2008 und Bauseiten 2009.

• Neben den Sensoren, die reguläre Messwerte ermitteln, bietet BetterNetworks für die Ethernetbox auch Sensoren an, die lediglich ein Ereignis anzeigen, wie z.B. das Vorhandensein von Spannung, Wasser oder Rauch. Wir setzen z.B. Wassersensoren ein, um Rohrbrüche oder undichte Ventile frühzeitig aufspüren zu können.
• Der Wassersensor wird mit Hilfe eines Messadapters an die Ethernetbox angeschlossen. Der eigentliche Sensorkopf verfügt über eine Bohrung, mit der man ihn problemlos in Bodenhöhe an der Wand oder der Fussleiste befestigen kann. Vorbildlich!

Weitere Informationen zur Ethernetbox auf unserer Technik-Seite für Peripherie und auf den Bauseiten 2008 und Bauseiten 2009.

Seit April 2009 betreiben wir das serielle externe Analog-Modem Longshine LCS-8560A für den Versand von SMS bei kritischen Ausfällen.

Wir entschieden uns für dieses Modem aus den folgenden Gründen:

• es ist eines der wenigen seriellen Modems auf dem Markt ist, das für deutlich unter 100€ zu haben ist
• Da wir regelmäßig Probleme mit USB haben, griffen wir auf ein serielles Modem zurück.
• bei einem analogen internen PCI-Modem kann niemand vorhersagen, ob das Modem auch unter Linux korrekt funktionieren wird. Und die Suche nach einem Modem mit einem Chip, der von Linux / Ubuntu problemlos unterstützt wird, war uns viel zu aufwendig.

Da war die Wahl eines externen seriellen Modems die einfachste und vmtl. auch presigünstigste Lösung.

Leider gab es gleich bei der Installation das erste Problem:

Longshine hatte an einer aussagkräftigen Beschriftung der Anschlüsse auf der Rückseite gespart. So konnten wir Phone- und Line-Buchse nicht unterscheiden und mussten erstmal ausprobieren, auf welcher Buchse das Modem nun "telefonierte".

Siehe auch unsere Technik-Seite zur Peripherie und die entsprechende Bauseite.