A escalabilidade não se refere apenas ao número de nós que podem formar um cluster ou à capacidade máxima de armazenamento. Os aspectos mais importantes da escalabilidade são como um ambiente se expande de várias perspectivas, incluindo gerenciamento, desempenho, capacidade, resiliência e como a escala afeta os aspectos operacionais.
Vamos começar com a escalabilidade dos componentes necessários para gerenciar / administrar o AHV:
Escalabilidade de gerenciamento
O AHV dimensiona automaticamente todos os componentes de gerenciamento durante a implantação do cluster inicial ou ao adicionar nó (s) ao cluster. Isso significa que não há necessidade de fazer o dimensionamento inicial ou o dimensionamento manual dos componentes de gerenciamento do XCP, independentemente do tamanho inicial e final dos clusters.
Onde o fator de resiliência 3 (N + 2) estiver configurado, os componentes de gerenciamento da Acropolis serão dimensionados automaticamente para atender aos requisitos de N + 2. Vamos ser sinceros, não faz sentido ter N + 2 em uma camada e não em outra porque a disponibilidade, como uma Cadeia, é tão boa quanto seu elo mais fraco.
Escala de capacidade de armazenamento
O DSF (Nutanix Distributed Storage Fabric) não possui capacidade máxima de armazenamento; além disso, a capacidade de armazenamento pode ser dimensionada separadamente para computar com nós "somente armazenamento", como o NX-6035C. Somente nós de armazenamento da Nutanix ajudam a eliminar os problemas ao dimensionar a capacidade em comparação com o armazenamento tradicional.
Dimensionar nós apenas de armazenamento executam AHV (que são interoperáveis com outros hipervisores suportados), permitindo que os clientes escalem a capacidade independentemente do Hypervisor. Nós apenas de armazenamento não exigem licenciamento de hipervisor ou gerenciamento separado. Os nós apenas de armazenamento também suportam totalmente todas as atualizações com um clique do Acropolis Base Software e do AHV, assim como os nós de computação + armazenamento. Como resultado, apenas os nós de armazenamento são invisíveis, além do aumento da capacidade e desempenho que os nós oferecem.
Os nós do armazenamento Nutanix apenas ajudam a eliminar os problemas ao dimensionar a capacidade em comparação com o armazenamento tradicional.
Alguns dos problemas de dimensionamento do armazenamento tradicional são adicionar prateleiras de unidades e não dimensionar serviços / gerenciamento de dados. Isso leva a problemas como IOPS / GB mais baixo e maior impacto nas cargas de trabalho no caso de falhas de componentes, como controladores de armazenamento.
Escalar apenas os nós de armazenamento é notavelmente simples. À medida que cada nó apenas de armazenamento é adicionado ao cluster, um Nutanix CVM leve se junta ao cluster para fornecer serviços de dados para garantir recursos de gerenciamento e desempenho de dimensionamento linear, evitando os problemas de dimensionamento que afetam o armazenamento tradicional.
Escalabilidade de computação
A ativação da HA dentro de um cluster requer a reserva de um ou mais nós para HA. Isso pode criar ineficiências desnecessárias quando o hypervisor limita o tamanho máximo do cluster. O AHV não apenas não tem limite para o número de nós em um cluster. Como resultado, o AHV pode ajudar a evitar silos desnecessários que podem levar ao uso ineficiente da infraestrutura devido à exigência de que um ou mais nós por cluster sejam reservados para HA. Nós AHV também são configurados automaticamente com todas as configurações necessárias ao ingressar em um cluster existente. Tudo o que o administrador precisa fornecer é informações básicas sobre o endereço IP, pressione o botão Expandir cluster e o Acropolis cuida do resto.
Veja a demonstração abaixo mostrando como expandir um cluster do Nutanix:
Escalabilidade do Analytics
O AHV inclui o Analytics interno e, assim como os outros componentes do Acropolis Management, os componentes do Analysis são dimensionados automaticamente durante a implantação inicial e dimensionados automaticamente à medida que os nós são adicionados.
Isso significa que nunca há um ponto de inflexão em que é necessário que um administrador dimensione ou implante novas instâncias ou componentes do Analysis. A funcionalidade de análise e seu desempenho permanecem lineares, independentemente da escala.
Isso significa que o AHV elimina o requisito de instâncias de software e bancos de dados separados para fornecer análises.
Escalabilidade de resiliência
Como o Acropolis usa o Fabric de armazenamento distribuído da Nutanix, no caso de falha da unidade (s) ou do (s) nó (s), todos os nós do cluster participam na restauração do fator de resiliência (RF) configurado para os dados impactados. Isso ocorre independentemente do Hypervisor, no entanto, o AHV inclui componentes de gerenciamento totalmente distribuídos; quanto maior o cluster, mais resiliente a camada de gerenciamento também se torna.
Por exemplo, a perda de um único nó em um cluster de 4 nós teria um impacto potencial de 25% no desempenho dos componentes de gerenciamento. Em um cluster de 32 nós, uma falha de nó único teria um impacto potencial muito menor de apenas 3,125%. À medida que o ambiente de um AHV aumenta, o impacto de uma falha diminui e a capacidade de recuperação automática aumenta a velocidade de recuperação e o número de falhas subsequentes que podem ser suportadas.
Escalabilidade de desempenho
Independentemente do hipervisor, à medida que os clusters XCP crescem, o desempenho melhora. No momento em que novos nós são adicionados ao cluster, os CVM / s adicionais começam a participar das tarefas de Gerenciamento e resiliência de dados, mesmo quando nenhuma VM está em execução nos nós. A adição de novos nós permite que o Storage Fabric distribua o tráfego de RF entre mais controladores, o que aprimora a resiliência e E / S de gravação e ajuda a diminuir a latência.
A vantagem que o AHV possui sobre os outros hipervisores suportados é que o desempenho dos componentes de gerenciamento (muitos dos quais foram discutidos anteriormente) é escalonado dinamicamente com o cluster. Semelhante ao Analytics, os componentes de gerenciamento do AHV se expandem. Nunca há um ponto de inflexão que exija a redução manual do gerenciamento ou novas instâncias de implantação de componentes de gerenciamento ou suas dependências.
É importante ressaltar que, para todos os componentes, o XCP distribui dados e funções de gerenciamento em todos os nós do cluster. O Acropolis não usa componentes / hardware ou objetos “espelhados”, o que garante que dois nós ou componentes / hardware não se tornem um gargalo ou ponto de falha.
Segurança
A segurança é um dos principais pilares do design do XCP. O uso de automação inovadora resulta talvez na infraestrutura de virtualização mais rígida, simples e abrangente do setor.
O AHV não foi projetado para funcionar com um HCL abrangente de fornecedores de hardware, nem possui inúmeros produtos de estilo parafusado que precisam ser atendidos. Em vez disso, o hipervisor Acropolis foi otimizado para trabalhar com o Nutanix Distributed Storage Fabric e os appliances aprovados da Nutanix e parceiros OEM para fornecer todos os serviços / funcionalidades de uma maneira verdadeiramente em escala da Web.
Isso permite uma garantia de qualidade muito mais rígida e direcionada e reduz drasticamente a superfície de ataque em comparação com os hipervisores.
O Ciclo de Vida de Desenvolvimento de Segurança (SecDL) é aproveitado em toda a plataforma Acropolis, garantindo que todas as linhas de código estejam prontas para produção. Esse design segue um modelo de defesa em profundidade que remove todos os serviços desnecessários da libvirt / QEMU (SPICE, drivers não utilizados), aproveita os soquetes do grupo não raiz da libvirt para o princípio do menor privilégio, o SELinux confinou os hóspedes à proteção do vmescape e uma intrusão incorporada sistema de detecção.
O hipervisor da Acropolis possui uma linha de base de segurança documentada e suportada (XCCDF STIG) e apresenta o hipervisor de correção automática. Em um intervalo definido pelo cliente, o hipervisor é verificado quanto a alterações na linha de base de segurança suportada e redefine a linha de base de volta ao estado seguro se alguma anomalia for detectada em segundo plano sem intervenção do usuário.
A plataforma Acropolis também oferece uma lista abrangente de certificações / validações de segurança:
Sumário
Acropolis oferece inúmeras vantagens de segurança, incluindo:
Guias de implementação técnica (STIGs) de segurança internos e auto-auditáveis
Hypervisor reforçado pronto para uso, sem a necessidade de os administradores aplicarem recomendações de proteção
Superfície de ataque reduzida em comparação com outros hipervisores suportados
Resiliência
Ao discutir a resiliência, é comum cometer o erro de considerar apenas a resiliência de dados e não considerar a resiliência dos controladores de armazenamento e dos componentes de gerenciamento necessários para atender aos aplicativos de negócios.
As tecnologias herdadas, como as unidades RAID e Hot Spare, podem, em alguns casos, fornecer alta resiliência aos dados; no entanto, se eles forem apoiados por configurações do tipo de controlador duplo que não podem ser dimensionadas e recuperadas automaticamente, os dados podem estar indisponíveis ou o desempenho / funcionalidade severamente degradado após até uma falha de componente único. A infraestrutura que depende da substituição do HW para restaurar a resiliência após uma falha é fundamentalmente falha.
Além disso, se a camada de aplicativos de gerenciamento não for resiliente, a alta disponibilidade / resiliência da camada de dados poderá ser irrelevante, pois os aplicativos de negócios podem não estar funcionando adequadamente (por exemplo: em velocidades normais) ou de todo.
A plataforma Acropolis fornece alta resiliência para as camadas de dados e gerenciamento em um nível N + 1 ou N + 2 configurável (fator de resiliência 2 ou 3) que pode tolerar até duas falhas de nó simultâneas sem perder o acesso ao gerenciamento ou aos dados. Ao dizer que, com "Reconhecimento de bloco", um bloco inteiro (até quatro nós) pode falhar e o cluster ainda mantém a funcionalidade completa. Isso aumenta a resiliência dos componentes de dados e gerenciamento no XCP até N + 4.
Além disso, quanto maior o cluster XCP, menor o impacto de uma falha de nó / controlador / componente. Para um ambiente de quatro nós, N-1 é 25% de impacto, enquanto que para um cluster de 8 nós, N-1 é apenas 12,5%. Quanto maior o cluster, menor o impacto de uma falha do controlador / nó. Por outro lado, uma SAN de controlador duplo tem uma falha de controlador único e, em muitos casos, o impacto é de 50% de degradação e uma falha subsequente resultaria em uma interrupção. Os ambientes Nutanix XCP se auto-reparam, de modo que, mesmo para um ambiente configurado apenas para N-1, é possível após uma auto-recuperação, pois as falhas subsequentes podem ser toleradas sem causar alto impacto ou interrupções.
Caso a instância do Acropolis Master falhe, a funcionalidade completa retornará ao ambiente após uma eleição que será concluída em <30 segundos. Isso equivale a disponibilidade de gerenciamento maior que "seis noves" (99,9999%). É importante ressaltar que o AHV possui essa resiliência de gerenciamento integrada; requer zero configuração!
Quanto à disponibilidade de dados, independentemente do hipervisor, o DSF (Nutanix Distributed Storage Fabric) mantém duas ou três cópias de dados / paridade e, no caso de uma falha no SSD / HDD ou no nó, a RF configurada é restaurada por todos os nós no cluster.
Resiliência de dados
Embora tenhamos acabado de abordar por que a resiliência dos dados não é o único fator importante, ainda é fundamental. Afinal, se uma solução que fornece armazenamento compartilhado perde dados, ela não é adequada para o objetivo em nenhum datacenter.
Como a resiliência de dados é uma base fundamental para o Fabric de armazenamento distribuído da Nutanix, o status da resiliência de dados é exibido na tela inicial do Prism. Na captura de tela abaixo, podemos ver que a capacidade de fornecer resiliência no estado estacionário e no caso de uma falha (capacidade de reconstrução) é rastreada.
Neste exemplo, todos os dados no cluster são compatíveis com o fator de resiliência configurado (RF2 ou 3) e o cluster tem pelo menos N + 1 capacidade disponível para reconstruir após a perda de um nó.
Para se aprofundar no status de resiliência, basta clicar na caixa acima e ela será expandida para mostrar detalhes mais detalhados das falhas que podem ser toleradas.
Integridade de dados
O reconhecimento de uma E / S de gravação em um sistema operacional convidado deve ocorrer apenas quando os dados forem gravados em mídia persistente, pois até esse momento, é possível que ocorra perda de dados mesmo quando o armazenamento estiver protegido por cache com bateria e fontes de alimentação ininterruptas (UPS).
A única vantagem de reconhecer gravações antes que isso ocorra é o desempenho, mas qual é o desempenho quando seus dados não têm integridade ou são perdidos?
Outro requisito geralmente esquecido de qualquer solução de armazenamento de nível corporativo é a capacidade de detectar e recuperar-se da corrupção de dados silenciosa. O Acropolis realiza somas de verificação no software para cada gravação E em cada leitura. Importante Nutanix não é de forma dependente do hardware subjacente ou qualquer 3 rd software partido para manter a integridade dos dados, tudo soma de verificação e correção (quando necessário) é tratado de forma nativa.
Dica profissional: se uma solução de armazenamento não executar somas de verificação em Write AND Read, NÃO a use para dados de produção.
No caso de corrupção de dados silenciosa (que pode afetar qualquer dispositivo de armazenamento de qualquer fornecedor), a soma de verificação falhará e a E / S será atendida por outra réplica armazenada em um nó diferente (e, portanto, SSD / HDD físico). Se uma soma de verificação falhar em um ambiente com Erasure Coding, o EC-X recalcula os dados da mesma maneira como se um HDD / SSD falhasse e atenda à E / S.
Em segundo plano, o Nutanix Distributed Storage Fabric descartará os dados corrompidos e restaurará o fator de resiliência configurado da boa réplica ou faixa em que o EC-X é usado.
Esse processo é completamente transparente para a máquina virtual e o usuário final, mas é um componente crítico da resiliência do XCP. O DFS (Distributed Storage Fabric) subjacente também protege automaticamente todos os componentes de gerenciamento da Acropolis, este é um exemplo de uma das muitas vantagens da arquitetura da Acropolis, na qual todos os componentes são construídos juntos e não aparafusados posteriormente.
Um ambiente Acropolis com um contêiner configurado com RF3 (Replication Factor 3) fornece disponibilidade de gerenciamento N + 2. Como resultado, seria necessária uma falha extraordinariamente improvável de três falhas de nó simultâneas antes que uma interrupção do gerenciamento pudesse ocorrer. Felizmente, o XCP também tem uma resposta para esse cenário, embora seja improvável, o Block Awareness é um recurso em que, com 3 ou mais blocos, o cluster pode tolerar a falha de um bloco inteiro (até 4 nós) sem causar a perda de dados ou gerenciamento.
Parte da história da Acrópole sobre resiliência remonta à falta de complexidade. O Acropolis permite atualizações contínuas com 1 clique e inclui todas as funcionalidades. Não há um ponto único de falha; na pior das hipóteses, se o nó com o Acropolis mestre falhar, em 30 segundos a função Mestre será reiniciada em um nó sobrevivente e iniciará as VMs para ligar. Novamente, essa é uma funcionalidade incorporada, não soluções adicionais ou de terceiros que precisam ser projetadas / instaladas e mantidas.
Os pontos acima são basicamente funções do XCP e não o próprio AHV, então pensei em destacar os recursos de balanceamento de carga e failover de um AHV.
Diferentemente da infraestrutura tradicional de três camadas (ou seja: SAN / NAS), as soluções Nutanix não exigem multitapping, pois todas as E / S são atendidas pelo controlador local. Como resultado, não há uma política de caminhos múltiplos para escolher qual remove outra camada de complexidade e possível ponto de falha.
No entanto, no caso de a CVM local não estar disponível, por qualquer motivo, precisamos atender à E / S de todas as VMs no nó da maneira mais eficiente. O AHV faz isso redirecionando a E / S no nível por vDisk para uma instância remota aleatória do stargate, como mostrado abaixo.
O AHV pode fazer isso porque cada vdisk é apresentado via iSCSI e é seu próprio destino / LUN, o que significa que possui sua própria conexão TCP. O que isto significa é que um aplicativo crítico para os negócios, como o MS SQL / Exchange ou Oracle com vários vDisks, será atendido por vários controladores simultaneamente.
Como resultado, toda a E / S da VM tem carga balanceada em todo o cluster Acropolis, o que garante que nenhum CVM se torne um gargalo e as VMs desfrutam de excelente desempenho, mesmo em um cenário de falha ou manutenção.
Resumo
Recursos prontos para auto-recuperação para:
Falha no SSD / HDD / Node / s
Acrópole e PRISM (camada de gerenciamento)
Integridade de dados incorporada com somas de verificação baseadas em softw
Capacidade de tolerar até 4 falhas de nó simultâneas
Disponibilidade de gerenciamento de> 99.9999 (seis "noves")
Nenhuma dependência do hardware para resiliência de dados ou gerenciamento
ASG
contato@asg.com.br
(51) 3376.1210