Este artigo foi escrito para ajudá-lo a escolher a solução certa para você e entender as diferenças entre SDS como Gluster, Ceph e Vstorage (Virtuozzo).
O texto utiliza links para artigos com divulgação mais detalhada de determinados problemas, de modo que as descrições serão tão breves quanto possível, utilizando pontos-chave sem bobagens desnecessárias e informações introdutórias que você pode, se desejar, obter de forma independente na Internet.
Na verdade, é claro, os temas levantados exigem os tons do texto, mas no mundo moderno cada vez mais pessoas não gostam de ler muito))), então você pode ler rapidamente e fazer uma escolha, e se algo for não está claro, siga os links ou procure palavras pouco claras no Google))), e este artigo é como um invólucro transparente para esses tópicos profundos, mostrando o preenchimento - os principais pontos-chave de cada decisão.
brilho
Vamos começar com o Gluster, que é usado ativamente por fabricantes de plataformas hiperconvergentes com SDS baseadas em código aberto para ambientes virtuais e pode ser encontrado no site da RedHat na seção de armazenamento, onde você pode escolher entre duas opções de SDS: Gluster ou Ceph.
O Gluster consiste em uma pilha de tradutores – serviços que realizam todo o trabalho de distribuição de arquivos, etc. Brick é um serviço que atende um disco, Volume é um volume (pool) que une esses tijolos. Em seguida vem o serviço de distribuição de arquivos em grupos usando a função DHT (tabela hash distribuída). Não incluiremos o serviço Sharding na descrição, pois os links abaixo descreverão os problemas associados a ele.
Ao gravar, todo o arquivo é armazenado no tijolo e sua cópia é simultaneamente gravada no tijolo no segundo servidor. A seguir, o segundo arquivo será gravado no segundo grupo de dois blocos (ou mais) em servidores diferentes.
Se os arquivos tiverem aproximadamente o mesmo tamanho e o volume consistir em apenas um grupo, então está tudo bem, mas sob outras condições surgirão os seguintes problemas a partir das descrições:
- o espaço nos grupos é utilizado de forma desigual, depende do tamanho dos arquivos e se não houver espaço suficiente no grupo para gravar um arquivo, você receberá um erro, o arquivo não será gravado e não será redistribuído para outro grupo ;
- ao gravar um arquivo, o IO vai apenas para um grupo, o restante fica ocioso;
- você não pode obter IO de todo o volume ao gravar um arquivo;
- e o conceito geral parece menos produtivo devido à falta de distribuição dos dados em blocos, onde é mais fácil equilibrar e resolver o problema de distribuição uniforme, e não como agora o arquivo inteiro vai para um bloco.
Da descrição oficial também involuntariamente chegamos à conclusão de que o gluster funciona como armazenamento de arquivos sobre o RAID de hardware clássico. Houve tentativas de desenvolvimento de cortar (sharding) arquivos em blocos, mas tudo isso é um acréscimo que impõe perdas de desempenho na abordagem arquitetural já existente, além do uso de componentes distribuídos gratuitamente com limitações de desempenho como o Fuse. Não há serviços de metadados, o que limita o desempenho e as capacidades de tolerância a falhas do armazenamento ao distribuir arquivos em blocos. Melhores indicadores de desempenho podem ser observados com a configuração “Distribuído Replicado” e o número de nós deve ser de pelo menos 6 para organizar uma réplica confiável 3 com distribuição de carga ideal.
Essas descobertas também estão relacionadas à descrição da experiência do usuário e quando comparado com , e há também uma descrição da experiência que leva à compreensão desta configuração mais produtiva e confiável
A imagem mostra a distribuição de carga ao gravar dois arquivos, onde cópias do primeiro arquivo são distribuídas pelos três primeiros servidores, que são combinados no grupo volume 0, e três cópias do segundo arquivo são colocadas no segundo grupo volume1 de três servidores. Cada servidor possui um disco.
A conclusão geral é que você pode usar o Gluster, mas com o entendimento de que haverá limitações de desempenho e tolerância a falhas que criam dificuldades sob certas condições de uma solução hiperconvergente, onde recursos também são necessários para as cargas computacionais de ambientes virtuais.
Existem também alguns indicadores de desempenho do Gluster que podem ser alcançados sob certas condições, limitados a
ceph
Agora vamos dar uma olhada no Ceph a partir das descrições de arquitetura que consegui Há também uma comparação entre , onde você pode entender imediatamente que é aconselhável implantar o Ceph em servidores separados, pois seus serviços requerem todos os recursos de hardware sob carga.
Arquitetura mais complexo que o Gluster e existem serviços como serviços de metadados, mas toda a pilha de componentes é bastante complexa e pouco flexível para uso em uma solução de virtualização. Os dados são armazenados em blocos, o que parece mais produtivo, mas na hierarquia de todos os serviços (componentes), há perdas e latência sob determinadas cargas e condições de emergência, por exemplo o seguinte
A partir da descrição da arquitetura, o coração é o CRUSH, graças ao qual é selecionado o local de armazenamento dos dados. Em seguida vem o PG - esta é a abstração (grupo lógico) mais difícil de entender. Os PGs são necessários para tornar o CRUSH mais eficaz. O principal objetivo do PG é agrupar objetos para reduzir o consumo de recursos, aumentar o desempenho e a escalabilidade. Abordar objetos diretamente, individualmente, sem combiná-los em um PG seria muito caro. OSD é um serviço para cada disco individual.
Um cluster pode ter um ou vários pools de dados para finalidades diferentes e com configurações diferentes. Os pools são divididos em grupos de colocação. Os grupos de posicionamento armazenam objetos que os clientes acessam. É aqui que o nível lógico termina e o nível físico começa, porque a cada grupo de posicionamento é atribuído um disco principal e vários discos de réplica (quantos dependem exatamente do fator de replicação do pool). Em outras palavras, no nível lógico, o objeto é armazenado em um grupo de posicionamento específico e no nível físico - nos discos atribuídos a ele. Nesse caso, os discos podem estar localizados fisicamente em nós diferentes ou mesmo em data centers diferentes.
Neste esquema, os grupos de colocação aparecem como um nível necessário para a flexibilidade de toda a solução, mas ao mesmo tempo, como um elo extra nesta cadeia, o que involuntariamente sugere uma perda de produtividade. Por exemplo, ao gravar dados, o sistema precisa dividi-los nesses grupos e, em seguida, no nível físico, no disco principal e nos discos para réplicas. Ou seja, a função Hash funciona ao pesquisar e inserir um objeto, mas há um efeito colateral - são custos muito altos e restrições para reconstruir o hash (ao adicionar ou remover um disco). Outro problema de hash é a localização claramente definida dos dados que não podem ser alterados. Ou seja, se de alguma forma o disco estiver sob carga aumentada, então o sistema não terá a oportunidade de não gravar nele (selecionando outro disco), a função hash obriga os dados a serem localizados de acordo com a regra, por pior que seja o disco é, então o Ceph consome muita memória ao reconstruir o PG em caso de autocorreção ou aumento de armazenamento. A conclusão é que o Ceph funciona bem (embora lentamente), mas apenas quando não há escalonamento, situações de emergência ou atualizações.
É claro que existem opções para aumentar o desempenho por meio de cache e compartilhamento de cache, mas isso requer um bom hardware e ainda haverá perdas. Mas, no geral, o Ceph parece mais tentador do que o Gluster em termos de produtividade. Além disso, ao utilizar estes produtos, é necessário levar em consideração um fator importante - este é um alto nível de competência, experiência e profissionalismo com grande ênfase no Linux, pois é muito importante implantar, configurar e manter tudo corretamente, o que impõe ainda mais responsabilidade e ônus ao administrador.
Varmazenamento
A arquitetura parece ainda mais interessante , que pode ser usado em conjunto com um hipervisor nos mesmos nós, no mesmo , mas é muito importante configurar tudo corretamente para conseguir um bom desempenho. Ou seja, implantar tal produto pronto para uso em qualquer configuração sem levar em conta as recomendações de acordo com a arquitetura será muito fácil, mas não produtivo.
O que pode coexistir para armazenamento ao lado dos serviços do hipervisor kvm-qemu, e estes são apenas alguns serviços onde uma hierarquia compacta ideal de componentes foi encontrada: serviço de cliente montado via FUSE (modificado, não de código aberto), serviço de metadados MDS (serviço de metadados), serviço de blocos de dados de serviço Chunk, que no nível físico é igual a um disco e pronto. Em termos de velocidade, é claro, é ideal usar um esquema tolerante a falhas com duas réplicas, mas se você usar cache e logs em unidades SSD, a codificação tolerante a erros (erase coding ou raid6) pode ter um overclock decente em um esquema híbrido ou melhor ainda em flash. Existe alguma desvantagem com EC (apagar codificação): ao alterar um bloco de dados, é necessário recalcular os valores de paridade. Para contornar as perdas associadas a esta operação, o Ceph grava no EC de forma diferida e problemas de desempenho podem ocorrer durante uma determinada solicitação, quando, por exemplo, todos os blocos precisam ser lidos, e no caso do Virtuozzo Storage, a escrita dos blocos alterados é realizada usando a abordagem de “sistema de arquivos estruturado em log”, que minimiza os custos de cálculo de paridade. Para estimar aproximadamente as opções com aceleração de trabalho com e sem CE, existem – os valores podem ser aproximados dependendo do coeficiente de precisão do fabricante do equipamento, mas o resultado dos cálculos é uma boa ajuda no planejamento da configuração.
Um simples diagrama de componentes de armazenamento não significa que esses componentes não absorvam mas se você calcular todos os custos antecipadamente, poderá contar com a colaboração junto ao hipervisor.
Existe um esquema para comparar o consumo de recursos de hardware pelos serviços de armazenamento Ceph e Virtuozzo.
Se antes era possível comparar Gluster e Ceph usando artigos antigos, usando as linhas mais importantes deles, então com Virtuozzo é mais difícil. Não existem muitos artigos sobre este produto e as informações só podem ser obtidas na documentação em ou em russo se considerarmos Vstorage como armazenamento utilizado em algumas soluções hiperconvergentes em empresas como e Acronis.
Vou tentar ajudar com uma descrição dessa arquitetura, então haverá um pouco mais de texto, mas leva muito tempo para você mesmo entender a documentação, e a documentação existente só pode ser usada como referência revisando a tabela de conteúdos ou pesquisa por palavra-chave.
Vamos considerar o processo de gravação em uma configuração de hardware híbrida com os componentes descritos acima: a gravação começa a ir para o nó a partir do qual o cliente a iniciou (o serviço de ponto de montagem FUSE), mas o componente mestre do Metadata Service (MDS) irá, é claro direciona o cliente diretamente para o serviço de chunk desejado (blocos CS de serviço de armazenamento), ou seja, o MDS não participa do processo de gravação, mas simplesmente direciona o serviço para o chunk desejado. Em geral, podemos fazer uma analogia com a gravação de despejar água em barris. Cada barril é um bloco de dados de 256 MB.
Ou seja, um disco é um certo número desses barris, ou seja, o volume do disco dividido por 256 MB. Cada cópia é distribuída para um nó, a segunda quase em paralelo para outro nó, etc... Se tivermos três réplicas e houver discos SSD para cache (para leitura e gravação de logs), então a confirmação da gravação ocorrerá após a gravação o log para o SSD e a redefinição paralela do SSD continuará no HDD, como se estivesse em segundo plano. No caso de três réplicas, o registro será confirmado após a confirmação do SSD do terceiro nó. Pode parecer que a soma da velocidade de gravação de três SSDs pode ser dividida por três e obteremos a velocidade de gravação de uma réplica, mas as cópias são gravadas em paralelo e a velocidade de latência da rede geralmente é maior que a do SSD, e na verdade o desempenho de gravação dependerá da rede. Nesse sentido, para ver IOPS reais, você precisa carregar corretamente todo o Vstorage , ou seja, testar a carga real, e não memória e cache, onde é necessário levar em consideração o tamanho correto do bloco de dados, número de threads, etc.
O log de gravação acima mencionado no SSD funciona de forma que, assim que os dados nele entram, são imediatamente lidos pelo serviço e gravados no HDD. Existem vários serviços de metadados (MDS) por cluster e seu número é determinado por um quorum, que funciona de acordo com o algoritmo Paxos. Do ponto de vista do cliente, o ponto de montagem FUSE é uma pasta de armazenamento do cluster que é simultaneamente visível para todos os nós do cluster, cada nó possui um cliente montado de acordo com este princípio, portanto este armazenamento está disponível para cada nó.
Para o desempenho de qualquer uma das abordagens descritas acima, é muito importante, na fase de planejamento e implantação, configurar corretamente a rede, onde haverá balanceamento devido à agregação e largura de banda do canal de rede corretamente selecionada. No total, é importante escolher o modo de hashing e os tamanhos de quadro corretos. Há também uma diferença muito forte em relação ao SDS descrito acima, este é o fusível com a tecnologia fast path no Virtuozzo Storage. Que, além do fusível modernizado, ao contrário de outras soluções de código aberto, aumenta significativamente o IOPS e permite não ficar limitado pela escala horizontal ou vertical. Em geral, em comparação com as arquiteturas descritas acima, esta parece mais poderosa, mas para tanto prazer, é claro, é necessário comprar licenças, ao contrário do Ceph e do Gluster.
Resumindo, podemos destacar o topo dos três: Virtuozzo Storage fica em primeiro lugar em termos de desempenho e confiabilidade da arquitetura, Ceph fica em segundo e Gluster fica em terceiro.
Os critérios pelos quais o Virtuozzo Storage foi selecionado: é um conjunto ideal de componentes arquitetônicos, modernizados para esta abordagem Fuse com caminho rápido, um conjunto flexível de configurações de hardware, menor consumo de recursos e capacidade de compartilhamento com computação (computação/virtualização), isto é, é completamente adequado para uma solução hiperconvergente, da qual ele faz parte. Em segundo lugar fica o Ceph por ser uma arquitetura mais produtiva em relação ao Gluster, devido ao seu funcionamento em blocos, além de cenários mais flexíveis e capacidade de trabalhar em clusters maiores.
Há planos para escrever uma comparação entre vSAN, Space Direct Storage, Vstorage e Nutanix Storage, testando Vstorage em equipamentos HPE e Huawei, bem como cenários para integração de Vstorage com sistemas de armazenamento de hardware externo, então se você gostou do artigo, seria é um prazer receber seu feedback, o que pode aumentar a motivação para novos artigos, levando em consideração seus comentários e desejos.
Fonte: habr.com