🍜 👩‍🏭 👨🏾 Por que hiperconvergência? Visão geral e testes do Cisco HyperFlex 🤟🏾 🍤 👩🏽‍🔧

Em TI, o principal é três letras

A tarefa de qualquer infraestrutura de TI é fornecer uma plataforma confiável para os processos de negócios da empresa. Tradicionalmente, acredita-se que a qualidade da infraestrutura de tecnologia da informação seja avaliada de acordo com três parâmetros principais: acessibilidade, segurança e confiabilidade. No entanto, a avaliação para esse triplo não está de forma alguma relacionada aos negócios e à receita / perda direta da empresa.

Três letras principais governam a TI. Se as letras "RUB" não estiverem no topo da hierarquia de TI, você estará criando sua infraestrutura de TI incorretamente. Obviamente, é difícil criar TI diretamente, começando apenas com receitas / despesas; portanto, existe uma hierarquia de “três letras” - das mais importantes às mais privadas. SLA, RPO, RTO, GRC - tudo isso é conhecido por especialistas do setor e há muito tempo é usado na construção de infra-estruturas. Infelizmente, nem sempre vinculamos esses indicadores a uma hierarquia de ponta a ponta.

Hoje, muitas empresas estão construindo infraestrutura para o futuro usando a tecnologia de ontem na arquitetura de ontem. E, ao mesmo tempo, o desenvolvimento acelerado da TI mostra que os serviços modernos estão mudando fundamentalmente não apenas os negócios, mas também a sociedade - as pessoas da era digital estão acostumadas ao fato de que alguns segundos são suficientes para acessar qualquer informação. A TI de uma tecnologia incompreensível se tornou comum para as massas, como um hambúrguer ou uma cafeteria. Isso adicionou novas três cartas extremamente importantes à TI. Essas cartas - TTM (Time to market) - o tempo antes do lançamento de um serviço produtivo no mercado.

Sds

Por outro lado, um kraken surgiu das profundezas da tecnologia, revertendo a TI e o estilo de vida tradicionais. À medida que o poder de computação dos processadores x86 aumentou, os sistemas de armazenamento de software se tornaram o primeiro tentáculo. Os sistemas clássicos de armazenamento eram peças muito específicas de ferro cheias de “silício personalizado”, vários aceleradores de hardware proprietários e software especializado. E era administrado por uma pessoa especialmente treinada que era praticamente adorada na companhia como sacerdote de um culto das trevas. Expandir o sistema de armazenamento de dados em operação na empresa foi um projeto inteiro, com muitos cálculos e aprovações - afinal, é caro!

O alto custo e a complexidade estimularam a criação de sistemas de armazenamento de software sobre o hardware x86 usual, com um sistema operacional de uso geral comum - Windows, Linux, FreeBSD ou Solaris. Somente o software permaneceu no hardware personalizado complexo, funcionando nem mesmo no kernel, mas no nível do usuário. Os primeiros sistemas de software eram obviamente bastante simples e limitados em funcionalidade, geralmente eram soluções de nicho especializadas, mas o tempo passava. E agora até grandes fornecedores de sistemas de armazenamento começaram a abandonar soluções especializadas de hardware - o TTM para esses sistemas não podia mais suportar a concorrência e o custo do erro tornou-se muito alto. De fato, com raras exceções, até os sistemas de armazenamento clássicos até 2020 se tornaram os servidores x86 mais comuns, apenas com lindos focinhos de plástico e várias prateleiras de discos.

O segundo tentáculo do kraken que se aproxima é a aparência e a adoção maciça pelo mercado da tecnologia de memória flash, que se tornou um pilar de concreto quebrando as costas de um elefante.
O desempenho dos discos magnéticos não muda há muitos anos e os processadores dos controladores de armazenamento lidam completamente com centenas de discos. Porém, mais cedo ou mais tarde, a quantidade se tornará qualidade - e o sistema de armazenamento já está em um nível médio, sem mencionar o inicial, e possui um limite superior no número significativo de unidades flash. Com uma certa quantidade (literalmente de dez discos), o desempenho do sistema não para de crescer, mas também pode começar a diminuir devido à necessidade de processar um volume cada vez maior. Afinal, o poder de processamento e a taxa de transferência dos controladores não mudam com o aumento da capacidade. A solução, em teoria, foi o surgimento de sistemas de expansão que podem montar muitas prateleiras independentes com discos e recursos de processador em um único cluster que parece de fora como um único sistema de armazenamento com vários controladores. Restava apenas um passo.

Hiper convergência

O passo mais óbvio para o futuro foi a unificação de pontos de processamento e armazenamento de dados anteriormente díspares. Em outras palavras, por que não implementar o armazenamento distribuído, não em servidores separados, mas diretamente nos hosts de virtualização, recusando, assim, uma rede de armazenamento especial e um hardware dedicado, combinando funções. O kraken acordou.
Mas deixe-me dizer, você vê, porque combinação é convergência. De onde veio esse prefixo estúpido hiper?

. + + . . , “ ”.
…
, , , . — SDS.

:

— , , , /. .
Sistema convergente - tudo de uma fonte, um suporte, um número de parceiro. Não deve ser confundido com a montagem automática de um fornecedor.

E acontece que o termo para nossa arquitetura convergente já foi adotado. Exatamente a mesma situação que com o supervisor.

Sistema hiperconvergente - Um sistema convergente com arquitetura convergente.

As definições são retiradas do artigo " Teoria Geral e Arqueologia da Virtualização ", na qual escrevi uma parte animada.

O que dá a abordagem hiperconvergente no aplicativo às três letras mencionadas?

Comece com um volume mínimo (e custo mínimo)
Capacidade de armazenamento cresce com poder de computação
Cada nó do sistema é seu controlador - e o problema do "teto de vidro" é removido (os discos podem, mas o controlador não existe mais)
Gerenciamento de armazenamento simplificado drasticamente

Para o último parágrafo, os sistemas hiperconvergentes não gostam muito dos administradores de armazenamento no modo antigo, usados para administrar filas nas portas Fibre Channel. O espaço é alocado em apenas alguns cliques do mouse no console de gerenciamento da infraestrutura virtual.

Em outras palavras, apenas as nuvens são mais rápidas que os sistemas hiperconvergentes no lançamento de um produto, mas as nuvens não são adequadas para todos e / ou nem sempre.

Se você é um administrador técnico e lê até aqui - regozije-se, as palavras gerais terminaram e agora vou falar sobre minha visão pessoal do sistema Cisco Hyperflex, que recebi em patas tenazes por realizar vários testes nele.

Cisco Hyperflex

Por que a Cisco

A Cisco é conhecida principalmente como fornecedor dominante no mercado de equipamentos de rede, mas ao mesmo tempo está amplamente presente em outros segmentos do mercado de data centers, oferecendo soluções para servidores e hiperconvergentes, bem como sistemas de automação e controle.

Surpreendentemente, até 2020, ainda existem pessoas: “Servidores Cisco? E de quem ela os tira?
A Cisco começou a lidar com servidores já em 2009, escolhendo o caminho do crescimento ativo das soluções blade naquele momento. A idéia da Cisco era implementar a abordagem de calculadoras anônimas. O resultado foi um sistema UCS (Sistema de Computação Unificado) que consiste em dois comutadores especializados (chamados de Fabric Interconnect) e de 1 a 20 chassis (8 blades de tamanho médio) ou até 160 servidores. Ao mesmo tempo, o chassi tornou-se geralmente estúpido com um pedaço de ferro com potência, toda a lógica e comutação são feitas no Fabric Interconnect; o chassi é apenas uma maneira de hospedar servidores e conectá-los ao sistema. O Fabric Interconnect é totalmente responsável por todas as interações do servidor com o mundo externo - Ethernet, FC e gerenciamento. Parece que as lâminas e lâminas, o que está lá, exceto para comutação externa, e não como todos os outros no chassi.

Um momento chave na implementação dessas mesmas “calculadoras anônimas”. Como parte do conceito do Cisco UCS, os servidores não têm outra personalidade além de um número de série. Nem MAC, nem WWN, nem qualquer outra coisa. O sistema de gerenciamento UCS desenvolvido pela Fabric Interconnect é baseado em perfis e modelos de servidor. Após conectar um pacote de servidores no chassi, eles precisam receber um perfil apropriado, dentro do qual todos os endereços e identificadores de identificação são definidos. Obviamente, se você tiver apenas uma dúzia de servidores, o jogo não valerá a pena. Mas quando há pelo menos duas, ou mesmo três dúzias delas, essa é uma vantagem séria. Torna-se fácil e rápido migrar configurações ou, mais importante, replicar configurações de servidor na quantidade certa, aplicar as alterações imediatamente a um grande número de servidores,essencialmente gerenciando um conjunto de servidores (por exemplo, um farm de virtualização) como uma única entidade. A abordagem proposta no sistema UCS permite, com a abordagem correta, simplificar seriamente a vida dos administradores, aumentar a flexibilidade e reduzir significativamente os riscos, para que os blades UCS literalmente em 2 a 3 anos se tornem a plataforma blade mais vendida no Hemisfério Ocidental, e hoje eles são globalmente uma das duas plataformas dominantes, junto com a HPE.

Logo ficou claro que a mesma abordagem baseada em uma fábrica universal com gerenciamento integrado baseado em políticas e modelos é totalmente requisitada e se aplica não apenas a blades, mas também a servidores em rack. E, nesse sentido, os servidores de montagem em rack da Cisco conectados ao Fabric Interconnect obtêm os mesmos benefícios que tornam os blades tão populares.

Hoje vou falar sobre o HyperFlex, uma solução hiperconvergente da Cisco construída em servidores montados em rack conectados ao Fabric Interconnect. O que torna o HyperFlex interessante e vale a pena considerar na revisão:

Cisco , , «» – , HyperFlex; , , , HyperFlex ;
– ; HyperFlex , , ; , .
« » — « », , ;
Fabric Interconnect Cisco -, SAN , native FC;
“” – , , ;
Cisco , , , ;
, , Cisco HCI, , HyperFlex , , .

O HyperFlex é um verdadeiro sistema hiperconvergente com VMs controladoras dedicadas. Deixe-me lembrá-lo de que a principal vantagem dessa arquitetura é sua portabilidade potencial para diferentes hipervisores. Hoje, a Cisco implementou o suporte ao VMware ESXi e Microsoft Hyper-V, mas é possível que uma das opções do KVM apareça à medida que sua popularidade cresce no segmento corporativo.

Considere o mecanismo de trabalho no exemplo do ESXi.

Os dispositivos que usam a tecnologia VM_DIRECT_PATH - disco de cache e discos de nível de armazenamento - são lançados diretamente para a VM do controlador (a seguir CVM). Portanto, excluímos o efeito da pilha de discos do hipervisor no desempenho. Pacotes VIB adicionais são instalados no próprio hypervisor:

IO Visor: fornece o ponto de montagem do armazenamento de dados NFS para o hypervisor
VAAI: VMware API « »

Os blocos de disco virtual são distribuídos uniformemente por todos os hosts em um cluster com relativamente pouca granularidade. Quando a VM no host executa algum tipo de operação em disco, através da pilha de discos do hipervisor, a operação vai para o armazenamento de dados, depois para o IO Visor e depois para a CVM responsável por esses blocos. Nesse caso, o CVM pode estar localizado em qualquer host do cluster. Dado os recursos muito limitados do IO Visor, é claro que não há tabelas de metadados e a escolha é matematicamente determinada. Em seguida, a CVM que a solicitação chegou processou. No caso de leitura, ele envia dados de um dos níveis de cache (RAM, cache de gravação, cache de leitura) ou dos discos de seu host. No caso de gravação, ele grava no diário local e duplica a operação para um (RF2) ou dois (RF3) CVM.

Talvez isso seja suficiente para entender o princípio do trabalho dentro da estrutura desta publicação; caso contrário, pegarei o pão dos treinadores da Cisco e ficarei com vergonha. Na verdade não, mas ainda o suficiente.

Pergunta sobre testes sintéticos

- Navegador, aparelhos!
36!
- O que é 36?
- E os eletrodomésticos?

Algo assim hoje parece com a maioria dos testes sintéticos de sistemas de armazenamento. Por que é que?

Até relativamente recentemente, a maioria dos sistemas de armazenamento era plana com acesso uniforme. O que isto significa?

O espaço total em disco disponível foi coletado de discos com as mesmas características. Por exemplo, 300 unidades de 15k. E o desempenho foi o mesmo em todo o espaço. Com o advento da tecnologia de armazenamento em camadas, os sistemas de armazenamento tornaram-se não estáveis - o desempenho varia em um único espaço em disco. E não é apenas diferente, mas também imprevisível, dependendo dos algoritmos e recursos de um modelo de armazenamento específico.

E tudo não seria tão interessante se os sistemas hiperconvergentes com localização de dados não aparecessem. Além da desigualdade do próprio espaço em disco (cansações, caches em flash), também há acesso desigual a ele - dependendo se uma das cópias de dados está localizada nos discos locais do nó ou se deve ser acessada pela rede. Tudo isso leva ao fato de que o número de testes sintéticos pode ser absolutamente qualquer, e não falar de nada praticamente significativo. Por exemplo, o consumo de combustível de um carro de acordo com uma brochura publicitária que você nunca pode alcançar na vida real.

Pergunta sobre dimensionamento

O outro lado dos números de teste sintéticos foi dimensionar números e especificações sob o teclado de pré-venda. Neste caso, as pré-vendas são divididas em duas categorias - algumas simplesmente estupidamente martelam seu TK no configurador do fornecedor, e o segundo é o próprio, porque eles entendem como ele funciona. Mas com o segundo você terá que considerar em detalhes o que escreveu no seu TK.

Como você sabe, sem um TK claro - o resultado do HZ.

Por experiência prática - ao dimensionar um sistema hiperconvergente bastante pesado em uma competição com um dos clientes, pessoalmente, depois do piloto, peguei os indicadores de carga do sistema e os comparei com o que estava escrito no TOR. Acabou como em uma piada:

- Rabinovich, é verdade que você ganhou um milhão na loteria?
- Quem te contou isso? Não um milhão, mas dez rublos, não na loteria, mas na preferência, e não ganhou, mas perdeu.

Em outras palavras, a situação clássica do GIGO - Garbage In Garbage Out - Entrada de lixo = Lixo na saída.

O dimensionamento prático aplicável para a hiperconvergência é quase garantido para ser de dois tipos: leve-nos com uma margem ou, por um longo tempo, dirigiremos um piloto e tomaremos indicadores.

Há mais um ponto no dimensionamento e avaliação das especificações. Sistemas diferentes são construídos de maneira diferente e funcionam de maneira diferente com discos; seus controladores interagem de maneira diferente. Portanto, é praticamente inútil comparar “frente a frente” de acordo com as especificações, o número e o volume de discos. Você tem algum tipo de TK, dentro do qual entende o nível de carga. E há um certo número de caixas de velocidades, nas quais você oferece vários sistemas que atendem aos requisitos de desempenho e confiabilidade. Qual é a diferença fundamental, quanto custa um disco e que tipo no sistema 1, e que no sistema 2 existem mais / menos deles se ambos lidarem com êxito com a tarefa.

Como o desempenho é geralmente determinado pelos controladores que vivem nos mesmos hosts que as máquinas virtuais, para alguns tipos de cargas, ele pode nadar significativamente, simplesmente porque processadores com frequências diferentes estão localizadas em diferentes clusters, sendo todas as outras coisas iguais.

Em outras palavras, mesmo o arquiteto-arquiteto de pré-venda mais experiente não informará a especificação com mais precisão do que você formula os requisitos e com mais precisão do que "bem, em algum lugar do SAM-VOSEM" sem projetos-piloto.

Sobre instantâneos

O HyperFlex pode fazer instantâneos nativos de máquinas virtuais usando a tecnologia Redirect-on-Write. E aqui é necessário parar separadamente para considerar diferentes tecnologias de instantâneos.
Inicialmente, havia instantâneos do tipo Copy-on-Write (CoW), e os instantâneos nativos do VMware vSphere podem ser tomados como um exemplo clássico. O princípio de operação é o mesmo com o vmdk sobre o VMFS ou o NFS, que com sistemas de arquivos nativos como o VSAN. Depois de criar um instantâneo CoW, os dados originais (blocos ou arquivos vmdk) são congelados e, quando você tenta gravar em blocos congelados, uma cópia é criada e os dados são gravados em um novo bloco / arquivo (arquivo delta para vmdk). Como resultado, à medida que a árvore de instantâneos cresce, o número de acessos "espúrios" ao disco que não possuem nenhum significado produtivo aumenta equedas / atrasos de desempenho aumentam .

Em seguida, foram inventados os instantâneos Redirect-on-Write (RoW), nos quais, em vez de criar cópias de blocos com dados, uma cópia dos metadados é criada e o registro continua sem atrasos, leituras e verificações adicionais. Com a implementação correta do RoW, os instantâneos têm efeito quase zero no desempenho do sistema de disco. O segundo efeito de trabalhar com metadados em vez dos dados ativos em si não é apenas a criação instantânea de instantâneos, mas também clones de VM, que imediatamente após a criação não ocupam espaço (não consideramos a sobrecarga do sistema para os arquivos de serviço da VM).

E o terceiro ponto principal que distingue radicalmente os instantâneos RoW de CoW para sistemas produtivos é a remoção instantânea do instantâneo. Parece que é assim? No entanto, você precisa se lembrar de como os snapshots da CoW funcionam e a remoção de um snapshot não é realmente uma remoção delta, mas sua confirmação. E aqui o tempo de sua confirmação é extremamente dependente do tamanho do delta acumulado e do desempenho do sistema de disco. Os instantâneos RoW são confirmados instantaneamente, simplesmente porque não importa quantos terabytes de diferença se acumulam, a exclusão (confirmação) de instantâneos RoW é uma atualização da tabela de metadados.

E aqui aparece uma aplicação interessante dos instantâneos RoW - reduza o RPO para valores de dezenas de minutos. Fazer backups a cada 30 minutos é quase impossível no caso geral e, na maioria dos casos, é feito uma vez por dia, o que fornece um RPO de 24 horas. Mas, ao mesmo tempo, podemos fazer instantâneos de RoW em uma programação, levando o RPO para 15 a 30 minutos e armazená-los por um dia ou dois. Não há penalidade no desempenho, gastando apenas capacidade.

Mas existem algumas nuances.

Para operação adequada de instantâneos nativos e integração com o VMware, o HyperFlex requer um instantâneo oficial chamado Sentinel. A captura instantânea do Sentinel é criada automaticamente quando você cria uma captura instantânea para uma determinada VM por meio do HXConnect e não deve excluí-la, não deve "voltar" para ela, basta confirmar que, na interface da lista de capturas instantâneas, esse é o primeiro instantâneo de serviço do Sentinel.

As capturas instantâneas do HyperFlex podem ser executadas no modo consistente com falha ou no modo consistente com o aplicativo. O segundo tipo envolve "liberar buffers" dentro da VM, requer VMTools e inicia se a caixa de seleção "Quiesce" estiver marcada no menu de instantâneo do HXConnect.
Além dos snapshots HyperFlex, ninguém proíbe o uso de snapshots VMware "nativos". Vale a pena para uma máquina virtual específica determinar quais instantâneos você usará e, no futuro, se concentrar nessa tecnologia, “não perturbando” diferentes instantâneos para uma VM.

Como parte do teste, tentei criar instantâneos e verificar sua FIO. E, no entanto, sim, posso confirmar que os instantâneos são realmente RoW, eles não afetam o desempenho. As capturas instantâneas são realmente criadas rapidamente (alguns segundos, dependendo do perfil de carregamento e do tamanho do conjunto de dados), posso dar a seguinte recomendação com base nos resultados: se a sua carga possui muitas operações de gravação aleatória, você deve começar a criar uma captura instantânea a partir da interface HXConnect, com a marca de verificação "Quiesce" e com uma prévia a presença de um instantâneo do Sentinel.

Testes

Plataforma de teste

A seguinte plataforma caiu em patas tenazes:

4 x C220 M4 (2630v4 10c x 2,20 GHz, 256, 800 + 6 * 960)
vSphere 6.7
HX Data Platform 4.0.2

Teste de correção clara

Que tipo de teste sem o CrystalDisk? É isso mesmo, não pode ser, caras normais sempre iniciam um disco cristalizado! Bem, se for necessário, então é necessário.

Para o disco de cristal, foi criada uma VM criada especialmente com 2 vCPU de 4 GB e Windows 7 a bordo. Ah, e eu cansei de colocar patches nele, eu vou te dizer! O teste foi realizado nas melhores tradições das melhores casas de Londres e Paris - ou seja, apenas um disco virtual foi adicionado sem pensar e o teste foi lançado. Sim, a propósito, é claro que o próprio CrystalDiskMark não está envolvido nos testes, é apenas uma interface, mas carrega diretamente o sistema de disco com o conhecido pacote DiskSpd incluído no kit.

O que me impressionou literalmente - por algum motivo, todos ignoraram a escolha de unidades no canto superior direito. E tudo mais!

Ouça, honestamente, eu não esperava 75 mil IOPS e mais de 1 gigabyte por segundo da micro-máquina no modo próximo ao próximo acabamento!

Para dizer o mínimo, nem toda empresa na Rússia possui cargas que excedem esses indicadores no total.

Testes adicionais foram realizados usando o VMware HCI Bench e o Nutanix XRay, como “ideologicamente hostis” ao HyperFlex e, portanto, era esperado que não fôssemos presos. Como os números se mostraram extremamente próximos, os resultados do pacote XRay foram tomados como base simplesmente porque ele possui um sistema de relatórios mais conveniente e modelos de carregamento prontos.

Para quem não confia em ninguém e deseja controle total sobre o processo, lembro-lhe do meu artigo sobre como criar seu próprio sistema para gerar a carga em uma plataforma hiperconvergente - "Sistemas de teste de desempenho giperkonvergentnyh e SDS com as próprias mãos "

Achtung! Uwaga! Pozor!

Todos os outros resultados e suas interpretações são da opinião do autor do artigo e são apresentados por eles mesmos no âmbito do estudo do sistema. A maioria dos testes é sintética simples e é aplicável apenas para entender os indicadores de limite em casos extremos e degenerados, que você nunca alcançará na vida real.

Microbenchmark FourCorners

O microteste de quatro lados foi projetado para avaliar o sistema "rapidamente" para obter o máximo desempenho teórico e máximo de desempenho dos controladores. A aplicação prática para esse teste é verificar o sistema imediatamente após o lançamento quanto a erros de configuração e ambiente, especialmente erros de rede. Essa. se você executa esses sistemas regularmente, sabe apenas quais números deve esperar "se tudo estiver bem".

Números finais: IOPS de 280k / 174k, 3,77 / 1,72 GBps (leitura / gravação)

Como se comportaram nossos controladores?

A partir do qual se pode observar que o consumo total de recursos para 4 controladores e 4 cargas de VM foi de 49 núcleos de 2,2. De acordo com as estatísticas da VMware, a utilização da CPU dos controladores era de até 80%, ou seja, de fato, o desempenho foi limitado pelo desempenho dos controladores e, especificamente, dos processadores. A velocidade das operações seqüenciais descansava especificamente contra a velocidade da rede 10G.

Vamos tentar de novo. O desempenho máximo em um pequeno cluster de 4 nós com os processadores de 2,2 GHz mais rápidos é de quase 300 mil IOPS em alturas de 4U.

A conversa "aqui temos 10, 20 ou até 40% a mais / menos" é praticamente sem sentido devido à ordem dos números. O mesmo que começar a medir "e eu posso ter um carro 240, tenho 280", apesar do limite ser 80.

Os nós de 280k / 4 oferecem um desempenho máximo de 70k / nó, que por exemplo excede os números da calculadora VMware VSAN, que pressupõe que o nó AF emita não mais que 46k por grupo de discos. No nosso caso, aqui na terminologia do VMware, há apenas um grupo de discos, que é executado na x1.8.

Efeito do tamanho do bloco do armazenamento de dados

Ao criar um armazenamento de dados HyperFlex, você pode escolher o tamanho do bloco de dados - 4k ou 8k.

O que isso afetará? Execute o mesmo teste quadrangular.

Se a imagem é quase idêntica à leitura, o registro é contrário. O teste quadrangular utiliza uma carga de 8k.

Números totais: 280k / 280k, 172-158k / 200-180k (4k 8k). Quando o tamanho do bloco corresponde, é obtido + 15% do desempenho da gravação. Se você espera uma quantidade significativa de gravação com um pequeno bloco (4k) na carga - crie um armazenamento de dados para essa carga específica com um bloco de 4k, caso contrário, use 8k.

Simulador OLTP

Um quadro muito mais próximo da realidade é dado por outro teste. Como parte disso, dois geradores são lançados com um perfil próximo a um DBMS transacional e um nível de carga de 6000 + 400 IOPS. Aqui, o atraso é medido, o que deve permanecer em um nível baixo estável.

O atraso para o carregamento da VM foi de 1,07 / 1,08 ms. Em suma, um ótimo resultado, mas vamos adicionar um pouco de calor!

Colocação do Banco de Dados: Alta Intensidade

Como a base transacional se comportará, dependendo dos atrasos, se de repente um vizinho consecutivo barulhento for formado. Bem, muito barulhento.

Portanto, a base OLTP no nó 1 gera 4200 IOPS com atraso de 0,85 ms. O que acontece depois que um sistema DSS repentinamente começa a consumir recursos em operações seqüenciais?
Dois geradores nos nós 2 e 3 carregam a plataforma em 1,18 / 1,08 GBps, respectivamente, esses 2,26 GBps no total. É claro que o atraso no OLTP aumenta e se torna menos estável, mas o valor médio permanece 1,85ms, e a base recebe seus 4200 IOPS sem problemas.

Impacto da captura instantânea

O sistema sequencialmente tira vários instantâneos uma vez por hora em uma base OLTP. Não há nada de surpreendente no cronograma e, além disso, geralmente é um indicador de como os instantâneos clássicos do VMware funcionam, pois o Nutanix XRay não sabe como trabalhar com os instantâneos nativos, exceto os seus. Você não precisa usar os instantâneos do vSphere regularmente, porque nem todos os iogurtes são igualmente úteis.

Os snapshots nativos do HyperFlex funcionam muito melhor, use-os e seu cabelo ficará macio e sedoso!

Ingestão de Big Data

Como o HyperFlex digerirá uma grande quantidade de dados carregados sequencialmente? Bem, digamos 1 TB.

O teste levou 27 minutos, incluindo clonagem, ajuste e partida dos geradores.

Escalabilidade de taxa de transferência

Agora, carregue gradualmente todo o cluster e observe os números constantes. Para começar com a leitura aleatória e depois a escrita.

Estamos vendo uma imagem estável com uma diminuição gradual no desempenho da carga da máquina de 78k para 55-57k IOPS, com prateleiras suaves. Ao mesmo tempo, há um aumento constante no desempenho geral de 78 para 220k IOPS.

A gravação é um pouco menos suave, mas ainda estáveis nas prateleiras de 64k a 19-21k por carro. Ao mesmo tempo, a carga nos controladores é muito menor. Se durante a leitura o nível de carga total do processador aumentou de 44 para 109, em seguida, na gravação de 57 para 73 GHz.

Aqui você pode observar o exemplo mais simples e óbvio dos recursos dos sistemas hiperconvergentes - o único consumidor simplesmente não é capaz de utilizar completamente todos os recursos do sistema e, quando a carga é adicionada, não há queda significativa no desempenho. A queda que estamos testemunhando já é o resultado de cargas sintéticas extremas projetadas para comprimir tudo até a última gota, o que quase nunca ocorre em um produto normal.

Quebrando OLTP

A essa altura, tornou-se ainda chato o quão previsível o HyperFlex era. Necessidade urgente de quebrar alguma coisa!

O ponto vermelho marca o momento em que a VM do controlador é encerrada em um dos hosts com uma carga.

Como, por padrão, a reconstrução no HyperFlex inicia imediatamente apenas quando o disco é perdido e, quando o nó é perdido, o tempo limite é de 2 horas, o momento da reconstrução forçada é marcado com um ponto verde.

login as: admin
 HyperFlex StorageController 4.0(2a)
admin@192.168.***.***'s password:
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
    percentComplete: 0
    rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance start -f
msgstr: Successfully started rebalance
params:
msgid: Successfully started rebalance
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
    percentComplete: 16
    rebalanceState: cluster_rebalance_ongoing
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b>

As operações congelaram por alguns segundos e continuaram novamente, quase percebendo a reconstrução. Ele está em um estado estável quando está longe da sobrecarga do cluster.

Por que 2 horas Cisco não é um problema, embora os concorrentes tenham menos números? A Cisco recomenda enfaticamente o uso do RF3 como um nível básico de proteção de dados para tudo, exceto máquinas que não são uma pena. Você decidiu instalar patches ou fazer algo com o host, desligue-o. E existe a chance de que nesse momento outro host falhe - e, no caso da RF2, tudo se tornará uma aposta, e com a RF3 haverá uma cópia ativa dos dados. E sim, é realmente possível sobreviver duas horas em um acidente na RF2 até que a recuperação da RF3 comece.

Me quebre completamente!

Quebrando - tão quebrando. Carga máxima. Nesse caso, criei um teste com um perfil mais ou menos semelhante a uma carga real (70% lida, 20% aleatória, 8k, 6d 128q).

Adivinhe onde a CVM foi desativada e onde começou a reconstrução?

Na situação com a reconstrução, o HyperFlex teve um bom desempenho, sem causar uma queda catastrófica no desempenho ou um aumento múltiplo nos atrasos, mesmo sob carga sob os tomates. A única coisa que eu realmente gostaria é da querida Cisco, fazer o tempo limite ser igual a menos de 2 horas por padrão.

achados

Para concluir, recordo o objetivo do teste: investigar o sistema Cisco HyperFlex hoje, sem olhar para o histórico, investigar seu desempenho usando sintéticos e tirar conclusões sobre sua aplicabilidade a um produto real.

Conclusão 1 , sobre desempenho. O desempenho é muito bom e você não comenta aqui. Como eu tinha um sistema da geração anterior em teste, posso dizer exatamente uma coisa: no HyperFlex All Flash, você terá capacidade, processador e memória, mas não discos. Exceto, talvez, 1% dos aplicativos sobrecarregados, mas é necessário conversar pessoalmente com eles. Os instantâneos de RoW nativos funcionam.

Conclusão 2, por disponibilidade. O sistema após a detecção de uma falha é bastante bom (sem uma queda de desempenho às vezes) realiza a restauração do número de cópias de dados. Há uma pequena reclamação no tempo limite padrão de duas horas antes de iniciar a recuperação (se o host for perdido), mas, considerando o RF3 altamente recomendado, isso é mais exigente. A recuperação após uma falha no disco começa imediatamente.

Conclusão 3, em preço e comparação com concorrentes. O preço do sistema pode variar muitas vezes, dependendo da configuração de um projeto específico. Uma grande parte do custo do projeto será um sistema licenciado e software de aplicativo, que funcionará na parte superior da plataforma de infraestrutura. Portanto, a única maneira de comparar com os concorrentes é comparar ofertas comerciais específicas que atendem aos requisitos técnicos, especificamente para sua empresa para um projeto específico.

Conclusão final : o sistema está funcionando, bastante maduro para uso no produto em abril de 2020, se as recomendações do fornecedor forem lidas e aplicadas, em vez de fumar.

Por que hiperconvergência? Visão geral e testes do Cisco HyperFlex