9. Sitzung Bereich Administration Rechentechnik 2016

Anwesende

• Paul (V)
• Paul (S)

• Max
• ab 17:00
• PT
• bis 13:00

Abwesende

• bommel

Tops

• Ausarbeitung Angebote für Server
• Weitere benötigte Hardware
• Besprechung der Jailnamen
• Backup- und Jailkonzepte (redundante Jails, wichtige/unwichtige Jails, Dienste, etc.)
• Deploymenttool - Vorstellung Max (nur Erinnerung ;) )

Links

1. Angebote Server: https://pentapad.c3d2.de/p/stura-htw-dresden_server-2016
2. Fujitsu Primergy RX300 S8: https://wiki.c3d2.de/Benutzer:Vater/Fujitsu_Primergy_RX300_S8
3. https://wiki.stura.htw-dresden.de/index.php/Server/Aktualisierung/2016

Festplatten Server mollige Dörte

Aktuell sind im Server mollige Dörte 3 Festplatten verbaut.

1 Festplatte ist defekt und daher außer Betrieb.

Des Weiteren ist ein weiteres Fach (für eine 4 Festplatte) noch frei.

PT wünscht sich zwei neue Festplatten. Er bietet an sich um die Anschaffung zu kümmern. Er fragt an, ob dieser Ersatz bzw. Ergänzung gleich mit als Teil vom Projekt Server im Sommer aktualisieren! betrachtet werden kann. Schön wäre auch, wenn entsprechend für alle 4 Festplatteneinschübe auch ordentliche Einschübe beschafft werden. Das würde PT dann selbstverständlich auch mit anschaffen.

Paul(S) in der Funktion als Bereichsleitung und als entsprechende Projektleitung stimmt dem zu.

Server Fujitsu RX 300 S6

Paul und Paul holen einen Paket von der Poststelle. Bommel sprach da von was.

Es muss der Server hinsichtlich Funktionen geprüft werden, um zu beurteilen, ob er tauglich ist.

Es wird festgestellt, dass wegen dem Gehäuse der Netzteile das Gerät nicht funktioniert. Nach der Begutachtung wird das Problem mit entsprechend platzierter Isolierung behoben.

Dem Server fehlt es noch an Speicher (RAM) und Massenspeicher (HDD/SSD).

Zum richtigen Testen brauchen wir erst einmal passende Festplatten. (RAID ist doof und mag nicht richtig.)

Server Fujitsu RX 300 S8

Paul und Paul fanden im "Archiv" (A008) einen krass unbenutzten Server. Bommel sprach da von was.

Dem Server fehlt es noch an Speicher (RAM) und Massenspeicher (HDD/SSD).

Wieder verpackt bleibt der Server weiter im Archiv.

Ausarbeitung Angebote für Server

Paul(S) verweist noch einmal auf die Sammlung von recherchierten Angeboten, die Paul(V) und Paul(S). Sie haben das im Pad zum Projekt gesammelt. https://pentapad.c3d2.de/p/stura-htw-dresden_server-2016

Paul(S) wird - entsprechend des Beschlusses zur Anschaffung Server 2016 - die Angebote dem Referat Finanzen zusenden und sich die Zustimmung abholen. Wesentlich erscheint allen Beteiligten, dass wir "alternativ" Hardware beschaffen dürfen. (Auf diesen Weg schaffen wir das wesentlich preiswerter.)

Weitere benötigte Hardware

Paul(S) meint, dass nach Hardware zu FC sich umgeschaut werden sollte. Jo! (Das soll dem Verbund von Servern dienen.)

Bezüglich der Festplatten für die neuen Server schlägt Paul(S) vor, dass für den maßgeblichen Server SAS und für den ergänzenden Server SATA verwendet werden soll. Paul(V) würde statt SAS auch SSD nehmen. Paul(S) entgegnet, dass das "wegen dem plötzlich Wegsterben" der gesamten platte doof ist. Jedoch gesteht jedoch Paul(V) zu, dass für ZFS für caching SSD angeschafft werden soll. Max recherchiert auf die Schnelle, dass der preisliche Unterschied ohnehin gering ist.

Paul(S) benennt den Preis von 250 - 290 € für 600 GB SAS. Max schaut, ob es das auch für SSD - insbesondere hinsichtlich Server - gibt. (SSD (bei Samsung) soll mindestens die Generation 800 sein.) Bei der Sitzung kommende Woche soll die Entscheidung dazu spätestens getroffen werden.

Paul(S) wird RAM besorgen.

• mindestens 2 x 16 GB (S6), maximal 4 x 16 GB
• mindestens 1 x 32 GB (S8), maximal 4 x 32 GB

wie festplatten wir

Das besprechen wir im Detail noch einmal, wenn wir wissen wieviel Festplatten wir günstig bekommen.

"der Plan"

Paul und Paul machen sich "den Plan". Es ist doof, dass bommel nicht da ist, denn es geht ja nun viel um Redundanz und Ausfall-Foo.

Es soll 3 Maschinen geben:

• Service
• Hier läuft erst einmal alles.
• Hier soll auch alle Daten der Dienste, außer besonders Massendaten intensiven Diensten, liegen.
• Alle Daten sollen auf den Server Storage gesichert werden.
• Die Daten von besonders Massendaten intensiven Diensten sollen auf dem Server Storage liegen.
• Hier soll ein relativ neuer und leistungsstarker Server (Fujitsu (RX300) S8) zum Einsatz kommen.
• Fallback
• Hier werden für den Notfall (Ausfall vom Server Service) alle Dienste ergänzend übernommen.
• (Es könnte vielleicht einer der bestehenden (alten Server) verwendet werden.)
• Hier könnte - neben dem Backup auf dem Server Storage - auch ein Backup (zum sofortigen Ersatzbetrieb) gehalten werden.
• Storage
• Hier sollen massenhaft Massendaten abgelegt werden.
• Es soll auch ein backup vom backup geben.
• Hier soll ein relativ neuer und leistungsfähiger Server mit vielen möglichen Festplatten (Fujitsu (RX300) S6) zum Einsatz kommen.

Bezeichnung von Jails (virtuelle Instanzen)

Paul(V) ist das ziemlich egal. Jedoch schlägt er vor, dass zu erkennen sein soll was der maßgebliche Zweck der Instanz ist oder es strukturiert nachgeschlagen werden kann.

Paul(S) will nicht nachschlagen müssen und meint selbst, dass immer der Dienst klar erkennbar sein soll.

Lange Rede kurz:

Wir nennen unser Jails immer 'srs_' und fügen den jeweiligen Dienst an, wie z.B.:

• srs_plone
• srs_ldap
• srs_mail
• srs_mariadb

Wir nennen Jails für andere immer 'srs_' und fügen eine einheitliche Abkürzung für die jeweilige Organisation an,

• srs_et_owncloud
• srs_wiwi_wordpress
• srs_im_web
• srs_im_data
• srs_ba_web
• srs_kss_www
• srs_bufak-wiso_www-17

Änderung von bestehenden Konzepten

Instanzen für Datenbanken

Für jede Art von Datenbank (MariaDB, PostgreSQL, oder derartiges) soll es eine zentrale Jail geben.

Alle Datenbanken in allen anderen Jails (etwa MediaWiki, ownCloud oder derartiges) sollen die eine Instanz dieser Art von Datenbank nutzen.

Instanzen für Webserver

Eigentlich wäre es ja konsequent, wenn wir - wie auch bei Datenbanken - zentrale Jails für jede Art von Webserver (Apache, nginx oder derartiges) schaffen.

bommel?

Loadbalancing

bommel!

letsencrypt

Eigentlich wäre es schön das auch in einer eigenständigen Instanz zu betreiben.

bommel?

Backup

Paul(S) kümmert sich um lokale (in der jeweiligen Jail für die Art von Datenbank) Backups der Datenbanken.

bommel soll sich um die Backups von Daten über den eigenen Server hinaus kümmern.

Dienste

Paul(V) sollte vielleicht mal eine Übersicht zu allen künftig benötigten Jails bzw. Diensten erstellen. Paul(S) macht mit.

Paul(V) meint, dass sich das ja auch aus der von ihm erarbeiten Liste zu Einträgen für DNS ergibt.

Eigentlich brauchen wir daher erst einmal nur die "internen" Dienste zu benennen.

Fangen wir doch gleich mal an:

• mariadb
• postgresql
• ldap
• mail
• (apache)
• (nginx)
• (haproxy)
• (i)pxe
• cups
• ispconfig (oder sowas halt)

Deploymenttool

Max hat sich dem Thema angenommen. Es fand eine kurze Einarbeitung statt aber bisher kam noch nichts konkretes heraus.

Paul(V) bittet Paul(S) sich - ergänzend zu Max das auch nochmal grob anzuschauen:

• chef
• puppet
• ansible
• saltstack
• (fabric)

Server Monitoring (Nagios)

Paul (S) musste Max zeigen, dass es auch eine kostenlose Version (Nagios Core) gibt. Ebenfalls sollen die Plugins (Nagios Plugins) mit installiert werden. Paul(V) gibt den Senf dazu, dass es das selbstverständlich auch in den Ports gibt.

kommende Treffen

Arbeitstreffen Plone

• 1. Arbeitstreffen Plone-Umzug
• 2016-08-22 12:00

nächste Woche

• Paul und Paul möchten bommel nicht mehr vermissen müssen.
• Paul(V) und das Thema srs1 (Plone) und srs14 (mail ) aus dem FreeBSD 8.2 kratzen.
• 2016-08-25 11:00

übernächste Woche

• Vorstellung zu deployment tooling von Max (aka Prinz Valium :-* )