|
|
|
Neues aus der RBG
Aktuelle Meldungen aus der RBG. Außerdem gibt jemand jede
Woche eine blog-ähnliche Zusammenfassung über diejenigen
Ereignisse, die außerhalb des täglichen 10-stündigen
Tagesgeschäfts erwähnenswert sind ;-)
| Vorbereitungen für die Modernisierung der IT-Infrastruktur laufen an |
19. April 2012 |
![]() |
![]() |
Fer Forschungsbau Intelligente Interaktive Systeme wird in diesem Jahr nicht nur Platz für neue
Büros und Labore schaffen, sondern auch die neue Heimat für den Großteil der IT-Infrastruktur von
CIT-EC, TechFak und CoR-Lab werden.
Dazu entstehen im Untergeschoss des Neubaus zwei Nachrichtentechnikräume, die eine redundante Anbindung
des Gebäudes an das Universitätshauptgebäude mittels Glasfaserkabel erlauben und den neuen Kern unserer
IT-Infrastruktur aufnehmen werden. Dieser redundante "Backbone" besteht aus zwei Geräten, damit ein
Ausfall einer Komponente den Netzwerkbetrieb nicht komplett lahmlegt, sondern nur die maximal zur
Verfügung stehende Bandbreite und Performanz verringert.
Im Backbone werden zwei Cisco Nexus 7010 Switche zum Einsatz kommen. Diese können bis zu acht Linecards
mit jeweils bis zu 48 10 GBit/s-Ports aufnehmen. Die Fabric bietet für jeden Slot eine Bandbreite
von 550 GBit/s (also insgesamt 4,4 Terabits pro Sekunde!), so dass das mittlere 10-Slot-Chassis mit
bis zu 384 Non-Blocking 10 GBit/s ausgestattet werden könnte.
Aber auch die IT-Infrastruktur im Hauptgebäude wird erneuert: viele der größeren Bereiche der
TechFak haben bereits neue Switche bekommen. Die restlichen Standorte folgen in den nächsten Wochen.
Alle Switche im Access-Layer im UHG werden redundant mit 20 GBit/s angebunden. Die Anbindung des
UHG an das FBIIS wird mit insgesamt 80 GBit/s erfolgen.
Im FBIIS wird es erstmals möglich sein, auch Workstations oder Labor-Equipment mit 10 GBit/s zu
versorgen. Für den Laborbereich werden dazu eine kleine Anzahl (48-64 Stück) von 10 GBit/s-Ports
zur Verfügung stehen.
Außerdem entsteht ein neues Datacenter, welches mehr Platz und ausreichende Kühlleistung für eine
größere Anzahl von Servern bietet. Statt der klassichen Verkabelung (Patchkabel von den Servern werden
zu einem zentralen Switch verlegt), werden wir dort mit ToR-Switchen (Top of Rack) arbeiten.
Dabei wird jeder Serverschrank mit einem kleinen (1 HE) Switch ausgestattet, der die Server in
diesem Schrank anbindet. Die einzelnen Schränke werden dann über Glasfaserkabel an zwei zentrale
"Parentswitche" an das Netzwerk angebunden. Dies reduziert den Verkabelungsaufwand enorm, da nicht
hunderte von starren Cat-6-Patchkabeln über Kabeltrassen von allen Serverschränken zu einem zentralen
Netzwerkschrank verlegt werden müssen.
Damit der Aufwand für das Management überschaubar bleibt, arbeiten wir dabei nicht mit autonomen
Switchen, sondern nutzen die Fabric-Extender-Technologie (FEX) von Cisco.
Zwei Cisco Nexus 5596UP bieten genug 10 GBit/s-Ports für die Anbindung von bandbreitenintensiven
Anwendungen (Fileserver-Cluster, Netboot-Server, usw.). Die meisten Server werden mit
1 GBit/s an jeweils eine oder zwei Nexus 2248 Fabric-Extender angeschlossen. Diese 1 HE hohen
Geräte kann man sich als Linecard für einen modularen Switch vorstellen. Nur werden diese nicht
nicht in ein zentrales Chassis montiert, sondern über Glasfaserkabel (10 GBit/s) an die beiden
Nexus 5596 angeschlossen. Die Fabric-Extender selbst sind nicht managebar, denn deren Ports
werden über ihre Partent-Switche verwaltet. Statt 17 einzelne Switche müssen somit nur zwei
verwaltet werden.
Unser momentan noch aktuelles Datacenter wird dann zum zweiten Standort umgebaut. Dort werden
alle wichtigen Dienste und Daten repliziert, so dass bei einem Ausfall des Haupt-Datacenters die
wichtigsten Dienste erreichbar bleiben.
(sf)
|
| Kurzzeitiger Netzausfall heute morgen |
18. Januar 2012 |
Der zentrale Netzwerkrouter der Technischen Fakultät war heute morgen ausgefallen.
Dies hatte zur Folge, dass interne und externe Dienste während dieser Zeit nicht
erreichbar waren. Grund für den Komplettausfall war ein Softwarecrash auf dem Gerät.
In ein paar Monaten werden wir zum Glück diesen wichtigen Knotenpunkt gegen eine
redundante Konfiguration austauschen, damit derartige Ausfälle keine Beeinträchtigung
des Produktivbetriebes zur Folge haben.
Möglich wird dies durch den Forschungsneubau. Ein Großteil der IT wird dann in das
neue Datacenter umziehen und die Kerninfrastruktur wird damit erneuert.
(sf)
|
| Fileserverstörungen in den letzten Monaten |
18. Januar 2012 |
Seit November letzten Jahres haben wir immer wieder mit Problemen unserer Fileserver
zu kämpfen.
Wir beobachten überdurchschnittlich viele Ausfälle von Festplatten und RAID-Controllern.
Teilweise fallen drei bis vier - bis dahin laut Diagnosedaten völlig unauffällige -
Festplatten an einem Tag aus. Auch drei Ausfälle von RAID-Controllern hatten wir in
den letzten Woche zu verbuchen. Leider ist dabei teilweise Datenverlust aufgetreten, so
dass wir einige Daten aus dem Backup restaurieren mussten.
Ob ein direkter Zusammenhang mit einem vorigen Teilausfall der Kühlung in unserem Datacenter
besteht, können wir nicht mit Sicherheit sagen.
Da leider ein vorsorglicher Austausch aller betroffen Festplatten und RAID-Controller
zu kostspielig ist, können wir nur versuchen drohende Ausfälle möglichst früh Vorherzusagen
und ggf. durch Komponententausch zu verhindern. Wir haben dazu unser Ersatzteillager
aufgestockt.
(sf)
|
| Keine Nutzung von externen Diensten für geschäftliche Daten |
Oktober 2011 |
Der IT-Sicherheitsbeauftragte
der Universität weist in einem Rundschreiben vom 17.10.2011 alle Mitarbeiter an,
keine externen Dienste für die Speicherung von dienstlichen Daten zu benutzen.
Eine Speicherung von vertraulichen dienstlichen Daten außerhalb der Universität
sei nicht gestattet.
Dies betrifft u.a.:
- Die Weiterleitung von vertraulichen dienstlichen E-Mails zu externen
Anbietern
- Die Nutzung von Online-Speichern wie DropBox, iCloud
oder ähnlichen Diensten für vertrauliche dienstliche Daten
- Die Nutzung von Cloud-basierten Office-Lösungen wie z.B. Google
Docs oder Microsoft Office 365
Informationen über die Nutzung der TechFak-, CIT-EC- und CoR-Lab-Mailaccounts
sind in der Rubrik
Rechnernutzung / E-Mail auf unserer Webseite zu finden.
Bei weiteren Fragen und Problemen sind wir selbstverständlich per E-Mail an
support oder per Telefon unter
der Durchwahl 2900 erreichbar.
(sf)
|
| Neue Tastaturen und Mäuse für V2-234 und V2-240 |
Oktober 2011 |
Dank einer Spende aus 30 neuen Tastaturen und Mäusen von der Sparkasse Bielefeld
können wir die beiden Räume mit den momentan ältesten Rechnern auffrischen.
Damit haben wir in allen Räumen des GZI einheitlich deutsches Tastaturlayout.
Außerdem ist die Haptik der neuen Tastaturen deutlich angenehmer (die alten Tasturen
haben einen linearen Druckpunkt, was viele Benutzer als unangenehm empfanden).
Raum V2-234 ist bereits damit ausgestattet; V2-240 wird in dieser Woche folgen.
(sf)
|
| Keine Nutzung der TechFak-Dienste aus dem WLAN des HRZ |
Oktober 2011 |
![]() |
![]() |
Es kommen in fast regelmäßigen Abständen Anfragen von verschiedenen NutzerInnen,
einige TechFak-Dienste aus dem WLAN des Hochschulrechenzentrums erreichbar zu
machen.
Dies ist leider aus verschiedenen Gründen nicht möglich.
Eine Erklärung vorweg: das Hochschulrechenzentrum (HRZ) betreibt das allgemeine
WLAN in allen Gebäudeteilen der Universität. Das WLAN ist für alle da: Studierende,
MitarbeiterInnen aller Fakultäten und Gäste.
Damit sollte bereits jedem klar sein: ein großer Teil der WLAN-Benutzer ist gar nicht
berechtigt, Dienste der Technischen Fakultät zu nutzen.
Ausserdem haben wir keinerlei Kontrolle und Möglichkeit einen Störer
schnell und effektiv zu sperren.
Dazu kommt noch die Tatsache, dass leider viele Benutzergruppen des WLANs ihre
Software weniger gut und regelmäßig warten als es unsere NutzerInnen mit
technischem Hintergrund machen. Dies ist keine Vermutung, sondern Realität:
SSH-Brute-Force-Angriffe auf unsere Loginserver aus dem IP-Bereich des WLANs
sind nicht selten.
Wir bitten daher alle NutzerInnen - soweit möglich - das Kabelbebundene Laptopnetz
der Technischen Fakulät einzusetzen. Leichte Einschränkungen der Mobilität und der
nutzbaren Geräteklassen (Drucken vom iPad wird z.B. nicht möglich sein) müssen
damit leider hingenommen werden.
Aus dem WLAN sind alle Dienste, die auch aus dem Internet erreichbar sind, wie
z.B. E-Mail, viele Webdienste und unsere SSH-Login-Server, selbstverständlich
nutzbar.
(sf)
|
| Automatische Druckerkonfiguration für mobile Clients |
Oktober 2011 |
![]() |
![]() |
Gerade NutzerInnen von Notebooks hatten immer wieder Schwierigkeiten bei der
Benutzung der Drucker. Weil die korrekte Konfiguration für das Drucken über unseren
zentralen CUPS-Server realtiv kompliziert ist, haben viele Nutzer einfach den
gewünschten Drucker direkt angesprochen. Dies war möglich, da unsere Firewall
den direkten Zugriff auf die Drucker erlaubt hatte. Diese Methode birgt
allerdings einige Nachteile und Risiken: zum einen ist eine Zugriffskontrolle
so nicht realisierbar, weil kaum ein Druckertyp dies unterstützt und falls doch
ist die Konfiguration dezentral, fehleranfällig und nicht wartbar.
Zum anderen brachte eine falsche Konfiguration eines Laptops die Drucker immer
wieder zum Absturz (nur durch einen Hard-Reset zu beheben).
Damit alle NutzerInnen unseren zentralen Druckdienst auch nutzen, haben wir die
automatische Konfiguration über Zeroconf (Bonjour unter OS X) eingeführt.
Wir setzen dabei auf die "Wide Area"-Variante, welche die Publizierung der
Drucker und ihrer Fähigkeiten über das "normale" Unicast-DNS erlaubt.
Ein OS X-Nutzer bekommt somit alle freigegebenen Drucker automatisch angezeigt
und braucht nur noch seinen bevorzugten Drucker auswählen. Die Einrichtung
erfolgt dann vollkommen automatisch.
In einigen Fällen ist noch ein wenig Hand anzulegen, weil wir die Ausstattung
der Drucker (Papierfächer, Auflösungen, Qualitätsstufen) nicht immer genau kennen.
Dort sind wir auf die Mithilfe der Rechnerbeauftragten angewiesen.
Update: Hier kam gerade die Frage rein, ob man dann auch mit dem iPad
(und auch iPhone) drucken könne: ja das geht. Aber nur theoretisch. Rein
technisch ist das kein Problem; das habe ich heute mal ausprobiert, aber das
geht rein praktisch nicht, weil das Drucken aus dem WLAN des HRZ nicht
möglich ist. Ich konnte das Testen, weil wir hier einen WLAN-Test-Accesspoint,
mit dem wir unser Forschungs-WLAN für mobile Roboter testen, haben.
(sf)
|
| Das Wetter für den Forschungsneubau: bewölkt |
Oktober 2011 |
![]() |
![]() |
Das Wort ist momentan Buzzword Nummer eins in der IT-Welt: die Cloud.
Virtualisierung setzen wir seit Xen 2.0 ein. Erst für unsere eigenen Server
und jetzt haben wir schon fast 120 virtuelle Maschinen. Bald werden es bereits
200 sein - das sagen die Ergebnisse der letzten Anforderungserhebung.
Nicht nur im Speichersektor wird sich für uns einiges ändern müssen, sondern
auch beim Thema Virtualisierung.
Momentan betreuen wir einen Pool von Virtualisierungshosts - Servern
verschiedenster Hersteller und Ausstattung: einige mit langsamen, aber
großen SATA-Festplatten, andere mit wenig Massenspeicher, aber schnellen
15krpm-SAS-Laufwerken, Maschinen mit viel Arbeitsspeicher und andere
mit weniger. Einie Maschinen sind sehr gut ausgelastet - manchmal ein
wenig zu gut - und andere könnten deutlich mehr Last vertragen, haben aber
zu wenig Speicher dafür. Alle Maschinen haben lokalen Massenspeicher.
Virtuelle Maschinen kann man daher nicht zwischen den verschiedenen Hosts
live (ohne sie abschalten zu müssen) migrieren. Dies macht das Installieren
von Updates und Routinewartung an der Hardware sehr kompliziert: es müssen
alle VMs auf dem Host abgeschaltet werden. Dazu muss ein Termin gefunden
werden, wo dies möglich ist - ohne großartig viele Benutzer damit zu
stören. Ein Ding der Unmöglichkeit. Der Verwaltungsaufwand ist auch
nicht zu unterschätzen.
Diese Sache muss ebenfalls einheitlicher, flexibler, ausfallsicherer und
performanter werden. Daher planen wir als Ersatz einzelner, autonomer und
unflexibler Virtualisierungs-Hosts die "private Cloud" des
Forschungsneubaus. Sie soll aus Knoten einheitlicher, deutlich performanterer
Hardware bestehen, Block-Storage aus der Storage-Cloud beziehen und in
Sachen Bedienbarkeit und Wartungsfreundlichkeit deutlich besser sein als die
aktuelle Lösung.
Storage-Cloud? Richtig gelesen: das von uns favorisierte Massenspeichersystem
bietet auch hierfür eine Lösung. Neben der NAS-Funktionalität bietet es
auch die Möglichkeit Blockspeicher für die virtuellen Maschinen zur Verfügung
zu stellen.
Live-Migration, Provisioning, Monitoring und Management sind nur einige
Must-Have-Key-Features der neuen Lösung.
(sf)
|
| Evaluierung einer neuen Storageumgebung für den Forschungsneubau |
Oktober 2011 |
![]() |
![]() |
Seit einigen Wochen haben wir eine ganze Menge zu tun - und dann muss
noch ein komplett neues Massenspeicherkonzept erarbeitet und geplant
werden.
Vor rund vier Jahren war die IT der TechFak noch überschaubar:
ein paar Server für Netzwerkdienste, ein paar SunRay-Server und ein
kleines SAN, bestehend aus fünf Fibre-Channel-Arrays mit einer
Gesamtkapazität von run 10 Terabyte und drei Fileservern.
Dann kam der große Knall: erst machte uns ein Bug im Filesystemcode arge
Probleme und liess einen Fileserver ständig abstürzen und dann brachte
uns ein Fehler in der Firmware eines RAID-Controllers schleichende
Datenkorruption. Irgendwann mussten die Arbeitsgruppen ihre Arbeit
temporär mehr oder weniger komplett einstellen, da die fehlerhaften
Fileserver und Arrays ein vernüntiges Arbeiten zu verhindern wussten.
Die Lösung war schnell parat und umgesetzt: statt teure FC-Arrays und
nur drei Fileserver für die TechFak, das CoR-Lab und das CIT-EC wurden
mehrere - pro Arbeitsgruppe einer - Fileserver mit Direct-Attached-Storage
(mit Festplatten direkt in der Maschine), bestehend aus x86-Standard-Komponenten,
angeschafft. Die Vorteile lagen auf der Hand: der Ausfall einer Komponente
oder eines Servers betraf nun nicht mehr die gesamten Benutzer (oder einen
großen Teil davon), sondern nur eine Arbeitsgruppe. Außerdem stieg die
Performance somit um ein vielfaches an und ein Performance- oder
Plattenplatzsünder konnte nun nur noch die Kollegenen seiner eigenen
Arbeitsgruppe stören. Das allerbeste daran: mein morgendliches Ritual,
nach dem Aufstehen den einen Fileserver per Remote-Management-Console
neuzustarten oder besser gesagt zu resetten, war nicht mehr! Ich
habe das "Advanced Lights Out Management" der Sun Fire V240
vermisst!
Nun sind drei Jahre vergangen und das Konzept hat sich durchaus sehr
gut bewährt: keinen einzigen Hardware-Ausfall (bis auf defekte
Festplatten)!
Und die Schwächen? Ja, die gibt es auch. Vor drei bis vier Jahren
füllte der gesamte Datenbestand der TechFak nur 10 Terabyte.
Jetzt sind es zwischen 120 und 150 Terabyte. So war das aber damals
nicht geplant! Aus den anfänglich sieben Fileservern sind inzwischen
20 geworden. Und man merkt so langsam: dieses Konzept skaliert für
die nun vorhandenen Datenmengen und Benutzerzahlen und neuen
Forschungswerkzeuge (wie z.B. High-Speed-Kameras) nicht mehr.
Auch ein High-End-RAID-Controller mit 24 Festplatten kommt bei
60 bis 70 Power-Usern, die alle gleichzeitig schreiben und lesen
wollen, ganz gehörig aus dem Takt: gerade das CIT-EC führte zu
größerer Zusammenarbeit zwischen den Arbeitsgruppen. Früher kamen die
Zugriffe auf den Fileserver einer Arbeitsgruppe fast ausschließlich aus
dieser selbst und nun ist das anders. Es gibt inzwischen AGs, die
mit Massendaten, wie z.B. HD-Video-Aufnahmen und Motion-Capturing
arbeiten. Und es gibt natürlich auch mehr Benutzer. Eine ganze
Menge mehr Benutzer.
In den nächsten Jahren ist nochmal mit weiterem großen Wachstum
zu rechnen. Es müssen 400 Terabyte her. Das ist Minimum. Mit
unserem aktuellen Konzept einzelner Fileserver ist das nicht
mehr zu stemmen. Der Verwaltungs- und Betreuungsaufand wäre
enorm hoch und die zu erwartende Performance einiger Hotspots
lächerlich und inakzeptabel.
Der Forschungsneubau des CIT-EC ist daher die perfekte Chance für
einen Neuanfang. Ein Neuanfang mit einer Technologie, die den
Erwartungen und Bedürfnissen der Forscher für die nächsten Jahre
gerecht wird. Niemand soll sich über ein Schneckentempo ärgern und
niemand soll genötigt sein unhandliche USB-Festplatten einsetzen zu
müssen, weil nicht genug Speicherplatz auf dem Server vorhanden ist.
Und so bestand unsere Tätigkeit der letzten Wochen aus Recherche und
dem Folgen von Verkaufsvorträgen der verschiedensten Firmen von
Speicherösungen. Wir haben die unterschiedlichsten Kozepte und
Lösungen kennengelernt. Alle haben eine Eigenschaft gemeinsam:
Sie sind teuer. Verdammt teuer. Was allerdings noch viel erschrekender
für uns war: die meisten davon passen nicht für uns. Was sollen wir
mit einem Speichersystem, das zwar in Sachen Speicherplatz
erweiterbar ist, aber die Performance nicht mitwachsen kann, da
es nur zwei Fileserverköpfe gibt, die irgendwann (für unsere
Verhältnisse viel zu früh) performancetechnisch am Ende sind?
Was sollten wir mit einem System, bei dem Speicherplatz fest
zu Volumes partitioniert werden muss? Das wär also unsere aktuelle
Lösung, nur als Big-Block. An der einen Stelle fehlt Speicherplatz
und an der anderen Stelle ist alles frei. Dazu kommen bei einigen
Herstellern noch ganz tolle Begrenzungen: 15 Terabyte pro Volume und
dann ist Schluss. Wie bitte? Gehts noch? Wir sind Forscher der
Informatik, Robotik und Biologie und kein Büroladen mit 600
Office-Rechnern.
Dann kommt die Frage nach der Redundanz. Keinen Single-Point-of-Failure
soll es geben. Das heisst bei den meisten Lösungen Replikation.
In Grunde genommen alles zwei mal kaufen und die Daten dann spiegeln.
So hatten wir uns das nicht gedacht.
Zum Glück haben wir dennoch eine Lösung gefunden, die nicht nur alle
Anforderungen der Benutzer erfüllt, sondern uns sogar auch noch gut
gefällt: diese Lösung arbeitet wie ein Cluster: man hat eine Menge
von Storagenodes (mindestens drei), wovon jeder eine doppelte
10GB-Anbindung an das Netzwerk bekommt und ein ultraschnelles
Infiniband-Backend-Netzwerk mit je zweimal 40GBit/s für die Kommunikation
der Nodes untereinander hat. Der Speicherplatz steht dank eines
speziellen Filesystems an jedem Punkt komplett zur Verfügung. Ohne
Partitionierung. Ein Filesystem ohne die typischen Nachteile.
Das System kann aus Nodes mit verschiedenen Speichertypen bestehen:
große SATA-Festplatten, schnelle SAS-Laufwerke und ultraschnelle
Solid-State-Disks. Die Daten werden dann je nach Zugriffshäufigkeit
automatisch auf die Speicherklassen verteilt. Ein Quellcode-Repository,
auf das besonders viele Benutzer gleichzeitig zugreifen, wird so
auf den schnellen SSDs vorgehalten und eine große Videodatei, die
hautsächlich sequentiell gelesen und geschrieben wird, liegt dann
auf dem preisgünstigen SATA-Pool. Ändert sich das Nutzungsverhalten
von einer Datenmenge, so wird diese vollautomaitsch migriert.
Die Erweiterung von Speicherplatz ist denkbar unkompliziert: einfach
einen oder mehrere weitere Nodes einbauen, an das Netzwerk anklemmen
und mit einem Hangriff in den Cluster aufnehmen. Und damit hat man
nicht nur an Speicherplatz gewonnen, sondern auch mehr Performance
zur Verfügung - weil jeder Node ein eigener Server mit eigenen
Prozessoren, Speicher (als Cache genutzt) und einer eigenen
Netzwerkanbindung ist.
Außerdem ist eine perfekte Integration in unsere komplizierte
und UN*X-orientierte Benutzerverwaltung möglich.
Aber das beste an dem System: es basiert auf Standard-Hardware und
benutzt als Unterbau FreeBSD. Damit ist weniger extrem pervers
teuer als so manch anderes System. Und man darf sich sogar als
root einloggen auf den Nodes ;) Ohne dafür extra zahlen zu
müssen (ich denke gerade an einen großen Netzwerkausrüster...).
Das schafft vertrauen.
In den nächsten Wochen werden wir uns die Meinungen von anderen
großen Hochschulen und Instituten einholen, welche dieses System
bereits produktiv einsetzen.
(sf)
|
| Erleichterung bei der Firewall-Verwaltung |
Oktober 2011 |
![]() |
![]() |
Seit einigen Wochen ist die Verwaltung der Firewall für eingehende
Verbindungen für uns deutlich unkomplizierter und entspannter geworden:
Bis dahin mussten wir als "Kunde" des Hochschulrechenzentrums jede
IP-Adresse, die aus dem Internet erreichbar sein sollte, einzeln in der
HRZ-Firewall freischalten lassen - und das obwohl die TechFak seit
Anbeginn eine eigene Firewall betreibt. Dieser zusätzliche Schritt hatte
enorm viel Zeit gekostet, weil die Benutzerverwaltung des HRZ mit der
großen Anzahl der Einträge der TechFak zu kämpfen hatte. Für die Freischaltung
von 20 IP-Adressen brauchte Carsten fast eine Stunde. Dies war aber nur die
halbe Miete: der Antrag musste noch ausgedruckt, unterschrieben und zum
HRZ gebracht werden.
Zum Glück konnte der komplette Netzbereich der TechFak auf einmal
und auf Dauer freigeschaltet werden, so dass wir nur noch unsere eigene
Firewall administrieren müssen ;)
Damit haben wir auch ein ganzes Stück Flexibilität gewonnen: ab jetzt
können wir Anfragen schneller bearbeiten und dies auch außerhalb der
Geschäftszeiten des HRZ.
(sf)
|
| DynDNS im Laptopnetz eingeführt |
Oktober 2011 |
![]() |
![]() |
Wir haben in der letzten Zeit immer wieder Anfragen nach der Möglichkeit,
feste IP-Adressen an bestimmte Laptops, Roboter oder embedded-Geräte im
Laptopnetz zu vergeben, erhalten, damit diese über einen festen Hostnamen
ansprechbar sind.
Leider ist dies aus verschiedenen Gründen nicht möglich, da der IP-Bereich
für die dynamische Vergabe von IP-Adressen vorgesehen ist und feste Adressen
den Pool von IP-Adressen für die dynamische Vergabe unnötig verkleinern.
Um dennoch eine Möglichkeit zu bieten, bestimme Geräte mit einem bestimmten
DNS-Namen ansprechen zu können, haben wir DynDNS (dynamic DNS) für das
Laptopnetz eingeführt. Ein Gerät kann dem DHCP-Server einen Wunschnamen
mitteilen. Ist dieser frei, wird automatisch ein DNS-Eintrag für diesen
Namen unter der Domäne "DHCP.TechFak.Uni-Bielefeld.DE." erzeugt.
Ein Laptop mit dem Namen "foobar" ist damit automatisch unter der FQDN
"foobar.DHCP.TechFak.Uni-Bielefeld.DE." erreichbar.
Hier ist aber Vorsicht geboten: es gibt keine Garantie, dass ein Gerät
seinen Wunschnamen erhält oder dass ein anderes Gerät diesen Namen bereits
hat. Daher ist immer sicherzustellen, dass bei Benutzung des Namens auch
der korrekte Host adressiert wird (z.B. bei SSH durch Kontrolle des
SSH-Host-Key-Fingerprints).
Im Gegensatz zu der ehemaligen Implementierung des HRZ von DynDNS in den
Flächen-VLANs haben alle unsere IP-Adressen im Laptopnetz primär feste
DNS-Einträge und die dynamsichen Namen werden nur zusätzlich vergeben.
(sf)
|
| DNSSEC eingeführt |
April-Oktober 2011 |
![]() |
![]() |
Seit letztem Monat sind alle von der RBG betriebenen Domänen digital
signiert.
DNSSEC ist eine Erweiterung des Domain-Name-Systems (DNS) um einige
Sicherheitsfunktionen. Weil fast alle IT-Dienste vom DNS Gebrauch machen
und oder über einen Domainnamen erreichbar sind, wirken sich die Schwachstellen
des DNS daher auf fast alle Dienste aus. Mittels Angriffsmethoden wie z.B.
Cache-Poisoning kann ein potentieller Angreifer den Datenverkehr beliebiger
Dienste umleiten und ggf. den Datenverkehr mitschneiden und Passwörter
abhören, indem dem Benutzer eine gefälschte Webseite "untergeschoben" wird.
Mittels DNSSEC können gefälschte oder veränderte DNS-Antworten erkannt
werden, weil dem Angreifer die passenden digitalen Schlüssel zum erzeugen
der korrekten Signatur fehlen.
Einen Wermutstropfen hat unsere Implementierng dennoch: um eine sichere
Authentifizierung zu erreichen, muss eine Vertrauenskette von unserer Domäne
(Zone) bis zum Wurzelknoten existieren - d.h. alle Glieder der Kette (Zonen)
müssen DNSSEC einsetzen. Im Falle der Domäne "techfak.uni-bielefeld.de."
wären die einzelnen Glieder "techfak" (signiert, von uns verwaltet),
"uni-bielefeld" (vom HRZ verwaltet, leider nicht signiert), "de"
(signiert) und die Wurzel (signiert). Weil das Hochschulrechenzentrum
noch kein DNSSEC anbietet, haben wir die öffentlichen Teile der Schlüssel
unserer Domänen in der DNSSEC Lookaside Validation registry (DLV) des
Internet Systems Consortium (ISC) hinterlegt.
Neben der Signierung aller unserer Zonen sind natürlich auch alle unsere
DNS-Resolver in der Lage, DNSSEC-signierte DNS-Antworten zu validieren.
(sf)
|
| IPv6-Migration fast abgeschlossen |
2010-Oktober 2011 |
Die RBG betreibt seit 2003 eine IPv6-Testinstallation und hat seit einigen
Jahren einen Nameserver im Dual-Stack-Betrieb.
Vor gut zwei Jahren haben wir damit begonnen, IPv6-Adressen in den
Arbeitsgruppennetzen per Autoconfiguration (SLAAC) auszugeben.
Die sorgfältige Planung und Vorbereitung hat sich ausgezahlt: es gab
weniger als eine Handvoll Problemreports.
Diese Aktion diente uns als Grundlage, erste interne Dienste ebenfalls
per IPv6 anzubieten. So sind unser LDAP-Dienst, unsere DNS-Resolver, unser
HTTP-Proxy und einige andere Dienste seit fast zwei Jahren erfolgreich
im Dual-Stack-Betrieb (IPv6 zusätzlich zu IPv4) erreichbar.
Ein weiterer großer Schritt erfolgte in den letzten Monaten. Heute sind
fast alle IT-Dienste der TechFak - auch von außerhalb aus - per IPv6
erreichbar: SMTP, IMAP, HTTP, WebDAV, SVN, SSH, usw.
Die Migration der restlichen Webdienste wird in den nächsten Wochen und
Monaten weiter vorranschreiten...
(sf)
|
| Keine Aktualisierung der News |
September 2010- |
|
Zur Zeit haben wir so viel zu tun daß die Aktualisierung dieser
Seiten zu kurz kommt. Wir hoffen daß wir uns in der vorlesungsfreien
Zeit ab Februar 2011 wieder mehr um unseren Internetauftritt kümmern können.
|
| GZI-Rollout und Urlaubspause |
Juni-August 2010 |
![]() |
![]() |
|
Urlaubsbedingt waren wir im Berichtszeitraum dünn besetzt und hatten
kaum Zeit, die News weiter zu pflegen. Das Hauptereignis in dieser
Zeit war natürlich das Ausrollen der 50 neuen Rechner für die
GZI-Räume V2-221 und V2-229. Um einen Eindruck vom Ausmaß dieser
Aktion zu vermitteln haben wir eine kleine Fotostrecke angelegt:
Die gut 50 Dell-Rechner und Monitore wurden am Morgen von der
Spedition angeliefert. So hatten wir dann erst mal 6 Europaletten
mit insgesamt 1430kg (steht so in den Frachtpapieren) in der
Fahrstraße stehen.
|
Natürlich konnten die Paletten dort nicht
stehen bleiben, also schafften wir sie erst mal herüber in den
Serverraum, wo es einiges an Stauraum gibt. Dort waren die Paletten
bis zum Mittagessen sicher untergebracht, denn
bis zum Abend wollten wir den Raum natürlich wieder freihaben.
Ab und an müssen wir ja auch an die Serverschränke zum Administrieren
ran ;-)
|
 |
 |
|
Also wurden die Paletten vor Ort ausgepackt (und mit den Folien gleich vor
Ort entsorgt) und auf den Rollwagen umgeladen. Damit der Rollwagen noch
in den Aufzug paßt, kann man pro Fuhre ca. 8 Rechner oder 10 Displays
mit nach oben nehmen. Wer sich zudem mit den Wartezeiten bei den Aufzügen
im entsprechenden Bauteil auskennt, kann abschätzen wie lange wir mit dem
Umräumen beschäftigt waren.
|
 |
 |
Die vorläufige Endstation waren unsere Räume in M3, auf die die Kisten verteilt wurden. Dort wurden
die PCs dann in den nächsten Tagen ausgepackt, geprüft und vorbereitet.
|
 |
 |
|
Zuvor wollten wir aber natürlich erst einmal sehen, ob das bereits schon vorbereitete Ubuntu Lucid
auf den Maschinen auch wie erwartet läuft.
Aufgrund der sich zuspitzenden Situation mit den
ausfallenden SunRay-Servern hatten wir nämlich nicht mehr die Zeit eine Teststellung kommen zu lassen.
Es gab bereits Ausfälle von Lehrveranstaltungen - die neuen Maschinen mußten
schnellstens beschafft werden.
|
 |
|
Also wurde flugs die erste Maschine ausgepackt - der optische Eindruck war schon mal
gut. Auch innendrin sind die Maschinen aufgeräumt und gut durchkonstruiert. Steckkarten
sind nicht vorhanden, denn inklusive der Grafik ist schon alles auf dem Mainboard vorhanden.
|
 |
 |
|
Schnell wurde noch ein TFT ausgepackt und das Ganze dort aufgestellt wo noch ein
wenig Platz zu finden war. Nach dem Anbooten macht sich allgemeine Erleichterung
breit - das vorbereitete Netboot-Lucid kommt hoch und die Maschine ist benutzbar.
Damit haben wir einen Arbeitstag erfolgreich abgeschlossen.
|
 |
In den nächsten Tagen wurden zunächst einige einzelne Maschinen ausgepackt
und auf unsere Büros und die Fachschaft verteilt, um die Linux-Installation
im praktischen Betrieb von mehreren AnwenderInnen testen zu lassen.
|
Schließlich war der Zeitpunkt gekommen: V2-221 wurde umgebaut. Die SunRays landeten
unten im Depot, und der Raum wurde zunächst einmal komplett leergeräumt und entkabelt.
Danach wurde gründlich sauber gemacht, und sämtliche Kabel wurden neu verlegt.
|
 |
 |
|
Dann rollten die neuen Maschinen an. Einige kleine Softwareprobleme, die erst beim massenweisen
Aufsetzen des gesamten Raumes aufgefallen waren, wurden gleich vor Ort repariert. Bis zum
Abend war es dann geschafft und der gesamte Raum bootete so, wie man ihn jetzt kennt.
|
 |
 |
Danach ließen wir uns eine Woche Zeit um sicherzugehen, daß nicht doch noch einige
Problemchen mit den neuen Maschinen unentdeckt geblieben waren. Doch unsere Sorgen waren
unbegründet, und wir konnten planmäßig auch V2-229 umstellen.
Danach hätten wir uns
gerne entspannt zurückgelehnt und uns darüber gefreut, nun das gesamte GZI wieder mit
einer aktuellen und einheitlichen Betriebssystemumgebung laufen zu haben - doch die
Vandalen machten uns einen Strich durch die Rechnung. Bereits einige Tage nach dem
Aufbauen der neuen Rechner eskalierten die Beschädigungen in den alten und neuen Räumen.
Wir wurden gezwungen die Schließregelung erneut zu verschärfen und schließlich zerstörten
die Vandalen die Schlösser in den GZI-Räumen, so daß momentan überhaupt kein Lehrbetrieb
in den Räumen mehr möglich ist - wir kommen selbst nicht mehr in die Räume hinein.
Weiteres zur Lage im GZI werden wir in Kürze berichten.
|
| Vorbereitungen |
17.05.-04.06.2010 |
![]() |
![]() |
Wann immer wir ein wenig Zeit hatten, haben wir das Ausrollen
der Ubuntu Lucid-Maschinen für das GZI weiter vorbereitet. Die Testmaschinen
booten mittlerweile stabil; es gibt an den Desktop-Umgebungen aber noch einiges
an Feineinstellungen zu leisten. Wir gehen davon aus die ersten Maschinen
Mitte Juni in der Fachschaft und im GZI einsetzen zu können.
Ein Problem mit IPv6 bedingte einen Update unseres Kernrouters. Dabei stellten
wir fest daß die aktuelle Firmware nicht mehr mit einem alten Telco-Modul darin
kompatibel war. Dieses Modul war im Serverraum ganz praktisch, da es mehrere
einzelne Patchkabel auf ein dickeres bündelte. Glücklicherweise war durch den
Upgrade des Switches auf M5 ein moderneres Modul freigeworden so daß wir das
Telco-Modul dagegen tauschen und die aktuelle Firmware anschließend nutzen
konnten.
Für die AG NI wurde der Umzug der Homes und Volumes abgeschlossen.
Damit können wir beginnen unsere alte Benutzerverwaltung
zu beerdigen und nur noch das neue LDAP-basierte System einsetzen.
Sobald dies passiert ist können wir über weitere Neuerungen und Vereinfachungen
im Bereich der Benutzerverwaltung nachdenken.
Auf unserem Webserver gibt es momentan Speicherplatzprobleme, da auf der gut
10 Jahre alten Hardware nur insgesamt ca. 40G Speicherplatz zur Verfügung stehen.
Mehr Speicherplatz können wir dort kurzfristig nicht nachlegen da keine weiteren
Steckplätze für Festplatten zur Verfügung stehen und aktuelle Modelle dort nicht
eingebaut werden können. Wir arbeiten noch an einer Übergangslösung
bis die TechFak einen neuen Server bekommt.
Anfang Juni haben wir endlich die gute Nachricht bekommen, daß die Verträge
von Jan und Christian verlängert werden. Damit wird auch in den nächsten beiden
Jahren das bewährte RBG-Supportteam zur Verfügung stehen.
|
| Neue Hardware wirft ihre Schatten voraus |
03.05.-14.05.2010 |
![]() |
![]() |
Die neuen PCs für das GZI sind (auf 5 Europaletten ;-) eingetroffen
und nach einigen Stunden intensiver Arbeit sicher verstaut. Die
Vorbereitungen für eine aktuelle Netboot-Release auf Basis von Ubuntu Lucid
sowie das Ausrollen der neuen Rechner sind angelaufen. Einen
ausführlichen Bericht dazu gibt es in einer der nächsten News.
Im Gebäude H (dem ehemaligen BLB-Gebäude) gab es noch einige
Nachbereitungen und Hinzufügungen für die dort vorgenommen provisorischen
Patchungen. Aber die Hauptsache ist schließlich daß dort die ersten
Büros mittlerweile genutzt werden können. Auf dem Cor-Lab-Dateiserver
haben wir die Firmware der dort installierten Festplatten aktualisiert;
dies wurde vom Hersteller zur Erhöhung der Betriebssicherheit empfohlen.
Da die Aktualisierung durch den RAID-Controller nicht möglich ist,
mußten die Festplatten einzeln ausgebaut und in einem PC aktualisiert
werden.
Am Freitag haben wir Komponenten für den Netzwerk-Switch im M-Bauteil
erneuert. Das M-Bauteil ist nun mit 10GBit (statt bisher 1GBit) an
unseren Kern angebunden, hat eine schnellere Supervisor-Engine
bekommen (die zum Verteilen des Netzwerk-Verkehrs dient) sowie die
letzten beiden 100MBit-Moduleinschübe wurden durch neuere 1GBit-Modelle ersetzt.
Damit haben wir jetzt dort auch genügend Kapazität für die Anbindung
der AG KS im M6-Bauteil.
|
Zunächst einmal mußten sämtliche Patchungen (die Verbindungen von
den Netzwerkdosen in den Büros zu dem Switch) entfernt werden.
Auf dem Bild sieht man, daß die oberen 7 Module bereits leergeräumt
sind, während in den unteren Modulen noch die Patchungen stecken.
Die herausgezogenen Kabel wurden sorgfältig gebündelt und auf die
Schränke gelegt, um sie nachher nach der vorbereiteten neuen
Patchliste wieder einstecken zu können. Eine Vertauschung an dieser
Stelle - bei ca. 400 Kabeln nicht ganz unwahrscheinlich - hätte
dazu geführt daß in den betreffenden Büros die Netzwerkdosen nicht
mehr funktioniert hätten. |
 |
|
Als nächstes wurden alle Module ausgebaut und durch Druckluft und Abwischen
gesäubert. Auf dem rechten Foto sieht man daß dies dringend nötig war,
da sich während der letzten 4 Jahre einiges an Dreck angesammelt hatte.
Der Schmutz fing bereits an die Kühlung der Komponenten zu beeinträchtigen
- nichts, was man einer 100.000 Euro (ja, mit 5 Nullen) teueren Hardware
antun möchte.
Auf dem linken Fotos sieht man das leere Chassis des Switches - alle
Module sowie die beiden Netzteile wurden zwecks Reinigung entnommen.
|
 |
 |
|
Danach erfolgte wieder der Zusammenbau in umgekehrter Richtung.
Auf dem Foto sieht man den Switch mit allen neuen Modulen sowie dem
bereits gesteckten 10GBit-Uplink. Danach mußten alle Patchungen wieder
gesteckt werden. Insgesamt hat uns die Aktion einen kompletten
Arbeitstag gekostet, aber es hat sich gelohnt - nicht eine Patchung
war danach verkehrt gesteckt :-)
|
 |
|
|
RBG Rechnerbetriebsgruppe der Technischen Fakultät · Universität Bielefeld 
