Zwei Server besser ausnutzen

[Timm R. (Firma: privatfrickler.de) (treinisch)]

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

[Sheeva P. (sheevaplug)]

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!

[Timm R. (Firma: privatfrickler.de) (treinisch)]

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

[Sheeva P. (sheevaplug)]

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!