[Admin] Servicekarte Tabelle

Admin
1

hallo ihr,

mir fällt bei den servern (dedi, vm, container und services) die
übersicht schwierig. ich weiß nicht wie es euch geht, aber ich möchte
dies verbessern und somit etwas zur Diskussion stellen.

syncthing/ffnwAdmin/Technics/Serverplanung/servicekarte.ods

grundlegende verändung gibt es im srv namens bereich!
ich möchte zur diskusion stellen nur noch dedi und (k)vm die gemietet
sind als srvxxx zu benennen und alle container die wir anlegen auf den
gemieteten dann anders nennen.
z.b srvxxx(a,b,c usw...) oder etwas vergleichbares was NameService
konform ist.

hiermit werden folgende dinge erreicht.
ssh verbindungen: verbinde ich mich auf einen dedi/vm oder container.

unterhaltungen: an z.b srv01 oder srv13a erkennt man direkt um welche
art von host es sich handelt.

durch eine tabelle kann man auf einem blick erkennen was ist noch an
"Services" "Installiert" oder "Planung" wen "Gehört" der Server und wo
ist der "Standort" EOL und anderen spalten natürlich ohne probleme
anhängbar.

ich habe die tabelle bis jetzt nur mit ein paar daten gefüllt um zu
zeigen in welche richtung ich es mir denke.

Meinungen, Ideen und Diskussion bitte.

2

hallo ihr,

mir fällt bei den servern (dedi, vm, container und services) die
übersicht schwierig. ich weiß nicht wie es euch geht, aber ich
möchte dies verbessern und somit etwas zur Diskussion stellen.

syncthing/ffnwAdmin/Technics/Serverplanung/servicekarte.ods

finde ich jetzt tendenziell noch unübersichtlicher als das, was wir
bereits haben.

grundlegende verändung gibt es im srv namens bereich! ich möchte
zur diskusion stellen nur noch dedi und (k)vm die gemietet sind als
srvxxx zu benennen und alle container die wir anlegen auf den
gemieteten dann anders nennen. z.b srvxxx(a,b,c usw...) oder etwas
vergleichbares was NameService konform ist.

Das sehe ich genauso. Da sollten wir in jedem Fall ne sinnvolle
namensgebung entwickeln.

hiermit werden folgende dinge erreicht. ssh verbindungen: verbinde
ich mich auf einen dedi/vm oder container.

unterhaltungen: an z.b srv01 oder srv13a erkennt man direkt um
welche art von host es sich handelt.

durch eine tabelle kann man auf einem blick erkennen was ist noch
an "Services" "Installiert" oder "Planung" wen "Gehört" der Server
und wo ist der "Standort" EOL und anderen spalten natürlich ohne
probleme anhängbar.

ich habe die tabelle bis jetzt nur mit ein paar daten gefüllt um
zu zeigen in welche richtung ich es mir denke.

Meinungen, Ideen und Diskussion bitte.

Meine Ideen wären folgende:
- - Hierarchisches layer-basiertes Diagramm:
Würde das ganze vllt. in einer art Tabellenform anlegen - in
querrichtung die unterschiedlichen server, in hochrichtung die
Schichten: Blech/Hardware, VMS (kvm/openvz), VMS (lxc), dienste

- - idealerweise Darstellung und Pflege im Wiki: Auch wenn da
hoffentlich demnächst etwas Ruhe einkehrt, gab es ja in der
Vergangenheit diverse Änderungen und es würde mich nicht wundern, wenn
wieder in 3 verschiedenen Ordnern 5 verschiedene Darstellungen der
Serveraufteilung in 8 verschiedenen Dateiversionen herumflögen und
keine sie fände. Deshalb wäre es sinnvoll, das mal gut aufbereitet
(angefangen hatten wir damit ja sogar schon einmal) im wiki
dargestellt wäre. Gibt es da passende Plugins für moin moin mit denen
man solche diagramme direkt im wiki anlegen/bearbeiten könnte?

das ist jetzt aber nur so meine vorstellung; ich glaube, da gehen die
geschmäcker, was übersichtlich ist, weit auseinander.

3

Das sehe ich genauso. Da sollten wir in jedem Fall ne sinnvolle
namensgebung entwickeln.

hierzu hatte stefan eine idee

dedi = srv
(k)vm = vm
lxc = service.domain

- idealerweise Darstellung und Pflege im Wiki: Auch wenn da
hoffentlich demnächst etwas Ruhe einkehrt, gab es ja in der
Vergangenheit diverse Änderungen und es würde mich nicht wundern, wenn
wieder in 3 verschiedenen Ordnern 5 verschiedene Darstellungen der
Serveraufteilung in 8 verschiedenen Dateiversionen herumflögen und
keine sie fände. Deshalb wäre es sinnvoll, das mal gut aufbereitet
(angefangen hatten wir damit ja sogar schon einmal) im wiki
dargestellt wäre. Gibt es da passende Plugins für moin moin mit denen
man solche diagramme direkt im wiki anlegen/bearbeiten könnte?

eine tabelle lässt sich im wiki anlegen z.b in der form
https://wiki.nordwest.freifunk.net/SN

Kannst du es mal an einem srv als bsp bringen eike?

4

ich sehe schon, auf dokumentation haben alle lust :wink:

also bleiben wir erstmal bei dem was wir haben,
https://wiki.nordwest.freifunk.net/Server%20und%20Netzstruktur
erweitern es mit den neuen hosts und LXC Containern.
dazu passen wir noch die details an und damit sind wir wieder auf dem aktuellen ist stand.

Host Fingerprints hänge ich dann unter jeden host/container eintrag drunter, wie hier
https://wiki.nordwest.freifunk.net/Server%20und%20Netzstruktur#srv02

aber das namens schema müssen wir noch anpassen.

dedi = srvxx (srv01)
(k)vm = vmxx (vm01)
lxc = service (backup)

gebt ein +1. oder verbesserunge vorschläge.

5

Moin,

da muss ich als der Neue hier direkt mal reingrätschen, auch wenn ich mich auf
dünnes Eis begebe, da ich die örtlichen Gegebenheiten nicht kenne, aber ich
benenne schon seit einem dutzend Jahren beruflich Server.

aber das namens schema müssen wir noch anpassen.

dedi = srvxx (srv01)
(k)vm = vmxx (vm01)
lxc = service (backup)

Ich bin ja der Meinung, dass man Server nicht nach äußeren Attributen, sondern
nach Aufgaben benennen sollte. Schließlich ist die Haupteigentschaft eines
Servers ja nicht, ob er virtuell ist oder nicht ist, sondern er definiert sich
durch das, was er tut.

Daher würde ich Server immer nach dem bereitgestellten Dienst bennenen, zB
git1 oder netmon1. Gerne auch abgekürzt, zB mdb1 für einen Mariadb-Server oder
ora3, pgsql5, usw. usf.

So muss man auch nicht überlegen, war Git auf dem srv07 oder srv09, sondern
hat einen Namensbestandteil direkt zur Hand, durch die größere Bandbreite an
Namen bleibt die Zahl auch niedrig.

Ein weiterer Vorteil ist auch, wenn man einen Server mangels Last
virtualisiert oder einen virtuellen aus Lastgründen auf bare metal migriert:
Man muss nicht weiter umbenennen.

Diese Nomenklatur setzt natürlich voraus, dass konsequent gilt "1 Server == 1
Aufgabe", was aber in meinen Augen in den heutigen Virtualisierungszeiten kein
Problem darstellen sollte. Kommt einem am Anfang zwar etwas verschwenderisch
vor - aber wer einmal in einer Abhängigkeitshölle zweiter Serverdienste
steckte oder einen Servercrash auf einem Server mit vielen Diensten hatte,
wird nichts anderes mehr wollen. Dank Puppet kann es einem eigentlich auch
egal sein, ob es 10 oder 50 Server sind.

Gruß
Pta

6

Zitat von Peter Schmidt <pta@dvv32.de>:

da muss ich als der Neue hier direkt mal reingrätschen, auch wenn ich mich auf
dünnes Eis begebe, da ich die örtlichen Gegebenheiten nicht kenne, aber ich
benenne schon seit einem dutzend Jahren beruflich Server.

immer her damit, gerne.

Ich bin ja der Meinung, dass man Server nicht nach äußeren Attributen, sondern
nach Aufgaben benennen sollte. Schließlich ist die Haupteigentschaft eines
Servers ja nicht, ob er virtuell ist oder nicht ist, sondern er definiert sich
durch das, was er tut.

ich sehe einen unterschied zwischen Server (egal ob dedi oder VM) und LXC ContainerN.
jeden srv und vm muss man einzelln connecten um zugriff auf die daten zu haben.
bei einem LXC container komm ich (auch) über den Host an die daten.

So muss man auch nicht überlegen, war Git auf dem srv07 oder srv09, sondern
hat einen Namensbestandteil direkt zur Hand, durch die größere Bandbreite an
Namen bleibt die Zahl auch niedrig.

das ist ein vorteil.

Ein weiterer Vorteil ist auch, wenn man einen Server mangels Last
virtualisiert oder einen virtuellen aus Lastgründen auf bare metal migriert:
Man muss nicht weiter umbenennen.

das ist ein vorteil.

Diese Nomenklatur setzt natürlich voraus, dass konsequent gilt "1 Server == 1
Aufgabe", was aber in meinen Augen in den heutigen Virtualisierungszeiten kein
Problem darstellen sollte. Kommt einem am Anfang zwar etwas verschwenderisch
vor - aber wer einmal in einer Abhängigkeitshölle zweiter Serverdienste
steckte oder einen Servercrash auf einem Server mit vielen Diensten hatte,
wird nichts anderes mehr wollen. Dank Puppet kann es einem eigentlich auch
egal sein, ob es 10 oder 50 Server sind.

im moment nutzen wir LXC siehe
https://wiki.nordwest.freifunk.net/Server%20und%20Netzstruktur#LXC_Container