ISPConfig Cluster über Public IP

B

Brainfood

Member
Habe heute Nacht mal Unison eingerichtet, cron lief aller 5 min.

Habe von einem RZ ins andere ein 1.6 GB File verschoben, nebenbei habe ich etwas per "iftop" den Traffic beobachtet und die Verzeichnisse vergleichen

Irgendwann fing er mit, .unison_xyz_temp_verzeichnis an ... der Traffic stieg vom erwarteten 1.6 GB Transfer auf 2, 3, dann 5 ... dann 6 ... an, in der /root/unison.log stand folgendes:

Code: 
Failed: The file .unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar was incorrectly transferred  (fingerprint mismatch in file contents) -- temp file saved as.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar-bad

UNISON 2.32.52 finished propagating changes at 05:02:26 on 27 Apr 2013

Synchronization incomplete at 05:02:26  (28 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun

UNISON 2.32.52 started propagating changes at 05:05:07 on 27 Apr 2013

[BGN] Copying www/clients/client1/web3/web/sun from /var to //XXX.XXX.XXX.XXX//var
/var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar.md5 has already been transferred
Failed: Failed to set modification time of file /var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar to 2013-04-27 at  4:53:57: the time was set to 2013-04-27 at  5:06:44 instead

UNISON 2.32.52 finished propagating changes at 05:06:44 on 27 Apr 2013

Synchronization incomplete at 05:06:44  (33 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun

UNISON 2.32.52 started propagating changes at 05:10:07 on 27 Apr 2013

[BGN] Copying www/clients/client1/web3/web/sun from /var to //XXX.XXX.XXX.XXX//var
/var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar.md5 has already been transferred
Failed: The file .unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar was incorrectly transferred  (fingerprint mismatch in file contents) -- temp file saved as.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar-bad

UNISON 2.32.52 finished propagating changes at 05:11:25 on 27 Apr 2013

Synchronization incomplete at 05:11:25  (0 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun

UNISON 2.32.52 started propagating changes at 05:15:07 on 27 Apr 2013

[BGN] Copying www/clients/client1/web3/web/sun from /var to //XXX.XXX.XXX.XXX//var
/var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar.md5 has already been transferred
Failed: The file .unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar was incorrectly transferred  (fingerprint mismatch in file contents) -- temp file saved as.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar-bad

UNISON 2.32.52 finished propagating changes at 05:16:12 on 27 Apr 2013

Synchronization incomplete at 05:16:12  (0 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun

Unison-Prozess gekillt, und auf */15 Minuten im Crontab gesetzt ... dann wurde das File sauber übertragen, er scheint also irgendwie Probleme zu haben wenn Unison ausgeführt wird und erneut Unison (per crontab) gestartet wird ...

des is Mist.

PS: Im Installing A Web, Email & MySQL Database Cluster On Debian 6.0 With ISPConfig 3 sollten noch ergänzt werden, dass Unison ebenso auf Server2 installiert sein muss
 
Zuletzt bearbeitet:
T

Till

Administrator
des is Mist.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Pack doch unison in ein wrapper script welches eine lock Datei erstellt und am ende wieder entfernt und nur dann unison ausführt wenn keine lockdatei da ist.

PS: Im Installing A Web, Email & MySQL Database Cluster On Debian 6.0 With ISPConfig 3 sollten noch ergänzt werden, dass Unison ebenso auf Server2 installiert sein muss
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Danke für den Hinweis!
 
B

Brainfood

Member
Jop hab es mit .lock File gemacht und mir die ganze Schoße paar Stunden angeschaut.

Übermittelt werden sollte 75 GB, 5 Domain Postfächer mit ca. insgesamt 15 Konten + ca 30 GB Webcontent.

Unison hat erstmal 30 min nix gemacht, als nur CPU belastet (file scan?) dann 10 Sub_Prozesse gestartet. zig .unison.tmp Files auf dem Server2 erstellt und nix gebacken bekommen.

Unison taugt überhaupt nix ...

1. Ich hab Apache2/Postfix/Dovecot beendet
2. Alle files aufs aktuelle Datum (auf Server1) gesetzt:

Code: 
find /var/vmail -exec touch -c {} \;

find /var/www -exec touch -c {} \;

3. alles per rsync over ssh transferiert

Code: 
# web sync
/usr/bin/rsync -avz --delete /var/www/domain.tld/cgi-bin/ root@server.domain.tld:/var/www/domain.tld/cgi-bin/
/usr/bin/rsync -avz --delete /var/www/domain.tld/ssl/ root@server.domain.tld:/var/www/domain.tld/ssl/
/usr/bin/rsync -avz --delete /var/www/domain.tld/web/ root@server.domain.tld:/var/www/domain.tld/web/
/usr/bin/rsync -avz --delete /var/www/domain.tld/webdav/ root@server.domain.tld:/var/www/domain.tld/webdav/

# mail sync
/usr/bin/rsync -avz --delete /var/vmail/domain.tld/ root@server.domain.tld:/var/vmail/domain.tld/

Ein Script läuft per Crontab aller 24 Stunden durch.

Um es salopp zu sagen: rsync over ssh ist schnell, zuverlässig = geil und ballert mir in wenigen Minuten die GBs über die Gigabit Leitung ins andere RZ weg.
 
Zuletzt bearbeitet:
B

Brainfood

Member
Ok Cluster trifft derzeit wirklich nur für die MySQL Master/Master Replication zu.

Was die Konsistenz bei Web/Mail angeht, sind rsync/unison keine "gute" Lösung. GlusterFS sagtest du, skaliert schlecht ab einer großen Anzahl von kleinen Dateien ...

Was mich jetzt interessiert ist ein brauchbarer Sync für Web, um eben per DNS Roundrobin ein einfaches HA (High Availability) und simples Loadbalacing zu bekommen.

Ich schau mir jetzt mal die "Relay Empfänger/E-mail Routing" Funktionen von ISPConfig und eine direkte Dovecot Synchronisierung mit "dsync" für den Clusterbetrieb an.

Bis jetzt laufen meine anderen (ISPConfig Master+dedicated Slave Server) Mailserver mit mehreren MX Einträgen und Routing + maximal_queue_lifetime als Cache.

Definiert sind also per DNS:

Code: 
domain.tld   TTL   MX 10   server1.domain.tld.
domain.tld   TTL   MX 20   server2.domain.tld.
domain.tld   TTL   MX 30   server3.domain.tld.
domain.tld   TTL   MX 40   server4.domain.tld.
domain.tld   TTL   MX 50   server5.domain.tld.
domain.tld   TTL   TXT   "v=spf1 mx -all"

Server2/3/4/5 sind nicht nicht für die Email-Domains zuständig:

ISPConfig -> E-Mail -> E-Mail Domain = keine domain.tld Einträge

jedoch für das Zwischenlagern:

ISPConfig -> E-Mail Routing -> domain.tld

Code: 
fremddomain.tld   smtp   Ziel   server1.domain.tld

ISPConfig -> Relay Empfänger

Code: 
@domain.tld

vi /etc/postfix/main.cf

Code: 
### ### ### PLITC ### ### ###
delay_warning_time = 6h
bounce_queue_lifetime = 12h
maximal_queue_lifetime = 12h
### ### ### PLITC ### ### ###

Server3/4/5 haben höhere delay/bounce/queue_lifetime werte

Ergebnis:
- Wenn Server1 ausfällt, wird die Mail an Server2 geschickt, dort bis zu 12 Stunden zwischengelagert, in dieser Zeit versucht an Server1 zu schicken und erst nach abgelaufener Zeit als unzustellbar abgelehnt.

Das ganze funktioniert tadellos

Was jetzt jedoch das Cluster Setup angeht:

- Die Mail würde auf MX2 zugestellt werden, da das Postfach auf Server2 vorhanden ist, und durch den primitiven file sync einfach plump überschrieben werden.

Punkt1: Wenn ich nun das Postfach mit domain Zugehörigkeit auf Server2 im Cluster erstellen lasse, greift vermutlich die Routing nicht mehr?

Punkt2: statt rsync muss ein direktes mirroring per dsync her, dass teste ich jetzt mal ...

Punkt3: Was den Websync angeht, fällt mir auf die schnelle nix brauchbares ein...



Das Cluster-Pärchen synct wie gesagt aller 24 Stunden von Server1 zu Server1, da einige Leute ihr Outlook auf "Lösche/Säubere den Papierkorb beim beenden von Outlook" aktiviert haben, ist im Roundcube der (Mail)Server2 als Server2 (Backup) definiert.

POP3 deaktiviere ich aus Prinzip beim erstellen der Postfächer und per autodiscover.xml ist nur IMAP definiert, ebenso werden standardmäßig die SRV Records negiert:

Code: 
_autodiscover._tcp.domain.tld. 3600      SRV        5 0 443 domain.tld.
_imap._tcp.domain.tld. 3600      SRV        0 0 0 .
_imaps._tcp.domain.tld. 3600      SRV        5 0 993 server1.domain.tld.
_pop3._tcp.domain.tld. 3600      SRV        0 0 0 .
_pop3s._tcp.domain.tld. 3600      SRV        20 0 995 server1.domain.tld.
_submission._tcp.domain.tld. 3600      SRV        5 0 587 server1.domain.tld.

Gesagt wurde ihnen: "Jungs, wenn ihr mal eine Mail (trotz erzwungenem IMAP) versehentlich gänzlich gelöscht haben solltet, könnt ihr sie per Roundcube vom Backup-Server innerhalb von 24 Stunden wieder zurück schieben"

Im "professionellen" Umfeld muss aber sowieso ein vernünftiger Sync zwischen den Web/Mail Inhalten herrschen.
 
Zuletzt bearbeitet:
florian030

florian030

Well-Known Member
Ich verwende statt GlusterFS DRBD als dual-primary und als FS OCFS2. Das funktioniert ganz gut.

Da die meisten Web-Domains aber eh CMS sind, würde dafür auch Unison o.ä. reichen.
 
B

Brainfood

Member
ok ich bastel mir erstmal ein VPN, vermutlich cert.basiertes IPSec drumherum bevor ich dann mal ein DRBD/OCFS2 aufsetze ...

Zum Thema Mysql-Sync:

Code: 
May  5 12:40:07 servername mysqld: 130505 12:40:07 [Warning] Statement may not be safe to log in statement format. Statement: UPDATE `session` 
May  5 12:40:07 servername mysqld:             SET `data` = 'last_login_date|s:19:\"2013-05-04 17:28:47\";new_member|b:0;sysmsg|a:0:{}return_url|s:0:\"\";sysmsg_info|a:0:{}', `expire` = '1367930407' 
May  5 12:40:07 servername mysqld:             WHERE `sid` = 'apl16uantloehe0g9001svlq34' LIMIT 1

irgendein Tipp dazu?
 
B

Brainfood

Member
ich habe mal etwas per PHPMyAdmin geblättert:

dbispconfig1

der Einträgt lässt sich unter: dbispconfig1 -> monitor_data -> log_messages finden:

Code: 
1	log_messages	1367783102	s:16810:"May  5 21:43:17 server mysqld:...	no_state
3	log_messages	1367783102	s:13917:"May  5 21:33:17 server mysqld...	no_state

Der Inhalt wird vermutlich aus dem "minütlichem" ISPConfig Crontab erzeugt.

Zwischen der MySQL Replication hängt aber immer noch der "ALTE" Eintrag in der Luft:

Code: 
SET `data` = 'last_login_date|s:19:\"2013-05-04 17:28:47\";new_member|b:0;sysmsg|a:0:{}return_url|s:0:\"\";sysmsg_info|a:0:{}', `expire` = '1367962037'

Wenn ich jetzt per phpmyadmin die 2 Sachen heraus lösche, sodass der M+M Rep. die alten Daten sauber reinschreiben kann und diese automatisiert per Crontab ersetzt werden ... wäre das eine brauchbare Lösung?
 
florian030

florian030

Well-Known Member
Nein, löschen ist keine brauchbare Lösung. Das dürfte Dir dann öfter passieren. Welches binlog_format verwendest Du denn? Das sollte mixed sein.
 
B

Brainfood

Member
Jop genau,

ich war mir erst unsicher, da:

Code: 
grep CONFIG $(which mysqlbug)

nix von irgendeiner "row" Unterstützung in dem vorkompilierten Debianbinary zeigte.

Zuerst versuchte ich einen Resync - mit STOP SLAVE; CHANGE MASTER TO MASTER ...; RESET SLAVE; START SLAVE; dass zerschoss mir aber nur den laufenden Sync, da er wieder die "Public IPs" aus der /etc/mysql/my.cnf nahm ... der sync wurde aber nachträglich übers stunnel gepackt.

ein erneuter CHANGE MASTER TO MASTER, zerschoss dann auf Filesystemebene den Sync, da die "alten" Bin-Logs vorhanden waren und er beim RESET SLAVE; auf 0 wieder springen sollte ...

Nach einem Backup-Recovery beider Master Server hab ich nun den "mixed mode" in der my.cnf ergänzt:

Code: 
skip-external-locking
#
### ### ### PLITC ### ### ###
# MySQL Master / Master Replication - Server1
#
server-id = 1
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 1

master-host = XXX.XXX.XXX.XXX
master-user = slaveuser
master-password = Geheim
master-connect-retry = 60

expire_logs_days        = 10
max_binlog_size         = 500M
log_bin                        = /var/log/mysql/mysql-bin.log
#
### avoid ISPConfig/MySQL Repl. create/delete DB sync_fail ###
slave_skip_errors=1007,1008
#
### more robustness ###
sync_binlog = 1
#
### avoid ISPConfig data value sync warnings ###
binlog-format = mixed
#
### ### ### PLITC ### ### ###
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
### ### ### PLITC ### ### ###
# bind-address          = 127.0.0.1
### ### ### PLITC ### ### ###
#
# * Fine Tuning
#


mmm repl. geht & syslog kann wieder durchatmen ...
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top