Redundante ISPConfig Wheezy-Server

[mrzs2k]

Hallo!

Da es noch keine entsprechende Anleitung für eine Clusterinstallation basierend auf Debian Wheezy gibt möchte ich mit diesem Thread über mein Vorhaben berichten.

Grundsätzlich war ich schon mal knapp davor eine richtige Clusterumgebung basierend auf Debian Wheezy zu erstellen, dieses Projekt wurde allerdings aus zeitlichen Gründen abgebrochen.

Ausgangssituation:
- Firma mit 2 Standorten - in der Zentrale 8 statische IP-Adresse, davon 2 derzeit verfügbar
- 2. Standort 1 statische IP-Adresse, Webserver steht in einem eigenen VLAN und mittels NAT kann auch diese IP verwendet werden
- Für die Übergangszeit wurden noch zusätzlich 2 vServer für 1 Jahr gemietet - um eine wirklich funktionstüchtige Konfiguration herstellen zu können

Der Plan:
- Installation eines einzelnen Debian Wheezy Servers auf dem vHost 1 - quasi als "Standalone"-Webserver.
- Installation des zusätzlichen Debian Wheezy Servers - Clusterkonfiguration - Daten, Datenbanken, DNS.... soll auf beiden Server mehr oder weniger in gespiegelter Form verfügbar sein. Siehe Cluster Setup Debian Squeeze. Dateisynchronisation via Unison - alternativen herzlich willkommen!
- Datenübernahme auf die 2 neuen vServer (wird alles neu händisch angelegt und die Daten eingespielt)
- Hinzufügen der Server der Firmenserver beider Standorte zum Cluster
- Entfernen der beiden vServer

Internetleitungen: vServer 100MBit synchron, Zentrale 100MBit synchron, Außenstelle 30/30MBit

So zu meinem ersten Schritt:
- Installation des ersten Servers - ähnlich der "The perfect Server"-Installation im Englischen HowToForge Forum für Debian Wheezy

Zum ersten problematischen Schritt:
- Hinzufügen eines "redundanten Partners" - dem sekundären Servers

wie gehe ich hier am besten vor?

Danke für eure Antworten!

 

[Till]

Schau Dir am Besten mal das Cluster setup für Debian squeeze an:

Installing A Web, Email & MySQL Database Cluster On Debian 6.0 With ISPConfig 3 | HowtoForge - Linux Howtos and Tutorials

Das sollte so auch für Wheezy gehen, bis auf den mysql replication setup teil denn da hat sich die Konfiguration mit mysql 5.5 geändert. Du musst Dir also eine andere anleitung im netzt suchen, ich glaube es gibt aber auch einen forum thraed hier bei howtoforge.de, welcher die geänderte mysql config beschreibt.

 

[denny]

Mein Setup aktuell und ungelöste Probleme

hi,

also ich habe jetzt eine ganze Menge gefrickelt und bin relativ "weit" gekommen.

Aktuell habe ich:

1. Percona MySQL Cluster (3 Nodes) auf InnoDB basierend und xtrabackup-v2 als SST Methode
2. HAProxy Instanz + keepalived + schwenkbare IP auf den DB-Nodes, wobei auf diese IP kein Roundrobin auf die DBs verteilt wird, sondern nach "balance source"
3. 2 x ISPConfig 3.0.5.3 auf zwei Nodes
4. lsyncd + csync halten /var/www synchron

Beide ISPConfig Instanzen greifen auf die gleiche Datenbank (dbispconfig) zu. web-01 ist Master, web-02 ist die zweite Instanz bei der ich gesagt habe, dass "is mirror of" für web-01 ist.

Soweit, so gut. Es war allerdings ein mittlerer Horror, was die Installation von ISPConfig angeht, bzw. deren Datenbank. Dabei ging es im Kern um drei Probleme:

1. Der Percona Cluster kann ausschließlich mit InndoDB umgehen, bzw. replizieren. ISP nutzt aber per Default MyISAM (ENGINE=MyISAM). Ergo, wird die Datenbank nicht auf die anderen Nodes gespiegelt -> Blöd. Abhilfe ist aber "einfach". Es reicht die passenden Zeilen in der *.sql zu tauschen.
2. Die ispconfig3.sql die mit dem Archiv mitgeliefert wird, funktioniert nicht "einfach" so. Da sind einige Felder, die nicht mit der InndoDB und Strict funktionieren (Stichwort Blob/Text etc.). Im Git (diese hier) ist aber eine passende SQL enthalten, die die notwendigen Korrekturen mitbringt.
3. Bei der Installation wird ein User in der DB erzeugt (ispconfig) + Zugriffsrechte auf web-01.example.com. Das ist zwar nett für eine einzelne DB, aber in einem Cluster hinter HAProxy blöd, denn ISPConfig spricht nicht direkt mit der DB, sondern mit HAProxy, der dann die Verbindung weiterleitet. Also spricht nicht web-01 mit der DB, sondern die jeweilige HA Proxy Instanz mit DB. Also erstellt man den User (ispconfig) besser selbst 'ispconfig'@'%' IDENTIFIED BY ... und wählt dann statt der Standard Installation, die Expert. Das Gleiche gilt auch für den Root Benutzer der DB, sonst scheitert der Installer bereits beim Erstellen der DB.

Lustig war auch, dass in einigen meiner Versuche die DB dann vorhanden war, allerdings ohne Inhalte. Sprich es waren mehr oder weniger nur die Tabellen da ....

Meiner Meinung nach, ist der Installer zu wenig auf Fehler vorbereitet, denn bis ich die Probleme mit der DB gefunden habe (man muss ja auch erstmal wissen, wonach man sucht).


Immerhin kann ich jetzt beide Instanzen nutzen. Was noch kommen wird, ist haproxy + keepalived + wandernde IP, um auch nach Ausfall einer Web Instanz Zugriff auf die Webseiten zu haben. Wird also noch getestet. web-01 und web-02 sind dann nur noch Verwaltungs- IPs, und die "Kunden/wir" nutzen nur "web.example.com". Wo sie dann rauskommen, bestimmt HAProxy.


Was noch nach mehreren Tagen kämpfen (bis zu dem genannten Status) noch offen ist -> /etc/passwd Replikation


Ich weiß nicht genau, was "Connect Linux userid to webid" bewirken soll, aber ich habe nach wie vor das Problem, dass eine angelegt Webseite auf web-01 von $KUNDE eine USERID z.B. 6007 bekommt, aber auf web-02 wird eben genau diese UID nicht in der /etc/passwd eingetragen. Ich weiß noch nicht, was die Ursache dafür ist. Eventuell ein Cron, der nicht korrekt arbeitet?
Des Weiteren hatte ich das Problem, dass auf web-02 die UID/GID von ispconfig nicht die 500* waren, sondern 100* hatten. Eventuell lag das an einer übersehenden Expert Option. Die /etc/passwd von beiden Instanzen müssen auf jedenfall gleich sein, sonst gibt es seltsame Effekte, wenn /var/www synchronisiert wird. Außerdem habe ich für den Fall der Fälle "Folder immutable" abgeschaltet, um da gleich Problemen aus dem Weg zu gehen.


Kommen wir zu der Quota: Wenn die Daten gespiegelt werden, ist es natürlich auch wichtig, dass (ext4) Quota auf beiden System identisch sind. Mein Test Kunde hat auf web-01 (wo die Domain angelegt wurde) hat 500MB, aber auf web-02 wurde nichts hinterlegt ... eventuell hängt das mit dem Problem oben zusammen. Da weiß ich noch keinen Rat.


Soweit mein Status. Was völlig außen vor ist, sind DNS, SMTP und IMAP/POP3. DNS wird extern betrieben und IMAP läuft auf Dovecot2 auf einem vorhandenen IMAP Server, der sich die Daten aus einem LDAP holt, genauso wie Postfix auf einem separaten Server läuft, ebenfalls mit LDAP als Quelle.
Ich werde schauen was passiert, wenn ich E-Mail und Co konfiguriere, aber das was ISPConfig erzeugt auf dem Dateisystem wegwerfe und auf den anderen System einfach passend die SQL Backends einbinde.
Aber das ist nur ein Schauplatz von vielen





cu denny

 

[nowayback]

hi,

ich sitze, wenn ich mal Langeweile habe, an einem ähnlichen Setup, jedoch spar ich mir das halbautomatische replizieren indem ich auf GlusterFS setze. So kann ich ohne Probleme /var/www und /var/log/ispconfig/ "syncron" halten (und habe zusätzlich, je nach Setup auch gleich ein verteiltes Dateisystem dass z.B. einen Download auf mehrere Server verteilt und dadurch deutlich höhere Geschwindigkeiten erreichen kann (macht jedoch für normale Websites keinen Sinn, aber für reine File/Download Server schon)).

Vielleicht ist das ja auch ein Ansatz für dich auch wenn es dein Problem selbst jetzt nicht direkt löst.

grüße
nwb

 

[Till]

Ich habe mit glusterfs sehr schlcehte Erfahrungen gemacht. Es funktioniert super und schnell, solange man nur ein paar Testdaten drauf hat. aber wenn Du mal z.B. 50 oder 100 Websites mit jeweils tausenden kleiner dateien auf ein Glusterfs share packst und dann apache auf alle seiten zugreifen lässt, bricht die performance massiv ein bis zu nahezu Stillstand. das problem ist dass Glusterfs nicht mit vielen kleinen dateien klarkommt, habe das auch vor einiger Teit im Internet recherchiert und es gibt wohl keine Lösung dafür. das einzige was meiner meinung nach gehen könnte ist wenn Du /var/www und /var/vmail als loopback device (eine große Datei) erstellst und diese Datei auf ein glusterfs share legst. Ich musste schon mehrere größere Prosuktivsysteme von Kunden von Glusterfs auf unison umstellen weil die Systeme extram langsam waren. Ich kann daher nur raten mal ein paar GB an Daten mit vielen kleinen Dateien zu nehmen und mal zu testen wenn Du mit "ab" mehrer webs gleichzeitig abrufst.

 

[nowayback]

Ich habe mit glusterfs sehr schlcehte Erfahrungen gemacht. Es funktioniert super und schnell, solange man nur ein paar Testdaten drauf hat. aber wenn Du mal z.B. 50 oder 100 Websites mit jeweils tausenden kleiner dateien auf ein Glusterfs share packst und dann apache auf alle seiten zugreifen lässt, bricht die performance massiv ein bis zu nahezu Stillstand. das problem ist dass Glusterfs nicht mit vielen kleinen dateien klarkommt, habe das auch vor einiger Teit im Internet recherchiert und es gibt wohl keine Lösung dafür. das einzige was meiner meinung nach gehen könnte ist wenn Du /var/www und /var/vmail als loopback device (eine große Datei) erstellst und diese Datei auf ein glusterfs share legst. Ich musste schon mehrere größere Prosuktivsysteme von Kunden von Glusterfs auf unison umstellen weil die Systeme extram langsam waren. Ich kann daher nur raten mal ein paar GB an Daten mit vielen kleinen Dateien zu nehmen und mal zu testen wenn Du mit "ab" mehrer webs gleichzeitig abrufst.

Das Problem ist ja genau das, was ich oben in Klammern geschrieben habe. Hast du mal getestet wie die Performance ist, wenn es kein Striped Setup ist? Ich denke nämlich das hier dein Problem liegt/lag. Wenn es ein reines replicated Volume ist (oder distributed replicated sollte auch funktionieren) dann müsste es auch bei kleinen Dateien funktionieren.

Grüße
nwb

 

[Till]

Ich hatte seinerzeit den typ "cluster/replicate" verwendet. Hatte das irgendwann auch mal mit aktuellerer glusterfs version getestet, war aber nur minimal besser.

Installing A Web, Email And MySQL Database Cluster (Mirror) On Debian 5.0 With ISPConfig 3 | HowtoForge - Linux Howtos and Tutorials

Wenn Du eine funktionierende Config hast, dann kannst Du sie ja gerne mal posten, dann teste ich das nochmal.

Wäre ja schön, wenn es dafür eine Lösung gibt. Unison ist definitiv auch nur ein Notnagel

 

[nowayback]

Ich schau mal ob ich eventuell am Wochende oder kommende Woche dazu komm mein Testsetup zu vervollständigen und dann kann ich ja mal ne Runde rumspielen

Grüße
nwb

 

[denny]

hi,

nachdem sich nun mein Firefox aufgehangen hat ... hier die Kurzfassung:

• Glusterfs soll wirklich schlecht sein, habe ich auch von anderen gehört. unabhängig von ISPConfig
• Mit glusterfs klappt kein Quota mehr auf Dateisystemebene, wenn man es nicht benötigt, Ok, wenn doch, ist es ein K.O Kriterium.
• unison soll nicht sooo prickelnd sein, besser ist die Kombination lsyncd und csynd2 (von den DRBD Erfindern)

Ich habe heute soweit alles zum Laufen bekommen, inkl. Quota und /etc/passwd etc.
Am Montag denke ich, werde ich mal für mich eine Anleitung schreiben, wie ich was gemacht habe. Die steht dann natürlich auch öffentlich zur Verfügung.


cu denny

 

[denny]

Nachtrag

hi,

also, ich habe jetzt tatsächlich zwei funktionierende ISPConfig3 Installationen die weitestgehend HA sind.
Ich schreibe weitestgehend, weil /var/www nicht via unison/csync2/drbd gespiegelt wird, weil alle diese Lösungen eigentlich keine Lösungen sind, sondern Workarounds. Nachdem csync2 sich unvermittelt verabschiedete, weil aus seltsamen Gründen der ein Problem mit dem syncronisieren hatte; Unison per Cron glaube ich keine gute Lösung ist, da das zu seltsamen Fragen führen könnte, seitens der "Kunden"; drbd + ClusterIP a) kompliziert, b) Fehleranfällig c) Master/Master Setup mit ISPconfig3 nicht mehr funktioniert.

Eine richtige Lösung bieten nur Cluster-Dateisysteme die auch die normalen Quota Kommandos unterstützen, bzw. /var/www auf einem NFS Server. Für letzteres habe ich mich entschieden. Der NFS Server ist zwar selbst nicht HA, aber dafür die VM (Proxmox) und das Storage unten drunter (ISCSI). Ich glaube auch, dass man einen NFS Server schneller wieder flott bekommt, als all die Konstrukte die bisher existieren. Das klappt natürlich nur, wenn man so gut ausgestattet ist, wie wir derzeit

Damit habe ich nun folgendes Endkonstrukt:

Haproxy 1 > web-01 > db-cluster -> Percona InnoDB
Haproxy 2 > web-02 > db-cluster -> Percona InnoDB

Eine globale Cluster IP wird via keepalived auf den Haproxy Rechnern bereitgestellt und die jerweilige Haproxy VM verteilt dann die Anfragen an die internen Web-01 und web-02 VMs. Auf diese Weise erhalte ich wieder mein Loadbalancing.

Die Datenbank von ISPConfig musste ich dafür von MyISAM auf InnoDB umstellen, damit der Percona Cluster die DBs (von beiden ISP3 Instanzen) replizieren kann. Außerdem musste ich die Berechtigungen anpassen, damit ISP3 auf die DBs zugreifen darf, denn die Anfragen kommen von den HAProxy Instanzen (Clusterip/Loadbalancing) und nicht von web-01 und web-02.

Damit auch Quota über NFS funktioniert, läuft bei mir auf dem NFS quotarpc als Dienst. Allerdings benötigte ich einen Workaround, der sich aber leicht dokumentieren lässt: der NFS Server bezieht seine Daten ausschließlich über LDAP, sodass der die von ISP3 angelegten User nicht kennt. Daher habe ich eine Untergruppe erzeugt ou=webhosting,ou=people,dc=domain,dc=foo, mit den uid=web1, web2 ...

dn: uid=web4,ou=webhosting,ou=people...
 e
gidNumber: 60004
objectClass: posixAccount
objectClass: inetOrgPerson
uidNumber: 60004
uid: web4
homeDirectory: /var/www/clients/client4/web4/./home/ispisp:/usr/sbin/jk_chroot
 sh
sn: web4
cn: web4

Das reicht aus, damit der User auf dem NFS Server bekannt ist. Da die gleiche UID/GID auf web-01 / web-02 verwendet wird ...

quota  web4
Dateisystemquotas für user web4 (uid 60004):
    Dateisystem Blöcke   Quota   LimitGnadenfrist Dateien   Quota   LimitGnadenfrist
1.2.3.4:/web-data
                     80  716800  717824              20       0       0

Als letztes musste nur der setquota Befehl in apache2_plugin.inc.php/cron_plugin.inc.php/nginx_plugin.inc.php angepasst und um "-r" erweitert werden (also setquota -r .....). Damit kann nun ISP3 den Quotabefehl per RPC setzen. Eleganter wäre es, wenn ein if/else Konstrukt selbst erkennen würde, ob das Dateisystem per NFS eingebunden, oder lokal ist.

Das bedingt natürlich, dass beim anlegen von neuen Kunden/Webs diese im LDAP eingetragen werden. Das mache ich derzeit zu Fuß, sollte sich aber auch automatisieren lassen.

Als Schönheitsaufgabe wäre jetzt nur noch /var/log/... ebenfalls auf NFS zu bringen, aber das erspare ich mir, da wir auf Apache Logs nicht soviel Wert legen.

Mit dieser Lösung kann ich nun ruhigen Gewissens auch einen längeren Urlaub antreten, da sich alles gut und sauber dokumentieren lässt und kein Spezialwissen erforderlich ist, wie dies bei Pacemaker/DRBD der Fall wäre.

Was haltet ihr davon?