Private DNS Azure mit mehreren IPs auf einem Eintrag funktioniert nicht, wie ich erwartet hatte

Private DNS Azure mit mehreren IPs auf einem Eintrag funktioniert nicht, wie ich erwartet hatte

Ich hoffe, Sie können helfen. Vielen Dank im Voraus.

Ich habe einen Azure Private DNS auf Azure, der mit 4 Vnets in 2 Regionen verbunden ist. Ich habe gelesen, dass ich 2 IPs in einen einzigen A-Eintrag einfügen kann (Beispiel: A-Eintragname sql.midomain.local IP1 192.168.1.1 / 192.168.2.1).

Ich hatte erwartet, dass ein Client, wenn VM IP1 ausgeschaltet ist, auf IP2 aufgelöst werden könnte, aber das ist nicht passiert. Wenn ich einen Ping für „sql.domain.local“ ausführe, wird immer IP1 aufgelöst, obwohl diese VM ausgeschaltet ist.

Ich brauche dies, weil ich mehr Ausfallsicherheit brauche, wenn die Instanz SQL1 in Region 1 AUS ist, der Client aber trotzdem eine Verbindung zur replizierten VM in Region 2 herstellt. Der interne Load Balancer auf Azure unterstützt dies, aber ich möchte meinen SQLs keine öffentliche IP zuweisen, um den externen Load Balancer zu verwenden.

Irgendwelche Ideen, wie ich das erreichen kann?

PD: Es ist wichtig zu wissen, dass alle VNets sich gegenseitig über VNet-Peering erreichen können. Ich kann jede VM in jedem VNet erreichen.

Antwort1

Ich habe gelesen, dass ich 2 IPs in einen einzigen A-Eintrag einfügen kann

Nein, Sie können mehrere A-Einträge (oder CNAME-, TXT-, MX-Einträge) mit demselben Namen und unterschiedlichen Werten erstellen.

Ich hatte erwartet, dass ein Client IP2 auflösen könnte, wenn VM IP1 ausgeschaltet ist, aber das ist nicht passiert. Wenn ich einen Ping für "sql.domain.local" ausführe, wird immer IP1 aufgelöst, obwohl diese VM ausgeschaltet ist.

Wenn für einen bestimmten Namen mehrere Adressen angegeben werden,sollenProbieren Sie sie nacheinander aus. Dies wird beschrieben inRFC 1794. Ping ist ein einfaches Diagnosetool. Ich müsste einiges an Recherche betreiben, um festzustellen, ob das Verhalten hier Absicht ist, anachronistisch oder einfach nur fehlerhaft.

Browser funktionieren sehr unterschiedlich - Round Robin DNS (rrDNS) ist ein sehr effektives Tool zur Unterstützung der Hochverfügbarkeit für HTTP[s]-Dienste. Aber das liegt daran, dass sie die Fehlererkennung mit implementierenvielkürzere Timeouts (<1 Sekunde) als andere TCP-Clients. Die Standard-TCP-Konfigurationen der meisten Betriebssysteme haben ein Timeout für die Fehlererkennung von 5 Minuten oder mehr. Dies setzt auch voraus, dass der TCP-Client ordnungsgemäß RFC-kompatibel ist. Meiner Erfahrung nach verarbeitet Java (oder möglicherweise der auf Java ausgeführte Anwendungscode) die DNS-Auflösung nicht wie erwartet.

Eine teure Alternative zur Bereitstellung von HA-Zugriff für externe Clients ist TCP-Multipathing. Bei IME mit 2 verschiedenen Anbietern dauerte die Failover-Erkennung/Umschaltung mindestens 3 Minuten und erfolgte manchmal überhaupt nicht.

Obwohl es eine großartige Lösung ist, um externen Clients eine hohe Verfügbarkeit zu bieten, würde ich rrDNS nicht verwenden, um für Verbindungen zwischen Knoten innerhalb einer bestimmten Infrastruktur eine hohe Verfügbarkeit zu gewährleisten.

aber ich möchte keine öffentliche IP auf meinen SQLs einrichten, um External Load Balance zu nutzen

Es ist sinnvoll, Ihre DBMS-Server nicht über eine öffentliche Adresse verfügbar zu machen. Das bedeutet nicht, dass Sie sie nicht über andere Wege verbinden können. Wenn Sie Transaktionsdaten auf Ihrem DBMS haben, dann müssen Sie wirklichWIRKLICHSie müssen in der Lage sein, die Kommunikation zwischen den Datenbankknoten sicherzustellen. Wenn dies über VNet-Peering möglich ist und Ihre Anwendung keine integrierte HA-Client-Funktion unterstützt, sehen Sie sich Haproxy oder ProxySQL an.

Andererseits stellen Sie möglicherweise fest, dass Ihre Anwendung etwas empfindlich auf Latenz zwischen dem Anwendungsserver und dem DBMS reagiert (z. B. bei Verwendung von trivialem ORM). In diesem Fall ist es NICHT wünschenswert, einem Anwendungsserver an Standort „A“ die Verbindung zu einem DBMS an Standort „B“ zu ermöglichen. Hier kann rrDNS zu isolierten Stapeln das Problem teilweise lösen, aber Sie müssen auch über Sitzungsverwaltung und Datenreplikation während des Failovers/Failbacks nachdenken.

Antwort2

Wenn ich einen Ping für „sql.domain.local“ mache, wird immer IP1 zurückgegeben, obwohl diese VM ausgeschaltet ist.

Dies ist natürlich, da das Betriebssystem die aufgelöste IP-Adresse für die vom DNS-Server angegebene TTL-Zeit zwischenspeichert.

DNS verfügt über einen Round-Robin-Mechanismus, der die Antwort jedes Mal rotiert, wenn ein Client direkt von diesem Server eine Anfrage stellt. Er wurde jedoch nicht für Failover-Szenarien wie Ihres entwickelt. Ich kenne Ihre Umgebung nicht, aber im Allgemeinen würde ich zur Verwendung eines Reverse-Proxys raten.

verwandte Informationen