Tach!
Die zusätzliche Komplexität der virtuellen Umgebung hat doch der Hoster zu bewältigen, oder?
Das hilft uns aber nicht, wenn durch eine Lücke im Host-System das Gast-System kompromittiert werden konnte.
Ok, das kann ein zusätzliches Einfallstor darstellen, neben den Lücken im Betriebssystem oder den Anwendungen. Aber das muss der Hoster einfach mit beherrschen, ebenso wie den Rest seiner Infrastruktur.
Aber sollte da keins dabei sein, mit dem wir leben können? Gentoo wird es ja vermutlich nicht wieder werden.
Ich würde immer Gentoo präferieren. Hier hat man die größte Freiheit. Im Notfall tut es auch ein Debian oder ein FreeBSD.
Wenn ich mich recht erinnere, hat selbst CS den Nachteil der langen Compilezeit als bedeutend gegenüber dem Vorteil der Individualität gesehen. Es ist ja nicht so, dass man auf den vorcompilierten Distributionen nicht mehr selbst tätig werden kann. Zudem dauert es selbst bei Gentoo manchmal ewig, bis eine von Hersteller als stabil angesehene Version ein emerge-Script bekommt. Andererseits gibt es für die Distributionen, wenn auch manchmal abseits vom offiziellen Pfad (sprich testing statt stable o.ä.) durchaus auch zeitnah aktuelle Pakete. - Die Klärung dieser Frage ist aber nicht kriegsentscheidend.
Die Redundanzen durch zusätzliche Server oder Ersatzteile sind bei den virtuellen Servern sicher eingepreist und wohl aus monetärer Sicht nicht sehr abweichend sein.
Bei Virtualisierung ist Redundanz idR nicht notwendig. Wenn wirklich der Host abraucht, dann zieht man auf einen anderen um – davon haben die Anbieter idR ein paar herumstehen.
Ich meinte, dass der Hoster im Hintergrund für Redundanzen sorgen muss, die er in seiner Preisgestaltung natürlich berücksichtigen muss. Dass man durch die Virtualisierung im Gastsystem mit Redundanzen virtueller Hardware nicht mehr viel erreichen kann, ist mir soweit klar.
Bei nur einer Maschine müssten also zumindest die jetzigen RAM- und Plattengrößen zusammengezählt werden, […]
Nein. Das kann man so nicht rechnen. Erstens benötigt das OS ja auch einiges an Platz und zweitens sind einige Daten doppelt vorhanden. Man muss wirklich sich beschränken auf die reinen Nutz-Daten und die dann zusammen rechnen.
Gut, dann hat man bei einfachem Summieren am Ende sogar noch Platz übrig. Auch nicht schlecht.
Administrativ hat man mit einer Maschine auch weniger Arbeit.
Im Prinzip richtig, aber man sollte im Auge behalten, dass bei Wachstum mehr als eine Kiste notwendig wird. Die Trennung von Datenbank-Server und der Rest ist der erste Optimierungs-Schritt. Deshalb schrieb ich extra dazu, dass bei _aktuellen_ Leistungs-Eckdaten eine Kiste ausreicht.
Ja, deswegen auch mein Hinweis auf das interne Netz zwischen den Servern. Es wäre dann sehr von Vorteil, wenn zumindest das in einer virtuellen Umgebung vom Hoster zur Verfügung gestellt wird. (Beim 1&1-Cloud beispielsweise kann man zwar problemlos weitere Server hinzufügen, aber dieser Aspekt steht in keiner Leistungsmerkmalauflistung, noch sehe ich in Hilfe und Konfigurationsoberfläche bei einem solchen Server eine entsprechende Konfigurationsmöglichkeit.) Wenn auch nicht für heute, so sollte man sich zumindest diesen Weg für die Zukunft nicht völlig verbauen.
Wie sieht es mit Administrationshilfsmitteln aus. Kann ein Plesk, Webmin, etc. helfen oder steht es eher im Weg?
Ich würde von solchen Tools immer abraten. Nicht nur erzeugen sie einiges an Komplexität, sondern sie haben oft auch Probleme mit der Sicherheit und die generierte Konfiguration ist immer „kaputt“… Plex, Confixx und Co sind die WYSIWYG-Editoren der Server-Administration.
So eine Antwort hab ich von dir als Hardcore-Admin schon erwartet :-) Aber denk mal kundenorientiert. Sind die Nachteile so gravierend oder andersrum gedacht, gibt es vergleichsweise einfache Alternativen für die "täglichen" Jobs der Nebenadministratoren (EMail-Verwaltung als Beispiel)? Wenn ich mir von Plesk 10 die Apache-Konfiguration betrachte, so sieht mir das nicht wirklich kaputt aus und enthält genügend Eingriffsmöglichkeiten für Individualitäten.
dedlfix.