Micro cluster Proxmox para alta disponibilidade do HA

[Moacir_Ferreira]

@codedmind, se fosse eu:

1 - Não utilizaria Ceph em baixa densidade de discos; Ceph, para fazer sentido, requer uma cópia em tempo real e necessita de arbitragem para decidir que tudo está ok. Como só tens 1 disco por servidor, sempre que escreves um o dado no mesmo isto é imediatamente refletido via rede para mais um disco (cópia) e para a arbitragem. Enquanto o Ceph não garantiu a qualidade da cópia e arbitragem, ele reduz a capacidade (velocidade) de escrita.

2 - No teu caso específico, eu utilizaria ZFS (nativo do Nutanix). É absolutamente rápido e faz compactação sem que tenhas de fazer qualquer coisa, cópias de segurança, etc.

3 - Se puderes, compre um disco menor e instale o Proxmox nele; utilize o disco SSD de 450GB só para ZFS. Quantos mais discos por máquina tiveres, mais rápido fica; entretanto, se fores por aí tentes ter os discos de dados iguais em capacidade e desempenho.

Acho que te vais assustar com a performance se fizeres isto… Só para teste, experimente instalar um dos teus servidores com 2 discos, sendo um exclusivo para o sistema operativo Proxmox. Depois levante uma máquina virtual e faça testes de stress.

[Moacir_Ferreira]

Ainda neste assunto, veja na página oficial do produto Ceph o “hardware recommendations” deles:
https://docs.ceph.com/en/nautilus/start/hardware-recommendations/#data-storage

[codedmind]

Tudo isso foi feito … @Moacir_Ferreira

o proxmox esta instalado num disco, o ceph e tambem no zfs (fiz testes nos dois) e o problema era sempre o mesmo.

O microserver, tem limitação de até 4 slots de discos, sendo que apenas 2 sao 6Gbps e portanto apenas foi testado um disco em cluster por nó.

Os testes foram graduais, primeiro apenas com 1gib na placa de rede, com discos HDD… depois foi-se evoluindo para nic 10gb e discos sdd, que não sendo empresariais tem uma velocidade teorica de 500Mbps… o problema era sempre o mesmo… o i/o delay era absimal, como tinha muitas escritas num das vms/lxc (foram testados os dois tbm por bug do proxmox que só da informação num deles)

Sempre que era preciso “escrever” nos outros nós aumentava imenso o delay… era mais funcional (tinha menos delay) ter a vms em NFS com rede 1gb

O delay acabava por tornar todo o cluster lento, lá está é a minha experência

[Moacir_Ferreira]

Isto é um “balde de água fria”… Já estive a pensar comprar 3 mini-PCs para tentar fazer o mesmo. Obviamente, deve ter alguma coisa nestes PC (mini-servers) que impede o bom funcionamento do Proxmox. Minha experiência em servidores a rodar Proxmox é muito, muito positiva. Há uma “catrafada” de coisas que podem mexer com isto tipo TCP off-load para as placas de rede; velocidade real do barramento PCIE; número de discos; tipo de discos; não sei se tentaste mais até o MTU da rede pode afetar em muito a performance. Entretanto, para uma VM dentro de um servidor, a performance deveria ser elevada à menos que haja muita escrita de dados entre discos dos outros nós.

E a pergunta de fundo continua: Como é que “um gajo” dá redundância ao HA sem investir milhares de euros…

[codedmind]

@Moacir_Ferreira os meus posts servem apenas de “alerta” foi algo que eu nao reparei quando optei por mudar de exsi para proxmox e desta forma aproveitar o HA… porque lá está o proprio homeassistant não está pensado para funcionar dessa forma.

No meu caso especifico o problema o delay não é tanto do “hardwar”, apesar de correr em servidor os discos são domesticos, sdd, mas domésticos, no entanto para homelab as specs ão são assim tao fracas quanto isso. Prova, que usando um servidor normal não tem qualquer problema quando tem a carga toda que antes estava repartido por 3 nós.

Tive alguns cuidados, de usar os mesmos componentes em todos os nós.

A unica diferença para o caso do Luis, do que vimos na altura era a capacidade dos discos e o tipo, ele tem discos nvme e de menor capacidade.

Todos os testes que fiz o problema nunca foi na trasferencia entre os nós, o problema era sempre no sincronismos dos mesmos, o upgrade para 10Gib acabou por não ter uma melhoria muito grande em comparação com 1Gib porque transferia rapido, mas depois demorava quase o mesmo a fazer o sync.

Após alguma investigação, (o proxmox tem lacunas a reportar o disk write/diskread) em LXC o problema estava tanto no HA como no LXC mariadb e influxdb, como referi, tenho muitos sensores que guardam os dados de 15 em 15 segundos, o que usando hoje num nó e antes numca foi problema para o hardware usado (hdd) assim que tentei zfs/ceph mesmo alterando o disco para ssd foi problemático…

Print que ontem não deu para colocar

Em suma, proxmox é fixe mas quando se começa a pensar em cluster (seja ceph seja nfs) sugiro pensar duas vezes, principalmente em homelab em que o hardware será sempre mais modesto… sendo que o problema pode não ser do hardware e mais do que lá se pretende correr.

Outra questão a ter em conta é que HA no proxmox só com VM com LXC não é possivel, e portanto ha sempre off → move → on

[Moacir_Ferreira]

Há uns 4 anos atrás eu fui contratado para determinar como saturar, de forma sustentada, interfaces de 10Gbps e de 40Gbps em transferência de ficheiros. Me vi obrigado a estudar um monte de sistemas de file server/transferência de dados. A utilizar servidores Huawei de 2009 eu consegui saturar os 10Gbps com apenas um fluxo e saturar os 40Gbps com 2 fluxos concomitantes. A limitação estava no barramento PCIE e na forma como o NUMA funcionava numa máquina com dois sockets.

Não sei se vais à tempo (e com paciência para isto), mas deixo-te aqui os desafios…

Em meio aos teus estudos conseguiste determinar se o problema era a VM do HA ou do cluster em si? Por exemplo, instalaste 2 máquinas Linux, uma num nó outra noutro, e fizeste uma transferência de ficheiros grande entre elas?

Testaste a velocidade de comunicação em rede entre máquinas?

Se ainda tiveres o ambiente (e paciência), o ideal era fazer os dois testes:

1 - Testar a banda entre duas VMs Linux (i.e.: Ubuntu ou Centos), rodando em nós distintos, a utilizar iperf; a banda deveria ser próxima dos 10Gbps se estivesses a utilizar os 10Gbps;

2 - Testar desempenho de escrita em disco copiando, entre estas duas VMs acima, um grande volume de dados (i.e.: dá um “cat >>” de um ficheiro ISO 10 vezes para dentro de um outro ficheiro para ele ter uns 30GB e depois fazer um scp dele para a outra máquina.

Isto definiria se o problema era banda de rede ou banda de escrita em disco. Se não tiveres o Proxmox instalado para o efeito, pega dois dos teus servidores; instala com Linux + KVM. Faz os mesmos testes e terás uma ideia de onde é o gargalo real, se houver, no sistema.

[codedmind]

@Moacir_Ferreira eu fiz alguns desses testes

O problema nao era na performance pura e dura era ao longo do tempo, no sincronismo… o problema é que havia sempre dois nós em que o delay/io era muito grande… ao longo do tempo ia atascando o cluster como um todo

UPDATE: imagem de iperf

[codedmind]

No caso tinha o addon mariadb dentro do HomeAssistant, com a escrita de cerca de 2Mb do addon, empancava logo o delay (rondar os 20%) no cluster, bastava mudar o homeassistant para o disco local e todos os nós baixavam logo o delay (abaixo de 2%) para valores aceitaveis, sem isso o delay era enorme…

Nunca coloquei de parte ser problema de configuração, mas nunca vi como resolver, e fiz várias experiencias… no forum do proxmox a conversa era sempre a mesma… o hardware nao dá

@Moacir não me deixam respoder… Zona centro

Um teste ao disco apenas

[Moacir_Ferreira]

Ainda tens o cluster a rodar que dê para fazer testes?

Insisto que deverias estudar onde está o gargalo. Por vezes nos concentramos na parte do sistema sem dar por conta de outros fatores. Tem ainda um item importante que é saber se a tua placa de rede faz off-load de TCP e qual é o MTU da rede configurado nas placas e nos switches que utilizas.

Se bem feitos, os testes de iperf te revelariam problemas com pacotes com payloads pequenos e grandes. Os pacotes pequenos são o demónio para baixar performance, pelo que o teste de iperf deveria ser feito com um payload de 96 bytes e depois de 1500. Há que olhar com uma lupa se há erros na rede (verificar os contadores das placas e dos switches). Repara que a escrita na base de dados é sempre de pacotes pequenos.

Em resumo, eu não estou convencido que seja o Proxmox em si. O teste que te sugeri de transferência de dados entre máquinas virtualizadas em 2 nós distintos poderia te dar uma visão real do que se passa, a testar banda real de rede e banda real de disco. Pense nisto…

Já agora, em que parte do país te encontras?

[Moacir_Ferreira]

@codedmind, tal como prometi, eu pedi ajuda a um amigo sénior em Proxmox. Ele tem em casa um cluster com micro servidores, discos normais, a funcionar bem. Ele disse-me que tens de habilitar o caching dos discos SSD que é desabilitado por defeito devido as performances de discos ampresariais. Para ver se os teus discos estão ou não com o caching habilitado dê o comando “hdparm -W /dev/sdX” onde “X” é o número do disco.

A segunda dica foi de que tens de desligar o sincronismo dos discos em tempo real e ele passa para sincronismo à cada 5 segundos. Como óbvio, se houver uma grande falha perdes os 5 segundos… Se tiveres interesse, leia esta thread do fórum Promox a verás como fazer:

[SOLVED] - Slow ZFS performance

[Luis_Andrade (Luís Miguel Andrade)]

@Moacir_Ferreira

hdparm -W /dev/sdX

No meu tenho os SSDs do CEPH com write-caching =1 (on) . Contudo, não estou recordado de ter alterado… mas, como já tenho feito a alguns anos é possível que tenha feito por ter sido tudo por linha de comandos.

Esse sincronismo é para o CEPH?!

[Moacir_Ferreira]

Segundo o meu amigo, o caching de SSD é desabilitado por defeito devido a velocidade de escrita dele. Contudo, se não for um SSD “topo de gama”, então a performance aumenta em muito se tiveres o caching ativo pois este é feito em memória.

O remover do sincronismo em tempo real abordado no artigo acima é para o ZFS. Não sei se o mesmo pode ser feito em Ceph…

[codedmind]

@Moacir_Ferreira como podes ver no post que fiz antes do teu tenho uma imagem em que testei isso mesmo com o cache ativo e não ativo, na tabela dá para ver as diferenças de velocidades…

[Moacir_Ferreira]

Tentaste desabilitar o sincronismo???

[codedmind]

Testei a velocidade do disco com cache ativo e cache desativo…

O sincronismo já não tenho a certeza se cheguei a testar ou nao

[Luis_Andrade (Luís Miguel Andrade)]

A parte do SSD concordo e até é possível que tenha ativado e não estou recordado.Contudo, tenho também ativo no disco de sistema e nesse tenho a certeza de não ter feito esta alteração. Por isso acho que pode ter sido por defeito.

Não estava a entender a parte do ZFS visto estarmos a falar em CEPH.

[Moacir_Ferreira]

Pois é Luís… No ZFS há como desabilitar o sincronismo em tempo real. Não sei se é possível fazer o mesmo em CEPH. Se for possível, acho que seria um bom teste a fazer. Este meu amigo disse-me que a velocidade de escrita em disco aumento em cerca de 2,5 vezes com o sincronismo desabilitado.

[codedmind]

O meu problema nao era na velocidade de escrita era mesmo no tempo que demorava a “escrever/sincronizar” nos outros…

Mas posso ligar o cluster e fazer os testes que indicarem

PS: todos os sdds dos nós tem o cache ativo

[Moacir_Ferreira]

Eu acho que não custa tentar… Já tens tudo mesmo “marado”…

[codedmind]

Llololo… mas tentar o que?