Bedrijfscontinuïteit en databaseherstel - SQL Server op Linux

Van toepassing op:SQL Server - Linux

Dit artikel bevat een overzicht van bedrijfscontinuïteitsoplossingen voor hoge beschikbaarheid en herstel na noodgevallen in SQL Server, in Windows en Linux.

Een veelvoorkomende taak voor iedereen die SQL Server implementeert, is ervoor zorgen dat alle essentiële SQL Server-exemplaren en de databases daarin beschikbaar zijn wanneer het bedrijf en de eindgebruikers ze nodig hebben, of dat nu van 9 tot 5 is of de klok rond. Het doel is om het bedrijf actief te houden met minimale of geen onderbreking. Dit concept wordt ook wel bedrijfscontinuïteit genoemd.

SQL Server 2017 (14.x) heeft veel nieuwe functies of verbeteringen geïntroduceerd in bestaande functies, waarvan sommige beschikbaar zijn. De grootste toevoeging aan SQL Server 2017 (14.x) was ondersteuning voor SQL Server op Linux-distributies. Zie de volgende artikelen voor een volledige lijst met de nieuwe functies in SQL Server:

• Wat is nieuw in SQL Server 2017
• Wat is er nieuw voor SQL Server 2017 in Linux
• nieuwe functies in SQL Server 2019
• Wat is er nieuw voor SQL Server 2019 in Linux
• Wat is er nieuw in SQL Server 2022

Dit artikel is gericht op het bespreken van de beschikbaarheidsscenario's in SQL Server 2017 (14.x) en latere versies, evenals de nieuwe en verbeterde beschikbaarheidsfuncties. De scenario's omvatten hybride implementaties die SQL Server-implementaties kunnen omvatten op zowel Windows Server als Linux, en degenen die het aantal leesbare kopieën van een database kunnen verhogen.

Hoewel dit artikel geen betrekking heeft op beschikbaarheidsopties buiten SQL Server, zoals die worden geleverd door virtualisatie, is alles wat hier wordt besproken van toepassing op SQL Server-installaties binnen een virtuele gastmachine, ongeacht of deze zich in de openbare cloud bevinden of worden gehost door een on-premises hypervisorserver.

SQL Server-scenario's met behulp van de beschikbaarheidsfuncties

AlwaysOn-beschikbaarheidsgroepen, AlwaysOn-failoverclusterexemplaren en logboekverzending kunnen op verschillende manieren worden gebruikt en niet noodzakelijkerwijs alleen voor beschikbaarheidsdoeleinden. Er zijn vier manieren waarop de beschikbaarheidsfuncties kunnen worden gebruikt:

• Hoge beschikbaarheid
• Herstel na een ramp
• Migraties en upgrades
• Leesbare kopieën van een of meer databases uitschalen

In de volgende secties worden de relevante functies besproken die voor dat specifieke scenario kunnen worden gebruikt. De ene functie die niet wordt behandeld, is SQL Server-replicatie. Hoewel sql Server-replicatie niet officieel is aangewezen als een beschikbaarheidsfunctie onder de paraplu van AlwaysOn, wordt sql Server vaak gebruikt voor het redundant maken van gegevens in bepaalde scenario's. Samenvoegreplicatie wordt niet ondersteund voor SQL Server in Linux. Zie SQL Server-replicatie in Linux voor meer informatie.

Hoge beschikbaarheid

Het is belangrijk om ervoor te zorgen dat SQL Server-exemplaren of -databases beschikbaar zijn in het geval van een probleem dat lokaal is in een datacenter of één regio in de cloud. In deze sectie wordt beschreven hoe de SQL Server-beschikbaarheidsfuncties u kunnen helpen bij die taak. Alle beschreven functies zijn zowel beschikbaar op Windows Server als in Linux.

Beschikbaarheidsgroepen

Beschikbaarheidsgroepen (AG's) die zijn geïntroduceerd in SQL Server 2012 (11.x), bieden beveiliging op databaseniveau door elke transactie van een database naar een ander exemplaar of replica te verzenden, die een kopie van die database in een speciale status bevat. Een AG kan worden geïmplementeerd in Standard- of Enterprise-edities. De exemplaren die deelnemen aan een AG, kunnen zelfstandige exemplaren of failoverclusterexemplaren zijn (CCI's, zoals beschreven in de volgende sectie). Omdat de transacties naar een replica worden verzonden terwijl ze plaatsvinden, worden AG's aanbevolen wanneer er vereisten zijn voor lagere beoogde herstelpunten en hersteltijd. Gegevensverplaatsing tussen replica's kan synchroon of asynchroon zijn, waarbij de Enterprise-editie het mogelijk maakt om maximaal drie replica's (inclusief de primaire) synchroon in te stellen. Een AG heeft één volledig lees-/schrijfkopie van de database die zich op de primaire replica bevindt, terwijl alle secundaire replica's geen transacties rechtstreeks van eindgebruikers of toepassingen kunnen ontvangen.

Vóór SQL Server 2022 (16.x) bieden AG's alleen beveiliging op databaseniveau en niet op exemplaarniveau. Alles wat niet is vastgelegd in het transactielogboek of geconfigureerd in de database, moet handmatig worden gesynchroniseerd voor elke secundaire replica. Enkele voorbeelden van objecten die handmatig moeten worden gesynchroniseerd, zijn aanmeldingen op exemplaarniveau, gekoppelde servers en SQL Server Agent-taken.

In SQL Server 2022 (16.x) en latere versies kunt u metagegevensobjecten beheren, waaronder gebruikers, aanmeldingen, machtigingen en SQL Server Agent-taken op ag-niveau, naast het exemplaarniveau. Zie Wat is een ingesloten beschikbaarheidsgroep?

Een AG heeft ook een ander onderdeel genaamd de listener, waarmee toepassingen en eindgebruikers verbinding kunnen maken zonder te hoeven weten welk SQL Server-exemplaar als host fungeert voor de primaire replica. Elke AG zou een eigen listener hebben. Hoewel de implementaties van de listener enigszins verschillen in Windows Server versus Linux, is de functionaliteit die wordt geboden en hoe deze wordt gebruikt, hetzelfde. In het volgende diagram ziet u een windows Server-beschikbaarheidsgroep die gebruikmaakt van een Windows Server-failovercluster (WSFC). Een onderliggend cluster op de besturingssysteemlaag is vereist voor beschikbaarheid, ongeacht of het zich in Linux of Windows Server bevindt. In het voorbeeld ziet u een eenvoudige configuratie met twee servers of knooppunten, met een WSFC als het onderliggende cluster.

Standard en Enterprise Edition hebben verschillende maximumlimieten als het gaat om replica's. Een AG in Standard-editie, ook wel een standaard beschikbaarheidsgroep genoemd, ondersteunt twee replica's (één primaire en één secundaire) met slechts één database in de beschikbaarheidsgroep. Met Enterprise Edition kunnen niet alleen meerdere databases worden geconfigureerd in één beschikbaarheidsgroep, maar ook maximaal negen totale replica's (één primaire, acht secundaire replica's). Enterprise Edition biedt ook andere optionele voordelen, zoals leesbare secundaire replica's, de mogelijkheid om back-ups te maken van een secundaire replica en meer.

Als het gaat om beschikbaarheid, kunnen AG's automatische of handmatige failover bieden. Automatische failover kan optreden als synchrone gegevensverplaatsing is geconfigureerd en de database op de primaire en secundaire replica een gesynchroniseerde status heeft. Zolang de listener wordt gebruikt en de toepassing een latere versie van .NET Framework (3.5 met een update of 4.0 en hoger) gebruikt, moet de failover worden verwerkt met minimaal tot geen effect op eindgebruikers als een listener wordt gebruikt. Als u een failover naar een secundaire replica uitvoert, kan de nieuwe primaire replica zodanig worden geconfigureerd dat deze automatisch of handmatig is en over het algemeen in seconden wordt gemeten.

In de volgende lijst ziet u enkele verschillen met AG's in Windows Server versus Linux:

• Vanwege verschillen in de manier waarop het onderliggende cluster werkt op Linux en Windows Server, worden alle failovers (handmatig of automatisch) van AG's uitgevoerd via het cluster op Linux. In windows Server-ag-implementaties moeten handmatige failovers worden uitgevoerd via SQL Server. Automatische failovers worden verwerkt door het onderliggende cluster op zowel Windows Server als Linux.
• Voor SQL Server in Linux is de aanbevolen configuratie voor AG's minimaal drie replica's. Dit komt door de manier waarop de onderliggende clustering werkt.
• In Linux wordt de algemene naam die door elke listener wordt gebruikt, gedefinieerd in DNS en niet in het cluster, zoals in Windows Server.

SQL Server 2017 (14.x) introduceert de volgende functies en verbeteringen in AG's:

• Clustertypen
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Verbeterde DTC-ondersteuning (Microsoft Distributor Transaction Coordinator) voor configuraties op basis van Windows Server
• Aanvullende uitschaalscenario's voor read-only-databases (verderop in dit artikel beschreven)

Clustertypen van beschikbaarheidsgroep

De ingebouwde beschikbaarheidsvorm van clustering in Windows Server is ingeschakeld via een functie met de naam FailoverClustering. Hiermee kunt u een WSFC bouwen voor gebruik met een AG of FCI. Integratie voor AG's en FCI's wordt geleverd door clusterbewuste resource-DLL's die worden verzonden door SQL Server.

SQL Server op Linux ondersteunt meerdere clusteringtechnologieën. Microsoft ondersteunt de SQL Server-onderdelen, terwijl onze partners de relevante clusteringtechnologie ondersteunen. Sql Server op Linux ondersteunt bijvoorbeeld HPE Serviceguard en DH2i DxEnterprise als clusteroplossing, samen met Pacemaker.

Een Windows-failovercluster en Linux-clusteroplossing zijn vergelijkbaarer dan anders. Beide bieden een manier om afzonderlijke servers te nemen en te combineren in een configuratie om beschikbaarheid te bieden en concepten te hebben van zaken als resources, beperkingen (zelfs als ze anders zijn geïmplementeerd), failover enzovoort.

Als u bijvoorbeeld Pacemaker wilt ondersteunen voor zowel AG- als FCI-configuraties, waaronder zaken als automatische failover, biedt Microsoft het mssql-server-ha pakket, dat vergelijkbaar is met, maar niet precies hetzelfde is als de resource-DLL's in een WSFC, voor Pacemaker. Een van de verschillen tussen een WSFC en Pacemaker is dat er geen netwerknaamresource in Pacemaker is. Dit is het onderdeel waarmee de naam van de listener (of de naam van de FCI) op een WSFC kan worden geabstraheerd. DNS verzorgt naamomzetting op Linux.

Vanwege het verschil in de clusterstack moeten er enkele wijzigingen worden aangebracht voor AG's, omdat SQL Server enkele metagegevens moet verwerken die systeemeigen worden verwerkt door een WSFC. Een dergelijke belangrijke wijziging is de introductie van een clustertype voor een beschikbaarheidsgroep. Dit wordt opgeslagen in sys.availability_groups de cluster_type en cluster_type_desc kolommen. Er zijn drie clustertypen:

• WSFC
• Extern
• Geen

Alle AG's waarvoor hoge beschikbaarheid is vereist, moeten gebruikmaken van een onderliggend cluster. In het geval van SQL Server 2017 (14.x) en latere versies betekent WSFC of een Linux-clusteringagent. Voor Windows Server-AG's die gebruikmaken van een onderliggende WSFC, is het standaardclustertype WSFC en hoeft niet te worden ingesteld. Bij het maken van een Linux-gebaseerde beschikbaarheidsgroep (AG) moet het clustertype worden ingesteld op extern. De integratie met een externe clusteroplossing in Linux wordt geconfigureerd nadat de beschikbaarheidsgroep (AG) is gemaakt, terwijl dit bij de creatie van een Failovercluster van Windows Server (WSFC) gebeurt.

Een clustertype Geen kan worden gebruikt met zowel Windows Server als Linux AG's. Als het clustertype is ingesteld op Geen, heeft de beschikbaarheidsgroep geen onderliggend cluster nodig. Dit betekent dat SQL Server 2017 (14.x) de eerste versie van SQL Server is ter ondersteuning van AG's zonder een cluster, maar het nadeel is dat deze configuratie niet wordt ondersteund als een oplossing voor hoge beschikbaarheid.

Voor degenen die alleen extra alleen-lezen kopieën van een database willen toevoegen, of zoals wat een AG biedt voor migratie/upgrades, maar niet willen worden gekoppeld aan de extra complexiteit van een onderliggend cluster of zelfs de replicatie, is een AG met het clustertype None een perfecte oplossing. Zie de secties Migraties en upgrades enleesschaal voor meer informatie.

In de volgende schermopname ziet u de ondersteuning voor de verschillende soorten clustertypen in SQL Server Management Studio (SSMS). U moet versie 17.1 of hoger uitvoeren. De volgende schermafbeelding volgt uit versie 17.2:

VEREIST_GESYNCHRONISEERDE_SECONDARIES_OM_TE_COMMITTEREN

SQL Server 2016 (13.x) verbeterde ondersteuning voor het aantal synchrone replica's van twee tot drie in enterprise-editie. Echter, als een secundaire replica was gesynchroniseerd, maar de andere een probleem had, was er geen manier om het gedrag te beheren en de primaire te laten wachten op de defecte replica of toe te staan verder te gaan. Dit betekent dat de primaire replica op een bepaald moment schrijfverkeer blijft ontvangen, ook al heeft de secundaire replica geen gesynchroniseerde status, wat betekent dat er gegevensverlies is op de secundaire replica.

In SQL Server 2017 (14.x) en latere versies kunt u het gedrag bepalen van wat er gebeurt wanneer er synchrone replica's zijn met REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Deze optie werkt als volgt:

• Er zijn drie mogelijke waarden: 0, 1en 2
• De waarde is het aantal secundaire replica's dat moet worden gesynchroniseerd, wat gevolgen heeft voor gegevensverlies, beschikbaarheid van ag's en failover
• Voor WSFCs en een clustertype "None" is de standaardwaarde 0, en kan deze handmatig worden ingesteld op 1 of 2.
• Voor een clustertype Extern wordt deze waarde standaard ingesteld door het clustermechanisme en kan deze handmatig worden overschreven. Voor drie synchrone replica's is 1de standaardwaarde.

Op Linux wordt de waarde voor REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT geconfigureerd op de AG-resource in het cluster. In Windows wordt deze ingesteld via Transact-SQL.

Een waarde die hoger is dan 0 zorgt voor een hogere gegevensbeveiliging, omdat als het vereiste aantal secundaire replica's niet beschikbaar is, de primaire waarde pas beschikbaar is als dat is opgelost. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT is ook van invloed op het failovergedrag, omdat automatische failover niet kan optreden als het juiste aantal secundaire replica's niet de juiste status heeft. Op Linux zal een waarde van 0 automatische failover niet toestaan. Daarom moet bij gebruik van synchrone replicatie met automatische failover de waarde hoger worden ingesteld dan 0 om automatische failover te bereiken. 0 op Windows Server is het gedrag in SQL Server 2016 (13.x) en eerdere versies.

Verbeterde ondersteuning voor Microsoft Distributed Transaction Coordinator

Vóór SQL Server 2016 (13.x) was de enige manier om beschikbaarheid te krijgen in SQL Server voor toepassingen waarvoor gedistribueerde transacties zijn vereist, die gebruikmaken van DTC onder de dekkingen, was het implementeren van GCI's. Een gedistribueerde transactie kan op twee manieren worden uitgevoerd:

• Een transactie die meer dan één database omvat in hetzelfde SQL Server-exemplaar
• Een transactie die meer dan één SQL Server-exemplaar omvat of mogelijk een niet-SQL Server-gegevensbron omvat

SQL Server 2016 (13.x) introduceerde gedeeltelijke ondersteuning voor DTC met AG's die het laatste scenario behandelden. SQL Server 2017 (14.x) voltooit het verhaal door beide scenario's met DTC te ondersteunen.

In SQL Server 2017 (14.x) en latere versies kan DTC-ondersteuning ook worden toegevoegd aan een AG nadat deze is gemaakt. In SQL Server 2016 (13.x) kan het inschakelen van ondersteuning voor DTC naar een AG alleen worden uitgevoerd wanneer de beschikbaarheidsgroep is gemaakt.

Exemplaren van failover-clusters

Geclusterde installaties zijn sinds versie 6.5 een functie van SQL Server. FCI's zijn een bewezen methode voor het bieden van beschikbaarheid voor de volledige installatie van SQL Server, ook wel een instantie genoemd. Dit betekent dat alles binnen het exemplaar, inclusief databases, SQL Server Agent-taken, gekoppelde servers, enzovoort, naar een andere server wordt verplaatst als de onderliggende server een probleem ondervindt. Voor alle GCI's is een soort gedeelde opslag vereist, zelfs als deze via netwerken wordt geleverd. De bronnen van de FCI kunnen op elk moment slechts actief zijn en eigendom zijn van één knooppunt. In het volgende diagram is het eerste knooppunt van het cluster eigenaar van de FCI, wat ook betekent dat het eigenaar is van de gedeelde opslagbronnen die eraan zijn gekoppeld door de ononderbroken lijn naar de opslag.

Na een failover verandert het eigendom zoals wordt weergegeven in het volgende diagram:

Er is geen gegevensverlies met een FCI, maar de onderliggende gedeelde opslag is een enkelvoudig storingspunt omdat er één kopie van de gegevens is. GCI's worden vaak gecombineerd met een andere beschikbaarheidsmethode, zoals een beschikbaarheidsgroep of logboekverzending, om redundante kopieën van databases te hebben. De geïmplementeerde extra methode moet fysiek gescheiden opslag van de FCI gebruiken. Wanneer de FCI een failover naar een ander knooppunt uitvoert, stopt deze op het ene knooppunt en begint het op een ander knooppunt, vergelijkbaar met het uitschakelen van een server en het inschakelen ervan. Een FCI doorloopt het normale herstelproces, wat betekent dat transacties die moeten worden doorgeschoven, dat zullen worden, en alle transacties die onvolledig zijn, worden teruggedraaid. Daarom is de database consistent van een gegevenspunt tot het tijdstip van de fout of handmatige failover, waardoor er geen gegevensverlies is. Databases zijn alleen beschikbaar nadat het herstel is voltooid, dus de hersteltijd is afhankelijk van veel factoren, en is over het algemeen langer dan het uitvoeren van een failover van een AG. Het nadeel is dat wanneer u een failover uitvoert van een beschikbaarheidsgroep, er mogelijk extra taken nodig zijn om een database bruikbaar te maken, zoals het inschakelen van een SQL Server Agent-taak.

Net als een AG abstraheren FCI's welk knooppunt van het onderliggende cluster deze host. Een FCI behoudt altijd dezelfde naam. Toepassingen en eindgebruikers maken nooit verbinding met de knooppunten; de unieke naam die aan de FCI is toegewezen, wordt gebruikt. Een FCI kan deelnemen aan een AG als een van de exemplaren die een primaire of secundaire replica hosten.

In de volgende lijst worden enkele verschillen met CCI's in Windows Server vergeleken met Linux:

• Op Windows Server maakt een FCI deel uit van het installatieproces. Een FCI in Linux wordt geconfigureerd na de installatie van SQL Server.
• Linux ondersteunt slechts één installatie van SQL Server per host, dus alle FCI's zijn de standaardexemplaren. Windows Server ondersteunt maximaal 25 FCI's per WSFC.
• De algemene naam die wordt gebruikt door CCI's in Linux, wordt gedefinieerd in DNS en moet dezelfde zijn als de resource die voor de FCI is gemaakt.

Logboekverzending

Als de doelstellingen voor herstelpunten en hersteltijden flexibeler zijn of databases niet als zeer bedrijfskritiek worden beschouwd, is logboekverzending een andere bewezen beschikbaarheidsfunctie in SQL Server. Op basis van de systeemeigen back-ups van SQL Server genereert het proces voor het verzenden van logboeken automatisch back-ups van transactielogboeken, kopieert deze naar een of meer exemplaren die bekend staan als een warme stand-by. De back-ups van het transactielogboek worden automatisch op die stand-by toegepast. Logboekverzending maakt gebruik van SQL Server Agent-taken om het proces voor het maken van back-ups, het kopiëren en toepassen van de back-ups van het transactielogboek te automatiseren.

Het grootste voordeel van het gebruik van log shipping op een bepaalde manier is dat het rekening houdt met menselijke fouten. De toepassing van transactielogboeken kan worden vertraagd. Als iemand iets als een UPDATEWHERE zonder component uitgeeft, heeft de stand-by mogelijk niet de wijziging, zodat u kunt overschakelen terwijl u het primaire systeem herstelt. Hoewel logboekverzending eenvoudig te configureren is, is overschakelen van de primaire naar een warme stand-by, ook wel een rolwijziging genoemd, altijd handmatig. Een rolwijziging wordt gestart via Transact-SQL en net als een AG moeten alle objecten die niet in het transactielogboek zijn vastgelegd, handmatig worden gesynchroniseerd. Logboekverzending moet ook per database worden geconfigureerd, terwijl één beschikbaarheidsgroep meerdere databases kan bevatten.

In tegenstelling tot een AG of FCI heeft logboekverzending geen abstractie voor een rolwijziging, die toepassingen moeten kunnen verwerken. Technieken zoals een DNS-alias (CNAME) kunnen worden gebruikt, maar er zijn voor- en nadelen, zoals de tijd die het kost om DNS na de switch te vernieuwen.

Herstel na een ramp

Wanneer uw primaire beschikbaarheidslocatie een catastrofale gebeurtenis ondervindt, zoals een aardbeving of overstroming, moet het bedrijf zijn voorbereid om zijn systemen elders online te laten komen. In deze sectie wordt beschreven hoe de sql Server-beschikbaarheidsfuncties kunnen helpen bij bedrijfscontinuïteit.

Beschikbaarheidsgroepen

Een van de voordelen van AG's is dat zowel hoge beschikbaarheid als herstel na noodgevallen kunnen worden geconfigureerd met één functie. Zonder de vereiste om ervoor te zorgen dat gedeelde opslag ook maximaal beschikbaar is, is het veel eenvoudiger om replica's te hebben die lokaal zijn in één datacenter voor hoge beschikbaarheid en externe in andere datacenters voor herstel na noodgevallen, elk met afzonderlijke opslag. Het gebruik van extra kopieën van de database is de afweging om redundantie te garanderen. In het volgende diagram ziet u een voorbeeld van een beschikbaarheidsgroep die meerdere datacenters omvat. Eén primaire replica is verantwoordelijk voor het synchroniseren van alle secundaire replica's.

Buiten een AG zonder specifiek clustertype vereist een AG dat alle replica's deel uitmaken van hetzelfde onderliggend cluster, of het nu een WSFC of een externe clusteroplossing is. Dit betekent dat in het bovenstaande diagram de WSFC is uitgerekt om te werken in twee verschillende datacenters, wat complexiteit toevoegt. ongeacht het platform (Windows Server of Linux). Het uitrekken van clusters op afstand voegt complexiteit toe.

Geïntroduceerd in SQL Server 2016 (13.x), kan een gedistribueerde beschikbaarheidsgroep een AG omvatten die is geconfigureerd op verschillende clusters. Gedistribueerde AG's ontkoppelen de vereiste dat de knooppunten allemaal deelnemen aan hetzelfde cluster, waardoor het configureren van herstel na noodgevallen veel eenvoudiger wordt. Zie gedistribueerde beschikbaarheidsgroepen voor meer informatie over gedistribueerde AG's.

Exemplaren van failover-clusters

FCI's kunnen worden gebruikt voor herstel na noodgevallen. Net als bij een normale beschikbaarheidsgroep moet het onderliggende clustermechanisme ook worden uitgebreid naar alle locaties, wat de complexiteit verhoogt. Er is een extra overweging voor FCI's: de gedeelde opslag. Dezelfde schijven moeten beschikbaar zijn op de primaire en secundaire sites. Een externe methode, zoals functionaliteit die wordt geleverd door de leverancier van de opslag op de hardwarelaag, of het gebruik van opslagreplica in Windows Server, is vereist om ervoor te zorgen dat de schijven die door de FCI worden gebruikt elders aanwezig zijn.

Logboekverzending

Logboekverzending is een van de oudste methoden voor herstel na noodgevallen voor SQL Server-databases. Logboekverzending wordt vaak gebruikt met AG's en FCI's om kostenefficiënt en eenvoudiger herstel na noodgevallen te bieden, waarbij andere opties een uitdaging kunnen zijn vanwege omgevings-, administratieve vaardigheden of budget. Net als bij het verhaal over hoge beschikbaarheid voor logboekverzending, vertragen veel omgevingen het laden van een transactielogboek om rekening te houden met menselijke fouten.

Migraties en upgrades

Bij het implementeren van nieuwe exemplaren of het upgraden van oude exemplaren kan een bedrijf lange storingen niet tolereren. In deze sectie wordt beschreven hoe de beschikbaarheidsfuncties van SQL Server kunnen worden gebruikt om de downtime in een geplande architectuurwijziging, serverswitch, platformwijziging (zoals Windows Server naar Linux of omgekeerd) of tijdens het patchen tot een minimum te beperken.

Beschikbaarheidsgroepen

Een bestaand exemplaar met een of meer AG's kan worden bijgewerkt naar latere versies van SQL Server. Hoewel dit enige downtime vereist, kan dit worden geminimaliseerd, met de juiste hoeveelheid planning.

Als het doel is om te migreren naar nieuwe servers en niet de configuratie te wijzigen (inclusief het besturingssysteem of de SQL Server-versie), kunnen deze servers worden toegevoegd als knooppunten aan het bestaande onderliggende cluster en worden toegevoegd aan de beschikbaarheidsgroep. Zodra de replica's de juiste status hebben, kan er een handmatige failover plaatsvinden naar een nieuwe server, en kunnen de oude worden verwijderd uit de AG en uiteindelijk uitgeschakeld.

Gedistribueerde AG's zijn ook een andere methode om te migreren naar een nieuwe configuratie of SQL Server bij te werken. Omdat een gedistribueerde beschikbaarheidsgroep verschillende onderliggende AG's ondersteunt op verschillende architecturen, kunt u bijvoorbeeld veranderen van SQL Server 2016 (13.x) die wordt uitgevoerd op Windows Server 2012 R2 naar SQL Server 2017 (14.x) die wordt uitgevoerd op Windows Server 2016.

Ten slotte kunnen AG's met het clustertype Geen ook worden gebruikt voor migratie of upgrade. U kunt clustertypen niet combineren en vergelijken in een typische AG-configuratie, dus alle replica's moeten een type Geen zijn. Een gedistribueerde beschikbaarheidsgroep kan worden gebruikt om AG's te omvatten die zijn geconfigureerd met verschillende clustertypen. Deze methode wordt ook ondersteund op de verschillende besturingssysteemplatforms.

Alle varianten van AG's voor migraties en upgrades laten toe dat het meest tijdrovende deel van het werk, namelijk gegevenssynchronisatie, in de loop van de tijd kan plaatsvinden. Wanneer het tijd is om de overstap naar de nieuwe configuratie te starten, is de cutover een korte storing ten opzichte van één lange periode van downtime waarbij al het werk, inclusief gegevenssynchronisatie, moet worden voltooid.

AG's kunnen minimale downtime bieden tijdens het patchen van het onderliggende besturingssysteem door handmatig een failover van de primaire naar een secundaire replica uit te voeren terwijl de patching wordt voltooid. Vanuit het oogpunt van een besturingssysteem is dit gebruikelijker op Windows Server, omdat het onderhoud van het onderliggende besturingssysteem vaak opnieuw moet worden opgestart. Het patchen van Linux moet soms opnieuw worden opgestart, maar dit kan niet vaak zijn.

Het patchen van SQL Server-exemplaren die deelnemen aan een beschikbaarheidsgroep , kan ook downtime minimaliseren, afhankelijk van hoe complex de AG-architectuur is. Als u servers wilt patchen die deelnemen aan een AG, wordt eerst een secundaire replica gepatcht. Zodra het juiste aantal replica's is gepatcht, wordt er handmatig een failover uitgevoerd van de primaire replica naar een ander knooppunt om de upgrade uit te voeren. Op dat moment kunnen ook alle resterende secundaire replica's worden bijgewerkt.

Exemplaren van failover-clusters

CCI's kunnen zelf niet helpen bij een traditionele migratie of upgrade; een beschikbaarheidsgroep of logboekverzending moet worden geconfigureerd voor de databases in de FCI en alle andere objecten waarvoor rekening is gehouden. FCI's onder Windows Server zijn echter nog steeds een populaire optie voor wanneer de onderliggende Windows-servers moeten worden gepatcht. Een handmatige failover kan worden gestart, wat betekent dat er een korte storing optreedt in plaats van dat het exemplaar gedurende de hele tijd dat Windows Server wordt gepatcht, niet beschikbaar is. Er kan een FCI worden bijgewerkt naar latere versies van SQL Server. Zie Een failoverclusterexemplaren upgraden voor meer informatie.

Logboekverzending

Logboekverzending is nog steeds een populaire optie voor het migreren en upgraden van databases. Net als bij AG's, maar deze keer met behulp van het transactielogboek als synchronisatiemethode, kan de doorgifte van gegevens ruim voor de serverswitch worden gestart. Op het moment van de switch moet een definitief transactielogboek worden genomen, gekopieerd en toegepast op de nieuwe configuratie zodra al het verkeer bij de bron is gestopt. Op dat moment kan de database online worden gebracht. Logboekverzending is vaak toleranter voor tragere netwerken en hoewel de switch mogelijk iets langer is dan één met behulp van een AG of een gedistribueerde beschikbaarheidsgroep, wordt deze meestal gemeten in minuten, niet uren, dagen of weken.

Net als bij AG's kan logboekverzending een manier bieden om over te schakelen naar een andere server in geval van patching.

Andere SQL Server-implementatiemethoden en -beschikbaarheid

Er zijn twee andere implementatiemethoden voor SQL Server in Linux: containers en het gebruik van Azure (of een andere openbare cloudprovider). De algemene behoefte aan beschikbaarheid zoals in dit document wordt weergegeven, bestaat ongeacht hoe SQL Server wordt geïmplementeerd. Deze twee methoden hebben een aantal speciale overwegingen met betrekking tot het maximaal beschikbaar maken van SQL Server.

SQL Server-containers en opties voor hoge beschikbaarheid/herstel na noodgevallen

Sql Server-containerimplementatie is een nieuwe manier om SQL Server in Linux te implementeren. Een container is een volledige installatiekopieën van SQL Server die klaar is om te worden uitgevoerd.

Afhankelijk van het containerplatform dat u gebruikt, kan een container, bijvoorbeeld wanneer u een containerorchestrator zoals Kubernetes gebruikt, opnieuw worden geïmplementeerd en gekoppeld aan de gedeelde opslag die werd gebruikt. Hoewel dit enige tolerantie biedt, is er enige downtime die is gekoppeld aan databaseherstel en is deze niet echt maximaal beschikbaar, zoals het zou zijn als u een beschikbaarheidsgroep of FCI gebruikt.

Als u hoge beschikbaarheid wilt configureren voor SQL Server-containers die zijn geïmplementeerd op Kubernetes- of niet-Kubernetes-platforms, kunt u DH2i DxEnterprise gebruiken als een van de clusteringoplossingen, waarboven u een AG in de modus voor hoge beschikbaarheid kunt configureren. Deze optie biedt u de beoogde herstelpuntdoelstelling (RPO) en de beoogde hersteltijd (RTO) van een oplossing voor hoge beschikbaarheid.

IaaS-implementatie op basis van Linux

Virtuele Linux IaaS-machines kunnen worden geïmplementeerd met SQL Server geïnstalleerd met behulp van Azure. Net als bij on-premises installaties vereist een ondersteunde installatie het gebruik van een mislukt knooppunt dat zich buiten de clusteragent zelf bevindt. Knooppuntafscheiding wordt geleverd via afschermingsbeschikbaarheidsagents. Sommige distributies verzenden ze als onderdeel van het platform, terwijl andere afhankelijk zijn van externe hardware- en softwareleveranciers. Neem contact op met de Linux-distributie van uw voorkeur om te zien welke vormen van knooppuntafscheiding beschikbaar zijn, zodat een ondersteunde oplossing kan worden geïmplementeerd in de openbare cloud.

Handleidingen voor het installeren van SQL Server in Linux zijn beschikbaar voor de volgende distributies:

• Quickstart: SQL Server installeren en een database maken in Red Hat
• Quickstart: SQL Server installeren en een database maken in Ubuntu
• Quickstart: SQL Server installeren en een database maken op SUSE Linux Enterprise Server

Leesschaal

Secundaire replica's hebben de mogelijkheid om te worden gebruikt voor alleen-lezenquery's. Er zijn twee manieren waarop een beschikbaarheidsgroep kan worden bereikt: door directe toegang tot de secundaire beschikbaarheidsgroep toe te staan en alleen-lezenroutering te configureren, waarvoor het gebruik van de listener is vereist. SQL Server 2016 (13.x) heeft de mogelijkheid geïntroduceerd om alleen-lezen verbindingen via de listener te verdelen met behulp van een round robin-algoritme, waardoor alleen-lezen aanvragen over alle leesbare replica's kunnen worden verspreid.

Het schalen van leesbare kopieën van een database via AG's is voor het eerst geïntroduceerd met gedistribueerde AG's in SQL Server 2016 (13.x). Hierdoor kunnen bedrijven alleen-lezen kopieën van de database hebben, niet alleen lokaal, maar regionaal en wereldwijd met een minimale hoeveelheid configuratie en netwerkverkeer en latentie verminderen door query's lokaal uit te voeren. Elke primaire replica van een beschikbaarheidsgroep (AG) kan twee andere AG's seeden, zelfs als het niet de volledige lees- en schrijfkopie is. Hierdoor kan elke gedistribueerde beschikbaarheidsgroep maximaal 27 leesbare kopieën van de gegevens ondersteunen.

In SQL Server 2017 (14.x) en latere versies kunt u een bijna realtime, alleen-lezen oplossing maken met AG's die zijn geconfigureerd met een clustertype Geen. Als het doel is om AG's te gebruiken voor leesbare secundaire replica's en geen beschikbaarheid, wordt hiermee de complexiteit van het gebruik van een WSFC of een externe clusteroplossing op Linux verwijderd en biedt dit de leesbare voordelen van een AG in een eenvoudigere implementatiemethode.

De enige belangrijke kanttekening is dat het configureren van alleen-lezenroutering enigszins anders is, omdat er geen onderliggend cluster is met het clustertype Geen. Vanuit sql Server-perspectief is een listener nog steeds vereist om de aanvragen te routeren, ook al is er geen cluster. In plaats van een traditionele listener te configureren, wordt het IP-adres of de naam van de primaire replica gebruikt. De primaire replica wordt vervolgens gebruikt om de aanvragen met het kenmerk Alleen-lezen te routeren.

Een warme stand-by voor logboekverzending kan technisch worden geconfigureerd voor leesbaar gebruik door de database WITH STANDBYte herstellen. Omdat de transactielogboeken echter exclusief gebruik van de database vereisen voor herstel, betekent dit dat gebruikers geen toegang hebben tot de database terwijl dat gebeurt. Hierdoor is logboekverzending een minder dan ideale oplossing, met name als bijna realtime gegevens vereist zijn.

Een ding dat moet worden opgemerkt voor alle scenario's met leesschaal met AG's is dat in tegenstelling tot het gebruik van transactionele replicatie waarbij alle gegevens live zijn, elke secundaire replica zich niet in een staat bevindt waarin unieke indexen kunnen worden toegepast, de replica is een exacte kopie van de primaire. Als er indexen nodig zijn voor rapportage of gegevens moeten worden bewerkt, moeten ze worden gemaakt op de databases op de primaire replica. Als u die flexibiliteit nodig hebt, is replicatie een betere oplossing voor leesbare gegevens.

Interoperabiliteit tussen platformoverschrijdende en Linux-distributie

Nu SQL Server nu wordt ondersteund in Zowel Windows Server als Linux, worden in deze sectie de scenario's beschreven waarin wordt beschreven hoe ze kunnen samenwerken voor beschikbaarheid, naast andere doeleinden, en het verhaal voor oplossingen die meer dan één Linux-distributie bevatten.

Gedistribueerde beschikbaarheidsgroepen

Gedistribueerde AG's zijn ontworpen om AG-configuraties te omvatten, ongeacht of deze twee onderliggende clusters onder de AG's twee verschillende WSFC's, Linux-distributies of één op een WSFC en de andere in Linux zijn. Een gedistribueerde beschikbaarheidsgroep is de primaire methode voor het hebben van een platformoverschrijdende oplossing. Een gedistribueerde AG is ook de primaire oplossing voor migraties, zoals het converteren van een SQL Server-infrastructuur op basis van Windows Server naar een op Linux gebaseerde infrastructuur, als dat is wat uw bedrijf wil doen. Zoals hierboven vermeld, zouden AG's en met name gedistribueerde AG's de tijd minimaliseren dat een toepassing niet beschikbaar zou zijn voor gebruik. Een voorbeeld van een gedistribueerde beschikbaarheidsgroep die een WSFC en Pacemaker omvat, wordt weergegeven in het volgende diagram:

Als een AG is geconfigureerd met een clustertype Geen, kan deze zowel Windows Server als Linux omvatten, evenals meerdere Linux-distributies. Aangezien dit geen echte hoge beschikbaarheidsconfiguratie is, moet deze niet worden gebruikt voor bedrijfscritische implementaties, maar voor scenario's met lees schaalbaarheid of migratie/upgrade.

Logboekverzending

Omdat het verzenden van logboeken is gebaseerd op back-up en herstel en er zijn geen verschillen in de databases, bestandsstructuren, enzovoort, voor SQL Server op Windows Server versus SQL Server op Linux. Dit betekent dat logboekverzending kan worden geconfigureerd tussen een sql Server-installatie op basis van Windows Server en een Linux-installatie, en tussen distributies van Linux. Alles anders blijft hetzelfde. De enige kanttekening is dat logboekverzending, net als een AG, niet kan werken wanneer de bron een hogere primaire SQL Server-versie heeft tegen een doel dat zich in een lagere versie van SQL Server bevindt.

Samenvatting

Exemplaren en databases van SQL Server 2017 (14.x) en latere versies kunnen maximaal beschikbaar worden gemaakt met dezelfde functies op zowel Windows Server als Linux. Naast standaard beschikbaarheidsscenario's voor lokale hoge beschikbaarheid en herstel na noodgevallen, kan downtime die is gekoppeld aan upgrades en migraties, worden geminimaliseerd met de beschikbaarheidsfuncties in SQL Server. AG's kunnen ook extra kopieën van een database bieden als onderdeel van dezelfde architectuur om leesbare kopieën uit te schalen. Of u nu een nieuwe oplossing implementeert of een upgrade overweegt, SQL Server heeft de beschikbaarheid en betrouwbaarheid die u nodig hebt.

Verwante inhoud

• SQL Server AlwaysOn-beschikbaarheidsgroep configureren voor hoge beschikbaarheid in Linux
• Failover van AlwaysOn-beschikbaarheidsgroepen in Linux-