Al suelo desde las nubes: mover Proxmox a una computadora en una oficina en la Federación de Rusia

¡Buen día, Habr!



Me gustaría llamar su atención sobre una breve historia del traslado de un servidor de virtualización basado en Proxmox de Hetzner a la Federación de Rusia a un servidor de virtualización ubicado en un bastidor en la oficina de la empresa.

Brevemente sobre las razones para elegir Proxmox, sus características. Wikipedia sobre el sistema de virtualización Proxmox .



Publicado como una guía para usted y los que lo deseen, para no restablecer el orden de las acciones y no perder el tiempo en esos escollos, que, de hecho, están en el artículo siguiente.



En resumen, el principal deseo es que no sea necesario administrar un proyecto en ejecución; no hay necesidad de actualizaciones, solo cuando se lanzan los parches de seguridad; simplicidad de la interfaz web. Debido al hecho de que la empresa no tiene un verdadero gurú de Linux en su personal. Entonces, el estándar Debian práctico decidió todas las preguntas a favor de Proxmox. Otra ventaja es la baja carga del kernel de virtualización en el (los) procesador (es), esto es realmente así.



Alabé el sistema, pido el resto sobrado.



En relación con el crecimiento del tipo de cambio del euro, el servicio alquilado para proporcionar lugares de trabajo remotos en un servidor especialmente alquilado comenzó a subir de precio. Después de los cálculos, se decidió adquirir en una configuración física "Procesador 8 x AMD Ryzen 5 1400 Quad-Core Processor (1 Socket)", 2 * SSD M.2 1TB + risers para ellos para su instalación en el puerto PCI-E, 32 Gb RAM ... En la nube, la misma máquina CPU (s) 8 x Intel® Core (TM) i7 CPU 920 @ 2.67GHz (1 Socket), 2 * 2TB HDD, 47.16 Gb RAM.





La configuración de almacenamiento de Proxmox lista para usar se basa en volúmenes LVM, aunque es posible usar la carpeta del SO y otras opciones para sistemas de archivos e incluso recursos FTP externos para el almacenamiento de imágenes (más sobre esto a continuación). En esta máquina, se configura una partición LVM con el nombre "datos" en el disco 1 y se registra un almacén de datos proxmox llamado "datos", que almacena imágenes de disco de máquinas virtuales. Las copias de seguridad (instantáneas) de las máquinas virtuales se guardan en el segundo disco de acuerdo con un programa determinado.



Hay dos nodos de cliente que se ejecutan en la nube con 4 CPU de 16 GB de RAM cada uno y con un tipo de procesador core2duo. Sus discos virtuales son completamente de 2TB.





Para movernos, analizamos la configuración del disco, observamos el tamaño de la copia de seguridad completa para determinar el tamaño del nodo comprimido y la ubicación de almacenamiento (a un nuevo nodo o al almacenamiento de la oficina):

• Nodo 1: 200 Gb + 400 Gb + 200 Gb; Tamaño de la copia de seguridad 175 Gb
• Nodo 2: 200 Gb + 500 Gb; Tamaño de la copia de seguridad 7 Gb;

Le pedimos al cliente que otorgue acceso y determine que el disco 2 del nodo 2 no se utiliza, aunque está activo. Por lo tanto, en la máquina original en la nube, debe configurar correctamente el sistema operativo invitado y deshabilitar el disco de 500 GB en la interfaz web de Proxmox. En este caso, permanecerá vinculado al Nodo 2, pero estará "deshabilitado", es decir, el Nodo 2 no lo verá.



En la interfaz web se realiza una copia de seguridad con los cambios realizados con la máxima compresión de la imagen del disco en GZip. Obtenemos los mismos 6 Gb en el archivo, que en realidad se espera.



El espacio de la oficina tiene un almacenamiento con acceso FTP, se asigna 1TB para cargar imágenes archivadas de máquinas virtuales, por lo que se decidió conectar este almacenamiento vía FTP a la carpeta "/ bkps" del SO en la nube.







En el servidor receptor, los discos se configuran de la siguiente manera: LVM data1 en 1TB-> Storage data1; LVM data2 temporalmente en SSD 256Gb -> Storage data2. Después de transferir la imagen de la máquina al FTP-ball, conéctela utilizando el método descrito anteriormente al directorio / bkps del servidor receptor. En el almacenamiento del servidor receptor, conecte el directorio "/ bkps" como almacenamiento de respaldo e intente restaurarlo en el Nodo 2 creado previamente desde la interfaz web. Primeros problemas:

1. Resulta que la configuración del nodo está completamente en el archivo, por lo que no es necesario crear una similar en el receptor usando copiar y pegar.
2. Resulta que descomprimir la imagen en el sistema requiere el almacenamiento de "datos", pero no tenemos uno, por lo que el proceso de descompresión se detiene con un error.

Error al intentar editar el archivo "Archivo del nodo 2.tar.bz2" en MC. Estoy probando un nodo 2 detenido desde la consola del servidor de virtualización usando

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

cargar a FTP e implementar en el servidor receptor desde la consola a la imagen creada en LVM data2 llamada "/ dev / data2 / vm-101-disk0" usando los comandos:

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Al final del proceso, el nodo 2 se inició correctamente, el sistema operativo invitado comenzó a funcionar sin más manipulación.



Con el Nodo 1, el proceso se volvió más complicado, ya que con DD no fue posible expandir el disco 2 a 400Gb. Aún desconozco cuál es la razón. A medida que se agotaba el tiempo, se tomó la decisión de Solomon: cambiar el nombre del almacenamiento del servidor receptor de "datos1" a "datos" e implementar el Nodo 1 desde la copia de seguridad. En esta configuración, el proceso fue bien, la máquina se inició y funciona correctamente, ve todos los discos conectados.



Y en conclusión, brevemente sobre la migración de discos dentro del servidor entre almacenamientos.

1. Paramos el nodo.
2. En los ajustes de configuración del nodo, apuntamos al disco que se debe migrar. Es extraño que solo funcione en un disco conectado y que uno que no esté "adjunto" no se pueda migrar.
3. Seleccionamos el almacenamiento de destino y el sistema lo traslada al almacenamiento requerido.

Según la conclusión, era posible moverse así (una forma adicional de moverse para los lectores más persistentes):

1. en el servidor en la nube, inicie la migración a un directorio arbitrario de las unidades de Node1 y Node2;
2. transferirlos copiándolos a FTP (podría haber sido comprimido con el mismo gzip para reducir el tráfico);
3. desplegar un archivo de disco virtual en el servidor FTP si transferimos una imagen comprimida;
4. conéctese (sin comenzar) al Nodo requerido y presione el botón "migrar".

Estas manipulaciones conducirían a una migración regular de la imagen del disco virtual al almacenamiento que necesitamos.



Gracias por su atención, espero que alguien encuentre útil este texto.