Este é um mito bastante comum na área de hardware de servidor. Na prática, soluções hiperconvergentes (quando tudo está em um só) são necessárias para muitas coisas. Historicamente, as primeiras arquiteturas foram desenvolvidas pela Amazon e pelo Google para seus serviços. Então a ideia era fazer um farm de computação a partir de nós idênticos, cada um com seus próprios discos. Tudo isso foi unido por algum software formador de sistema (hipervisor) e dividido em máquinas virtuais. O objetivo principal é um mínimo de esforço para atender um nó e um mínimo de problemas durante o dimensionamento: basta comprar mais mil ou dois servidores iguais e conectá-los próximos. Na prática, estes são casos isolados, e muito mais frequentemente estamos falando de um número menor de nós e de uma arquitetura um pouco diferente.
Mas a vantagem permanece a mesma: incrível facilidade de dimensionamento e gerenciamento. A desvantagem é que diferentes tarefas consomem recursos de forma diferente, e em alguns locais haverá muitos discos locais, em outros haverá pouca RAM e assim por diante, ou seja, para diferentes tipos de tarefas a utilização de recursos diminuirá.
Acontece que você paga de 10 a 15% a mais pela facilidade de configuração. Foi isso que gerou o mito do título. Passámos muito tempo à procura de onde a tecnologia seria aplicada de forma otimizada e encontrámo-la. O fato é que a Cisco não possuía sistemas de armazenamento próprios, mas queria um mercado de servidores completo. E eles criaram o Cisco Hyperflex - uma solução com armazenamento local em nós.
E isso de repente se tornou uma solução muito boa para data centers de backup (Recuperação de Desastres). Eu vou te dizer por que e como agora. E vou mostrar os testes de cluster.
Onde necessário
Hiperconvergência é:
- Transferindo discos para nós de computação.
- Integração total do subsistema de armazenamento com o subsistema de virtualização.
- Transferência/integração com o subsistema de rede.
Essa combinação permite implementar muitos recursos do sistema de armazenamento no nível de virtualização e tudo em uma janela de controle.
Em nossa empresa, projetos para projetar data centers redundantes são muito procurados, e uma solução hiperconvergente é frequentemente escolhida devido a uma série de opções de replicação (até um metrocluster) prontas para uso.
No caso de data centers de backup, geralmente estamos falando de uma instalação remota em um local do outro lado da cidade ou em outra cidade. Ele permite restaurar sistemas críticos em caso de falha parcial ou total do data center principal. Os dados de vendas são constantemente replicados lá, e essa replicação pode ser no nível do aplicativo ou no nível do dispositivo de bloco (armazenamento).
Portanto, agora falarei sobre o design e os testes do sistema e, em seguida, sobre alguns cenários de aplicação da vida real com dados de economia.
Testes
Nossa instância consiste em quatro servidores, cada um com 10 unidades SSD de 960 GB. Há um disco dedicado para armazenar em cache as operações de gravação e armazenar a máquina virtual de serviço. A solução em si é a quarta versão. O primeiro é francamente grosseiro (a julgar pelos comentários), o segundo é úmido, o terceiro já é bastante estável, e este pode ser chamado de lançamento após o término dos testes beta para o público em geral. Durante os testes não vi nenhum problema, tudo funciona como um relógio.
Mudanças na v4Vários bugs foram corrigidos.
Inicialmente, a plataforma só funcionava com o hipervisor VMware ESXi e suportava um pequeno número de nós. Além disso, o processo de implantação nem sempre terminava com êxito, algumas etapas precisavam ser reiniciadas, havia problemas com a atualização de versões mais antigas, os dados na GUI nem sempre eram exibidos corretamente (embora ainda não esteja satisfeito com a exibição dos gráficos de desempenho ), às vezes surgiam problemas na interface com a virtualização.
Agora que todos os problemas infantis foram corrigidos, o HyperFlex pode lidar com ESXi e Hyper-V, além de ser possível:
- Criando um cluster estendido.
- Criando um cluster para escritórios sem usar Fabric Interconnect, de dois a quatro nós (compramos apenas servidores).
- Capacidade de trabalhar com sistemas de armazenamento externos.
- Suporte para contêineres e Kubernetes.
- Criação de zonas de disponibilidade.
- Integração com VMware SRM se a funcionalidade integrada não for satisfatória.
A arquitetura não difere muito das soluções dos seus principais concorrentes: não foram eles que criaram a bicicleta. Tudo funciona na plataforma de virtualização VMware ou Hyper-V. O hardware está hospedado em servidores Cisco UCS proprietários. Há quem odeie a plataforma pela relativa complexidade da configuração inicial, muitos botões, um sistema nada trivial de templates e dependências, mas também há quem aprendeu Zen, se inspira na ideia e não quer mais para trabalhar com outros servidores.
Consideraremos a solução para VMware, já que a solução foi originalmente criada para ele e possui mais funcionalidades; o Hyper-V foi adicionado ao longo do caminho para acompanhar os concorrentes e atender às expectativas do mercado.
Existe um cluster de servidores cheio de discos. Existem discos para armazenamento de dados (SSD ou HDD - de acordo com seu gosto e necessidade), existe um disco SSD para cache. Ao gravar dados no armazenamento de dados, os dados são salvos na camada de cache (disco SSD dedicado e RAM da VM de serviço). Paralelamente, um bloco de dados é enviado aos nós do cluster (o número de nós depende do fator de replicação do cluster). Após a confirmação de todos os nós sobre o sucesso da gravação, a confirmação da gravação é enviada ao hipervisor e depois à VM. Os dados gravados são desduplicados, compactados e gravados em discos de armazenamento em segundo plano. Ao mesmo tempo, um bloco grande é sempre gravado nos discos de armazenamento e sequencialmente, o que reduz a carga nos discos de armazenamento.
A desduplicação e a compactação estão sempre habilitadas e não podem ser desabilitadas. Os dados são lidos diretamente dos discos de armazenamento ou do cache RAM. Se uma configuração híbrida for usada, as leituras também serão armazenadas em cache no SSD.
Os dados não estão vinculados à localização atual da máquina virtual e são distribuídos uniformemente entre os nós. Essa abordagem permite carregar todos os discos e interfaces de rede igualmente. Há uma desvantagem óbvia: não podemos reduzir ao máximo a latência de leitura, pois não há garantia de disponibilidade de dados localmente. Mas acredito que este seja um sacrifício menor comparado aos benefícios recebidos. Além disso, os atrasos na rede atingiram valores tais que praticamente não afetam o resultado geral.
Um controlador de serviço especial VM Cisco HyperFlex Data Platform, criado em cada nó de armazenamento, é responsável por toda a lógica de operação do subsistema de disco. Em nossa configuração de VM de serviço foram alocadas oito vCPUs e 72 GB de RAM, o que não é tão pouco. Deixe-me lembrá-lo de que o próprio host possui 28 núcleos físicos e 512 GB de RAM.
A VM de serviço tem acesso direto aos discos físicos, encaminhando o controlador SAS para a VM. A comunicação com o hipervisor ocorre através de um módulo especial IOVisor, que intercepta operações de I/O, e por meio de um agente que permite enviar comandos para a API do hipervisor. O agente é responsável por trabalhar com snapshots e clones do HyperFlex.
Os recursos de disco são montados no hipervisor como compartilhamentos NFS ou SMB (dependendo do tipo de hipervisor, adivinhe qual está onde). E nos bastidores, este é um sistema de arquivos distribuído que permite adicionar recursos de sistemas de armazenamento completos para adultos: alocação de volume fino, compactação e desduplicação, instantâneos usando a tecnologia Redirect-on-Write, replicação síncrona/assíncrona.
A VM de serviço fornece acesso à interface de gerenciamento WEB do subsistema HyperFlex. Há integração com o vCenter, e a maioria das tarefas diárias pode ser executada a partir dele, mas os datastores, por exemplo, são mais convenientes para cortar de uma webcam separada se você já mudou para uma interface HTML5 rápida ou usa um cliente Flash completo com integração total. Na webcam de serviço você pode visualizar o desempenho e o status detalhado do sistema.
Existe outro tipo de nó em um cluster - nós de computação. Podem ser servidores rack ou blade sem discos integrados. Esses servidores podem executar VMs cujos dados são armazenados em servidores com discos. Do ponto de vista do acesso aos dados, não há diferença entre os tipos de nós, pois a arquitetura envolve abstração da localização física dos dados. A proporção máxima de nós de computação para nós de armazenamento é de 2:1.
O uso de nós de computação aumenta a flexibilidade ao dimensionar recursos de cluster: não precisamos comprar nós adicionais com discos se precisarmos apenas de CPU/RAM. Além disso, podemos adicionar uma gaiola de blade e economizar na colocação de servidores em rack.
Como resultado, temos uma plataforma hiperconvergente com as seguintes funcionalidades:
- Até 64 nós em um cluster (até 32 nós de armazenamento).
- O número mínimo de nós em um cluster é três (dois para um cluster Edge).
- Mecanismo de redundância de dados: espelhamento com fator de replicação 2 e 3.
- Aglomerado metropolitano.
- Replicação assíncrona de VM para outro cluster HyperFlex.
- Orquestração de comutação de VMs para um data center remoto.
- Snapshots nativos usando tecnologia Redirect-on-Write.
- Até 1 PB de espaço utilizável com fator de replicação 3 e sem desduplicação. Não levamos em consideração o fator de replicação 2, pois esta não é uma opção para vendas sérias.
Outra grande vantagem é a facilidade de gerenciamento e implantação. Todas as complexidades de configuração de servidores UCS são atendidas por uma VM especializada preparada por engenheiros da Cisco.
Configuração da bancada de testes:
- 2 x Cisco UCS Fabric Interconnect 6248UP como cluster de gerenciamento e componentes de rede (48 portas operando no modo Ethernet 10G/FC 16G).
- Quatro servidores Cisco UCS HXAF240 M4.
Características do servidor:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/classificação dupla/x4/1.2v
Network
UCSC-MLOM-CSC-02 (VIC 1227). 2 portas Ethernet 10G
HBA de armazenamento
Controlador de passagem SAS modular Cisco 12G
Discos de armazenamento
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Mais opções de configuraçãoAlém do hardware selecionado, as seguintes opções estão disponíveis atualmente:
- HXAF240c M5.
- Uma ou duas CPUs variando de Intel Silver 4110 a Intel Platinum I8260Y. Segunda geração disponível.
- 24 slots de memória, faixas de 16 GB RDIMM 2600 a 128 GB LRDIMM 2933.
- De 6 a 23 discos de dados, um disco de cache, um disco de sistema e um disco de inicialização.
Unidades de capacidade
- HX-SD960G61X-EV 960 GB 2.5 polegadas Enterprise Value 6G SATA SSD (resistência 1X) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 polegadas Enterprise Value 6G SATA SSD (1X resistência) SAS 3.8 TB.
- Cache de unidades
- HX-NVMEXPB-I375 Unidade Intel Optane de 375 GB e 2.5 polegadas, desempenho e resistência extremos.
- HX-NVMEHW-H1600* 1.6 TB 2.5 polegadas Ent. Desempenho. SSD NVMe (resistência 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 polegadas Ent. Desempenho. SSD 12G SAS (resistência 10X) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 polegadas Ent. Desempenho. SSD 12G SAS SED (resistência 10X) SAS 800 GB.
- HX-SD16T123X-EP SSD 1.6G SAS de 2.5 TB e 12 polegadas com desempenho empresarial (resistência 3X).
Unidades de sistema/log
- HX-SD240GM1X-EV SSD SATA 240G Enterprise Value de 2.5 GB e 6 polegadas (requer atualização).
Unidades de Inicialização
- HX-M2-240GB SSD SATA M.240 de 2 GB SATA 240 GB.
Conecte-se à rede por meio de portas Ethernet 40G, 25G ou 10G.
O FI pode ser HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
O teste em si
Para testar o subsistema de disco, usei o HCIBench 2.2.1. Este é um utilitário gratuito que permite automatizar a criação de uma carga a partir de várias máquinas virtuais. A carga em si é gerada pelo fio usual.
Nosso cluster consiste em quatro nós, fator de replicação 3, todos os discos são Flash.
Para testes, criei quatro datastores e oito máquinas virtuais. Para testes de gravação, presume-se que o disco de cache não esteja cheio.
Os resultados do teste são os seguintes:
100% lido 100% aleatório
0% lido 100% aleatório
Profundidade do bloco/fila
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59ms 213804 IOPS
0,84ms 303540 IOPS
1,36ms 374348 IOPS
2.47ms 414116 IOPS
4,86ms 420180 IOPS
2,22ms 57408 IOPS
3,09ms 82744 IOPS
5,02ms 101824 IPOS
8,75ms 116912 IOPS
17,2ms 118592 IOPS
8K
0,67ms 188416 IOPS
0,93ms 273280 IOPS
1,7ms 299932 IOPS
2,72ms 376,484 IOPS
5,47ms 373,176 IOPS
3,1ms 41148 IOPS
4,7ms 54396 IOPS
7,09ms 72192 IOPS
12,77ms 80132 IOPS
16K
0,77ms 164116 IOPS
1,12ms 228328 IOPS
1,9ms 268140 IOPS
3,96ms 258480 IOPS
3,8ms 33640 IOPS
6,97ms 36696 IOPS
11,35ms 45060 IOPS
32K
1,07ms 119292 IOPS
1,79ms 142888 IOPS
3,56ms 143760 IOPS
7,17ms 17810 IOPS
11,96ms 21396 IOPS
64K
1,84ms 69440 IOPS
3,6ms 71008 IOPS
7,26ms 70404 IOPS
11,37ms 11248 IOPS
Negrito indica valores após os quais não há aumento de produtividade, às vezes até degradação é visível. Isso se deve ao fato de estarmos limitados pelo desempenho da rede/controladores/discos.
- Leitura sequencial 4432 MB/s.
- Gravação sequencial 804 MB/s.
- Se um controlador falhar (falha de uma máquina virtual ou host), a queda no desempenho será dupla.
- Se o disco de armazenamento falhar, o rebaixamento será de 1/3. A reconstrução do disco consome 5% dos recursos de cada controlador.
Em um bloco pequeno, ficamos limitados pelo desempenho do controlador (máquina virtual), sua CPU está carregada em 100%, e quando o bloco aumenta, ficamos limitados pela largura de banda da porta. 10 Gbps não são suficientes para desbloquear o potencial do sistema AllFlash. Infelizmente, os parâmetros do suporte de demonstração fornecido não nos permitem testar a operação a 40 Gbit/s.
Na minha impressão dos testes e do estudo da arquitetura, devido ao algoritmo que coloca os dados entre todos os hosts, obtemos um desempenho escalável e previsível, mas isso também é uma limitação na leitura, pois seria possível extrair mais dos discos locais, aqui pode economizar uma rede mais produtiva, por exemplo, FI a 40 Gbit/s está disponível.
Além disso, um disco para armazenamento em cache e desduplicação pode ser uma limitação; na verdade, neste ambiente de teste podemos gravar em quatro discos SSD. Seria ótimo poder aumentar o número de unidades de cache e ver a diferença.
Uso real
Para organizar um data center de backup, você pode usar duas abordagens (não consideramos colocar um backup em um site remoto):
- Passivo ativo. Todos os aplicativos estão hospedados no data center principal. A replicação é síncrona ou assíncrona. Se o data center principal falhar, precisamos ativar o de backup. Isso pode ser feito manualmente/scripts/aplicativos de orquestração. Aqui obteremos um RPO proporcional à frequência de replicação, e o RTO depende da reação e das habilidades do administrador e da qualidade do desenvolvimento/depuração do plano de comutação.
- Ativo-Ativo. Neste caso, há apenas replicação síncrona; a disponibilidade dos data centers é determinada por um quórum/árbitro localizado estritamente no terceiro site. RPO = 0, e o RTO pode chegar a 0 (se a aplicação permitir) ou igual ao tempo de failover de um nó em um cluster de virtualização. No nível de virtualização, é criado um cluster estendido (Metro) que requer armazenamento Ativo-Ativo.
Normalmente vemos que os clientes já implementaram uma arquitetura com um sistema de armazenamento clássico no data center principal, então projetamos outra para replicação. Como mencionei, o Cisco HyperFlex oferece replicação assíncrona e criação de cluster de virtualização ampliada. Ao mesmo tempo, não precisamos de um sistema de armazenamento dedicado de nível médio e superior, com funções de replicação caras e acesso de dados ativo-ativo em dois sistemas de armazenamento.
Script 1: Temos data centers primários e de backup, uma plataforma de virtualização em VMware vSphere. Todos os sistemas produtivos estão localizados no data center principal, e a replicação das máquinas virtuais é realizada no nível do hipervisor, o que evitará manter as VMs ligadas no data center de backup. Replicamos bancos de dados e aplicativos especiais usando ferramentas integradas e mantemos as VMs ligadas. Se o data center principal falhar, lançamos sistemas no data center de backup. Acreditamos que temos cerca de 100 máquinas virtuais. Enquanto o data center primário estiver operacional, o data center em espera poderá executar ambientes de teste e outros sistemas que poderão ser desligados se o data center primário for alternado. Também é possível que usemos replicação bidirecional. Do ponto de vista do hardware, nada mudará.
No caso da arquitetura clássica, instalaremos em cada data center um sistema de armazenamento híbrido com acesso via FibreChannel, hierarquização, desduplicação e compressão (mas não online), 8 servidores para cada site, 2 switches FibreChannel e Ethernet 10G. Para replicação e gerenciamento de switching em uma arquitetura clássica, podemos usar ferramentas VMware (Replicação + SRM) ou ferramentas de terceiros, que serão um pouco mais baratas e às vezes mais convenientes.
A figura mostra o diagrama.
Ao usar o Cisco HyperFlex, é obtida a seguinte arquitetura:
Para o HyperFlex, usei servidores com grandes recursos de CPU/RAM, porque... Parte dos recursos irão para a VM controladora HyperFlex, em termos de CPU e memória, até reconfigurei um pouco a configuração do HyperFlex para não brincar com a Cisco e garantir recursos para as VMs restantes. Mas podemos abandonar os switches FibreChannel e não precisaremos de portas Ethernet para cada servidor; o tráfego local é comutado dentro da FI.
O resultado foi a seguinte configuração para cada data center:
Servidores
Servidor 8 x 1U (384 GB de RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB de RAM, 2 x Intel Gold 6150, SSD de 3,2 GB, 10 x 6 TB NL-SAS)
Armazenar
Sistema de armazenamento híbrido com FC Front-End (SSD de 20 TB, NL-SAS de 130 TB)
-
LAN
2 x switch Ethernet 10G 12 portas
-
SAN
2 x switch FC 32/16 Gb 24 portas
2xCisco UCS FI 6332
Licenças
VMware Ent Plus
Replicação e/ou orquestração de comutação de VM
VMware Ent Plus
Não forneci licenças de software de replicação para o Hyperflex, pois elas estão disponíveis imediatamente para nós.
Para a arquitetura clássica, escolhi um fornecedor que se estabeleceu como um fabricante barato e de alta qualidade. Para ambas as opções, apliquei o desconto padrão para uma solução específica e, como resultado, recebi preços reais.
A solução Cisco HyperFlex acabou sendo 13% mais barata.
Script 2: criação de dois data centers ativos. Neste cenário, estamos projetando um cluster estendido no VMware.
A arquitetura clássica consiste em servidores de virtualização, uma SAN (protocolo FC) e dois sistemas de armazenamento que podem ler e gravar no volume esticado entre eles. Em cada sistema de armazenamento colocamos uma capacidade útil de armazenamento.
No HyperFlex simplesmente criamos um Stretch Cluster com o mesmo número de nós em ambos os sites. Neste caso, um fator de replicação de 2+2 é usado.
O resultado é a seguinte configuração:
arquitetura clássica
HiperFlex
Servidores
Servidor 16 x 1U (384 GB de RAM, 2 x Intel Gold 6132, FC HBA, 2 x NIC 10G)
16 x HX240C-M5L (512 GB de RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
Armazenar
2 x sistemas de armazenamento AllFlash (SSD de 150 TB)
-
LAN
4 x switch Ethernet 10G 24 portas
-
SAN
4 x switch FC 32/16 Gb 24 portas
4xCisco UCS FI 6332
Licenças
VMware Ent Plus
VMware Ent Plus
Em todos os cálculos não levei em consideração infraestrutura de rede, custos de data center, etc.: serão iguais para a arquitetura clássica e para a solução HyperFlex.
Em termos de custo, o HyperFlex acabou sendo 5% mais caro. Vale ressaltar aqui que em termos de recursos de CPU/RAM tive um desvio para Cisco, pois na configuração preenchi os canais do controlador de memória de maneira uniforme. O custo é ligeiramente superior, mas não numa ordem de grandeza, o que indica claramente que a hiperconvergência não é necessariamente um “brinquedo para os ricos”, mas pode competir com a abordagem padrão para a construção de um centro de dados. Isso também pode ser do interesse de quem já possui servidores Cisco UCS e a infraestrutura correspondente para eles.
Entre as vantagens, temos a ausência de custos de administração de SAN e sistemas de armazenamento, compactação e desduplicação online, ponto de entrada único para suporte (virtualização, servidores, também são sistemas de armazenamento), economia de espaço (mas não em todos os cenários), simplificando a operação.
Quanto ao suporte, aqui você obtém de um fornecedor - Cisco. A julgar pela minha experiência com servidores Cisco UCS, gostei; não precisei abri-lo no HyperFlex, tudo funcionou igual. Os engenheiros respondem prontamente e podem resolver não apenas problemas típicos, mas também casos extremos complexos. Às vezes recorro a eles com perguntas: “É possível fazer isso, dane-se?” ou “Configurei algo aqui e não quer funcionar. Ajuda!" - encontrarão pacientemente ali o guia necessário e apontarão as ações corretas; não responderão: “Só resolvemos problemas de hardware”.
referências
- Meu e-mail - [email protegido]
Fonte: habr.com