Jag tycker att när människor designar Oracle RAC-arkitektur, tänker de ofta inte på N+1-redundans i sina implementeringsplaner. Det finns två skäl att implementera Oracle RAC, tillgänglighet och skalbarhet. I den här diskussionens syfte fokuserar jag bara på tillgänglighetssidan. Om dina RAC-distributioner endast är av skalbarhetsskäl, kanske det här ämnet inte gäller dig.
Så vad är N+1-redundans? Enkelt uttryckt, om du behöver N enheter av något, då för redundansändamål, bör du ha N+1 av det objektet. Låt oss titta på en databasserver. Den måste ha strömförsörjning. Det är ett krav. Utan en fungerande strömförsörjning fungerar inte servern alls. Minsta antal nätaggregat är 1. Om vi vill att denna server ska ha en hög grad av tillgänglighet ser vi till att den har N+1 strömförsörjning, eller i det här fallet dubbla strömförsörjningar. Om det bara finns en strömkälla och den går sönder tar den servern med sig. Om vi har en extra strömkälla, en reservenhet, kommer förlusten av en strömkälla inte att ta ner servern med den. Redundans är en bra sak att ha och en viktig komponent för en infrastruktur med hög tillgänglighet.
När man designar ett Oracle RAC-system måste DBA bestämma hur många noder som behövs för att stödja slutanvändarens krav. Om DBA:n fastställer att 4 noder behövs, och detta RAC-kluster måste uppvisa höga tillgänglighetsegenskaper, är det viktigt för DBA:n att skapa ett 5 nodkluster (4+1). Om resurskraven är tillräckliga för att hålla 4 noder upptagna och en nod går förlorad, kommer de återstående 3 inte att kunna hänga med i arbetsbelastningen. Om DBA bygger RAC-systemet med N+1-kapacitet i åtanke, kommer förlusten av en nod inte att märkas av slutanvändarna. Om DBA bygger RAC-klustret utan N+1-redundans, kan förlusten av en nod vara så fruktansvärd för slutanvändarens prestanda att hela klustret lika gärna kan vara nere. När du designar dina RAC-implementeringar, sträva efter N+1-redundans.
Jag minns för två år sedan hade jag ett RAC-kluster som tappade en nod. Inga problem, vi hade fortfarande två tillgängliga noder. När jag såg prestandan för de två återstående noderna verkade de vara ganska överväldigade. Vårt callcenter började ta emot klagomål. Jag arbetade med andra administratörer i IT-teamet för att få den noden igång igen så snabbt som möjligt, men det kanske inte alltid är fallet om orsaken till avbrottet är hårdvarurelaterade och delar måste bytas ut. Efter att noden var tillbaka i drift övervakade jag klustrets prestanda i veckor senare. Vår användning hade ökat sedan detta system ursprungligen designades. Vi hade från början designat detta system med N+1-redundans i åtanke, men vår användning växte och N gick från 2 till 3. Vårt nuvarande 3-nodskluster var inte längre N+1-redundant. Så jag arbetade med ledningen för att lägga in tillräckligt med pengar i nästa års budget för att skaffa en ny nod och se till att Oracle var licensierad på den. Jag sover mycket bättre på nätterna med vetskapen om att jag är tillbaka till N+1 redundans.
Som många andra implementeringar där ute är mitt RAC-system inte den enda High Availability-funktionen inbyggd i vår infrastruktur. Denna RAC-databas är en primär till en fysisk standby-databas med Oracles Data Guard. Jag är förvånad när jag diskuterar RAC standby-databaser med andra Oracle DBA:s hur många av dem inte tänker på N+1-kapacitet för deras standby. Den fysiska standbydatabasen är mitt skyddsnät ifall det primära datacentret inte är tillgängligt av någon anledning. Jag har sett så många Oracle DBA:s implementera standby för en enda instans för en primär RAC med flera noder. aj! Jag hoppas att de aldrig behöver misslyckas. Hela deras multi-nod RAC-kluster arbetsbelastning kommer att kämpa kraftigt på den enda instans standby. Så när du designar dina RAC-implementeringar för både den primära och standbyen, överväg dina N+1-redundansimplikationer på arkitekturdesignen.
Där jag förmodligen skiljer mig från många människor är att mina fysiska standby-implementationer inte är N+1-kapabla, utan snarare N. Jag hoppar över den redundanta extra noden för min fysiska standby. Varför är det så? Rent kostnadsmässigt. Mitt fysiska beredskap är bara ett skyddsnät. Jag vill att det ska fungera för mig den dagen jag behöver det. Men jag behöver det förhoppningsvis aldrig. Det fysiska beredskapsläget är min försäkring ifall risk skulle bli verklighet. För mig är den extra "+1" på standbyplatsen överförsäkring. Jag kan spara på den fysiska hårdvaran och Oracle-licensiering.
Så låt oss säga att dagen kommer och jag gör failover till standby. Jag har tappat min N+1-redundans. Men vad är chansen att jag kommer att förlora det primära datacentret *och* förlora en av noderna i mitt standby-kluster? Ganska små chanser. Sannolikheten för fel på två platser samtidigt är ganska liten. Vid det här laget utvärderar vårt IT-team varför vårt primära datacenter går förlorat och när vi med största sannolikhet kan återföra vår verksamhet till den anläggningen. Om det primära datacentret tappade all sin ström och elbolaget säger att tjänsten kommer att återställas i morgon, så kör vi helt enkelt i standby-datacentret även om vi bara har N noder för RAC-databasen där. Men om det primära datacentret utplånades av en brand kommer det att ta många månader innan det är igång igen. Det är vid det här laget som jag måste planera för att få det fysiska standbyläget upp till N+1 redundans eftersom vår tid att använda det standbyläget som primärt kommer att vara en mycket längre period. Så vi skyndar oss att beställa en annan server och lägga till den i klustret så snart som möjligt. Så jag designar min standby-RAC-databas som N, inte N+1 med ett öga på att öka den till N+1 på kort tid om vi bestämmer att vi kommer att använda standby-läget på riktigt under en längre tid.
Så det finns ett annat specialfall jag skulle vilja diskutera. Det är där DBA bestämmer att N=1. För de nuvarande arbetsbelastningskraven räcker det med en nod. Men vi vill ha hög tillgänglighet så vi designar ett RAC-kluster med två noder för den primära databasen. Vi har nu N+1-redundans inbyggd i den primära. Efter mitt sista stycke behöver min standby-databas bara en nod. Misstaget jag ser att vissa människor gör är att skapa vänteläget som en engångsdatabas. Än så länge är deras logik vettig. Den primära är N+1 och standby-läget är N. Så långt har det gått bra. Där jag skiljer mig åt är att jag gör standby-läget till ett RAC-kluster med en nod, inte en ren implementering av en enda instans. Anledningen är framtida tillväxt. Vid någon tidpunkt kan DBA upptäcka att N inte längre är lika med 1 vid den primära. Användningen har ökat och N måste vara 2 nu. DBA vill utöka den primära till 3 noder (2+1). Detta är lätt nere med noll driftstopp för att lägga till en ny nod till klustret och utöka RAC-databasen till den nya noden. Men det är inte så lätt att göra i standbyläge att göra standby till ett 2-nodskluster om den 1 noden som finns inte är RAC-aktiverad. Om en ren standby för en instans är allt som existerar, måste DBA skrota den och flytta den till ett tvånodskluster. Om DBA:n hade förutseende och installerade Grid Infrastructure som om det fysiska standby-läget vore ett kluster med en enda nod, så behöver DBA:n bara lägga till en ny nod, precis som de gjorde på primärsidan.
När du designar dina RAC-implementeringar, överväg att se till att du har N+1-kapacitet på den primära och åtminstone N i vänteläge. Om ett företag bedömer att beredskapsläget är för kritiskt, kanske de vill implementera N+1 i beredskapsläget också. Om DBA bestämmer att N=1, överväg att göra vänteläget till åtminstone ett RAC-kluster för en enda nod.