[Bron] Hoge beschikbaarheid in SQL Server (1) ---- een overzicht van hoge beschikbaarheid

Sinds SQL Server 2005 heeft Microsoft een verscheidenheid aan high-availability technologieën geleverd om downtime te verminderen en de bescherming van bedrijfsdata te vergroten, en met de continue release van SQL Server 2008, SQL Server 2008 R2 en SQL Server 2012 zijn er veel high availability-technologieën in SQL Server om aan verschillende scenario's te voldoen.

    Voordat ik aan dit artikel begin, begin ik met een kort overzicht van wat bepaalt welke technologie met hoge beschikbaarheid gebruikt moet worden.

    Veel bedrijven hebben alle of een deel van hun data nodig om zeer beschikbaar te zijn, zoals online winkelwebsites, online productdatabases moeten 24/7 online zijn, anders betekent downtime in een zeer competitieve marktomgeving verloren klanten en omzet. Bijvoorbeeld, in een callcenter dat afhankelijk is van SQL Server, als de database uitvalt, kunnen alle bellers alleen maar blijven zitten en de klant antwoorden met "Sorry, systeemfout", wat ook onacceptabel is.

    Natuurlijk is in een ideale wereld alle kritieke data altijd online, maar in de praktijk zijn er verschillende redenen waarom de database niet beschikbaar is, omdat het onmogelijk is om het tijdstip en de vorm van een ramp te voorspellen; het is noodzakelijk om vooraf maatregelen te nemen om diverse noodgevallen te voorkomen, dus SQL Server biedt een verscheidenheid aan technologieën met hoge beschikbaarheid, deze technologieën omvatten vooral: clustering, replicatie, spiegeling, loglevering, AlwaysOn-beschikbaarheidsgroepen en andere zoals back-up en herstel van bestandsgroepen, Single-instance high-availability technologieën zoals online herbouwindexen. Het gebruik van technologie met hoge beschikbaarheid is niet om een bekende technologie direct te kiezen, maar om het bedrijf en de technologie volledig te overwegen. Omdat er geen enkele technologie is die alle functies kan uitvoeren. Hoe je deze technologieën toepast op basis van je specifieke bedrijf en budget wordt een high availability-strategie genoemd.

Bij het ontwerpen van een strategie voor hoge beschikbaarheid moet u eerst de volgende factoren overwegen:

• RTO (Recovery Time Objective) - dat wil zeggen, hersteltijddoel, betekent hoeveel downtime is toegestaan, meestal uitgedrukt in enkele 9s, bijvoorbeeld, 99,999% beschikbaarheid betekent niet meer dan 5 minuten downtime per jaar, 99,99% beschikbaarheid betekent niet meer dan 52,5 minuten downtime per jaar, en 99,9% beschikbaarheid betekent niet meer dan 8,75 uur downtime per jaar. Het is goed om te weten dat de berekeningsmethode van RTO rekening houdt met of het systeem 24/365 is of slechts van 6.00 tot 21.00 uur, enzovoort. Je moet ook letten of het onderhoudsvenster als downtime wordt geteld, en het is makkelijker om een hogere beschikbaarheid te bereiken als databaseonderhoud en patchen tijdens het onderhoudsvenster zijn toegestaan.
• RPO (Recovery Point Objective) – Ook wel het recovery point objective genoemd, betekent hoeveel dataverlies is toegestaan. Meestal, zolang je een goede back-up maakt, kun je gemakkelijk nul dataverlies bereiken. Maar wanneer er een ramp plaatsvindt, afhankelijk van de omvang van de databasecorruptie, zal de tijd die nodig is om data uit een back-up te herstellen ervoor zorgen dat de database onbeschikbaar wordt, wat de implementatie van RTO beïnvloedt. Een vroeg en bekender voorbeeld is een banksysteem in Europa en de Verenigde Staten, waarbij alleen rekening wordt gehouden met RPO, er zijn alleen volledige back-ups en logback-ups in het systeem, volledige back-ups elke 3 maanden, logback-ups elke 15 minuten, en bij een ramp kunnen alleen volledige back-ups en logback-ups data worden hersteld, dus hoewel er geen dataverlies is, was het banksysteem twee dagen lang niet beschikbaar, waardoor een groot aantal klanten verloren ging. Een ander tegengesteld voorbeeld is een binnenlandse online videowebsite, waarbij SQL Server als back-end relationele database wordt gebruikt, de front-end gebruikt No-SQL en regelmatig No-SQL-gegevens importeert in de relationele database als back-up.
  

    Budget – RTO en RPO staan gezamenlijk bekend als SLA's (Service Level Agreements), en bij het ontwerpen van een high availability-strategie moet je meten hoe goed je aan SLA's voldoet op basis van je bedrijf, afhankelijk van je budget en het meten van de kosten van verschillende SLA's in het geval van een storing. Over het algemeen is het moeilijk om hoge SLA's te behalen met een beperkt budget, en zelfs als hoge SLA's worden bereikt via complexe architecturen, betekenen complexe architecturen ook hoge operationele en onderhoudskosten, dus is het noodzakelijk om de juiste technologie binnen het budget te kiezen om aan de SLA's te voldoen.

Daarom kan het grote kader voor hoge beschikbaarheid in het algemeen worden bepaald door verschillende order-takenvragen:

• Wat is de downtime die aandeelhouders bereid zijn te accepteren?
• Welke downtime is acceptabel voor managers?
• Wat is het budget dat wordt gereserveerd voor een scenario met hoge beschikbaarheid?
• Hoeveel is het verlies per uur door downtime?
  

• Koude back-up: De standby-server is zo ingesteld dat hij de gegevens van de primaire server accepteert, en wanneer deze faalt, wordt de data handmatig hersteld naar de primaire database, of wordt de verbindingsstring of de rechten van het programma aangepast om de back-updatabase online te brengen.
• Warme back-up: De primaire servergegevens zullen continu logs naar de back-upserver sturen (op onregelmatige intervallen, dit kan 15 minuten, 30 minuten, 1 minuut, enz. zijn), op deze manier wordt de primaire server naar de back-upserver meestal asynchroon bijgewerkt, waardoor de gegevens van de primaire server en de back-upserver niet gegarandeerd kunnen worden. Daarnaast implementeert dit schema doorgaans geen automatische foutbewaking en failover.
• Hot backup: De data van de primaire server wordt automatisch gesynchroniseerd op de back-upserver, en in de meeste gevallen zijn automatische foutmonitoring en failover inbegrepen, waarbij de dataconsistentie van de primaire server en de back-upserver gegarandeerd kan worden.
  

    Van koud tot warm naar heet back-ups, de kosten schieten omhoog.

    De hoge beschikbaarheidsfuncties die in SQL Server worden ondersteund, zijn nauw verwant aan de versie, en de Enterprise-editie ondersteunt alle hoge beschikbaarheidsfuncties, waaronder:

• Failover-cluster
• l Databaseafbeelding
• l Transmissielogoverdracht
• l Databasesnapshots
• Hoge beschikbaarheid upgrades
• l Hot load-geheugen
• l Online indexeringsoperaties
• l Database gedeeltelijk online (alleen masterbestandsgroep of masterbestandsgroep en extra NDF-bestanden worden hersteld)
  

    Voor specifieke versies van welke hoge beschikbaarheidsfuncties, zie:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxHet is vermeldenswaard dat de gratis Express-versie kan dienen als getuigenserver voor databasespiegeling, wat leidt tot kostenbesparingen.

Failover-cluster

    Failover-clusters bieden ondersteuning voor hoge beschikbaarheid voor de gehele SQL Server-instantie, wat betekent dat een SQL Server-instantie op een node in de cluster overgaat naar andere nodes in de cluster vanwege hardwarefouten, besturingssysteemfouten, enzovoort. Hoge beschikbaarheid wordt bereikt doordat meerdere servers (nodes) één of meer schijven delen, en failoverclusters verschijnen in het netwerk op dezelfde manier als een enkele computer, maar met eigenschappen van hoge beschikbaarheid. Het is belangrijk op te merken dat aangezien failoverclusters gebaseerd zijn op gedeelde schijven, er één punt van schijfstoring is, dus extra beveiligingen zoals SAN-replicatie moeten op schijfniveau worden ingezet. De meest voorkomende failovercluster is een failovercluster met twee knooppunten, inclusief de master en slave.

Transmissie van transactielogboeken

    Transaction log shipping biedt bescherming op databaseniveau met hoge beschikbaarheid. Logging wordt gebruikt om een of meer standby-databases (zogenaamde "secundaire databases") van de bijbehorende productiedatabase (de zogenaamde "primaire database") te onderhouden. Voordat een failover plaatsvindt, moet de secundaire database volledig worden bijgewerkt door handmatig alle niet-herstelde logback-ups toe te passen. Loglevering heeft de flexibiliteit om meerdere standby-databases te ondersteunen. Als meerdere alternatieve databases nodig zijn, kan loglevering afzonderlijk worden gebruikt of als aanvulling op databasespiegeling. Wanneer deze oplossingen samen worden gebruikt, is de hoofddatabase van de huidige databasespiegelingsconfiguratie ook de primaire database van de huidige log shipping-configuratie.

    Transaction log delivery kan worden gebruikt om koude en warme back-ups te maken.

Databasespiegeling

    Databasespiegeling is eigenlijk een softwareoplossing die ook bescherming op databaseniveau biedt, waardoor vrijwel onmiddellijke failover mogelijk is om de beschikbaarheid van de database te verbeteren. Een databasespiegel kan worden gebruikt om een enkele standby-database (of "spiegeldatabase") te onderhouden voor de bijbehorende productiedatabase (de zogenaamde "principal database").
Omdat de spiegeldatabase altijd in een hersteltoestand is, maar de database niet wordt hersteld, kan de spiegeldatabase niet direct worden benaderd. Voor alleen-lezen laadpunten zoals rapporten kun je de gespiegelde database echter indirect gebruiken door een databasesnapshot van de gespiegelde database te maken. Databasesnapshots bieden clients alleen-lezen toegang tot de gegevens in de database wanneer de snapshot wordt gemaakt. Elke databasespiegelconfiguratie omvat een "hoofdserver" die de hoofddatabase bevat, en ook een spiegelserver die de gespiegelde database bevat. De mirrorserver werkt continu de mirrordatabase bij met de hoofddatabase.
    Databasespiegeling draait synchroon in high-security modus of asynchrone werking in high-performance mode. In high-performance modus hoeven transacties niet te wachten tot de mirrorserver logs naar de schijf schrijft voordat ze kunnen worden ingediend, wat de prestaties maximaliseert. In high-security modus worden verplichte transacties door beide partners gecommitteerd, maar de vertraging in de transactie wordt verlengd. De eenvoudigste configuratie van databasespiegeling omvat alleen de hoofdserver en de spiegelserver. In deze configuratie kan de mirrorserver als de hoofdserver verloren gaat als standby-server worden gebruikt, maar dit kan dataverlies veroorzaken. High security modus ondersteunt standby-configuratie high security mode met automatische failover. Deze configuratie omvat een externe serverinstantie, een zogenaamde "witness server", waarmee de mirrorserver als hot backup-server kan worden gebruikt. De failover van de primaire database naar de spiegeldatabase duurt doorgaans enkele seconden.

    Databasemirroring kan zowel voor warme als warme back-ups worden gebruikt.

kopiëren

    Replicatie is niet strikt een functie die is ontworpen voor hoge beschikbaarheid, maar kan wel worden toegepast op hoge beschikbaarheid. Replicatie biedt bescherming op database-objectniveau. Replicatie maakt gebruik van een publicish-subscribe-model, waarbij data door de primaire server, de uitgever, wordt gepubliceerd aan een of meer secundaire abonnees of abonnees. Replicatie zorgt voor realtime beschikbaarheid en schaalbaarheid tussen deze servers. Het ondersteunt filtering om een subset van de gegevens aan abonnees te leveren, terwijl partitie-updates ook worden ondersteund. De abonnee is online en beschikbaar voor rapportage of andere functies zonder queryherstel. SQL Server biedt vier replicatietypen: snapshot-replicatie, transactionele replicatie, peer-to-peer replicatie en merge-replicatie.

AlwaysOnGebruiksvriendelijkheidsgroep

    AlwaysOn Availability Groups is een nieuwe functie die is geïntroduceerd in SQL Server 2012. Er wordt ook bescherming op databaseniveau geboden. Het breidt ook de limiet uit dat databasespiegeling slechts 1:1 kan zijn, zodat één primaire replica kan overeenkomen met maximaal 4 secundaire replica's (in SQL Server 2014 wordt deze limiet uitgebreid tot 8), waarvan 2 secundaire replica's gesynchroniseerd kunnen worden als hot back-ups en primaire replica's in realtime, en de andere twee asynchrone secundaire replica's als warme back-ups kunnen worden gebruikt. Daarnaast kunnen secundaire replica's worden geconfigureerd als alleen-lezen en kunnen ze worden gebruikt om de belasting van back-ups op te vangen.

    Hierdoor wordt databasespiegeling in SQL Server 2012 als "verouderd" gemarkeerd.

    Na het begrijpen van de basisconcepten van hoge beschikbaarheid en de technologieën die in SQL Server worden aangeboden, laten we eens kijken naar het ontwerp van een strategie voor hoge beschikbaarheid. Het plannen van een strategie voor hoge beschikbaarheid kan worden onderverdeeld in vier fasen:

Verzamelvereisten

    De eerste stap bij het kiezen van een high availability-strategie is ongetwijfeld het verzamelen van zakelijke vereisten om SLA's op te stellen. RTO en RPO zijn de meest kritieke onderdelen en stellen op basis hiervan realistische verwachtingen vast voor beschikbaarheidsvereisten en stellen ze een realistische strategie voor hoge beschikbaarheid op basis van deze verwachtingen.

Beoordelingslimieten

    Beoordelingslimieten beperken zich niet alleen tot de beperkingen van verschillende hoogbeschikbaarheidstechnologieën in SQL Server, maar ook tot niet-technische technologieën. Als je maar een budget van tienduizenden yuan hebt, maar je wilt een oplossing met hoge beschikbaarheid maken gebaseerd op externe datacenters en SAN-replicatie, is het ongetwijfeld een dwaze droom. Een andere niet-technische beperking is het niveau van operationeel personeel, en vaak betekenen complexe architecturen meer gekwalificeerd operationeel personeel. Andere niet-technische beperkingen zijn de beschikbaarheid van schijfruimte in het datacenter, of de stroomvoorziening en airconditioning aan de behoeften voldoen, en de tijd die nodig is om de beschikbaarheidsstrategie uit te voeren.

    Technische beperkingen omvatten verschillende functies en beperkingen voor hoge beschikbaarheid, functies die worden ondersteund door verschillende SQL Server-versies, het aantal CPU's en de grootte van het geheugen. Het wordt sterk aanbevolen om eerst de beperkingen van verschillende SQL Server-versies en functies op de Microsoft MSDN-website te bespreken voordat u een high availability-beleid invoert.

Selecte technologie

    Na het verzamelen van eisen en het beoordelen van beperkingen, is de volgende stap het selecteren van de eerder in dit artikel beschreven technologieën of combinaties om aan de SLA-eisen te voldoen. Als de geselecteerde technologie niet aan de SLA voldoet, is het eenvoudig om te melden welke beperkingen niet aan de SLA voldoen, waardoor je ontbrekende middelen kunt aanvragen of compromitteren kunt sluiten op de SLA.

Test, valideer en documenteer

    Beleidsregels voor hoge beschikbaarheid moeten vanaf het begin grondig worden getest en gevalideerd om te waarborgen dat de huidige beschikbaarheidsbeleidsregels voldoen aan SLA's. Wanneer echter een strategie voor hoge beschikbaarheid wordt gelanceerd, is het ook noodzakelijk deze regelmatig te testen en te valideren om te garanderen dat het huidige beleid nog steeds aan SLA's kan voldoen ondanks datagroei, bedrijfs- of vereistenwijzigingen. Tegelijkertijd moeten de configuratie van de beschikbaarheidsoplossing, de failovermethode en het rampenherstelplan tegelijk worden gedocumenteerd, zodat deze kunnen worden getraceerd in geval van storing of toekomstige aanpassing van de high availability-strategie.

Dit artikel legt de basisconcepten van hoge beschikbaarheid uit, het concept van SLA's, de verschillende soorten high availability-functies die in SQL Server worden ondersteund, en de stappen die nodig zijn om een high availability-strategie te ontwerpen. Het is vermeldenswaard dat hoewel dit artikel alleen gaat over hoge beschikbaarheid op databaseniveau, hoge beschikbaarheid niet alleen een kwestie is voor DBA, maar ook de samenwerking omvat van verschillende rollen zoals systeembeheer- en onderhoudspersoneel, netwerkbeheerders, ontwikkelaars en managers om beter aan SLA's te voldoen.