Ambiente e processamento do sistema de storage Novus
Sugerir alterações
PDFs
Existem vários aspectos importantes do ambiente Novus e do seu processamento que você deve compreender.
Comunicação interna entre o Novus Data Director e o servidor de dados ONTAP
Os Novus Data Directors se comunicam com os servidores de dados ONTAP para dar suporte ao acesso a arquivos e ao gerenciamento. A maior parte disso é iniciada pelo NDD, e não pelos servidores ONTAP.
Descoberta do servidor de dados do ONTAP
Os Novus Data Directors precisam descobrir quais servidores de dados estão disponíveis. O ONTAP nunca inicia a comunicação com o Novus Data Director. Um operador ou uma ferramenta registra cada servidor de dados por meio do mds.conf arquivo de configuração, que é usado no momento da inicialização; os servidores de dados também podem ser adicionados manualmente usando o comando mds-admin ds add. Cada servidor de dados é representado como uma linha no repositório de metadados distribuído, incluindo seu host, exportação, portas, estado e capacidade.
Disponibilidade do servidor de dados do ONTAP
Existem diversos processos usados para determinar a disponibilidade de cada servidor de dados ONTAP.
- Heartbeat
-
O MDS envia uma chamada RPC NULL de NFSv3 por TCP para cada servidor de dados online. Por padrão, ele faz isso a cada 5 segundos usando uma mensagem de heartbeat.
- Ficando offline
-
Após um determinado número de falhas consecutivas, o servidor de dados é marcado como offline. O MDS para de colocar novos arquivos nele e informa aos clientes para que devolvam layouts que apontem para ele.
- Voltando
-
Após um número suficiente de sondagens bem-sucedidas em sequência, ele retorna ao modo online. Um período de resfriamento impede que ele alterne entre os modos.
- Erros do cliente não contam
-
Quando um cliente relata um erro, ele só é registrado em log. A integridade do servidor de dados do ONTAP é determinada apenas pelas sondas.
- O failover do ONTAP é invisível
-
Se um par de HA do ONTAP assumir o controle, o MDS só perceberá isso por meio de timeouts de sondagem.
Conteúdo de dados do servidor de dados ONTAP
O NDD não pergunta ao ONTAP o que ele armazena. Ele já sabe, porque cria todos os arquivos de suporte:
-
Quando um arquivo é criado, o MDS seleciona os servidores de dados, cria os arquivos de suporte neles e salva o resultado no mapa de faixas no repositório de metadados distribuído. O mapa de faixas registra qual servidor de dados e qual identificador de arquivo NFS contêm cada faixa e espelho.
-
Os arquivos de apoio no ONTAP têm um formato de nome específico no NDD.
-
A capacidade é o único valor operacional que o NDD lê do ONTAP usando statvfs() em cada exportação montada.
-
O tamanho do arquivo não é verificado em relação ao ONTAP. Isso é determinado pelo layout commit do cliente.
Alta disponibilidade e resiliência para o cluster NDD
O plano de metadados ancorado pelos Novus Data Directors garante alta disponibilidade e resiliência no sistema.
Projeto de cluster
A Novus utiliza um cluster multi-host para garantir alta disponibilidade e tolerância de falhas para os serviços NDD.
- Três hosts com três domínios de falha
-
O cluster NDD mínimo consiste em três hosts físicos ou máquinas virtuais (VMs) implantados em servidores separados. Cada host executa um processo MDS e um nó de armazenamento de metadados. O cluster foi projetado para sobreviver à perda de um host.
- Todas as réplicas servem
-
Cada réplica do MDS atende os clientes ao mesmo tempo, sem nenhuma designada em modo de espera. Todas as réplicas íntegras anunciam o mesmo VIP por meio do BGP. O BFD (detecção rápida de falha de link) é necessário porque os temporizadores do próprio BGP, por si só, não constituem um mecanismo de failover totalmente aceitável. Uma réplica anuncia o VIP somente quando seu serviço NFS, gateway e conexão com o repositório de metadados estão todos prontos para atender clientes.
- Replicação de metadados
-
O repositório de metadados distribuído mantém três cópias síncronas. Um árbitro impede um cenário de split-brain ao optar por ficar indisponível em vez de permitir que os dois lados gravem.
- Reinicializações são seguras
-
Os processos MDS não mantêm nenhum estado próprio; o repositório de metadados distribuído contém os metadados autoritativos.
Limitações e precauções
Você também deve estar ciente das seguintes limitações e precauções:
-
A transferência de propriedade de subárvores não ocorre automaticamente. O namespace pode ser dividido em subárvores, cada uma pertencente a um MDS. Se um proprietário falhar, sua subárvore permanece inativa até que o proprietário retorne, mesmo que o VIP já tenha sido movido.
-
A falha de um host afeta todos os locatários nesse host, pois cada locatário possui uma réplica por host.
-
Os clientes devem montar o VIP e não um IP de host. Caso contrário, o cliente não poderá realizar o failover.
-
Montagens hard podem bloquear durante a recuperação. Uma montagem bloqueada não significa que os dados foram perdidos.
-
Sempre faça a manutenção de uma réplica por vez. Retire a réplica da VIP e drene-a primeiro.