フェールオーバークラスタークライアントアクセスポイントは、所有者のpingにのみ応答しますNode
背景
SQL ServerがインストールされたAzureで2つのVM（Windows Server 2012 R2）を実行しており、可用性グループとして設定されています。もちろん、専用DCとして別のVM）もあります。これらはすべて単一の仮想ネットワークを介して接続されています。このセットアップはうまく機能しており、からSQLに接続できました。ローカルの物理マシンに問題はありませんでしたが、アカウントの使用制限に達したため、すべてのプロビジョニングが解除されました。制限を解除し、同じVHDを使用してすべてのサーバーを再度割り当て、すべての設定を（おそらく）復元しました。しかし、SQLServerにアクセスできなくなりました。
名前の定義
これを最もよく説明するために、2つのノードSQL1とSQL2、可用性グループSQL-AG、可用性グループリスナーSQL-Listener、およびこれがすべて実行されているクラウドサービス（適切なエンドポイントが設定されている）と呼びます。 up）SQL-CloudService。 SQL1はフェールオーバークラスターの役割の所有者であり（したがって、プライマリのレプリカの役割があります）、SQL2はセカンダリです。
シナリオ
両方のサーバーにRDPを実行し、SQL1からSSMSを使用してSQL-Listenerに接続し、すべてが正常で同期されていると報告するSQL-AGダッシュボードを表示できます。
SQL2では、SQL-Listenerに接続できません。また、以前も機能していたローカルマシンからSQL-CloudServiceに接続できません。どちらのシステムもエラーを返しますが、
SQL-Listenerに接続できません。
SQL Serverへの接続の確立中に、ネットワーク関連またはインスタンス固有のエラーが発生しました。サーバーが見つからないか、アクセスできませんでした。インスタンス名が正しいこと、およびSQLServerがリモート接続を許可するように構成されていることを確認してください。 （プロバイダー：名前付きパイププロバイダー、エラー：40-SQL Serverへの接続を開くことができませんでした）（Microsoft SQL Server、エラー：53）
ネットワークパスが見つかりませんでした
SQL1にアクセスしてSSMSを介して接続すると、SQL-AGにSQL2にフェイルオーバーするように指示できます。これは正常に実行されます。ただし、その後、SQL1からSQL-Listenerに接続できなくなりましたが、SQL2からです。
簡単に言うと、プライマリのレプリカの役割でマークされているシステムからのみ、SSMSを使用可能グループリスナーに接続できます。
本当の問題
これらすべてを実行できる必要はありませんが、ローカルマシンからインターネット経由でSQL Serverにアクセスできる必要があります。これらの問題は、同じ根本的な問題が原因であると想定しています。同じエラーメッセージが表示されるためです。
途中で見つけたもの
エラーメッセージと状況を考えれば当然ですが、pingを開始したマシンで実行されていない限り、SQL-Listenerにpingを実行できません。 SQL1がプライマリとしてマークされている場合、SQL1から問題なくpingを実行できますが、SQL2から試行すると、DNSを使用してIPを正常に検索しますが、「[SQL2のIP]からの応答：宛先ホストに到達できません」と返されます。 SQL-AGをフェイルオーバーすると、同じ問題が反対方向に発生します。ただし、SQL2からSQL1に常にpingを実行でき、その逆も可能です。このため、SQLの問題ではなく、フェールオーバークラスターの問題であると信じる傾向があります。したがって、この質問のタイトル。
また、ファイアウォールは手つかずのように見えることもわかりました。これは、pingの問題と一致していると思いますが、ファイアウォールでの監視では、リモートマシン（ローカルマシンまたは所有していないVM）からのSQLServerの試行は示されません。
すでに述べたことから推測できますが、クラウドサービスを介しても、ポート1433でファイアウォールにアクセスできないことを指摘するのは注目に値します。直接の理由から、なぜそうなるのか完全にはわかりません。 -サーバーへのルートは、サーバーに直接プッシュする必要があると思います。したがって、これを表すログ内のアイテムを期待しますが、アイテムはたくさんあり、どれもそうではありません。
当然のことながら、pingの問題を考えると、所有者ノードでローカルにレポートサーバーのURL（http://sql-listener/ReportServerに似ています）にアクセスすることもできますが、他のノードからリモートでアクセスすることはできません。
コンピューターの名前（SQLリスナーと比較してSQL1またはSQL2）を指定すると、どちらのSQLServerにも接続できます。これは、とにかく、私がクラウドサービスを通過できないように見えることをすべて見知らぬ人にします。これは、どこにいてもリッスンしていることを意味すると思います。AzureにSQL-Listenerを指すように指示する必要がなかったことを考えると、それが違いを生むとは思いません。だから多分私はこの状況全体を間違って読んでいるだけです。
私が行ったトラブルシューティング手順
- 関係するすべてのマシンを再起動します
- すべてのIPが静的であり、期待されるものであることを確認します
- ファイアウォールが正しく設定されていることを確認してください
- 各SQLサーバーをシャットダウンし（Azureでは、VMの割り当てが解除されるため、再起動するよりもはるかに深刻です）、再度起動します。
- フェールオーバークラスターロールのクライアントアクセスポイント（およびそれとともに、可用性グループリスナー）を削除して再作成します。
- クラウドサービスエンドポイントを再作成しました（サーバー間に問題があることに気付く前だったので、これは何の役にも立たないようですが）
- 明示的に指定されたIPアドレス（ "tcp：[SQL-Listener's IP]"）を使用してサーバーに接続しようとしました。これは、「接続されたパーティが一定期間後に適切に応答しなかったために接続の試行が失敗したか、接続されたホストが応答しなかったために確立された接続が失敗した」というネットワーク関連/インスタンス固有のエラーで返されます。
私が持っていた考え
- それはサブネットと関係があるのでしょうか？それらは確かに同じものにあるように見えますが、私はこのようないくつかの奇妙な問題を引き起こしていると想像することができます。
- 支出制限を超えて実行するためにサーバーをシャットダウンするときにAzureが行うことを特に知っている人はいますか？私が気づかなかった変更された設定がどこかに1つだけありますか？
したがって、これは予想通り、かなりばかげた間違いであることが判明しました。概説したように、Azureと連携するように可用性グループを設定するために必要なすべての手順を忘れていました ここ 。
クラウドサービスの割り当て解除によりIPが変更されたため、SQLリスナーは間違ったIPアドレスをリッスンしていました。私はそれについて考え、リスナーを削除して再作成することで対処しましたが、恥ずかしいことに、最初にリスナーを設定するために個人的に実行したすべての手順を完全に見落としていました。そのため、マイクロソフトサポートとの電話で1時間後、ようやくすべてが再びセットアップされました。これですべてバックアップされ、機能しています。
わかりました、今日私は非常に似ているように見える私の問題を解決しました。 2週間過ごしました。意気消沈した。おそらく（ad minがそれを削除しない場合）それは誰かを助けるでしょう。
したがって、答えはAzure VM NICです。2つあります。1つを削除すると、必要のないものはすべてスムーズに進みました。
私にとって重要な点は、パラメーター-StaticAddressxx.xxx.xx.12をコマンドnew-cluster-name Cluster –Node VM01、VM02 -StaticAddress xx.xxx.xx.12 -NoStorage –AdministrativeAccessPointDNSに渡すことでした。
私の場合、2番目のNICを削除するまで、そのパラメーターを続行できませんでした。