Partilhar via

Interoperabilidade de funcionalidades com ouvintes AG e DNN

Aplica-se a:SQL Server em VM do Azure

Sugestão

Há muitos métodos para configurar 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, poderá migrá-lo para um ambiente de várias sub-redes.

Certas funcionalidades do SQL Server dependem de um nome de rede virtual (VNN) codificado fixamente. Quando usa o ouvinte de nome de rede distribuída (DNN) com o seu grupo de disponibilidade Always On e o SQL Server em VMs Azure numa única subrede, pode encontrar algumas limitações.

Este artigo descreve as funcionalidades do SQL Server e a interoperabilidade com o ouvinte DNN do grupo de disponibilidade.

Diferenças de comportamento

Note as seguintes diferenças entre a funcionalidade do ouvinte VNN e do ouvinte DNN:

  • Tempo de failover: O tempo de failover é mais rápido quando se usa um ouvinte DNN, pois não há necessidade de esperar que o balanceador de carga de rede detete o evento de falha e altere o seu encaminhamento.
  • Ligações existentes: As ligações a uma base de dados específica dentro de um grupo de disponibilidade de failing-over fecham-se, mas outras ligações à réplica primária permanecem abertas, uma vez que a DNN permanece online durante o processo de failover. Este comportamento é diferente de um ambiente VNN tradicional, onde todas as ligações à 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 o papel secundário. Quando usa um ouvinte DNN, pode ser necessário ajustar as cadeias de ligação da aplicação para garantir que as ligações são redirecionadas para a nova réplica primária durante o failover.
  • Transações abertas: As transações abertas num banco de dados num grupo de disponibilidade em failover são fechadas e revertidas, e você precisa reconectar-se manualmente. Por exemplo, no SQL Server Management Studio, feche a janela de consulta e abra uma nova.

Drivers de cliente

Para drivers de ODBC, OLEDB, ADO.NET, JDBC, PHP e Node.js, especifique o nome do ouvinte DNN e a porta como o nome do servidor na string 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.

Tools

Os utilizadores do SQL Server Management Studio, sqlcmd e SQL Server Data Tools precisam de especificar o nome do ouvinte DNN e a porta como nome do servidor na string de ligação para se ligarem ao ouvinte.

Criar o ouvinte DNN usando a interface gráfica do SQL Server Management Studio (SSMS) não é atualmente suportado.

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 esta configuração funcione com o ouvinte DNN, a instância de cluster de failover também deve usar a DNN, uma vez que não é possível inserir o endereço IP virtual do FCI na lista de IPs do DNN da 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 utilizada como uma réplica apenas para leitura, o encaminhamento de leitura para a réplica FCI deverá usar o 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 de leitura é: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Por exemplo, se o nome DNS DNN for dnnlsnr, e 1444 for a 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'

Podes omitir a porta na URL se for a porta padrão 1433. Para uma instância nomeada, configure uma porta estática para essa instância e especifique-a na URL de rota de leitura apenas.

Grupo de disponibilidade distribuída

Se configurar o ouvinte do seu grupo de disponibilidade usando um nome de rede distribuída (DNN), não pode configurar um grupo de disponibilidade distribuído por cima do seu grupo de disponibilidade.

Replication

A replicação transacional, de mesclagem e de snapshot suporta a substituição do ouvinte VNN pelo ouvinte DNN e a utilização da porta em objetos de replicação que se conectam ao serviço de escuta.

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

Tanto o MSDTC local como o clusterizado são suportados, mas o MSDTC utiliza uma porta dinâmica. Esta porta dinâmica requer um Azure Load Balancer padrão para configurar a porta HA. Assim, a VM deve usar uma reserva IP padrão, caso contrário não pode expô-la à internet.

Defina duas regras: uma para a porta 135 do RPC Endpoint Mapper e outra para a porta real do MSDTC. Após o failover, modifique a regra do balanceador de carga 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 baseia-se num servidor ligado, que pode configurar com o AG DNN listener e a porta. 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 utilizadores acedem à partilha de ficheiros com âmbito usando a API de Ficheiro do Windows.

FileTable

FileTable é suportado, mas não para cenários em que os utilizadores acedem ao compartilhamento de ficheiros definido usando a API de Ficheiro do Windows.

Servidores vinculados

Configure o servidor ligado com o nome do ouvinte AG DNN e a porta. 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 do SQL Server suporta o ouvinte AG DNN?

SQL Server 2019 CU 8 e versões posteriores.

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

Para o ouvinte DNN, o tempo de failover é o mesmo do tempo de failover do AG, sem tempo extra (como o tempo de sonda quando se usa o Azure Load Balancer).

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

Utilize a MultiSubnetFailover=True cadeia de ligação para suporte ao 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?

Yes. O cluster associa o 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?

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

Conteúdo relacionado

  • Last updated on