När administratörer utvärderar och väljer lösningar för hög tillgänglighet (HA) och katastrofåterställning (DR), måste de ta hänsyn till organisationens affärskrav och fastställa lämpliga värden för Recovery Time Objective (RTO) och Recovery Point Objective (RPO). Dessa två parametrar är avgörande för att säkerställa att systemen kan återställas inom ett acceptabelt tidsfönster och med minimal förlust av data.

Recovery Time Objective (RTO) och Recovery Point Objective (RPO)

Recovery Time Objective (RTO) definierar den maximala tiden som en resurs kan vara otillgänglig utan att allvarligt påverka verksamheten. Till exempel, om en företags SQL-databas går offline, specificerar RTO den maximala nedetiden som kan tolereras innan affärsoperationerna blir allvarligt lidande. I fallet med en orderhanteringsoperation, kan ett databasutbrott hindra företaget från att ta emot nya beställningar, vilket i sin tur påverkar försäljningssiffrorna och orsakar en dominoeffekt i hela produktionskedjan. Administratörer måste därför bedöma hur mycket systemavbrott företaget kan stå ut med innan de ekonomiska konsekvenserna blir oacceptabla. Detta definierar RTO och det kan mätas i minuter, timmar eller dagar. Ju kortare RTO, desto mer effektiva (och dyra) HA/DR-lösningar krävs för att uppfylla det.

Recovery Point Objective (RPO) anger hur mycket dataförlust företaget kan tolerera vid en driftstörning. Om en SQL-databas har ett RPO-värde på 30 minuter och upplever ett katastrofalt avbrott som börjar klockan 15:00, innebär detta att katastrofåterställningsmekanismerna bör kunna återställa databasen till en tidsstämpel senast 15:30. Både RTO och RPO är teoretiska koncept som administratörer ofta hoppas kunna uppfylla under alla omständigheter. För att verkligen uppnå dessa mål måste dock systemen ha tillräckliga HA/DR-mekanismer på plats. Ju lägre RTO och RPO-värden administratörerna väljer, desto mer avancerad och kostsam måste HA/DR-utrustningen vara för att uppfylla dessa krav.

Det finns företag som inte accepterar någon nedtid eller dataförlust alls, medan andra ser på att spendera pengar på HA/DR-teknologi för att skydda mot en eventuell katastrof som orealistiskt och slösaktigt. Därför är det av största vikt att skapa realistiska RTO- och RPO-värden för att balansera mellan affärsbehov och ekonomiska resurser. Om ett företag fastslår att de inte kan tolerera mer än 10 minuters databasutbrott, måste HA/DR-lösningarna inkludera redundanta servrar som snabbt kan ta över databasbearbetningen vid ett eventuellt fel. En enklare lösning som att återställa databaser från säkerhetskopior skulle sannolikt ta längre tid än 10 minuter. Även redundanta servrar kan vara otillräckliga om en naturkatastrof, som en jordbävning, påverkar hela området. I sådana fall krävs mer extrema och kostsamma lösningar, såsom redundanta datacenter i olika städer, för att möta RTO-kraven.

Därmed är det uppenbart att HA/DR-planering inte alltid är en exakt vetenskap. Få företag har råd att implementera HA/DR-skydd mot varje tänkbar typ av fel, vilket innebär att de måste etablera en balans mellan organisationens datakrav och den ekonomiska verkligheten kring HA/DR-skydd.

SQL Server HA/DR-lösningar

De HA/DR-lösningar som erbjuds inom SQL Server-implementeringar varierar beroende på plattformen. I en Infrastructure as a Service (IaaS) SQL-distribution installeras SQL Server-produktet på en virtuell maskin (VM) i Azure. Detta ger administratören full kontroll över Windows-operativsystemet på VM:n samt fullständig administratörsbehörighet för SQL Server-programvaran. Azure tillhandahåller även egna HA/DR-funktioner för den virtuella maskinen.

De HA/DR-funktioner som ingår i SQL Server-programvaran omfattar bland annat:

  • Always On Failover Cluster Instance (FCI): Använder en Windows Server Failover Cluster (WSFC) för att skapa flera noder som innehåller redundanta SQL Server-instanser. Om en nod misslyckas, startar SQL Server-instansen om på en annan nod, vilket säkerställer fortsatt drift.

  • Always On Availability Group (AG): En database-level redundans där en primär databas (läs/skrift) har en eller flera sekundära databaser (bara för att ta emot transaktioner). Om den primära databasen misslyckas, uppgraderas en sekundär till primär.

  • Log Shipping: En metod att skapa och uppdatera sekundära kopior av en SQL-databas genom att säkerhetskopiera databasen på en server och återställa den på en sekundär server.

Azure tillhandahåller ytterligare HA/DR-mekanismer för IaaS-installationer, vilket beskrivs närmare i senare delar om att utvärdera Azure-specifika HA/DR-lösningar.

PAAS HA/DR-lösningar

För PaaS SQL-implementationer, såsom Azure SQL Database och Azure SQL Managed Instance, är HA/DR-funktioner inbyggda och kräver vanligtvis ingen administrativ intervention. Till exempel inkluderar Azure SQL Database som standard ett service level agreement (SLA) som garanterar 99,99 % tillgänglighet för databasen. Om Azure-noden som kör användarens databas misslyckas sker failover-processen omedelbart och automatiskt. Hostservern skapar en ny nod och kopplar den till lagringsmekanismen som innehåller databasen.

Azure SQL Database och Azure SQL Managed Instance innehåller även funktionen Accelerated Database Recovery (ADR), som tillåter omedelbara transaktionsåterställningar, loggtrunkering och snabb återhämtning av databaser.

PaaS-implementationerna gör det också möjligt för abonnenter att skapa läsreplicor av sina databaser och lagra dem i olika geografiska regioner, vilket ger HA/DR-skydd även vid en större regionalt drabbad tjänsteavbrott.

Utvärdering av HA/DR för hybriddistributioner

En hybrid SQL-distribution blandar lokala SQL Server-installationer – antingen på fysiska eller virtuella servrar – med Azure VMs som kör SQL Server. Administratörer skapar ofta en hybridarkitektur för att lägga till hög tillgänglighet och/eller katastrofåterställning till sina befintliga nätverk. Ett redundanta SQL-server i molnet kan fungera som en lastbalanserare under hög arbetsbelastning eller som en failover-server vid ett lokalt serverfel.

Azure kan tillhandahålla motsvarigheten till en lokal Active Directory Domain Services-installation och kan också möjliggöra skapandet av redundanta servrar i olika regioner.

Azure SQL Database och Azure SQL Managed Instance har sina egna HA/DR-mekanismer, men PaaS SQL-implementationer fungerar generellt inte som en del av en hybridarkitektur. Det finns dock undantag, som möjligheten att replikera transaktioner från en lokal server till en Managed Instance i molnet, även om replikeringen endast kan flöda i en riktning.

Hur sharding kan hjälpa till att skala upp och förbättra prestandan i databaser

Sharding är en teknik som möjliggör skalning av en databas genom att dela upp den i flera partitioner som lagras i separata databasinstanser. Detta kallas ofta för horisontell skalning eller "scaling out" och kan ge nästan obegränsad kapacitet för databasen. Samtidigt kan det också förbättra prestanda och felsäkerhet genom att sprida data över flera enheter. Sharding är dock en process som kräver noggrant övervägande och planering, eftersom den innebär betydande administrativa och tekniska utmaningar.

När det gäller implementeringen av sharding i Azure SQL, är det vanligt att skapa shards på instanser av Azure SQL Database, även om det är möjligt att använda SQL Managed Instances eller Azure VMs som kör SQL Server. En fördel med denna strategi är att den skapar utrymme för nästan obegränsad expansion, vilket gör det möjligt att hantera mycket stora datamängder utan att överskrida de fysiska begränsningarna för en enda server.

Valet att använda sharding bör inte tas lättvindigt. För vissa databaser, särskilt de som främst används för läsoperationer, kan replikering vara ett enklare och mer effektivt alternativ än sharding. Replikering innebär att hela databasen kopieras och distribueras över flera instanser, vilket gör det möjligt att hantera fler läsförfrågningar utan att behöva dela upp själva datamodellen.

Vid val av strategi för partitionering av databasen finns det flera alternativ. Ett sätt är att dela upp databasen efter rader, där varje shard innehåller en delmängd av fullständiga poster som följer ett specifikt attribut, till exempel datum eller plats. Ett annat sätt är att dela upp databasen efter kolumner, vilket gör det möjligt att exempelvis lagra känsliga data, som kreditkortsinformation, i en shard som är extra säker.

De tre vanligaste metoderna för att skapa shards är:

  1. Range-baserad sharding: Här väljer administratören en kolumn och delar upp databasen i shards baserat på intervall av värden, som exempelvis datum eller produktnummer. Detta är en relativt enkel metod men kan leda till obalans mellan shards, där vissa kan bli "hotspots" med mycket hög belastning.

  2. Hash-baserad sharding: Administratören väljer en kolumn som fungerar som shard-nyckel, och SQL använder en hashberäkning för att fördela raderna jämt mellan shards. Detta minskar risken för hotspots men kan leda till problem när fler shards måste läggas till, eftersom datan måste omfördelas mellan de existerande shards.

  3. Lookup-baserad sharding: I denna metod använder administratören en kolumn som shard-nyckel och skapar en uppslagsdatabas som anger vilken shard varje värde ska tillhöra. Denna metod är mer flexibel och gör det lättare att lägga till nya shards.

Fördelarna med sharding är uppenbara: genom att placera shards på olika servrar kan man snabbare genomföra sökningar, eftersom varje shard är en liten del av den totala databasen. Om en shard skulle gå ner, påverkar det inte hela systemet, vilket ger högre tillförlitlighet och felresistens. Vidare kan man optimera servrar för att hantera specifika typer av data, som mer känslig eller ofta åtkomstad information.

Men sharding medför också en rad nackdelar. För det första krävs fler servrar för att upprätthålla den uppdelade databasen, och varje administrativ uppgift som tidigare sköttes på en enskild instans måste nu hanteras för varje shard. Dessutom kan frågehantering bli mer komplex, särskilt när en fråga kräver data från flera shards. Detta innebär att extra resurser måste tilldelas för att hantera routing av dessa frågor, vilket kan medföra ökad latens.

En annan viktig aspekt av sharding är kostnaderna. Eftersom det krävs fler servrar och instanser, kan den totala kostnaden för drift och underhåll bli högre än att helt enkelt skala upp en enskild server med mer resurser. Här måste administratören noggrant väga kostnaden för att lägga till ytterligare instanser och servrar mot kostnaden för att uppgradera den befintliga servern.

För att effektivt konfigurera Azure SQL för skalning och prestanda, erbjuder plattformen flera alternativ som gör det möjligt för administratörer att anpassa resursanvändningen baserat på behov. Med funktioner som elastiska pooler, som samlar lagringsresurser för flera databaser, kan man förenkla hanteringen och optimera användningen av resurser.

Även om sharding kan erbjuda stora fördelar i form av skalbarhet och prestanda, är det viktigt att förstå att det inte är en universell lösning. Den metod som fungerar bäst beror på databasens specifika användningsfall, inklusive hur data lagras och bearbetas, samt vilken typ av frågor som vanligtvis ställs. Därför är det viktigt att noggrant överväga både fördelar och nackdelar innan beslutet om att implementera sharding fattas.

Hur fungerar flerstationers automatiska polermaskiner och deras fördelar?
Hur textkommunikation förändrar våra relationer och affärer: Är vi på väg mot en isolerad framtid?
Hur reflektioner och kollisioner av partiklar kan simulera dynamik i en vätska