sql >> Databasteknik >  >> RDS >> Oracle

N+1-redundans och serverkonsolidering

I ett tidigare blogginlägg pratade jag om att designa dina RAC-implementationer med N+1-redundans. Detta säkerställer att förlusten av en nod inte överväldigar de återstående noderna om en nod skulle misslyckas. Idag ska jag diskutera effekten av serverkonsolidering, särskilt CPU-kärnor, och dess potentiella N+1-effekter.

Ett av huvudsystemen jag arbetar med idag är ett Oracle RAC-kluster med fyra noder. Varje nod har 4 kärnor. Jag är licensierad för alla 16 kärnor (4 kärnor/nod * 4 noder =16 totala kärnor) i min miljö. Jag designade detta system med N+1 redundans. Om jag tappar en nod och tappar fyra kärnor är jag fortfarande bra eftersom mina arbetsbelastningskrav bara kräver 12 kärnor för att upprätthålla normala, acceptabla prestandanivåer.

När detta system ursprungligen designades var servrar med 4 kärnor vanliga. Dagens miljö är annorlunda och det blir svårare att hitta servrar med fyra kärnor. De finns fortfarande, men hårdvaruleverantörer driver system med större kärnantal.

I ett samtal med min SysAdmin nyligen ville han beställa 6-kärniga system för att ersätta våra 3 år gamla servrar. Tja, vi kan inte bara göra det. Min Oracle-licens är för 16 kärnor. Jag skulle kunna distribuera tre 6-kärniga system, men då skulle jag ha totalt 18 kärnor i klustret och jag skulle behöva ha ytterligare två kärnor värda Oracle-licenser. Om jag distribuerade två 6-kärniga system skulle jag ha totalt 12 kärnor och ha licenser till ett värde av fyra kärnor som står oanvända.

Jag informerade också SysAdmin om vår N+1-design. Effekten av att flytta till system med 6 kärnor kan ha stora konsekvenser för N+1-designen. Kom ihåg att jag sa tidigare att våra arbetsbelastningskrav kräver 12 kärnor för att upprätthålla normala driftsnivåer. Om vi ​​distribuerar 6-kärniga maskiner så uppfyller två av dem våra krav och en annan nod, "+1", skulle behövas för att säkerställa att vi kan förlora en nod utan större inverkan på prestandan. Vi skulle behöva distribuera tre 6-kärniga maskiner för att behålla vårt N+1-designmål intakt. Men detta betyder att vi måste öka antalet licenser som jag sa tidigare.

Vid det här laget trodde min systemadministratör att han hade en bra idé...vi kunde köpa två 8-kärniga servrar. Det är fortfarande 16 totala kärnor och exakt vad vi är licensierade för idag. Ingen höjning av licensavgifterna. Men om vi tappar en nod går vi ner till 8 totala kärnor i drift vilket är mindre än vad jag behöver. Detta tar upp en mycket bra poäng...

Just nu finns det inget enkelt svar. Vi kan fortfarande köpa servrar med fyra kärnor så det är vad vi kommer att ersätta de nuvarande med nästa år. Men det kommer en dag då 4-kärniga servrar är omöjliga att hitta. Vi måste ha en plan på plats vid den tidpunkten, med våra N+1 designmål i åtanke.

Om jag bara kunde hårdpartitionera våra Linux-servrar och låta kärnor vara inaktiva och fortfarande följa våra Oracle-licensavtal.


  1. Trender under 2020 som DBA:er bör vara medvetna om

  2. Oracle motsvarighet till Postgres' DISTINCT ON?

  3. MySQL-servern har försvunnit - på exakt 60 sekunder

  4. Importera .csv-fil till ett Oracle Forms-program