Root-Server im MySQL-Cluster

[theton]

Ich versuche gerade 2 Rootserver in ein MySQL-Cluster einzubinden. Dabei gibt es leider nur ein Problem, fuer das ich keine Loesung finde. Der komplette bestehende Teil des Clusters wird auf LAN-IPs adressiert, waehrend die 2 Rootserver natuerlich "normale Internet-IPs" haben. Momentan habe ich fuer das Adressierungsproblem einen Workaround dadurch gefunden, dass ich einen weiteren Rootserver im gleichen RZ habe, der als zweite Management-Konsole dient. Ich kann mir allerdings nicht vorstellen, dass dies nicht auch mit einer einzigen Management-Konsole geht. Momentan sieht die Konfiguration der Management-Knoten wie folgt aus:

Code: Select all

[NDBD DEFAULT]
NoOfReplicas=3
DataMemory=512M
IndexMemory=512M
MaxNoOfOrderedIndexes=6800
MaxNoOfUniqueHashIndexes=5200
MaxNoOfAttributes = 4000
RedoBuffer = 64M

[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]

# Management Nodes
[NDB_MGMD]
HostName=123.123..123.1 # "alte" Management-Konsole
[NDB_MGMD]
Hostname=133.133.133.1 # zusaetzliche Management-Konsole

# Storage Nodes
[NDBD]
HostName=192.168.1.5
DataDir=/var/lib/mysql-cluster
[NDBD]
HostName=192.168.1.4
DataDir=/var/lib/mysql-cluster
[NDBD]
HostName=192.168.1.101
DataDir=/var/lib/mysql-cluster

# Setup node IDs for MySQL API servers (clients of the cluster)
[MYSQLD]
[MYSQLD]
[MYSQLD]
[MYSQLD]

Um mein Problem etwas besser verstehen zu koennen, hier mal eine kurze Beschreibung der Teile des Netzwerks, die fuer das Cluster relevant sind:

Das komplette bestehende Cluster befindet sich in einem Server-Schrank, der zum Internet nur eine Leitung hat. Der Management-Knoten ist somit auch Router. Das Netzwerk im Schrank sieht also wie folgt aus... Der Rechner 192.168.1.1 (bei uns heisst er phoenix) ist Management-Knoten und Router, dessen zweite Netzwerkkarte am Switch des RZ haengt und darueber mit fester IP im Internet erreichbar ist. Insgesamt sind dem Router/Management-Server 5 verschiedene IPs zugewiesen, die dieser ueber virtuelle Interfaces aufloest. Das funktioniert z.B. fuer einen der API-Knoten mit den IPTables etwa so:

Code: Select all

$IPTABLES -t nat -A POSTROUTING -s $IP_INT_ALBATROS -o eth0 -j SNAT --to-source $IP_EXT_ALBATROS
$IPTABLES -t nat -A POSTROUTING -s $IP_INT_ALBATROS -o eth1 -j SNAT --to-source $IP_EXT_ALBATROS
$IPTABLES -t nat -A PREROUTING -i eth0 -d $IP_EXT_ALBATROS -j DNAT --to-destination $IP_INT_ALBATROS
$IPTABLES -t nat -A PREROUTING -i eth1 -d $IP_EXT_ALBATROS -j DNAT --to-destination $IP_INT_ALBATROS

Auf diese Weise sind also alle Knoten des Clusters auch im Internet mit einer festen IP erreichbar, waehrend innerhalb des Schranks nur LAN-IPs genutzt werden.
Und an dieser Stelle sitzt mein Problem. Wollen naemlich die neuen Speicherknoten mit den alten kommunizieren und melden sich bei einem von diesen, bekommen sie die Antwort mit einer LAN-IP, die fuer sie natuerlich nicht gueltig ist, da sie die Anfrage ja an eine voellig andere IP gestellt haben. Ich habe auch schon die komplette Konfiguration auf die Internet-IPs umgestellt, aber auch das brachte nichts, da sich die Rechner im Schrank ja unter dieser IP garnicht kennen. Die kennen nur ihre LAN-IP, die "Aufloesung" der Internet-IPs macht ja der Router.
Problem dabei ist, dass diese Netzwerk-Konstruktion noch von meinem Vorgaenger stammt und ich nun hier bin um damit ein Cluster einzurichten. Da in dem Schrank auch noch Server stehen, die im Produktiv-Betrieb sind, kann ich aber auch nicht einfach den Serverschrank neu verkabeln. Ich weiss, dass dies die beste Loesung waere.
Vielleicht hat ja hier noch jemand eine Idee, was ich machen koennte um die Server aus dem Schrank dazu zu bewegen korrekt mit den Servern, die draussen stehen, zu kommunizieren.

[lord_pinhead]

Schlag mich, tritt mich, hau mich, aber die IPTables Regeln müssen doch ganz anders lauten oder nicht?

iptables
-t nat
-A PREROUTING
-i eth0
--protocol tcp
--source <rootserverip>
--destination <extip>
--destination-port <dein_zielport>
-j DNAT
--to-dest <intip>:<mysqlport>

(mit umbrüchen ist das etwas übersichtlicher)
So hab ich jedenfalls alle meine Ports in mein Intranet zu dem Syslog und Backupserver genatet.

[theton]

Nein, das was du dort machst is ja ein einfaches Port-Forwarding. Darum geht es bei dieser Firewall aber nicht. Um es etwas klarer zu machen, eine kurze Beschreibung des Routers:

eth1 ist mit der LAN-IP 192.168.1.1 adressiert, waehrend eth0 aufgeteilt ist in eth0:1 bis eth0:27. Jedem der eth0-Interfaces ist eine eigene feste IP fuer das Internet zugewiesen, denn diese Karte haengt auch am Switch des RZ. Die iptables-Befehle tun nun nichts anderes, als dafuer zu sorgen, dass Verbindungen auf eine bestimmte Internet-IP auf eine bestimmte LAN-IP umgelegt werden und umgekehrt.

Eigentlich funktionieren die von mir geposteten iptables-Befehle ja auch problemlos solange es nicht um das NDB-Cluster geht. Normale MySQL-Verbindungen von innen nach aussen und umgekehrt machen keinerlei Probleme, gleiches gilt auch fuer Webserver, Mailserver, DNS usw.

Bei NDB-Cluster ist es halt so, dass sich die Knoten anhand der im Management-Server eingetragenen IPs kennen lernen und untereinander Verbindungen aufbauen. Ich kann aber nunmal keine Internet-IP mit einer LAN-IP verbinden lassen, die Server selbst kennen sich aber ja nur mit ihrer LAN-IP und geben daher Antworten mit dieser IP raus. Fuer den Rest waere dann eigentlich das Routing zustaendig, aber aus mir unverstaendlichen Gruenden kommt die Antwort der Server aus'm Schrank immer mit LAN-IP an. Ich weiss nicht, ob MySQL dabei direkt die Netzwerkpakete untersucht oder wie es sonst dazu kommt, dass die "aussen stehenden" Knoten ihre Antworten mit den LAN-IPs bekommen. Fuer alle anderen Verbindungen legt der Router diese ja auch auf die Internet-IPs um und das ist der Grund, warum sich die externen Knoten nicht ins Cluster einbinden lassen. Denkbar waere auch, dass innerhalb eines NDB-Cluster die Knoten nur ueber die Management-Konsole adressiert und Verbindungen auf diese Weise weiter gereicht werden. Leider konnte ich aber keine genauere Doku finden, die bis ins kleinste Detail erlaeutert, wie innerhalb eines NDB-Clusters die Verbindungen zwischen den Knoten zustande kommen, denn sowas waere bestimmt sehr hilfreich.

Ich habe zwar mittlerweile angefangen mich in die Quelltexte von MySQL einzuarbeiten, aber da diese nicht gerade klein sind, wird es eine Weile brauchen, bis ich mich da durchgewuselt habe und weiss, was da abgeht. Soviel Zeit habe ich aber nicht. Gut, der Workaround mit der zweiten Management-Konsole funktioniert erstmal, kostet uns aber jeden Monat 20 Euro zusaetzlich, die ich lieber in einen andere Dinge investieren wuerde. Deswegen suche ich nach einer Loesung fuer dieses Problem.

An der Firewall kann es eigentlich kaum liegen. Ich vermute eher, dass ich in der Management-Konsole Aenderungen machen muss, damit auch dort bekannt wird, dass Rechner 123.123.123.3 z.B. eigentlich die Adresse 192.168.1.3 hat, denn, wie gesagt, mit anderen Server-Programmen funktioniert die Firewall ja auch auf diese Weise, nur im Cluster nicht. Das ist der Grund, warum meine Vermutung eher dahin geht, dass mit den Einstellungen der Management-Konsole etwas nicht stimmt.