Vers le sol depuis les nuages: déplacer Proxmox vers un ordinateur dans un bureau de la Fédération de Russie

Bonne journée, Habr!



Je voudrais attirer votre attention sur un bref historique du déplacement d'un serveur de virtualisation basé sur Proxmox de Hetzner vers la Fédération de Russie vers un serveur de virtualisation situé dans un rack du bureau de l'entreprise.

En bref sur les raisons du choix de Proxmox, ses fonctionnalités. Wikipedia sur le système de virtualisation Proxmox .



Publié comme un guide sur vous-même et sur ceux qui le souhaitent, afin de ne pas restaurer l'ordre des actions et de ne pas perdre de temps sur ces écueils, qui, en fait, se trouvent dans l'article ci-dessous.



En bref, le souhait principal est qu'il n'y a pas besoin d'administrer un projet en cours; pas besoin de mises à jour, uniquement lorsque les correctifs de sécurité sont publiés; simplicité de l'interface Web. En raison du fait que l'entreprise n'a pas de véritable gourou Linux parmi son personnel. Ainsi, le standard Debian pratique a tranché toutes les questions en faveur de Proxmox. Un autre avantage est la faible charge du noyau de virtualisation sur le (s) processeur (s) - c'est vraiment le cas.



J'ai loué le système, je demande le reste sous la coupe.



En lien avec la croissance du taux de change de l'euro, le prix du service loué de fourniture de postes de travail à distance sur un serveur spécialement loué a commencé à augmenter. Après calculs, il a été décidé d'acheter dans une configuration physique «Processeur 8 x AMD Ryzen 5 1400 Quad-Core Processor (1 Socket)», 2 * SSD M.2 1To + risers pour eux pour l'installation dans le port PCI-E, 32 Go de RAM ... Dans le cloud, le (s) même processeur (s) de la machine 8 x Intel® Core (TM) i7 CPU 920 @ 2,67 GHz (1 socket), 2 * 2 To HDD, 47,16 Go RAM.





Les paramètres de stockage Proxmox prêts à l'emploi sont basés sur les volumes LVM, bien qu'il soit possible d'utiliser le dossier OS et d'autres options pour les systèmes de fichiers pour le stockage d'images, et même des ressources FTP externes (plus d'informations ci-dessous). Sur cette machine, une partition LVM nommée "data" est configurée sur le disque n ° 1 et un magasin de données proxmox nommé "data" est enregistré, il stocke les images disque des machines virtuelles. Les sauvegardes (instantanés) des machines virtuelles sont enregistrées sur le deuxième disque selon une certaine planification.



Dans le cloud, deux nœuds clients sont lancés avec 4 processeurs de 16 Go de RAM chacun et avec un processeur de type core2duo. Leurs disques virtuels font complètement 2 To.





Pour déplacer, nous analysons la configuration du disque, regardons la taille de la sauvegarde complète pour déterminer la taille du nœud compressé et l'emplacement de stockage (vers un nouveau nœud ou vers le stockage du bureau):

• Nœud 1: 200 Go + 400 Go + 200 Go; Taille de sauvegarde 175 Go
• Nœud 2: 200 Go + 500 Go; Taille de sauvegarde 7 Go;

Nous demandons au client d'accorder l'accès et de déterminer que le disque 2 du nœud 2 n'est pas utilisé, bien qu'il soit actif. Par conséquent, sur la machine d'origine dans le cloud, vous devez configurer correctement le système d'exploitation invité et désactiver le disque de 500 Go dans l'interface Web de Proxmox. Dans ce cas, il restera lié au nœud 2, mais sera «désactivé», c'est-à-dire que le nœud 2 ne le verra pas.



Dans l'interface Web, une sauvegarde est effectuée avec les modifications apportées avec la compression maximale de l'image disque dans GZip. Nous obtenons le même 6 Go dans l'archive, ce qui est en fait attendu.



L'espace de bureau dispose d'un stockage avec accès FTP, 1 To est alloué pour le téléchargement d'images archivées de machines virtuelles, il a donc été décidé de connecter ce stockage via FTP au dossier "/ bkps" du cloud OS.







Sur le serveur récepteur, les disques sont configurés comme suit: LVM data1 on 1TB-> Storage data1; Données LVM2 temporairement sur SSD 256 Go -> Données de stockage 2. Après avoir transféré l'image de la machine sur le FTP-ball, connectez-la en utilisant la méthode décrite ci-dessus au répertoire / bkps du serveur de réception. Dans le stockage du serveur de réception, connectez le répertoire "/ bkps" comme stockage de sauvegarde et essayez de le restaurer sur le nœud 2 précédemment créé à partir de l'interface Web. Premiers problèmes:

1. Il s'avère que les paramètres Node sont complètement dans l'archive, il n'est donc pas nécessaire d'en créer un similaire sur le récepteur en utilisant le copier-coller.
2. Il s'avère que la décompression de l'image dans le système nécessite le stockage des «données», mais nous n'en avons pas, donc le processus de décompression s'arrête avec une erreur.

Une tentative de modification du fichier "Archive du nœud 2.tar.bz2" dans MC a échoué. J'essaye sur un nœud 2 arrêté depuis la console du serveur de virtualisation en utilisant

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

télécharger sur FTP et déployer sur le serveur de réception depuis la console vers l'image créée sur LVM data2 avec le nom "/ dev / data2 / vm-101-disk0" à l'aide des commandes:

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

À la fin du processus, Node 2 a démarré correctement, le système d'exploitation invité a commencé à fonctionner sans autre manipulation.



Avec le nœud 1, le processus est allé plus compliqué, car en utilisant DD, il n'était pas possible d'étendre le disque 2 à 400 Go. Quelle est la raison m'est encore inconnue. Comme le temps passait, la décision de Solomon a été prise: renommer le stockage du serveur de réception de «data1» en «data» et déployer le nœud 1 à partir de la sauvegarde. Dans cette configuration, le processus s'est bien passé, la machine a démarré et fonctionne correctement, voit tous les disques connectés.



Et en conclusion, brièvement sur la migration des disques à l'intérieur du serveur entre les stockages.

1. Nous arrêtons le nœud.
2. Dans les paramètres de configuration du nœud, nous visons le disque qui doit être migré. Il est étrange que cela fonctionne uniquement sur un disque connecté, et celui qui n'est pas «attaché» ne peut pas être migré.
3. Nous sélectionnons le stockage cible et le système le déplace vers le stockage requis.

Sur la base de la conclusion, il était possible de se déplacer comme ça (un moyen supplémentaire de se déplacer pour les lecteurs les plus persistants):

1. sur le serveur dans le cloud, lancez la migration vers un répertoire arbitraire des lecteurs de Node1 et Node2;
2. transférez-les en copiant sur FTP (vous pouvez le compresser avec le même gzip pour réduire le trafic);
3. déployer un fichier de disque virtuel sur le serveur FTP si nous transférons une image compressée;
4. connectez-vous (sans démarrer) au nœud souhaité et appuyez sur le bouton «migrer».

Ces manipulations conduiraient à une migration régulière de l'image du disque virtuel vers le stockage dont nous avons besoin.



Merci pour votre attention, j'espère que quelqu'un trouvera ce texte utile.