Problemen oplossen AlwaysOn - Soms zijn er veel paar ogen nodig

Een paar weken geleden ben ik begonnen met het configureren van een demo-omgeving met meerdere configuraties van AlwaysOn-beschikbaarheidsgroepen. Ik had een WSFC-cluster met 5 knooppunten - elk knooppunt had een op zichzelf staand exemplaar van SQL Server 2012 met de naam, en er waren ook twee Failover Cluster Instances (FCI's) bovenop deze knooppunten. Een snel diagram:

U kunt dus zien dat er 5 zelfstandige benoemde instanties zijn (.\AGDEMO op elk knooppunt), en vervolgens twee FCI's – één met mogelijke eigenaren VM-AARON-1 en VM-AARON-2 (AGFCI1\AGFCI1 ), en dan een met mogelijke eigenaren VM-AARON-3, VM-AARON-4 en VM-AARON-5 (AGFCI2\AGFCI2 ). Het handmatig uittekenen hiervan zou aanzienlijk ingewikkelder moeten worden (daarover later meer), dus ik ga het om voor de hand liggende redenen vermijden. In wezen was de vereiste om meerdere soorten AG-configuraties te hebben:

• Primair op een FCI met een replica op een of meer zelfstandige instanties
• Primair op een FCI met een replica op een andere FCI
• Primair op een zelfstandige instantie met een replica op een of meer FCI's
• Primair op een zelfstandige instantie met een replica op een of meer zelfstandige instanties
• Primair op een zelfstandige instantie met replica's op zowel zelfstandige instanties als FCI's

En dan combinaties (waar mogelijk) van synchrone versus asynchrone commit, handmatige versus automatische failover en alleen-lezen secundairen. Er zijn enkele technische beperkingen die de mogelijke permutaties hier zouden beperken, bijvoorbeeld:

• Handmatige failover is nodig bij elke replica die op een FCI staat
• Geen enkel WSFC-knooppunt kan hosten - of zelfs eigenaar zijn van - meerdere instanties, zowel standalone als geclusterd, die betrokken zijn bij dezelfde beschikbaarheidsgroep. U krijgt deze foutmelding:kan geen replica maken, deelnemen aan of toevoegen aan de beschikbaarheidsgroep 'MyGroup', omdat knooppunt 'VM-AARON-1' een mogelijke eigenaar is voor zowel replica 'AGFCI1\AGFCI1' als 'VM-AARON-1\' AGDEMO'. Als een replica een failover-clusterinstantie is, verwijdert u het overlappende knoop punt van de mogelijke eigenaren en probeert u het opnieuw. (Microsoft SQL Server, Fout:19405)

De meeste scenario's die ik probeerde weer te geven zijn niet praktisch in real-world scenario's, maar ze zijn grotendeels en theoretisch mogelijk . Als je het nu nog niet geraden hebt, wordt deze omgeving expliciet opgezet om nieuwe functionaliteit te testen rond Beschikbaarheidsgroepen die we van plan zijn aan te bieden in een toekomstige versie van SQL Sentry. We gaven een voorproefje van een deel van deze technologie tijdens onze keynote met Fusion-io op de recente SQL Intersection-conferentie in Las Vegas.

Obstakel #1

Beschikbaarheidsgroepen instellen met behulp van de wizard in SSMS is vrij eenvoudig. Tenzij je bijvoorbeeld heterogene bestandspaden hebt. De wizard heeft validatie die ervoor zorgt dat dezelfde gegevens- en logboekpaden op alle replica's bestaan. Dit kan lastig zijn als je het standaard gegevenspad gebruikt voor twee verschillende benoemde instanties, of als je verschillende stationsletterconfiguraties hebt (wat vaak gebeurt als er FCI's bij betrokken zijn).

De volgende maplocaties bestaan ​​niet op de serverinstantie die als host fungeert voor secundaire replica VM-AARON-1\AGDEMO:

P:\MSSQL11.AGFCI2\MSSQL\DATA;
(Microsoft.SqlServer.Management.HadrTasks)

Nu moet het vanzelfsprekend zijn dat u dit scenario niet wilt opzetten in een omgeving die de tand des tijds moet doorstaan. Het gaat heel snel mis als je bijvoorbeeld later een nieuw bestand toevoegt aan een van de databases. Maar voor een test-/demo-omgeving, proof of concept, of een omgeving waarvan je verwacht dat deze nog lang stabiel zal zijn, wees niet getreurd:je kunt dit nog steeds doen zonder de wizard.

Helaas, om nog erger te maken, laat de wizard je het niet scripten. U kunt niet voorbij de validatiefout gaan en er is geen Script knop:

Dit betekent dus dat u het zelf moet coderen (aangezien de DDL geen "nuttige" validatie voor u uitvoert). Als u andere gevallen heeft waar dezelfde paden bestaan, kunt u dit doen door dezelfde wizard te volgen, voorbij het validatiescherm te gaan en vervolgens op Script te klikken in plaats van Finish , en verander de servernaam(en) en voeg toe met WITH MOVE opties voor het eerste herstel. Of je kunt gewoon je eigen helemaal opnieuw schrijven, zoiets als dit (het script gaat ervan uit dat je de eindpunten en machtigingen al hebt geconfigureerd en dat alle instanties de functie Beschikbaarheidsgroepen hebben ingeschakeld):

-- Gebruik SQLCMD-modus en verwijder de opmerkingen bij de :CONNECT-commando's-- of voer de twee segmenten afzonderlijk uit / wijzig de verbinding-- :CONNECT Server1 MAAK BESCHIKBAARHEIDSGROEP [Groepsnaam] MET (AUTOMATED_BACKUP_PREFERENCE =SECUNDAIR) VOOR DATABASE [Database1] -- , ... REPLICA AAN -- primair:N'Server1' WITH (ENDPOINT_URL =N'TCP://Server1:5022', FAILOVER_MODE =HANDMATIG, AVAILABILITY_MODE =ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY =50, SECONDARY_ROLE (ALLOW_CONNECTIONS =GEEN) - secundair:N'Server2' WITH (ENDPOINT_URL =N'TCP://Server2:5022', FAILOVER_MODE =MANUAL, AVAILABILITY_MODE =ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY =50, SECONDARY_ROLE (ALLOW_CONNECTIONS =NO)); BESCHIKBAARHEIDSGROEP WIJZIGEN [Groepsnaam] LUISTERAARS TOEVOEGEN N'ListenerName' (MET IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433); BACK-UP DATABASE Database1 NAAR SCHIJF ='\\Server1\Share\db1.bak' MET INIT, ALLEEN KOPIE, COMPRESSIE; BACK-UPLOGBOEK Database1 NAAR SCHIJF ='\\Server1\Share\db1.trn' MET INIT, COMPRESSIE; -- :CONNECT Server2ALTER BESCHIKBAARHEIDSGROEP [Groepsnaam] WORD LID; HERSTEL DATABASE Database1 VAN SCHIJF ='\\Server1\Share\db1.bak' WITH REPLACE, NORECOVERY, NOUNLOAD, MOVE 'data_file_name' NAAR 'P:\path\file.mdf', MOVE 'log_file_name' NAAR 'P:\path \bestand.ldf'; LOGBOEK HERSTELLEN Database1 VANAF SCHIJF ='\\Server1\Share\db1.trn' MET NORECOVERY, NOUNLOAD; ALTER DATABASE Database1 STEL HADR BESCHIKBAARHEID IN GROEP =[Groepsnaam];

Obstakel #2

Als u meerdere exemplaren op dezelfde server hebt, kan het zijn dat beide exemplaren poort 5022 niet kunnen delen voor hun database-mirroring-eindpunt (dit is hetzelfde eindpunt dat wordt gebruikt door beschikbaarheidsgroepen). Dit betekent dat u het eindpunt moet laten vallen en opnieuw moet maken om het in plaats daarvan op een beschikbare poort in te stellen.

DROP ENDPOINT [Hadr_endpoint];GA CREATE ENDPOINT [Hadr_endpoint] STATE =GESTART ALS TCP ( LISTENER_PORT =5023 ) VOOR DATABASE_MIRRORING (ROLE =ALLE);

Nu zou ik een instantie kunnen specificeren met een eindpunt op ServerName:5023 .

Obstakel #3

Toen ik dit echter eenmaal deed, toen ik bij de laatste stap in het bovenstaande script kwam, kreeg ik na precies 48 seconden - elke keer - deze nutteloze foutmelding:

Hierdoor moest ik allerlei mogelijke problemen achtervolgen - bijvoorbeeld firewalls en SQL Server Configuration Manager controleren op alles dat de poorten tussen instanties zou blokkeren. Nada. Ik heb verschillende fouten gevonden in het foutenlogboek van SQL Server:

Aanmeldingspoging Database Mirroring mislukt met fout:'Verbindingshandshake mislukt. Een OS-aanroep is mislukt:(80090303) 0x80090303 (het opgegeven doel is onbekend of onbereikbaar). Staat 66.'.

Er is een verbindingstime-out opgetreden tijdens een poging om een ​​verbinding tot stand te brengen met de beschikbaarheidsreplica 'VM-AARON-1\AGDEMO' met id [5AF5B58D-BBD5-40BB-BE69-08AC50010BE0]. Er is een netwerk- of firewallprobleem, of het eindpuntadres dat voor de replica is opgegeven, is niet het database-mirroringeindpunt van de hostserverinstantie.

Het blijkt (en dankzij Thomas Stringer (@SQLife)) dat dit probleem werd veroorzaakt door een combinatie van symptomen:(a) Kerberos was niet correct ingesteld en (b) het coderingsalgoritme voor het hadr_endpoint dat ik had gemaakt, was standaard naar RC4. Dit zou goed zijn als alle zelfstandige instanties ook RC4 zouden gebruiken, maar dat was niet het geval. Om een ​​lang verhaal kort te maken, ik liet de eindpunten vallen en maakte ze opnieuw , op alle gevallen. Aangezien dit een laboratoriumomgeving was en ik Kerberos-ondersteuning niet echt nodig had (en omdat ik al genoeg tijd in deze problemen had geïnvesteerd en ik niet ook Kerberos-problemen wilde opsporen), heb ik alle eindpunten ingesteld om Negotiate te gebruiken met AES:

DROP ENDPOINT [Hadr_endpoint];GO MAAK ENDPOINT [Hadr_endpoint] STATE =GESTART ALS TCP ( LISTENER_PORT =5023 ) VOOR DATABASE_MIRRORING ( AUTHENTICATIE =WINDOWS ONDERHANDELING, ENCRYPTIE =VEREIST ALGORITHM A); 

 (Ted Krueger (@onpnt) blogde onlangs ook over een soortgelijk probleem.)
 

 Nu kon ik eindelijk Beschikbaarheidsgroepen maken met alle verschillende vereisten die ik had, tussen knooppunten met heterogene bestandspaden, en gebruikmakend van meerdere instanties op hetzelfde knooppunt (alleen niet in dezelfde groep). Hier is een kijkje in hoe een van onze AlwaysOn Management-weergaven eruit zal zien (klik om te vergroten voor een veel beter overzicht):
 

 
 

 Nu, dat is gewoon een beetje plagen, en het is volledig opzettelijk. Ik zal de komende weken meer bloggen over deze functionaliteit!
 
Conclusie
 

 Als je lang genoeg naar een probleem kijkt, kun je nogal voor de hand liggende dingen over het hoofd zien. In dit geval waren er enkele duidelijke problemen verborgen door enkele ronduit niet-intuïtieve foutmeldingen. Ik wil Joe Sack (@JosephSack), Allan Hirt (@SQLHA) en Thomas Stringer (@SQLife) bedanken voor het laten vallen van alles om een ​​medegemeenschapslid in nood te helpen.