Sequoia / Continuent Erfahrungen

Da ich mich in letzter Zeit sehr intensiv mit dem Thema MySQL Clustering mit Continuent bzw. Sequoia beschäftigt habe, werde ich hier mal eine Zusammenfassung meiner Arbeit und Tests bereitstellen, da es sonst im Web nahezu keine Erfahrungsberichte oder ähnliches gibt.

Was ist Sequoia / Continuent

Continuent bietet ein skalierbares Cluster für Datenbankserver, egal welcher Art. Einzige Vorgabe ist, dass ein JDBC Treiber vorhanden sein muss. Diesen findet man bei fast allen Datenbankservern, wie MySQL, MSSQL,…

Auf der Webseite wird dieses Cluster als Allheilmittel verkauft, das sowohl alle Skalierungsprobleme, als auch Hochverfügbarkeits-Probleme löst.

Was ist der Unterschied zwischen Continuent und Sequoia

Der einzige Unterschied ist, dass Continuent ein umfangreiches Supportpaket dabei hat, was Sequoia nicht hat, da es Opensource ist. Die Supportpakete sind so viel ich gesehen und gehört habe sehr teuer.

Allgemeines zu Sequoia

Das Cluster soll dazu dienen sowohl Schreibzugriffe, als auch Lesezugriffe auf mehrere Server aufzuteilen. Lesezugriffe sind ja gar nicht das Problem, das Problem – und das weiss jeder Admin der sich damit befasst hat – sind die Schreibzugriffe. Man greift auf das Sequoia Cluster zu und schreibt seine Queries (z.B. INSERT INTO table (testrow1, testrow2) VALUES (‘test1’, ‘test2’ ) ). Sequoia teilt diese so auf, dass diese a) auf jedem Node vorhanden sind und b) so geschrieben werden, dass man nicht in die Quere mit irgendwelchen AUTO-INCREMENT Werte kommt.

Soweit klingt das super und natürlich für jeden Administrator interessant.

Wie ist der Ablauf?

a) Man stellt den Query an den Controller – an eine virtuelle Datenbank.

b) Der Controller leitet diesen Request an das jeweilige Node weiter.

c) Ist ein Node nicht erreichbar, wird der Request nicht weitergeleitet.

d) Man bekommt ein Ergebnis zurückgeliefert und der Query ist abgeschlossen.

Die Datenbankserver im Hintergrund

Mit Sequoia kann man seitens der Backendinfrastruktur sämtliche Perversitäten und Vorlieben ausleben. Man kann als ersten Datenbankserver einen MySQL hinstellen, als zweiten einen PostgreSQL und als dritten einen Oracle Server. Das funktioniert wunderbar. Ob es Sinn macht sei dahingestellt, aber es geht.

Erstellen von Datenbanken

Beim Controller vom Sequoia muss eine virtuelle Datenbank zum Beispiel die myDB angelegt werden. Auf jedem weiteren Datenbanknode (Datenbankserver 1, 2 und 3) muss auch eine Datenbank angelegt werden. Da reicht einfaches CREATE DATABASE und man hat die gewünschte Datenbank.

Starten des Controllers und man kann normal auf seine virtuelle Datenbank zugreifen.

Also mit:

USER myDB;

SELECT * FROM table;

Ganz simple.

Schreiben von Datenbankeinträgen (INSERTs, UPDATEs)

Nun kommt das Enttäuschende. Wird nun ein INSERT getätigt, so wird dieser INSERT an jeden einzelnen Backend Server geleitet. Fällt euch was auf? Genau – wenn ich viele Schreibzugriffe habe, dann ist mein Cluster so stark wie das schwächste Glied und auch wenn das schwächste Glied ein Dual Quad Core Xeon mit 16GB Ram oder noch viel besser ist, bin ich irgendwann am Ende. Sprich es gibt keine Endlosskalierung der Schreibzugriffe.

Verwendung von InnoDB, MyISAM,…

Nachdem mein ganzes Cluster eigentlich nur aus einem intelligenten Skript besteht, welches die SQL Queries wie ein Proxy weiterleitet, kann ich im Hintergrund InnoDB, MyISAM, oder egal was sonst noch verwenden. Ich kann die Engines sogar mischen. Es ist nur ein Proxy.

Zugriff auf die virtuelle Datenbank

Lange Zeit hatte ich die Befürchtung, dass ich meine Applikationen auf einen JDBC Treiber umbauen muss, was natürlich für Hosting oder herkömmliche Applikationen total uninteressant wäre. Mit Myosotis bringt die Community einen Connector, der vor den Controller geschaltet wird, dass man herkömmlich über seinen Port 3306 zugreifen kann.

Anlegen von virtuellen Datenbanken

Das Gesamte System besteht aus virtuellen Datenbanken. Ein CREATE DATABASE ist nicht vorhanden. Um eine Datenbank anzulegen muss man die Konfiguriationsdatei vom Controller editieren und dort die Datenbank eintrage und den Controller neu starten.

Praxitext mit diversen Skripten

phpMyAdmin: Loggt man sich mit phpMyAdmin ein, so erscheint nicht die virtuelle Datenbank, sondern die Backend Datenbank. Von der virtuellen Datenbank keine Spur. Will man auf die anderen Datenbanken zugreifen, die am Backend Server liegen, erhält man keinen Zugriff. Ein SHOW PROCESSLIST bringt nur die Last der einzelnen Backend Server, es gibt keine wirklichen Analysefunktionen direkt über die SQL Befehle und ein SHOW DATABASES zeigt keine virtuelle Datenbank.

phpBB3: Dieses Board bringt ein umfangreiches Installationsskript und vor allem viele Datenbanktests mit. Es ist recht komplex aufgebaut, hin und wieder auch etwas langsam, eignet sich aber als nettes Testskript. Eine Installation verlief nicht wirklich erfolgreich, da offenbar Queries fehlgeschlagen sind, die aber auf den normalen Datenbankservern sehrwohl funktioniert haben. Weiters ist mir aufgefallen, dass trotz abgeschalteten Loggings das System sehr langsam war. Als phpMyAdmin die SQL Daten eingespielt hat, dauerte dies ca. 30 Sekunden! Man muss bedenken, dass Controller, MySQL Connector und beide Datenbanken auf ein und dem selben System lagen. Der Server lief auf volle 100% (P4 mit 2,4 GHz, 1 GB RAM). Freilich der Server ist kein starkes Ding, dennoch hätte es aber schneller gehen müssen.

WordPress: Die WordPress Installation ist sehr simple (datenbanktechnisch gesehen) und war auch erfolgreich, auch wenn Sequoia ein paar Fehler auswarf, offenbar funktionierte aber alles.

Fazit

Im Allgemeinen war meine Euphorie sehr schnell vorbei. Das System ist langsam, fehleranfällig und bringt weniger Vorteile als ein MySQL Proxy (der mir wenigstens die Readonly-Slaves bei einem Schreibzugriff nicht belastet bzw. nicht so stark, denn die Replikation arbeitet ein wenig anders). Ich habe sehr schnell aufgehört zu testen, nachdem sich das System sehr schnell aus unbrauchbar herausgestellt hat.

Interessant ist das System sicherlich für die ein oder andere Hochverfügbarkeitsanwendung oder bietet sich vielleicht als etwas schwächere Variante für einen MySQL Proxy an, wenn man viele Lesezugriffe hat.

Ich muss sagen, dass ich die Entwicklung weiter verfolgen werde, aber aktuell ist die Software noch lange nicht so weit, um es beispielsweise mit einem Orcale Cluster aufzunehmen.

, , , , , ,

6 thoughts on “Sequoia / Continuent Erfahrungen

  • Brati says:

    Wie ist denn das bei MySQLs eigenem Cluster-Management? Gibt es da auch diese großen Probleme? Ich wollte mich damit eigentlich mal beschäftigen, aber mein Xen will irgendwie keine weiteren virtuellen Server starten, obwohl noch RAM frei ist.

    Ich habe mir den Text auf der Webseite [1] noch nicht ganz durchgelesen, bin aber ein wenig verwirrt:
    “If you are OK to here it is time to test mysql. On either server mysql1 or mysql2 enter the following commands: Note that we have no root password yet.
    [CREATE TABLE …]”
    Das lässt mich irgendwie in dem Glauben, dass man die Server trotzdem noch irgendwie selbst verwalten muss, was ich mir aber nicht vorstellen kann.

    “In the case that [the management server] is not running, “split-brain” scenario will occure.”
    Wenn ich split-brain richtig interpretiere, dann steht hier ja, dass der Management-Server eben die Aufgabe übernimmt, dass die Daten auf beiden Servern gleich gespeichert werden. So habe ich es eigentlich auch erwartet.

    Naja, vielleicht weißt du ja etwas zur MySQL-eigenen Lösung. Das würde mich interessieren, inwiefern die da bessere oder schlechtere Lösungen liefert.

    Und wie sieht es bei Oracle aus? Die sind doch Führer bei professionellen DB-Systemen. Bieten die da keine gute Umsetzung an?

    Und des Interesse wegen noch: Wie würde man das denn besser machen? Wenn auf Server1 jemand einen Eintrag schreibt und gleichzeitig auf Server2 ein anderer Eintrag eingetragen wird, das Clustering-System aber nicht darauf wartet, dass Server2 auch den Eintrag von Server1 erhalten wird, dann hat man ja zwei Eintrage auf der gleichen ID (auto increment).

    Sähe also so aus:
    “Hallo mein Freund” => Server1 => ID 15
    “Dann mal los” => Server2 => ID 15
    Synchronisation im Hintergrund
    Server1 => “Hallo mein Freund” => Server2 => ID 16
    INKONSISTENZ!

    Das könnte man nun vielleicht irgendwie bereinigen lassen, aber wenn nun gleichzeitig noch jemand die Seite aufruft, dann kriegt er vielleicht den falschen Eintrag zugesendet.

    Ich verstehe ja das Problem: Zum Schreiben kann man gleich einfach EINEN Server hinstellen, wenn es eh immer so lange dauert, wie der langsamste braucht, aber: Wie anders umsetzen?

    So, mal ein langer und hoffentlich qualitativ halbwegs akzeptabler Kommentar meinerseits.

    Grüße
    Stefan

    http://dev.mysql.com/tech-resources/articles/mysql-cluster-for-two-servers.html

  • gutsyheron says:

    Ich habe schon vor einem Jahr aufgehört nach einer Lösung zu suchen, nachdem ich 2 Monate vergeblich versucht habe einen Cluster auf zu ziehen.

    Meine Lösung war dann, das die User einfach hardgecoded auf die verschiedenen Server umgeleitet wurden. User 1 – 1000 Server1 1000 – 2000 Server2.

    Ist vielleicht nicht die elleganteste Lösung aber relative schnell umsetzbar und Hardware ist ja extrem billig geworden.

    Kommen neue User -> einfach ein Kästen hinzustellen.

    Das richtige Clustern von LAMP Anwendungen ist ein wenig der Heilige Gral der Internet Applications. Digg.com hat lange vergeblich nach jemanden gesucht, der ihre Seite betreut und wenn sie jemanden gefunden haben war der sehr sehr teuer.

  • aw says:

    Also das ganze ist sowieso nicht leicht.
    Webapplikationen mit Storage, skalierbar, etc. aufzubauen ist gar kein Problem, das funktioniert wunderbar.
    Spannend wird es dann nur bei der Datenbank.

    Was sehr gut funktioniert und was wir nun aufbauen werden ist ein MySQL Read/Write Cluster. Das Read/Write wird über den MySQL Proxy gesplittet. Je nach Anwendung reicht das aus. READs kann man sehr einfach loadbalancen, aber bei den Writes wirds schwierig, aber das ist dann über Methoden wie du es sagst, lösbar.

    lg

  • schoash says:

    Seit gestern ist Continuent auch open source.

  • georg says:

    > es gibt keine Endlosskalierung der Schreibzugriffe.
    Richtig; eine “Endlosskalierung der Schreibzugriffe” gibts in keiner einzigen DB-Cluster Lösung (Echtzeit wohlgemerkt).

    > Ein CREATE TABLE ist nicht vorhanden
    Falsch; über den uc/connector von Continuent kann man beliebig Tabellen anlegen / modifizieren.

    > als etwas schwächere Variante für einen MySQL Proxy an, wenn man viele Lesezugriffe hat.
    Falsch; der Vergleich mit MySQL Proxy geht sehr daneben; es geht hauptsaechlich um Hochverfügbarkeit, und in zweiter Linie um Skalierbarkeit. Einer der grossen Vorteile von Continuent ist der Multi-Master Setup, dessen Vorteile weder MySQL Proxy nich die klassischen Master-Slave Setups bieten können.

    > lange nicht so weit, um es beispielsweise mit einem Orcale Cluster aufzunehmen.
    Diese Aussage solltest Du in spaetestens 6 Monaten einem Review unterziehen.

  • aw says:

    Hallo Georg,

    bei Sequoia gibt es definitiv kein CREATE DATABASE. Hatte da leider falsch geschrieben. Bessere ich aus.

    Continuent ist meiner Meinung nach eher schlecht. Wirklichen Vorteil bringt es mir nicht. Wenn ich was hochverfügbares brauche, wie z.B. im Telefoniebereich oder ISP-Bereich, dann nehme ich ein NDB Cluster (wenn ich FULLTEXT brauche bringt mir das natürlich nichts mehr).
    Der MySQL Proxy ist dennoch primär dafür da, dass man READ Requests aufsplittet. Die Failover Funktion ist eher sekundär, aber dennoch wichtig.

    Die gesamte Thematik rund um MySQL beobachte ich natürlich weiter, mal schaun ob es bei Sequoia Neuerungen gibt. Bin gespannt, allerdings bin ich eher “hoffnungslos”. Das Lizenzgeld ist es allerdings nicht wert (auch wenn das nun nur noch “Support” ist).

Leave a Reply