Hallo allerseits,
ich programmiere gerade eine Datenbank-Lastige Web-Anwendung (LAMP) und habe mich in der letzten Zeit daher mit Optimierungs- und Skalierungs-Methoden beschäftigt.
Die Anwendung ist glücklicherweise überwiegend durch Read-Abfragen geprägt und es sind kurzfristig auch keine gigantischen Besucher-Zahlen zu erwarten. Dafür sollte die Anwendung aber eine robuste Verfügbarkeit aufweisen.
In manchen Bereichen der Anwendung werden pro Seitenaufruf mehrere hundert Queries erzeugt und der Seitenaufruf bzw. der Ajax-Request kann dann durchaus ein paar Sekunden dauern.
Nachdem ich nun viele Skalierungs-Modelle studiert habe, ist mein favorisiertes SetUp ein MariaDB GaleraCluster mit MaxScale als vorgeschaltetem Datenbank-Proxy mit Read/Write-Split.
Ich habe bei mir zu Hause sowohl den Cluster als auch den Proxy zu Testzwecken eingerichtet und soweit ich das beurteilen kann, funktioniert alles so wie erwartet. Den Haupt-Vorteil sehe ich darin, dass die Anwendung (basiert auf einem PHP-Framework) nur den Proxy sieht und der Cluster quasi verdeckt im Hintergrund lesend skaliert. Auf diese Weise sind zumindest keine Anpassungen am ORM notwendig, was je nach Framework und zur Verfügung stehenden CallBack-Möglichkeiten eine große Erleichterung bedeutet.
Leider kann ich das Setup primär aus zeitlichen Gründen nicht selber managen, sondern bin auf einen Hoster angewiesen. Insofern ist nahezu jedes SetUp mit ziemlich hohen Kosten verbunden und deshalb würde ich gerne nachfragen, wo Ihr Vor- und Nachteile seht oder praktische Erfahrungen gesammelt habt...
Auf der offiziellen Seite von GaleraCluster wird bei den "Configuration Tips" zwischen "Multi-Master Setup" und "Single Master Setup" unterschieden.
Ich habe das so verstanden, dass beim Multi-Master-SetUp die Wahrscheinlichkeit für Konflikte und den damit verbundenen RollBacks steigt.
Eigentlich bewirbt GaleraCluster das Feature Multi-Master jedoch sehr offensiv. Auf Applikationsebene scheint ja auch ohne Proxy kein Read/Write-Split mehr notwendig zu sein (ein Load-Balancing hingegen schon). Es wird aber auch explizit auf die möglichen Konflikte im Multi-Master-Betrieb hingewiesen. Im Prinzip verstehe ich das so, dass die Anwendung mit den neuen Herausforderungen des Multi-Master-SetUps zurecht kommen muss, die es vorher in der Einzel-Datenbank-Umgebung so nicht gab. Aus Sicht der Anwendung treten Konflikte nun möglicherweise häufiger oder in anderer Form auf als bei Single-Master-SetUps. Mir ist nur nicht ganz klar, was diese "certification conflicts" für die im Hintergrund arbeitende Web-Anwendung in der Praxis bedeuten. Wird bei certification conflicts zuvor im Hintergrund versucht den Konflikt mit einer kleinen Verzögerung alleine zu lösen, so dass bei vernünftig geplanten Kapazitäten dann doch nicht alles zurückgerollt werden muss, sondern die Konflikte bzw. das Monitoring selbiger erstmal nur die Notwendigkeit aufzeigt, die Cluster-Kapazitäten zu erhöhen?
Ich versuche also zwischen Multi-Master-Betrieb und Single-Master-Betrieb abzuwägen und frage mich auch, in wie weit ich Konflikte nicht nur erkennen können muss, sondern möglicherweise auch Strategien entwickeln muss, um nach einem RollBack die jeweilige Aktion benutzerfreundlich zum Abschluss zu bringen?
Ist bei MaxScale mit Read/Write-Split die WriteMaster-Node gleichzeitig auch noch für Read-Anfragen erreichbar? Ich frage mich hierbei, ob der MaxScale in so einem SetUp dynamisch dafür sorgt, dass der WriteMaster stets genügend Ressourcen für Write übrig hat, aber bei entsprechend geringer Auslastung auch noch für Read-Anfragen zur Verfügung steht? Wenn der WriteMaster nur schreibt, würden von den mindestens 3 notwendigen Nodes ja nur 2 für die Skalierung der Reads zur Verfügung stehen und wenn ein Knoten dann noch regelmäßig für BackUps in den Donor-Mode geschickt wird, zeitweise sogar nur eine einzige Node.
Ich habe gelesen, dass die bei MaxScale notwendige Logik für einen Read/Write-Split wohl einiges an CPU-Zeit kosten kann. In meinem Fall erwarte ich da durchaus Probleme, da pro Seitenaufruf wie gesagt mehrere hundert Abfragen stattfinden können, was mit steigender User-Anzahl dann viel Arbeit für MaxScale bedeuten könnte..die Frage ist aber auch, wie zuverlässig MaxScale in der Praxis läuft und ob man problemlos 2 Rechner mit je einem Trio aus Webserver, MaxScale und keepalived als HA-Lösung zusammenschalten kann, was dann mit 3 Cluster-Nodes insgesamt 5 Server ergibt.
Ich hoffe, das war nicht zu viel Text - eventuell kann ja jemand seine praktischen Erfahrungen mit GaleraCluster teilen.
Viele Grüße
Bimmel
ich programmiere gerade eine Datenbank-Lastige Web-Anwendung (LAMP) und habe mich in der letzten Zeit daher mit Optimierungs- und Skalierungs-Methoden beschäftigt.
Die Anwendung ist glücklicherweise überwiegend durch Read-Abfragen geprägt und es sind kurzfristig auch keine gigantischen Besucher-Zahlen zu erwarten. Dafür sollte die Anwendung aber eine robuste Verfügbarkeit aufweisen.
In manchen Bereichen der Anwendung werden pro Seitenaufruf mehrere hundert Queries erzeugt und der Seitenaufruf bzw. der Ajax-Request kann dann durchaus ein paar Sekunden dauern.
Nachdem ich nun viele Skalierungs-Modelle studiert habe, ist mein favorisiertes SetUp ein MariaDB GaleraCluster mit MaxScale als vorgeschaltetem Datenbank-Proxy mit Read/Write-Split.
Ich habe bei mir zu Hause sowohl den Cluster als auch den Proxy zu Testzwecken eingerichtet und soweit ich das beurteilen kann, funktioniert alles so wie erwartet. Den Haupt-Vorteil sehe ich darin, dass die Anwendung (basiert auf einem PHP-Framework) nur den Proxy sieht und der Cluster quasi verdeckt im Hintergrund lesend skaliert. Auf diese Weise sind zumindest keine Anpassungen am ORM notwendig, was je nach Framework und zur Verfügung stehenden CallBack-Möglichkeiten eine große Erleichterung bedeutet.
Leider kann ich das Setup primär aus zeitlichen Gründen nicht selber managen, sondern bin auf einen Hoster angewiesen. Insofern ist nahezu jedes SetUp mit ziemlich hohen Kosten verbunden und deshalb würde ich gerne nachfragen, wo Ihr Vor- und Nachteile seht oder praktische Erfahrungen gesammelt habt...
Auf der offiziellen Seite von GaleraCluster wird bei den "Configuration Tips" zwischen "Multi-Master Setup" und "Single Master Setup" unterschieden.
Ich habe das so verstanden, dass beim Multi-Master-SetUp die Wahrscheinlichkeit für Konflikte und den damit verbundenen RollBacks steigt.
Eigentlich bewirbt GaleraCluster das Feature Multi-Master jedoch sehr offensiv. Auf Applikationsebene scheint ja auch ohne Proxy kein Read/Write-Split mehr notwendig zu sein (ein Load-Balancing hingegen schon). Es wird aber auch explizit auf die möglichen Konflikte im Multi-Master-Betrieb hingewiesen. Im Prinzip verstehe ich das so, dass die Anwendung mit den neuen Herausforderungen des Multi-Master-SetUps zurecht kommen muss, die es vorher in der Einzel-Datenbank-Umgebung so nicht gab. Aus Sicht der Anwendung treten Konflikte nun möglicherweise häufiger oder in anderer Form auf als bei Single-Master-SetUps. Mir ist nur nicht ganz klar, was diese "certification conflicts" für die im Hintergrund arbeitende Web-Anwendung in der Praxis bedeuten. Wird bei certification conflicts zuvor im Hintergrund versucht den Konflikt mit einer kleinen Verzögerung alleine zu lösen, so dass bei vernünftig geplanten Kapazitäten dann doch nicht alles zurückgerollt werden muss, sondern die Konflikte bzw. das Monitoring selbiger erstmal nur die Notwendigkeit aufzeigt, die Cluster-Kapazitäten zu erhöhen?
Ich versuche also zwischen Multi-Master-Betrieb und Single-Master-Betrieb abzuwägen und frage mich auch, in wie weit ich Konflikte nicht nur erkennen können muss, sondern möglicherweise auch Strategien entwickeln muss, um nach einem RollBack die jeweilige Aktion benutzerfreundlich zum Abschluss zu bringen?
Ist bei MaxScale mit Read/Write-Split die WriteMaster-Node gleichzeitig auch noch für Read-Anfragen erreichbar? Ich frage mich hierbei, ob der MaxScale in so einem SetUp dynamisch dafür sorgt, dass der WriteMaster stets genügend Ressourcen für Write übrig hat, aber bei entsprechend geringer Auslastung auch noch für Read-Anfragen zur Verfügung steht? Wenn der WriteMaster nur schreibt, würden von den mindestens 3 notwendigen Nodes ja nur 2 für die Skalierung der Reads zur Verfügung stehen und wenn ein Knoten dann noch regelmäßig für BackUps in den Donor-Mode geschickt wird, zeitweise sogar nur eine einzige Node.
Ich habe gelesen, dass die bei MaxScale notwendige Logik für einen Read/Write-Split wohl einiges an CPU-Zeit kosten kann. In meinem Fall erwarte ich da durchaus Probleme, da pro Seitenaufruf wie gesagt mehrere hundert Abfragen stattfinden können, was mit steigender User-Anzahl dann viel Arbeit für MaxScale bedeuten könnte..die Frage ist aber auch, wie zuverlässig MaxScale in der Praxis läuft und ob man problemlos 2 Rechner mit je einem Trio aus Webserver, MaxScale und keepalived als HA-Lösung zusammenschalten kann, was dann mit 3 Cluster-Nodes insgesamt 5 Server ergibt.
Ich hoffe, das war nicht zu viel Text - eventuell kann ja jemand seine praktischen Erfahrungen mit GaleraCluster teilen.
Viele Grüße
Bimmel
