Interoperabilidade de recursos com o AG e o ouvinte DNN

  • Artigo

Aplica-se a:SQL Server na VM do Azure

Dica

Há vários métodos de implantação de um grupo de disponibilidade. Simplifique sua implantação sem precisar usar o Azure Load Balancer ou DNN (nome de rede distribuída) para seu grupo de disponibilidade Always On criando suas VMs (máquinas virtuais) do SQL Server em várias sub-redes dentro da mesma rede virtual do Azure. Se você já tiver criado seu grupo de disponibilidade em uma única sub-rede, poderá migrá-lo para um ambiente de várias sub-redes.

Determinados recursos do SQL Server dependem de um VNN (nome de rede virtual) embutido em código. Dessa forma, se você usar o ouvinte DNN (nome de rede distribuída) com o grupo de disponibilidade Always On e o SQL Server em VMs do Azure em uma só sub-rede, poderá haver algumas considerações adicionais.

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

Diferenças de comportamento

Há algumas diferenças importantes de comportamento entre a funcionalidade do ouvinte VNN e o ouvinte DNN que devem ser observadas:

  • Tempo de failover: o tempo de failover é mais rápido ao usar um ouvinte DNN, pois não há necessidade de aguardar o balanceador de carga de rede detectar o evento de falha e alterar seu roteamento.
  • Conexões existentes: as conexões feitas a um banco de dados específico, dentro de um grupo de disponibilidade de failover serão fechadas, mas outras conexões com a réplica primária permanecerão abertas, pois o DNN permanecerá aberto durante o processo de failover. Isso é diferente de um ambiente de VNN tradicional, em que todas as conexões com a réplica primária normalmente são fechadas quando o grupo de disponibilidade faz o failover, o ouvinte fica offline e a réplica primária faz a transição 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: transações abertas em um banco de dados, em um grupo de disponibilidade, durante um failover, serão fechadas e revertidas, e você precisará se reconectar manualmente. Por exemplo, no SQL Server Management Studio, feche a janela de consulta e abra uma nova.

Drivers de cliente

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

Ferramentas

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

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

Grupos de disponibilidade e FCI

Você pode configurar um grupo de disponibilidade Always On usando uma instância de cluster de failover (FCI) 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 o DNN, pois não há como colocar o endereço IP virtual FCI na lista de IPS do AG DNN.

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

O formato para o 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 criação da URL do ponto de extremidade será semelhante a:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

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

Por exemplo, se o nome DNS do DNN for dnnlsnr e 1444 for a porta usada pelo destino somente leitura da FCI do SQL Server, o trecho de código T-SQL para criação da URL de roteamento somente leitura terá esta aparência:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

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

Grupo de disponibilidade distribuído

Se seu ouvinte do grupo de disponibilidade estiver configurado com um DNN (nome de rede distribuído), não haverá suporte para a configuração de um grupo de disponibilidade distribuído na parte superior do grupo de disponibilidade.

Replicação

Replicação transacional, de mesclagem e de instantâneos, todos dão suporte à substituição do ouvinte VNN com a porta e o ouvinte DNN 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 Publisher e AG, subscriber e AG, e distribuidor e AG.

MSDTC

O MSDTC local e o de cluster são suportados, mas o MSDTC usa uma porta dinâmica, que requer um Azure Load Balancer padrão para configurar a porta de alta disponibilidade. Assim, 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 ponto de extremidade RPC e outra para a porta real do MSDTC. Após o failover, modifique a regra de 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 do 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 tem suporte, 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.

FileTable

FileTable tem suporte, 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 vinculados

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 frequentes

Qual versão SQL Server traz suporte a ouvinte AG DNN?

SQL Server 2019 CU 8 e posteriores.

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

Para o ouvinte DNN, o tempo de failover é o mesmo o tempo de failover da AG, sem nenhum outro tempo adicional (como o tempo de investigação quando você estiver usando Azure Load Balancer).

Há algum requisito de versão para clientes SQL para oferecer suporte a DNN com OLEDB e ODBC?

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

Há alterações de configuração do SQL Server obrigatórias para usar o ouvinte DNN?

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

O DNN oferece suporte a clusters de várias sub-redes?

Sim. O cluster associa o DNN no DNS aos endereços IP físicos de todas as réplicas no grupo de disponibilidade, qualquer que seja a sub-rede. O cliente SQL tenta todos os endereços IP do nome DNS, qualquer que seja a sub-rede.

O ouvinte DNN do grupo de disponibilidade dá suporte ao roteamento somente leitura?

Sim. O roteamento somente leitura tem suporte com o ouvinte DNN.

Conteúdo relacionado