Interoperabilidade de recursos com ouvintes AG e DNN

  • Artigo

Aplica-se a:SQL Server na VM do Azure

Gorjeta

Há muitos métodos para implantar um grupo de disponibilidade. Simplifique sua implantação e elimine a necessidade de um Balanceador de Carga do Azure ou DNN (nome de rede distribuída) para seu grupo de disponibilidade Always On criando suas máquinas virtuais (VMs) do SQL Server em várias sub-redes dentro da mesma rede virtual do Azure. Se você já criou seu grupo de disponibilidade em uma única sub-rede, pode migrá-lo para um ambiente de várias sub-redes.

Há certos recursos do SQL Server que dependem de um nome de rede virtual codificado (VNN). Como tal, ao usar o ouvinte DNN (nome de rede distribuída) com seu grupo de disponibilidade Always On e o SQL Server em VMs do Azure em uma única sub-rede, pode haver algumas considerações adicionais.

Este artigo detalha os recursos do SQL Server e a interoperabilidade com o ouvinte DNN do grupo de disponibilidade.

Diferenças de comportamento

Existem algumas diferenças de comportamento entre a funcionalidade do ouvinte VNN e do ouvinte DNN que são importantes observar:

  • Tempo de failover: o tempo de failover é mais rápido ao usar um ouvinte DNN, pois não há necessidade de esperar que o balanceador de carga de rede detete o evento de falha e altere seu roteamento.
  • Conexões existentes: as conexões feitas com um banco de dados específico dentro de um grupo de disponibilidade de failover fecham, mas outras conexões com a réplica primária permanecem abertas, uma vez que a DNN permanece online durante o processo de failover. Isso é diferente de um ambiente VNN tradicional, onde todas as conexões com a réplica primária normalmente fecham quando o grupo de disponibilidade faz failover, o ouvinte fica offline e a réplica primária transita para a função secundária. Ao usar um ouvinte DNN, talvez seja necessário ajustar as cadeias de conexão do aplicativo para garantir que as conexões sejam redirecionadas para a nova réplica primária após o failover.
  • Transações abertas: abra transações em um banco de dados em um grupo de disponibilidade de failover fechar e reverter e você precisa se reconectar manualmente . Por exemplo, no SQL Server Management Studio, feche a janela de consulta e abra uma nova.

Controladores do cliente

Para drivers ODBC, OLEDB, ADO.NET, JDBC, PHP e Node.js, os usuários precisam especificar explicitamente o nome do ouvinte DNN e a porta como o nome do servidor na cadeia de conexão. Para garantir conectividade rápida após o failover, adicione MultiSubnetFailover=True à cadeia de conexão se o cliente SQL oferecer suporte a ela.

Ferramentas

Os usuários do SQL Server Management Studio, sqlcmd, Azure Data Studio e SQL Server Data Tools precisam especificar explicitamente o nome do ouvinte DNN e a porta como o nome do servidor na cadeia de conexão para se conectar ao ouvinte.

No momento, não há suporte para a criação do ouvinte DNN por meio da GUI do SQL Server Management Studio (SSMS).

Grupos de disponibilidade e FCI

Você pode configurar um grupo de disponibilidade Always On usando uma FCI (instância de cluster de failover) como uma das réplicas. Para que essa configuração funcione com o ouvinte DNN, a instância de cluster de failover também deve usar a DNN, pois não há como colocar o endereço IP virtual FCI na lista de IP DNN AG.

Nessa configuração, a URL do ponto de extremidade de espelhamento para a réplica da FCI precisa usar a DNN da FCI. Da mesma forma, se a FCI for usada como uma réplica somente leitura, o roteamento somente leitura para a réplica FCI precisará usar a DNN da FCI.

O formato do ponto de extremidade de espelhamento é: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Por exemplo, se o nome DNS DNN FCI for dnnlsnr, e 5022 for a porta do ponto de extremidade de espelhamento da FCI, o trecho de código Transact-SQL (T-SQL) para criar a URL do ponto de extremidade terá a seguinte aparência:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

Da mesma forma, o formato para a URL de roteamento somente leitura é: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Por exemplo, se o nome DNS DNN for , e 1444 for dnnlsnra porta usada pela FCI do SQL Server de destino somente leitura, o trecho de código T-SQL para criar a URL de roteamento somente leitura terá a seguinte aparência:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

Você pode omitir a porta na URL se ela for a porta 1433 padrão. Para uma instância nomeada, configure uma porta estática para a instância nomeada e especifique-a na URL de roteamento somente leitura.

Grupo de disponibilidade distribuída

Se o ouvinte do grupo de disponibilidade estiver configurado usando um DNN (nome de rede distribuído), não há suporte para a configuração de um grupo de disponibilidade distribuída sobre o grupo de disponibilidade.

Replicação

A replicação transacional, de mesclagem e de snapshot oferece suporte à substituição do ouvinte VNN pelo ouvinte DNN e porta em objetos de replicação que se conectam ao ouvinte.

Para obter mais informações sobre como usar a replicação com grupos de disponibilidade, consulte Publicador e AG, Assinante e AG e Distribuidor e AG.

MSDTC

Há suporte para MSDTC local e clusterizado, mas o MSDTC usa uma porta dinâmica, que requer um Balanceador de Carga do Azure padrão para configurar a porta HA. Como tal, a VM deve usar uma reserva de IP padrão ou não pode ser exposta à Internet.

Defina duas regras, uma para a porta 135 do Mapeador de Pontos de Extremidade RPC e outra para a porta MSDTC real. Após o failover, modifique a regra LB para a nova porta MSDTC depois que ela for alterada no novo nó.

Se o MSDTC for local, certifique-se de permitir a comunicação de saída.

Consulta distribuída

A consulta distribuída depende de um servidor vinculado, que pode ser configurado usando o ouvinte e a porta AG DNN. Se a porta não for 1433, escolha a opção Usar outra fonte de dados no SQL Server Management Studio (SSMS) ao configurar o servidor vinculado.

FILESTREAM

FILESTREAM é suportado, mas não para cenários em que os usuários acessam o compartilhamento de arquivos com escopo usando a API de Arquivo do Windows.

Tabela de arquivos

FileTable é suportado, mas não para cenários em que os usuários acessam o compartilhamento de arquivos com escopo usando a API de Arquivo do Windows.

Servidores ligados

Configure o servidor vinculado usando o nome e a porta do ouvinte AG DNN. Se a porta não for 1433, escolha a opção Usar outra fonte de dados no SQL Server Management Studio (SSMS) ao configurar o servidor vinculado.

Perguntas mais frequentes

Qual versão do SQL Server oferece suporte ao ouvinte AG DNN?

SQL Server 2019 8 e posterior.

Qual é o tempo de failover esperado quando o ouvinte DNN é usado?

Para o ouvinte DNN, o tempo de failover é o mesmo que o tempo de failover AG, sem qualquer tempo adicional (como o tempo de teste quando você está usando o Azure Load Balancer).

Existe algum requisito de versão para clientes SQL para suportar DNN com OLEDB e ODBC?

Recomendamos o MultiSubnetFailover=True suporte de cadeia de conexão para o ouvinte DNN. Está disponível a partir do SQL Server 2012 (11.x).

São necessárias alterações na configuração do SQL Server para que eu possa usar o ouvinte DNN?

O SQL Server não requer nenhuma alteração de configuração para usar DNN, mas alguns recursos do SQL Server podem exigir mais consideração.

A DNN suporta clusters de várias sub-redes?

Sim. O cluster vincula a DNN no DNS com os endereços IP físicos de todas as réplicas no grupo de disponibilidade, independentemente da sub-rede. O cliente SQL tenta todos os endereços IP do nome DNS, independentemente da sub-rede.

O ouvinte DNN do grupo de disponibilidade suporta roteamento somente leitura?

Sim. O roteamento somente leitura é suportado com o ouvinte DNN.

Conteúdos relacionados