Início / dba / Perguntas / 146620
Accepted
Fza
Asked: 2016-08-13 04:20:35 +0800 CST

Grupos de disponibilidade AlwaysON - endereço IP e alteração de sub-rede do nó de réplica secundária

  • 772

Este é um acompanhamento da pergunta: AlwaysON Availability Groups - alteração do endereço IP do nó de réplica secundária

Mesmo cenário, Grupo de Disponibilidade no modo de confirmação síncrona, uma réplica primária e uma réplica secundária em uma configuração de várias sub-redes. Os nós do cluster são máquinas físicas. Devido à manutenção de hardware, o servidor usado pelo nó do cluster de réplica secundária está sendo movido, portanto, ficará off-line e voltará a ficar on-line com um endereço IP diferente em uma sub -rede diferente . Como alguém abordaria isso?

Meus pensamentos iniciais são: Se possível, adicione a nova interface de rede ao nó secundário. Configure a nova interface de rede com o novo endereço IP que está em uma sub-rede diferente. O cluster deve construir automaticamente as rotas internas e registrar a nova interface de rede.

No FCM (Failover Cluster Manager), uma nova rede de cluster aparecerá na guia 'Redes'. Nos recursos principais do cluster, adicione a nova rede e crie um novo endereço IP estático para o VNN do cluster. Aplique as alterações e, em seguida, volte e adicione uma dependência OR no novo endereço IP.

Antes da interrupção da movimentação do servidor em que o antigo endereço IP/interface de rede será removido, no FCM, volte aos recursos principais do cluster, acesse as propriedades do VNN do cluster e remova o antigo endereço IP de rede/estático e remova quaisquer dependências em isto. Quando o servidor for colocado off-line e voltar a ficar on-line, a interface de rede antiga não ficará visível para o servidor e não aparecerá na guia de redes no FCM. Não deve haver nenhum problema com nenhum recurso em cluster, pois todas as dependências do antigo IP/sub-rede/rede foram removidas.

Há algo mais que deve ser levado em consideração? Como os nós do cluster são físicos, isso complica as coisas em relação às interfaces de rede? Com o teste em um ambiente virtual, é obviamente simplificado, pois é fácil remover e conectar switches de rede virtual.

sql-server availability-groups

1 respostas

  1. Best Answer

    Como alguém abordaria isso?

    Com um monte de trabalho antes da mudança :)

    Meus pensamentos iniciais são: /snipped para brevidade

    Você tem as ideias certas, deixe-me acrescentar mais algumas.

    Pré trabalho

    • O cluster agora é Multisubnet, precisaremos adicionar um IP para o nome do cluster na segunda sub-rede. Isso será adicionado ao recurso de nome do cluster como uma dependência 'OU' conforme você afirmou acima. Isso pode ser adicionado a qualquer momento (eu adicionaria antes da mudança). O cluster CAP agora terá 2 endereços IP, um para cada sub-rede.
    • Regras de firewall, etc.
    • O ouvinte (como você já afirmou) se tornará multi-sub-rede. Outro endereço IP precisará ser adicionado na dependência 'OU'.
    • Verifique novamente a configuração do ponto de acesso do cliente (CAP [também conhecido como VNN, também conhecido como nome da rede]) para: HostRecordTTLe RegisterAllProvidersIPcertifique-se de que eles estão configurados da maneira que você deseja. Observe que você pode querer usar vários ouvintes para facilitar os clientes que usam bibliotecas de conexão mais antigas que não suportam as novas palavras-chave.
    • Decida se deseja remover a réplica do AG (se demorar um pouco para mover fisicamente o servidor) ou apenas pausar o AG. Se o AG for removido, os bancos de dados voltarão ao estado "restaurando..." e você poderá recuperá-los com restaurações posteriormente, depois que o servidor chegar e for configurado.
    • Quorum: Não há muito a dizer aqui, é um cluster de 2 nós com 1 nó obtendo milhas aéreas. Incluído porque abordaremos isso mais tarde e é uma pergunta comum.

    Pós-Trabalho

    • O servidor deve (com um novo IP e regras de firewall adequadas) ser capaz de entrar em contato com o cluster e ingressar.
    • Execute o assistente de validação de cluster. Salve este relatório como o relatório de movimentação inicial. Talvez precisemos examiná-lo mais tarde. Isso também verificará a maioria dos itens relacionados ao cluster e será executado muito rapidamente.
    • Verifique a latência da rede. Defina CrossSubnetDelaye CrossSubnetThresholdapropriadamente para a latência e integridade da conexão. Nenhuma alteração pode ser necessária, mas é bom verificar duas e três vezes.
    • Restaurar logs/diffs/etc de transações.
    • Adicione a réplica de volta ao AG
    • Revisite o Quórum. Mesmo que haja apenas dois nós no cluster, queremos verificar se não estamos usando uma testemunha de disco. Dependendo da versão do Windows, devemos/poderíamos usar uma testemunha de compartilhamento de arquivos ou uma testemunha do Azure.

    Pode haver itens adicionais específicos para o seu ambiente, mas essa deve ser a essência. Você acertou em cheio na sua pergunta/postagem original, isso apenas adiciona um pouco de preenchimento :)

    • 2

relate perguntas