Existem três tenents muito importantes para sistemas de definição de software:
Deve fornecer mobilidade de plataforma (hardware, hipervisor)
Não deve depender de nenhum hardware personalizado
Deve permitir uma rápida velocidade de desenvolvimento (recursos, correções de bugs, patches de segurança)
Deve tirar proveito da lei de Moore
Como mencionado acima (provavelmente várias vezes), a plataforma Nutanix é uma solução baseada em software que é fornecida como um pacote de software + hardware. A VM controladora é onde a grande maioria do software e da lógica da Nutanix se encontra e foi projetada desde o início para ser uma arquitetura extensível e conectável.
Um benefício-chave para ser definido por software e não depender de offloads ou construções de hardware está relacionado à extensibilidade. Como acontece com qualquer ciclo de vida do produto, os avanços e novos recursos sempre serão introduzidos.
Por não depender de nenhum recurso ASIC / FPGA ou de hardware personalizado, a Nutanix pode desenvolver e implantar esses novos recursos por meio de uma simples atualização de software. Isso significa que a implantação de um novo recurso (por exemplo, desduplicação) pode ser implantada ao atualizar a versão atual do software Nutanix. Isso também permite que novos recursos de geração sejam implantados em modelos de hardware legados. Por exemplo, digamos que você esteja executando uma carga de trabalho executando uma versão mais antiga do software Nutanix em uma plataforma de hardware da geração anterior (por exemplo, 2400). A versão de software em execução não oferece recursos de desduplicação dos quais sua carga de trabalho poderia se beneficiar muito. Para obter esses recursos, você executa uma atualização sem interrupção da versão do software Nutanix enquanto a carga de trabalho está em execução e agora você tem a deduplicação. É realmente assim tão fácil.
Semelhante aos recursos, a capacidade de criar novos “adaptadores” ou interfaces no DSF é outro recurso importante. Quando o produto foi lançado pela primeira vez, ele suportava apenas o iSCSI para E / S do hypervisor, e agora ele cresceu para incluir o NFS e o SMB. No futuro, há a capacidade de criar novos adaptadores para várias cargas de trabalho e hipervisores (HDFS, etc.). E, novamente, tudo isso pode ser implantado por meio de uma atualização de software. Isso é contrário à maioria das infra-estruturas legadas, em que normalmente é necessária uma atualização de hardware ou uma compra de software para obter os recursos “mais recentes e melhores”. Com a Nutanix, é diferente. Como todos os recursos são implantados em software, eles podem ser executados em qualquer plataforma de hardware, em qualquer hypervisor e implantados por meio de atualizações de software simples.
A figura a seguir mostra uma representação lógica do aspecto dessa estrutura de controlador definida por software:
Componentes de Cluster
Para uma explicação visual, você pode assistir ao seguinte vídeo: LINK
O produto Nutanix voltado para o usuário é extremamente simples de implantar e usar. Isso é possível principalmente por meio de abstração e muita automação / integração no software.
A seguir, uma visão detalhada dos principais componentes do Nutanix Cluster (não se preocupe, não é necessário memorizar ou saber o que tudo faz):
Cassandra
Função-chave: armazenamento de metadados distribuídosDescrição: o Cassandra armazena e gerencia todos os metadados de cluster de maneira semelhante a um anel distribuído, com base em um Apache Cassandra altamente modificado. O algoritmo Paxos é utilizado para impor uma consistência estrita. Este serviço é executado em todos os nós do cluster. O Cassandra é acessado através de uma interface chamada Medusa.
Zookeeper
Função-chave: gerenciador de configuração de clusterDescrição: O Zookeeper armazena toda a configuração do cluster, incluindo hosts, IPs, estado etc., e é baseado no Apache Zookeeper. Esse serviço é executado em três nós no cluster, um dos quais é eleito como líder. O líder recebe todos os pedidos e os encaminha aos seus pares. Se o líder não responder, um novo líder será automaticamente eleito. O Zookeeper é acessado através de uma interface chamada Zeus.
Stargate
Função-chave: Gerenciador de E / S de dadosDescrição: O Stargate é responsável por todo o gerenciamento de dados e operações de E / S e é a principal interface do hipervisor (via NFS, iSCSI ou SMB). Esse serviço é executado em todos os nós do cluster para servir a E / S localizada.
Curador
Função principal: gerenciamento e limpeza de cluster do MapReduceDescrição: O Curador é responsável por gerenciar e distribuir tarefas em todo o cluster, incluindo balanceamento de disco, limpeza proativa e muitos outros itens. O curador é executado em todos os nós e é controlado por um curador eleito, responsável pela tarefa e pela delegação de trabalho. Existem dois tipos de varredura para o Curator, uma varredura completa que ocorre a cada 6 horas e uma varredura parcial que ocorre a cada hora.
Prisma
Papel chave: interface do usuário e APIDescrição: Prism é o gateway de gerenciamento para que o componente e os administradores configurem e monitorem o cluster Nutanix. Isso inclui o Ncli, a interface do usuário HTML5 e a API REST. O prisma é executado em todos os nós do cluster e usa um líder eleito como todos os componentes do cluster.
Gênese
Papel chave: componente de cluster e gerente de serviçoDescrição: Genesis é um processo que é executado em cada nó e é responsável por quaisquer interações de serviços (start / stop / etc.), Bem como pela configuração inicial. O Genesis é um processo que é executado independentemente do cluster e não requer que o cluster seja configurado / esteja em execução. O único requisito para o Genesis estar em execução é que o Zookeeper esteja pronto e funcionando. As páginas cluster_init e cluster_status são exibidas pelo processo Genesis.
Chronos
Função-chave: Job and task schedulerDescrição: O Chronos é responsável por assumir os trabalhos e tarefas resultantes de uma varredura do Curador e de tarefas de programação / limitação entre nós. O Chronos é executado em todos os nós e é controlado por um Chronos Master eleito que é responsável pela tarefa e pela delegação do trabalho e é executado no mesmo nó que o Mestre do Curador.
Cerebro
Função-chave: Replication / DR managerDescrição: O Cerebro é responsável pelos recursos de replicação e DR do DSF.Isso inclui o agendamento de instantâneos, a replicação para sites remotos e a migração / failover do site. O Cerebro é executado em todos os nós do cluster Nutanix e todos os nós participam da replicação em clusters / sites remotos.
Pithos
Função-chave: gerenciador de configuração do vDiskDescrição: O Pithos é responsável pelos dados de configuração do vDisk (arquivo DSF). O Pithos é executado em todos os nós e é construído sobre o Cassandra.
Atualizações do AOS
Para uma atualização do AOS, existem algumas etapas principais que são executadas:
1 - Verificações de pré-atualização
Durante as verificações de pré-atualização, os seguintes itens são verificados.NOTA: Isso deve ser concluído com êxito antes que uma atualização possa continuar.
Verifique a compatibilidade de versões entre o AOS, versões do hipervisorVerificar a integridade do cluster (status do cluster, espaço livre e verificações de componentes (por exemplo, Medusa, Stargate, Zookeeper, etc.)Verifique a conectividade de rede entre todos os CVM e Hypervisors
2 - Carregar o software de atualização para 2 nós
Assim que as verificações de pré-atualização forem concluídas, o sistema carregará os binários do software de atualização para dois nós no cluster. Isso é feito para tolerância a falhas e para garantir que, se um CVM estiver reinicializando, o outro esteja disponível para outros usuários extraírem o software.
Software de Atualização em 3 Estágios
Uma vez que o software tenha sido enviado para dois CVMs, todos os CVMs irão realizar o upgrade em paralelo.
Os CVMs possuem duas partições para as versões do AOS:
Partição ativa (a versão atualmente em execução)Partição passiva (onde as atualizações são encenadas)
Quando ocorre uma atualização do AOS, realizamos a atualização na partição não ativa. Quando o token de atualização for recebido, ele marcará a partição atualizada como a partição ativa e reinicializará o CVM na versão atualizada. Isso é semelhante a um bootbank / altbootbank.
NOTA: o token de atualização é transmitido entre os nós de forma iterativa. Isso garante que apenas um CVM seja reinicializado por vez. Quando o CVM for reinicializado e estiver estável (verifique o status e a comunicação do serviço), o token poderá ser passado para o próximo CVM até que todos os CVMs tenham sido atualizados.
Tratamento de erro de atualização
Uma pergunta comum é o que acontece se a atualização não for bem-sucedida ou tiver um problema parcialmente durante o processo?
No caso de ocorrer algum problema de atualização, interromperemos a atualização e não avançaremos. Observação: isso é uma ocorrência muito pouco frequente como verificações pré-atualização encontrarão a maioria dos problemas antes do início da atualização. No entanto, caso as verificações de pré-atualização sejam bem-sucedidas e algum problema ocorra durante a atualização real, não haverá impacto nas cargas de trabalho e na E / S de usuário em execução no cluster.
O software Nutanix foi projetado para funcionar indefinidamente em um modo misto entre as versões de atualização suportadas. Por exemplo, se o cluster estiver executando o xyfoo e estiver atualizando para o xybar, o sistema poderá ser executado indefinidamente com os CVMs em ambas as versões.Isso é realmente o que ocorre durante o processo de atualização.
Por exemplo, se você tiver um cluster de 4 nós em xyfoo e iniciar a atualização para xybar, quando o primeiro nó for atualizado, ele estará executando xybar enquanto os outros estão em xyfoo. Esse processo continuará e os CVMs serão reinicializados no xybar quando receberem o token de atualização.
Fundação (Imaging)
Arquitetura
A Foundation é uma ferramenta fornecida pela Nutanix, alavancada para bootstrapping, geração de imagens e implantação de clusters Nutanix. O processo de criação de imagens instalará a versão desejada do software AOS, bem como o hipervisor de escolha.
Por padrão, os nós da Nutanix são fornecidos com o AHV pré-instalado, para aproveitar um tipo de hypervisor diferente, você deve usar a base para refazer a imagem dos nós com o hipervisor desejado. NOTA: Alguns OEMs serão enviados diretamente da fábrica com o hipervisor desejado.
A figura mostra uma visão de alto nível da arquitetura Foundation:
A partir de 4.5, a Fundação é incorporada aos CVMs para simplificar a configuração. O repositório do instalador é um diretório para armazenar as imagens enviadas, elas podem ser usadas para a geração de imagens inicial e também para a expansão do cluster quando a criação de imagens é necessária.
O Applet Foundation Discovery é responsável por descobrir os nós e permitir que o usuário selecione um nó ao qual se conectar.Uma vez que o usuário tenha selecionado um nó para se conectar, o applet irá proxy localhost: 9442 IPv4 para o endereço local de conexão IPv6 do CVM na porta 8000.
A figura mostra uma visão de alto nível da arquitetura do applet:
Entradas
A ferramenta Foundation possui as seguintes entradas de configuração (abaixo).Uma implantação típica requer 3 endereços IP por nó (hipervisor, CVM, gerenciamento remoto (por exemplo, IPMI, iDRAC, etc.)). Além dos endereços por nó, é recomendável definir os endereços IP de Cluster e Data Services.
GrupoNomeIP *NTP *DNS *CVMIP por CVMNetmaskGatewayMemóriaHipervisorIP por host de hypervisorNetmaskGatewayDNS *Prefixo do nome do hostIPMI *IP por nóNetmaskGateway
NOTA: Itens marcados com '*' são opcionais, mas altamente recomendável.
Repartição do Drive
Nesta seção, explicarei como os vários dispositivos de armazenamento (SSD / HDD) são divididos, particionados e utilizados pela plataforma Nutanix. NOTA: Todas as capacidades utilizadas estão no Base2 Gibibyte (GiB) em vez do Base10 Gigabyte (GB). A formatação das unidades com um sistema de arquivos e despesas gerais associadas também foi levada em conta.
Dispositivos SSD
Dispositivos SSD armazenam alguns itens importantes que são explicados em maiores detalhes acima:
Nutanix Home (núcleo da CVM)Cassandra (armazenamento de metadados)OpLog (buffer de gravação persistente)Cache unificado (parte do cache SSD)Armazenamento Extensivo (armazenamento persistente)
A figura a seguir mostra um exemplo do detalhamento de armazenamento de um (s) SSD (s) do nó Nutanix:
NOTA: O dimensionamento para o OpLog é feito dinamicamente a partir do release 4.0.1, o que permitirá que a parte da loja de extensão cresça dinamicamente. Os valores usados estão assumindo um OpLog completamente utilizado. Gráficos e proporções não são desenhados para escala. Ao avaliar as capacidades do GiB restante, faça isso de cima para baixo. Por exemplo, o GiB restante a ser usado para o cálculo do OpLog seria depois que o Nutanix Home e o Cassandra fossem subtraídos da capacidade formatada do SSD.
O OpLog é distribuído entre todos os dispositivos SSD até um máximo de 8 por nó a partir de 5.5 (Gflag: max_ssds_for_oplog). Se os dispositivos NVMe estiverem disponíveis, o OpLog será colocado nesses dispositivos em vez do SSD SATA.
O Nutanix Home é espelhado nos dois primeiros SSDs para garantir a disponibilidade. A partir de 5.0, o Cassandra é fragmentado em SSDs no nó (atualmente até 4) com uma reserva inicial de 15GiB por SSD (pode aproveitar alguns SSD do Stargate se o uso de metadados aumentar). Em sistemas SSD duplos, os metadados serão espelhados entre os SSDs. A reserva de metadados por SSD é de 15 GiB (30GiB para SSD duplo, 60GiB para 4+ SSD).
Antes do 5.0, o Cassandra estava no primeiro SSD por padrão, se o SSD falhar, o CVM será reiniciado e o armazenamento do Cassandra, então, será no segundo.Nesse caso, a reserva de metadados por SSD é de 30 GiB para os dois primeiros dispositivos.
A maioria dos modelos é fornecida com 1 ou 2 SSDs, no entanto, a mesma construção se aplica a modelos com mais dispositivos SSD. Por exemplo, se aplicarmos isso a um nó de exemplo 3060 ou 6060 que tenha 2 x SSDs de 400 GB, isso nos fornecerá 100GiB de OpLog, 40GiB de Cache Unificado e ~ 440GiB de capacidade de SSD de Armazenamento de Extensão por nó.
Dispositivos HDD
Como os dispositivos de HDD são usados principalmente para armazenamento em massa, sua divisão é muito mais simples:
Reserva do Curador (Armazenamento do Curador)Armazenamento Extensivo (armazenamento persistente)
Por exemplo, se aplicarmos isso a um nó de exemplo 3060 que tenha 4 x HDDs de 1 TB, isso nos daria 80GiB reservados para o Curador e ~ 3.4TiB de capacidade de HDD do Armazenamento de Extensão por nó.
OBSERVAÇÃO: os valores acima são precisos a partir de 4.0.1 e podem variar de acordo com o release.
ASG
https://www.asgit.com.br
contato@asg.com.br
(51) 3376.1210
Comments