Jeg oplever, at når folk designer Oracle RAC-arkitektur, tænker de ofte ikke på N+1-redundans i deres implementeringsplaner. Der er to grunde til at implementere Oracle RAC, tilgængelighed og skalerbarhed. I forbindelse med denne diskussion fokuserer jeg kun på tilgængelighedssiden. Hvis dine RAC-installationer kun er af skalerbarhedsgrunde, gælder dette emne muligvis ikke for dig.
Så hvad er N+1 redundans? Kort sagt, hvis du har brug for N enheder af noget, skal du til redundansformål have N+1 af den vare. Lad os se på en databaseserver. Den skal have strømforsyning. Det er et krav. Uden en fungerende strømforsyning fungerer serveren slet ikke. Minimumsantallet af strømforsyninger er 1. Hvis vi ønsker, at denne server skal have en høj grad af tilgængelighed, sørger vi for, at den har N+1 strømforsyninger, eller i dette tilfælde to strømforsyninger. Hvis der kun er én strømforsyning, og den fejler, tager den serveren med sig. Hvis vi har en ekstra strømforsyning, en reserveenhed, vil tabet af en strømforsyning ikke tage serveren med den ned. Redundans er en fantastisk ting at have og en væsentlig komponent til en høj tilgængelig infrastruktur.
Når man designer et Oracle RAC-system, skal DBA bestemme, hvor mange noder der er nødvendige for at understøtte slutbrugerens krav. Hvis DBA bestemmer, at der er behov for 4 noder, og denne RAC-klynge skal udvise høje tilgængelighedstræk, så er det afgørende for DBA'en at oprette en 5 node-klynge (4+1). Hvis ressourcekravene er tilstrækkelige til at holde 4 noder beskæftiget, og en node går tabt, vil de resterende 3 ikke være i stand til at følge med arbejdsbyrden. Hvis DBA'en bygger RAC-systemet med N+1-kapacitet i tankerne, så vil tabet af en node ikke kunne mærkes af slutbrugerne. Hvis DBA'en bygger RAC-klyngen uden N+1-redundans, så kan tabet af en node være så forfærdeligt for slutbrugerens ydeevne, at hele klyngen lige så godt kan være nede. Når du designer dine RAC-implementeringer, stræb efter N+1 redundans.
Jeg kan huske for to år siden, jeg havde en RAC-klynge, der mistede en knude. Intet problem, vi havde stadig to noder til rådighed. Da jeg så ydelsen af de to resterende noder, så de ud til at være ret overvældede. Vores callcenter begyndte at modtage klager. Jeg arbejdede sammen med andre administratorer på it-teamet for at få den node op og køre så hurtigt som muligt, men det er måske ikke altid tilfældet, hvis årsagen til udfaldet er hardwarerelateret, og dele skal udskiftes. Efter at noden var tilbage i drift, overvågede jeg klyngens ydeevne i uger senere. Vores brug var vokset, siden dette system oprindeligt blev designet. Vi havde oprindeligt designet dette system med N+1 redundans i tankerne, men vores brug voksede og N gik fra 2 til 3. Vores nuværende 3-node klynge var ikke længere N+1 redundant. Så jeg arbejdede sammen med ledelsen for at indsætte nok midler i næste års budget til at anskaffe en ny node og sikre, at Oracle var licenseret til den. Jeg sover meget bedre om natten vel vidende, at jeg er tilbage til N+1 redundans.
Som mange andre implementeringer derude, er mit RAC-system ikke den eneste High Availability-funktion indbygget i vores infrastruktur. Denne RAC-database er en primær til en fysisk standby-database med Oracles Data Guard. Jeg er overrasket, når jeg diskuterer RAC-standby-databaser med andre Oracle DBA'er, hvor mange af dem ikke tænker på N+1-kapacitet til deres standby. Den fysiske standby-database er mit sikkerhedsnet, hvis det primære datacenter af en eller anden grund ikke er tilgængeligt. Jeg har set så mange Oracle DBA'er implementere en enkelt instans standby for en primær multi-node RAC. Av! Jeg håber, de aldrig behøver at fejle. Hele deres multi-node RAC-klynges arbejdsbyrde vil kæmpe voldsomt på den enkelte instans standby. Så mens du designer dine RAC-implementeringer til både den primære og standby, skal du overveje dine N+1-redundansimplikationer på arkitekturdesignet.
Hvor jeg nok adskiller mig fra mange mennesker er, at mine fysiske standby-implementeringer ikke er N+1-kompatible, men derimod N. Jeg springer den overflødige ekstra node over for min fysiske standby. Hvorfor det? Rent ud fra et omkostningsperspektiv. Min fysiske standby er blot et sikkerhedsnet. Jeg vil have det til at virke for mig den dag, jeg har brug for det. Men jeg får det forhåbentlig aldrig brug for. Den fysiske standby er min forsikring, hvis risikoen bliver til virkelighed. For mig er den ekstra "+1" på standby-stedet overforsikring. Jeg kan spare på den fysiske hardware og Oracle-licenser.
Så lad os sige, at dagen kommer, og jeg laver failover til standby. Jeg har mistet min N+1 redundans. Men hvad er chancerne for, at jeg mister det primære datacenter *og* mister en af noderne i min standby-klynge? Ret ringe chancer. Sandsynligheden for fejl på to steder på samme tid er ret lille. På dette tidspunkt er vores it-team ved at evaluere, hvorfor vores primære datacenter går tabt, og hvornår vi højst sandsynligt kan returnere vores drift til den facilitet. Hvis det primære datacenter mistede al sin strøm, og forsyningsselskabet siger, at tjenesten vil blive gendannet i morgen, så kører vi bare ved standby-datacentret, selvom vi kun har N noder til RAC-databasen der. Men hvis det primære datacenter blev udslettet af en brand, vil det gerne tage mange måneder, før det er oppe at køre igen. Det er på dette tidspunkt, at jeg skal planlægge at få den fysiske standby op til N+1 redundans, da vores tid med at bruge den standby som primær vil være en meget længere periode. Så vi skynder os at bestille en anden server og tilføje den til klyngen så hurtigt som muligt. Så jeg designer min standby-RAC-database som N, ikke N+1 med henblik på at øge den til N+1 på kort tid, hvis vi beslutter, at vi vil bruge standbyen i virkeligheden i længere tid.
Så der er en anden speciel sag, jeg gerne vil diskutere. Det er der, DBA bestemmer, at N=1. For de nuværende arbejdsbelastningskrav er én node tilstrækkelig. Men vi ønsker at have høj tilgængelighed, så vi designer en to-node RAC-klynge til den primære database. Vi har nu N+1 redundans indbygget i den primære. Efter mit sidste afsnit behøver min standby-database kun 1 node. Den fejl, jeg ser nogle mennesker begår, er at oprette standbyen som en enkelt-instans database. Indtil videre giver deres logik mening. Den primære er N+1 og standbyen er N. Så langt så godt. Hvor jeg adskiller mig er, at jeg gør standby til en one-node RAC-klynge, ikke en ren enkelt-instans implementering. Årsagen er fremtidig vækst. På et tidspunkt kan DBA konstatere, at N ikke længere er lig med 1 ved den primære. Brugen er vokset, og N skal være 2 nu. DBA ønsker at udvide de primære til 3 noder (2+1). Dette er let nede med nul nedetid for at tilføje en ny node til klyngen og udvide RAC-databasen til den nye node. Men det er ikke så nemt at gøre standbyen til en 2-node klynge, hvis den 1 node, der eksisterer, ikke er RAC-aktiveret. Hvis en ren enkelt-instans standby er alt, der eksisterer, skal DBA'en skrotte den og flytte den til en to-node klynge. Hvis DBA'en havde forudseenhed og installerede Grid Infrastructure, som om den fysiske standby var en enkelt-node-klynge, så skal DBA kun tilføje en ny node, ligesom de gjorde på den primære side.
Mens du designer dine RAC-implementeringer, skal du overveje at sikre, at du har N+1-kapacitet på den primære og mindst N på standby. Hvis en virksomhed vurderer, at standby er for kritisk, vil de måske også implementere N+1 på standby. Hvis DBA bestemmer, at N=1, overvej at gøre standbyen til mindst en enkelt node RAC-klynge.