Skip to main content
ONTAP Select
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Configurações de alta disponibilidade do ONTAP Select

PDFs

Descubra as opções de alta disponibilidade para selecionar a melhor configuração de HA para o seu ambiente.

Embora os clientes estejam começando a migrar cargas de trabalho de aplicativos de dispositivos de armazenamento de classe empresarial para soluções baseadas em software executadas em hardware como commodity, as expectativas e necessidades em relação à resiliência e tolerância de falhas não mudaram. Uma solução de par de HA que forneça um objetivo de ponto de recuperação (RPO) zero protege o cliente contra perda de dados devido a uma falha em qualquer componente da pilha de infraestrutura.

Grande parte do mercado de SDS baseia-se no conceito de storage compartilhado-nada, com a replicação de software proporcionando resiliência ao armazenar múltiplas cópias dos dados de usuário em diferentes silos de storage. ONTAP Select expande essa premissa utilizando os recursos de replicação síncrona (RAID SyncMirror) fornecidos pelo ONTAP para armazenar uma cópia extra dos dados de usuário dentro do cluster. Isso ocorre no contexto de um par de HA. Cada par de HA armazena duas cópias dos dados de usuário: uma no storage fornecido pelo nó local e uma no storage fornecido pelo parceiro de HA. Dentro de um cluster ONTAP Select, HA e replicação síncrona estão integrados, e a funcionalidade de ambos não pode ser desacoplada ou usada independentemente. Como resultado, a funcionalidade de replicação síncrona está disponível apenas na oferta com múltiplos nós.

Observação Em um cluster ONTAP Select, a funcionalidade de replicação síncrona é uma função da implementação de HA, não uma substituição para os mecanismos de replicação assíncrona SnapMirror ou SnapVault. A replicação síncrona não pode ser usada independentemente de HA.

Existem dois modelos de implantação de HA do ONTAP Select: os clusters multinó (quatro, seis, oito, dez ou doze nós) e os clusters de dois nós. A principal característica de um cluster de dois nós do ONTAP Select é o uso de um serviço mediador externo para resolver cenários de split-brain. A VM ONTAP Deploy atua como mediador padrão para todos os pares de HA de dois nós que ela configura.

As duas arquiteturas estão representadas nas figuras a seguir.

Cluster de dois nós ONTAP Select com mediador remoto e utilizando storage local conectado diretamente

Cluster de dois nós ONTAP Select com mediador remoto e usando storage conectado localmente

Observação O cluster de dois nós ONTAP Select é composto por um par de HA e um mediador. Dentro do par de HA, os agregados de dados em cada nó de cluster são espelhados de forma síncrona e, em caso de failover, não há perda de dados.

*Cluster ONTAP Select de quatro nós usando storage conectado localmente*Cluster ONTAP Select de quatro nós usando armazenamento conectado localmente

  • O cluster ONTAP Select de quatro nós é composto por dois pares de HA. Os clusters de seis, oito, dez e doze nós são compostos por três, quatro, cinco e seis pares de HA, respectivamente. Dentro de cada par de HA, os agregados de dados em cada nó de cluster são espelhados de forma síncrona e, em caso de failover, não há perda de dados.

  • Apenas uma instância do ONTAP Select pode estar presente em um servidor físico ao usar armazenamento DAS. ONTAP Select requer acesso não compartilhado ao controlador RAID do sistema e foi projetado para gerenciar os discos conectados localmente, o que seria impossível sem conectividade física ao storage.

HA de dois nós versus HA de múltiplos nós

Ao contrário dos arrays FAS, os nós ONTAP Select em um par de HA comunicam-se exclusivamente pela rede IP. Isso significa que a rede IP é um ponto único de falha (SPOF), e proteger contra particionamentos de rede e cenários de split-brain torna-se um aspecto importante do projeto. O cluster com vários nós pode suportar falhas de um único nó porque o quorum do cluster pode ser estabelecido pelos três ou mais nós sobreviventes. O cluster de dois nós depende do serviço de mediação hospedado pela VM do ONTAP Deploy para obter o mesmo resultado.

O tráfego de rede de heartbeat entre os nós do ONTAP Select e o serviço mediador do ONTAP Deploy é mínimo e resiliente, permitindo que a VM do ONTAP Deploy seja hospedada em um data center diferente do cluster de dois nós do ONTAP Select.

Observação A VM do ONTAP Deploy torna-se parte integrante de um cluster de dois nós quando atua como mediadora para esse cluster. Se o serviço de mediação não estiver disponível, o cluster de dois nós continua a fornecer dados, mas os recursos de failover de armazenamento do cluster ONTAP Select são desativados. Portanto, o serviço de mediação do ONTAP Deploy deve manter comunicação constante com cada nó ONTAP Select no par de HA. Uma largura de banda mínima de 5 Mbps e uma latência máxima de ida e volta (RTT) de 125 ms são necessárias para permitir o funcionamento adequado do quorum do cluster.

Se a VM do ONTAP Deploy que atua como mediadora estiver temporariamente ou potencialmente permanentemente indisponível, uma VM secundária do ONTAP Deploy pode ser usada para restaurar o quorum do cluster de dois nós. Isso resulta em uma configuração na qual a nova VM do ONTAP Deploy não consegue gerenciar os nós do ONTAP Select, mas participa com sucesso do algoritmo de quorum do cluster. A comunicação entre os nós do ONTAP Select e a VM do ONTAP Deploy é feita usando o protocolo iSCSI sobre IPv4. O endereço IP de gerenciamento do nó do ONTAP Select é o iniciador, e o endereço IP da VM do ONTAP Deploy é o destino. Portanto, não é possível oferecer suporte a endereços IPv6 para os endereços IP de gerenciamento do nó ao criar um cluster de dois nós. Os discos de caixa de correio hospedados pelo ONTAP Deploy são criados e mascarados automaticamente para os endereços IP de gerenciamento do nó do ONTAP Select corretos no momento da criação do cluster de dois nós. Toda a configuração é realizada automaticamente durante a instalação, e nenhuma ação administrativa adicional é necessária. A instância do ONTAP Deploy que cria o cluster é a mediadora padrão para esse cluster.

Uma ação administrativa é necessária caso seja preciso alterar a localização original do mediador. É possível recuperar o quorum do cluster mesmo que a VM original do ONTAP Deploy seja perdida. No entanto, NetApp recomenda que você faça backup do banco de dados do ONTAP Deploy após a instanciação de cada cluster de dois nós.

Par de HA de dois nós versus par de HA estendido de dois nós (MetroCluster SDS)

É possível estender um par de HA ativo-ativo de dois nós por distâncias maiores e, potencialmente, alocar cada nó em um data center. A única distinção entre um cluster de dois nós e um cluster estendido de dois nós (também conhecido como MetroCluster SDS) é a distância de conectividade de rede entre os nós.

Um cluster de dois nós é definido como um cluster em que ambos os nós estão localizados no mesmo data center, a uma distância de 300m. Em geral, ambos os nós possuem uplinks para o mesmo switch de rede ou conjunto de switches de rede interswitch link (ISL).

Um cluster de dois nós MetroCluster SDS é definido como um cluster com nós fisicamente separados (salas diferentes, edifícios diferentes e centros de dados diferentes) por mais de 300m. Além disso, as conexões de uplink de cada nó são conectadas a switches de rede separados. O MetroCluster SDS não requer hardware dedicado. No entanto, o ambiente deve atender aos requisitos de latência (máximo de 5ms para RTT e 5ms para jitter, totalizando 10ms).

MetroCluster SDS é um recurso premium e requer uma licença Premium ou uma licença Premium XL. A licença Premium permite a criação de VMs pequenas e médias, bem como mídias HDD e SSD. A licença Premium XL também permite a criação de unidades NVMe.

Observação MetroCluster SDS é compatível com armazenamento conectado localmente (DAS) e storage compartilhado (vNAS). Observe que as configurações vNAS geralmente apresentam uma latência inata maior devido à rede entre a VM do ONTAP Select e o storage compartilhado. As configurações MetroCluster SDS devem fornecer no máximo 10 ms de latência entre os nós, incluindo a latência do storage compartilhado. Em outras palavras, medir apenas a latência entre as VMs do Select não é adequado, pois a latência do storage compartilhado não é desprezível nessas configurações.