Sven: StartUp: Optimale Serveraufteilung (Beispiel ist gegeben)?

Hallo,

ich plane derzeit ein großes Web 2.0 Portal, das verschiedene Arten von Medien an die Nutzer ausliefern wird. Dabei arbeite ich zur Zeit an verschiedenen Konzepten. Bevor ich jedoch überhaupt mit dem Businessplan beginnen kann, müsste ich erstmal wissen, was mich die Hardware kosten würde, und genau da liegt das Problem:

Als StartUp fängt man bei 0 an, muss jedoch entsprechend voraus planen. Fürs Marketing ist ein 5-stelliger Betrag einkalkuliert, dessen genaue Größe ich auch noch nicht kenne - hierzu sind weitere Kalkulationen nötig und nicht zuletzt professionelle Beratung.

Man sieht also, Marketing wird stattfinden und daher darf es natürlich nicht sein, dass nach 2 Monaten die Server überlastet sind, und alle Mühen vergebens sind, weil die Webseite nicht mehr erreichbar ist!

Ich hab mir technisch folgendes überlegt:

1. Webserver, dedicated:

  • Linux/Debian
  • Preisklasse: unter 100€
  • Nur Apache/PHP zur Ausführung von Skripten und Auslieferung von Content
  • Ist Ziel-IP des DNS-Eintrags der Domain

2. Amazon RDS (MySQL)

  • MySQL 5.1
  • Anfangs 1 (virtuelle) CPU, 1.7 GB RAM
  • jederzeit änderbar auf bis zu 8 virtuelle CPUs und 68 GB RAM

3. Amazon EC2

  • pure Rechenleistung
  • zur Konvertierung von Videos
  • Anfangs 1 virtuelle CPU, 1.7 GB RAM
  • jederzeit änderbar auf bis zu 8 virtuelle CPUs und 1,6 TB RAM

4. Amazon S3

  • Speicherserver
  • unbegrenzte Kapazität, maximal 4 GB pro Datei
  • zur Speicherung von Videos, Bildern, Dokumenten, ...

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. Auch vorübergehende Spitzenlast-Zeiten könnte man so gut abfangen, die Kosten bleiben überschaubar.

Ich hab nur Bedenken, ob der einfache Dedicated Server vielleicht schnell überfordert sein könnte. Da hab ich auch nicht viele Erfahrungswerte, und hoffe deshalb, dass mir jemand weiterhelfen kann.

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?

Oder noch einfacher: Prozentual gesehen, wieviel würde auf den Dedicated Server an Last zukommen? Wird er nicht großzügig entlastet, da er keine großen Inhalte speichern muss, keine Datenbank bedienen muss, etc.? Wäre das eine sinnvolle Ausgangsbasis?

Gruß
Sven

  1. 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.

    1. 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

    1. Hallo,

      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.

      Gut, ob 24/7 Support jetzt in den ersten Monaten unbedingt nötig sein wird, oder ob es nicht auch ein 8-22 uhr support tut, lass ich jetzt außen vor. Aber zum Server selbst: Möglicherweise ist 1 (in Worten: ein) Webserver tatsächlich zu wenig bzw. zu risikoreich.

      Daher überlege ich grad in die Richtung: 2 Webserver, 1 Load Balancer. Fällt dann einer der Server aus, bekäme ich es ja mit und hätte ggf. die Möglichkeit, zu reagieren, bevor der zweite auch ausfällt. Wobei sich mir grad die Frage stellt: Was ist, wenn der Load Balancer ausfällt?

      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.

      Beim Server Housing sehe ich immer eine große rote Zahl vor Augen, die mein Marketingkapital schmälert. Man investiert, sagen wir mal einfach 10.000€ in Hardware, obwohl man mit 0 Usern beginnt. Und selbst wenn das Marketing anschlägt, alles funktioniert und man nach 6 Monaten feststellt: Die Hardware reicht nicht mehr. Dann wieder investieren, und jedes Mal verschenkt man zu Beginn Serverkapazitäten (weil sie nicht benötigt werden) und später wird's eng und man muss reagieren.

      Ich dachte daher, durch die Amazon Web Services wäre ich hier deutlich flexibler. Aber...

      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.

      .. diese Zahlen klingen auch nicht gut. Das werde ich natürlich durchkalkulieren, aber ich könnte mir vorstellen, dass es tatsächlich so ist: Amazon will ja auch nichts verschenken.

      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.

      Vermutlich hast du recht, trotzdem helfen einem "einfache Antworten wie deine", einen gewissen Überblick zu gewinnen und vielleicht in die richtige Richtung zu steuern. Man muss ja nicht die Fehler machen, die 10 andere StartUps zuvor schon gemacht haben. Dein Link ist schon gebookmarked ;-) Die Artikel werde ich mir nach und nach zu Gemüte führen.

      Vielen Dank!

      Gruß
      Sven

    1. Webserver, dedicated:
    • Linux/Debian
    • Preisklasse: unter 100€
    • Nur Apache/PHP zur Ausführung von Skripten und Auslieferung von Content
    • Ist Ziel-IP des DNS-Eintrags der Domain

    Das wäre ein SPOF. Je nachdem, welches Risiko ein Ausfall für dich bedeutet, sollte hier ein Cluster eingesetzt werden. die Hochverfügbarkeit von RDS und S3 bringt nichts, wenn der Webserver ausfällt.
    Wie viele Requests ein einzelner Webserver handeln kann, hängt von der Anwendung ab. Mit aggressivem Caching (APC, memcached) und wenig I/O ist hier einiges herauszuholen.
    Bei der Server-Dimensionierung solltest du auf möglichst viel Arbeitsspeicher achten. Vielleicht ist auch eine Kombination von nginx als Load Balancer und einem anderen Webserver (zB lighttpd mit php) für die dynamischen Inhalte sinnvoll - das hängt aber vom Anwendungsfall ab.

    1. Amazon RDS (MySQL)
    • MySQL 5.1
    • Anfangs 1 (virtuelle) CPU, 1.7 GB RAM
    • jederzeit änderbar auf bis zu 8 virtuelle CPUs und 68 GB RAM

    Die einfache Skalierbarkeit und Hochverfügbarkeit ist natürlich praktisch, aber auch relativ teuer (ungefähr $ 100/monatlich für die kleinste Variante [ohne Traffic, I/O]). Die Latenzzeiten von Webserver zu MySQL werden durch das Amazon-Hosting natürlich auch nicht schneller. Ob RDS einem weiteren dedicated Server vorzuziehen ist, hängt auch davon ab, wie häufig Daten zwischen Webserver und Datenbank ausgetauscht werden müssen.

    1. Amazon EC2
    • pure Rechenleistung
    • zur Konvertierung von Videos
    • Anfangs 1 virtuelle CPU, 1.7 GB RAM
    • jederzeit änderbar auf bis zu 8 virtuelle CPUs und 1,6 TB RAM

    Als Arbeitssklave für Konvertierung etc. sehr gut geeignet (evtl. auch nur für einige Stunden/Tag, um Kosten zu sparen). Nur I/O-intensive Tasks sind für EC2 ungeeignet. Wenn aber nur Videos aus S3 geladen, konvertiert und erneut dort gespeichert werden sollen, ist EC2 eine gute wahl.
    Einziger negativer Punkt: Zusätzlicher Aufwand bei der Entwicklung (kommunikation mit Webserver etc.).

    1. Amazon S3
    • Speicherserver
    • unbegrenzte Kapazität, maximal 4 GB pro Datei
    • zur Speicherung von Videos, Bildern, Dokumenten, ...

    S3 bzw. CloudFront lässt sich sehr gut als CDN einsetzen (Edge-Standorte weltweit mit CloudFront). Die Transferraten sind sehr hoch, die Latenz in Ordnung. Damit würdest du den Webserver sehr stark entlasten, sämtliche statische Inhalte können über S3 ausgeliefert werden

      1. Webserver, dedicated:
      • Ist Ziel-IP des DNS-Eintrags der Domain
        Das wäre ein SPOF. Je nachdem, welches Risiko ein Ausfall für dich bedeutet, sollte hier ein Cluster eingesetzt werden. die Hochverfügbarkeit von RDS und S3 bringt nichts, wenn der Webserver ausfällt.

      Gibt es da empfehlenswerte Anbieter? Server Housing wollte ich jetzt nicht in Anspruch nehmen, wegen der Anschaffungskosten. Aber da gibt es bestimmt auch fertige Angebote, nur findet man die *nicht* bei 1&1 und Konsorten... fällt dir da spontan was ein?

      Bei der Server-Dimensionierung solltest du auf möglichst viel Arbeitsspeicher achten. Vielleicht ist auch eine Kombination von nginx als Load Balancer und einem anderen Webserver (zB lighttpd mit php) für die dynamischen Inhalte sinnvoll - das hängt aber vom Anwendungsfall ab.

      Schön, ich war sowieso am überlegen, ob ich nginx oder lighty verwende. Die Idee mit dem Load Balancer klingt sinnvoll. Das wäre dann technisch gesehen ein Server (also tatsächlich ein hardwaretechnisches Gerät) als Load Balancer und dann mindestens 2 Server dahinter. Oder macht man sowas inzwischen virtualisiert?

      S3 bzw. CloudFront lässt sich sehr gut als CDN einsetzen (Edge-Standorte weltweit mit CloudFront). Die Transferraten sind sehr hoch, die Latenz in Ordnung. Damit würdest du den Webserver sehr stark entlasten, sämtliche statische Inhalte können über S3 ausgeliefert werden

      Dann ist S3 perfekt geeignet, vor allem mit dem EC2 - genau so hatte ich mir das vorgestellt! Aber du hast mich da auf eine weitere Idee gebracht:

      Wenn ich nun ein Template für die Startseite baue, dass z. B. alle 5 oder 10 Minuten durch einen Cronjob neu mit Inhalten befüllt und als index.html abgespeichert wird - dann habe ich eine statische Startseite, die trotzdem immer top-aktuell ist. Da viele Leute nur die Startseite ansurfen und direkt wieder gehen, würde dafür dann gar kein PHP-Parser anspringen müssen. Ich hab von dieser Methode mal gehört, da ging es um Optimierung einer Website für TV-Werbung.

      Wenn ich das so machen würde, und die statische Startseite dann vielleicht auch noch auf dem S3 speichern würde - wäre das nicht zusätzlich Entlastung? Ich könnte den Aufruf der index.html per RewriteRule vom Webserver auf den S3 umlenken. Oder wäre das deiner Meinung nach eher viel Aufwand für nichts?

      Nur ein Gedanke... vielen Dank für deine Anregungen!

      Gruß
      Sven

        1. Webserver, dedicated:
        • Ist Ziel-IP des DNS-Eintrags der Domain
          Das wäre ein SPOF. Je nachdem, welches Risiko ein Ausfall für dich bedeutet, sollte hier ein Cluster eingesetzt werden. die Hochverfügbarkeit von RDS und S3 bringt nichts, wenn der Webserver ausfällt.

        Gibt es da empfehlenswerte Anbieter? Server Housing wollte ich jetzt nicht in Anspruch nehmen, wegen der Anschaffungskosten. Aber da gibt es bestimmt auch fertige Angebote, nur findet man die *nicht* bei 1&1 und Konsorten... fällt dir da spontan was ein?

        Serverhousing ist in DE zwar ziemlich billig (in AT fast nicht leistbar ...), aber bei drei Servern wirst du mit Service-Verträgen etc. mindestens € 10.000 an Anschaffungskosten haben.
        Die dedicated Server bei Host Europe haben ein gutes P/L-Verhältnis.

        Bei der Server-Dimensionierung solltest du auf möglichst viel Arbeitsspeicher achten. Vielleicht ist auch eine Kombination von nginx als Load Balancer und einem anderen Webserver (zB lighttpd mit php) für die dynamischen Inhalte sinnvoll - das hängt aber vom Anwendungsfall ab.

        Schön, ich war sowieso am überlegen, ob ich nginx oder lighty verwende. Die Idee mit dem Load Balancer klingt sinnvoll. Das wäre dann technisch gesehen ein Server (also tatsächlich ein hardwaretechnisches Gerät) als Load Balancer und dann mindestens 2 Server dahinter. Oder macht man sowas inzwischen virtualisiert?

        nginx lässt sich als caching reverse proxy einrichten. Dabei werden die Requests an die dahinterliegenden PHP-Webserver weitergeleitet. Der Response kann dann anschließend von nginx gecached werden, sodass spätere Requests direkt von nginx aus dem Cache (statisch) bedient werden können.
        Bei der Konfiguration des nginx-Cache gibt es mehrere Wege zum Ziel. Du kannst z.B. Cache-Control-Header in deiner Anwendung mitschicken, die von nginx ausgewertet werden.
        Virtualisieren lässt sich das ganze natürlich auch, würde das ganze aber komplizierter machen.

        S3 bzw. CloudFront lässt sich sehr gut als CDN einsetzen (Edge-Standorte weltweit mit CloudFront). Die Transferraten sind sehr hoch, die Latenz in Ordnung. Damit würdest du den Webserver sehr stark entlasten, sämtliche statische Inhalte können über S3 ausgeliefert werden

        Dann ist S3 perfekt geeignet, vor allem mit dem EC2 - genau so hatte ich mir das vorgestellt! Aber du hast mich da auf eine weitere Idee gebracht:

        Wenn ich nun ein Template für die Startseite baue, dass z. B. alle 5 oder 10 Minuten durch einen Cronjob neu mit Inhalten befüllt und als index.html abgespeichert wird - dann habe ich eine statische Startseite, die trotzdem immer top-aktuell ist. Da viele Leute nur die Startseite ansurfen und direkt wieder gehen, würde dafür dann gar kein PHP-Parser anspringen müssen. Ich hab von dieser Methode mal gehört, da ging es um Optimierung einer Website für TV-Werbung.

        Wenn ich das so machen würde, und die statische Startseite dann vielleicht auch noch auf dem S3 speichern würde - wäre das nicht zusätzlich Entlastung? Ich könnte den Aufruf der index.html per RewriteRule vom Webserver auf den S3 umlenken. Oder wäre das deiner Meinung nach eher viel Aufwand für nichts?

        Genau diesen Effekt erreichst du mit der oben genannten nginx-Konfiguration.

        Beim Load Balancing hättest du auch noch die Möglichkeit, den Elastic Load Balancer zu verwenden. Dabei werden die Anfragen auf alle anderen EC2-(Webserver)-Instanzen verteilt. Fällt einer der Webserver aus, wird dies vom Load Balancer erkannt und der Webserver nicht mehr verwendet.
        Vorteil bei dieser Lösung wäre, dass du nicht auch noch ein Load Balancing-Cluster aufbauen müsstest, weil sich Amazon darum kümmert. ELB kostet ungefähr $ 18/Monat ohne Traffic.
        Allerdings musst du dich um das Caching bei dieser Lösung an anderer Stelle kümmern (direkt im Webserver). Und natürlich müssten auch alle Webserver in EC2 betrieben werden, da der Load Balancer nur mit EC2-Instanzen funktioniert (Vielleicht lässt sich das ganze über Ubuntu Enterprise Cloud irgendwie mit einem dedicated Server kombinieren ...).

  2. Hallo Sven,

    leider habe ich direkt zu deiner Frage nichts zu sagen. Aber ich habe vor ein paar Monaten mal einen Artikel in einem Facebook Blog (glaube ich) gelesen, wo die Facebook Programmierer erklären, wie sie das mit den ganzen Servern amchen und auch, wie das mit dem Caching etc. abläuft.

    Ich bin der Meinung, dass man aus diesem Artikel sehr viel lernen kann. Vielleicht findest du ihn ja über Google. Ich habe ihn leider nicht gebookmarkt - oder finde ihn nicht...

    Gruß
    Alex