管理サーバーがデータ ウェアハウス データベースへの接続を試みるイベント 31551

この記事では、Operations Manager 管理サーバーが、データ ウェアハウス データベースをホストするSQL Server クラスターに接続できない問題を修正します。

元の製品バージョン: System Center 2012 R2 Operations Manager、Microsoft System Center 2012 Operations Manager
元の KB 番号: 3084547

現象

System Center Operations Manager 管理サーバーは、データ ウェアハウス データベースをホストするSQL Server クラスターに接続することも、通信することもできません。 この状況では、イベント ID 31551 が Operations Manager ログに記録され、さまざまなワークフロー名について次のような説明が記録されます。

ログ名: Operations Manager
ソース: Health Service モジュール
日付：
イベント ID: 31551
タスク カテゴリ: Data Warehouse
レベル: エラー
キーワード: クラシック
ユーザー: N/A
コンピューター: server.Contoso.com
説明:
Data Warehouseにデータを格納できませんでした。 操作が再試行されます。
例外 'SqlException': SQL Serverへの接続の確立中に、ネットワーク関連またはインスタンス固有のエラーが発生しました。 サーバーが見つからなかったか、アクセスできませんでした。 インスタンス名が正しいことと、リモート接続を許可するようにSQL Serverが構成されていることを確認します。 (プロバイダー: SQL ネットワーク インターフェイス、エラー: 26 - 指定されたサーバー/インスタンスの検索エラー)

1 つ以上のワークフローがこの影響を受けた。

ワークフロー名: Microsoft.SystemCenter.DataWarehouse.CollectEventData
インスタンス名: server.Contoso.com
インスタンス ID: {8A13A832-776E-096E-32E7-DC479FCD6DBC}
管理グループ: SupportGroup

原因

ここでは、次の文字列にフォーカスを合わせる必要があります。

error: 26 - 指定されたサーバー/インスタンスの検索中にエラーが発生しました

このエラーは、多くの場合、サーバーでリモート接続が有効になっていないために発生すると考えられます。 ただし、このエラーは、クライアントが SQL Server Browser からSQL Server解決プロトコル (SSRP) 応答 UDP パケットを受信できない場合SQL Server生成されます。 通常、この動作は、管理サーバーと Operations Manager データ ウェアハウスをホストするSQL Server クラスターとの間で UDP ポート通信がブロックされるために発生します。

解決方法

この問題を解決するには、管理サーバーとSQL Server クラスターの間で UDP ポート通信が失敗する原因となっている問題を解決する必要があります。 ほとんどの場合、次の手順に従って問題を特定するのは非常に簡単です。

1. サーバー名が正しいことを確認します (たとえば、名前にエラーがないことを確認してください)。
2. インスタンス名が正しいこと、およびインスタンスが実際にターゲット コンピューターに存在することを確認します。 一部のアプリケーションでは、\\ を \\ に変換します。 アプリケーションがわからない場合は、接続文字列でと server\\instance の両方server\instanceを試してください。
3. サーバーに到達可能であることを確認します。 DNS が正しく解決できることと、サーバーに ping を実行できることを確認します。
4. SQL Server ブラウザー サービスがサーバー上で実行されていることを確認します。
5. サーバーでファイアウォールが有効になっている場合は、sqlbrowser.exe と UDP ポート 1434 の例外があることを確認します。

このユーティリティは、PortQry バージョン 2.0 の新機能からダウンロードPortQryして、手順 4 と 5 をテストできます。

が完了したら PortQry、次のコマンドを実行します。

portqry.exe -n serverName -p UDP -e 1434

このコマンドが情報を返し、ターゲット インスタンスが含まれている場合は、手順 4 と 5 のシナリオを除外できます。 これは、SQL Browser が実行されており、ファイアウォールがブラウザー UDP パケットSQL Serverブロックされていないことを意味します。

これらの手順を完了すると、エラーは発生しなくなります。 管理サーバーは引き続きSQL Serverへの接続に失敗する可能性がありますが、その場合は、この時点で別のエラー メッセージをトリガーする必要があります。 それでも管理サーバーの接続に失敗する場合は、 または tcp:server\instance を にnp:server\instance置き換えserver\instance、TCP プロトコルまたは NP プロトコルで成功するかどうかを確認します。

詳細

この問題は、次の組み合わせによって発生します。

• Windows クラスターの詳細
• 名前付きインスタンスのSQL Serverの検出方法

名前付きインスタンスSQL Serverに接続すると、クライアント コンポーネントは SQL Server Browser に依存してサーバーとそのパラメーターを検出します。 検出プロセスは次のように実行されます。

• クライアントは、ターゲット コンピューター SQL Serverブラウザーに UDP パケットを送信します。 名前付きインスタンスが Windows クラスター上にある場合、パケットはクラスター IP に送信されます。具体的には、SQL Server実行されている仮想マシンに対応する IP アドレスに送信されます。 ただし、SQL Browser はクラスター対応ではなく、IP any でリッスンします。
• ブラウザー SQL Server UDP 要求パケットを受信すると、応答 UDP パケットがクライアントに送信されます。 宛先 IP アドレスはクライアントの IP アドレスですが、ソース IP アドレスは変更されます。 仮想SQL Server IP アドレスではなく、物理コンピューター上のネットワーク アダプターの IP アドレスになりました。
• 応答 UDP パケットの送信元 IP アドレスは、ルーティング テーブルに基づいて Windows OS によって決定されます。 仮想SQL Server IP アドレスと物理ネットワーク アダプターに接続されている IP アドレスの両方が通常、同じサブネット上にあるため、同じルートに属しているため、物理 IP アドレスが選択されます。 クライアントおよびサーバー コンピューターのセキュリティ設定によっては、ピア IP アドレスが変更されているため、この応答 UDP パケットがサード パーティ製ファイアウォールまたは IPsec によって破棄される場合があります。 Windows ファイアウォールはパケットをドロップしません。
• クライアントが Windows Vista ベースのコンピューターの場合、クライアントで IPsec ポリシーが有効になっている場合、およびクライアントとサーバー間の信頼接続を確立できない場合、IPsec はパケットをドロップする可能性があります。 この問題を回避するには、接続文字列で TCP ポートまたはパイプ名を手動で指定します。