Hallo,
ich habe für einige Systeme zwei Server im Einsatz, ich würde sie als
Mittelklasse bezeichnen (3.6 GHz Xeon Quadcore mit 64 GB RAM). Der
Traffic ist auch eher so Mittelklasse, ich würde sagen, so rund 600k
Besucher im Jahr verteilt auf eine handvoll Domains.
Es gibt noch einen dritten, der aber von außen nicht zugänglich ist und
im Abstand von Minuten bis Stunden bestimmte Backups zieht.
Einer der beiden Server tut genau gar nichts. Nachts zieht er eine Kopie
vom anderen Server und führt einige Tests durch, das wars. Das dient
dazu, dass ich im K-Fall einfach diesen Server in Betrieb nehmen kann
und alles läuft problemlos weiter. Ein Totalausfall ist halt recht
ärgerlich und sehr teuer.
Das Setup läuft super und problemlos und ich benutze diesen zweiten
Server um Betriebssystem-Updates, Konfigurationsänderungen, Updates der
Applikationen, aber auch kleine Entwicklungen zu testen. Wenn ich was
vor die Wand fahre, kann ich in der Regel einfach warten und alles ist
wieder gut. Das ist schon sehr nett.
Eine Anwendung (Shop-System, php) würde ich allerdings gern noch ein
wenig beschleunigen und bevor ich rumexperimentiere, würde ich gern mal
eure Meinung zu zwei Szenarien hören: Ich nenne die beiden Server mal
Produktion und Replikat
Szenario 1: Ich ändere den DNS Eintrag für den Shop auf das Replikat,
dort läuft ein Lord-Balancer und leitet die Anfrage entweder auf den
Replikat-Server oder auf den Produktion-Server. Die Datenbank für das
Shopsystem ziehe ich vom Produktiv auf das Replikat um.
Ich denke, das müsste ein Gewinn sein, weil das Replikat halt nichts zu
tun hat und das MySQL wäre dann sogar exklusiv nur für das Shopsystem
zuständig.
In einem von zwei K-Fällen hätte ich keine Datenbank mehr, aber ich
hätte immer noch das minütliche Backup der Datenbank und die ist nicht
so groß, dass die Wiederherstellung ein Problem wäre.
Die beiden Server stehen nicht im selben Rechenzentrum und haben
untereinander eine 1gbit/s Verbindung.
Szenario 2:
Ich lasse alles wie es ist und ziehe die komplette Datenbank auf das
Replikat um. Ich hätte jetzt keine Dopplung der Datenbank mehr, aber das
kann ich verknusen, denn bei der Datenbank spielt die Musik eh beim
Backup.
Gibt es irgendwelche Hinweise, Ideen, Stolpersteine, wäre bei einem der
beiden Szenarien mit einer signifikanten Verbesserung zu rechnen?
Herzliche Grüße
Timm
Timm R. schrieb:> ich habe für einige Systeme zwei Server im Einsatz, ich würde sie als> Mittelklasse bezeichnen (3.6 GHz Xeon Quadcore mit 64 GB RAM). Der> Traffic ist auch eher so Mittelklasse, ich würde sagen, so rund 600k> Besucher im Jahr verteilt auf eine handvoll Domains.Räusper Eigentlich sind das schon ziemlich dicke Büchsen. Jede
einzelne davon müsste das bisschen Traffic auf der linken Arschbacke
absitzen...
> Eine Anwendung (Shop-System, php) würde ich allerdings gern noch ein> wenig beschleunigen und bevor ich rumexperimentiere, würde ich gern mal> eure Meinung zu zwei Szenarien hören: Ich nenne die beiden Server mal> Produktion und Replikat
Nenn' sie "Master" und "Slave", dann bist Du schonmal halbwegs im
Jargon.
> Szenario 1: Ich ändere den DNS Eintrag für den Shop auf das Replikat,> dort läuft ein Lord-Balancer und leitet die Anfrage entweder auf den> Replikat-Server oder auf den Produktion-Server. Die Datenbank für das> Shopsystem ziehe ich vom Produktiv auf das Replikat um.
Was Du Dir vorstellst, nennt sich "Hochverfügbarkeit" und war, wenn man
so sagen kann, eine der Königsdisziplinen im Admin-Business.
Den ersten Fehler machst Du schon mit Deinem Load-Balancer: es macht
nämlich keinen Sinn, den einen Single Point of Failure durch einen
anderen zu ersetzen. Entweder Du legst alles redundant aus, also auch
Deinen Load-Balancer, oder Du vergißt die Sache besser schnell wieder.
Denn mit einem HA-Setup führst Du eine nicht unwesentliche Komplexität
ein, und höhere Komplexität zieht eine höhere Fehlerwahrscheinlichkeit
nach sich. Außerdem steigt die Gesamt-Fehlerwahrscheinlichkeit: je mehr
Rechner beteiligt sind desto höher ist die Wahrscheinlichkeit, daß einer
davon ausfällt. Trotzdem verdoppelt sich die rechnerische Verfügbarkeit
Deines Dienstes, wenn Du es richtig machst...
Es ist auch nicht besonders sinnvoll, einen Fail- oder Switchover über
den DNS zu machen, das dauert wegen der TTL meistens zu lange.
Normalerweise macht man das so, daß man eine "virtuelle IP-Adresse" als
Ressource in den Cluster konfiguriert und beim Clusterschwenk nur diese
umzieht.
So viel nur auf die Schnelle, ich muß ins Bett -- Mittwoch wird deployt.
Wenn Du mehr über das Thema erfahren willst, gibt es bei O'Reilly ein
zwar schon etwas älteres, aber immer noch sehr gutes Buch namens
"Clusterbau: Hochverfügbarkeit mit Linux" von Michael Schwartzkopff, das
Dir den Kern der Angelegenheit nahebringen kann. Viel Spaß!
PS: Dein Setup kannst Du übrigens mal mit RasPis ausprobieren, einfach
mal den Strom, die SD-Karte oder das Ethernet-Kabel im laufenden Betrieb
ziehen oder einfach mal einen oder mehrere Prozesse mit SIGKILL
meucheln. Und hüte Dich vor dem Split-Brain -- das ist übrigens einer
der Gründe, warum es in der Regel keine gute Idee ist, Clusternodes in
verschiedenen Rechenzentren betreiben zu wollen!
Hallo Sheeva,
danke schonmal, da waren ein paar wertvolle Hinweise dabei. Ich denke,
ich werde den Plan aufgeben.
Um Hochverfügbarkeit geht es zwar bei der aktuellen Überlegung
eigentlich nicht, sondern nur um Geschwindigkeit, aber dss ändert ja
nichts.
Ich denke, ich werde besser statischen Content auf ein CDN auslagern,
das wird auch schon einiges bringen und erhöht die Komplexität praktisch
gar nicht.
Das mit der IP Nummer ist ein guter Hinweis! Das kann ich so machen, wie
du sagst, werde nachts mal testen.
Viele liebe Grüße
Timm
Timm R. schrieb:> danke schonmal, da waren ein paar wertvolle Hinweise dabei. Ich denke,> ich werde den Plan aufgeben.
Schade... da kann man viel bei lernen. ;-)
> Um Hochverfügbarkeit geht es zwar bei der aktuellen Überlegung> eigentlich nicht, sondern nur um Geschwindigkeit, aber dss ändert ja> nichts.
Nun, ein Teil der Überlegungen, die Du angestellt hast -- zum Beispiel
die Übernahme eines Dienstes durch einen Slave, wenn der Master abraucht
-- war und ist der Kern von Hochverfügbarkeit bzw. High Availability
(HA). Es geht darum, eventuelle Ausfallzeiten durch Fehler (Failover)
und / oder Updates (Switchover) zu minimieren und vor allem den Failover
zu automatisieren, so daß kein Admin händisch eingreifen musste.
In den Anfangszeiten haben wir das meistens so gemacht, daß die
Ressourcen des Clusters auf dem (oder den) Master(n) liefen und von
Slave(s) überwacht wurden, die sie dann im Falle eines Ausfalls
übernommen haben. Irgendwann fiel den Betriebswirten auf, daß sie ja
dann zwei Maschinen brauchten, von denen die eine praktisch immer nur
gelangweilt hat.
Also kamen die Herren Betriebswirte auf eine geniale Idee: die Koppelung
der HA mit der Verteilung von Last, so daß beide Maschinen einen Teil
der Last tragen und sich gegenseitig überwachen sollten. Dumm nur, daß
jede Hälfte des Clusters trotzdem so ausgelegt werden muß, daß er bei
einem Fail- oder Switchover die Gesamtlast alleine tragen kann...
Heute werden HA-Setups, bei denen es im Wesentlichen um Redundanz geht,
oft auf die Applikationsebene verlagert und mit Technologien wie dem
Sharding und einer Lastverteilung kombiniert, die aus dem
High-Performance-Umfeld stammen. Das ist wesentlich effizienter,
erfordert allerdings spezielle, darauf ausgelegte Applikationen und
Architekturen: so sind die heutigen "elastischen" Cloud- und
Microservice-Architekturen entstanden.
Ich persönlich kann Dir da nur zwei Ratschläge geben. Erstens: wenn Du
bei Deinen herkömmlichen Hard- und Softwarearchitekturen bleiben und
nicht auf eine moderne, inhärent clusterfähiger Software wechseln
willst, solltest Du Deine Betrachtungen hinsichtlich Performance und
Verfügbarkeit voneinander trennen und sie für Dich priorisieren.
Zweitens beginnt eine seriöse Performanceoptimierung immer damit, zuerst
die Flaschenhälse zu identifizieren, damit Du dort dann gezielt ansetzen
kannst. Dabei helfen unter UNIXoiden Systemen wie Linux zum Beispiel die
Pakete sysstat und acct. Das Paket sysstat enthält den System Activity
Reporter sar(1), der periodisch die Performancecounter des Kernels liest
und für eine spätere Analyse abspeichert, sowie Programme wie iostat(1),
vmstat(1), pidstat(1) und mpstat(1), mit dem sich bestimmte Ressourcen
und ihre Auslastung gezielt beobachten lassen. Das Paket acct richtet
dagegen ein Prozeß-Accounting ein, mit dessen Hilfe sich herausfinden
läßt, welche Benutzer und Programme die Ressourcen beanspruchen.
Naja, der Opa erzählt vom Krieg... ;-) Im Ernst: leider sind beide
Themen zu umfangreich und komplex, um sie im Rahmen eines Forenbeitrags
auch nur oberflächlich zu behandeln, deswegen sind meine Einlassungen
hierzu in geradezu unzulässiger Weise verkürzt. Aber ganz unabhängig
davon, welche Werkzeuge Du benutzt, oder ob Du die Performance, die
Verfügbarkeit oder die Resilienz (Widerstandsfähigkeit) optimieren
willst: Dein wichtigstes Tool befindet sich dabei immer zwischen Deinen
Ohren. Nutze es! ;-)
> Ich denke, ich werde besser statischen Content auf ein CDN auslagern,> das wird auch schon einiges bringen und erhöht die Komplexität praktisch> gar nicht.
Hm, das hängt davon ab. Ein CDN bedingt wieder zusätzlichen Netzwerk-
und DNS-Overhead. So etwas lohnt sich üblicherweise nur dann, wenn man
seine Netzwerkanbindung saturiert -- also bei sehr vielen und / oder
sehr großen Inhalten, wie zum Beispiel Videos. Für die meisten Shops --
zumal, wenn deren Traffic im überschaubaren Rahmen ist -- lohnt sich das
oft nicht, oder kann sich sogar kontraproduktiv auswirken.
Häufig ist es sinnvoller, einmal auf die Applikationen zu schauen: eine
Datenbank kann mit entsprechenden Indizes um mehrere Faktoren schneller
werden, Webseiten können beschleunigt werden, indem ihre Artefakte wie
Javascript- und CSS-Dateien zusammengefaßt und komprimiert werden. Was
genau der Königsweg ist, ist von Fall zu Fall unterschiedlich und kann
ausschließlich durch Messung und Analyse bestimmt werden.
> Das mit der IP Nummer ist ein guter Hinweis! Das kann ich so machen, wie> du sagst, werde nachts mal testen.
Viel Erfolg!
