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
:
Bearbeitet durch User
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!
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.