Tedious: Multisubnetfailover-Unterstützung für mühsame

Erstellt am 23. Mai 2016  ·  20Kommentare  ·  Quelle: tediousjs/tedious

Hallo,
Ich bin neu bei Node js und habe vor kurzem eine Anwendung gestartet, um einen Webdienst für die MSSQL-Datenbank zu entwickeln.
Ich verwende einen mühsamen Treiber, um eine Verbindung zur Datenbank herzustellen. Ich habe erfahren, dass die Multisubnetfailover-Funktion in mühsam, aber noch nicht in Master zusammengeführt unterstützt wird.
Darf ich wissen, bis wann diese Änderung im Master eingereicht werden kann?
Gibt es eine Möglichkeit, die Multisubnetfailover-Option zu testen, indem ich über npm von einer Filiale aus installiere, in der sie entwickelt wurde?

Vielen Dank im Voraus.

Follow up discussion

Hilfreichster Kommentar

@mrinalmonga Ich habe die von Ihnen verlinkte SQLServer-Dokumentation sowie die Dokumentation zu dns.lookup und dns.resolve4 / dns.resolve6 und ihren Unterschieden gelesen, und ich denke, die Implementierung in tedious ist richtig.

Wenn ich das richtig verstehe, werden alle IP-Adressen (ob aktiv oder nicht) für den DNS-Namen des Clusters registriert, wenn RegisterAllProvidersIP auf 1 , was standardmäßig für Cluster-Setups sein sollte . Beim Nachschlagen des Namens über dns.lookup wird die erste IP-Adresse aus der Liste der registrierten Adressen zurückgegeben. Dies sehen Sie, wenn Sie dns.lookup oder nslookup aufrufen. Die Reihenfolge der IPs kann sich ändern, und dies wird normalerweise auf Systemebene zwischengespeichert, und deshalb sehen Sie, dass nslookup das Ergebnis von dns.lookup kann und umgekehrt.

Aber in tedious ist dies nicht das, was wir tun - wir rufen dns.lookup mit der all: true Option auf - dies gibt alle IP-Adressen zurück, die für den angegebenen Hostnamen registriert sind , und dann versuchen wir, diese parallel (wenn multisubnetfailover: true gesetzt ist) oder nacheinander zu verbinden.

Tatsächlich spielt es keine Rolle, dass wir dns.lookup (das die DNS-Auflösungsfunktion des Betriebssystems verwendet) anstelle von dns.resolve4/6 , da wir immer noch die Rückgabe aller IP-Adressen anfordern und versuchen, eine Verbindung zu ihnen herzustellen . Ich würde sogar argumentieren, dass die direkte Verwendung von dns.resolve4/6 nicht intuitiv wäre, da wir plötzlich die Konfiguration des Betriebssystems nicht berücksichtigen würden (und z. B. über /etc/hosts Dateien und ähnliches überschreiben).

Ich hoffe, diese Erklärung macht Sinn. 🙇

@IanChokS @MichaelSun90 können Sie dies mit dem SQL Server-Team und/oder mit den anderen Client-Treibern überprüfen?

Alle 20 Kommentare

Siehe #362
Als ich diese PR getestet habe, bekomme ich leider immer noch gelegentliche Auszeiten. Sie können diesen PR testen, indem Sie ihn direkt in Ihre node_modules holen oder Shrinkwrap verwenden

@arthurschreiber und @tvrprasad arbeiten daran, die Probleme von #362 zu beheben (#346 wurde zusammengelegt). Haben Sie die neueste PR ausprobiert, @pradeep250 ?

Gibt es dazu ein Update? Ich habe es mit der neuesten Version des mssql-Pakets (v 4.3.0) versucht, das mühsame Treiber verwendet, und ich kann keine Verbindung zu einem geclusterten SQL Server herstellen. Zeitüberschreitung bei Verbindungsanfrage.

Ich verwende die langweilige 6.4.1, stehe aber immer noch vor dem gleichen Problem. Irgendwelche Updates?

Hallo @prashant19sep , ich habe gerade überprüft, ob das Feature seit dem 10. März 2017 zusammengeführt und als langweilige Version 1.15.0 veröffentlicht wurde. Die Funktion ist noch in der neuesten Version von mühsam. Um es zu verwenden, können Sie eine Option namens "multiSubnetFailover" unter config.options setzen, um diese Funktion zu aktivieren. Kannst du es versuchen und sehen, ob das funktioniert?

var config = {
options.multiSubnetFailover=true;
}

Wir haben festgestellt, dass options.multiSubnetFailover=true nicht funktioniert.. immer noch keine Verbindung zum SQL-Cluster herstellt.. Musste das Problem umgehen

Hallo @prashant19sep , ich habe gerade überprüft, ob das Feature seit dem 10. März 2017 zusammengeführt und als langweilige Version 1.15.0 veröffentlicht wurde. Die Funktion ist noch in der neuesten Version von mühsam. Um es zu verwenden, können Sie eine Option namens "multiSubnetFailover" unter config.options setzen, um diese Funktion zu aktivieren. Kannst du es versuchen und sehen, ob das funktioniert?

var config = {
options.multiSubnetFailover=true;
}

Bei mir hat es jetzt funktioniert. Ich habe das Flag direkt hinzugefügt und nicht mit "Optionen".

Die Sache ist, dass das Modul "dns" (von mühsamen js verwendet) des Knotens (https://nodejs.org/api/dns.html) die Methoden "lookup", "resolve4" und "resolve6" hat. Es gibt viele Unterschiede zwischen "lookup" und den Methoden "resolve4", "resolve6".

Die "lookup"-Methode von "dns" führt NICHT unbedingt eine DNS-Suche durch (wie man angesichts des Namens der Methode denken könnte).

Da mühsames js dns.lookup verwendet, unterstützt es Multisubnet-Failover nicht ordnungsgemäß 100-mal.

Ich habe ein Experiment auf meiner Maschine durchgeführt. Die Ergebnisse lassen sich wie folgt zusammenfassen:

Angenommen, es gibt einen Cluster "xyz.abc.com", der in 2 IP-Adressen aufgelöst wird (1)und 2). Nehmen Sie außerdem an, dass nur eine der IP-Adressen aktiv ist und die andere NICHT aktiv ist. Als ich dann die Methode "dns.lookup" ein paar Mal ausführte, gab sie mir (sagen wir), dann, als ich das Terminal / die Eingabeaufforderung des Betriebssystems öffnete und explizit eine DNS-Suche mit den entsprechenden Befehlen ('nslookup'-Befehl) für "xyz.abc.com" durchführte, stellte ich fest, dass danach die Methode dns.lookup gestartet wurde gibt miranstatt.

Fazit - Wie in der DNS- Dokumentation für die Lookup-Methode angegeben, _"führen Sie nicht unbedingt eine Netzwerkkommunikation durch"_ . Dies ist ein totes Zeichen dafür, dass es falsch ist, diese Methode in langweiligem js-Code zu verwenden. Siehe Github https://github.com/tediousjs/tedious/search?q=dns.lookup&unscoped_q=dns.lookup

LÖSUNG -

Wir haben eine einfache Lösung entwickelt, die der Empfehlung der Microsoft-Empfehlung entspricht (siehe Diagramm auf https://docs.microsoft.com/en-us/sql/sql-server/failover-clusters/windows/sql-server -multi-subnet-clustering-sql-server?view=sql-server-2017)

(1) VERWENDEN SIE dns.resolve4 oder dns.resolve6, anstatt dns.lookup des "dns"-Moduls für den "host" zu verwenden
(2) Sie erhalten eine Liste aller IP-Adressen, die dem "Host" entsprechen.
(3) Probieren Sie alle registrierten IPs aus, die mit der Methode dns.resolve4 erhalten wurden (die tatsächlich eine DNS-Suche über das Netzwerk durchführt, im Gegensatz zu dns.lookup, die dies nicht tut und immer noch von mühsamen js verwendet wird)
(4) Verbinden bei der ersten Antwort .

HINWEIS -

(1) Überraschenderweise haben wir keine Leistungseinbußen festgestellt, wenn eine tatsächliche DNS-Suche über das Netzwerk mit dns.resolve4 statt mit dns.lookup durchgeführt wird (was NICHT unbedingt eine tatsächliche DNS-Suche über das Netzwerk durchführt).

(2) Die Implementierung von mühsamem js muss aktualisiert werden. Wir haben KEINEN Verweis auf die Methode "resolv4" oder "resolv6" in der Codebasis von mühsamen js gefunden (zum Zeitpunkt des Schreibens dieses Kommentars).
Bitte beachten Sie den Link https://github.com/tediousjs/tedious/search?q=dns.resolve&unscoped_q=dns.resolve als BEWEIS

@mrinalmonga Vielen Dank für die sehr ausführliche Beschreibung! Ich werde versuchen, den Code mühsam zu aktualisieren, um dns.lookup , basierend auf den von Ihnen bereitgestellten Recherchen! ️

@mrinalmonga Ich habe die von Ihnen verlinkte SQLServer-Dokumentation sowie die Dokumentation zu dns.lookup und dns.resolve4 / dns.resolve6 und ihren Unterschieden gelesen, und ich denke, die Implementierung in tedious ist richtig.

Wenn ich das richtig verstehe, werden alle IP-Adressen (ob aktiv oder nicht) für den DNS-Namen des Clusters registriert, wenn RegisterAllProvidersIP auf 1 , was standardmäßig für Cluster-Setups sein sollte . Beim Nachschlagen des Namens über dns.lookup wird die erste IP-Adresse aus der Liste der registrierten Adressen zurückgegeben. Dies sehen Sie, wenn Sie dns.lookup oder nslookup aufrufen. Die Reihenfolge der IPs kann sich ändern, und dies wird normalerweise auf Systemebene zwischengespeichert, und deshalb sehen Sie, dass nslookup das Ergebnis von dns.lookup kann und umgekehrt.

Aber in tedious ist dies nicht das, was wir tun - wir rufen dns.lookup mit der all: true Option auf - dies gibt alle IP-Adressen zurück, die für den angegebenen Hostnamen registriert sind , und dann versuchen wir, diese parallel (wenn multisubnetfailover: true gesetzt ist) oder nacheinander zu verbinden.

Tatsächlich spielt es keine Rolle, dass wir dns.lookup (das die DNS-Auflösungsfunktion des Betriebssystems verwendet) anstelle von dns.resolve4/6 , da wir immer noch die Rückgabe aller IP-Adressen anfordern und versuchen, eine Verbindung zu ihnen herzustellen . Ich würde sogar argumentieren, dass die direkte Verwendung von dns.resolve4/6 nicht intuitiv wäre, da wir plötzlich die Konfiguration des Betriebssystems nicht berücksichtigen würden (und z. B. über /etc/hosts Dateien und ähnliches überschreiben).

Ich hoffe, diese Erklärung macht Sinn. 🙇

@IanChokS @MichaelSun90 können Sie dies mit dem SQL Server-Team und/oder mit den anderen Client-Treibern überprüfen?

Hallo @arthurschreiber , gerade mit dem OLEDB-Fahrerteam besprochen, sie entlocken denen das gleiche Verhalten wie langweilig

Dies gibt alle IP-Adressen zurück, die für den angegebenen Hostnamen registriert sind, und dann versuchen wir, uns parallel (wenn multisubnetfailover: true gesetzt ist) oder nacheinander mit diesen zu verbinden.

Hallo @arthurschreiber

  1. Zum Zeitpunkt der Veröffentlichung des Kommentars haben wir versucht, das Multisubnetfailover: true zu verwenden, aber es hat nicht funktioniert. Wir haben es sowohl auf Windows-Rechnern als auch auf Linux ausprobiert. Da es nicht funktionierte, mussten wir eine andere Lösung finden.

  2. Ich denke, der Zweck von Ökosystemen wie Node Js und Paketen, die in diesem Ökosystem bereitgestellt werden, besteht darin, dass sie als Abstraktionen fungieren. Diese Pakete und Node Js abstrahieren niedrigere Details wie das Betriebssystem , den verwendeten Prozessor, seine Architektur vom Entwickler, der das Paket verwendet.

Wenn das nicht der Fall wäre, warum dann überhaupt? Die Verwendung der Abstraktion empfiehlt, dass der Entwickler, der die Abstraktion verwendet, die inneren Implementierungsdetails einer Methode nicht kennen muss.

  1. Ich denke, dass die Verwendung von dns.resolve4/6 besser ist, da der Code direkt mit der Quelle der Wahrheit für die Domänennamenauflösung kommuniziert und immer die neuesten Informationen erhält.

@mrinalmonga Die Verwendung von dns.resolv4 / dns.resolv6 würde der Funktionsweise aller anderen integrierten Funktionen in Node.js widersprechen, z. B. http , https und sogar net einfach dns.lookup . Sie können dies hier sehen: https://github.com/nodejs/node/blob/4bec6d13f9e9068fba778d0c806a2ca1335c8180/lib/net.js#L1037

Langfristig könnten wir Benutzern ermöglichen, ihre eigene lookup Funktionalität bereitzustellen, damit sie jede Art von Suche durchführen können, die sie für richtig halten. Dies ist auch etwas, was Node.js tut, siehe die Option lookup auf net.connect : https://nodejs.org/api/net.html#net_socket_connect_options_connectlistener

@mrinalmonga Wäre eine solche Option für Ihren Anwendungsfall zufriedenstellend?


@mrinalmonga Würde es Ihnen etwas ausmachen, noch einmal zu überprüfen, ob Multisubnet-Failover für Sie mit einer aktuellen Version von tedious sofort einsatzbereit ist? Ich bin mir ziemlich sicher, dass es funktioniert, würde es aber gerne noch einmal überprüfen und sicherstellen, dass es wirklich funktioniert. 🙇

@IanChokS @MichaelSun90 Haben Sie Zugriff auf eine Testumgebung, die mit Multisubnet-Failover-Funktionalität eingerichtet ist?

Derzeit tun wir es nicht, aber ich kann versuchen, es zu untersuchen.

Ich hatte das ähnliche Problem beim Herstellen einer Verbindung zu MSSQL-Multisubnet-Failover-Datenbankinstanzen von der Knoten-App, das durch die folgenden Änderungen behoben wurde

let config = {
          userName: username,
          password: password,
          server: host,
          options: {
            port: conn.config.port,
            database: conn.config.database,
            multiSubnetFailover:true
          }
        };
var connection = new Connection(config);

Hallo @prashant19sep , ich habe gerade überprüft, ob das Feature seit dem 10. März 2017 zusammengeführt und als langweilige Version 1.15.0 veröffentlicht wurde. Die Funktion ist noch in der neuesten Version von mühsam. Um es zu verwenden, können Sie eine Option namens "multiSubnetFailover" unter config.options setzen, um diese Funktion zu aktivieren. Kannst du es versuchen und sehen, ob das funktioniert?

var config = {
options.multiSubnetFailover=true;
}
Danke, es hat funktioniert

@mrinalmonga @Jindam @arthurschreiber , @MichaelSun90 und ich sind dabei, eine Testumgebung zu erstellen, um dies zu testen und alle Probleme damit zu beheben.


@mrinalmonga was ist deine Konfiguration? Beachte, in der Konfiguration ist es multiSubnetFailover (mit Kameltasche) nicht multisubnetfailover

@arthurschreiber @mrinalmonga Nach dem Testen glaube ich, dass das multiSubnetFailover so funktioniert, wie es sollte.

Bei "multiSubnetFailover": false, können Sie sehen, dass der Client nacheinander einen Ping für jede IP-Adresse sendet.

image

Aber wenn "multiSubnetFailover": true, , wird die IP-Adresse parallel gepingt.

image


@YogeshPD , um eine Verbindung zum Sql-Server mit verschiedenen IP-Adressen herzustellen, musste ich die TCP-Portnummer für jede IP-Adresse im Sql Server Configuration Manager manuell angeben. Ich bin mir jedoch nicht sicher, ob dies das gleiche Setup wie bei dir ist

Schließung vorerst. Fühlen Sie sich frei, erneut zu öffnen, wenn dieses Problem weiterhin besteht.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen