AlwaysOnのトラブルシューティング–多くの目がかかる場合があります

数週間前、AlwaysOn可用性グループの複数の構成でデモ環境の構成を開始しました。 5ノードのWSFCクラスターがありました。各ノードにはSQLServer2012のスタンドアロンの名前付きインスタンスがあり、これらのノードの上に2つのフェールオーバークラスターインスタンス（FCI）もセットアップされていました。簡単な図：

したがって、5つのスタンドアロンの名前付きインスタンス（.\AGDEMO）があることがわかります。各ノードで）、次に2つのFCI – 1つは所有者の可能性があるVM-AARON-1およびVM-AARON-2（AGFCI1\AGFCI1 ）、次に所有者の可能性があるものVM-AARON-3、VM-AARON-4、VM-AARON-5（AGFCI2\AGFCI2 ）。さて、これを手動で図解することはかなり複雑になる必要があるでしょう（それについては後で詳しく説明します）ので、明白な理由でそれを避けるつもりです。基本的に、要件は複数のタイプのAG構成を持つことでした：

1つ以上のスタンドアロンインスタンスにレプリカがあるFCIのプライマリ
別のFCIにレプリカがあるFCIのプライマリ
1つ以上のFCIにレプリカがあるスタンドアロンインスタンスのプライマリ
スタンドアロンインスタンスのプライマリと、1つ以上のスタンドアロンインスタンスのレプリカ
スタンドアロンインスタンスとFCIの両方にレプリカがあるスタンドアロンインスタンスのプライマリ

次に、同期コミットと非同期コミット、手動フェイルオーバーと自動フェイルオーバー、および読み取り専用セカンダリの組み合わせ（可能な場合）。ここで可能な順列を制限するいくつかの技術的制限があります。例：

FCI上にあるレプリカでは手動フェイルオーバーが必要です
WSFCノードは、スタンドアロンであろうとクラスター化されていようと、同じ可用性グループに関係する複数のインスタンスをホストすることはできず、所有者になることもできません。次のエラーメッセージが表示されます。ノード「VM-AARON-1」がレプリカ「AGFCI1\AGFCI1」と「VM-AARON-1\」の両方の所有者である可能性があるため、可用性グループ「MyGroup」へのレプリカの作成、参加、または追加に失敗しました。 AGDEMO'。 1つのレプリカがフェールオーバークラスターインスタンスである場合は、重複しているノードをその可能な所有者から削除して、再試行してください。（Microsoft SQL Server、エラー：19405）

私が表現しようとしていたシナリオのほとんどは、実際のシナリオでは実用的ではありませんが、大部分は理論的には可能。今までに推測していなかった場合、この環境は、SQLSentryの将来のバージョンで提供する予定の可用性グループに関する新機能をテストするために明示的に設定されています。ラスベガスで開催された最近のSQLIntersectionカンファレンスでのFusion-ioとの基調講演で、このテクノロジーの一部を紹介しました。

障害物＃1

SSMSのウィザードを使用して可用性グループを設定するのは非常に簡単です。たとえば、異種のファイルパスがある場合を除きます。ウィザードには、すべてのレプリカに同じデータパスとログパスが存在することを確認する検証があります。これは、2つの異なる名前付きインスタンスにデフォルトのデータパスを使用している場合、またはドライブ文字の構成が異なる場合（FCIが関係している場合によく発生します）、問題になる可能性があります。

セカンダリレプリカのデータベースファイルの場所の互換性を確認すると、エラーが発生しました。（Microsoft.SqlServer.Management.HadrTasks）

次のフォルダの場所は、セカンダリレプリカVM-AARON-1\AGDEMOをホストするサーバーインスタンスに存在しません。

P：\ MSSQL11.AGFCI2 \ MSSQL \ DATA;
（Microsoft.SqlServer.Management.HadrTasks）

言うまでもなく、時間の試練に耐える必要のあるあらゆる種類の環境でこのシナリオを設定する必要はありません。たとえば、後でデータベースの1つに新しいファイルを追加すると、事態は急速に悪化します。ただし、テスト/デモ環境、概念実証、またはかなりの期間安定していると予想される環境の場合は、心配しないでください。ウィザードがなくてもこれを実行できます。

残念ながら、怪我に侮辱を加えるために、ウィザードではスクリプトを作成できません。検証エラーを通過することはできず、Scriptはありませんボタン：

つまり、これは自分でコーディングする必要があることを意味します（DDLは「役立つ」検証を実行しないため）。同じパスが存在する他のインスタンスがある場合は、同じウィザードに従い、検証画面を通過して、Scriptをクリックすることでこれを行うことができます。 Finishの代わりに、サーバー名を変更し、WITH MOVEで追加します初期復元のオプション。または、次のように、独自のスクリプトを最初から作成することもできます（スクリプトでは、エンドポイントとアクセス許可が既に構成されており、すべてのインスタンスで可用性グループ機能が有効になっていることを前提としています）：

-- Use SQLCMD mode and uncomment the :CONNECT commands
-- or just run the two segments separately / change connection
-- :CONNECT Server1
 
CREATE AVAILABILITY GROUP [GroupName] 
  WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
  FOR DATABASE [Database1] --, ...
  REPLICA ON -- primary:
    N'Server1' WITH (ENDPOINT_URL = N'TCP://Server1:5022',   
      FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    -- secondary:
    N'Server2' WITH (ENDPOINT_URL = N'TCP://Server2:5022',
      FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO));
 
ALTER AVAILABILITY GROUP [GroupName] 
  ADD LISTENER N'ListenerName' 
  (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
 
BACKUP DATABASE Database1 TO DISK = '\\Server1\Share\db1.bak'
  WITH INIT, COPY_ONLY, COMPRESSION;
 
BACKUP LOG Database1 TO DISK = '\\Server1\Share\db1.trn'
  WITH INIT, COMPRESSION;
 
-- :CONNECT Server2
ALTER AVAILABILITY GROUP [GroupName] JOIN;
 
RESTORE DATABASE Database1 FROM DISK = '\\Server1\Share\db1.bak'
  WITH REPLACE, NORECOVERY, NOUNLOAD, 
  MOVE 'data_file_name' TO 'P:\path\file.mdf',
  MOVE 'log_file_name'  TO 'P:\path\file.ldf';
 
RESTORE LOG Database1 FROM DISK = '\\Server1\Share\db1.trn'
  WITH NORECOVERY, NOUNLOAD;
 
ALTER DATABASE Database1 SET HADR AVAILABILITY GROUP = [GroupName];

障害物＃2

同じサーバー上に複数のインスタンスがある場合、両方のインスタンスがデータベースミラーリングエンドポイント（可用性グループで使用されるのと同じエンドポイント）のポート5022を共有できない場合があります。つまり、エンドポイントを削除して再作成し、代わりに使用可能なポートに設定する必要があります。

DROP ENDPOINT [Hadr_endpoint];
GO
 
CREATE ENDPOINT [Hadr_endpoint]
    STATE = STARTED
    AS TCP ( LISTENER_PORT = 5023 )
    FOR DATABASE_MIRRORING (ROLE = ALL);

これで、ServerName:5023にエンドポイントを持つインスタンスを指定できます。。

障害物＃3

ただし、これを実行すると、上記のスクリプトの最後のステップに到達すると、正確に48秒後に、毎回、次の役に立たないエラーメッセージが表示されます。

メッセージ35250、レベル16、状態7、行2
プライマリレプリカへの接続がアクティブではありません。コマンドを処理できません。

これにより、あらゆる種類の潜在的な問題を追跡する必要がありました。たとえば、ファイアウォールやSQL Server Configuration Managerをチェックして、インスタンス間のポートをブロックするものがないかどうかを確認しました。灘。 SQL Serverのエラーログにさまざまなエラーが見つかりました：

データベースミラーリングのログイン試行が次のエラーで失敗しました：'接続ハンドシェイクに失敗しました。互換性のある暗号化アルゴリズムはありません。状態22。'。

データベースミラーリングのログイン試行が次のエラーで失敗しました：'接続ハンドシェイクに失敗しました。 OS呼び出しが失敗しました：（80090303）0x80090303（指定されたターゲットが不明または到達不能です）。状態66。'。

ID[5AF5B58D-BBD5-40BB-BE69-08AC50010BE0]の可用性レプリカ「VM-AARON-1\AGDEMO」への接続を確立しようとしたときに接続タイムアウトが発生しました。ネットワークまたはファイアウォールの問題が存在するか、レプリカに提供されたエンドポイントアドレスがホストサーバーインスタンスのデータベースミラーリングエンドポイントではありません。

この問題は次の症状の組み合わせによって引き起こされていたことが判明しました（そしてThomas Stringer（@SQLife）のおかげで）：（a）Kerberosが正しく設定されておらず、（b）私が作成したhadr_endpointの暗号化アルゴリズムがデフォルトになっていますRC4へ。すべてのスタンドアロンインスタンスがRC4も使用している場合、これは問題ありませんが、そうではありませんでした。簡単に言うと、エンドポイントを削除して再作成しました、すべてのインスタンスで。これはラボ環境であり、Kerberosサポートは実際には必要ありませんでした（そして、Kerberosの問題も追跡したくないほどこれらの問題に十分な時間を費やしていたため）、Negotiateを使用するようにすべてのエンドポイントを設定しましたAES：

DROP ENDPOINT [Hadr_endpoint];
GO
 
CREATE ENDPOINT [Hadr_endpoint]
    STATE = STARTED
    AS TCP ( LISTENER_PORT = 5023 )
    FOR DATABASE_MIRRORING (
       AUTHENTICATION = WINDOWS NEGOTIATE,
       ENCRYPTION = REQUIRED ALGORITHM AES,
       ROLE = ALL);

（Ted Krueger（@onpnt）も最近、同様の問題についてブログに書いています。）

これで、最終的に、異種ファイルパスを持つノード間で、同じノード上の複数のインスタンスを利用して（同じグループ内ではなく）、さまざまな要件をすべて備えた可用性グループを作成できました。これがAlwaysOn管理ビューの1つがどのように見えるかを示しています（クリックして拡大すると、より良い概要が表示されます）：

さて、それはほんの少しのいじめであり、それは完全に意図的です。この機能については、今後数週間でさらにブログを書きます！

結論

あなたが問題を見るのに十分長い時間を費やすとき、あなたはいくつかのかなり明白なことを見落とすことができます。この場合、いくつかのまったく直感的でないエラーメッセージによって隠されたいくつかの明らかな問題がありました。困っている仲間のコミュニティメンバーを助けるためにすべてを捨ててくれたJoeSack（@JosephSack）、Allan Hirt（@SQLHA）、Thomas Stringer（@SQLife）に感謝します。