nicht angemeldet
Ins Ausland: Servermanagement. Lastenverteilung, Replikation
Hallo zusammen.
Meinen Dienst gibt es derzeit nur in Deutschland.
Aktuell läuft hier auch nur ein Server.
Es handelt sich um eine Auktionsseite, d.h. kaum User-Generated-Content, alles redaktionell.
Zur Technik:
Webserver Apache 2
Statische Inhalte Nginx
Sprache PHP 5.3
Datenbank PostgreSQL 8.4
Compilercache APC
Cache-Server memcached
Reverse Proxy Squid
Content-Encoding UTF-8
Outputbuffering wird auch verwendet
Content-Komprimierung über mod_deflate
Es wird ziemlich viel über memcached gemacht damit PG-SQL entlastet ist.
Das alles läuft derzeit auf _einem_ Server - hier eine Frage nebenbei, durch das ganze Zeug entsteht natürlich ein Overhead, zweiter Server notwendig?
Die Seite wurde nun in Spanisch, Englisch und Französisch übersetzt.
D.h. wir werden unseren Dienst in verschiedenen Ländern anbieten können.
Es soll einen Server in Texas geben, zwei weitere in anderen Ländern.
Wie regel ich auf welchen Server der User weitergeleitet wird?
Aktuell wird die Sprache anhand HTTP_ACCEPT_LANGUAGE festgelegt (er kann es optional ändern, die ausgewählte Sprache wird dann als Cookie gespeichert und beim nächsten mal hat man seine gewünschte Sprache).
Je nachdem könnte man mit example.com _immer_ in DE landen und würde dann auf sprachkuerzel.example.com (z.B. en.example.com) weitergeleitet werden.
Beziehungsweise das könnte man auch mit Squid lösen.
Wie handhabt man generell mehrere Server im Ausland?
Teilen sich alle eine Datenbank oder muss ich jeden Schreibquery x (x=Anzahl der Server) fach ausführen?
Wenn die Leute bieten dann kommt es in den letzten Sekunden zu 2000 Lese/Schreibzugriffe / Sekunde. Wenn ich diese Auktion also in mehreren Ländern anbieten möchte, wie kann ich dann die Performance gewährleisten?
Wie sollte ich meinen Dienst nun ins Ausland verlagern?
Nur die Web-App und die Datenbank lasse ich in einem Land?
Das würde vielleicht sogar gehen da eh alles mit memcached abläuft und am Ende kann dann in die DB geschrieben werden.
Lg, Expandeur
-
Das alles läuft derzeit auf _einem_ Server - hier eine Frage nebenbei, durch das ganze Zeug entsteht natürlich ein Overhead, zweiter Server notwendig?
Schau' dir die Auslastung des bestehenden Servers an. Wenn der sich die meiste Zeit langweilt, braucht du keinen zweiten Server. Wenn er sich nur ein wenig langweilt, solltest du dir die Sache mit dem zweiten Server trotzdem gut überlegen – nicht, dass es darauf hinausläuft, den schnellen internen Speicherbus durch ein vergleichsweise kreuzlahmes Netzwerkkabel zu ersetzen und damit vom Regen in die Traufe zu stolpern.
Wie sollte ich meinen Dienst nun ins Ausland verlagern?
Auch hier mal ganz grundsätzlich: Man verlagert nicht ins Ausland, sondern zum Benutzer hin. Wenn ein Zugriff aus dem Ausland zur Zeit ewig braucht, weil die Leitung so lang ist, dann macht es Sinn, in diesem Ausland (lies: näher am Benutzer) einen Server aufzustellen. Ansonsten ist das eher eine kosmetische Operation.
Angenommen, du brauchst mehrere Server:
Am einfachsten wäre es, einen zentralen Datenbankserver zu benutzen und dazu ein oder mehrere Webserver, die so viele Daten wie möglich selbst vorhalten. -
Moin!
Das alles läuft derzeit auf _einem_ Server - hier eine Frage nebenbei, durch das ganze Zeug entsteht natürlich ein Overhead, zweiter Server notwendig?
Welches "Zeug"?
Die Seite wurde nun in Spanisch, Englisch und Französisch übersetzt.
D.h. wir werden unseren Dienst in verschiedenen Ländern anbieten können.Es soll einen Server in Texas geben, zwei weitere in anderen Ländern.
Ich dupliziere Dodos Meinung: Server vervielfacht man dann, wenn man mehr Leistung benötigt, und handelt sich damit komplett neue Klassen von Problemen ein, die man vorher, mit nur einem Server, nicht hatte.
Wie regel ich auf welchen Server der User weitergeleitet wird?
Hängt davon ab, wie du die Server strukturiert hast. Und welche weitere Infrastruktur zum Einsatz kommt, um die IPs der Server z.B. via DNS bekannt zu machen, ggf. nur für eingeschränkte Bereiche des Netzes.
Wie handhabt man generell mehrere Server im Ausland?
Teilen sich alle eine Datenbank oder muss ich jeden Schreibquery x (x=Anzahl der Server) fach ausführen?Die Idee, mehrere Datacenter auf der Welt zu verteilen (und ein einzelner Server ist nunmal der Anfang eines Datacenters), ist verhältnismäßig aufwendig, wenn der Datenbestand der Center überall identisch sein soll.
Geh mal davon aus, dass dein gesamtes derzeitiges Setup, mit RAM-Caching und Zugriffszeiten im Mikrosekundenbereich, komplett vor die Hunde geht, wenn es durch langsame Netzwerkverbindungen total ausgebremst wird. Nur so als Idee: Ein Datenpaket aus den USA nach Deutschland zu bekommen, und wieder zurück, verbraucht rein an Transferzeit sowas um die 100 Millisekunden - das ist also mehr als das 100.000 fache eines Cache-Zugriffs.
Sprich: Du willst die Datenbank definitiv so lokal haben, wie möglich. Wenn's geht, auf derselben Maschine. Wenns notwendig wird, auf einer zweiten Maschine, die über schnellstmögliches LAN angebunden ist. Irgendeine lahme Connection rund um den Erdball ist definitiv keine gute Idee.
Wenn die Leute bieten dann kommt es in den letzten Sekunden zu 2000 Lese/Schreibzugriffe / Sekunde. Wenn ich diese Auktion also in mehreren Ländern anbieten möchte, wie kann ich dann die Performance gewährleisten?
Trennen.
User in den USA sind ausschließlich auf dem Texas-Server, und sehen nur das, was sich da drauf befindet. Wer unbedingt aus Deutschland dorthin bieten will, hat halt die Ping-Zeiten auszuhalten. Umgekehrt genauso. Und daraus ergibt sich dann irgendwie auch, auf welchem Server der User sich einloggt. Die Userdatenbank zwischen allen Servern zu sharen, bzw. jeweils eine lokale Kopie zu verteilen, sollte nicht so sehr das Problem sein. Wenn es überhaupt notwendig sein sollte. Die User-ID ließe sich ja beispielsweise passend partitionieren.
- Sven Rautenberg
-
User in den USA sind ausschließlich auf dem Texas-Server, und sehen nur das, was sich da drauf befindet. Wer unbedingt aus Deutschland dorthin bieten will, hat halt die Ping-Zeiten auszuhalten. Umgekehrt genauso. Und daraus ergibt sich dann irgendwie auch, auf welchem Server der User sich einloggt. Die Userdatenbank zwischen allen Servern zu sharen, bzw. jeweils eine lokale Kopie zu verteilen, sollte nicht so sehr das Problem sein. Wenn es überhaupt notwendig sein sollte. Die User-ID ließe sich ja beispielsweise passend partitionieren.
Hi.
Ich würde es jetzt so machen:
3 Server.
1x Texas, 1x HongKong, 1x UK
Dort steht jeweils ein Rechenzentrum von Rackspace.Auf allen 3 Server sind die PHP-Files, ebenfalls CSS, JS, IMGs, HTML, TXTs.
Auf allen Servern ist folgendes installiert:
Squid (Reverse Proxy)
Apache2 (für die PHP-Files)
nginx (für die statischen Dateien)
PHP 5.3 + APCNur auf einem Server ist zusätzlich die Datenbank + memcached installiert. Dort greife ich entweder auf PGSQl zurück oder auf Cassandra. Letzteres ist denke ich deutlich schneller.
Ist das System so möglich? Ich möchte davor nen LoadBalance schalten welcher dann den nächsten Server raussucht und von dort die Dateien liefert.
Die Auktionen würden natürlich nur über den mit der Datenbank und memcached laufen.
Worauf sollte ich achten wenn ich die Webapp in PHP code. Muss ich auf irgendwas Rücksicht nehmen wenn alle DB-Anfragen über einen anderen Server kommen?Lässt sich das System noch optimieren?
Lg, Expandeur
-
Moin!
Ich würde es jetzt so machen:
3 Server.
1x Texas, 1x HongKong, 1x UK
Dort steht jeweils ein Rechenzentrum von Rackspace.Naja, ist dein Geld.
Nur auf einem Server ist zusätzlich die Datenbank + memcached installiert. Dort greife ich entweder auf PGSQl zurück oder auf Cassandra. Letzteres ist denke ich deutlich schneller.
Fail Nummer 1: Die Datenbank ist weit von zwei Servern weg. Das sorgt für lange Wartezeiten. Und Memcached ist auch weit von zwei Servern weg, das sorgt ebenfalls für lange Wartezeiten.
Ist das System so möglich? Ich möchte davor nen LoadBalance schalten welcher dann den nächsten Server raussucht und von dort die Dateien liefert.
Fail Nummer 2: Ein Loadbalancer sitzt vor einer Gruppe von Webservern, misst deren Auslastung und verteilt hereinkommende Requests gleichmäßig. Es hat absolut keinen Sinn, in UK einen Loadbalancer hinzustellen, zu dem die gesamte Welt connected, um dann den Loadbalancer feststellen zu lassen, dass er zwei Drittel der Requests wieder nach Texas und Hongkong weiterleiten muss.
Sprich: Ein Loadbalancer hilft nur, wenn die Webserver lokal sind. Mit deinem auf die Welt verteilten Setup willst du keinen Request, der bei einem Server ankommt, intern weiterleiten, sondern direkt abarbeiten.
Dein Konzept erlaubt kein Loadbalancing zwischen den drei Serverstandorten.
Außerdem ist Loadbalancing eine Methode zur Gewährleistung von Hochverfügbarkeit. Bedeutet: Man setzt nicht EINEN Loadbalancer ein, denn wenn der ausfällt, ist die Site komplett down, sondern man hat mindestens ZWEI.
Die Auktionen würden natürlich nur über den mit der Datenbank und memcached laufen.
Wozu dann die sinnlosen zwei anderen Server auf der Welt? Du handelst dir damit mehr Probleme ein, als dass du sie löst.
Worauf sollte ich achten wenn ich die Webapp in PHP code. Muss ich auf irgendwas Rücksicht nehmen wenn alle DB-Anfragen über einen anderen Server kommen?
Klar musst du was beachten: Dass deine Datenbankabfragen nicht in einigen Mikrosekunden aus dem lokalen Cache beantwortet wird, sondern dass du pro DB-Abfrage mindestens 100 Millisekunden wartest, weil die Datenpakete rund um die Welt geschickt werden. Sprich: Es ist - außer in einem Skript wird mal keine Datenbank benutzt - absolut irrelevant, ob der Browser des Users sich direkt mit dem weit entfernten DB-Zentralserver verbindet, oder ob er sich mit dem dichter lokalisierten Server verbindet, welcher sich seinerseits mit dem weit entfernten DB-Zentralserver verbindet. Im Gegenteil: Die zweite Variante wird vermutlich für einen größeren Teil der User sogar der noch deutlich langsamere sein, weil diese zwei Connections insgesamt einen Umweg darstellen, der länger braucht, als der eine, direkte Weg.
Nur mal so als Rechenexempel: Ich hab von mir (Deutschland) via DSL eine Ping-Zeit von 45 Millisekunden zum SELFHTML-Server im deutschen Rechenzentrum. Zu Servern in den USA beträgt die Zeit 150 Millisekunden von mir, und 140 Millisekunden vom SELFHTML-Server.
Wenn jetzt ein Konstrukt aus Server und entferner Datenbank nur einen einzigen Roundtrip machen muss, dann bedeutet das:
Kontaktiere ich direkt den Servern in den USA, verbraucht das 150 Millisekunden, gehen ich über die Zwischenstation, habe ich die Summe aus beiden Einzelstrecken: 140 + 45 = 185 Millisekunden.
Und hier geht's erstmal nur um die Latenzzeiten eines Requests. Die Lage wird natürlich noch schlimmer, wenn zu beachten ist, dass der direkte Query zum entfernten Server mehr oder weniger ohne große Latenzen direkt die Anfrage bearbeitet, insbesondere die Datenbank direkt zur Verfügung hat, während die Methode mit entfernter Datenbank mindestens ZWEIMAL die Latenzzeit zwischen Web- und DB-Server erfordert: Einmal für den Aufbau der DB-Connection (ein Handshake braucht 140 Millisekunden), und dann nochmal zum Hin- und Hersenden eines Requests (erneute 140 Millisekunden). Die Zeit der Datenbank, den Query zu parsen, die Daten zu finden und zurückzusenden, ist in beiden Fällen identisch und braucht daher nicht gesondert betrachtet zu werden.
Schon sind wir bei der Direktverbindung bei einer Latenz von weiterhin nur 150 Millisekunden, bei deinem Verteilungs-Konstrukt addiert es sich aber auf 325 Millisekunden - mehr als doppelt soviel Zeit fur eine Aktion. Das ist schon eine Drittel-Sekunde, die da draufgeht.
Lässt sich das System noch optimieren?
Klar: Überlass die überflüssige Verteilung der Server über den Erdball jemandem, der sich mit sowas auskennt. Alle wichtigen Webauftritte mit Hochlastsituationen nutzen irgendeine Art von lokaler Distribution ihres Webangebotes - für sowas gibts Dienstleister wie Akamai - WENN denn tatsächlich irgendwann der entsprechende Bedarf nach deiner Website besteht.
Im Moment passt der Auftritt offenbar ja noch locker auf einen einzelnen Server. Es erscheint absolut blödsinnig, sich in dieser Situation die Probleme eines auf der Welt verteilten Serverparks ans Bein binden zu wollen. Das ist den fünften Schritt vor dem ersten tun. Schritt eins wäre vermutlich, tatsächliche Lastprobleme abzufangen durch mehr Serverkapazität in dem einen Rechenzentrum - eventuell, indem die Datenbank einen eigenen Server kriegt. Schritt zwei wäre, Redundanz und Ausfallsicherheit durch Load-Balancing hinzukriegen. Sowohl für die Web- als auch die Datenbankserver, je nach Bedarf.
Und wenn das Projekt dann immer noch weiter wächst, wäre Schritt 3, sich einen kompetenten DB-Administrator ins Boot zu holen, der die Lastprobleme der Datenbankserver durch geeignete Maßnahmen entschärft.
Die Wahl deines Nicknames legt allerdings nahe zu glauben, dass es hier weniger um die Lösung eines technischen Problems, denn vielmehr um die Schaffung eines möglichst protzenden Setups geht. Kannst du natürlich so machen.
- Sven Rautenberg
-
-