it-swarm.com.de

Verbindung AlwaysOn AG Listener Problem

Ich bin ein Neuling für Microsoft-Technologien und habe Probleme im Konnektivitätsteil für SQL Server 2014. Dies ist wahrscheinlich ein einfaches Problem, aber ich stecke fest.

Ich habe 4 Server. Einer davon ist der Active Directory-Domänencontroller, einer ist der Anwendungsserver und die anderen werden für SQL Server verwendet. Da es sich um ein Konnektivitätsproblem handelt, sind IPs für Server; - AD DC: 10.6.0.100 (auch der DNS-Server) -APP: 10.6.0.110 -SQL 1: 10.6.0.120 -SQL 2: 10.6.0.121

Ich habe erfolgreich einen Failovercluster (DBCLUSTER) erstellt und die IP-Adresse des FC auf 10.6.0.1 (was nicht eine tatsächliche Server-IP ist, ich weiß wirklich nicht 'gesetzt. Ich bekomme diesen Teil nicht ..).

Später habe ich eine AlwaysOn-Verfügbarkeitsgruppe für SQL Server erstellt. Ich habe die AG erfolgreich ohne Listener erstellt. Ich konnte eine Verbindung zu Servern herstellen, die Datenbank wurde problemlos synchronisiert. Dann habe ich einen Listener (AG-LISTENER) erstellt und seine IP als 10.6.0.131 (was nicht eine tatsächliche Server-IP ist , erneut ?) und setzen Sie den Port auf 5525. Es gab keine Probleme.

Also wollte ich die Konnektivität testen. Wenn ich Verbindungen vom APP Server zum direkten SQL 1 oder SQL 2 herstellen wollte, kann ich ohne Probleme verbinden. Aber Wenn ich versuche, eine Verbindung zu AG-LISTENER herzustellen, kann es im Netzwerk nicht gefunden werden. Wenn ich die DNS-Einträge überprüfe. Ich kann es so sehen, wie es auf 10.6.0.131 gehostet wird.

Als ich versuchte, von AD-DC, APP, SQL 2 Servern an AG-LISTENER zu pingen, antwortete ich, dass der Zielhost nicht erreichbar ist (es pingt 10.6.0.131, aber das Die Antwort kommt von den IPs von AD-DC-, APP- und SQL 2-Servern. Es kann eine Verbindung von einem SQL 1-Server hergestellt werden, der der primäre Server für AG ist.

Ich habe die Firewalls überprüft, es gibt kein Problem. Aber ich denke, dies ist ein Netzwerkproblem, von dem ich keine Ahnung habe.

PS: Server arbeiten unter Windows Server 2012 und werden nicht auf Azure gehostet.

LÖSUNG

Ursache des Problems war die Netzwerktopologie des Dienstanbieters. Es wurde festgestellt, dass IPs 10.6.0.0/32 von anderen Servern anderer Kunden verwendet werden können. Also haben sie uns einen weiteren IP-Block zugewiesen, auf den nur wir Zugriff haben, und der hat wie ein Zauber funktioniert.

7
erdimeola

Es kann eine Verbindung vom SQL 1-Server herstellen, der der primäre Server für AG ist.

Meinen Sie mit "verbinden", dass es pingAG-LISTENER Von SQL1 Kann?

Es klingt so, als ob Ihr Problem möglicherweise in der Portnummer liegt, die Sie für Ihren Listener ausgewählt haben. Wenn Sie 5525 auswählen, wählen Sie einen nicht standardmäßigen Port aus (1433 wäre der Standardport).

Wie sieht Ihre Verbindungszeichenfolge aus, wenn Sie versuchen, eine Verbindung zum Listener herzustellen? Ich vermute, es sieht ungefähr so ​​aus:

data source = ag-listener; initial catalog = ...

Sie haben hier zwei Möglichkeiten. Sie können entweder die Portnummer Ihres Listeners explizit angeben:

data source = ag-listener,5525; initial catalog = ...

Wenn Sie dies mit SQL Server Management Studio (SSMS) testen, wird das Dialogfeld Mit Server verbinden angezeigt, anstatt ag-listener Geben Sie für das Textfeld Servernameag-listener,5525 Ein.

Oder Sie können den Port ändern, den Ihr Listener 1433 abhört (lesen Sie die folgende BOL-Referenz, bevor Sie diese Änderung in Betracht ziehen):

alter availability group YourAvailabilityGroupName
modify listener 'AG-LISTENER'
(
    port = 1433
);

Es ist erwähnenswert, wann Sie den Standardport (1433) verwenden können. Schauen Sie sich diese Referenz auf BOL an und erklären Sie, wann Sie 1433 für den Listener verwenden können und wann nicht (Auszugskopie/unten als Referenz eingefügt):

Sie können den Standardport auf 1433 konfigurieren, um die Clientverbindungszeichenfolgen zu vereinfachen. Wenn Sie 1433 verwenden, müssen Sie keine Portnummer in einer Verbindungszeichenfolge angeben. Da jeder Verfügbarkeitsgruppen-Listener einen separaten virtuellen Netzwerknamen hat Jeder Verfügbarkeitsgruppen-Listener, der auf einer einzelnen WSFC konfiguriert ist, kann so konfiguriert werden, dass er auf denselben Standardport von 1433 verweist.

(Teile der Kürze halber weggelassen)

Wenn Sie den Standardport 1433 für Verfügbarkeitsgruppen-Listener-VNNs verwenden, müssen Sie weiterhin sicherstellen, dass keine anderen Dienste auf dem Clusterknoten diesen Port verwenden . ;; Andernfalls würde dies zu einem Portkonflikt führen.

[~ # ~] edit [~ # ~] : Wenn das oben genannte nicht Ihr Problem ist (wie aus Ihrem Kommentar unten hervorgeht), dann nach Ihnen Wenn Sie die Protokolle durchsehen, würde ich sagen, dass die nächstbeste Vorgehensweise darin besteht, den Netzwerkverkehr zu untersuchen, um zu sehen, was passiert (und was nicht). Sie können dazu ein Netzwerküberwachungstool wie netmon verwenden.

Eine andere Sache, die ich tun würde, und mir ist klar, dass Sie gesagt haben, die Firewall sei kein Problem, aber ich würde sehen, ob der Port tatsächlich lauscht (mein Lieblingswerkzeug dafür ist portqry ).

5
Thomas Stringer