Ik merk dat wanneer mensen Oracle RAC-architectuur ontwerpen, ze vaak niet denken aan N+1-redundantie in hun implementatieplannen. Er zijn twee redenen om Oracle RAC te implementeren:beschikbaarheid en schaalbaarheid. Voor de doeleinden van deze discussie richt ik me alleen op de beschikbaarheidskant. Als uw RAC-implementaties alleen voor schaalbaarheidsredenen zijn, is dit onderwerp mogelijk niet op u van toepassing.
Dus wat is N+1 Redundantie? Simpel gezegd, als je N eenheden van iets nodig hebt, dan zou je voor redundantiedoeleinden N+1 van dat item moeten hebben. Laten we eens kijken naar een databaseserver. Het moet een stroomvoorziening hebben. Dat is een vereiste. Zonder een werkende voeding werkt de server helemaal niet. Het minimum aantal voedingen is 1. Als we willen dat deze server een hoge mate van beschikbaarheid heeft, zorgen we ervoor dat deze N+1 voedingen heeft, of in dit geval dubbele voedingen. Als er maar één voeding is en deze uitvalt, neemt hij de server mee. Als we een extra voeding hebben, een reserve-eenheid, zal het verlies van één voeding de server niet mee uitvallen. Redundantie is geweldig om te hebben en een essentieel onderdeel van een infrastructuur met hoge beschikbaarheid.
Bij het ontwerpen van een Oracle RAC-systeem moet de DBA bepalen hoeveel nodes nodig zijn om aan de eisen van de eindgebruiker te voldoen. Als de DBA bepaalt dat er 4 nodes nodig zijn en dit RAC-cluster hoge-beschikbaarheidskenmerken moet vertonen, is het van vitaal belang dat de DBA een cluster met 5 nodes maakt (4+1). Als de resourcevereisten voldoende zijn om 4 knooppunten bezig te houden en één knooppunt verloren gaat, kunnen de overige 3 de werklast niet bijhouden. Als de DBA het RAC-systeem bouwt met N+1-mogelijkheden in gedachten, zal het verlies van één knooppunt niet merkbaar zijn voor de eindgebruikers. Als de DBA het RAC-cluster bouwt zonder N+1-redundantie, kan het verlies van één knooppunt zo verschrikkelijk zijn voor de prestaties van de eindgebruiker, dat het hele cluster net zo goed uit de lucht kan vallen. Streef bij het ontwerpen van uw RAC-implementaties naar N+1-redundantie.
Ik herinner me dat ik twee jaar geleden een RAC-cluster had die een knooppunt verloor. Geen probleem, we hadden nog twee nodes beschikbaar. Toen ik de prestaties van de twee resterende knooppunten bekeek, leken ze behoorlijk overweldigd te zijn. Ons callcenter begon klachten te ontvangen. Ik heb met andere beheerders van het IT-team gewerkt om dat knooppunt zo snel mogelijk weer aan de gang te krijgen, maar dit is misschien niet altijd het geval als de reden voor de storing hardware-gerelateerd is en onderdelen moeten worden vervangen. Nadat het knooppunt weer in gebruik was, heb ik de clusterprestaties weken later gevolgd. Ons gebruik was gegroeid sinds dit systeem in eerste instantie werd ontworpen. We hadden dit systeem aanvankelijk ontworpen met N+1-redundantie in gedachten, maar ons gebruik groeide en N ging van 2 naar 3. Ons huidige cluster met 3 knooppunten was niet langer N+1-redundant. Dus werkte ik samen met het management om genoeg geld in het budget van volgend jaar te steken om een nieuw knooppunt aan te schaffen en ervoor te zorgen dat Oracle er een licentie voor had. Ik slaap 's nachts veel beter, wetende dat ik weer N+1 redundantie heb.
Zoals bij veel andere implementaties is mijn RAC-systeem niet de enige hoge-beschikbaarheidsfunctie die in onze infrastructuur is ingebouwd. Deze RAC-database is een primaire voor een fysieke standby-database met Oracle's Data Guard. Het verbaast me wanneer ik RAC-standbydatabases met andere Oracle DBA's bespreek hoeveel van hen niet denken aan N+1-mogelijkheden voor hun stand-by. De fysieke standby-database is mijn vangnet voor het geval het primaire datacenter om de een of andere reden niet beschikbaar is. Ik heb zoveel Oracle DBA's een stand-by voor één instantie zien implementeren voor een primaire RAC met meerdere knooppunten. Au! Ik hoop dat ze nooit hoeven te falen. De werklast van hun hele multi-node RAC-cluster zal enorm worstelen op die standby-stand van één instantie. Dus als u uw RAC-implementaties ontwerpt voor zowel de primaire als de stand-by, moet u rekening houden met uw N+1-redundantie-implicaties voor het architectuurontwerp.
Waar ik waarschijnlijk van veel mensen anders ben, is dat mijn fysieke standby-implementaties niet N+1-capabel zijn, maar eerder N. Ik sla de overtollige extra node voor mijn fysieke standby over. Waarom is dat? Puur uit kostenoogpunt. Mijn fysieke stand-by is slechts een vangnet. Ik wil dat het voor mij werkt op de dag dat ik het nodig heb. Maar ik hoop het nooit nodig te hebben. De fysieke stand-by is mijn verzekering voor het geval risico werkelijkheid wordt. Voor mij is die extra "+1" op de stand-by-site oververzekering. Ik kan besparen op de fysieke hardware en Oracle-licenties.
Dus laten we zeggen dat de dag komt en ik doe een failover naar de stand-by. Ik ben mijn N+1-redundantie kwijt. Maar hoe groot is de kans dat ik het primaire datacenter *en* een van de nodes in mijn standby-cluster kwijtraak? Vrij kleine kansen. De kans op storingen op twee locaties tegelijk is vrij klein. Op dit moment evalueert ons IT-team waarom ons primaire datacenter verloren is gegaan en wanneer we hoogstwaarschijnlijk onze activiteiten naar die faciliteit kunnen terugbrengen. Als het primaire datacenter al zijn stroom verliest en het nutsbedrijf zegt dat de service morgen wordt hersteld, dan werken we gewoon in het standby-datacenter, ook al hebben we daar maar N-knooppunten voor de RAC-database. Als het primaire datacenter echter door een brand is verwoest, duurt het nog vele maanden voordat het weer operationeel is. Het is op dit punt dat ik moet plannen om die fysieke stand-by tot N+1 redundantie te krijgen, aangezien onze tijd om die stand-by als primaire stand-by te gebruiken een veel langere periode zal zijn. Dus we haasten ons om nog een server te bestellen en deze zo snel mogelijk aan het cluster toe te voegen. Dus ik ontwerp mijn stand-by RAC-database als N, niet als N+1 met het oog op het verhogen tot N+1 in korte tijd als we vaststellen dat we de stand-by echt voor een langere periode zullen gebruiken.
Er is dus nog een speciaal geval dat ik wil bespreken. Dat is waar de DBA bepaalt dat N=1. Voor de huidige workload-eisen is één node voldoende. Maar we willen een hoge beschikbaarheid hebben, dus ontwerpen we een RAC-cluster met twee knooppunten voor de primaire database. We hebben nu N+1 redundantie ingebouwd in de primaire. Na mijn laatste paragraaf heeft mijn standby-database slechts 1 knooppunt nodig. De fout die ik sommige mensen zie maken, is om de stand-by als een database met één instantie te maken. Tot nu toe is hun logica logisch. De primaire is N+1 en de stand-by is N. Tot nu toe gaat het goed. Waar ik van verschil, is dat ik van de stand-by een RAC-cluster met één knoop maak, niet een pure implementatie met één instantie. De reden is voor toekomstige groei. Op een gegeven moment kan de DBA ontdekken dat N niet langer gelijk is aan 1 bij de primaire. Het gebruik is gegroeid en N moet nu 2 zijn. De DBA wil de primaire uitbreiden tot 3 nodes (2+1). Dit is eenvoudig uit te schakelen zonder downtime om een nieuw knooppunt aan het cluster toe te voegen en de RAC-database uit te breiden naar dat nieuwe knooppunt. Maar het is niet zo gemakkelijk gedaan bij de reserve om van de reserve een cluster met 2 knooppunten te maken als dat 1 knooppunt dat bestaat niet RAC-enabled is. Als er alleen pure stand-by met één exemplaar is, moet de DBA deze schrappen en naar een cluster met twee knooppunten verplaatsen. Als de DBA een vooruitziende blik had en Grid Infrastructure installeerde alsof de fysieke stand-by een cluster met één knooppunt was, dan hoeft de DBA alleen maar een nieuw knooppunt toe te voegen, net zoals ze deden aan de primaire kant.
Overweeg bij het ontwerpen van uw RAC-implementaties ervoor te zorgen dat u N+1-mogelijkheden hebt op de primaire en ten minste N op de stand-by. Als een bedrijf vaststelt dat de standby te kritisch is, wil ze misschien ook N+1 op de standby implementeren. Als de DBA vaststelt dat N=1, overweeg dan om van de standby ten minste een RAC-cluster met één knooppunt te maken.