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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 31.07.2015 11:19, picard wrote:
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.
Am 31.07.2015 um 15:40 schrieb Eike Baran:
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?
ich sehe schon, auf dokumentation haben alle lust ;-)
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.
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.
Am Montag, 3. August 2015, 17:55:46 schrieb picard:
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
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
-
Eike Baran -
Peter Schmidt -
picard