Toggle sidebar Toggle sidebar

Migration auf neuen Server

C

condatec

Mitglied seit
18. Juli 2018
Beiträge
8
Wir möchten unsere 3CX Installation zu einem neuen Provider umziehen. Der alte Server sitzt bei OVH und soll nun zu einen neuen Server mit neuer IP. Wenn ich ein Backup ziehe und es bei der Installation des neuen Servers angebe, kommt 3CX dann mit den neuen IPs zurecht ? Der FQDN soll gleich bleiben.
 
Hallo condatec,

Ja, die Pbx kommt mittlerweile zurecht auch wenn man die Private IP im nachhinein ändert. Ich würde dir aber trotzdem empfehlen ein Backup ohne Lizenz und Fqdn zu machen.
Die Publik IP kannst du auch ändern ohne Probleme. Muss dafür nicht neuinstalliert werden.
Du muss aber beachten dass du bis 6 Stunden warten kannst bis die FQDN auf die neue IP ''zeigt''.

Gruß
Ilias
 
@ilias_3CX : Ich habe ein ähnliches Problem. Ich möchte unseren lokal gehostete 3CX Debian von einem Hyper V auf ein KVR System umziehen. Technisch bekomme ich das hin. Die 3CX bootet auf dem neuen Server, bekomme aber keinen Zugriff auf die Konsole. Denke das man da wohl mit der IP-Adresse was machen muss, da bestimmt das System eine neue Netzwerkkarte erkennt. Wie ist da das genau Prozedere? Wir habe aktuell die 16.0.8.9

Gruß Kay
 
  • Like
Reaktionen: tropicsoft
Ist ein Scale Comuputer Cluster der auf Basis KVM (nicht KVR) läuft. Ist aber wohl durch Scale angepasst.
Die VM läuft auch an. Denke das ich nur die virtuelle Netzwerkkarte zum Laufen bringen muss.
 
Oder wäre es sinnvoller die 3CX auf ein Windows Server laufen zu lassen?
 
Wir haben 3CX auf Debian nativ, auf Windows nativ, auf Debian und Windows unter Hyper V virtualisiert als auch auf Debian unter KVM (meist gleich Proxmox VE) virtualisiert am laufen. Insbesonders auf NUC ab Generation 8 ist es (bisher noch) sinnvoll einen Virtualisierer einzusetzen (z.B. Proxmox VE mit einer Debian 3CX) wegen der NIC Unterstützung (wegen dem Debian 9).

Wir hatten bisher (seit v15.5) auch noch nie Probleme der grundlegenden 3CX Installation beim Umzug von einer auf irgend eine andere Installation - egal ober vorher / hinterher virtualisiert oder nicht und auch egal ob Windows oder Debian. Der Einrichtungsassistent muss halt anlaufen (was er immer tun sollte), danach ein gleich altes oder minimal älteres Backup einspielen und danach läuft die bisherige 3CX Instanz grundlegend an. Es gibt noch die üblichen Nacharbeiten (IP, Firewall Checker, Backup usw.), aber selbst die meisten CFA sind wieder da. Spezielle 'Hacks', Skripte und schräge Erweiterungen bedürfen sowieso immer der Nacharbeit.
 
das heißt bedeutet auch die Übernahme von Lizenz und FQDN funktioniert problemlos?
Oder wie Ilias geschrieben hat, Backup ohne FQDN und Lizenz und beides im Nachhinein nachziehen?
Kann man den FQDN überhaupt im Nachhinein noch anpassen oder setze ich dem im Einrichtungsassistent, wo ich dann auch das Backup auswähle?
 
1) Ja.

2) Auch das funktioniert (sofern 3 passt).

3) Eine Lizenz ist immer an einen FQDN gekoppelt. Andersrum: sobald man eine vorhandene neue Lizenz mit einem FQDN verbindet ist diese Lizenz und auch der FQDN vergeben und ab da nicht anderweitig durch 3CX Installationen nutzbar. Man kann diese Kopplung Lizenz <-> FQDN im 3CX Lizenzportal aufheben und danach der Lizenz einen neuen FQDN zuweisen. Das wiederum geht bei der Installation einer neuen 3CX oder wenn man ein Backup ohne Lizenz / FQDN erstellt, die Anlage zurücksetzt, das Backup einspielt und dann im Einrichtungsassistenten diese Lizenz erneut an einen FQDN bindet. Voraussetzung für all das ist auch eine geeignete 3CX Lizenz. Das geht nur mit einer Pro aufwärts, siehe hier, unter Telefonie-Features mal aufklappen: Benutzerdefinierter FQDN.

Du hast doch das Basic Zertifikat gemacht, da war das doch dabei ;)
 
Zur Info. Es hat jetzt der Umzug von Hyper V auf KVM geklappt.
Folgendes habe ich gemacht:
Neue VM auf KVM (ScaleComputung Cluster) erstellt mit VLAN und den notwendigen Hardwareeinstellungen.
Dann an den Speicherort der Hyper-V Virtualdisk exportiert und VM wieder gelöscht. Die HYper-V Disk umbenannt wie die exportierte Festplatte aus KVM heißt und wieder die VM in KVM importiert.
VM fuhr hoch. Der virtuellen Netzwerkkarte dieselbe MAC-Adresse gegeben. Ich musste dann noch in der die Netzwerkschittstelle in der /etc/network/interfaces von eth0 auf ens3 ändern. Die 3CX läuft ohne eine weitere Anpassung.
 
Top!

Harte Kost: es wurde ja nicht neu installiert und ein Backup zurückgespielt sondern die ganze Disk ist von einem auf einen gänzlich anderen Hypervisor umgezogen. Ein weniger empfohlenes Szenario. Eine VHD ist auch weniger performant als eine qcow2 virtual disk. Aber generell: so etwas geht eben nur mit unixioden einigermaßen glimpflich ;)

Ich würde noch qemu-guest-agent und haveged installieren.
 
  • Like
Reaktionen: k.praag
@fxbastler Was macht der qemu-guest-Agent und haveged? Bin jetzt nicht so eine Linux-Koryphäe :)
 
  • Like
Reaktionen: k.praag
fxbastler schrieb:
Top!

Harte Kost: es wurde ja nicht neu installiert und ein Backup zurückgespielt sondern die ganze Disk ist von einem auf einen gänzlich anderen Hypervisor umgezogen. Ein weniger empfohlenes Szenario. Eine VHD ist auch weniger performant als eine qcow2 virtual disk. Aber generell: so etwas geht eben nur mit unixioden einigermaßen glimpflich ;)

Ich würde noch qemu-guest-agent und haveged installieren.
Zum Vergrößern anklicken....
Grins.... Habe die 2 Sachen installiert...
Noch eine andere Frage gleich:
Wir sichern den Cluster mit einer Acronis Cyper Protect Appliance.
Da bekomme ich die Meldung:
Die Aktivität 'Creating application-consistent (VSS) hypervisor snapshot' wurde mit folgender Warnmeldung abgeschlossen: 'Es wird ein crash-konsistenter Snapshot der virtuellen Maschine erstellt, weil kein applikationskonsistenter Snapshot von ihr erstellt werden konnte. Es können Applikationsdaten innerhalb des Backups betroffen sein.

Was kann man da machen?
 
Ist das ein Problem? Es steht doch da: kein VSS weil das in der debian VM nicht geht weil es das dort nicht gibt. Es wurde vmtl. kurz die VM angehalten, dieser temporär angehaltene Laufzeitzustand gesichert und dann die VM fortgesetzt.

Das wird bei den meisten (allen?) unixoiden / allen Nicht-Windows VM unter Hyper V mit solcher Art Sicherung passieren. Die kennen keine Volumesnapshot Technologie welche einen solchen (von aussen von der Sicherungssoftware auf dem Hyper V) auslöst. Das ist vmtl. auch unabhängig vom Dateisystem der VM. Ich weiss nicht konkret wie es sich verhält wenn man btrfs oder ZFS (welche Version dann wiederum?) in der VM nutzt (geht eh nicht komplett) weil diese Snapshots kennen und können. Eventuell gibt es spezielle Pakete oder extra Tools für so etwas, eventuell gar von Acronis. Das ist eine gänzlich andere Thematik.

Fazit: eine so gesicherte VM funktionssicher wiederherzustellen, insbes. mit einer aktiv genutzten DB und verschiedenen Abhängigkeiten zur Laufzeit und zeitkritischen Komponenten, ist absehbar zum Scheitern verurteilt. Zumindest wird die nicht dauerhaft sicher voll funktionsfähig wiederherstellbar sein. Aber die grundlegende Installation und das (hoffentlich) eingerichtete automatische Backup der 3CX inerhalb der VM ist ja noch da und wird reichen zur Wiederherstellung eines konsistenten Zustandes innerhab der VM.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: k.praag
Vielen Dank für die detaillierte Erklärung.
 
Wir migrieren auch von v16 auf v18 und übersiedeln die Installation auf einen neuen Windows Server 2019.
Wenn ich das Backup aus v16 ohne Lizenz und FQDN exportiere und bei der v18 Neuinstallation auswähle werde ich nach einem Lizenzschlüssel und an eine dazugehörige Bindung.

Ist hier der erworbene Lizenzschlüssel zu verwenden oder vorerst eine Free-Lizenz.

Bevor ich unsere Anlage schieße frag ich lieber mal in die Runde.
 
Warum nicht mit Lizenz und FQDN exportieren und wieder importieren?
 
Weil wir im Hintergrund die neue Version auch auf SSO um konfigurieren, der Server in eine anderes Subnetz wandert, einige FW-Policies dahingehend angepasst werden müssen, ...
Einfach zu viele Dinge um einen Umstieg von jetzt auf gleich zu wagen.
 
Ich würde nicht immer alles auf einmal machen. Subnetz und Firewall hat ja nichts mit der 3CX zu tun, das sollte ja schon vorher konfiguriert sein. Das einspielen das Backups mit Lizenz und FQDN erspart Dir da die Arbeit alles neu anzugeben. SSO erst nach dem erfolgreichen Upgrade und Umzug.
 
  • Like
Reaktionen: fxbastler
Um antworten zu können musst du eingeloggt sein.

Einstieg für Admins

Statistik des Forums

Themen
44.414
Beiträge
232.721
Mitglieder
78.331
Neuestes Mitglied
b2daniel
3CX Logo Footer Copyright © Sitemap Datenschutz Impressum
Oben Unten