Delen via

Vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen

  • Artikel

van toepassing op:SQL Server-

In dit artikel worden overwegingen beschreven voor het implementeren van AlwaysOn-beschikbaarheidsgroepen, waaronder vereisten, beperkingen en aanbevelingen voor hostcomputers, Windows Server-failoverclusters (WSFC), serverexemplaren en beschikbaarheidsgroepen. Voor elk van deze onderdelen worden beveiligingsoverwegingen en vereiste machtigingen aangegeven.

Belangrijk

Voordat u AlwaysOn-beschikbaarheidsgroepen implementeert, raden we u ten zeerste aan om elke sectie van dit onderwerp te lezen.

.NET-hotfixes die beschikbaarheidsgroepen ondersteunen

Afhankelijk van de SQL Server-onderdelen en -functies die u met AlwaysOn-beschikbaarheidsgroepen gaat gebruiken, moet u mogelijk extra .NET-hotfixes installeren die in de volgende tabel worden geïdentificeerd. De hotfixes kunnen in elke volgorde worden geïnstalleerd.

Afhankelijke functie Hotfix Verbinden
Reporting Services Hotfix voor .NET 3.5 SP1 voegt ondersteuning toe aan SQL Client voor AlwaysOn-functies van read-intent, readonly en multisubnetfailover. De hotfix moet worden geïnstalleerd op elke Reporting Services-rapportserver. KB-2654347: hotfix voor .NET 3.5 SP1 om ondersteuning toe te voegen voor Always On-functies

Controlelijst: Vereisten (Windows-systeem)

Als u de functie AlwaysOn-beschikbaarheidsgroepen wilt ondersteunen, moet u ervoor zorgen dat elke computer die deelneemt aan een of meer beschikbaarheidsgroepen voldoet aan de volgende fundamentele vereisten:

Eis Verbinden
Zorg ervoor dat het systeem geen domeincontroller is. Beschikbaarheidsgroepen worden niet ondersteund op domeincontrollers.
Zorg ervoor dat elke computer draait op een ondersteunde Windows Server-versie Hardware- en softwarevereisten voor:
- SQL Server 2022
- SQL Server 2019
- SQL Server 2017-
- SQL Server 2016
Zorg ervoor dat elke computer een knooppunt in een WSFC is. Windows Server-failoverclustering met SQL Server
Zorg ervoor dat de WSFC voldoende knooppunten bevat om de configuraties van uw beschikbaarheidsgroep te ondersteunen. Een clusterknooppunt kan één replica hosten voor een beschikbaarheidsgroep. Hetzelfde knooppunt kan geen twee replica's van dezelfde beschikbaarheidsgroep hosten. Het clusterknooppunt kan deelnemen aan meerdere beschikbaarheidsgroepen, met één replica van elke groep.

Vraag uw databasebeheerders hoeveel clusterknooppunten nodig zijn om de beschikbaarheidsreplica's van de geplande beschikbaarheidsgroepen te ondersteunen.

Wat is een AlwaysOn-beschikbaarheidsgroep?.

Belangrijk

Zorg er ook voor dat uw omgeving correct is geconfigureerd voor het maken van verbinding met een beschikbaarheidsgroep. Voor meer informatie, zie ondersteuning voor stuurprogramma- en clientconnectiviteit voor beschikbaarheidsgroepen.

Aanbevelingen voor computers waarop beschikbaarheidsreplica's worden gehost (Windows-systeem)

  • Vergelijkbare systemen: Voor een bepaalde beschikbaarheidsgroep moeten alle beschikbaarheidsreplica's worden uitgevoerd op vergelijkbare systemen die identieke werkbelastingen kunnen verwerken.

  • Toegewezen netwerkadapters: Gebruik voor de beste prestaties een toegewezen netwerkadapter (netwerkinterfacekaart) voor AlwaysOn-beschikbaarheidsgroepen.

  • Voldoende schijfruimte: Elke computer waarop een serverexemplaar een beschikbaarheidsreplica host, moet voldoende schijfruimte hebben voor alle databases in de beschikbaarheidsgroep. Houd er rekening mee dat wanneer primaire databases groeien, de bijbehorende secundaire databases dezelfde hoeveelheid vergroten.

  • Identieke schijfindeling: Elke computer waarop een serverexemplaar fungeert als host voor een beschikbaarheidsreplica, moet een identieke schijfindeling hebben (met exacte stationsletters en -grootten) zodat de bestandspaden voor databasebestanden (mdf, ldf) worden gespiegeld, waardoor complicaties tijdens seeding en synchronisatie worden voorkomen. Bekijk Beperkingen (beschikbaarheidsdatabases) voor afwijkende schijfindelingen.

  • Resource Governor-configuratie: Als u resource governor gebruikt, gebruikt u dezelfde resource governor-configuratie op alle exemplaren waarop replica's van de beschikbaarheidsgroep worden gehost.

Machtigingen (Windows-systeem)

Als u een WSFC wilt beheren, moet de gebruiker een systeembeheerder op elk clusterknooppunt zijn.

Zie bijlage A: Vereisten voor failoverclustersvoor meer informatie over het account voor het beheren van het cluster.

Gerelateerde taken (Windows-systeem)

Taak Verbinden
Stel de waarde HostRecordTTL in. HostRecordTTL wijzigen met Windows PowerShell

De HostRecordTTL wijzigen (met behulp van PowerShell)

  1. Open het PowerShell-venster via Als administrator uitvoeren.

  2. Importeer de module FailoverClusters.

  3. Gebruik de cmdlet Get-ClusterResource om de netwerknaamresource te vinden en gebruik vervolgens cmdlet Set-ClusterParameter om de HostRecordTTL--waarde in te stellen:

    Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    In het volgende PowerShell-voorbeeld wordt de HostRecordTTL ingesteld op 300 seconden voor een netwerknaamresource met de naam SQL Network Name (SQL35).

    Import-Module FailoverClusters

$nameResource = "SQL Network Name (SQL35)"
Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300

    Tip

    Telkens wanneer u een nieuw PowerShell-venster opent, moet u de FailoverClusters module importeren.

Gerelateerde inhoud (PowerShell)

Gerelateerde inhoud (Windows-systeem)

Vereisten en beperkingen voor SQL Server-exemplaren

Elke beschikbaarheidsgroep vereist een set failoverpartners, ook wel bekend als beschikbaarheidsreplica's, die worden gehost door exemplaren van SQL Server. Een bepaald serverexemplaar kan een zelfstandige instantie zijn of een SQL Server failoverclusterexemplaar (FCI).

In deze sectie:

Controlelijst: Vereisten (serverexemplaren)

Voorwaarde Koppelingen
De hostcomputer moet een WSFC-knooppunt zijn. De exemplaren van SQL Server die beschikbaarheidsreplica's hosten voor een bepaalde beschikbaarheidsgroep bevinden zich op afzonderlijke knooppunten van het cluster. Een beschikbaarheidsgroep kan tijdelijk over twee clusters gespreid zijn terwijl deze naar een verschillend cluster wordt gemigreerd. SQL Server 2016 (13.x) heeft gedistribueerde beschikbaarheidsgroepen geïntroduceerd. In een gedistribueerde beschikbaarheidsgroep bevinden zich twee beschikbaarheidsgroepen op verschillende clusters. Windows Server-failoverclustering met SQL Server-

Failoverclustering en Always On-beschikbaarheidsgroepen (SQL Server)

gedistribueerde beschikbaarheidsgroepen
Als u wilt dat een beschikbaarheidsgroep werkt met Kerberos:

Alle serverexemplaren die als host fungeren voor een beschikbaarheidsreplica voor de beschikbaarheidsgroep, moeten hetzelfde SQL Server-serviceaccount gebruiken.

De domeinbeheerder moet handmatig een SPN (Service Principal Name) registreren bij Active Directory in het SQL Server-serviceaccount voor de naam van het virtuele netwerk (VNN) van de listener voor de beschikbaarheidsgroep. Als de SPN is geregistreerd voor een ander account dan het SQL Server-serviceaccount, mislukt de verificatie.

Als u Kerberos-verificatie wilt gebruiken voor de communicatie tussen beschikbaarheidsgroepeindpunten (AG), moet u SPN's handmatig registreren voor de eindpunten voor databasespiegeling die door de AG worden gebruikt.

Belangrijk: Als u het SQL Server-serviceaccount wijzigt, moet de domeinbeheerder de SPN handmatig opnieuw registreren.		 Een service-principalnaam registreren voor Kerberos-verbindingen

Opmerking:

Kerberos en SPN's dwingen wederzijdse verificatie af. De SPN wordt toegewezen aan het Windows-account waarmee de SQL Server-services worden gestart. Als de SPN niet juist is geregistreerd of als deze mislukt, kan de Windows-beveiligingslaag het account dat is gekoppeld aan de SPN niet bepalen en kan Kerberos-verificatie niet worden gebruikt.

Opmerking: NTLM heeft deze vereiste niet.
Als u van plan bent om een exemplaar van een SQL Server-failovercluster (FCI) te gebruiken om een beschikbaarheidsreplica te hosten, moet u ervoor zorgen dat u de FCI-beperkingen begrijpt en dat aan de FCI-vereisten wordt voldaan. Vereisten voor het gebruiken van een SQL Server-failoverclusterinstantie (FCI) voor het hosten van een beschikbaarheidsreplica (verderop in dit artikel)
Elke serverinstantie moet dezelfde versie van SQL Server uitvoeren om deel te nemen aan een beschikbaarheidsgroep. Zie de lijst met edities en ondersteunde functies aan het einde van deze sectie voor meer informatie.
Alle serverexemplaren die beschikbaarheidsreplica's hosten voor een beschikbaarheidsgroep, moeten dezelfde SQL Server-sortering gebruiken. de servercollatie instellen of wijzigen
Schakel de functie AlwaysOn-beschikbaarheidsgroepen in op elk serverexemplaar waarop een beschikbaarheidsreplica van elke beschikbaarheidsgroep wordt gehost. Op een bepaalde computer kunt u zoveel serverexemplaren inschakelen voor AlwaysOn-beschikbaarheidsgroepen als uw SQL Server-installatie ondersteunt. Always On-beschikbaarheidsgroep inschakelen of uitschakelen

Belangrijk: Als u een WSFC vernietigt en opnieuw maakt, moet u de functie AlwaysOn-beschikbaarheidsgroepen uitschakelen en opnieuw inschakelen op elk serverexemplaren dat is ingeschakeld voor AlwaysOn-beschikbaarheidsgroepen op het oorspronkelijke cluster.
Voor elk serverexemplaar is een eindpunt voor databasespiegeling vereist. Dit endpoint wordt gedeeld door alle beschikbaarheidsreplica's, partners in databasespiegeling en getuigen op het serverexemplaar.

Als een serverexemplaar dat u selecteert om een beschikbaarheidsreplica te hosten, wordt uitgevoerd onder een domeingebruikersaccount en nog geen eindpunt voor databasespiegeling heeft, kan de Wizard Beschikbaarheidsgroep (SQL Server Management Studio) (of Een replica toevoegen aan uw Always On-beschikbaarheidsgroep met behulp van de wizard Beschikbaarheidsgroep in SQL Server Management) het eindpunt maken en de VERBINDING-permissie verlenen aan het serviceaccount van het serverexemplaar. Als de SQL Server-service echter wordt uitgevoerd als een ingebouwd account, zoals lokaal systeem, lokale service of netwerkservice, of een niet-domeinaccount, moet u certificaten gebruiken voor eindpuntverificatie en kan de wizard geen eindpunt voor databasespiegeling maken op het serverexemplaren. In dit geval raden we u aan de eindpunten voor databasespiegeling handmatig te maken voordat u de wizard start.

Beveiligingsnotitie: Transportbeveiliging voor AlwaysOn-beschikbaarheidsgroepen is hetzelfde als voor databasespiegeling.		 Het Eindpunt voor Databasespiegeling (SQL Server)

TransportBeveiliging - Databasespiegeling - AlwaysOn-beschikbaarheid
Als databases die GEBRUIKMAKEN van FILESTREAM worden toegevoegd aan een beschikbaarheidsgroep, moet u ervoor zorgen dat FILESTREAM is ingeschakeld op elk serverexemplaren waarop een beschikbaarheidsreplica voor de beschikbaarheidsgroep wordt gehost. FILESTREAM- inschakelen en configureren
Als er ingesloten databases worden toegevoegd aan een beschikbaarheidsgroep, moet u ervoor zorgen dat de ingesloten databaseverificatie (serverconfiguratieoptie) is ingesteld op 1 op elke serverinstantie waarop een beschikbaarheidsreplica voor de beschikbaarheidsgroep wordt gehost. bevatte databaseverificatieserverconfiguratie-optie

Server-configuratieopties (SQL Server)

Zie voor een lijst met functies die worden ondersteund door de edities van SQL Server in Windows:

Threadgebruik per beschikbaarheidsgroep

AlwaysOn-beschikbaarheidsgroepen hebben de volgende vereisten voor werkrolthreads:

  • In een niet-actief exemplaar van SQL Server maakt AlwaysOn-beschikbaarheidsgroepen gebruik van 0 threads.

  • Het maximum aantal threads dat door beschikbaarheidsgroepen wordt gebruikt, is de geconfigureerde instelling voor het maximale aantal serverthreads ('maximale werkdraadthreads') minus 40.

  • De beschikbaarheidsreplica's die worden gehost op een bepaald serverexemplaar, delen één threadpool in SQL Server 2019 (15.x) en de eerdere versies.

    Threads worden als volgt op aanvraag gedeeld:

    • Normaal gesproken zijn er 3-10 gedeelde threads, maar dit aantal kan toenemen, afhankelijk van de werkbelasting van de primaire replica.

    • Als een bepaalde thread een tijdje niet actief is, wordt deze weer vrijgegeven in de algemene SQL Server-threadgroep. Normaal gesproken wordt een inactieve thread vrijgegeven na ongeveer 15 seconden inactiviteit. Afhankelijk van de laatste activiteit kan een niet-actieve thread echter langer worden bewaard.

    • Een instantie van SQL Server gebruikt maximaal 100 threads voor parallelle redo bij secundaire replica's. Elke database maakt gebruik van maximaal de helft van het totale aantal CPU-kernen, maar niet meer dan 16 threads per database. Als het totale aantal vereiste threads voor één exemplaar groter is dan 100, gebruikt SQL Server één redo-thread voor elke resterende database. Seriële redo-threads worden vrijgegeven na ongeveer 15 seconden inactiviteit.

  • Bovendien gebruiken beschikbaarheidsgroepen niet-gedeelde threads als volgt:

    • Elke primaire replica maakt gebruik van 1 Logboekopname-thread voor elke primaire database. Daarnaast wordt voor elke secundaire database 1 thread voor het verzenden van logboeken gebruikt. Threads voor het verzenden van logboeken worden vrijgegeven na ongeveer 15 seconden inactiviteit.

    • Een back-up van een secundaire replica houdt een thread vast op de primaire replica gedurende de back-upprocedure.

  • SQL Server 2022 (16.x) heeft de parallelle redo threadpool geïntroduceerd, een exemplaarniveau threadpool die wordt gedeeld met alle databases die redo-werk hebben. Met deze pool kan dezelfde set threads de logboekrecords voor verschillende databases tegelijk verwerken (parallel). In SQL Server 2019 (15.x) en eerdere versies is het aantal beschikbare threads voor redo beperkt tot 100.

  • SQL Server 2019 (15.x) heeft parallelle redo geïntroduceerd voor geheugen-geoptimaliseerde beschikbaarheidsgroepdatabases. In SQL Server 2016 (13.x) en SQL Server 2017 (14.x) worden op schijven gebaseerde tabellen niet parallel opnieuw gebruikt als een database in een beschikbaarheidsgroep ook geoptimaliseerd is voor geheugen.

Zie AlwaysOn - HADRON Learning Series: Werkgroepgebruik voor databases met HADRON-functionaliteit (een CSS SQL Server Engineers-blog) voor meer informatie.

Machtigingen (serverinstantie)

Taak Vereiste toestemmingen
Het eindpunt voor databasespiegeling maken Vereist de machtiging CREATE ENDPOINT of vereist lidmaatschap van de sysadmin vaste serverrol. Hiervoor is ook CONTROL ON ENDPOINT-machtiging vereist. Voor meer informatie, zie Endpoint Machtigingen (Transact-SQL).
AlwaysOn-beschikbaarheidsgroepen inschakelen Vereist lidmaatschap van de Administrator groep op de lokale computer en volledige controle over de WSFC.

Gerelateerde taken (serverinstantie)

Taak Artikel
Bepalen of het eindpunt voor databasespiegeling bestaat sys.database_mirroring_endpoints (Transact-SQL)
Het eindpunt voor databasespiegeling maken (als dit nog niet bestaat) een eindpunt voor databasespiegeling maken voor Windows-verificatie (Transact-SQL)

Certificaten gebruiken voor een eindpunt voor databasespiegeling (Transact-SQL)

een eindpunt voor databasespiegeling maken voor een beschikbaarheidsgroep met behulp van PowerShell
Beschikbaarheidsgroepen inschakelen Always On-beschikbaarheidsgroep functionaliteit in- of uitschakelen

Gerelateerde inhoud (serverexemplaren)

Aanbevelingen voor netwerkconnectiviteit

We raden u ten zeerste aan dezelfde netwerkkoppelingen te gebruiken voor communicatie tussen WSFC-knooppunten en communicatie tussen beschikbaarheidsreplica's. Het gebruik van afzonderlijke netwerkkoppelingen kan onverwacht gedrag veroorzaken als sommige koppelingen mislukken (zelfs onregelmatig).

Als een beschikbaarheidsgroep bijvoorbeeld ondersteuning biedt voor automatische failover, moet de secundaire replica die de partner voor automatische failover is, de status GESYNCHRONISEERD hebben. Als de netwerkkoppeling naar deze secundaire replica mislukt (zelfs af en toe), voert de replica de status UNSYNCHRONIZED in en kan deze pas opnieuw synchroniseren als de koppeling is hersteld. Als de WSFC een automatische failover aanvraagt terwijl de secundaire replica niet is gesynchroniseerd, wordt automatische failover niet uitgevoerd.

Ondersteuning voor clientconnectiviteit

Zie ondersteuning voor stuurprogramma- en clientconnectiviteit voor beschikbaarheidsgroepenvoor informatie over ondersteuning voor AlwaysOn-beschikbaarheidsgroepen voor clientconnectiviteit.

Vereisten en beperkingen voor het gebruik van een instantie van een SQL Server failovercluster (FCI) voor het hosten van een beschikbaarheidsreplica

In deze sectie:

Beperkingen (FCI's)

Notitie

Failover cluster instances (FCI's) ondersteunen geclusterde gedeelde volumes (CSV). Voor meer informatie over CSV, zie Begrip van gedeelde clustervolumes in een failovercluster.

  • De clusterknooppunten van een FCI kunnen slechts één replica hosten voor een bepaalde beschikbaarheidsgroep: Als u een beschikbaarheidsreplica toevoegt aan een FCI, kunnen de WSFC-knooppunten die mogelijk FCI-eigenaren zijn geen andere replica hosten voor dezelfde beschikbaarheidsgroep. Om mogelijke conflicten te voorkomen, is het raadzaam om potentiële eigenaren te configureren voor het failoverclusterexemplaar. Hierdoor wordt voorkomen dat een enkele WSFC probeert twee beschikbaarheidsreplica's voor dezelfde beschikbaarheidsgroep te hosten.

    Bovendien moet elke andere replica worden gehost door een exemplaar van SQL Server dat zich op een ander clusterknooppunt in hetzelfde Windows Server-failovercluster bevindt. De enige uitzondering hierop is dat een beschikbaarheidsgroep tijdens de migratie naar een ander cluster tijdelijk twee clusters kan verwisselen.

    Waarschuwing

    Als u failoverclusterbeheer gebruikt om een FCI die als host fungeert voor een beschikbaarheidsgroep te verplaatsen naar een knooppunt dat al als host fungeert voor een replica van dezelfde beschikbaarheidsgroep, kan dit leiden tot verlies van de replica van de beschikbaarheidsgroep, waardoor deze niet online kan worden gebracht op het doelknooppunt. Eén knooppunt van een failovercluster kan niet meer dan één replica hosten voor dezelfde beschikbaarheidsgroep. Raadpleeg de blog Replica onverwacht verwijderd in de beschikbaarheidsgroepvoor meer informatie over hoe dit kan gebeuren en hoe u hiervan kunt herstellen.

  • FCI's bieden geen ondersteuning voor automatische failover door beschikbaarheidsgroepen: FFA's bieden geen ondersteuning voor automatische failover op beschikbaarheidsgroepen, zodat elke beschikbaarheidsreplica die wordt gehost door een FCI alleen kan worden geconfigureerd voor handmatige failover.

  • FCI-netwerknaam wijzigen: Als u de netwerknaam van een FCI wilt wijzigen die als host fungeert voor een beschikbaarheidsreplica, moet u de replica verwijderen uit de beschikbaarheidsgroep en vervolgens de replica weer toevoegen aan de beschikbaarheidsgroep. U kunt de primaire replica niet verwijderen, dus als u de naam van een FCI wijzigt die als host fungeert voor de primaire replica, moet u een failover uitvoeren naar een secundaire replica en vervolgens de voormalige primaire replica verwijderen en deze weer toevoegen. Als u de naam van een FCI wijzigt, kan de URL van het eindpunt voor databasespiegeling worden gewijzigd. Wanneer u de replica toevoegt, moet u ervoor zorgen dat u de huidige eindpunt-URL opgeeft.

Controlelijst: Vereisten (FCI's)

Voorwaarde Verbinden
Zorg ervoor dat elk exemplaar van een SQL Server-failovercluster (FCI) beschikt over de vereiste gedeelde opslag volgens de standaardinstallatie van het SQL Server-failovercluster.

Gerelateerde taken (FCI's)

Taak Artikel
Een SQL Server FCI installeren Een nieuw Always On-failoverclusterexemplaar (Instelling) maken
In-place upgrade van uw bestaande SQL Server FCI een failoverclusterinstantie upgraden
Uw bestaande SQL Server FCI onderhouden Knooppunten toevoegen aan of verwijderen uit een failoverclusterexemplaar (Setup)

Gerelateerde inhoud (FCIs)

Vereisten en beperkingen voor beschikbaarheidsgroepen

In deze sectie:

Beperkingen (beschikbaarheidsgroepen)

  • Beschikbaarheidsreplica's moeten worden gehost door verschillende knooppunten van één WSFC: Voor een bepaalde beschikbaarheidsgroep moeten beschikbaarheidsreplica's worden gehost door serverexemplaren die worden uitgevoerd op verschillende knooppunten van hetzelfde WSFC. De enige uitzondering hierop is dat een beschikbaarheidsgroep tijdens de migratie naar een ander cluster tijdelijk twee clusters kan verwisselen.

    Notitie

    Virtuele machines op dezelfde fysieke computer kunnen elk een beschikbaarheidsreplica hosten voor dezelfde beschikbaarheidsgroep, omdat elke virtuele machine fungeert als een afzonderlijke computer.

  • unieke naam van de beschikbaarheidsgroep: Elke naam van elke beschikbaarheidsgroep moet uniek zijn op de WSFC. De maximale lengte voor de naam van een beschikbaarheidsgroep is 128 tekens.

  • Beschikbaarheidsreplica's: Elke beschikbaarheidsgroep ondersteunt één primaire replica en maximaal acht secundaire replica's. Alle replica's kunnen worden uitgevoerd onder de asynchrone doorvoermodus of maximaal vijf replica's kunnen worden uitgevoerd in de synchrone doorvoermodus (één primaire replica met twee synchrone secundaire replica's). Elke replica moet een unieke servernaam hebben in Zowel Windows als SQL Server. De servernamen tussen Windows en SQL Server moeten overeenkomen.

  • Maximum aantal beschikbaarheidsgroepen en beschikbaarheidsdatabases per computer: Het werkelijke aantal databases en beschikbaarheidsgroepen dat u op een computer (VM of fysiek) kunt plaatsen, is afhankelijk van de hardware en workload, maar er is geen afgedwongen limiet. Microsoft heeft maximaal 10 AG's en 100 DB's per fysieke machine getest, maar dit is geen bindingslimiet. Afhankelijk van de hardwarespecificatie op de server en de workload kunt u een hoger aantal databases en beschikbaarheidsgroepen op een exemplaar van SQL Server plaatsen. Tekenen van overbelaste systemen kunnen omvatten, maar zijn niet beperkt tot, werkthreaduitputting, trage reactietijden voor systeemweergaven van beschikbaarheidsgroepen en DMV's en/of vastgelopen dispatchersysteemdumps. Zorg ervoor dat u uw omgeving grondig test met een productieachtige workload om ervoor te zorgen dat deze piekcapaciteit van de werkbelasting binnen uw toepassings-SLA's kan verwerken. Bij het overwegen van SLA's moet u rekening houden met belasting onder foutomstandigheden en verwachte reactietijden.

  • gebruik failoverclusterbeheer niet om beschikbaarheidsgroepen te bewerken. De status van een SQL Server FCI wordt gedeeld tussen SQL Server en het Windows Server Failover Cluster (WSFC), waarbij SQL Server gedetailleerdere statusinformatie over de exemplaren bewaart dan het cluster belangrijk vindt. Het beheermodel is dat SQL Server de transacties moet aandrijven en verantwoordelijk is voor het houden van de status van het cluster, gesynchroniseerd met de statusweergave van SQL Server. Als de status van het cluster wordt gewijzigd buiten SQL Server, is het mogelijk dat de status niet meer wordt gesynchroniseerd tussen WSFC en SQL Server, wat kan leiden tot onvoorspelbaar gedrag.

    Bijvoorbeeld:

    • Wijzig geen eigenschappen van beschikbaarheidsgroepen, zoals de mogelijke eigenaren.

    • Gebruik failoverclusterbeheer niet om een failover van beschikbaarheidsgroepen uit te voeren. U moet Transact-SQL of SQL Server Management Studio gebruiken.

  • Geen resources toevoegen of afhankelijkheden wijzigen die zijn gekoppeld aan de rol van beschikbaarheidsgroep. We raden u niet aan extra resources (inclusief gebruiker of derde partij) in de rol van beschikbaarheidsgroep te plaatsen of de rolafhankelijkheden te wijzigen, omdat deze wijzigingen een negatieve invloed kunnen hebben op de failoverprestaties.

Vereisten (beschikbaarheidsgroepen)

Wanneer u een configuratie van een beschikbaarheidsgroep maakt of opnieuw configureert, moet u ervoor zorgen dat u voldoet aan de volgende vereisten.

Voorwaarde Beschrijving
Als u van plan bent om een exemplaar van een SQL Server-failovercluster (FCI) te gebruiken om een beschikbaarheidsreplica te hosten, moet u ervoor zorgen dat u de FCI-beperkingen begrijpt en dat aan de FCI-vereisten wordt voldaan. vereisten en beperkingen voor het gebruik van een exemplaar van een SQL Server-failovercluster (FCI) voor het hosten van een beschikbaarheidsreplica (eerder in dit artikel)

Beveiliging (beschikbaarheidsgroepen)

  • Beveiliging wordt overgenomen van de WSFC. Windows Server-failoverclustering biedt twee niveaus van gebruikersbeveiliging op de granulariteit van het hele cluster:

    • Alleen-lezentoegang

    • Volledig beheer

      AlwaysOn-beschikbaarheidsgroepen hebben volledige controle nodig en het inschakelen van AlwaysOn-beschikbaarheidsgroepen op een exemplaar van SQL Server geeft het volledige beheer van het cluster (via service-SID).

      U kunt geen beveiliging voor een serverinstantie rechtstreeks toevoegen of verwijderen van Clusterbeheer. Als u clusterbeveiligingssessies wilt beheren, gebruikt u SQL Server Configuration Manager of het WMI-equivalent van SQL Server.

  • Elk exemplaar van SQL Server moet machtigingen hebben voor toegang tot het register, het cluster enzovoort.

  • We raden u aan versleuteling te gebruiken voor verbindingen tussen serverexemplaren die beschikbaarheidsreplica's van AlwaysOn-beschikbaarheidsgroepen hosten.

Machtigingen (beschikbaarheidsgroepen)

Taak Vereiste machtigingen
Een beschikbaarheidsgroep maken Vereist lidmaatschap van de sysadmin vaste serverrol en de machtiging om AVAILABILITY GROUPS te maken, de machtiging om ENIGE AVAILABILITY GROUPS te wijzigen, of SERVERcontrole-machtiging.
Een beschikbaarheidsgroep wijzigen Hiervoor is de machtiging ALTER AVAILABILITY GROUP vereist voor de beschikbaarheidsgroep, de machtiging CONTROL AVAILABILITY GROUP, de machtiging ALTER ANY AVAILABILITY GROUP of de machtiging CONTROL SERVER.

Bovendien vereist het toevoegen van een database aan een beschikbaarheidsgroep lidmaatschap van de db_owner vaste databaserol.
Een beschikbaarheidsgroep verwijderen/uitschakelen Hiervoor is machtiging voor ALTER AVAILABILITY GROUP vereist op de beschikbaarheidsgroep, machtiging voor CONTROL AVAILABILITY GROUP, machtiging voor ALTER ANY AVAILABILITY GROUP of machtiging voor CONTROL SERVER. Als u een beschikbaarheidsgroep wilt verwijderen die niet wordt gehost op de lokale replicalocatie, hebt u de machtiging CONTROL SERVER of CONTROL-machtiging voor die beschikbaarheidsgroep nodig.

Gerelateerde taken (beschikbaarheidsgroepen)

Taak Artikel
Een beschikbaarheidsgroep maken Gebruik de wizard Beschikbaarheidsgroep (SQL Server Management Studio)

Een AlwaysOn-beschikbaarheidsgroep maken met behulp van Transact-SQL (T-SQL)

Een AlwaysOn-beschikbaarheidsgroep maken met behulp van PowerShell

Eindpunt-URL opgeven: beschikbaarheidsreplica toevoegen of wijzigen
Het aantal beschikbaarheidsreplica's wijzigen een secundaire replica toevoegen aan een AlwaysOn-beschikbaarheidsgroep

een secundaire replica toevoegen aan een AlwaysOn-beschikbaarheidsgroep

Verwijder een secundaire replica van een Beschikbaarheidsgroep (SQL Server)
Een listener voor een beschikbaarheidsgroep maken een listener configureren voor een AlwaysOn-beschikbaarheidsgroep
Een beschikbaarheidsgroep verwijderen Een beschikbaarheidsgroep (SQL Server) verwijderen

Vereisten en beperkingen voor beschikbaarheidsdatabases

Als u in aanmerking wilt komen voor een beschikbaarheidsgroep, moet een database voldoen aan de volgende vereisten en beperkingen.

In deze sectie:

Controlelijst: Vereisten (beschikbaarheidsdatabases)

Als u in aanmerking wilt komen om aan een beschikbaarheidsgroep toe te voegen, moet een database:

Eisen Verbinden
Wees een gebruikersdatabase. Systeemdatabases kunnen niet tot een beschikbaarheidsgroep behoren.
Bevindt zich op het exemplaar van SQL Server waar u de beschikbaarheidsgroep maakt en toegankelijk is voor het serverexemplaren.
Wees een database voor lezen/schrijven. Alleen-lezen-databases kunnen niet worden toegevoegd aan een beschikbaarheidsgroep. sys.databases (is_read_only = 0)
Wees een database voor meerdere gebruikers. sys.databases (user_access = 0)
Gebruik AUTO_CLOSE niet. sys.databases (is_auto_close_on = 0)
Gebruik het volledige herstelmodel. sys.databases (recovery_model = 1)
Beschikt over ten minste één volledige databaseback-up.

Opmerking: Nadat u een database hebt ingesteld op een volledig herstelmodel, is een volledige back-up vereist om de logboekketen voor volledig herstel te starten.		 een volledige databaseback-up maken
Behoort niet tot een bestaande beschikbaarheidsgroep. sys.databases (group_database_id = NULL)
Niet geconfigureerd voor databasespiegeling. sys.database_mirroring (als de database niet deelneemt aan spiegeling, zijn alle kolommen met het voorvoegsel 'mirroring_' NULL.)
Voordat u een database toevoegt die FILESTREAM gebruikt voor een beschikbaarheidsgroep, moet u ervoor zorgen dat FILESTREAM is ingeschakeld op elk serverexemplaar dat als host fungeert of zal fungeren voor een beschikbaarheidsreplica voor de beschikbaarheidsgroep. FILESTREAM- inschakelen en configureren
Voordat u een ingesloten database toevoegt aan een beschikbaarheidsgroep, moet u ervoor zorgen dat de optie ingesloten databaseverificatie server is ingesteld op 1 op elke serverinstantie die een beschikbaarheidsreplica voor de beschikbaarheidsgroep host of zal hosten. bevatten optie voor serverconfiguratie van databaseverificatie

Server-configuratieopties (SQL Server)

Notitie

AlwaysOn-beschikbaarheidsgroepen werken met elk ondersteund databasecompatibiliteitsniveau.

Beperkingen (beschikbaarheidsdatabases)

  • Als het bestandspad (inclusief de stationsletter) van een secundaire database verschilt van het pad van de bijbehorende primaire database, gelden de volgende beperkingen:

    • wizard Nieuwe beschikbaarheidsgroep/Wizard Database toevoegen aan beschikbaarheidsgroep: De optie Volledige wordt niet ondersteund (op de pagina Initiële gegevenssynchronisatiepagina selecteren (Wizards voor AlwaysOn-beschikbaarheidsgroep) pagina),

    • RESTORE WITH MOVE: Om de secundaire databases te maken, moeten de databasebestanden WORDEN HERSTELD MET DE OPTIE VERPLAATSEN op elk exemplaar van SQL Server dat een secundaire replica host.

    • Invloed op bewerkingen van invoegtoepassingen: Een latere bewerking voor het toevoegen van bestanden op de primaire replica kan mislukken op de secundaire databases. Deze fout kan ertoe leiden dat de secundaire databases worden onderbroken. Dit zorgt ervoor dat de secundaire replica's op hun beurt de status NIET SYNCHRONISEREN aannemen.

      Notitie

      Voor informatie over het reageren op een mislukte ad-bestandsbewerking, zie Problemen oplossen bij een mislukte Add-File-bewerking (Always On-beschikbaarheidsgroepen).

  • U kunt een database die momenteel deel uitmaakt van een beschikbaarheidsgroep niet verwijderen.

Vervolgacties voor TDE-beveiligde databases

Als u TDE (Transparent Data Encryption) gebruikt, moet het certificaat of de asymmetrische sleutel voor het maken en ontsleutelen van andere sleutels hetzelfde zijn op elk serverexemplaren waarop een beschikbaarheidsreplica voor de beschikbaarheidsgroep wordt gehost. Zie Een met TDE beveiligde database verplaatsen naar een andere SQL Server-voor meer informatie.

Machtigingen (databases voor beschikbaarheid)

Vereist ALTER-machtigingen voor de database.

Gerelateerde taken (beschikbaarheidsdatabase)

Taak Artikel
Een secundaire database voorbereiden (handmatig) een secundaire database voorbereiden voor een AlwaysOn-beschikbaarheidsgroep
Een secundaire database toevoegen aan een beschikbaarheidsgroep (handmatig) een secundaire database toevoegen aan een AlwaysOn-beschikbaarheidsgroep
Het aantal beschikbaarheidsdatabases wijzigen een database toevoegen aan een AlwaysOn-beschikbaarheidsgroep

Een secundaire database verwijderen uit een SQL Server-beschikbaarheidsgroep

een primaire database verwijderen uit een AlwaysOn-beschikbaarheidsgroep

Verwante inhoud