Fundo:
Para manter as coisas simples, temos um cluster de 2 nós onde cada nó no cluster tem 3 instâncias do SQL instaladas: padrão + 2 nomeadas. Entendo que o empilhamento de instâncias é ruim e é algo do qual estamos nos afastando ativamente. 2/3 desses nós mencionados utilizam SQL Server AGs (padrão e 1 instância nomeada), enquanto o outro utiliza FCI para DR (esta última instância realmente não pertence à questão, mas adicioná-la de qualquer maneira). Todos os nossos ouvintes utilizam a porta 1433 porque a Microsoft recomendou essa abordagem anos atrás durante uma migração, pois adicionar uma porta não padrão exigiria a inclusão do número da porta no nome do ouvinte durante a conexão. em retrospectiva, não sei por que não seria possível simplesmente incluir a porta no ouvinte AG na criação, pois ela é ofuscada para o aplicativo por meio do CNAME. acredito que não
Pergunta:
No exemplo abaixo, quando a instância padrão do SQL é configurada em uma porta não padrão (por exemplo, 1400), todos os aplicativos se conectam conforme o esperado. No entanto, quando a porta padrão está sendo usada, todos os CNAMES roteiam inesperadamente para 1433 (supondo que seja porque o próprio ouvinte está na porta 1433). O que estou tentando determinar é quando um usuário tenta se conectar a 1433, mas não existe, o navegador identifica que não existe nenhuma instância com a porta 1433 e, portanto, faz algum tipo de lógica secundária de verificação/resolução para correlacionar o nome de o próprio ouvinte com a instância adequada do SQL?
Encontrei outro documento da Microsoft que explica esse cenário, mas não explica como o SQL é capaz de relacionar um VNN de ouvinte com a própria instância. Parece-me que o recurso WSFC relaciona essas informações ao cliente para determinar qual ouvinte roteia para qual instância. No entanto, se houver uma instância em 1433, o SQL roteará tudo incorretamente para essa instância, assumindo que todos os ouvintes estão configurados em 1433 por qualquer motivo.
"Porta do ouvinte Ao configurar um ouvinte do grupo de disponibilidade, você deve designar uma porta via SSMS. Você pode configurar a porta padrão como 1433 para permitir a simplicidade das cadeias de conexão do cliente. Isso significa que, se você usar 1433, não Não é necessário incluir um número de porta em uma cadeia de conexão do seu aplicativo. Além disso, como cada ouvinte de grupo de disponibilidade terá um nome de rede virtual separado, cada ouvinte de grupo de disponibilidade configurado em um único WSFC pode ser configurado para referenciar a mesma porta padrão de 1433 .
Se você usar a porta padrão de 1433 para VNNs de ouvinte de grupo de disponibilidade, ainda precisará garantir que nenhum outro serviço no nó do cluster esteja usando essa porta; caso contrário, isso causaria um conflito de porta.
Se uma das instâncias do SQL Server já estiver escutando na porta TCP 1433 por meio do ouvinte de instância e não houver outros serviços (incluindo instâncias adicionais do SQL Server) no computador escutando na porta 1433, isso não causará um conflito de porta com o ouvinte do grupo de disponibilidade. Isso ocorre porque o ouvinte do grupo de disponibilidade pode compartilhar a mesma porta TCP dentro do mesmo processo. No entanto, várias instâncias do SQL Server (lado a lado) não devem ser configuradas para escutar na mesma porta porque uma delas falhará ao escutar as conexões.
Você também pode designar uma porta de ouvinte de grupo de disponibilidade não padrão. No entanto, você também precisa usar explicitamente a porta de destino na cadeia de conexão do aplicativo ao se conectar a um ouvinte. Você também precisa abrir permissão no firewall para esta porta.
Você pode se conectar ao ouvinte usando o nome e a porta (se não for 1433). A porta pode ser a porta do ouvinte ou a porta subjacente do SQL Server na qual está configurada para escutar." - https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability -group-listener-overview?view=sql-server-ver16
O SQL Browser não interage, de forma alguma, com os Grupos de Disponibilidade. Período.
Isso está correto, uma porta não padrão com um Grupo de Disponibilidade exigirá o uso de números de porta.
Resposta à resposta do OP
Você está incorreto.
Isso é falso, nenhum outro item pode estar na mesma combinação de IP e porta. Isso é fundamentos básicos de rede. Você pode usar diferentes endereços IP e a mesma porta (veja abaixo, por exemplo).
Não é assim que funciona. Primeiro, ocorrerá um erro se a mesma combinação de IP/Porta for tentada para ser vinculada. No SQL Server, isso geralmente gerará o erro 10013:
An attempt was made to access a socket in a way forbidden by its access permissions.Em segundo lugar, como a tentativa de ligação falhará, o que ou quem estiver ouvindo nessa combinação IP/porta exclusiva ainda terá a ligação, portanto, quaisquer conexões que a usem continuarão a usá-la.Não existe "precedência" de portas, AG, SQL ou não. Funciona como expliquei acima.
o atrito
Tudo isso se resume a rede básica e configuração adequada.
Na captura de tela abaixo, você pode ver que há 3 instâncias empilhadas no mesmo servidor, todas com um ouvinte em 1433, todas conectadas corretamente.
Isso requer que você configure a rede do SQL Server corretamente e há várias maneiras de fazer isso. Uma opção é fornecer vários endereços IP à interface de rede ou criar uma interface de rede por instância. Outra maneira é dizer ao SQL Server para parar de escutar em TODOS os IPs e escutar apenas em alguns . Para mostrar uma melhor configuração do SQL Server e porque você precisaria fazer com a primeira opção, configurei dessa forma.
Observe que desativei o listen all e habilitei apenas os IPs específicos que desejo. Isso remove a escuta em IP ANY, que interrompe a tentativa de ligação à porta do ouvinte para cada AG em todos os IPs. Como não há mais
0.0.0.0:1433vinculação, não há conflito, pois cada instância possui uma combinação única de IP:Porta, incluindo o ouvinte.Para reiterar todo o cerne das várias perguntas do OP, o SQL Browser não funciona com AGs. Os CNAMEs não têm ligação nem nada a ver com portas. As combinações IP:Port devem ser únicas, não há nenhuma mágica de duplicação de porta acontecendo (embora você possa criar um duplicador e redirecionador de soquete, mas isso está fora do escopo).
Acredito que fiz pesquisas suficientes para entender melhor o que está acontecendo, então estou postando minha resposta aqui na esperança de que ela beneficie outras pessoas. Se eu estiver incorreto, por favor me avise e eu editarei minha resposta.
Como afirmou Sean, ao conectar-se a um AG por meio de um ouvinte, o navegador SQL é irrelevante. Quando você tem uma configuração que envolve várias instâncias SQL na mesma máquina e os ouvintes estão configurados para serem executados na porta 1433, é imperativoque não há nenhum outro serviço escutando na porta 1433 (por exemplo, uma instância padrão do SQL). Se uma instância padrão do SQL estiver habilitada e o cliente estiver fazendo uma conexão com um ouvinte que usa a porta 1433, ocorrerá um conflito de porta, pois o cliente navegará para o host primário (IP do ouvinte AG) e roteará imediatamente para 1433 ( instância padrão do SQL), já que a porta SQL Service tem precedência sobre a porta do ouvinte AG. Quando a instância padrão do SQL é alterada para uma porta diferente de 1433, o cliente que faz a conexão mais uma vez se conecta ao IP do ouvinte e, em seguida, usando o endereço IP TCP + porta TCP exclusivo, é capaz de rotear corretamente para a instância correta de SQL.