Aus den Wolken auf den Boden: Proxmox auf einen Computer in einem Büro in der Russischen Föderation bringen

Guten Tag, Habr!



Ich möchte Ihre Aufmerksamkeit auf eine kurze Geschichte des Umzugs eines Proxmox-basierten Virtualisierungsservers von Hetzner in die Russische Föderation auf einen Virtualisierungsserver in einem Rack im Büro des Unternehmens lenken.

Kurz über die Gründe für die Wahl von Proxmox und seine Funktionen. Wikipedia über das Proxmox-Virtualisierungssystem .



Gepostet als Leitfaden für sich selbst und diejenigen, die dies wünschen, um die Reihenfolge der Aktionen nicht wiederherzustellen und keine Zeit mit den Fallstricken zu verschwenden, die in der Tat im folgenden Artikel beschrieben werden.



Kurz gesagt, der Hauptwunsch ist, dass kein laufendes Projekt verwaltet werden muss. Keine Notwendigkeit für Updates, nur wenn Sicherheitspatches veröffentlicht werden; Einfachheit der Weboberfläche. Aufgrund der Tatsache, dass das Unternehmen keinen echten Linux-Guru im Personal hat. Der praktische Debian-Standard entschied also alle Fragen zugunsten von Proxmox. Ein weiteres Plus ist die geringe Auslastung des Virtualisierungskerns auf den Prozessoren - das ist wirklich so.



Ich habe das System gelobt, ich bitte um den Rest unter Schnitt.



Im Zusammenhang mit dem Anstieg des Euro-Wechselkurses begann der Preis für den gemieteten Dienst zur Bereitstellung von Remote-Arbeitsplätzen auf einem speziell gemieteten Server zu steigen. Nach Berechnungen wurde beschlossen, in einer physischen Konfiguration "Prozessor 8 x AMD Ryzen 5 1400 Quad-Core-Prozessor (1 Sockel)", 2 * SSD M.2 1 TB + Riser für sie zur Installation im PCI-E-Port, 32 GB RAM zu erwerben ... In der Cloud die gleiche Computer-CPU (n) 8 x Intel® Core (TM) i7-CPU 920 bei 2,67 GHz (1 Sockel), 2 * 2 TB Festplatte, 47,16 Gb RAM.





Die sofort einsatzbereiten Proxmox-Speichereinstellungen basieren auf LVM-Volumes. Es ist jedoch möglich, den Betriebssystemordner und andere Optionen für Dateisysteme für den Image-Speicher und sogar externe FTP-Ressourcen zu verwenden (mehr dazu weiter unten). Auf diesem Computer wird eine LVM-Partition mit dem Namen "data" auf Datenträger 1 konfiguriert und ein Proxmox-Datenspeicher mit dem Namen "data" registriert. Er speichert Datenträgerabbilder von virtuellen Maschinen. Backups (Snapshots) von virtuellen Maschinen werden nach einem bestimmten Zeitplan auf der zweiten Festplatte gespeichert.



In der Cloud werden zwei Clientknoten mit 4 CPUs mit jeweils 16 GB RAM und einem Core2duo-Prozessortyp gestartet. Ihre virtuellen Festplatten sind vollständig 2 TB groß.





Um zu verschieben, analysieren wir die Festplattenkonfiguration und überprüfen die Größe der vollständigen Sicherung, um die Größe des komprimierten Knotens und den Speicherort (auf einen neuen Knoten oder in einen Bürospeicher) zu bestimmen:

• Knoten 1: 200 GB + 400 GB + 200 GB; Backup-Größe 175 GB
• Knoten 2: 200 GB + 500 GB; Backup-Größe 7 GB;

Wir bitten den Client, Zugriff zu gewähren und festzustellen, dass Knoten 2 Datenträger 2 nicht verwendet wird, obwohl er aktiv ist. Daher müssen Sie auf dem ursprünglichen Computer in der Cloud das Gastbetriebssystem korrekt konfigurieren und die 500-GB-Festplatte in der Proxmox-Weboberfläche deaktivieren. In diesem Fall bleibt es an Knoten 2 gebunden, wird jedoch "deaktiviert", dh Knoten 2 wird es nicht sehen.



In der Weboberfläche wird eine Sicherungskopie mit den Änderungen erstellt, die mit der maximalen Komprimierung des Festplattenabbilds in GZip vorgenommen wurden. Wir erhalten die gleichen 6 GB im Archiv, was tatsächlich erwartet wird.



Der Büroraum verfügt über einen Speicher mit FTP-Zugriff. 1 TB wird für das Hochladen archivierter Images von virtuellen Maschinen zugewiesen. Daher wurde beschlossen, diesen Speicher über FTP mit dem Ordner "/ bkps" des Cloud-Betriebssystems zu verbinden.







Auf dem Empfängerserver sind die Festplatten wie folgt konfiguriert: LVM-Daten1 auf 1 TB-> Speicherdaten1; LVM-Daten2 vorübergehend auf SSD 256 GB -> Speicherdaten2. Nachdem Sie das Image des Computers auf den FTP-Ball übertragen haben, verbinden Sie es mit der oben beschriebenen Methode mit dem Verzeichnis / bkps des empfangenden Servers. Verbinden Sie im Speicher des empfangenden Servers das Verzeichnis "/ bkps" als Sicherungsspeicher und versuchen Sie, es über die Webschnittstelle auf dem zuvor erstellten Knoten 2 wiederherzustellen. Erste Probleme:

1. Es stellt sich heraus, dass sich die Knoteneinstellungen vollständig im Archiv befinden, sodass mit Copy-Paste keine ähnliche Einstellung auf dem Empfänger erstellt werden muss.
2. Es stellt sich heraus, dass das Entpacken des Images im System den "Datenspeicher" erfordert, aber wir haben keinen, sodass der Entpackvorgang mit einem Fehler beendet wird.

Ein Versuch, die Datei "2.tar.bz2 Node Archive" in MC zu bearbeiten, ist fehlgeschlagen. Ich versuche auf einem gestoppten Knoten 2 von der Konsole des Virtualisierungsservers aus

dd if=/data/vm-101-disk-0 | grep -9cf > /bkps/vm-101-disk-0.img.gz
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Laden Sie es auf FTP hoch und stellen Sie es auf dem empfangenden Server von der Konsole auf das auf LVM data2 erstellte Image mit dem Namen "/ dev / data2 / vm-101-disk0" mit den folgenden Befehlen bereit:

cd /bkps
ls | grep vm101
gunzip -c vm101-disk-0.img.gz | dd of=/dev/data2/vm101-disk-0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Am Ende des Prozesses wurde Knoten 2 korrekt gestartet, das Gastbetriebssystem begann ohne weitere Manipulation zu arbeiten.



Mit Knoten 1 wurde der Prozess komplizierter, da mit DD die Festplatte 2 nicht auf 400 GB erweitert werden konnte. Was der Grund ist, ist mir noch unbekannt. Als die Zeit ablief, wurde die Entscheidung von Solomon getroffen: Den Speicher des empfangenden Servers von "Daten1" in "Daten" umzubenennen und Knoten 1 aus der Sicherung bereitzustellen. In dieser Konfiguration verlief der Prozess einwandfrei, der Computer wurde gestartet und funktioniert ordnungsgemäß. Alle angeschlossenen Festplatten werden angezeigt.



Abschließend kurz die Migration von Festplatten innerhalb des Servers zwischen Speichern.

1. Wir stoppen den Knoten.
2. In den Konfigurationseinstellungen des Knotens zielen wir auf die Festplatte ab, die migriert werden muss. Es ist seltsam, dass es nur auf einer verbundenen Festplatte funktioniert und eine, die nicht „angeschlossen“ ist, nicht migriert werden kann.
3. Wir wählen den Zielspeicher aus und das System verschiebt ihn in den gewünschten Speicher.

Basierend auf der Schlussfolgerung war es möglich, sich so zu bewegen (ein Bonus für die hartnäckigsten Leser):

1. Starten Sie auf dem Server in der Cloud die Migration in ein beliebiges Verzeichnis der Laufwerke von Knoten1 und Knoten2.
2. Übertragen Sie sie durch Kopieren auf FTP (es könnte mit demselben gzip komprimiert worden sein, um den Datenverkehr zu reduzieren).
3. Stellen Sie eine virtuelle Festplattendatei auf dem FTP-Server bereit, wenn Sie ein komprimiertes Image übertragen haben.
4. Stellen Sie eine Verbindung (ohne zu starten) zum gewünschten Knoten her und klicken Sie auf die Schaltfläche "Migrieren".

Diese Manipulationen würden zu einer regelmäßigen Migration des Images der virtuellen Festplatte in den von uns benötigten Speicher führen.



Vielen Dank für Ihre Aufmerksamkeit, ich hoffe, jemand wird diesen Text nützlich finden.