nicht angemeldet
Hallo Sven
Dein Problem ist möglicherweise komplexer als du denkst. Du planst zur Zeit einen Server. Bei einem Web 2.0-Portal musst du ggf. eine humane 24/7-Betreuung einplanen und damit weitere Mitarbeiter und vieles andere mehr. Mit anderen Worten: Der Server alleine wird kaum reichen. Aber gut bleiben wir eim Server.
- Webserver, dedicated:
- Linux/Debian
- Preisklasse: unter 100€
Du meinst wahrscheinlich den Preis pro Monat und wahrscheinlich meinst du den Managed-Root-Server
Die Amazon Web Services gefallen mir deshalb sehr gut, weil sie frei skalierbar sind, innerhalb von Minuten hat man die Kapazitäten vervierfacht, sollte das System sich der Auslastung nähern.
Das hier und der Abschnitt davor, der passt nicht zusammen. Natürlich kann man per .htaccess zum Beispiel eine Lastverteilung vornehmen, derart, dass man einen Nutzer zum Server_1 schickt, den nächsten zu Server_2 u.s.w., nur wenn du auf der Internetebene eine solche Strukutur aufbaust, dann müssen gewalte Informationsströme zwischen den Servern zum Ausgleich fließen. Eine auf Server_1 hochgeladene Datei muss entweder kopiert werden auf die anderen Server oder es muss per Link klar sein, dass es die Datei nur auf Server_1 gibt. Ein editierter Beitrag auf Server_3 muss irgendwann gespielt werden auf Server_1 und Server_2.
Also mit einem einfachen Buch&Klick vervielfachst du keine Serverleistung.
Die "Wachstumsalternative" ist Server-Housing. Das bedeutet: Man stellt seinen eigenen Rechner im Rechenzentrum eines Providers. Eigene Rechner kann man Stacken. Ausgehend von einer "paid-Traffic"-Connection in das Internet können die Rechner selbst Inhouse per eigenes Ethernet verbunden sein - real oder virutell - und so innerhalb des RZ einen Abgleich führen.
Mit deiner Konstruktion nimmer der Paid-Traffic überproportional zu. Beispiel: Dein User-Traffic verdoppelt sich, und du brauchst zwei Server. Jeder Server bekommt 1/2 User-Traffic. Die Server selbst müssen sich austauchen und bekommen das mit 50% des User-Traffics auf die Reihe. Das bedeutet, dass zwischen den Servern eine weitere Traffic-Einheit stattfindet. Das sind in der Summe 3 Traffic-Einheiten.
Bei drei Servern sind es je eine Traffic-Einheit zu jedem Server und jeder Server sendet 1/2 Einheit zu den beiden anderen und das sind 6 Einheiten.
Also: Die Kundenzahl verdoppelt sich, die Traffic-Kosten wachsen mit dem Faktor 3. Wenn sie sich verdreifacht, dann habe ich 6 fachen Traffic.
Und unterschätze nicht die Kosten für die Entwicklung dieser Hintergrundsoftware, die nur die n Server aktuell hält!
Du musst dich dazu mal mit einem Enterprise-Server-Fachmann beraten, ich habe da letztens einen Vortrag gehört, über eine Software, die auf 24 CPUs läuft. Und das ist für ein Wachstumssystem eigentlich die ideale Lösung.
Das bedeutet: Man hat ein "Betriebsystem" und das kontrolliert 12 Motherboards, wobei diese auf die gleichen Datensäzte zurückgreifen.
Käme ich mit solch einer Serveraufstellung hin? Oder: Bis zu wieviel Page Impressions bzw. gleichzeitig aktiven Usern könnte man auf diese Weise fahren?
Das wird dir hier keiner sagen können. Es wird ganz auf die Infrastruktur ankommen, auf der du aufsetzt. Also wenn du bei den Autoren von Wordpress fragst, weil das dein initiales CMS ist, wirst du eine andere Antwort bekommen als würdest du bei Plone fragen. Im Kern wirst du also überhaupt erst einmal die CMSe durchgehen müssen und überlegen ob du diese als Starterpack nutzen kannst und willst.
Im übrigen: Es gehört eine solide Risikoabschätzung dazu: Welche Konsequenzen hätte es später für das Geschäft, wenn der Server n Stunden ausfällt. Ärgern sich nur ein paar Kunden oder kommen dann ruinöse Schadensersatzforderungen auf einen zu. Das hat einen maßgeblichen Anteil auf die notwendige Hardware.
Ich weiß nicht, ob und in welchem Umfang du hilfe bei der Planung bezahlen kannst oder möchstest. Ich habe mal meinen Link hier eingefügt Wolfgang Uhr. Ich fürchte nur: Einfache Antworten wie diese hier werden kaum weiter helfen.
Herzliche Grüße
Wolfgang