SQL Server Always On Availability Groups er Microsofts nyeste teknologi til at imødekomme behovene for høj tilgængelighed og katastrofegendannelse hos organisationer, der bruger SQL Server. En stor fordel ved AlwaysOn er evnen til at adressere både HA og DR i én implementering. Vi oplevede følgende vigtige fordele ved AlwaysOn:
Vi kan gruppere relaterede databaser som en del af en enkelt tilgængelighedsgruppe og have dem failover sammen, hvis dette er nødvendigt. Dette er især nyttigt for programmer, der er afhængige af mere end én database, såsom Microsoft Office SharePoint, Microsoft Lync og Sage.
Sammenlignet med SQL Server Failover Cluster Instances, finder vi ud af, at lagring som et enkelt fejlpunkt er blevet elimineret siden hver forekomst, som udgør en replika er tildelt sit eget lager.
Med AlwaysOn er det muligt at konfigurere HA og DR på én gang. Dette opnås ved at oprette en Multi-site Windows Failover Clusters som grundlaget for din AlwaysOn-konfiguration. At udføre et rolleskifte, når du bruger AlwaysOn, er betydeligt enklere end at gøre det, når du bruger Transaction Log Shipping.
Computerobjekter
Active Directory (AD) er et stort emne, og vi vil ikke dykke ned i detaljerne i denne artikel. Som du kan gætte, er Active Directory Microsofts adressebogstjeneste. I computernetværkstermer er en adressebogstjeneste en facilitet, der giver os mulighed for at registrere, identificere og administrere alle objekter i et netværk centralt. Indtastninger i katalogtjenesterne knytter navnene på netværksenheder til tilsvarende IP-adresser og andre egenskaber i kataloget. De mest almindelige objekter i en bibliotekstjeneste (og i Microsofts AD) er brugere og computere. Ligesom hver bruger på domænet kan registreres og administreres fra Active Directory, kan hver computer på domænet også administreres fra Active Directory. Ligesom hver bruger forventes at have en unik konto i Active Directory, er det også hver computer.
I Active Directory er ikke alle computerobjekter knyttet til en fysisk computer. Et computerobjekt kan repræsentere en fysisk computer (arbejdsstation eller server), men kan også repræsentere noget, der fungerer som en computer, såsom det repræsentative navn for en Windows-klynge eller det virtuelle navn for en klyngetjeneste (rolle). Sådanne repræsentationer er også unikke i Active Directory ligesom almindelige computernavne.
CNO'er og VNO'er i WSFC
Når du installerer en Windows Failover Cluster, opretter installationsprogrammet en enhed i Active Directory kaldet et Computer Name Object (CNO). Denne CNO er den primære enhed, der er oprettet i Active Directory for klyngen og repræsenterer "Servernavnet" for hele klyngen. Efterfølgende andre objekter kendt som Virtuelle navneobjekter oprettes af CNO'en, når de udfører sådanne aktiviteter som oprettelse af klyngeroller, tilgængelighedsgrupper, eller Tilgængelighedsgruppelyttere . Disse CNO'er og VNO'er har IP-adresser tilknyttet. Du kan angive disse adresser, når du installerer klyngen eller opretter en ny klyngerolle eller en lytter. For hver klynge, rolle og lytter, du opretter, skal du bruge et unikt computernavn og en unik IP-adresse. Fig. 1 viser det trin, hvor du angiver klyngenavnobjektet og dets IP-adresse, når du konfigurerer en klynge.
De navne, du bruger, når du konfigurerer en klynge, er fuldstændig vilkårlige. De skal bare være unikke. Det tilrådes dog at følge din organisations navnekonventioner for almindelige computere, når du opretter CNO'er eller VNO'er - dette hjælper med at holde administrationen nemmere. Det giver også mening at bruge en specifik blok af IP-adresser, som vil dække alle adresseringsbehov for hele din klynge – CNO'en og alle VNO'er (roller), du har til hensigt at oprette.
Fig. 1 Navn til adressekortlægning i en klynge
Nøgledomænetilladelser
DBA'en eller systemadministratoren, der udfører en klyngeinstallation, skal have tilladelse til at Oprette computerobjekter i Active Directory-domænet. Efter oprettelse af computernavneobjektet skal domæneadministratoren til gengæld give følgende tilladelser til computernavneobjektet, så roller (som resulterer i virtuelle navneobjekter) kan oprettes i klyngen:
Opret computerobjekter
Læs alle egenskaber
Uden disse tilladelser vil du sandsynligvis få fejlmeddelelser svarende til nedenstående, når du forsøger at oprette en rolle (i tilfælde af AlwaysOn FCI ) eller en lytter (i tilfælde af AlwaysOn AG ):
Fejl under installation af MS SQL Server Cluster:
Klyngenetværksnavnressource 'SQL-netværksnavn (EUK-SCCM-01)' kunne ikke oprette dets tilknyttede computerobjekt i domænet 'domænenavn.com' af følgende årsag:Kan ikke oprette computerkonto.
Teksten til den tilknyttede fejlkode er:Adgang nægtet.
Denne fejlmeddelelse er observeret i Event Viewer, da SQL Server ikke ville være tilgængelig på nuværende tidspunkt. Du vil også kunne se dette, hvis du navigerer til SQL Error Log-filerne i LOG-mappen, som ligger i SQL Servers installationsmappe. Nøglesætningen er "Adgang nægtes ”.
Andre krav
Jeg bør nævne konceptet med en domænecontroller. En domænecontroller, eller mere præcist, et sæt domænecontrollere leverer nøgletjenester til Active Directory, såsom registrering af objekter og godkendelse af brugere og computere. For at kunne konfigurere en klynge eller en AlwaysOn Listener, skal en domænecontroller være tilgængelig fra den computer, hvor du udfører konfigurationen. Det betyder, at kommunikation fra computeren til domænecontrolleren skal åbnes på en række TCP- og UDP-porte. Microsoft dokumenterer dette meget detaljeret i denne artikel . Dette kan være en selvfølge i de fleste tilfælde, men ved fejlfinding af forbindelsesproblemer hjælper det at vide, hvad der faktisk er nødvendigt.
I en tidligere artikel , jeg nævnte også, at det er nødvendigt at give tilladelser til CNO'en for en klynge, når du konfigurerer et fildelingskvorum.
Fig. 2 tilladelser på en fildeling
En note om navneopløsning
At være computerobjekter er CNO'er og VNO'er afhængige af Domain Name Service for at løse det navn, der er angivet, når du installerer klyngen, opretter en rolle eller opretter en AlwaysOn Listener. Typisk får klienter disse computernavne for at etablere en forbindelse til klyngen. Med andre ord er IP-adressen gennemsigtig for dem, hvilket gør klientkonfigurationen enkel og abstraherer failovers fra slutbrugerne.
Fig. 3 AG Listener-egenskaber for lytter med to IP-adresser
I en tidligere artikel nævnte jeg et tilfælde, hvor dette scenarie kan forårsage problemer. I vores multi-site klynge havde vi én lytter til vores AlwaysOn Availability Group. Denne lytter blev konfigureret til at løse til to IP-adresser. Dette er nødvendigt for en multi-site klynge, der spænder over flere undernet. I en sådan konfiguration vil navneserveren returnere begge IP-adresser, der er knyttet til lytteren ved udstedelse af et nslookup tjek (se fig. 4). Men når du opretter forbindelse, kan du kun få adgang til én af disse IP-adresser ad gangen. Cluster Manager vil vise den anden IP-adresse som Offline (se fig. 5).
Fig. 4 AG Listener-egenskaber for lytter med to IP-adresser
Fig. 5 egenskaber for klyngerolle med to IP-adresser i separate undernet
Dette er normalt. Hvis der er en failover til det alternative websted, begynder DNS-serveren at løse den alternative IP-adresse efter et par minutter. Betydningen af dette er, at kundernes kommunikation med den alternative side skal være mulig. Fig. 6 og Fig. 7 fremhæver dette yderligere.
Fig. 6 Kommunikationssti med primær replika i Dakar
Lad os tage et godt kig på stien, som pakkerne vil krydse fra klientcomputerne til klyngen. Når den primære replika er i Dakar, bliver lytternavnet SQL-SVR-LNR løst til IP-adressen 192.168.1.20, og WFCS sender på sin side anmodningen til serveren 192.168.1.22 (bemærk, at denne server også har sin egen computernavn). I tilfælde af en failover til Nairobi har vi kommunikationsvejen, der går gennem 192.168.2.20 og derefter til 192.168.2.22. Implikationen er, at for en problemfri kundeoplevelse skal alle klienter i alle datacentre have kommunikation tilladt på alle involverede firewalls ved brug af port 1433.
Fig. 7 Kommunikationssti med primær replika i Nairobi
Konklusion
Mens Windows Failover Clustering, Active Directory og Domain Name Service kan være uden for rollen som databaseadministrator, betaler det sig at have en grundlæggende forståelse af, hvordan disse teknologier fungerer for at kunne bygge og fejlfinde AlwaysOn Failover-klyngeforekomster og AlwaysOn-tilgængelighedsgrupper. Nogle organisationer har en streng adskillelse af opgaver mellem systemadministratorer og databaseadministratorer, men hvor dette ikke er tilfældet, skal databaseadministratoren være i stand til at omslutte disse Windows-koncepter for at få succes som DBA.
Referencer
Oversigt over AlwaysOn-tilgængelighedsgrupper
Windows Failover Clustering med SQL Server
Tjenesteoversigt og netværksportkrav til Windows
Administration af computerobjekter