3

.NET プログラム用の Dockerfile を作成しました。このプログラムは、私のデスクトップと、Docker を使用しない Windows Server 2016 (Azure VM) で正常に動作します。内部でコンテナーとして実行しようとすると ( microsoft/windowsservercoreに基づく)、Azure SQL インスタンスに接続するときにデータベース エラーが発生することがよくあります。

2 つの Azure SQL インスタンスが実行されています (P1 と負荷なし)。接続を確立できる場合はかなり高速ですが、問題は接続を確立できないことが多いことです。ネットワークが非常に不安定なようです。これらは私に投げられる典型的なエラーです:

System.Data.SqlClient.SqlException: SQL Server への接続を確立中に、ネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないか、アクセスできませんでした。インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。(プロバイダー: 名前付きパイプ プロバイダー、エラー: 40 - SQL Server への接続を開けませんでした)

内部例外は、 The network path was not found を報告します。最初は自分のローカル マシンかもしれないと思っていましたが、Azure の Windows Server 2016 (コンテナーを使用) VM インスタンスにも問題があります。

問題を特定するために、5 秒ごとにデータベースに接続する (そして を実行するSELECT COUNT(*) from sysobjects) テスト プログラムを作成しました。このプログラムは常にデータベースの検索に成功します。

私の他のプログラムは起動時に失敗することが多いようですが、初期化中にデータベース呼び出しがたくさんあります。スレッド化、接続プーリングなどで何かが違うのではないかと思います...

手がかりはありますか？

4

2 に答える 2

3

現時点では、Windows コンテナーでさらに多くのネットワークの問題が発生しています。ただし、Azure/コンテナーにあるようなソフトウェア定義のネットワークでは、再試行ロジックを配置することが一般的に推奨されています。

Entity Framework を使用している場合は、別の復元力と再試行戦略「SqlAzureExecutionStrategy」をプラグインできます。これは、コンテナーだけでなく、Azure 全般に適用されますが、例外を減らすのに役立ちます。

この記事では、その方法について説明します: https://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx

于 2017-01-03T15:28:40.040 に答える
2

Azure SQL は TCP/IP 経由でしか接続できないため、エラー メッセージがNamed Pipes Providerから来ているのは奇妙に思えます。どういうわけか、名前付きパイプにフォールバックするようですが、ホスト名の前にtcp:. したがって、私の接続文字列は次のようになります。

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

これにより、サーバーがフォールバックして名前付きパイプを使用しようとするのを防ぎます。この問題はもう見られません。

残念ながら、名前付きパイプ プロバイダーが一部の状況で使用される理由はわかりませんでした。Docker イメージの外部でエラー メッセージを見たことがないため、 microsoft/windowsservercoreイメージ内の何らかの構成が原因であるはずです。そうでなければ、Azure SQL のスロットリング メカニズムを疑っていたでしょう (負荷はかなり低いですが)。

于 2017-01-03T14:25:04.620 に答える