Migration-Tool + Multiserversetup

[somnium]

Hallo zusammen,

ich habe letzte Woche das Migration-Tool gekauft und habe damit etwas herum gespielt. So wirklich glücklich bin ich noch nicht damit. Aber der Reihe nach:
Ich habe ein Multiserver-Setup
- ISPC-Webinterface
- WEB1 (Apache auf U14.04)
- WEB2 (NginX auf U16.04)
- WEB3 (Apache auf U16.04 ***NEU***)
- Mailrelay (U16.04)

Jetzt möchte ich die Webseiten des WEB1 (U14.04 mit PHP5) auf den neuen, noch leeren WEB3 kopieren und die Kundenwebsites mit PHP7 zu testen (die meisten Kunden haben Null Ahnung, daher mache ich das). Das Kopieren und Testen funktioniert auch. Jetzt möchte ich einen Kunden auf den WEB3 "produktiv" nehmen - und genau hier hapert es. Wie bringe ich ISPC bei, dass der Kunde jetzt nicht mehr auf WEB1 sondern WEB3 liegt? Muss ich den zwischengeschalteten Reseller (bin ich auch selbst) unter den Templates/Limits um WEB3 erweitern und anschließend den Kunden über Limits den WEB1 weg nehmen und WEB3 zuweisen? Irgendwie stehe ich auf dem Schlauch.

Habe noch weitere Fragen, die stelle ich aber erst wenn dieser Thread gelöst ist.

Vielen Dank und vG
Marc

 

[Till]

Mit dem Migrationstool kannst Du sowohl single- als auch multiserver migrieren. aber es müssen für eine Migration aber immer 2 server sein, ein quellsystem und ein zielsystem. Wobei wuelle und ziel single oder auch multiserver setups sein können, das geht beides. Bei dem was Du oben abgebildet hast sind aber quelle und Zeil der selbe Master und das kann nicht gehen, denn eine Webseite kann nur einmal auf einem master existieren und nicht 2 mal und somit kann das Migrationstool, welches sich ja imemr mitd em master verbindet, den slave serevr bnicht kopieren. das obige würde nur funktionieren wenn 23b3 entweder ein single server ist oder aber an einem anderen master als web1 hängt.

 

[Croydon]

Theoretisch geht das, allerdings muss man beachten, dass sich dabei natürlich die web IDs ändern und somit die Pfade der Webs. Relevant ist das vor allem, wenn dort Software läuft, die Pfade irgendwo speichert (file oder DB).
Da im obigen Setup Quell- und Zielmaster derselbe Server sind, ist es essenziell, ein Backup des Masters zu machen, insbesondere der ISPConfig Datenbank, denn es könnte passieren, dass Kundendaten modifiziert werden. Ein großes Problem wird es, wenn die Kunden Templates nutzen, die könnten komplett durcheinandergeraten.
Anschließend (das kann das Migtool nicht, da es hierfür nicht gedacht ist), muss bei den Kunden der Default Server umgestellt werden. Normalerweise sollte es dann reichen, im DNS die IP der Domains vom alten auf den neuen Webserver umzustellen und, wenn dann alles läuft, die Daten der Webseiten in ISPConfig zu löschen, die auf dem alten Server liegen.
Grundsätzlich ein heikles Unterfangen, es ist immer zu empfehlen, nur Systeme auf die Art zu migrieren, die NICHT denselben ISPConfig Master haben.

 

[somnium]

Danke für Eure Antworten. Hmm, da hätte ich vor dem Kauf wohl etwas mehr lesen sollen ;-)
Egal... verbuche ich als Spende für das großartige ISPC-Projekt!

Aber jetzt nochmal zu meinem Problem bzw. zum korrekten Vorgehen. Ziel ist es, die Webseiten von WEB1 einzeln, Stück für Stück auf WEB3 zu migrieren - zur Not auch per Hand. Die UID und GID sowie die MySQL-Users sollten natürlich identisch sein/bleiben. Ich stehe gerade echt auf dem Schlauch. Ist es so ungewöhnlich, dass man einen Kunden von einem Server auf einen Anderen im Multi-Setup ziehen möchte? Wie machen es denn die Großen wenn ein Distri-Update ansteht? Bauen die direkt neue, eigenständige ISPC-Installationen auf und kopieren dann alle Daten samt IP-Adresse rüber? Und wenn dann Webseiten der Kunden nicht laufen?
Wie läuft das z.B. bei Timme-Hosting?
Vielleicht habe ich auch einen Gedankenfehler oder mache es mir viel zu kompliziert?!

 

[Till]

Wie machen es denn die Großen wenn ein Distri-Update ansteht?

Backup zur Sicherheit (immer) und dann einfach das Distributionsupdate durchführen. Bei Debian und Ubuntu geht sowas recht problemlos. Ich habe hier ISPConfig Server die werden seit Debian 3.0 ohne Neuinstallation upgegraded. Oder alternativ den kompletten server kopieren (z.B. mit rsync oder tar), also ein Duplikat des servers erstellen und dann das Duplikat upgraden während der live server aktiv bleibt und dann die Server tauschen.

Ich arbeite z.B. immer mit Virtuellen Maschinen, also auch wenn nur eine VM auf einem Server ist. Das ermöglicht mir:

1) Einfache Backups durch snapshots.
2) Einfacher Umzug auf neue Hardware, denn ich ziehe die komplette VM um.
3) Dist upgrade? Ich starte einfach eine Kopie der VM auf einer 2. IP, mache das dist upgrade und schalte dan die alte VM ab und starte die neue auf der ursprünglichen IP.

So wie Du es machen willst geht es antürlich auch, also nur teilweise Inhalte eiens Servers verschieben, ist nur aufwändiger. Die Vorgehensweise ist die:

1) Die web* user und client* Gruppen aus /etc/passwd, shadow, group und gshadow Datei auf den neuen server übernehmen. wichtig, nur diese zeilen und nicht alle!
2) /var/vmail und /var/www z.B. mit rsync unter beibehaltung der rechte auf den neuen server kopieren.
3) Die MySQL Datenbanken auf dem alten server dumpen und auf den neuen server wieder einfügen.
4) Bind mount Zeilen in /etc/fstab übernehmen.
5) in ispconfig's config.inc.php Dateien kannst Du die server_id des alten servers übernehmen, dann muss der alte aber auch deaktiviert werden. alternativ könntest Du auch die server_id's in der master db und lokalen DB auf die ID des neuen servers ändern. ich denke aber das ist aufwändiger als die erste Lösung.
6) und am Ende muss ein rsync in ISPConfig sein, damit er die fehlenden config Dateien für vhosts etc. anlegt.

Wir arbeiten an einem Tool um solche art der Migration zu automatisieren, aber das braucht nach vermutlich bis Ende des Jahres. Denn das aktuelle Migrationstool hat einen ganz anderen Ansatz durch die Nutzung des ISPConfig API, was viele Vorteile bringt aber eben auch die von Mir oben genannten Einschränkunden. wobei, wie Crydon ja ausgeführt hat, es durchaus möglich sein kann es auch mit dem aktuellen Tool zu machen seit ISPConfig 3.1 das auch mehere identische domains pro server erlaubt, getestet habe ich es aber noch nicht und ich weiß nicht ob es nicht z.B. bei FTP usern etc. zu Problemen kommen könnte.

 

[florian030]

3) Die MySQL Datenbanken auf dem alten server dumpen und auf den neuen server wieder einfügen.

Und dann noch /etc/mysql/debian.cnf vom alten auf den neuen Server kopieren.

Wenn Du nur eine Webseite umziehen willst, kannst Du auch in der DB die passenden server_id ändern und mit resync auf den neuen Server schreiben lassen (das läuft aber immer noch auf dem alten Server) und dann kannst Du die DB und /var/www/clientsX/webY kopieren und den DNS ändern.

Wenn Du nur PHP 7 testen willst, kannst Du auch PHP 7 als zusätzliche Version installieren, für die Webseite aktivieren und nachsehen.

 

[nowayback]

Wenn Du nur PHP 7 testen willst, kannst Du auch PHP 7 als zusätzliche Version installieren, für die Webseite aktivieren und nachsehen.

Sozusagen ein LIVE Test beim Kunden der im Zweifelsfall nur paar unwesentliche Euro verliert, die er auch dann bestimmt nicht von dir haben will ;-)

 

[florian030]

Die paar Minuten kann man ja vorher ankündigen / vereinbaren. Entweder gehts mit 7.x oder nicht. Probleme gibts eher mit typo3. Die sonstigen üblichen Verdächtigen haben mit php7 kein Problem.