Eu gostava de me valer de funções do tipo High Availability do Proxmox para suportar o meu HA. Entretanto, não quero fazer um cluster com 3 servidores só para isto (não há dinheiro!). Queria ter algo do tipo raspberry (ou similar) cujo o preço fosse muito em conta mas rodasse Proxmox e me desse a redundância que quero ter. Minha ideia é ter só mesmo o HA virtualizado neste micro cluster, mais nada.
Alguma sugestão?
Uma solução viável de alta disponibilidade “low cost” é sem dúvida um projecto interessante. Mas, como diz o velho provérbio “não se fazem omeletes sem ovos”… e, muito menos sem os partir.
Existem diversas abordagens sobre ter um sistema em alta disponibilidade. Contudo, não tenho conhecimento de existir alguma solução que envolva o nível de hardware que estás a identificar e que seja viável para o HA.
Não obstante do dito acima, será possível utilizar o proxmox com ceph em hardware de baixo custo e obter algo que seja minimamente aceitável na parte de resultados perante o objectivo pretendido.
Há pelo menos um projeto de Proxmox em raspberry (pimox). Meu problema com PCs seria comprar 3 placas + CPU + memória + 3 fontes + 9 discos, só para manter um HA em elevada disponibilidade. Pior, também quero fugir à complexidade em sistemas.
Já não toco em Ceph faz anos… Quando fiz algum estudo nessa área, o Ceph era largamente utilizado em OpenStack, coisa que também não toco há muito tempo. Entretanto, naquela época o Proxmox trabalhava com Gluster modificado e não com Ceph.
Talvez a solução adequada para mim seja ter 2 máquinas de alguma forma espelhadas. Não sei se, nativamente, o HA tem alguma solução para isto. Eu gostava de ter algo que eu instalasse e esquecesse que existia. Algo simples e fácil de manitenção no dia a dia. Contudo, com bem disseste, não se faz omeletes sem ovos e pior, sem parti-los…
Tenho o meu HA num cluster de alta disponibilidade a funcionar com 0% de indisponibilidade a cerca de 3 anos com proxmox e ceph. O mínimo de hw que acho possível para atingir os objetivos depende de 4 níveis: energia, rede, processamento e armazenamento. Em todos estes níveis tens de ter no mínimo 2 equipamentos para assegurar a falha de 1.
No que respeita ao mínimo de 2 equipamentos, vão servir a parte de rede (2 switch) e energia (2 origens de energia). Na parte de processamento e armazenamento, considero o mínimo de 3 para não depender de cenários ativo-passivo e ter a garantia de um quórum de decisão (só possível com mínimo de 3).
Nestes pressupostos, os recursos mínimos são 3 máquinas para processamento e armazenamento com as seguintes caraterísticas: 4 portas de rede (2 ceph e 2 para fora), 2 discos (1 sistema e 1 ceph).
Algo diferente, na minha opinião, dificilmente irá atingir os requisitos mínimos para garantir a não perca de dados ou duplicação e assegurar as várias camadas necessárias para um sistema completo de alta disponibilidade.
Da minha experiencia de uso… há que ter em conta algo muito importante que é a quantidade de escrita/leitura em disco que o HA vai utilizar.
O hardware do luis é inferior ou que eu usei e ainda assim desmontei o cluster, não é funcional sequer tal a lentidão.
Ou seja, ainda antes de pensar em hardware há que validar os requisitos do teu HA
@codedmind, deves ter algo errado no teu cluster… Proxmox é absolutamente rápido desde que tenhas boa velocidade entre as interfaces de rede e bons discos. Eu, particularmente, não gosto da performance do Ceph para instalações com demanda de serviços simples como os residenciais (para mim é um “over kill”). O meu HA roda virtualizado em KVM e não tenho qualquer problema de desempenho, pelo menos por enquanto. Entretanto, não tenho redundância…
Não ha nada de errado… é mesmo problema de performance com a escrita e a latencia.
Rede 10GB e ssd… a limitação são os 16GB de ram apenas em cada nó
A depender do tamanho de disco e sub-sistema (Ceph, Gluster, ZFS, etc.), podes consumir um imenso volume de memória só para manter este sub-sistema. As vezes subestimamos a complexidade e carga na virtualização… Diz-me lá:
Todo e qualquer sistema deve estar dimensionado em proporção das necessidades do lado do hw como do sw.
Naturalmente, se deixarmos a VM do HA com determinadas configurações de origem (podem ou não ser necessárias), a quantidade de acessos de leitura/escrita poderá atingir valores que vão causar lentidão devido ao IO delay com origem no ceph.
No meu caso em especifico, tive/tenho o cuidado de “afinar” o que entendo com necessário para evitar o acima dito. A título de exemplo, faço só a inclusão de registo dos sensores que pretendo guardar histórico; não utilizo determinados addons (conhecidos por serem muito “pesados” e dispensáveis dentro do HA), … para além de outras configurações ao nível do ceph que entendi como serem mais adequadas ao meu cenário em específico.
A VM do HA com cerca de 15 addons e mais de 100 integrações (sem contar com as do HACS) anda por norma com este tipo de comportamento:
A máquina física (só com a VM do HA), anda com carga média de 20% e IO delay de 0,5% em idle:
O único momento de lentidão (devido ao IO delay) que noto é só quando faço updates aos addons e HA. Contudo é algo que não sinto minimamente incomodado por não ser uma tarefa que seja assim tão demorada e/ou diária.
@Moacir como disse, nao tenho nada contra e dei o proprio exemplo do @Luis que me acompanhou nesta implementação e no meu caso concreto, apesar de ter “hardware mais performante” do que o Luis e a performance era insuficiente!
Eu tenho muitos acessos ao disco porque tenho muitos sensores e com leituras frequentes (15 segundos), mas para mim não faz sentido ter um cluster e perder dados de sensores… como sao muitos sensores a escrever com muita frequencia o delay ia aumentado.
O cluster era constituido por 3 nos com 16gb de ram, cada nó com um disco ssd de 450GB e cpu xeon e3-1265L v2, todos os nós com nics de 10GB entre eles e nics e 1GB para acesso à rede
Só uma VM (a do Homeassistant com 4gb de ram) de resto LXC, com mariadb influxdb etc… em nenhum nó a memoria do que estava a correr era superior aos 10gb.
Este apenas um nó com a carga que antes estava divida em cluster e o delay chegava aos 20%
Alguns prints que provam a má performance da coisa
@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.
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
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
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…
@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
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.
@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
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
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?
Copyright © 2017-2021. Todos os direitos reservados
CPHA.pt - info@cpha.pt
