• hase

Hier möchten wir alles zum „neuen“ Haupt-Server im shack-RZ dokumentieren. Tests, Design-Vorschläge und -Entscheidungen etc. aufzeichnen.

Grundproblem ist, dass die Hardware im shack-RZ leider ein sehr unflexibles und schlecht wartbares Design hat. Angefangen beim OS bis hoch zu den VMs und den darin laufenden Services ist der ganze Stack leider sehr selbstbeschränkend. Nach Hörensagen gabs das Problem schon bei der letzten Iteration vom shack RZ. Die Ersteller des Setup sind weitestgehend weg, keiner weiß mehr Bescheid und das meiste muss mühsam Reverse Engineered werden.

Dieses Mal ist es nicht so ganz schlimm, momo hat uns noch einen kleinen Braindump vom Netzwerk dagelassen. Der ist im shack Gitlab zu finden.

Um das Problem aber nicht zu wiederholen wird dieses Projekt von Grund auf anders aufgebaut. Dies ist in den folgenden Grundsätzen aufgeführt.

Wichtig: Alle Änderungen am Design bitte erst hase aufzeigen. hase prüft die Änderungen auf die notwendige Doku. hase unterstützt hier auch gerne.

Um nicht wieder die gleichen Fehler wie die letzten 1-x Gruppen vor uns machen zu wollen sollten wir uns unbedingt an folgende Grundsätze halten.

Bitte legt pro Thema eine Unterseite an.Hier liegt das Template.

Das größte Problem momentan ist nicht das Setup, sondern die fehlende Doku. Die momentan vorhandenen Mitglieder, die sich des Themas annehmen, müssen umständlich mit Reverse Engineering herausfinden, welche Software wie aufgesetzt wurde.

Um dem in Zukunft zu begegnen muss unbedingt Doku geschrieben werden. Und nein, Codezeilen sind keine Doku. Als Doku-Ziel kann gerne diese Wiki-Seite oder eine neue Unterseite pro Thema genutzt werden; außerdem kann auch gerne für nicht-öffentliche Doku das Shack-Gitlab genutzt werden.

Ein zweites, wirklich großes Problem ist die fehlende Zusammenarbeit im Team, wie nun was aufgesetzt wird und was überhaupt gemacht wird. Außerdem ist es wirklich nicht hilfreich, wenn einzelne Teammitglieder unabhängig voneinander agieren und sich nicht an Absprachen im Team halten.

Es wird nicht an den Konzepten gearbeitet ohne Absprache. Bitte setze dich mit dem Team zusammen; rede mit den Leuten, und wenn du ein Problem hast sprich es einfach an. Man kann technisch diskutieren, persönliche Einstellungen oder Meinungen sollten aber aus dem Projekt rausgehalten werden. Ist etwas technisch nicht eindeutig, muss ein technischer Test und eine anschließende Abwägung der Ergebnisse erfolgen. Die Abwägung erfolgt Team-weit.

Ein zusätzliches Problem ergibt sich aus dem Alltag der Menschen. Bitte sei dir bewusst, dass du ein gewisses Commitment an Zeit und Verfügbarkeit mitbringen musst, um bei diesem Projekt mitzumachen zu können. Das Team kommt nur voran, wenn alle mindestens einmal die Woche Zeit dafür haben. Treffen im shack oder online können nach Notwendigkeit stattfinden, müssen aber nicht.

Wichtig: Wenn es Klärungs- oder Informationsbedarf gibt wird eine Reaktionszeit von maximal 48 Stunden über die etablierten Kommunikationskanäle (E-Mail/IRC/Telegram/Rocketchat etc.) erwartet. Wer dies nicht einhalten kann muss das Team im Voraus über eine längere Abwesenheit informieren. Diejenigen, die diese Reaktionszeit generell nicht gewährleistet können sollten sich nochmal überlegen, wie viel Zeit überhaupt zur Verfügung gestellt werden kann.

Alles ist soweit wie möglich und so einfach wie möglich zu automatisieren. Außerdem bitte ich um Einhaltung von Standards, die auf dieser und den folgenden Unterseiten aufgeführt sind.

Die Shack-Infrastruktur auf Seiten Compute und Netzwerk muss ganzheitlich betrachtet werden. Dazu möchte ich euch ein paar verschiedene Blickwinkel auf das eigentlich gleiche Thema aufzeigen.

Der erste Blickwinkel ist die Lokations-Zuordnung von Services. Es gibt Services, die nur lokal im shack verfügbar sein sollte. Andere Services können in einer DMZ aus dem Internet erreichbar sein. Wieder andere Services sollten nur für den Adminserver verfügbar sein. Außerdem gibt es noch Services, die zwar per Internet, aber NUR per VPN von Außen erreichbar sein sollten. Die Vorstands-Box oder das Portal wären ein Beispiel hierfür.

Der nächste Blickwinkel ist Wartbarkeit. Es sollten unbedingt Automatismen für Updates eingesetzt werden wo möglich. Dies gilt unabhängig davon, ob dies eine normale virtuelle Maschine oder einen Docker-Container anspricht. Außerdem spricht dies den gesamten Stack von der Hardware bis hoch zum eigentlichen Service an. Auch der Service muss in regelmäßigen Abständen ein Update bekommen.

Der nächste Blickwinkel ist notwendige Verfügbarkeit. Die generelle Verfügbarkeit aller Services, die nur lokal verfügbar sind, können beim shutdown ausgeschaltet und beim erneuten shack-open wieder hochgefahren werden. Wenn niemand im shack ist braucht auch keiner den Service MPD (Beispiel). Für die restlichen User im Netzwerk wie die Musiker oder Freifunk müssen die genutzten Services aber natürlich weiter verfügbar bleiben.

Der nächste Blickwinkel wäre Flexibilität. Der gesamte Stack an eingesetzten HW- und SW-Lösungen ist auf den Shack abzustimmen. Der Shack kann nicht unbedingt viel Geld für neue HW im Fehlerfalle ausgeben. Andererseits muss die Lösung einfach administrierbar sein. Die shack-Admins haben nicht Stundenlang Zeit und Lust, die shack Infrastruktur am Leben zu erhalten. Daher ist es wichtig, dass günstige, „offene“ Hardware eingesetzt wird. Ein Beispiel hierfür ist das Disk-Array EMC ES30. Dies ist quasi das gleiche Array wie der große EMC Speicher im RZ. Da es aber über SAS angesprochen wird gibt es keine proprietären Anteile, die dem Shack Probleme bereiten könnten beim Tausch dieser Hardware. Als zweiten Aspekt beim Punkt Flexibilität ist es ungemein wichtig, dass die Service-Gruppen flexibel auf verschiedenen Umgebungen eingesetzt werden können. Eine VM, die durch eine Nutzung eines LVM Logical Volumes auf einen Host gebunden ist, ist einfach nur eine Design-Fehlentscheidung. Dies war dann nicht ausreichend durchdacht bzw. es wurden keine Tests verschiedener Szenarien gemacht.

1. notwendige Funktionen
2. noch benötigte Hardware
3. No-Go's

1. Reboot aus OS heraus funktioniert nicht. Das BIOS findet den USB Bootstick nicht. Bitte Cold Boot über iLO machen.

• HW Übersicht

noch zu kaufen:

• MTFDDAK480TDS-1AW1ZAB: Micron 5300 PRO - Read Intensive 480GB, SATA 3 Stück Raidz1 für OS- und Container-Platten