© HONGQI ZHANG, 123RF

Max Scale von Maria DB empfiehlt sich als schlauer Proxyserver für MySQL, der das Protokoll des Datenbankservers spricht. Neben solider Hochverfügbarkeit kündigt der Hersteller auch eine gute Skalierbarkeit an. Ist das Fakt oder leeres Gerede?

Viele MySQL-Datenbanken erweisen sich als neuralgische Komponenten. Daher sollen sie unbedingt hochverfügbar sein und gut in die Breite skalieren. Zur Erinnerung: Beim Skalieren in die Höhe bauen Admins eine einzelne große Hardware-Instanz weiter aus, auf der bestimmte Dienste laufen. Beim Skalieren in die Breite hingegen vergrößern sie die Anzahl der Instanzen, damit sich die Last auf mehr Schultern verteilt.

Nebenbei hat das Skalieren in die Breite auch klassische HA-Ansätze verdrängt, denn wenn es von einem Dienst etliche Instanzen gibt, ist der Ausfall einer einzelnen höchstens für die gerade offenen Verbindungen ein Problem – und das auch nur dann, wenn der Client nicht schlau genug für ein automatisches Reconnect ist.

Gerade bei Datenbanken ist das Skalieren in die Breite deutlich komplexer als bei anderen Diensten. Zwar gibt es auch bei MySQL zwei Ansätze, die reif für den produktiven Einsatz sind: MySQL im Master-Slave-Modus und Galera-Cluster mit Multi-Master-Funktionalität. Aber diese Lösungen machen allein noch nicht glücklich – die meisten MySQL-Clients sind nicht schlau genug für geclusterte MySQL-Installationen.

Unter einem Client versteht dieser Artikel eine beliebige Anwendung (CRM, Webshop, Dokumentenverwaltung und so weiter), die MySQL als Backend verwendet und daher gegenüber dem Datenbankserver als Client auftritt. Wer einem solchen Client fehlende Funktionen für Datenbankcluster nicht erst selbst hinzuprogrammieren will, der ist bei Max Scale gut aufgehoben.

Max Scale für Datenbanken

Max Scale kommt von Maria DB und feierte 2014 sein Debüt. Das Team rund um MySQL-Erfinder Monty Widenius verspricht, dass sich mit Max Scale MySQL-Datenbanken nicht nur hochverfügbar betreiben lassen, sondern dass auch Skalierbarkeitsprobleme ein Ende haben. Funktionell handelt es sich bei Max Scale um einen Proxyserver: Auf der einen Seite baut der Dienst im Hintergrund Verbindungen zu Backends der gleichen Datenbank auf, auf der anderen Seite wartet er auf eingehende Verbindungen von Clients.

Admins fühlen sich im ersten Augenblick vielleicht eher an einen Load Balancer erinnert. Von dem unterscheidet sich Max Scale jedoch in einem wichtigen Punkt: Max Scale tritt gegenüber dem Client selbst als Datenbank auf und beherrscht das MySQL-Protokoll. Es ist damit für den Client nicht nur transparent – das wäre auch der Load Balancer –, sondern kann die Anfragen der Clients auch analysieren und je nachdem zu bestimmten Servern leiten. Dabei lassen sich beispielsweise schreibende von lesenden Anfragen trennen.

Großer Bedarf, kleines Angebot

Die Trennung der Zugriffe ist ein häufiges Erfordernis in MySQL-Installationen mit mehreren Knoten. Die Gründe dafür sind vielfältig: Master-Slave-Installationen etwa haben nur einen Master, der schnelle Schreibzugriffe bieten soll. Die zahlenmäßig meist viel häufigeren Lesezugriffe sollen dann üblicherweise die Slaves abwickeln, von denen es entsprechend viele gibt.

Bei Galera-Clustern ergibt sich eine ähnliche Problematik: Theoretisch ist es hier zwar möglich, auf alle Backends gleichzeitig zu schreiben. In der Praxis hat sich dies jedoch als keine gute Idee herausgestellt. Mittlerweile bevorzugen viele Admins die Split-Konfiguration. Ein Grund dafür kann sein, dass die spezifische Applikation nicht darauf ausgelegt ist, im Hintergrund auf mehrere MySQL-Datenbanken zu schreiben.

Überhaupt scheitert der effiziente Betrieb eines MySQSL-Clusters meist am Unvermögen des Clients. Ganz gleich, wo man hinsieht – MySQL-Clients tun in aller Regel kaum mehr, als eine Datenbankverbindung herzustellen und dann eine Query abzusetzen.

Dabei sind praktisch alle gängigen Implementationen auf die Angabe eines einzelnen Hostnames für den MySQL-Server begrenzt, manchmal, weil bereits der Datenbank-Abstraktionslayer der zugrunde liegenden Skriptsprache nicht mit verteilten Datenbanken klarkommt. Hin und wieder stammen diese APIs auch aus einer Zeit, in der geclustertes MySQL noch gar nicht existierte.

Die meisten Admins umgehen das Problem, indem sie zwischen Client und Datenbank einen typischen Load Balancer wie HAproxy [1] oder eine F5-Appliance [2] installieren. Die lassen sich zwar für fast jeden Zweck missbrauchen, haben aber im Grunde alle das gleiche Problem: Weil sie kein MySQL sprechen, können sie sich vom MySQL-Cluster innerhalb ihrer Backends kein Bild machen. Sie sind darauf beschränkt, eingehende Verbindungen nach einem starren Schema an die Backends zu leiten.

Nicht viel mehr Erfolg verspricht die Idee, direkt in der Anwendung um die Unzulänglichkeiten des MySQL-Clients herumzuarbeiten: Das artet nämlich in der Regel in eine Code-Schlacht aus und führt vor allem zu Verwirrung. Lösungsansätze für das Problem gibt es mehrere, neben MySQL-Clustern etwa auch Scale ARC. Doch all diese Produkte leiden unter technisch mehr oder minder schlimmen Limitierungen, die den produktiven Einsatz unmöglich machen.

Max Scale als schlauer Proxy

An dieser Stelle setzt Max Scale an (Abbildung 1). Vereinfacht ausgedrückt: Max Scale versteht sich als besonders schlauer Client, der für weniger schlaue eine Art Brückenfunktion übernimmt. Gängige MySQL-APIs – wie etwa die von PHP oder C – verbinden sich mit Max Scale, das im Hintergrund die Verbindung zu Galera oder zu einem Master-Slave-MySQL aufbaut. Diese Funktion ist aber nicht das einzige herausragende Max-Scale-Feature.

Abbildung 1: Max Scale fungiert als Proxy zwischen Client und Datenbank und sorgt so für viel Zusatzfunktionalität.

Modulare Architektur

Bei Maria DB hat man offensichtlich lange über ein passendes Design für Max Scale nachgedacht, denn das Ergebnis überzeugt: Im Inneren basiert Max Scale auf einer durchgängig modularen Architektur. Jener Teil, der Ports zur Außenwelt öffnet und für Clients zur Verfügung steht, ist kaum mehr als ein Listener auf einem TCP-Port. Der Listener gibt eingehenden Traffic zunächst an das MySQL-Clientmodul weiter, das die anstehende Query auswertet.

Beim normalen MySQL wäre hier bereits Schluss und der Client bekäme eine Antwort vom Server. Nicht so bei Max Scale: Vom Clientmodul für MySQL gehen die enthaltenen und ausgewerteten Informationen weiter zu den Routern (Abbildung 2). Auf Höhe des Routers entscheidet sich, was mit der Query geschehen soll. Dabei ist ein einzelner Router für eine spezielle Funktion zuständig: Das Beispiel von oben, bei dem eingehende Anfragen in Schreib- und Lesezugriffe zu trennen sind, setzt etwa der Readwritesplit-Router um. Die Router sind also die wichtigsten Module innerhalb von Max Scale, neben »readwritesplit« stehen auch ein Router für reguläre Ausdrücke oder ein Logging-Router bereit.

Abbildung 2: Max Scale von innen betrachtet: Zu erkennen sind neben den Front- und Backends für das MySQL-Protokoll auch die Router.

Wenn die Pakete aus dem Router raus sind, wandern sie zum Backend-Modul, das eng mit dem Monitor-Plugin zusammenarbeitet: Das Monitor-Plugin behält den Überblick darüber, welche der konfigurierten Backends gerade zur Verfügung stehen. Es weiß auch, ob es sich um einen Master oder einen Slave handelt. Auf Basis dieser Informationen sendet das MySQL-Backend-Modul schließlich die jeweilige SQL-Query an eines seiner Backends. Mit im Boot sitzt ein Cache für Anmeldedaten.

Installation: Schnell erledigt

Max Scale steht auf der Website von Maria DB zum kostenlosen Download [3] bereit. Der Hersteller verteilt das Produkt zudem als Open-Source-Software; der gesamte Quelltext von Max Scale liegt auf Github [4]. Eine Enterprise-Version gibt es nicht, die Open-Source-Variante hat also alle vorhandenen Features.

Zudem ist es nicht nötig, Max Scale aus den Quellen zu kompilieren: Im User-Bereich von Mariadb.com [5] finden sich Anleitungen, um Max Scale in Form von Paketen auf Centos, Suse, Ubuntu oder Debian zu nutzen. Nach dem Aktivieren der entsprechenden Paketquelle reicht auf Ubuntu 14.04 bereits ein schlichtes »apt-get install maxscale« , um die Installation abzuschließen.

Konfiguration: Geht auch schnell

Nach der Installation folgt die Konfiguration. Die gute Nachricht: Max Scale kommt mit einer einzigen Konfigurationsdatei daher, und etwa 60 Zeilen sind bereits genug für eine funktionierende Installation. Das Beispiel in Listing 1 ist auf einen Galera-Cluster gemünzt, der eingehende Anfragen mit Hilfe des »readconnroute« -Routers auf die Back-ends verteilt. Ein Splitting je nach Querytyp ist in diesem Beispiel also noch nicht enthalten. Die einzelnen Parameter erklären sich praktisch von selbst, lediglich bei den Werten für » router_options« empfiehlt sich ein Blick in die Max-Scale-Dokumentation.

01 [maxscale]
02 threads=4
03
04 [Galera Router]
05 type=service
06 router=readconnroute
07 router_options=synced
08 servers=backend1, [...]
09 user=maxscale
10 passwd=geheim
11
12 [Galera Listener]
13 type=listener
14 service=Galera Router
15 protocol=MySQLClient
16 address=10.42.0.1
17 port=3306
18
19 [Galera Monitor]
20 type=monitor
21 module=galeramon
22 servers=backend1, [...]
23 user=maxscale
24 passwd=geheim
25
26 [Debug Listener]
27 type=listener
28 service=Debug Interface
29 protocol=telnetd
30 port=4442
31
32 [backend1]
33 type=server
34 address=10.42.0.2
35 port=3006
36 protocol=MySQLBackend
37
38 [CLI]
39 type=service
40 router=cli
41
42 [CLI Listener]
43 type=listener
44 service=CLI
45 protocol=maxscaled
46 address=localhost
47 port=6603

Wichtig: Der Nutzer, der bei »user« und »password« angegeben ist, muss auch in der Datenbank tatsächlich existieren. Denn ohne ihn hat Max Scale keine Chance, die Backends des Galera-Clusters zu monitoren. Der Mühe Lohn ist am Ende eine Max-Scale-Instanz, die eingehende Anfragen im gleichen Umfang auf drei Backends verteilt – das simpelste Max-Scale-Setup: ein Load Balancer.

Router haben eigene Parameter

Per »router_options« bestimmen Nutzer, nach welchem Grundsatz Max Scale ein Backend für eine Anfrage auswählt. Beim »readconnroute« geschieht dies ausschließlich auf Grundlage des Zustands, den die vorhandenen Backends gerade haben. »synced« verrät Max Scale, dass es sich um einen Galera-Cluster handelt und dass ein Backend nur Ziel sein darf, wenn es ein synchronisiertes Mitglied dieses Clusters ist.

Alternativen für ein Master-Slave-Setup sind »master« und »slave« . »running« erlaubt jeden Host als Ziel, mit dessen Datenbank Max Scale sich grundsätzlich verbinden kann. Über den optionalen Zusatzparameter »weightby« ließe sich in bester Load-Balancer-Manier auch eine Gewichtung der Maschinen festlegen, also eine Priorisierung anwenden.

Die gezeigte Konfiguration vor einem Galera-Cluster läuft letztlich auf ein klassisches Load-Balancer-Szenario hinaus. Ein typischer Load Balancer wäre aber im Gegensatz zu Max Scale kaum in der Lage, seinen Verteilmechanismus auf den Zustand der MySQL-Instanzen der Backends abzustimmen. Hier lässt Max Scale also die Muskeln spielen und zeigt, dass es mehr zu bieten hat.

Read-Write-Splits im Fokus

Während Galera erst nach und nach Einzug in vielen Unternehmen hält, sind Master-Slave-Setups mit MySQL gang und gäbe. Für diese eignet sich der »readwritesplit« -Router von Max Scale: Er analysiert MySQL-Queries und leitet lesende wie schreibende Queries auf unterschiedliche Backends weiter.

Das Beispiel in Listing 2 enthält eine beispielhafte Konfiguration für ein Master-Slave-Setup. Schreibzugriffe landen beim Master, Lese-Queries auf den Slaves. Es listet lediglich die relevanten Teile für das Setup auf – alles andere lässt sich aus der Beispielkonfiguration für das Galera-Setup übernehmen.

01 [ReadWrite Split Router]
02 type=service
03 router=readwritesplit
04 servers=backend1, [...]
05 user=maxscale
06 passwd=geheim
07 max_slave_connections=100%
08 max_slave_replication_lag=21
09
10 [ReadWrite Split Listener]
11 type=listener
12 service=ReadWrite Split Router
13 protocol=MySQLClient
14 port=3306
15 address=10.42.0.1

Bedeutsam sind die Parameter »max_slave_connections« und »max_slave_replication_lag« . Der Wert 100 Prozent bei Ersterem legt fest, dass Max Scale alle MySQL-Slaves nutzen darf. 80 Prozent an dieser Stelle würde dazu führen, dass Max Scale von fünf Slaves nur vier verwendet. »21« bei »max_slave_replication_lag« legt die Zeit in Sekunden fest, die ein Slave maximal seinem Master hinterherhinken darf, bis Max Scale ihn aussortiert.

Der »readwritesplit« -Router kommt ab Werk mit einer festen Tabelle an Query-typen für MySQL, die in Reads und Writes aufgeteilt sind. Nutzer haben die Möglichkeit, zusätzliche Filter selbst zu definieren. Mit dem Regexp-Filter lassen sich Queries etwa anhand regulärer Ausdrücke klassifizieren, sodass neben einem Read-Write-Splitting auch andere Splitting-Typen möglich sind.

Galera nach dem Master-Slave-Prinzip

Wer einen Galera-Cluster nutzt, seine Writes aber trotzdem nur auf einem Galera-Knoten sehen möchte, kann die beiden beschriebenen Betriebsmodi auch miteinander kombinieren. Der Router arbeitet dann im »readwritesplit« -Modus, was Max Scale dazu bringt, einen der Galera-Knoten zum Master zu machen und Writes dorthin zu leiten. Beim Splitter-Service sorgt »max_slave_connections« wie im Master-Slave-Beispiel dafür, dass Max Scale nur eine bestimmte Anzahl von Slave-Backends nutzt.

Mittels »disable_master_failback=1« beim Galera-Monitor unterbindet der Admin zudem, dass sich der Master-Knoten im laufenden Betrieb ändert, wenn ein neuer Knoten den Galera-Cluster betritt. Denn das wäre der Default: Max Scale würde sich den »WSREP_LOCAL_INDEX« -Parameter der Knoten anschauen und jenen Knoten zu seinem Master wählen, dessen Wert für diese Variable am geringsten ist. Steht »disable_master_failback« auf »1« , bleibt ein Server so lange Master, wie er im Cluster verfügbar ist.

Die Kombination aus »readwritesplit« und dem Galera-Backend erlaubt es dem Admin letztlich, eine echte Multi-Master-Cloud zu betreiben, die sich sogar mit älteren Applikationen verträgt, wenn diese nicht Cluster-fähig sind. Für große Cloudinstallationen, die MySQL im Backend nutzen – etwa Open Stack – ist das Programm damit ein echter Gewinn.

Wissen, was los ist: Das Max-Scale-CLI

MySQL selbst bietet mittlerweile eine Vielzahl von Befehlen, um sich direkt via CLI über den Zustand der Datenbank zu informieren. Max Scale kommt mit einem eigenen CLI (Abbildung 3), das das MySQL-Verhalten in gewisser Weise nachahmt. Per »maxadmin« starten Admins das Werkzeug. Der Befehl »show servers« gibt anschließend eine Übersicht über die konfigurierten Backends und deren Zustand.

Abbildung 3: Mit Hilfe des »maxadmin«-CLI finden Admins schnell heraus, wie es einem Router und seinen Backends geht.

Auch interne Statistiken hält »maxadmin« bereit: »show eventstats« zeigt an, wie lange verschiedene Queries im Durchschnitt dauern und wie hoch gerade die Last auf dem Max-Scale-Server ist. Wer ein einzelnes Backend aus dem Cluster entfernen muss – etwa zu Wartungszwecken – findet hier auch einen Maintenance-Modus (Abbildung 4). »set server Backend1 maintenance« aktiviert diesen für das Backend »backend1« ; der gleiche Befehl mit »clear« statt »set« hebt den Wartungsmodus für diesen Knoten auf.

Abbildung 4: Per CLI lassen sich einzelne Backends in den Maintenance-Modus versetzen, etwa für Updates oder Reboots.

Max Scale als Binlog-Server

Max Scale ist nicht allein dafür qualifiziert, nur Türsteher für andere MySQL-Backends zu sein. Es kann auch eine aktive Rolle innerhalb eines Clusters annehmen: Als Quelle für Binlogs, die MySQL-Slaves mit Daten füttern. Maria DB nennt diese Funktion “Replication Proxy”. In solch einem Setup wird Max Scale selbst zum Slave-Knoten für den Masterserver des MySQL-Clusters (Abbildung 5), fungiert aber andererseits zugleich selbst als Master für weitere Slaves. Weil sich Max-Scale-Instanzen beliebig skalieren lassen, darf die Zahl der möglichen Slaves hoch sein.

Abbildung 5: Als Binlog-Server wird Max Scale selbst zum Master für viele Slaves, obgleich es gegenüber dem MySQL-Master auch nur Slave ist.

Max Scale tritt mit dieser Funktion in direkte Konkurrenz zu MySQL selbst. Schließlich kann auch jeder normale MySQL-Slave Binlogs produzieren und diese an andere Slave-Server weitergeben. Die Entwickler nennen Performanceprobleme in der MySQL-Version als Grund für ihre Eigenentwicklung.

Eine komplette Anleitung für den Einsatz von Max Scale als Binlog-Router ist im Github-Verzeichnis von Max Scale unter [6] zu finden. Dort erwähnen die Entwickler auch, dass in »maxadmin« bei Binlog-Servern der Befehl »show service Replication« zur Verfügung steht – wenn das lokale Setup dem Beispiel folgt, andernfalls ist »Replication« durch den Namen zu ersetzen, den der Replikationsservice in der Konfiguration hat. Die Service-Statistik zu einem Binlog-Router verrät dem Admin viele wichtige Details über den Status der Replikation oder die Anzahl der Slaves und ist eine wichtige Quelle für Informationen.

Auch in Sachen Compliance und Security lässt sich Max Scale clever einsetzen. Wer Performance-Logging für seine Datenbank-Queries braucht, greift üblicherweise diese Daten direkt bei den Datenbanken ab. Weil aber jede Query auch bei Max Scale vorbeikommt, kann dieses natürlich ebenfalls ein passendes Log führen. Max Scale bietet diese Funktion tatsächlich an, sodass Admins die Last auf ihren Servern damit weiter reduzieren können.

Max Scale macht Cloud-Setups schneller

Bei Performancetests im Vorlauf zu diesem Artikel überzeugte Max Scale, und zwar gerade beim Durchsatz. Beim Thema Latenz kommt der Dienst nicht um die physikalischen Begebenheiten herum – geringer als die Latenz von Ethernet kann die Latenz natürlich nicht sein. Einen echten Mehrwert bietet Max Scale jedoch möglicherweise in Cloudsetups: Hier sind vorhandene SDN-Implementierungen oft verantwortlich dafür, dass die tatsächliche Latenz deutlich über der auf Ethernet-Ebene liegt.

Ab Version 1.3 beherrscht Max Scale persistente Datenbankverbindungen hin zu seinen Backends. Max Scale baut dann also Verbindungen im Hintergrund auf und verteilt eingehende Anfragen von Clients auf diese bereits offenen Verbindungen. In diesem Fall entfällt ein großer Teil des Netzwerk-Overheads, der die Latenz bei SDN-Umgebungen in die Höhe treibt. Wer MySQL etwa bei Amazon oder bei Rackspace schneller als bisher braucht, kommt über Max Scale 1.3 diesem Ziel ein Stück näher.

Das Setup gegen Ausfälle abhärten

Während Max Scale für zuverlässiges MySQL sorgt, bildet es selbst einen echten Single Point of Failure. Wenn etwa das eigene Setup vollständig auf Max Scale basiert, entsteht ein Problem, sobald die Max-Scale-Instanz den Geist aufgibt. Allerdings ist es nicht besonders kompliziert, Max Scale hochverfügbar zu machen. Einerseits können mehrere Max-Scale-Instanzen parallel auf dieselben Datenbank-Backends zugreifen. Die echten Clients teilt der Admin dann händisch auf die verfügbaren Max-Scale-Instanzen auf, sodass ein Ausfall nicht das ganze Setup lahmlegt. Ein anderer Weg wäre, den Max-Scale-Instanzen einen klassischen Load Balancer voranzustellen. Mit Blick auf die Latenz ist das aber nicht ideal.

Eine Alternative dazu ist der klassische Clustermanager: Für eine einzelne Max-Scale-Instanz genügt schließlich ein Aktiv-Passiv-Setup beispielsweise mit Pacemaker [7]. Ein Pärchen bestehend aus flexibler Service-IP und Max Scale wandert in dieser Variante problemlos von einem auf einen anderen Host. Max Scale beschreibt das erwähnte Setup in einem Firmenblog selbst [5].

Fazit

Max Scale von Maria DB entpuppt sich als ausgesprochen praktische Beigabe zu MySQL-Clustern. Es unterstützt dabei sowohl die Galera-Cluster als auch Backends nach dem Master-Slave-Prinzip, das bei MySQL ja bereits ab Werk fest eingebaut ist.

Für Admins löst Max Scale gleich mehrere Probleme: Einerseits erlaubt ein Gespann aus Max Scale und MySQL mit Galera den Aufbau einer Datenbank, die in die Breite skaliert. Das funktioniert selbst dann, wenn der Client nicht speziell darauf vorbereitet ist, mit mehreren Datenbankinstanzen zu sprechen. Stattdessen lässt sich dank Max Scale ein solcher Cluster tatsächlich von praktisch jedem MySQL-Client nutzen. Alle Anforderungen der Datenbank an die Client-Seite erfüllt Max Scale selbst.

Über die Möglichkeit, Reads und Writes zu splitten, freuen sich Admins von Master-Slave-Clustern besonders. Auch Nebenfeatures wie etwa das Monitoring von Datenbank-Clustern oder das separate Logging von Queries tragen zum positiven Gesamteindruck bei. Wer MySQL betreibt und sich in nächster Zeit mit dem Skalieren seines Setups in die Breite befasst, der sollte den gewandten Übersetzer auf jeden Fall einmal zu Wort kommen lassen.