Hallo ich bin neu bei Marklogic und Apache. Mir wurde die Aufgabe gestellt, Apache als Loadbalancer für unseren Marklogic Cluster von 3 Maschinen zu verwenden. Marklogic-Cluster läuft derzeit auf Linux-Servern.Wie kann ich Apache verwenden, um Balance zu laden Marklogic Cluster
Wie können wir das erreichen? Alle diesbezüglichen Informationen wären hilfreich.
Sie könnten mod_proxy_balancer verwenden. Wie Sie es konfigurieren, hängt davon ab, welchen MarkLogic-Client Sie verwenden möchten. Wenn Sie die Java Client API verwenden möchten, befolgen Sie bitte das zweite Beispiel here, damit der Apache Stickiness-Cookies generieren kann. Wenn Sie XCC verwenden möchten, konfigurieren Sie es bitte so, dass es den ML-Server-generierten oder Backend-generierten "SessionID" cookie verwendet.
Der Unterschied hier ist, dass XCC Sitzungen verwendet, während die Java-Client-API auf der REST-API aufbaut, die zustandslos ist, so dass es keine Sitzungen gibt. In der Java-Client-API wird jedoch bei Verwendung von Transaktionen mit mehreren Anforderungen für die Dauer dieser Transaktion ein Status festgelegt, sodass der Load Balancer eine Methode zum Weiterleiten von Anforderungen während dieser Transaktion an den richtigen Knoten im MarkLogic-Cluster benötigt. Der Stickiness-Cookie wird von der Java-Client-API bei jeder Anfrage, die eine Transaktion verwendet, erneut gesendet, sodass der Load Balancer diese Klebrigkeit für Anforderungen beibehalten kann, die sich auf diese Transaktion beziehen.
Wie immer testen Sie Ihre Konfiguration, um sicherzustellen, dass Sie alles richtig gemacht haben. Apache-Plugins richtig zu konfigurieren ist eine fortgeschrittene Fähigkeit. Da Sie neu bei Apache sind, sollten Sie mit einem HTTP-Überwachungstool wie WireShark den HTTP-Datenverkehr von Ihrer Anwendung zu MarkLogic Server überprüfen, um sicherzustellen, dass die Daten zum richtigen Knoten im Cluster gelangen wie erwartet.
Beachten Sie, dass selbst mit den Client-APIs (Java, Node.js) auf der Ebene der Sprach-API nicht immer offensichtlich oder explizit ist, was zur Erstellung einer Sitzung führen könnte. Das explizite Erstellen von Multi-Statement-Transaktionen wird dies definitiv, aber auch andere Operationen können dies tun. Wenn Sie dieselbe Verbindung für die Benutzeroberfläche (Browser) und API (REST oder XCC) verwenden, führt die Browser-App wahrscheinlich Dinge aus, die den Sitzungsstatus erstellen.
Die sicherste, aber am wenigsten flexible Konfiguration ist "TCP Session Affinity". Wenn sie unterstützt werden, werden sie die meisten Probleme im Zusammenhang mit dem Lastenausgleich beseitigen. Cookie Session Affinity ist darauf angewiesen, dass der Load Balencer das richtige Cookie verwendet. Nicht jeder Code ist gleich. Ich hatte Fälle, in denen der Load Balancer den bereitgestellten Cookie nicht immer verwendete. Durch Ändern der Konfiguration in "Load Balancer bereitgestellte Cookie-Affinität" wurde das behoben.
Dies ist nicht erforderlich, wenn alle Kommunikationen in der TCP-Schicht, der HTTP-Schicht und der App-Schicht zustandslos sind. Der spätere kann vom Server nicht abgeleitet werden. Eine andere Möglichkeit ist, ob Ihre App oder Middle Tier mit anderen Apps oder derselben App co-resident ist, die sich mit demselben Load Balancer und Port verbindet. Das kann schwierig sein, um sicherzustellen, dass es keine "gekreuzten Drähte" gibt. Wenn ML eine Anfrage erhält, verbindet sie ihre Identität mit der Client-IP und dem Port. Auch ohne Load Balencer implementieren die meisten modernen HTTP- und TCP-Client-Bibliotheken das Socket-Caching. Ein großartiger Erfolg, aber eine versteckte Quelle subtiler zufälliger schwerwiegender Fehler, wenn die Bibliothek oder App "Cookie-Krüge" (nicht unconnon) teilt. Ein TCP- und Cookie-Jar-Cache, der von verschiedenen Anwendungskontexten verwendet wird, kann dazu führen, dass Statusinformationen von einer nicht verwandten App in demselben Prozess an einen anderen gesendet werden. Meistens sind dies App-Server der mittleren Ebene, die einfach Anfragen von der ersten Stufe ohne Domänenwissen weiterleiten können, vorausgesetzt, dass sie sich auf die Low-Level-TCP-Bibliotheken verlassen, um "das Richtige zu tun" ... Sie tun das Richtige - für den Anwendungsfall, den die Bibliotheksprogrammierer im Sinn hatten - gehen Sie nicht davon aus, dass Ihr Fall derjenige ist, den die Bibliotheksautoren angenommen haben.Die Symptome tendieren dazu, sehr selten zu sein, aber katastrophale Probleme mit Transaktionsfehlern und möglicherweise Datenbeschädigungen und Sicherheitsproblemen (auf einer Anwendungsebene), weil der Server den Unterschied zwischen zwei Verbindungen von der gleichen mittleren Schicht nicht unterscheiden kann.
Manchmal ist es eine bessere Strategie, das Gleichgewicht zwischen der ersten und der mittleren Schicht zu laden und direkt von der mittleren Schicht mit MarkLogic zu verbinden. Insbesondere, wenn die Zwischenspeicherung im Load Balancer erfolgt. Es ist häufiger, dass Caching zwischen der mittleren Schicht und dem Client, dann der mittleren Schicht und dem Server nützlich ist. Dies ist auch analog zur klassischen 3-Tier-Architektur, die mit RDBMS verwendet wird. Hier findet der Lastausgleich zwischen den Client- und Geschäftslogikebenen statt zwischen Geschäftslogik und Datenbank statt.
So hat es wirklich geholfen :-) –