Recentemente me deparei com um problema interessante no meu ACI Fabric que foi detectado pela equipe de gerenciamento do SQL Server, a falha estava na solução de failover, pois não encontrei muitas informações disponíveis sobre isso, pensei em compartilhar minha experiência. Antes de começar a falar sobre o cenário, devemos entender vários conceitos básicos do SQL Server que você não conhecia como Listener.
Visao general de SQL Server Always On Listeners
Vou tentar explicar esse ambiente o mais breve possível, como você pode ver na imagem temos 2 placas de rede para cada instância, a primeira placa de rede que vamos chamar de pública, isso faz a comunicação em todo o domínio e a segunda rede tem o nome de Heartbeat esta placa é usada única e exclusivamente para comunicação entre os servidores que fazem parte do CLUSTER com endereços IP diferentes, essas placas são responsáveis por enviar um sinal entre elas caso o Cluster perca a comunicação entenderá que há um problema de indisponibilidade e, como tal, ele deve transportar toda a sessão da instância 1 (onde o SQL Server está sendo executado) para a segunda instância automaticamente. Lembrando que o ambiente SQL Server deve ser instalado dentro da solução Microsoft Windows Server Failover Clustering (WSFC) para que se tenha um ambiente de alta disponibilidade, como pode-se concluir, será necessário um Controlador de Domínio para poder implementar a referida solução.
O que é uma Availability Group (AG) Listener
Um Availability Group Listener é um nome de rede virtual (VNN) ao qual os clientes podem se conectar para acessar uma réplica primária ou secundária de um grupo de alta disponibilidade AlwaysOn. Um Ouvinte permite que um cliente se conecte a uma réplica sem precisar saber o nome da instância física do SQL Server. Como o ouvinte roteia o tráfego, não há necessidade de modificar a cadeia de conexão do cliente após a ocorrência de um failover.
Um Availability Group Listener consiste em um nome de ouvinte do Sistema de Nomes de Domínio (DNS), a designação da porta do ouvinte e um ou mais endereços IP. Somente o protocolo TCP oferece suporte ao Ouvinte do Grupo de Disponibilidade. O nome DNS do Ouvinte deve ser exclusivo no domínio e no NetBIOS. Quando você cria um Ouvinte, ele se torna um recurso de cluster associado a um nome de rede virtual (VNN), um IP virtual (VIP) e uma dependência de Ouvinte do Grupo de Disponibilidade. Um cliente usa o DNS para resolver o VNN para vários endereços IP e, em seguida, tenta se conectar a cada endereço, até que uma solicitação de conexão seja bem-sucedida ou até que as solicitações de conexão expirem.
Se o roteamento somente leitura estiver configurado para uma ou mais réplicas secundárias legíveis, as tentativas de conexões do cliente de leitura com o Ouvinte serão redirecionadas automaticamente para uma réplica secundária legível. Este artigo fornece uma visão geral de um ouvinte de grupo de disponibilidade. Você também pode configurar o Ouvinte e aprender como se conectar ao Availability Group Listener.
O Availability Group Listener consiste nos seguintes objetos
um nome de sistema de nomes de domínio (DNS)
uma porta de Listener
Um ou mais endereços IP (VIPs)
Exemplo:
DNS: salesag.mscorp.com
Puerto: 1433
IP: estática o DHCP
O Ouvinte sempre pertence à instância do SQL Server onde reside a réplica primária. No momento do failover, a réplica secundária será proprietária do listener.
Agora que entendemos o motivo da falha em nosso datacenter, vamos voltar ao assunto da ACI hehehe pois é assim que toda a história se torna um pouco mais emocionante, pois é o que vejo diariamente, vendo o cenário a explicação do Lado ACI Seria que a falha causada no SQL Server é após o failover ser acionado, isso significa que o listener envia um ARP gratuito conforme o esperado, mas o switch folha não mostra nenhum GARP sendo recebido e isso levou a limpeza da tabela ARP e a ativação da inundação unicast L2 e como esperado a falha foi solucionada em primeira instância, lendo vejo que temos outra alternativa e esse é o motivo deste artigo, abaixo explico as alterações a serem feitas na ferramenta ACI, pois Como todos sabemos, a solução foi a limpeza da tabela ARP e a ativação do Flood unicast L2.
Antes
Depois
Estas capturas de pantalla son de un APIC Versión 4.2.
Explicação da nova solução:
O comportamento natural de um ACI Fabric é aprender tudo por meio de pesquisas UDP exclusivas no banco de dados de endpoints localizado nos Spines e, como tal, não há necessidade de transmitir ou inundar um ARP. No entanto, como o Microsoft Windows Failover Clustering (MWFC), temos que aprender com base no GARP. Um GARP (Gratuitous ARP) é usado por dispositivos na rede como uma forma de atualizar proativamente o cache ARP para permitir que outros dispositivos saibam que a localização de um endereço MAC foi alterada. Para que o Fabric aprenda os movimentos dos EPGs através do GARP, precisamos habilitar alguns recursos não padrão no Bridge Domain (BD) associados ao Endpoint Group (EPG), essas funções são "ARP Flooding" e "EP Modo de detecção de movimento " (modo de detecção GARP).
Conclusão
Failover é quando um computador trava inesperadamente ou é desligado deliberadamente, o clustering garante que os processos e serviços em execução sejam movidos para outra máquina, ou seja, "fail over" do cluster. Isso acontece sem interrupção ou a necessidade de intervenção imediata do administrador, fornecendo uma solução altamente disponível, o que significa que os dados críticos estão sempre disponíveis.
O GARP é usado para atualizar endereços IP e MAC em dispositivos de rede. É mais relevante no caso de vmotions ou VM/servidores movendo-se de um host para outro, e o endereço MAC muda, mas o IP permanece o mesmo.
No contexto do ACI Fabric, os switches folha podem detectar o movimento de endereços MAC e IP entre portas de switch folha, domínios de ponte e EPGs (Endpoint Group), mas não detectam a mudança de um endereço IP atribuído para um novo endereço MAC e se o novo endereço MAC estiver associado ao antigo endereço IP da mesma forma se estiver na mesma interface e/ou EPG do antigo endereço MAC.
Ao ativar a opção de detecção baseada em GARP (configuração feita no Domínio Brigde), a Cisco ACI ativará uma alteração nos EPGs com base em pacotes GARP e verificará se ela ocorre na mesma interface e/ou EPG. Se um pacote GARP vier da mesma interface e/ou EPG, o aprendizado EPG será ativado somente quando o Roteamento Unicast, "ARP Flooding" e "GARP" estiverem habilitados no Bridge Domain.
Bom amigos, espero que este post ajude muito e digo que não consegui traduzir algumas palavras por motivos óbvios e espero que compreendam o assunto. Bom começo de semana e deixe seu like se quiser que eu continue escrevendo mais cases sobre o assunto.
Referencia:
