Server/Aktualisierung/2016

Aus Wiki StuRa HTW Dresden
Zur Navigation springen Zur Suche springen

Konzept

Erstellung eines Konzeptes

Es werden konzeptionelle Entscheidungen getroffenen werden. In diesem Abschnitt sollen Fragestellung und entsprechende Optionen aufgezählt und begründet werden.

Entscheidung für die Virtualisierung

Verzicht auf Virtualisierung

Wohl mittlerweile kaum vorstellbar, aber es könnte auch auf Virtualisierung verzichtet werden.

Dafür spricht:

  • "der Aufwand"

Dagegen spricht:

Siehe auch: Server#Konzeption
  • Langfristig ist der Aufwand zur Verwaltung wohl geringer, das innerhalb der einzelnen virtuellen Instanzen nicht arg hohe Komplexität (Durcheinander) besteht.
  • Es kann relativ einfach ein Instanz (ferner ein Dienst) einzeln sauber abgestellt werden.
  • Nur weil ein einzelner Dienst ein Problem hat, ist nicht das ganzen System betroffen. (Notfalls kann eine einzelne virtuelle Instanz "ruhig gestellt" werden.)
Jails als mögliche Virtualisierung
bhyve als mögliche Virtualisierung
KVM als mögliche Virtualisierung
Xen als mögliche Virtualisierung
Docker als mögliche Virtualisierung
LXC als mögliche Virtualisierung

Entscheidung für ein Betriebssystem

FreeNAS als mögliches Betriebssystem
FreeBSD als mögliches Betriebssystem
PC-BSD als mögliches Betriebssystem
SmartOS als mögliches Betriebssystem
CoreOS als mögliches Betriebssystem
Debian als mögliches Betriebssystem
CentOS als mögliches Betriebssystem
Fedora als mögliches Betriebssystem

Entscheidung für Werkzeuge zur Konfiguration

Damit sind Tools zur Einrichtung und Verwaltung des Betriebs gemeint.
Verzicht auf ein Werkzeug zur Konfiguration

Tut das überhaupt Not? :-D

Dafür spricht:

  • Somit würde sich viel (unnötig detaillierte) Dokumentation vermeiden lassen.
  • Durch die (veröffentlichten) Konfiguration anderen kann sich gut ein Bild von bestmöglicher Verwendung (best practice) gemacht werden.
  • Wegen einer gewissen Abstraktion ist es einfach sich einen Überblick zu verschaffen.
  • Neue Aktive haben einen geringeren Aufwand sich einzuarbeiten, da sie sich gewisse standardisierte Mechanismen voraussetzen können.

Dagegen spricht:

  • Es sollte sich daran gehalten werden. Selbstdisziplin!
  • Wegen einer gewissen Abstraktion können Details, die Auswirkungen haben, nicht direkt erkannt werden.
  • Neue Aktive haben einen höheren Aufwand sich einzuarbeiten, wenn sie das Werkzeug zur Konfiguration noch nicht verwendet haben.
BSDploy als mögliches Werkzeug zur Konfiguration
Ansible als mögliches Werkzeug zur Konfiguration
weitere mögliche Werkzeuge zur Konfiguration
soll noch einzeln aufgegliedert werde

weitere Anforderungen

Anforderung Dateisystem

Grad Inhalt pro con
kann moderne Funktionalitäten, wie snapshots
  • btrfs
  • lvm
  • zfs
  • ext4
  • ...
soll einfaches Verwalten
  • btrfs
  • zfs
  • lvm
muss stabiles Laufen
  • zfs
  • btrfs

Anforderung "andere" Betriebssysteme

Mindestens ein übliches (etabliertes), liebes (politisch vertretbares) und nettes (keine Zahlungsverpflichtung) Betriebssystem mit Linux soll irgendwie auch laufen können. (Das kann zum Beispiel Debian sein. Das ist selbstverständlich überflüssig, wenn es sich um das "native" Betriebssystem handelt.)

Es läuft bisher zum Beispiel ein Dienst ISPConfig, was aktuell in einer Instanz mit Debian läuft.

Beschlüsse

Beschluss für Hardware

Beschluss für das Projekt

Wenn ein Beschluss für die notwendige Hardware gefasst ist, so soll "das Projekt" (mit Konzept) erarbeitet und folglich beschlossen werden.

Interessierte

  • Paul
  • mindestens 2 weitere nette Menschen mit grundlegenden Vorkenntnissen