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