Visão geral do software tiebreaker
Sugerir alterações
PDFs
É útil entender o que é o software tiebreaker da NetApp MetroCluster e como ele distingue entre os tipos de falhas para que você possa monitorar suas configurações do MetroCluster com eficiência. Use a CLI do tiebreaker para gerenciar configurações e monitorar o status e as operações das configurações do MetroCluster.
Detecção de falhas com o software tiebreaker NetApp MetroCluster
Você só precisa do software tiebreaker se quiser monitorar dois clusters e o status de conectividade entre eles em um terceiro local. O software tiebreaker reside em um host Linux no terceiro local e permite que cada parceiro em um cluster faça a distinção entre uma falha ISL, quando os links entre sites estão inativos, de uma falha do local.
Depois de instalar o software tiebreaker em um host Linux, é possível configurar os clusters em uma configuração do MetroCluster para monitorar as condições de desastre.
O software tiebreaker pode monitorar até 15 configurações de MetroCluster simultaneamente. Ele dá suporte a uma combinação de configurações MetroCluster IP, MetroCluster FC e Stretch MetroCluster.
Como o software tiebreaker deteta falhas no local
O software tiebreaker do NetApp MetroCluster verifica a acessibilidade dos nós em uma configuração do MetroCluster e do cluster para determinar se ocorreu uma falha no local. O software tiebreaker também aciona um alerta sob certas condições.
Componentes monitorados pelo software tiebreaker
O software tiebreaker monitora cada controladora na configuração do MetroCluster estabelecendo conexões redundantes por meio de vários caminhos para um LIF de gerenciamento de nós e para o LIF de gerenciamento de cluster, ambos hospedados na rede IP.
O software tiebreaker monitora os seguintes componentes na configuração do MetroCluster:
-
Nós por meio de interfaces de nós locais
-
Cluster por meio das interfaces designadas por cluster
-
Cluster sobrevivente para avaliar se ele tem conetividade com o local de desastre (interconexão NV, armazenamento e peering entre clusters)
Quando houver uma perda de conexão entre o software tiebreaker e todos os nós no cluster e para o próprio cluster, o cluster será declarado como "não alcançável" pelo software tiebreaker. Demora cerca de três a cinco segundos para detetar uma falha de ligação. Se um cluster não estiver acessível a partir do software tiebreaker, o cluster sobrevivente (o cluster que ainda está acessível) deve indicar que todos os links para o cluster de parceiros são cortados antes que o software tiebreaker acione um alerta.
|
Todos os links são cortados se o cluster sobrevivente não puder mais se comunicar com o cluster no local de desastre por meio de FC (interconexão e armazenamento NV) e peering entre clusters. |
Cenários de falha durante os quais o software tiebreaker aciona um alerta
O software tiebreaker aciona um alerta quando o cluster (todos os nós) no local de desastre está inativo ou inacessível e o cluster no local sobrevivente indica o status "'AllLinksSevered'".
O software tiebreaker não aciona um alerta (ou o alerta é vetado) nos seguintes cenários:
-
Em uma configuração de MetroCluster de oito nós, se um par de HA no local de desastre estiver inativo
-
Em um cluster com todos os nós no local do desastre para baixo, um par de HA no local sobrevivente para baixo, e o cluster no local sobrevivente indica o status ""AllLinksSevered""
O software tiebreaker aciona um alerta, mas o ONTAP veta esse alerta. Nesta situação, também é vetado um switchover manual
-
Qualquer cenário em que o software tiebreaker possa alcançar pelo menos um nó ou a interface de cluster no local de desastre, ou o local sobrevivente ainda pode alcançar qualquer nó no local de desastre por meio de FC (interconexão e storage NV) ou peering entre clusters
"Riscos e limitações do uso do MetroCluster Tiebreaker no modo ativo"
Como o software tiebreaker deteta falhas de conetividade entre sites
O software tiebreaker do MetroCluster alerta você se toda a conetividade entre os sites for perdida.
Tipos de caminhos de rede
Dependendo da configuração, existem três tipos de caminhos de rede entre os dois clusters em uma configuração MetroCluster:
-
Rede FC (presente em configurações MetroCluster conetadas à malha)
Esse tipo de rede é composto por duas malhas de switch FC redundantes. Cada malha de switch tem dois switches FC, com um switch de cada malha de switch colocado com um cluster. Cada cluster tem dois switches FC, um de cada malha de switch. Todos os nós têm conectividade FC (interconexão NV e iniciador FCP) a cada um dos switches FC colocalizados. Os dados são replicados de cluster para cluster através do ISL.
-
Rede de peering entre clusters
Este tipo de rede é composto por um caminho de rede IP redundante entre os dois clusters. A rede de peering de cluster fornece a conectividade necessária para espelhar a configuração da máquina virtual de storage (SVM). A configuração de todos os SVMs em um cluster é espelhada pelo cluster de parceiros.
-
Rede IP (presente nas configurações IP do MetroCluster)
Este tipo de rede é composto por duas redes de switch IP redundantes. Cada rede tem dois switches IP, com um switch de cada malha de switch co-localizado com um cluster. Cada cluster tem dois switches IP, um de cada malha de switch. Todos os nós têm conectividade a cada um dos switches FC colocalizados. Os dados são replicados de cluster para cluster através do ISL.
Monitoramento da conetividade entre sites
O software tiebreaker recupera regularmente o status da conetividade entre sites dos nós. Se a conetividade de interconexão NV for perdida e o peering entre clusters não responder a pings, os clusters assumem que os sites estão isolados e o software tiebreaker aciona um alerta como ""AllLinksSevered"". Se um cluster identificar o status ""AllLinksSevered"" e o outro cluster não estiver acessível através da rede, o software tiebreaker aciona um alerta como "disaster".
Como diferentes tipos de desastre afetam o tempo de deteção do software tiebreaker
Para um melhor Planejamento de recuperação de desastres, o software tiebreaker da MetroCluster leva algum tempo para detetar um desastre. Este tempo gasto é o "tempo de deteção do "usuário". O software tiebreaker do MetroCluster deteta o desastre no local em 30 segundos a partir do momento da ocorrência do desastre e aciona a operação de recuperação de desastres para notificá-lo sobre o desastre.
O tempo de deteção também depende do tipo de desastre e pode exceder 30 segundos em alguns cenários, principalmente conhecidos como ""desastres rolantes"". Os principais tipos de desastre contínuo são os seguintes:
-
Perda de energia
-
Pânico
-
Parar ou reiniciar
-
Perda de switches FC no local de desastre
Perda de energia
O software tiebreaker aciona imediatamente um alerta quando o nó deixa de funcionar. Quando há uma perda de energia, todas as conexões e atualizações, como peering entre clusters, interconexão NV e disco de caixa de correio, param. O tempo decorrido entre o cluster se tornar inacessível, a deteção do desastre e o gatilho, incluindo o tempo de silêncio padrão de 5 segundos, não deve exceder 30 segundos.
Pânico
Nas configurações do MetroCluster FC, o software tiebreaker aciona um alerta quando a conexão de interconexão NV entre os sites está inativa e o site sobrevivente indica o status ""AllLinksSevered"". Isso só acontece depois que o processo de coredump estiver concluído. Nesse cenário, o tempo decorrido entre o cluster e a deteção de um desastre pode ser maior ou aproximadamente igual ao tempo necessário para o processo de coredump. Em muitos casos, o tempo de deteção é superior a 30 segundos.
Se um nó parar de funcionar, mas não gerar um arquivo para o processo de coredump, o tempo de deteção não deve ser superior a 30 segundos. Nas configurações IP do MetroCluster, o NV pára de se comunicar e o site sobrevivente não está ciente do processo de coredump.
Parar ou reiniciar
O software tiebreaker aciona um alerta apenas quando o nó está inativo e o site sobrevivente indica o status "'AllLinksSevered". O tempo necessário entre o cluster se tornar inacessível e a deteção de um desastre pode ser superior a 30 segundos. Nesse cenário, o tempo necessário para detectar um desastre depende de quanto tempo leva para que os nós no local do desastre sejam desligados.
Perda de switches FC no local de desastre (configuração de MetroCluster conectada à malha)
O software tiebreaker aciona um alerta quando um nó deixa de funcionar. Se os switches FC forem perdidos, o nó tentará recuperar o caminho para um disco por cerca de 30 segundos. Durante esse tempo, o nó está ativo e respondendo na rede de peering. Quando ambos os switches FC estão inativos e o caminho para um disco não pode ser recuperado, o nó produz um erro MultiDiskFailure e pára. O tempo decorrido entre a falha do switch FC e o número de vezes que os nós produziram erros MultiDiskFailure é cerca de 30 segundos mais longo. Esses 30 segundos adicionais devem ser adicionados ao tempo de deteção de desastres.
Sobre a CLI e as páginas man do tiebreaker
A CLI do tiebreaker fornece comandos que permitem configurar remotamente o software tiebreaker e monitorar as configurações do MetroCluster.
O prompt de comando da CLI é representado como NetApp MetroCluster tiebreaker::>.
As páginas man estão disponíveis na CLI inserindo o nome do comando aplicável no prompt.