Vorschlag für vServer

Sowas nennt sich dann Reseller Account.

Ich glaube, er meint es anders:
man kann sich zwei vServer anlegen und die Ressourcen dann nach Gutdünken verteilen, wie man möchte.

Man kann z.B., wenn man backuppen will, die 2 Server so anlegen:
1) 50GB HDD, 3,5GHz, 7,75GB RAM
2) 50GB HDD, 0,5GHz, 0,25GB RAM

Oder, wenn man nur einen sek NS braucht:
1) 49,5GB HDD, 3,5GHz, 7,5GB RAM
2) 00,5GB HDD, 0,5GHz, 0,5GB RAM

...

[LEFT]Ja, das hast du ziemlich oft bei Reseller Accounts.

Dort kannst du z.B. 4GH CPU Speed kaufen 4GB Ram 200GB Platte und darfst die nach belieben auf X vServer aufteilen.

[/LEFT]

Das ist aber nicht sonderlich sinnvoll.
OK, um Game- und Webserver zu trennen, ist es OK.
Aber was bringt es, wenn z.B. ein unerwarteter Anstrum auf mySQL abläuft?
Die anderen vServer idlen vor sich hin und der mySQL-vServer knickt ein?

Naja, was ist z.B., wenn ein PHP-Script einen simplen "durchsuche alles"-befehl an mySQL schickt?
Das PHP-Script verbraucht nichts, während der mySQL-Server einknickt.

Da manuell zu schrauben, macht auch keinen Sinn, wenn es ohne reboot geht (was sowieso wahrscheinlich gar nicht laufen wird):
Wenn ein Server ausgelastet ist, weil z.B. die Datenbankserver ordentlich Laufzeit verbraten, dann antwortet eben der Apache langsamer. Und anders herum. Teilt man hingegen die Ressourcen fest zu, antwortet der Apache bzw. mySQL-Server schnell, doch keiner hört sich die Antwort an, weil der andere Server mangels Ressourcen gestorben ist.

Tja, das ist ja der Punkt: Der Entwickler weiß, was er macht.
Das Problem ist: Man muss immer was an Spielraum für Lastspitzen irgendeines Daemonen einplanen. Ich werfe jetzt einfach einfach mal 100MB RAM z.B. in den Raum. Diese 100MB RAM sind dann Puffer für Webserver oder mySQL-Server oder für die Storage-Daemons gleichzeitig.
Wenn man jetzt aber seine Server aufteilt, muss man auf allen 3 vServern ca. 70MB für Lastspitzen bereitstellen. Denn den RAM des Nachbarn können die vServer ja nicht nehmen. Das Resultat ist, dass man schon mehr als Spielraum einplanen muss.
Nun will auf den vServern aber auch noch ein System laufen. 3x Cron, 3x SSH, 3x Exim usw. Das verbraucht nochmal einiges sinnlos an RAM. Hinzu kommt der Festplattenplatz, der für das System draufgeht.
Das Resultat ist, dass aus von einem 4GB-RAM-Server, vond em man 3,8GB effektiv nutzen könnte, nur 2GB übrig bleiben.
Von dem sinnlosen Mehraufwand 3-facher Logpflege, Systemaktualisierung... will ich jetzt gar nicht anfangen.

Eine Analogie:
Richtest du dir zu Hause auf deinem Desktop-PC virtuelle Maschinen ein?
Eine fürs Browsen, eine fürs Mailen, eine fürs Zeichnen, eine fürs Schreiben, eine fürs Rechnen ... ?

Es spricht nichts dagegen _große_ Aufteilungen zu nutzen.
D.h. entweder Partitionen von geringer Mächtigkeit: Ich habe ja schon gesagt, dass eine Aufteilung GameServer|Webserver durchaus sinnvoll ist.
Oder aber große Einzelsysteme.

Aber 4GB RAM und 100GB Festplatte auf 5 vServer aufzuteilen, ist ein bisschen übertrieben, oder? Ein Grundsystem schluckt schonmal, wenn es anständig ist, 200MB. bei einem 4GB-Server (5%) deutlich tragbar. Aber bei 5 800MB-Servern fällt es mit insgesamt 1GB (25%) schon ins Gewicht.

Warum nicht statt vHosts einzelne vServer mit einzelnen Daemons nehmen?
Oder für jede Mail-Domain ein eigens Postfix-Courier-Spamassasin-Postgrey-System?
Oder für jede DB einen vServer mit mySQL-Daemon?

Eine physikalische Maschine in mehrer vServer aufzuteilen, ist der letzte Schritt, der sinnvoll ist.
Aber die Ressourcen eines vServers auf 5 µvServer aufzuteilen...

Aber ist ja egal. Wenn du es so handhaben willst, misch ich mich da nicht rein.
Nur wundere dich nicht, wenn ich mit weniger Ressourcen und gleicher Konfiguration deutlich mehr Performance habe.

Btw: Du hast meine Frage nicht beantwortet: Wie viele VMs hast du nun zu Hause auf dem Desktop?

Zitat von TheReaper;21265

Nun kann der Kunde in einem Frontend diese Ressourcen beliebig auf virtuelle Maschinen verteilen. Diese sind natürlich jederzeit umlegbar. [...]
Was haltet ihr von der Idee?

finde ich sehr gut, aber die Virtualisierung unterstützt das Ändern dieser Daten zur Laufzeit der VM glaube ich gar nicht.
Ein Konkurrent[1] von Netcup hat dieses Feature ja.
Wobei ich den Gedanken weitergeführt auch nicht schlecht finde: man kann sein Paket dauerhaft dynamisch ändern, heute habe ich die Konfiguration wie bei einem VP1000 nun ändere ich es in einen VP2000 und morgen ist es wieder ein VP1000.

Zitat von Artimis;21279

Ein Grundsystem schluckt schonmal, wenn es anständig ist, 200MB. bei einem 4GB-Server (5%) deutlich tragbar. Aber bei 5 800MB-Servern fällt es mit insgesamt 1GB (25%) schon ins Gewicht.

Hat Netcup nicht diese geteilte-Kernel-Architektur wodurch sowieso nicht jeder vServer diesen Arbeitsspeicherverbrauch des Grundsystems hat?

Zitat von Artimis;21279

Eine physikalische Maschine in mehrer vServer aufzuteilen, ist der letzte Schritt, der sinnvoll ist.
Aber die Ressourcen eines vServers auf 5 µvServer aufzuteilen...

sieh es doch so:
statt dass er sich X VP1000 mietet, mietet er einen VP3000 und teilt sich die Leistung dann selbst zu, wie er will, also ich könnte das auch brauchen

[1] Anbieternamen geändert, ich glaube Netcup mag das nicht.

Zitat

Wobei ich den Gedanken weitergeführt auch nicht schlecht finde: man kann sein Paket dauerhaft dynamisch ändern, heute habe ich die Konfiguration wie bei einem VP1000 nun ändere ich es in einen VP2000 und morgen ist es wieder ein VP1000.

Was ihr sucht, sind diese "Clouds".
vServer, die man nach Ressourcenverbrauch minütlich bezahlt.

Zitat

Hat Netcup nicht diese geteilte-Kernel-Architektur wodurch sowieso nicht jeder vServer diesen Arbeitsspeicherverbrauch des Grundsystems hat?

Was hat das damit zu tun?
Nutzt du den Mail-Server, den Cron-Daemon, den syslogd, den SSH-Server etc. pp. in "geteilter-Kernel-Architektur"? Wäre jetzt nicht so mein Ding, muss ich sagen.

Zitat

sieh es doch so:
statt dass er sich X VP1000 mietet, mietet er einen VP3000 und teilt sich die Leistung dann selbst zu, wie er will, also ich könnte das auch brauchen

Wie gesagt: Für eine Trennung in zwei vServer für z.B. GameServer samt TS gegenüber Webserver samt DB und Mail ist es durchaus sinnvoll. Aber dann kann man sich auch statt des VP3000 einen VP1000 und einen VP2000 mieten, oder, wie in TheReapers Fall zwei VP2000 statt eines VP4000.
Eine kleinere Aufteilung macht schlicht keinen Sinn. Es ist einfach so, da kann man noch so argumentieren, dass Großkonzerne auch auf mehrere 16GB-und-mehr-RAM-Roots aufteilen, bei xxx-MB-RAM-Servern ist es einfach sinnlos.

Und dafür einen sehr enormen Enwicklungsaufwand zu betreiben, würde ich mir anstelle von Netcup gar nicht erst überlegen. Es gibt so viel Sinnvolleres zu tun (z.B. IPv6, das Backup in den Griff kriegen, gucken, was es mit den hohen Loads und IO-Waits auf sich hat, chitypos Problemchen mit ständigen Reboots ... Kaffee kochen ... Raufasertapetenhubbel zählen ...).

Btw:

Zitat

Starte ich halt mal eben 2 Server oder so neu

Wir haben sehr unterschiedliche Auffassungen von Serverbetrieb. Ich denke, du bist "Entwickler"...?

Also, ich muss erhlich sagen, ich halte von der Idee gar nichts. Wenn man ernsthaft ein produktives Projekt betreiben möchte, kalkuliert man auf den bisherigen und fremden Erfahrungen einfach die benötigten Ressourcen und mietet sich die Server, die man braucht. Wer alle 2 Tage die Ressourcen hin- und herschrauben muss, hat da etwas im Konzept voll verpeilt. Und wer tatsächlich dynamische Ressourcen benötigt, der soll sich diese neuen "Clouds" angucken.

Es wird vermutlich noch dieses Jahr sog. Cloud-Server bei uns geben. Hier können Ressourcen dann nach Bedarf in Echtzeit gebucht werden. Ich denke dieses Produkt würde dann auf Ihr Vorhaben passen.