Das nuvens para o solo: movendo o Proxmox para um computador em um escritório na Federação Russa

Bom dia, Habr!



Gostaria de chamar sua atenção para um breve histórico da mudança de um servidor de virtualização baseado em Proxmox de Hetzner para a Federação Russa para um servidor de virtualização localizado em um rack no escritório da empresa.

Resumidamente sobre os motivos da escolha do Proxmox, seus recursos. Wikipedia sobre o sistema de virtualização Proxmox .



Postado como um guia para você e para aqueles que desejam, de modo a não restaurar a ordem das ações e não perder tempo com essas armadilhas, que, na verdade, estão no artigo abaixo.



Em suma, o principal desejo é que não haja necessidade de administrar um projeto em execução; não há necessidade de atualizações, apenas quando os patches de segurança são lançados; simplicidade da interface da web. Devido ao fato de que a empresa não possui um verdadeiro guru do Linux na equipe. Portanto, o padrão prático do Debian decidiu todas as questões em favor do Proxmox. Outra vantagem é a baixa carga do kernel de virtualização no (s) processador (es) - realmente é isso.



Elogiei o sistema, peço o resto sob corte.



Em ligação com o crescimento da taxa de câmbio do Euro, o serviço alugado para a prestação de postos de trabalho remotos num servidor especialmente alugado começou a subir de preço. Após os cálculos, decidiu-se adquirir em configuração física "Processador 8 x AMD Ryzen 5 1400 Quad-Core Processor (1 Socket)", 2 * SSD M.2 1TB + risers para instalação na porta PCI-E, 32 Gb RAM ... Na nuvem, a mesma máquina CPU (s) 8 x Intel® Core (TM) i7 CPU 920 @ 2,67 GHz (1 soquete), 2 * 2 TB HDD, 47,16 Gb RAM.





As configurações de armazenamento Proxmox prontas para uso são baseadas em volumes LVM, embora seja possível usar a pasta do SO e outras opções do sistema de arquivos para o armazenamento de imagens e até mesmo recursos de FTP externos (mais sobre isso abaixo). Nesta máquina, uma partição LVM chamada "data" é configurada no disco # 1 e um armazenamento de dados proxmox chamado "data" é registrado, ele armazena imagens de disco de máquinas virtuais. Backups (instantâneos) de máquinas virtuais são salvos no segundo disco de acordo com uma determinada programação.



Na nuvem, dois nós de cliente são lançados com 4 CPUs de 16 GB de RAM cada e com um tipo de processador core2duo. Seus discos virtuais têm 2 TB.





Para mover, analisamos a configuração do disco, olhamos para o tamanho do backup completo para determinar o tamanho do nó compactado e o local de armazenamento (para um novo nó ou para armazenamento de escritório):

• Nó 1: 200 Gb + 400 Gb + 200 Gb; Tamanho de backup 175 Gb
• Nó 2: 200 Gb + 500 Gb; Tamanho do backup de 7 Gb;

Pedimos ao cliente para conceder acesso e determinar que o Nó 2 disco 2 não é usado, embora esteja ativo. Portanto, na máquina original na nuvem, você deve configurar corretamente o sistema operacional convidado e desativar o disco de 500 GB na interface da Web do Proxmox. Nesse caso, ele permanecerá vinculado ao Nó 2, mas ficará "desabilitado", ou seja, o Nó 2 não o verá.



Na interface web, é feito um backup com as alterações feitas com a compressão máxima da imagem do disco em GZip. Obtemos os mesmos 6 Gb no arquivo, o que é realmente esperado.



O espaço do escritório possui um armazenamento com acesso FTP, 1TB é alocado para o upload de imagens arquivadas de máquinas virtuais, por isso decidiu-se conectar este armazenamento via FTP à pasta "/ bkps" do SO em nuvem.







No servidor receptor, os discos são configurados da seguinte forma: LVM data1 em 1TB-> Storage data1; LVM data2 temporariamente em SSD 256Gb -> Storage data2. Após transferir a imagem da máquina para o FTP-ball, conecte-a usando o método descrito acima ao diretório / bkps do servidor receptor. No armazenamento do servidor receptor, conecte o diretório "/ bkps" como um armazenamento de backup e tente restaurá-lo para o Nó 2 criado anteriormente a partir da interface da web. Primeiros problemas:

1. Acontece que as configurações do Node estão completamente no arquivo, portanto não há necessidade de criar um semelhante no receptor usando copiar e colar.
2. Acontece que descompactar a imagem no sistema requer o armazenamento de "dados", mas não temos um, portanto, o processo de descompactação para com um erro.

Uma tentativa de editar o arquivo "2.tar.bz2 Node Archive" no MC falhou. Estou tentando em um nó parado 2 do console do servidor de virtualização usando

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

carregue no FTP e implemente no servidor de recebimento do console para a imagem criada no LVM data2 com o nome "/ dev / data2 / vm-101-disk0" usando os comandos:

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

No final do processo, o Nó 2 foi iniciado corretamente, o SO convidado começou a funcionar sem manipulação adicional.



Com o Nó 1, o processo ficou mais complicado, pois usando DD não foi possível expandir o disco 2 para 400Gb. Qual é o motivo ainda é desconhecido para mim. Como o tempo estava se esgotando, a decisão de Solomon foi tomada: renomear o Storage do servidor receptor de "data1" para "data" e implantar o Nó 1 do backup. Nessa configuração, o processo correu bem, a máquina iniciou e funciona corretamente, vê todos os discos conectados.



E, para concluir, brevemente sobre a migração de discos dentro do servidor entre armazenamentos.

1. Paramos o nó.
2. Nas definições de configuração do nó, visamos o disco que precisa ser migrado. É estranho que ele só funcione em um disco conectado e um que não esteja “conectado” não possa ser migrado.
3. Selecionamos o armazenamento de destino e o sistema o move para o armazenamento necessário.

Com base na conclusão, foi possível se mover assim (uma forma bônus de se mover para os leitores mais persistentes):

1. no servidor na nuvem, inicie a migração para um diretório arbitrário das unidades de Nó1 e Nó2;
2. transferi-los copiando para FTP (pode ser compactado com o mesmo gzip para reduzir o tráfego);
3. implantar um arquivo de disco virtual no servidor FTP se transferimos uma imagem compactada;
4. conecte (sem iniciar) ao nó necessário e pressione o botão "migrar".

Essas manipulações levariam a uma migração regular da imagem do disco virtual para o armazenamento de que precisamos.



Obrigado por sua atenção, espero que alguém ache este texto útil.