Cluster Setup Squeeze

[xxs]

Hallo,

habe ISPConfig 3.0.4 laut dieser Anleitung aufgesetzt. Beide sind in einem OpenVZ container installiert. Dass Quota und iptables_nat nicht leider nicht funktionier habe ich schon bemerkt.

Allerdings bekomme ich nach dieser Anleitung auch glusterfs nicht zum Laufen (2 Unterschiedliche IPs auch andere Netze).

Außerdem funktionieren folgende Angaben nicht.

Copy the mysql and www data back.
cp -prf /var/lib/mysql_bak/* /var/lib/mysql/
cp -prf /var/www_bak/* /var/www/
Copy back the data (only on the master server! Skip this step on the slave!).
​

Wenn die Daten an der Stelle nicht zurück kopiert werden, lässt sich der mySQL Server nicht mehr starten.

When you set up the slave server, copy the file /etc/mysql/debian.cnf file from the master server to the slave server before you start MySQL again!
​

geht ebenfalls nicht, führt zu Fehlermeldungen (beide Datenbankserver haben unterschiedliche root-Passwörter für mysql)

Die zusätzlich eingebunden Sources sind natürlich auf die jeweiligen für Squeeze geändert:

deb Index of /debian squeeze-updates main
deb Index of /debian-backports squeeze-backports main
​

Für Hilfe und Anregungen wäre ich Dankbar

 

[Till]

Dass Quota und iptables_nat nicht leider nicht funktionier habe ich schon bemerkt.

Quota funktioniert durchaus, schau mal in die openvz Doku zum Theme second level quota.

Wenn die Daten an der Stelle nicht zurück kopiert werden, lässt sich der mySQL Server nicht mehr starten.

das liegt daran, dass Glusterfs nicht geht. Denn das Zurückkopieren auf Master und slave macht ja rein logisch keinen Sinn, denn dann hättest Du ja wieder getrennte Datensätze und eben kein Clusterfilesystem.

geht ebenfalls nicht, führt zu Fehlermeldungen (beide Datenbankserver haben unterschiedliche root-Passwörter für mysql)

was auch wieder daran liegt, dass das Glusterfs volume nicht geht.


Du kannst das Cluster setup aber auch mit anderen Techniken statt glusterfs aufsetzen, und zwar z.B. mit unison zum syncen von /var/www und /var/vmail

Setting Up Unison File Synchronization Between Two Servers On Debian Squeeze | HowtoForge - Linux Howtos and Tutorials

und für mysql nimmst Du eine master / master mysql replikation, dabei solltest Du aber die Datenbanken "mysql" und "dbispconfig" auf beiden Servern von der Replikation ausnehmen.

Ich werde auch in den nächsten Wochen ein Tutorial für die Variante mit unison und master/master Repliaktion ein Tutorial veröffentlichen.

 

[xxs]

Vielen Dank erst mal für die schnelle Antwort.

Eine frage habe ich an der Stelle aber noch. Geht GlusterFS an der Stelle generell nicht (OpenVZ), oder funktioniert alles nicht, weil GlusterFS nicht läuft?

iptables_nat scheint auch irgendwie zu gehen, ist wohl kernel-abhängig, so wie ich das gelesen habe, aber bevor ich beim quota und den iptables weiter gesucht habe, wollte ich erst einmal klären, warum der rest nicht geht.

 

[Till]

Ich habe gluterfs unter openvz noch nicht verwendet, daher kann ich nicht sagen ob es generell geht oder nicht. Das alles nicht geht liegt aber wiederum daran, dass Glusterfs nicht läuft, denn ohne die zentrale Komponente zum Synchronisieren der daten kann ein Cluster nunmal nicht funktionieren.

 

[mattula]

Du kannst das Cluster setup aber auch mit anderen Techniken statt glusterfs aufsetzen, und zwar z.B. mit unison zum syncen von /var/www und /var/vmail
[...]
und für mysql nimmst Du eine master / master mysql replikation, dabei solltest Du aber die Datenbanken "mysql" und "dbispconfig" auf beiden Servern von der Replikation ausnehmen.

Beziehst du dich bei der Sync Variante auf folgende master/master replikation?
HowtoForge Linux Tutorials » Einrichten von Master-Master Replikation mit MySQL 5 auf Debian Etch

Wenn ja, eine Frage dazu: In dem Fall muss ich doch fuer jede DB, die ich replizieren will, die Replikation explizit eirichten, oder? D.h. eine ueber das CP angelegte DB ist erstmal nur lokal - oder versteh ich was falsch?

Und bei der Variante hier mit Gluster-FS:
HowtoForge Linux Tutorials » Einrichten von Master-Master Replikation mit MySQL 5 auf Debian Etch

Laeuft da wirklich auf beiden Nodes der Mysql als Master, hat 1:1 die gleiche DB (inkl. der "dbispconfig") und im CP wird dann einer der beiden Nodes als Mirror konfiguriert?

Und wie wird sich das Gluster-FS Setup in Bezug auf Jailkit verhalten?
Hintergrund: ich habe schon einen Cluster Versuch mit Heartbeat im Active/Passive Setup und NFS als Shared Storage gemacht, wobei /var/www u.a. auf NFS lag.
Beim Erstellen eines SSH Jailkit Users gab es dann folgende Fehlermeldung:

ln: creating hard link `/var/www/clients/client7/web5/var/run/mysqld/mysqld.sock' => `/var/run/mysqld/mysqld.sock': Invalid cross-device link

Ich befuerchte, dass das bei unterschiedlichen Gluster-FS Mountpoints innerhalb /var ebenfalls ein Problem sein wird.

gruss,
Matthias

 

[Till]

Wenn ja, eine Frage dazu: In dem Fall muss ich doch fuer jede DB, die ich replizieren will, die Replikation explizit eirichten, oder? D.h. eine ueber das CP angelegte DB ist erstmal nur lokal - oder versteh ich was falsch?

Das geht auch anders herum, also repliziere alle Datenbanken bis auf a und b.

Laeuft da wirklich auf beiden Nodes der Mysql als Master, hat 1:1 die gleiche DB (inkl. der "dbispconfig") und im CP wird dann einer der beiden Nodes als Mirror konfiguriert?

Nein, jeder node hat seine eigene DB (unterschiedliche DB Namen). Von Glusterfs für MySQL rate ich Dir ab, das läuft einfach nicht gut.

Beim Erstellen eines SSH Jailkit Users gab es dann folgende Fehlermeldung:

ln: creating hard link `/var/www/clients/client7/web5/var/run/mysqld/mysqld.sock' => `/var/run/mysqld/mysqld.sock': Invalid cross-device link

das ist ok, kannst Du ignorieren. Denn mysql funktioniert auch ohne diesen Hardlink über eine Verbindung zu localhost.

 

[mattula]

Nein, jeder node hat seine eigene DB (unterschiedliche DB Namen). Von Glusterfs für MySQL rate ich Dir ab, das läuft einfach nicht gut.

Aehm? Du raetst prinzipiell vom Setup Mysql auf Gluster-FS ab und stattdessen dazu Master/Master-Replikation zu verwenden?
Oder raetst nur davon ab die DB namens "mysql" auf's Gluster-FS zu legen?

Oder anders gefragt, was ist deine Empfehlung fuer einen 2 Node ISPConfig Cluster (Active/Passive mit autom. Failover) , wenn ich prinzipiell alle Resourcen (NAS, SAN, eigene Hardware bzw. VSphere, eigenes Netzwerk, beliebige IP, ..) zur Verfuegung habe?

Gruss,
Matthias

 

[xxs]

Soweit geht jetzt alles. GlusterFS lief in der Tat nicht, da fuse in Open-VZ Containern explizit aktiviert werden muss. Quota und IPtables_nat sollten jetzt auch gehen.

Allerdings bekomme ich folgende Fehlermeldung:

Replication failed. Error: (server) in MySQL server: (localhost) Access denied for user 'ispconfig'@'localhost' to database 'dbispconfig02' # SQL: REPLACE INTO server (`server_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_name`,`mail_server`,`web_server`,`dns_server`,`file_server`,`db_server`,`vserver_server`,`proxy_server`,`firewall_server`,`config`,`updated`,`mirror_server_id`,`dbversion`,`active`) VALUES ('3','1','1','riud','riud','r','srv02.serverurl.de','1','1','1','1','1','0','0','1','[global]nwebserver=apachenmailserver=postfixndnsserver=mydnsnn[server]nauto_network_configuration=nnip_address=10.10.10.2nnetmask=255.255.255.0ngateway=192.168.0.1nhostname=srv02.serverurl.dennameservers=192.168.0.1,192.168.0.2nloglevel=2nbackup_dir=/var/backupnbackup_dir_ftpread=nnn[mail]nmodule=postfix_mysqlnmaildir_path=/var/vmail/[domain]/[localpart]nhomedir_path=/var/vmailnpop3_imap_daemon=dovecotnmail_filter_syntax=sievenmailuser_uid=5000nmailuser_gid=5000nmailuser_name=vmailnmailuser_group=vmailnrelayhost=nrelayhost_user=nrelayhost_password=nmailbox_size_limit=0nmessage_size_limit=0nn[getmail]ngetmail_config_dir=/etc/getmailnn[web]nserver_type=apachenwebsite_basedir=/var/wwwnwebsite_path=/var/www/clients/client[client_id]/web[website_id]nwebsite_symlinks=/var/www/[website_domain]/:/var/www/clients/client[client_id]/[website_domain]/nwebsite_symlinks_rel=nnvhost_conf_dir=/etc/apache2/sites-availablenvhost_conf_enabled_dir=/etc/apache2/sites-enablednnginx_vhost_conf_dir=/etc/nginx/sites-availablennginx_vhost_conf_enabled_dir=/etc/nginx/sites-enablednsecurity_level=20nuser=www-datangroup=www-datannginx_user=www-datannginx_group=www-datanapps_vhost_port=8081napps_vhost_ip=_default_napps_vhost_servername=nphp_open_basedir=[website_path]/web:[website_path]/tmp:/var/www/[website_domain]/web:/srv/www/[website_domain]/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadminnhtaccess_allow_override=Allnawstats_conf_dir=/etc/awstatsnawstats_data_dir=/var/lib/awstatsnawstats_pl=/usr/lib/cgi-bin/awstats.plnawstats_buildstaticpages_pl=/usr/share/awstats/tools/awstats_buildstaticpages.plnphp_ini_path_apache=/etc/php5/apache2/php.ininphp_ini_path_cgi=/etc/php5/cgi/php.inincheck_apache_config=ynenable_sni=ynnginx_cgi_socket=/var/run/fcgiwrap.socketnphp_fpm_init_script=php5-fpmnphp_fpm_ini_path=/etc/php5/fpm/php.ininphp_fpm_pool_dir=/etc/php5/fpm/pool.dnphp_fpm_start_port=9010nphp_fpm_socket_dir=/var/lib/php5-fpmnn[dns]nbind_user=rootnbind_group=bindnbind_zonefiles_dir=/etc/bindnnamed_conf_path=/etc/bind/named.confnnamed_conf_local_path=/etc/bind/named.conf.localnn[fastcgi]nfastcgi_starter_path=/var/www/php-fcgi-scripts/[system_user]/nfastcgi_starter_script=.php-fcgi-starternfastcgi_alias=/php/nfastcgi_phpini_path=/etc/php5/cgi/nfastcgi_children=8nfastcgi_max_requests=5000nfastcgi_bin=/usr/bin/php-cginfastcgi_config_syntax=1nn[jailkit]njailkit_chroot_home=/home/[username]njailkit_chroot_app_sections=basicshell editors extendedshell netutils ssh sftp scp groups jk_lshnjailkit_chroot_app_programs=/usr/bin/groups /usr/bin/id /usr/bin/dircolors /usr/bin/lesspipe /usr/bin/basename /usr/bin/dirname /usr/bin/nano /usr/bin/piconjailkit_chroot_cron_programs=/usr/bin/php /usr/bin/perl /usr/share/perl /usr/share/phpnn[vlogger]nconfig_dir=/etcnn[cron]ninit_script=cronncrontab_dir=/etc/cron.dnwget=/usr/bin/wgetnn[rescue]ntry_rescue=nndo_not_try_rescue_httpd=nndo_not_try_rescue_mysql=nndo_not_try_rescue_mail=nnn','0','1','26','1')

​

wobei die IP-Adresse und die URL in der Ausgabe natürlich ersetzt sind.

 

[mattula]

Access denied for user 'ispconfig'@'localhost' to database 'dbispconfig02'

Das sagt doch imho alles. Du musst dem User die passenden Privileges einrichten - auf beiden Datenbanken.
Es gibt dazu auch irgendwo im Perfect Server Howto einen Hinweis, wie es geht.

 

[xxs]

Bevor es VErwirrung gibt. Hatte Die das zwischenzeitliche Gespräch nicht gesehen. Bin noch immer auf dem Stand Von GlusterFS auch für die Datenbanken. Das die Rechte nicht stimmen hatte ich auch festgestellt, nur laut dem HowTo wird auf dem MasterServer (srv01) ein user root@srv02 eingerichtet, was ich auch habe, weil ich sonst den zweiten Server ja nicht im Webinterface von srv01 (Master) hätte.

Einen Hinweis auf das anlegen eines Users ispconfig, oder das Umbiegen dessen Rechte kann ich nirgendwo finden.

 

[Till]

Der User ispconfig wird auch vom ispconfig installer angelegt, da ist aber bei Dir scheinbar was schief gelaufen. Lege bitte mal einen zusätzlichen User ispconfig mit Rechten für die Datenbank dbispconfig02 mit phpmyadmin an, das Klartext-Passwort für den User findest Du in der Datei /usr/local/ispconfig/server/lib/config.inc.php

 

[mattula]

Bevor es VErwirrung gibt.

Zu spaet - du hast Mysql auf dem Gluster-FS laufen und richtest gleichzeitig auch noch Replikation ein?

 

[xxs]

Ne, habe keine Replikation, nur GlusterFS laut tutorial aus dem ersten Posting

 

[xxs]

Der User ispconfig wird auch vom ispconfig installer angelegt, da ist aber bei Dir scheinbar was schief gelaufen. Lege bitte mal einen zusätzlichen User ispconfig mit Rechten für die Datenbank dbispconfig02 mit phpmyadmin an, das Klartext-Passwort für den User findest Du in der Datei /usr/local/ispconfig/server/lib/config.inc.php

Der User ispconfig auf dem MasterServer (srv01) ist angelegt und hat auch entsprechende Rechte für die Datenbank (dbispconfig01), nur für den die Datenbank des Slaves (zweiter Server (srv02)) (dbispconfig02) hat er nicht die passenden Rechte

 

[xxs]

Habe jetzt noch mal beide Server neu aufgesetzt. Das mit der Replikation über GlusterFS geht jetzt alles.

Allerdings, wenn ich den ersten Server (Master) aufgesetzt habe, kann ich mich auch einloggen über das Webinterface, sobald ich aber den 2ten Server aufgesetzt habe geht alles gut bis zu dem Punkt wo ich ISPconfig aufsetzte, sobald ich dieses getan habe, kann ich mich am masterserver bei ISPconfig nicht mehr einloggen "Benutzername oder Passwort falsch.1"

 

[Till]

Versuch mal bitte folgendes:

1) Sichere die Dateien /usr/local/ispconfig/server/lib/config.inc.php und /usr/local/ispconfig/interafce/lib/config.inc.php auf dem Master.

2) Kopiere diese beiden Dateien vom slave und überschreibe die des Masters.

Versuch ob Du Dich dann wieder einloggen kannst.

 

[xxs]

Hm... Einloggen geht jetzt wieder, aber auf dem server srv01 wird in ISPconfig jetzt nur noch der Server srv02 angezeigt und srv01 exisiert nicht mehr...

Gut, wenn ich allerdings nur das Passwort für den user ispconfig ändere in den Config-Dateien auf dem MasterServer, dann geht es wieder.

 

[xxs]

Nun bleibt nur noch das Problem, dass weitere Dienste durch den user ispconfig auf die Datenbank zugreifen und dadurch nicht wirklich gehen (Auf jedenfall der Mailserver), daher wäre es jetzt noch sinnvoll zu wissen, wo ich das entsprechende Passwort noch ändern muss, bzw zu klären, wie es zu diesem Fehler kommt (ne, ist eigentlich klar wie es dazu kommt) aber ob man ihn irgendwo umgehen kann (z. B. bei der Installation das Passwort angeben kann, welches dann überall verwendet wird.)

 

[xxs]

Nachdem ich mit nun den Installer angeschaut habe, weiß ich wie und warum es zu dem Fehler kommt. Als Workaround müsste man wenn ich es richtig sehe nur eine Zeile in der folgenden Art hinzufügen

$conf['mysql']['ispconfig_password'] = $inst->free_query('Set iscpconfig mysql-password', $conf['mysql']['ispconfig_password']);

und bei den Slave-Servern das Passwort vom MasterServer angeben und anderenfalls einfach das Standart-Passwort bestätigen, bzw. das ganze nur beim Multi-Server Setup aufrufen für den fall, dass man die Datenbank per GlusterFS (oder ein anderes File-System) replizieren will.

Oder analog dazu das Löschen eines vorhanden users "ispconfig" unterbinden und einen alternativen usernamen (z.b. "ispconfig") angeben.

 

[Till]

Ich hatte ja im Post #2 des Threads beschrieben dass es in Kürze ein neues setup mit mysql matser/master Replikation geben wird da mysql über glusterfs nicht stabil läuft (siehe Anmerkungen die ich am Anfang des Cluster Tutorials geschrieben habe) und bei mysql master/master tritt das Problem nicht mehr auf da dort die mysql DB von der Replikation ausgenommen werden kann.

Oder analog dazu das Löschen eines vorhanden users "ispconfig" unterbinden und einen alternativen usernamen (z.b. "ispconfig") angeben.

sowas in der Art ist bereits in Planung.