Frage Können RHEL6-Server "kopiert" werden?


Meine Firma muss einen Entwicklungsserver einrichten und wir haben bereits 2 RHEL 6-Server, die unter einem L4-Switch arbeiten.

Eine der Lösungen zum Einrichten des Dev-Servers bestand darin, einfach alle Dateien von einem der Produktionsserver zu kopieren und ein wenig zu optimieren.

Ich habe es noch nie zuvor getan, aber es klingt ähnlich wie Geisterbilder ... kann es gemacht werden? Ist es empfehlenswert? Wäre es anfällig für Fehler?


7
2017-08-22 18:53


Ursprung




Antworten:


Das Kopieren aller Dateien könnte funktionieren. Es hängt vom Betriebssystem und von der Art der Kopiermethode ab.

Ein allgemeines Problem besteht darin, das System zu kopieren, während es ausgeführt wird. In der Regel sind mindestens einige der Dateien gesperrt und werden daher nicht korrekt kopiert. Die Verwendung einer Art von Bildbearbeitungssoftware während des Herunterfahrens des Systems ist normalerweise am sichersten (Sie erwähnten Ghost als Beispiel)


7
2017-08-22 18:59



Es ist RHEL6. Kann es gemacht werden? - dK3
RSYNC ist für die Spiegelung konzipiert und auf nahezu jedem System verfügbar. Sie können das verwenden. - Jeff Clayton
Klingt gut. Danke :) - dK3
Was meinst du mit "verschlossen"? Das ist eine ziemlich Windows-Ansicht der Dinge. Das übliche Problem mit dem Kopieren eines Live-FS in UNIX ist, dass Dateien sich unter Ihnen ändern, während sie kopiert werden. - MadHatter
... ein Problem, das bei Systemen vermieden werden kann, die LVM verwenden, indem LVM-Snapshots verwendet werden, um ein konsistentes Image des zugrunde liegenden Blockgeräts zu erstellen und es zu duplizieren, anstatt Kopiervorgänge auf Dateisystemebene auszuführen. - Charles Duffy


Warum konvertieren Sie die laufenden Systeme nicht in virtuelle Maschinen? Die meisten Hypervisors wie VMware oder Hyper-V verfügen über ein Tool, mit dem ein laufendes System problemlos in eine virtuelle Maschine konvertiert werden kann.

Sie können dann mit einem nicht produktiven System arbeiten, bevor Sie etwas auf einem Produktionsserver tun.

Danke an @WernerCD

Vmware

Hyper-V


17
2017-08-22 19:05



Ich fürchte, diese Art von Veränderung ist außerhalb des Bildes ... - dK3
@ dK3 Ich glaube du verstehst falsch. Sie würden die Produktionsserver nicht ändern (außer Sie möchten). Sie würden ein kleines Tool auf einem der Produktionsserver installieren, damit Ihre VM-Lösung es "erkunden" und ein Image erstellen kann. Sie installieren die VM-Lösung in Ihrer Entwicklungsumgebung und zeigen sie auf das "konvertierte" Image Ihres Produktivservers. Also, wenn du es nicht tust bereitseine Entwicklungsumgebung haben, ist diese Lösung keine "Änderung" ... - svidgen
Google P2V Physisch zu virtuell - Vmware: my.vmware.com/web/vmware/evalcenter?p=converter - HyperV: social.technet.microsoft.com/wiki/contents/articles/... - Virtualisieren, sichern, isolieren (also wenn es auf eine Produktionsdatenbank hinweist) und dann Spaß haben - WernerCD


Kann es gemacht werden?

Definitiv Ja. Ich habe einen ganzen Linux-Server kopiert, indem ich einfach die Dateien zusammenpacke tar und extrahierte sie erneut auf dem Zielserver. Die einzige Einschränkung, an die ich mich erinnere, war, sich daran zu erinnern, sie zu benutzen --numeric-owner beim Extrahieren. Ich kann nicht für andere Betriebssysteme und andere Tools sprechen, aber ich kann mir vorstellen, dass dies mit allen gängigen Betriebssystemen möglich ist.

Sollte es getan werden?

Diese Frage ist etwas komplizierter zu beantworten. Ich werde nicht empfehlen, ein Produktionssystem einfach zu Entwicklungszwecken zu klonen. Es kann sehr gut viele Benutzerdaten sowie Schlüsselmaterial enthalten, das Sie auf Entwicklungssystemen nicht haben möchten.

Das Klonen Ihres Produktionssystems kann jedoch eine gute Idee für andere Zwecke sein.

Der Ansatz, den ich für die Erstellung eines Clones des Produktionssystems empfehlen würde, ist die Wiederherstellung aus der Sicherung. Sie können Leistungseinbußen auf dem Produktionssystem vermeiden, indem Sie von einer Sicherung wiederherstellen, und Sie können Ihre Wiederherstellungsprozedur testen, was eine gute Sache ist.

Es ist wichtig, den von Backup wiederhergestellten Klon isoliert vom Rest der Welt zu behalten. Da es von einem Backup eines Produktionssystems wiederhergestellt wurde, kann es automatisierte Jobs enthalten, die mit anderen Produktionssystemen kommunizieren und über entsprechende Anmeldeinformationen verfügen.

Sie könnten möglicherweise viel Schaden verursachen, wenn der Klon mit realen Produktionssystemen kommunizieren könnte.

Wenn Sie es jedoch isoliert halten, können Sie testen, ob das wiederhergestellte System wie vorgesehen funktioniert. Außerdem könnte ein solches wiederhergestelltes System eine nützliche Umgebung für den letzten Test des neuen Codes sein, bevor es in der Produktion bereitgestellt wird. Dies ist möglicherweise Ihre einzige Möglichkeit, den Code auf echten Benutzerdaten zu testen, bevor er tatsächlich in der Lage ist, das Produktionssystem zu durchbrechen.


9
2017-08-22 19:49



Kopieren eines Systems über eine Backup-Wiederherstellung ... wahrscheinlich die Beste weil es mehrere Ziele erreicht ... - Bart Silverstrim
Ich würde hinzufügen, dass das Mounten eines Entwicklungssystems von Grund auf eine gute Möglichkeit ist, die Systemdokumentation zu überprüfen. Wenn das Bereitstellen eines solchen Servers mit der vorliegenden Dokumentation nicht möglich ist, haben Sie ein Problem entdeckt, das für das Produktionssystem von entscheidender Bedeutung ist (falls Sie es jemals migrieren müssen, das System für eine andere Zweigstelle installieren oder eine Katastrophe verursachen) Wiederherstellung). - SJuan76


Durchführbarkeit

Sicher, es ist möglich, weil es nicht schwer ist, Linux mit unkonventionellen Mitteln zu "installieren". Sie könnten beispielsweise den Server mithilfe von rsync über SSH replizieren.

  1. Booten Sie den Zielrechner in ein "Rescue" -Bild, egal ob Red Hat DVD, Ubuntu Live Boot, Knoppix, was auch immer.
  2. Partitionieren und formatieren Sie die Zielmaschine und mounten Sie die Dateisysteme unter a /target.
  3. Rsync alle relevanten Dateisysteme über SSH (überspringt /proc, /sys, Wechsel).
  4. In Ordnung bringen /target/etc/fstab, besonders wenn die Partitionen mit UUID bezeichnet werden.
  5. Passen Sie den Hostnamen und die Netzwerkkonfiguration entsprechend an.
  6. Installieren Sie den Bootloader.

Schritt 3 könnte aus mehreren rsync-Durchgängen bestehen, möglicherweise unterstützt durch LVM-Snapshots auf dem Quellrechner, wobei der letzte Durchlauf mit allen Diensten auf dem Quellrechner gestoppt wurde, um die Datenkonsistenz sicherzustellen.

Erwünschtheit und Best Practices

Nur weil du kannst, heißt das nicht, dass du es tun solltest. Ich habe empfohlen der obige Prozess als eine Möglichkeit, eine Datencenter-Migration durchzuführen. Ihr Anwendungsfall ist jedoch ganz anders. Der Rückgriff auf das Klonen zeigt einige Mängel auf:

  • Virtualisierung wäre eine gute Möglichkeit und würde die Replikation vereinfachen.
  • Haben Sie Backups Ihrer Produktionsserver? Warum sie nicht einfach wiederherstellen? Dies wäre ein guter Test für Ihre Backup-Wiederherstellung.
  • Haben Sie Dokumentation, wie Sie alles von Grund auf reproduzieren können? Eventuell müssen Sie möglicherweise neu installieren, etwa wenn Sie das Betriebssystem aktualisieren. Dies wäre eine gute Bestätigung für Ihre Dokumentation.
  • Besser noch, haben Sie Automatisierung, die Ihnen hilft, Ihr Setup zu reproduzieren? Ein Shell-Skript könnte funktionieren. Eine Konfigurationsmanagementlösung wie CFengine, Puppet, Chef oder Ansible wäre sogar noch besser.

Wenn Sie den Produktionsserver blind klonen, verlieren Sie eine wertvolle Gelegenheit, genau zu klären, was auf dem Server läuft.


6
2017-08-23 08:26