Windows-Container führen dazu, dass Azure SQL-Verbindungen fehlschlagen

Question

Ich habe eine Dockerfile für mein .NET-Programm erstellt. Das Programm läuft auf meinem Desktop und auf einem Windows Server 2016 (Azure VM) ohne Docker einwandfrei. Wenn ich versuche, es als Container auszuführen (basierend auf microsoft/windowsservercore), erhalte ich häufig Datenbankfehler, wenn ich mich mit meinen Azure SQL-Instanzen verbinde.

Ich habe zwei Azure SQL-Instanz ausgeführt (P1 und keine Last). Wenn eine Verbindung hergestellt werden kann, sind sie ziemlich schnell, aber das Problem besteht darin, dass die Verbindung oft nicht hergestellt werden kann. Es sieht so aus, als ob das Netzwerk sehr instabil ist. Dies sind typische Fehler, die auf mich geworfen werden:

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Die innere Ausnahme berichtet Der Netzwerkpfad wurde nicht gefunden. Zuerst dachte ich, es könnte meine lokale Maschine sein, aber es hat auch Probleme auf der Windows Server 2016 (mit Containern) VM-Instanz in Azure.

Um das Problem zu lokalisieren, habe ich ein Testprogramm erstellt, das alle 5 Sekunden eine Verbindung zu meinen Datenbanken herstellt (und SELECT COUNT(*) from sysobjects ausführt). Dieses Programm findet immer die Datenbank.

Es scheint, dass mein anderes Programm oft während des Starts fehlschlägt, aber während der Initialisierung gibt es viele Datenbankaufrufe. Ich vermute, etwas ist anders mit Threading, Verbindungspooling, ...

Wer ein Hinweis?

Answer 1

Es scheint seltsam, dass die Fehlermeldung vom Named Pipes Provider kommt, da Azure SQL nur über TCP/IP eine Verbindung herstellen kann. Irgendwie scheint es auf Named Pipes zurückzugreifen, was verhindert werden kann, indem man den Hostnamen mit tcp: voranstellt. So sieht meine Verbindungszeichenfolge so etwas wie:

Server=tcp:example.database.windows.net;Database=<dbname>;User Id=... 

Dies verhindert, dass der Server zurückfällt, zu versuchen, Named Pipes zu verwenden, und ich habe dieses Problem nicht mehr zu sehen.

Leider habe ich den Grund, warum der Named-Pipes-Anbieter in einigen Situationen verwendet wird, nicht gefunden. Es sollte durch eine Konfiguration innerhalb des microsoft/windowsservercore Bildes verursacht werden, weil ich nie die Fehlermeldung außerhalb des Docker Bildes gesehen habe. Andernfalls hätte ich den Drosselungsmechanismus von Azure SQL vermutet (obwohl die Last ziemlich niedrig ist).

Answer 2

Wir erleben derzeit auch mehr Netzwerkprobleme mit Windows Container. Aber mit dem Software-definierten Netzwerk, wie Sie es in Azure/Containers haben, wird allgemein empfohlen, Logic erneut einzusetzen.

Wenn Sie Entity Framework verwenden, können Sie eine andere Ausfallsicherungs- und Wiederholungsstrategie "SqlAzureExecutionStrategy" verwenden. Dies ist für Azure im Allgemeinen nicht nur Container, sondern kann helfen, die Ausnahmen zu reduzieren.

Dieser Artikel beschreibt, wie: https://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx