IspConfig -- Slave Installation

[typoworx]

Hallo,
ich möchte meine IspConfig "single" Instanz gerne aufräumen und den Diensten einen separaten ESXi Host gönnen. Hierzu habe ich noch folgende Fragen, die ich leider mit Info im Netz nicht endgültig klären konnte.
- Benötigt jede Slave-Instanz eine eigene MySQL Datenbank oder kann die DB der Master-Instanz mit verwendet werden?
(Sicherheitstechnisch kein Problem, da der Zugriff über ein internes, lokales ESXi VM-Netz erfolgt!)
- Ist es möglich parallel zwei Web-Instanzen als Slave an einer Master-Instanz zu betreiben für einen Web-Server auf Apache-Basis und eine weitere Instanz für NGINX?

Gibt es sonst noch etwas hierbei zu beachten? Kann ich die neuen Dienste gefahrlos als Slave nachträglich aktivieren während die Master-Instanz noch produktiv läuft (Backup existiert natürlich!)?

Für eine kurze Rückmeldung hierzu bedanke ich mich im Voraus.

 

[Till]

- Benötigt jede Slave-Instanz eine eigene MySQL Datenbank oder kann die DB der Master-Instanz mit verwendet werden?
(Sicherheitstechnisch kein Problem, da der Zugriff über ein internes, lokales ESXi VM-Netz erfolgt!)

Jeder node hat eine eigene MySQL Instanz.

- Ist es möglich parallel zwei Web-Instanzen als Slave an einer Master-Instanz zu betreiben für einen Web-Server auf Apache-Basis und eine weitere Instanz für NGINX?

ja.

Kann ich die neuen Dienste gefahrlos als Slave nachträglich aktivieren während die Master-Instanz noch produktiv läuft (Backup existiert natürlich!)?

ja

 

[typoworx]

Jeder node hat eine eigene MySQL Instanz.
ja

Danke für die schnelle Info. Ist es alternativ auch möglich den Slave auf der selben MySQL Instanz wie den Master zu betreiben mit einem anderen DB-Namen? Ich möchte ehrlich gesagt ungerne soviele separate MySQL Instanzen betreiben und dafür lieber eine Instanz die dafür mit viel RAM performant konfiguriert ist.

 

[Till]

Sowas haben ein paar leute glaube ich manuell konfiguriert am Laufen, wird aber nicht offiziell unterstützt da es zu einem single point of failure führt. Außerdem ist es gerade bei größeren Systemen schlecht für die performance.

 

[typoworx]

Danke. Das hat mir schon mal sehr geholfen!

Außerdem ist es gerade bei größeren Systemen schlecht für die performance.

Das stimmt natürlich. Aber wenn ich die Slave-Instanzen mit etwas weniger RAM betreibe wird es eng für MySQL-Instanz + die Dienst-Instanz die ich auslagern will. Ist defakto dann sicherlich auch nicht sonderlich Performant, wenn man nicht beliebig viel RAM für jede Instanz spendieren kann/will.
Der Punkt mit single point of failure stimmt natürlich. Könnte man alternativ aber auch mittels Replikation abfangen. Aber verständlich, dass ispConfig hier nicht out-of-the-box jedes Wunsch-Szenario unterstützt (per Installer).

 

[typoworx]

@Till
Ich habe mich dazu entschlossen doch erst mal mit einer Single MySQL-Instanz zu testen. Hierfür habe ich auf dem MySQL separate Benutzer für root Zugriff auf dbispconfig (=existente master Instanz) eingerichtet sowie einen weiteren Benutzer für die Slave-Instanz. Das waren bei meinem Test "ispconfig-master" (GRANT ALL für dbipconfig.*) sowie ispconfig-mail01 (GRANT ALL für dbispconfig_mail01.*).

Das klappt scheinbar auch! Jedoch werden bei dem Create-User Query (siehe lib/installer_base.lib.php) offenbar die DB-Credentials durcheinander geworfen - was normalerweise mit einem Benutzer oder zwei Benutzern mit Root-Rechten nicht auffallen dürfte?!

GRANT SELECT, INSERT, UPDATE, DELETE ON dbispconfig_mail01.* TO ispconfig@mx01.mein-toller-server.xxx IDENTIFIED BY [irgendwas-kryptisches]

Ein (kleineres) Manko bei dem o.g. Query ist auch, dass ich eigentlich einen lokalen Alias mit lokaler VM-Net IP verwende für den MySQL-Server (definiert unter /etc/hosts als "mysql01"). Dieser wird dann aber in dem o.g. Query dass ich mir als Debug ausgebe ohne mein Wissen aufgelöst zu dem "echten" Hostname der im Installer als "Fully qualified hostname" abgefragt wird! Hier wäre es aber eigentlich korrekt, dass der selbe Hostname verwendet wird, der auch als DB-Hostname beim Installer angegeben wird.

//if($conf['mysql']['host'] == 'localhost') {
if($conf['mysql']['master_host'] == 'localhost') {
$from_host = 'localhost';
} else {
//-- $from_host = $conf['hostname'];
$from_host = $conf['mysql']['master_host'];
}

Das Problem hat mich einige Zeit gekostet, da ich so noch mal dem Benutzer im MySQL ein GRANT auf den anderen Hostname geben musste und zunächst erst mal gar nicht klar war wieso der Zugriff immerzu verweigert wurde.

Oder übersehe ich da irgendwas? Soll ich dazu mal ein Ticket im Bugtracker erstellen? Ich denke, dass es sich hier wirklich um 1-2 kleinere Bugs handeln könnte die zumindest in einem etwas komplexeren "Expert" Setup auffallen. Bei einer Single-Instanz Installation mit einem einzigen Root-Benutzer hingegen scheinbar nicht.

 

[Till]

ISPConfig löst den Hostnamen des mailservers auf, das ist so gewollt. Das zu ändern würde vermutlich auch einige zehntausend multiserver systeme beim nächsten Update killen, also keine gute Idee in meinen Augen Hast Du denn auf allen nodes jeweils den hostnamen des masters und des slaves in der /etc/hosts Datei in folgendem Format?

192.168.1.100 server1.example.com server1

ISPConfig legt seinen MySQL user auf Master und auf slave immer selbst an, Du musst daher immer einen User der root priveliges hat verwenden wenn der Installer nach dem root user fragt. Einen auf dbispconfig limitierten User, so wie Du es gemacht hast, kann man da nicht nehmen.

 

[typoworx]

ISPConfig legt seinen MySQL user auf Master und auf slave immer selbst an, Du musst daher immer einen User der root priveliges hat verwenden wenn der Installer nach dem root user fragt. Einen auf dbispconfig limitierten User, so wie Du es gemacht hast, kann man da nicht nehmen.

Das habe ich inzwischen auch bemerkt - aber dennoch so hin bekommen. Mein Slave läuft jetzt in der selben MySQL-Instanz als dbispconfig_mail01. Es gab hier jedoch etliche Fehlermeldungen beim Anlegen des User ispsrv seitens des Install-Skript. Den User musste ich letztendlich dann selbst mit entsprechend eingeschränkten Rechten anlegen. Nun klappt es aber.