Server Setup · 7 min read · Sep 28, 2025

Installation eines Web-, E-Mail- und MySQL-Datenbankclusters auf Debian 6.0 mit ISPConfig 3

Installation eines Web-, E-Mail- und MySQL-Datenbankclusters auf Debian 6.0 mit ISPConfig 3

Version 1.0
Autor: Till Brehm

Dieses Tutorial beschreibt die Installation eines clusterbasierten Web-, E-Mail-, Datenbank- und DNS-Servers, der für Redundanz, hohe Verfügbarkeit und Lastverteilung auf Debian 6 mit dem ISPConfig 3 Steuerungsfeld verwendet wird. MySQL Master/Master-Replikation wird verwendet, um die MySQL-Clientdatenbanken zwischen den Servern zu replizieren, und Unison wird verwendet, um die /var/www (Websites) und /var/vmail (E-Mail-Kontodaten) Ordner zu synchronisieren.

1 Einrichtung der beiden Basissysteme

In diesem Setup gibt es einen Master-Server (der die ISPConfig-Steuerungsschnittstelle ausführt) und einen Slave-Server, der die Web- (apache), E-Mail- (postfix und dovecot) und Datenbank- (MySQL) Dienste des Master-Servers spiegelt.

Um das clusterbasierte Setup zu installieren, benötigen wir zwei Server mit einer minimalen Debian 6.0-Installation. Die Basiseinrichtung wird im folgenden Tutorial in den Schritten 1 - 8 beschrieben:

https://www.howtoforge.com/perfect-server-debian-squeeze-with-bind-and-dovecot-ispconfig-3

Installieren Sie nur die Schritte 1 - 8 des perfekten Server-Tutorials und nicht die anderen Schritte, da sie sich für ein clusterbasiertes Setup unterscheiden!

In meinem Beispiel verwende ich die folgenden Hostnamen und IP-Adressen für die beiden Server:

Master-Server

Hostname: server1.example.tld
IP-Adresse: 192.168.0.105

Slave-Server

Hostname: server2.example.tld
IP-Adresse: 192.168.0.106

Wo auch immer diese Hostnamen oder IP-Adressen in den nächsten Installationsschritten vorkommen, müssen Sie sie ändern, um mit den IPs und Hostnamen Ihrer Server übereinzustimmen.

2 Installation der beiden Server

Die folgenden Schritte müssen sowohl auf dem Master- als auch auf dem Slave-Server ausgeführt werden. Wenn ein bestimmter Schritt nur für den Master oder Slave ist, habe ich eine Anmerkung in der Beschreibung in Rot hinzugefügt.

vi /etc/hosts
127.0.0.1       localhost
192.168.0.105   server1.example.tld
192.168.0.106   server2.example.tld

# Die folgenden Zeilen sind wünschenswert für IPv6-fähige Hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Setzen Sie den Hostnamen des Servers:

echo server1.example.tld > /etc/hostname
/etc/init.d/hostname.sh start

Verwenden Sie server1.example.tld auf dem ersten Server und server2.example.tld auf dem zweiten Server.

Bearbeiten Sie die sources.list-Datei…

vi /etc/apt/sources.list 

… und stellen Sie sicher, dass Ihre /etc/apt/sources.list das squeeze-updates-Repository enthält (dies stellt sicher, dass Sie immer die neuesten Updates für den ClamAV-Virenscanner erhalten - dieses Projekt veröffentlicht sehr häufig Releases, und manchmal hören alte Versionen auf zu funktionieren).

[...]  
deb http://ftp.de.debian.org/debian/ squeeze-updates main  
[...]  

Führen Sie aus

apt-get update
apt-get upgrade

um die neuesten Updates zu installieren (falls vorhanden).

Es ist eine gute Idee, die Systemuhr mit einem NTP ( n etwork t ime p rotokoll) Server über das Internet zu synchronisieren. Führen Sie einfach aus

apt-get -y install ntp ntpdate

und Ihre Systemzeit wird immer synchronisiert sein.

Auf Server 1:

Jetzt erstellen wir ein privates/öffentliches Schlüsselpaar auf server1.example.tld:

ssh-keygen -t dsa

root@server1:~# ssh-keygen -t dsa
Generiere ein öffentliches/privates dsa-Schlüsselpaar.
Geben Sie die Datei an, in der der Schlüssel gespeichert werden soll (/root/.ssh/id_dsa): <– ENTER
Verzeichnis ‘/root/.ssh’ erstellt.
Geben Sie eine Passphrase ein (leer für keine Passphrase): <– ENTER
Geben Sie dieselbe Passphrase erneut ein: <– ENTER
Ihre Identifikation wurde in /root/.ssh/id_dsa gespeichert.
Ihr öffentlicher Schlüssel wurde in /root/.ssh/id_dsa.pub gespeichert.
Der Fingerabdruck des Schlüssels ist:
1b:95:bc:4a:f4:9f:d8:ea:24:31:0f:c9:72:d5:a7:80 [email protected]
Das zufällige Bild des Schlüssels ist:
+–[ DSA 1024]—-+
| |
| o o |
| E * . . |
| o = o o |
| . S o . |
| + O + . |
| + + + |
| o . |
| .o |
+—————–+
root@server1:~#

Es ist wichtig, dass Sie keine Passphrase eingeben, da die Spiegelung sonst nicht ohne menschliches Eingreifen funktioniert, also drücken Sie einfach ENTER!

Als nächstes kopieren wir unseren öffentlichen Schlüssel nach server2.example.tld:

ssh-copy-id -i $HOME/.ssh/id_dsa.pub [email protected]

root@server1:~# ssh-copy-id -i $HOME/.ssh/id_dsa.pub [email protected]
Die Authentizität des Hosts ‘192.168.0.101 (192.168.0.101)’ kann nicht festgestellt werden.
Der RSA-Schlüsselfingerabdruck ist 25:d8:7a:ee:c2:4b:1d:92:a7:3d:16:26:95:56:62:4e.
Sind Sie sicher, dass Sie mit der Verbindung fortfahren möchten (ja/nein)? <– ja (dies sehen Sie nur, wenn dies das erste Mal ist, dass Sie sich mit server2 verbinden)
Warnung: ‘192.168.0.101’ (RSA) dauerhaft zur Liste der bekannten Hosts hinzugefügt.
[email protected] ‘s Passwort: <– server2 root Passwort
Versuchen Sie jetzt, sich mit “ssh ‘ [email protected] ‘“ in die Maschine einzuloggen, und überprüfen Sie:

 .ssh/authorized_keys
um sicherzustellen, dass wir keine zusätzlichen Schlüssel hinzugefügt haben, die Sie nicht erwartet haben.

Überprüfen Sie jetzt auf server2, ob der öffentliche Schlüssel von server1 korrekt übertragen wurde:

server2:

cat $HOME/.ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBAPhiAexgEBexnw0rFG8lXwAuIsca/V+lhmv5lhF3BqUfAbL7e2sWlQlGhxZ8I2UnzZK8Ypffq6Ks+lp46yOs7MMXLqb7JBP9gkgqxyEWqOoUSt5hTE9ghupcCvE7rRMhefY5shLUnRkVH6hnCWe6yXSnH+Z8lHbcfp864GHkLDK1AAAAFQDddQckbfRG4C6LOQXTzRBpIiXzoQAAAIEAleevPHwi+a3fTDM2+Vm6EVqR5DkSLwDM7KVVNtFSkAY4GVCfhLFREsfuMkcBD9Bv2DrKF2Ay3OOh39269Z1rgYVk+/MFC6sYgB6apirMlHj3l4RR1g09LaM1OpRz7pc/GqIGsDt74D1ES2j0zrq5kslnX8wEWSHapPR0tziin6UAAACBAJHxgr+GKxAdWpxV5MkF+FTaKcxA2tWHJegjGFrYGU8BpzZ4VDFMiObuzBjZ+LrUs57BiwTGB/MQl9FKQEyEV4J+AgZCBxvg6n57YlVn6OEA0ukeJa29aFOcc0inEFfNhw2jAXt5LRyvuHD/C2gG78lwb6CxV02Z3sbTBdc43J6y [email protected]

Installieren Sie postfix, dovecot und mysql mit einem einzigen Befehl:

apt-get -y install postfix postfix-mysql postfix-doc mysql-client mysql-server openssl getmail4 rkhunter binutils dovecot-imapd dovecot-pop3d sudo

Geben Sie das neue Passwort für den MySQL-Root-Benutzer ein, wenn Sie vom Installer dazu aufgefordert werden. Sie sollten dasselbe Passwort für beide Server wählen. Beantworten Sie dann die nächsten Fragen wie unten beschrieben:

Allgemeiner Typ der Konfiguration? <– Internetseite
Mail-Name? <– server1.mydomain.tld
SSL-Zertifikat erforderlich <– Ok

Verwenden Sie server1.example.tld auf dem ersten Server und server2.example.tld auf dem zweiten Server.

Wir möchten, dass MySQL auf allen Schnittstellen hört, nicht nur auf localhost, daher bearbeiten wir /etc/mysql/my.cnf und kommentieren die Zeile bind-address = 127.0.0.1 aus:

vi /etc/mysql/my.cnf
[...]  

# Anstelle von skip-networking hört die Standardeinstellung jetzt nur auf  
# localhost, was kompatibler ist und nicht weniger sicher ist.  
#bind-address           = 127.0.0.1  

[...]  

Starten Sie dann MySQL neu:

/etc/init.d/mysql restart

Jetzt bereiten wir die MySQL-Server für die MySQL Master/Master-Replikation vor.

Auf Server 1:

Melden Sie sich in MySQL an der Shell an…

 mysql -u root -p

… und geben Sie das MySQL-Root-Passwort ein, das Sie während der MySQL-Installation gewählt haben. Führen Sie dann diesen Befehl in der MySQL-Shell aus:

GRANT REPLICATION SLAVE ON . TO ‘slaveuser’@’%’ IDENTIFIED BY ‘slave_user_password’;
FLUSH PRIVILEGES;
quit;

Ersetzen Sie ‘slave_user_password’ durch ein sicheres Passwort, das Sie verwenden möchten, damit der Slave sich mit dem Master-Server verbindet. Ersetzen Sie diesen Platzhalter in den nächsten Schritten durch das Passwort, das Sie gewählt haben, wo immer der Platzhalter vorkommt.

Jetzt konfigurieren wir unsere 2 MySQL-Knoten:

Auf Server 1:

vi /etc/mysql/my.cnf

Suchen Sie nach dem Abschnitt, der mit [mysqld] beginnt, und fügen Sie die folgenden Optionen hinzu (kommentieren Sie alle vorhandenen konfliktierenden Optionen aus):

[...]  
[mysqld]  
server-id = 1  
replicate-same-server-id = 0  
auto-increment-increment = 2  
auto-increment-offset = 1  
 
master-host = 192.168.0.106  
master-user = slaveuser  
master-password = slave_user_password  
master-connect-retry = 60   
 
expire_logs_days        = 10  
max_binlog_size         = 500M  
log_bin                        = /var/log/mysql/mysql-bin.log  
[...]  

Stoppen Sie dann MySQL:

/etc/init.d/mysql stop

Jetzt machen wir fast dasselbe auf server2…

Auf Server 2:

vi /etc/mysql/my.cnf

Suchen Sie nach dem Abschnitt, der mit [mysqld] beginnt, und fügen Sie die folgenden Optionen hinzu (kommentieren Sie alle vorhandenen konfliktierenden Optionen aus):

[...]  
[mysqld]  
server-id = 2  
replicate-same-server-id = 0  
auto-increment-increment = 2  
auto-increment-offset = 2  
   
master-host = 192.168.0.105  
master-user = slaveuser  
master-password = slave_user_password  
master-connect-retry = 60  
 
expire_logs_days        = 10  
max_binlog_size         = 500M  
log_bin                        = /var/log/mysql/mysql-bin.log  
[...]  

Stoppen Sie dann MySQL:

/etc/init.d/mysql stop

Jetzt müssen wir die beiden MySQL-Server synchronisieren. Wir tun dies, indem wir das MySQL-Datenverzeichnis vom Master auf den Slave kopieren und auch die Debian-Konfigurationsdatei, die den debian-sys-maint-Benutzer enthält. Dies kann getan werden, da wir MySQL zuvor auf beiden Servern gestoppt haben.

Auf Server 1:

scp -pr /var/lib/mysql/* [email protected]:/var/lib/mysql/
scp -pr /etc/mysql/debian.cnf [email protected]:/etc/mysql/debian.cnf

Jetzt starten wir MySQL auf dem Master-Server wieder:

/etc/init.d/mysql start

Melden Sie sich als Root-Benutzer in der MySQL-Shell an…

mysql -u root -p

… und führen Sie diesen Befehl in der MySQL-Shell aus…

 SHOW MASTER STATUS; 

… um den MySQL-Masterstatus zu erhalten:

mysql> SHOW MASTER STATUS;
+——————+———-+————–+——————+
| Datei | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000002 | 106 | | |
+——————+———-+————–+——————+
1 Zeile in Menge (0.00 sec)

Die Informationen, die wir für den nächsten Schritt benötigen, sind die Binlog-Datei mysql-bin.000002 und die Binlog-Position 106. Wir benötigen dieselben Details später für server2.

Führen Sie dann diesen Befehl in der MySQL-Shell auf dem Master aus, um ihn mit dem Slave zu verbinden:

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST=’192.168.0.106’, MASTER_USER=’slaveuser’, MASTER_PASSWORD=’slave_user_password’, MASTER_LOG_FILE=’mysql-bin.000002’, MASTER_LOG_POS=106;
START SLAVE;

Überprüfen Sie dann den Slave-Status:

SHOW SLAVE STATUS \G

Es ist wichtig, dass sowohl Slave_IO_Running als auch Slave_SQL_Running den Wert Ja in der Ausgabe haben.

Auf Server 2:

Melden Sie sich als Root-Benutzer in der MySQL-Shell an…

mysql -u root -p

… und führen Sie diesen Befehl in der MySQL-Shell aus:

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST=’192.168.0.105’, MASTER_USER=’slaveuser’, MASTER_PASSWORD=’slave_user_password’, MASTER_LOG_FILE=’mysql-bin.000002’, MASTER_LOG_POS=106;
START SLAVE;

Überprüfen Sie dann den Slave-Status:

SHOW SLAVE STATUS \G

Es ist wichtig, dass sowohl Slave_IO_Running als auch Slave_SQL_Running den Wert Ja in der Ausgabe haben.

Die Konfiguration der MySQL Master/Master-Replikation ist jetzt abgeschlossen, und wir fahren mit der Installation der anderen Softwarepakete fort.

Share: X/Twitter LinkedIn

Erhalte neue Beiträge in deinem Posteingang.

Kein Spam. Jederzeit abmelden.