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. -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVu3qtAAoJEIu3uYB6vkH4KIEP/jJAQQx/kpJ6ikKR9W5qgifl xJy+OYx8s74VuFrcvnBiqvrRtedxnXCgclRWD2ivXtlsDiAxpMtDJuHkDGm9OMGU 1mPQieDNNPoe153RjMcmqF4MVCkwbuDwMRsVu34LqMG4JTRrKaiaKqxoFFYoxTUP mfHr46QA4RCMQGbrHyPq0C+3jCe2TbplVygkaAf7FJkNF2hpSB0I8YHlIBNiUWDP JFgAVsp92umaMlCge2iww/y3C4OA4SbH6llGalgQePwuQuEWIEu30PVuF6y8O4o4 r7jY6j68I9nBcZdI1smuAJZ+nk8cRJeS3sVyJ6rrAk72VNfbzusR7dZ48yvRgKHq 8sRXNqcx8A8Mrom+/O3uXvuTAQsBEr2wnUAGveK5cvG9c9psTLExNVSX7fE+ZAW9 5SZYHxVnY42zVV5Zepc7EUny1QFFceh4+lhiS9McxpWi8bu/Nk4FHdOHkfy1Knr0 TGuWQcoI/VC5rV6shVxNSbhDdIqNZH0P9Mx6PQI3vDZPoz6Sm1jrRIzUijT6OZF8 YhDUsBJtshSo5Je2Ka/G4c97fs8RNblVJQufWfzsNFUbVoRYqdtR/dp579o4iwYC 26ZyQMkIVWy7Kwf8wOMDfI4+9Ov0EkXWiTChhQJurpqf5L52/IdMUhl1I2Yp29l9 1x7GQcfrzGZuVAr3/uXM =HDcq -----END PGP SIGNATURE-----
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. -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
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
-- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
participants (3)
-
Eike Baran -
Peter Schmidt -
picard