O gerenciador de cluster Proxmox VE pvecm é uma ferramenta para criar um grupo de servidores físicos. Esse grupo é chamado de cluster . Usamos o Mecanismo de cluster do Corosyncpara comunicação de grupo confiável, e esses clusters podem consistir de até 32 nós físicos (provavelmente mais, dependendo da latência da rede).
O pvecm pode ser usado para criar um novo cluster, unir nós a um cluster, deixar o cluster, obter informações de status e executar várias outras tarefas relacionadas ao cluster. A P rox m o x Cbrilho F ile S istema ( “pmxcfs”) é utilizado para distribuir de forma transparente a configuração de cluster para todos os nós de fragmentação.
O agrupamento de nós em um cluster possui as seguintes vantagens:
- Gerenciamento centralizado baseado na web
- Clusters multi-mestre: cada nó pode fazer toda tarefa de gerenciamento
- pmxcfs : sistema de arquivos baseado em banco de dados para armazenar arquivos de configuração, replicado em tempo real em todos os nós usando o corosync .
- Fácil migração de máquinas virtuais e containers entre hosts físicos
- Implantação rápida
- Serviços em todo o cluster, como firewall e HA
Requisitos
- Todos os nós devem estar na mesma rede que o corosync usa IP Multicast para se comunicar entre os nós (consulte também o Corosync Cluster Engine ). O Corosync usa as portas UDP 5404 e 5405 para comunicação de cluster.
Algumas opções não suportam multicast IP por padrão e devem ser ativadas manualmente primeiro. - Data e hora precisam ser sincronizadas.
- O túnel SSH na porta TCP 22 entre os nós é usado.
- Se você estiver interessado em alta disponibilidade, precisará ter pelo menos três nós para quorum confiável. Todos os nós devem ter a mesma versão.
- Recomendamos uma NIC dedicada ao tráfego do cluster, especialmente se você usar o armazenamento compartilhado.
|
Não é possível misturar o Proxmox VE 3.xe anterior com nós de cluster do Proxmox VE 4.0. |
Preparando Nós
Primeiro, instale o Proxmox VE em todos os nós. Certifique-se de que cada nó esteja instalado com o nome do host final e a configuração IP. A alteração do nome do host e do IP não é possível após a criação do cluster.
Atualmente a criação do cluster tem que ser feita no console, então você precisa fazer o login via ssh .
Crie o cluster
Faça login via ssh no primeiro nó do Proxmox VE. Use um nome exclusivo para seu cluster. Este nome não pode ser alterado mais tarde.
hp1 # pvecm cria o SEU NÚMERO-CLUSTER
 |
O nome do cluster é usado para calcular o endereço multicast padrão. Por favor, use nomes de cluster exclusivos se você executar mais de um cluster dentro de sua rede. |
Para verificar o estado do seu cluster, use:
hp1 # pvecm status
Vários clusters na mesma rede
É possível criar vários clusters na mesma rede física ou lógica. Cada cluster deve ter um nome exclusivo, que é usado para gerar o endereço do grupo de multidifusão do cluster. Desde que nenhum nome de cluster duplicado seja configurado em um segmento de rede, os diferentes clusters não interferirão entre si.
Se vários clusters operam em uma única rede, pode ser vantajoso configurar um querier IGMP e habilitar o IGMP Snooping na rede. Isso pode reduzir significativamente a carga da rede, porque os pacotes multicast são entregues apenas aos terminais dos respectivos nós membros.
Adicionando Nós ao Cluster
Faça o login via ssh para o nó que você deseja adicionar.
hp2 # pvecm adicionar IP-ADDRESS-CLUSTER
Para IP-ADDRESS-CLUSTER, use o IP de um nó de cluster existente.
|
Um novo nó não pode conter nenhuma VM, porque você obteria conflitos sobre IDs de VM idênticas. Além disso, toda a configuração existente em / etc / pve é sobrescrita quando você associa um novo nó ao cluster. Para solucionar esse problema, use o vzdump para fazer backup e restaurar em um VMID diferente após adicionar o nó ao cluster. |
Para verificar o estado do cluster:
# status pvecm
hp2 # pvecm status Informação do quórum ~~~~~~~~~~~~~~~~~~ Data: seg 20 de abril 12:30:13 2015 Provedor de quórum: corosync_votequorum Nós: 4 ID do nó: 0x00000001 ID do anel: 1928 Quorate: sim Votequorum information ~~~~~~~~~~~~~~~~~~~~~~ Votos esperados: 4 Mais alto esperado: 4 Total de votos: 4 Quórum: 2 Bandeiras: Quorate Informação de adesão ~~~~~~~~~~~~~~~~~~~~~~ Nome dos Votos Nóidos 0x00000001 1 192.168.15.91 0x00000002 1 192.168.15.92 (local) 0x00000003 1 192.168.15.93 0x00000004 1 192.168.15.94
Se você quiser apenas que a lista de todos os nós use:
# nós pvecm
hp2 # pvecm nodes Informação de adesão ~~~~~~~~~~~~~~~~~~~~~~ Nome dos Votos Nóidos 1 1 hp1 2 1 hp2 (local) 3 1 hp3 4 1 hp4
Adicionando Nós com Rede de Cluster Separada
Ao adicionar um nó a um cluster com uma rede de clusters separada, você precisa usar os parâmetros ringX_addr para definir o endereço dos nós nessas redes:
pvecm adicionar IP-ADDRESS-CLUSTER -ring0_addr IP-ADDRESS-RING 0
Se você quiser usar o Redundant Ring Protocol, você também desejará passar o parâmetro ring1_addr .
Remover um nó de cluster
|
Leia atentamente o procedimento antes de prosseguir, pois não pode ser o que você quer ou precisa. |
Mova todas as máquinas virtuais do nó. Verifique se você não tem dados locais ou backups que deseja manter ou salve-os de acordo. No exemplo a seguir, removeremos o nó hp4 do cluster.
Efetue login em um nó de cluster diferente (não em hp4) e emita um comando pvecm nodes para identificar o ID do nó a ser removido:
hp1 # pvecm nodes Informação de adesão ~~~~~~~~~~~~~~~~~~~~~~ Nome dos Votos Nóidos 1 1 hp1 (local) 2 1 hp2 3 1 hp3 4 1 hp4
Neste ponto, você deve desligar a hp4 e certificar-se de que ela não será ligada novamente (na rede) como está.
 |
Como dito acima, é essencial desligar o nó antes da remoção e certificar-se de que ele nunca será ligado novamente (na rede de clusters existente) como está. Se você ligar o nó como está, seu cluster será danificado e poderá ser difícil restaurar um estado de cluster limpo. |
Depois de desligar o nó hp4, podemos removê-lo com segurança do cluster.
hp1 # pvecm delnode hp4
Se a operação for bem-sucedida, nenhuma saída será retornada, apenas verifique a lista de nós novamente com nós pvecm ou status pvecm . Você deveria ver algo como:
hp1 # pvecm status Informação do quórum ~~~~~~~~~~~~~~~~~~ Data: seg 20 abr 12:44:28 2015 Provedor de quórum: corosync_votequorum Nós: 3 ID do nó: 0x00000001 ID do anel: 1992 Quorate: sim Votequorum information ~~~~~~~~~~~~~~~~~~~~~~ Votos esperados: 3 Maior esperado: 3 Total de votos: 3 Quórum: 3 Bandeiras: Quorate Informação de adesão ~~~~~~~~~~~~~~~~~~~~~~ Nome dos Votos Nóidos 0x00000001 1 192.168.15.90 (local) 0x00000002 1 192.168.15.91 0x00000003 1 192.168.15.92
Se, por qualquer razão, você quiser que este servidor se junte ao mesmo cluster novamente, é necessário
- Reinstale o Proxmox VE a partir do zero
- em seguida, junte-se a ele, conforme explicado na seção anterior.
Separar um nó sem reinstalar
|
Este não é o método recomendado, prossiga com cautela. Use o método acima mencionado se não tiver certeza. |
Você também pode separar um nó de um cluster sem reinstalá-lo do zero. Mas depois de remover o nó do cluster, ele ainda terá acesso aos armazenamentos compartilhados! Isso deve ser resolvido antes de começar a remover o nó do cluster. Um cluster do Proxmox VE não pode compartilhar exatamente o mesmo armazenamento com outro cluster, pois o bloqueio de armazenamento não funciona nos limites do cluster. Além disso, também pode levar a conflitos de VMID.
É sugerido que você crie um novo armazenamento onde apenas o nó que você deseja separar tenha acesso. Essa pode ser uma nova exportação no seu NFS ou em um novo pool Ceph, para citar alguns exemplos. É importante que o mesmo armazenamento exato não seja acessado por vários clusters. Depois de configurar esse armazenamento, mova todos os dados do nó e suas VMs para ele. Então você está pronto para separar o nó do cluster.
 |
Assegure-se de que todos os recursos compartilhados estejam separados de forma clara! Você vai se deparar com conflitos e problemas mais. |
Primeiro, pare os serviços corosync e pve-cluster no nó:
systemctl stop pve-cluster systemctl stop corosync
Inicie o sistema de arquivos do cluster novamente no modo local:
pmxcfs -l
Exclua os arquivos de configuração do corosync:
rm / etc / pve / corosync . conf rm / etc / corosync / *
Agora você pode iniciar o sistema de arquivos novamente como serviço normal:
killx pmxcfs systemctl start pve-cluster
O nó agora está separado do cluster. Você pode excluí-lo de um nó restante do cluster com:
pvecm delnode oldnode
Se o comando falhou, porque o nó restante no cluster perdeu o quorum quando o nó agora separado saiu, você pode definir os votos esperados para 1 como uma solução alternativa:
pvecm esperado 1
E a repetição do comando delnode pvecm .
Agora volte para o nó separado, aqui, apague todos os arquivos restantes do antigo cluster. Isso garante que o nó possa ser adicionado a outro cluster novamente sem problemas.
rm / var / lib / corosync / *
Como os arquivos de configuração dos outros nós ainda estão no sistema de arquivos do cluster, você pode querer limpá-los também. Remova simplesmente todo o diretório recursivo de / etc / pve / nodes / NODENAME , mas verifique três vezes que você usou o correto antes de excluí-lo.
|
As chaves SSH dos nós ainda estão no arquivo authorized_key , isso significa que os nós ainda podem se conectar uns aos outros com autenticação de chave pública. Isso deve ser corrigido removendo as respectivas chaves do arquivo / etc / pve / priv / authorized_keys . |
Quorum
O Proxmox VE usa uma técnica baseada em quorum para fornecer um estado consistente entre todos os nós do cluster.
Um quorum é o número mínimo de votos que uma transação distribuída deve obter para poder realizar uma operação em um sistema distribuído.
– da Wikipedia
No caso de particionamento de rede, as alterações de estado exigem que a maioria dos nós esteja online. O cluster alternará para o modo somente leitura se perder o quorum.
|
O Proxmox VE atribui um único voto a cada nó por padrão. |
Rede de Cluster
A rede de cluster é o núcleo de um cluster. Todas as mensagens enviadas por ele devem ser entregues confiáveis para todos os nós em sua respectiva ordem. No Proxmox VE, essa parte é feita pelo corosync, uma implementação de um kit de ferramentas de desenvolvimento de alta disponibilidade com baixa sobrecarga de alta performance. Ele serve nosso sistema de arquivos de configuração descentralizada ( pmxcfs ).
Requisitos de Rede
Isso requer uma rede confiável com latências inferiores a 2 milissegundos (desempenho da LAN) para funcionar corretamente. Embora o corosync também possa usar unicast para comunicação entre nós, é altamente recomendável ter uma rede capaz de realizar multicast. A rede não deve ser usada intensamente por outros membros, idealmente o corosync é executado em sua própria rede. nunca compartilhe com a rede onde o armazenamento se comunica também.
Antes de configurar um cluster, é recomendável verificar se a rede é adequada para essa finalidade.
- Assegure-se de que todos os nós estejam na mesma sub-rede. Isso deve ser verdade apenas para as interfaces de rede usadas para comunicação de cluster (corosync).
- Assegure-se de que todos os nós possam alcançar uns aos outros nessas interfaces, usando ping é suficiente para um teste básico.
- Assegure-se de que a multidifusão funcione em geral e as altas taxas de pacote. Isso pode ser feito com a ferramenta de omissão . O número final de “% de perda” deve ser <1%.
omping -c 10000 -i 0,001- F -q NODE1-IP NODE2-IP ...
- Certifique-se de que a comunicação multicast funciona durante um longo período de tempo. Isso descobre problemas em que a detecção de IGMP é ativada na rede, mas nenhum comissionador de multicast está ativo. Este teste tem uma duração de cerca de 10 minutos.
omping-c 600 -i 1 -q NODE1-IP NODE2-IP ...
Sua rede não está pronta para cluster se algum desses testes falhar. Verifique novamente sua configuração de rede. Especialmente os switches são notórios por ter o multicast desativado por padrão ou o snooping IGMP habilitado sem o querier IGMP ativo.
Em cluster menor, também é uma opção usar unicast se você realmente não conseguir fazer o multicast funcionar.
Rede de Cluster Separada
Ao criar um cluster sem nenhum parâmetro, a rede do cluster é geralmente compartilhada com a UI da Web e as VMs e seu tráfego. Dependendo da sua configuração, até mesmo o tráfego de armazenamento pode ser enviado pela mesma rede. É recomendado alterá-lo, pois o corosync é um aplicativo crítico em tempo real.
Configurando uma nova rede
Primeiro você tem que configurar uma nova interface de rede. Deve estar em uma rede física separada. Certifique-se de que sua rede atenda aos requisitos de rede do cluster .
Separado na criação de cluster
Isto é possível através da ring0_addr e bindnet0_addr parâmetro do pvecm criar comando usado para criar um novo cluster.
Se você configurou uma NIC adicional com um endereço estático em 10.10.10.1/25 e deseja enviar e receber toda a comunicação do cluster por essa interface, você executaria:
pvecm create test --ring0_addr 10.10 . 10.1 --bindnet0_addr 10.10 . 10,0
Para verificar se tudo está funcionando corretamente, execute:
statusctl status corosync
Depois disso, prossiga como descrito na seção para adicionar nós com uma rede de cluster separada .
Separar após a criação de cluster
Você pode fazer isso também se já tiver criado um cluster e quiser mudar sua comunicação para outra rede, sem recriar todo o cluster. Essa alteração pode levar a curtos períodos de perda de quorum no cluster, pois os nós precisam reiniciar o corosync e aparecer um após o outro na nova rede.
Veja como editar primeiro o arquivo corosync.conf . A abertura e você deve ver um arquivo semelhante a:
exploração madeireira { depurar: desativado to_syslog: sim } nodelist { nó { nome: devido nodeid: 2 quorum_votes: 1 ring0_addr: devido } nó { nome: tre nodeid: 3 quorum_votes: 1 ring0_addr: tre } nó { nome: uno nodeid: 1 quorum_votes: 1 ring0_addr: uno } } quorum { provedor: corosync_votequorum } totem { cluster_name: thomas-testcluster config_version: 3 ip_version: ipv4 secauth: em versão 2 interface { bindnetaddr: 192.168.30.50 ringnumber: 0 } }
O primeiro que você deseja fazer é incluir as propriedades de nome nas entradas do nó, caso não as veja já. Aqueles devem corresponder ao nome do nó.
Em seguida, substitua o endereço das propriedades ring0_addr pelos novos endereços. Você pode usar endereços IP simples ou também nomes de host aqui. Se você usar nomes de host, assegure-se de que eles possam ser resolvidos de todos os nós.
No meu exemplo, quero mudar minha comunicação de cluster para a rede 10.10.10.1/25. Então eu substituo todos os ring0_addr respectivamente. Eu também defino o bindnetaddr na seção totem da configuração para um endereço da nova rede. Pode ser qualquer endereço da sub-rede configurada na nova interface de rede.
Depois de aumentar a propriedade config_version , o novo arquivo de configuração deve se parecer com:
exploração madeireira { depurar: desativado to_syslog: sim } nodelist { nó { nome: devido nodeid: 2 quorum_votes: 1 ring0_addr: 10.10.10.2 } nó { nome: tre nodeid: 3 quorum_votes: 1 ring0_addr: 10.10.10.3 } nó { nome: uno nodeid: 1 quorum_votes: 1 ring0_addr: 10.10.10.1 } } quorum { provedor: corosync_votequorum } totem { cluster_name: thomas-testcluster config_version: 4 ip_version: ipv4 secauth: em versão 2 interface { bindnetaddr: 10.10.10.1 ringnumber: 0 } }
Agora, depois de uma checagem final se todas as informações alteradas estão corretas, nós as salvamos e vemos novamente a seção editar arquivo corosync.conf para aprender como trazê-las.
Como a nossa mudança não pode ser aplicada ao vivo a partir do corosync, temos que reiniciar.
Em um único nó, execute:
reinicialização do systemctl corosync
Agora verifique se está tudo bem:
statusctl status corosync
Se o corosync for executado novamente, corosync de reinicialização correta também em todos os outros nós. Em seguida, eles ingressarão na associação do cluster, um por um, na nova rede.
Protocolo de Anel Redundante
Para evitar um único ponto de falha, você deve implementar medições de contador. Isso pode estar no nível de hardware e sistema operacional por meio de ligação de rede.
O próprio Corosync oferece também a possibilidade de adicionar redundância através do chamado Protocolo de Anel Redundante . Este protocolo permite a execução de um segundo toque de totem em outra rede, esta rede deve estar fisicamente separada da outra rede de anéis para realmente aumentar a disponibilidade.
RRP na criação de cluster
O comando pvecm create fornece os parâmetros adicionais bindnetX_addr , ringX_addr e rrp_mode , podem ser usados para configuração de RRP.
|
Veja o glossário se você não souber o que cada parâmetro significa. |
Então, se você tem duas redes, uma na 10.10.10.1/24 e outra na sub-rede 10.10.20.1/24 que você executaria:
pvecm create CLUSTERNAME -bindnet0_addr 10.10 . 10.1 -ring0_addr 10.10 . 10.1 \ -bindnet1_addr 10.10 . 20.1 -ring1_addr 10.10 . 20,1
RRP em clusters existentes
Você executará etapas semelhantes conforme descrito na separação da rede do cluster para ativar o RRP em um cluster já em execução. A única diferença é que você adicionará o ring1 e o usará ao invés do ring0 .
Primeiro adicione uma nova subseção de interface na seção totem , defina sua propriedade ringnumber como 1 . Configure a propriedade bindnetaddr de interfaces para um endereço da sub-rede que você configurou para o novo anel. Além disso, configure o rrp_mode para passivo , esse é o único modo estável.
Em seguida, adicione a cada entrada do nó na seção nodelist sua nova propriedade ring1_addr com o endereço adicional adicional dos nós.
Então, se você tem duas redes, uma na 10.10.10.1/24 e outra na sub-rede 10.10.20.1/24, o arquivo de configuração final deve se parecer com:
totem { cluster_name: ajustar config_version: 9 ip_version: ipv4 rrp_mode: passivo secauth: em versão 2 interface { bindnetaddr: 10.10.10.1 ringnumber: 0 } interface { bindnetaddr: 10.10.20.1 ringnumber: 1 } } nodelist { nó { nome: pvecm1 nodeid: 1 quorum_votes: 1 ring0_addr: 10.10.10.1 ring1_addr: 10.10.20.1 } nó { nome: pvecm2 nodeid: 2 quorum_votes: 1 ring0_addr: 10.10.10.2 ring1_addr: 10.10.20.2 } [...] # outros nós do cluster aqui } [...] # outras seções de configuração restantes aqui
Traga isso como descrito na edição da seção do arquivo corosync.conf .
Esta é uma alteração que não pode levar efeito ao vivo e precisa de pelo menos uma reinicialização do corosync. Recomendado é um reinício de todo o cluster.
Se você não puder reinicializar todo o cluster, verifique se nenhum serviço de alta disponibilidade está configurado e interrompa o serviço corosync em todos os nós. Depois que o corosync for interrompido em todos os nós, inicie-o um após o outro novamente.
Configuração do Corosync
O arquivo /etc/pve/corosync.conf desempenha um papel central no cluster do Proxmox VE. Ele controla a nave de membros do cluster e sua rede. Para ler mais sobre isso, verifique a página do manual corosync.conf:
homem corosync . conf
Para a associação ao nó, você deve sempre usar a ferramenta pvecm fornecida pelo Proxmox VE. Você pode ter que editar o arquivo de configuração manualmente para outras alterações. Aqui estão algumas dicas de práticas recomendadas para fazer isso.
Editar corosync.conf
A edição do arquivo corosync.conf pode não ser sempre direta. Existem dois em cada cluster, um em /etc/pve/corosync.conf e o outro em /etc/corosync/corosync.conf . A edição de um em nosso sistema de arquivos de cluster propagará as alterações para o local, mas não vice-versa.
A configuração será atualizada automaticamente assim que o arquivo for alterado. Isso significa que as alterações que podem ser integradas em um corosync em execução terão efeito instantâneo. Portanto, você deve sempre fazer uma cópia e editá-la, para evitar disparar algumas alterações indesejadas por um entre o cofre.
cp / etc / pve / corosync . conf / etc / pve / corosync . conf . Novo
Em seguida, abra o arquivo Config com o seu editor favorito, o nano e o vim.tiny são pré-instalados no Proxmox VE, por exemplo.
|
Sempre incremente o número config_version nas mudanças de configuração, omitindo isso pode levar a problemas. |
Depois de fazer as alterações necessárias, crie outra cópia do arquivo de configuração atual em funcionamento. Isso serve como backup se a nova configuração não se aplicar ou causar problemas de outras maneiras.
cp / etc / pve / corosync . conf / etc / pve / corosync . conf . bak
Em seguida, mova o novo arquivo de configuração sobre o antigo:
mv / etc / pve / corosync . conf . novo / etc / pve / corosync . conf
Você pode verificar com os comandos
statusctl status corosync journalctl -b -u corosync
Se a alteração puder ser aplicada automaticamente. Se não, você pode ter que reiniciar o serviço corosync via:
reinicialização do systemctl corosync
Nos erros, verifique a seção de solução de problemas abaixo.
Solução de problemas
Problema: quorum.expected_votes deve ser configurado
Quando o corosync começa a falhar e você recebe a seguinte mensagem no log do sistema:
[...] corosync [1647]: [QUORUM] Provedor de quorum: corosync_votequorum falhou ao inicializar. corosync [1647]: [SERV] O mecanismo de serviço 'corosync_quorum' falhou ao carregar por motivo 'erro de configuração: nodelist ou quorum.expected_votes deve ser configurado!' [...]
Isso significa que o nome do host que você definiu para o corosync ringX_addr na configuração não pôde ser resolvido.
Escrever configuração quando não é
Se você precisar alterar o /etc/pve/corosync.conf em um nó sem quorum e souber o que faz, use:
pvecm esperado 1
Isso define a contagem de votos esperada para 1 e torna o cluster quorado. Agora você pode corrigir sua configuração ou revertê-la de volta ao último backup de trabalho.
Isso não é suficiente se o corosync não puder mais iniciar. Aqui é melhor editar a cópia local da configuração do corosync em /etc/corosync/corosync.conf para que o corosync possa ser iniciado novamente. Certifique-se de que em todos os nós essa configuração tenha o mesmo conteúdo para evitar cérebros divididos. Se você não tem certeza do que deu errado, é melhor pedir à Comunidade Proxmox para ajudá-lo.
Glossário de configuração do Corosync
- ringX_addr
- Isso nomeia os diferentes endereços de toque para os anéis de totem do corosync usados para a comunicação do cluster.
- bindnetaddr
- Define a qual interface o anel deve se ligar. Pode ser qualquer endereço da sub-rede configurada na interface que queremos usar. Em geral, é recomendado usar apenas um endereço que um nó usa nessa interface.
- rrp_mode
- Especifica o modo do protocolo de anel redundante e pode ser passivo, ativo ou nenhum. Note que o uso de ativos é altamente experimental e não é suportado oficialmente. Passivo é o modo preferido, ele pode dobrar o throughput de comunicação do cluster e aumentar a disponibilidade.
Cluster Cold Start
É óbvio que um cluster não é quorato quando todos os nós estão offline. Este é um caso comum após uma falha de energia.
|
É sempre uma boa idéia usar uma fonte de alimentação ininterrupta (“UPS”, também chamada de “backup de bateria”) para evitar esse estado, especialmente se você quiser HA. |
Na inicialização do nó, o serviço pve-guests é iniciado e aguarda o quorum. Uma vez quorate, ele inicia todos os convidados que possuem o sinalizador onboot definido.
Quando você liga nós ou quando a energia volta após uma falha de energia, é provável que alguns nós sejam inicializados mais rápido do que outros. Lembre-se de que a inicialização do convidado está atrasada até chegar ao quorum.
Migração Convidada
A migração de convidados virtuais para outros nós é um recurso útil em um cluster. Existem configurações para controlar o comportamento de tais migrações. Isso pode ser feito através do arquivo de configuração datacenter.cfg ou para uma migração específica via API ou parâmetros de linha de comando.
Faz diferença se um convidado estiver online ou offline, ou se tiver recursos locais (como um disco local).
Para obter detalhes sobre a Migração de Máquina Virtual, consulte o Capítulo sobre Migração do QEMU / KVM
Para obter detalhes sobre a migração de contêiner, consulte o capítulo sobre migração de contêineres
Tipo de Migração
O tipo de migração define se os dados de migração devem ser enviados por um canal criptografado ( seguro ) ou não criptografado ( inseguro ). Definir o tipo de migração como insegura significa que o conteúdo de RAM de um convidado virtual também é transferido sem criptografia, o que pode levar à divulgação de informações de dados críticos de dentro do convidado (por exemplo, senhas ou chaves de criptografia).
Portanto, é altamente recomendável usar o canal seguro se você não tiver controle total sobre a rede e não puder garantir que ninguém esteja interceptando o canal.
|
A migração de armazenamento não segue essa configuração. Atualmente, ele sempre envia o conteúdo de armazenamento por um canal seguro. |
A criptografia requer muita capacidade de computação, portanto, essa configuração é frequentemente alterada para “insegura” para obter um melhor desempenho. O impacto nos sistemas modernos é menor porque eles implementam a criptografia AES no hardware. O impacto no desempenho é particularmente evidente em redes rápidas, onde você pode transferir 10 Gbps ou mais.
Rede de Migração
Por padrão, o Proxmox VE usa a rede na qual a comunicação do cluster ocorre para enviar o tráfego da migração. Isso não é ideal porque o tráfego de cluster sensível pode ser interrompido e essa rede pode não ter a melhor largura de banda disponível no nó.
Definir o parâmetro de rede de migração permite o uso de uma rede dedicada para todo o tráfego de migração. Além da memória, isso também afeta o tráfego de armazenamento para migrações off-line.
A rede de migração é definida como uma rede na notação CIDR. Isso tem a vantagem de não ser necessário definir endereços IP individuais para cada nó. O Proxmox VE pode determinar o endereço real no nó de destino da rede especificada no formulário CIDR. Para habilitar isso, a rede deve ser especificada para que cada nó tenha um, mas somente um IP na respectiva rede.
Exemplo
Assumimos que temos uma configuração de três nós com três redes separadas. Uma para comunicação pública com a Internet, uma para comunicação em cluster e uma muito rápida, que queremos usar como uma rede dedicada à migração.
Uma configuração de rede para tal configuração pode ter a seguinte aparência:
iface eno1 inet manual # rede pública auto vmbr0 iface vmbr0 inet static endereço 192.XY57 netmask 255.255.250.0 gateway 192.XY1 bridge_ports eno1 bridge_stp off bridge_fd 0 # rede de cluster auto eno2 iface eno2 inet estático endereço 10.1.1.1 netmask 255.255.255.0 # rede rápida auto eno3 iface eno3 inet estático endereço 10.1.2.1 netmask 255.255.255.0
Aqui, usaremos a rede 10.1.2.0/24 como uma rede de migração. Para uma única migração, você pode fazer isso usando o parâmetro migration_network da ferramenta de linha de comando:
# qm migrar 106 tre --online --migration_network 10.1.2.0/24
Para configurar isso como a rede padrão para todas as migrações no cluster, defina a propriedade de migração do arquivo /etc/pve/datacenter.cfg :
# use a rede de migração dedicada migração: segura, rede = 10.1.2.0 / 24
|
O tipo de migração sempre deve ser definido quando a rede de migração é definida em /etc/pve/datacenter.cfg . |
