Friskrivningsklausul

Följande är avsett att beskriva den allmänna inriktningen för våra produkter. Det är endast avsett som information, och får inte infogas i ett avtal av något slag. Det är inget åtagande att leverera någon form av material, kod eller funktion, och ska inte fungera som underlag vid köp. Oracle Corporation förbehåller sig rätten, enligt eget gottfinnande, att ändra informationen om utvecklingen av, utgivandet av, tidpunkten för och prissättningen för de funktioner som här beskrivs för Oracles produkter.

I detta dokument besvaras vanliga frågor om hur Oracle uppnår återhämtningsförmåga och kontinuerlig tillgänglighet för våra viktigaste infrastrukturtjänster och vår värdplattform. Det finns flera skäl till att kunder till Oracle Cloud kan vara intresserade av detta:

  • Det hjälper kunderna att vara noggranna när de utvärderar Oracles värdplattform och tjänster.
  • I många av svaren diskuteras utmaningar och lösningar som gäller för alla system i molnskala, vilket är information som kan vara till nytta vid framtagningen av arkitektur och design för de system som kunderna vill skapa i molnet.

Frågor och svar om återhämtningsförmåga och kontinuerlig tillgänglighet för tjänsterna och plattformen i Oracles molninfrastruktur

Delar Oracle upp sina tjänster i olika klasser, till exempel kritiska tjänster, ständigt tillgängliga tjänster eller enplatstjänster?

Vi delar inte upp våra tjänster på det sättet. I stället kategoriserar vi våra tjänster utifrån beroendenivå, tillgänglighetsområde eller dataplan gentemot kontrollplan. Dessa kategorier har utformats för att skapa användbara avvägningar för tillgänglighet, hållbarhet, prestanda och enkelhet.

Beroendenivåer

Man kan tänka på de här nivåerna som lagren i ett blockdiagram över en systemarkitektur. Varje lager kanske bara är beroende av de lager som finns nedanför det.

Nedifrån och upp:

  • Huvudtjänsterna: De här tjänsterna utgör själva grunden i Oracles molninfrastruktur. Det är bland annat Identitets- och åtkomsthantering (IAM), Nyckelhantering, Nätverk, Beräkning, Blockvolymer, Objektlagring, Telemetrik och flera delade interna tjänster. De är utformade för att ha minimalt med beroenden, även inbördes. (Senare i detta dokument finns mer information om beroenden.)
  • IaaS: Detta lager har fler funktioner på infrastrukturnivå, och bygger på huvudtjänsterna. Tjänsterna i det här lagret är bland annat Fillager, Databas och Containermotor för Kubernetes.
  • SaaS: Det här lagret är funktionsrik programvara som en tjänst, och bygger på de lägre lagren.
Tillgänglighetsområde

För att uppfylla målen för tillgänglighet och hållbarhet för en tjänst ska ett av följande tillgänglighetsområden väljas för varje tjänst:

  • Tillgänglighetsdomän - lokal: Varje tillgänglighetsdomän innehåller en oberoende instans av tjänsten. Tjänster av den här typen har en hög hållbarhet för lagrade data, genom att synkron replikering används mellan kopior inom samma tillgänglighetsdomän (mer information finns i avsnittet om feldomäner senare i det här dokumentet). De här tjänsterna klarar av ett driftavbrott som drabbar en tredjedel eller mer av infrastrukturen i tillgänglighetsdomänen, beroende på hur tjänsten ser ut. Att tjänster av typen tillgänglighetsdomän - lokal kan vara så feltoleranta beror på att två olika sorters logiska datacenter (logiska grupper för felisolering och prestandaisolering) används inom tillgänglighetsdomänen. Mer information finns i avsnitten om feldomäner och tjänstceller senare i det här dokumentet. Slutligen kan dessa tjänster fungera normalt även om tillgänglighetsdomänen inte kan kommunicera med några andra tillgänglighetsdomäner. Därför klarar de av om andra tillgänglighetsdomäner går förlorade eller om hela regionens nätverk slutar fungera.
  • Flera tillgänglighetsdomäner - regional: Varje region med flera tillgänglighetsdomäner innehåller en oberoende instans av tjänsten, och komponenterna finns i varje tillgänglighetsdomän i den regionen. Tjänster av den här typen har en mycket hög hållbarhet för lagrade data, tack vare att synkron replikering till flera tillgänglighetsdomäner inom samma region används. De här tjänsterna klarar av ett driftavbrott för, eller förlorad kommunikation med, vilken enskild tillgänglighetsdomän som helst i regionen.
  • En tillgänglighetsdomän - regional: Om en region bara innehåller en enda tillgänglighetsdomän, ser egenskaperna för en regional tjänst ut som de för tjänster av typen tillgänglighetsdomän - lokal. Dessa beskrivs ovan. Skillnaden mellan en tjänst av typen tillgänglighetsdomän - lokal och en tjänst av typen en tillgänglighetsdomän - regional blir relevant först när en region med en enda tillgänglighetsdomän utvidgas genom att man lägger till en eller flera tillgänglighetsdomäner. När det händer utvidgas varje regional tjänst automatiskt så att den på ett lämpligt sätt utnyttjar de nya tillgänglighetsdomänerna, samtidigt som den förblir en enskild instans av tjänsten. Till exempel utvidgas objektlagringsdataplanet så att det använder de extra tillgänglighetsdomänerna för att förbättra hållbarheten för befintliga data. För tjänster av typen tillgänglighetsdomän - lokal får var och en av de nya tillgänglighetsdomänerna en ny och separat instans av varje tjänst av typen tillgänglighetsdomän - lokal.
  • Fördelad över regioner: En grundläggande princip för Oracles molninfrastruktur är att varje region drifttekniskt är så oberoende av alla andra regioner som möjligt. Att vi lägger till som möjligt beror på att regionerna av nödvändighet måste dela viss infrastruktur, till exempel stamnätet för kommunikation mellan regioner. Annars skapar vi inte tätt sammankopplade mekanismer mellan regionerna (till exempel för transparent hög tillgänglighet eller failover), som skulle kunna påverka flera regioner på samma gång. I stället tillhandahåller vi två mekanismer för att fördela tjänsterna mellan regionerna med en lös sammankoppling:
    • Katastrofåterställning (DR): Att låta våra kunder bygga system med DR-egenskaper är en hörnsten i vår inställning till och våra investeringar i molnet. Många av huvudtjänsterna har redan DR-mekanismer – till exempel säkerhetskopiering mellan regioner i Blockvolymer och kopiering mellan regioner i Objektlagring. För alla våra tjänster har DR-funktioner hög prioritet på vår lista över kommande funktioner.
    • Prenumerationer mellan regioner: För närvarande erbjuder vi bara prenumerationer mellan regioner för IAM-data. Konceptuellt sett har IAM-data en global täckning. Kunderna kan prenumerera på (anmäla sig till) en uppsättning regioner, och vi replikerar automatiskt relevanta IAM-data och kommande uppdateringar till de angivna regionerna. För att undvika tätt sammankopplade mekanismer mellan regionerna är replikeringen asynkron och så småningom konsekvent. Kunderna ändrar sina IAM-data i en ”hemregion” som de själva utser. Om den aktuella hemregionen blir otillgänglig eller olämplig av något skäl, kan en annan region utses.
Kontrollplan gentemot dataplan

Dataplanet för en tjänst är alla de databehandlande gränssnitt och komponenter som implementerar de funktioner i tjänsten som är avsedda att användas av applikationer. Till exempel innehåller dataplanet för ett virtuellt molnnätverk bearbetningssystemet för nätverkspaketet, virtualiserade routers och nätslussar, medan dataplanet för blockvolymer innehåller implementeringen av iSCSI-protokollet och det feltoleranta, replikerade lagringssystemet för volymdata.

Kontrollplanet för en tjänst är den uppsättning med API:er och komponenter som utför följande uppgifter:

  • Hanterar kundbegäranden om att etablera, konfigurera om, skalförändra eller avsluta resurser
  • Snabbt och säkert utför automatiserade säkerhetskorrigeringar i stora maskinparker
  • Identifierar ej fungerande, försämrade eller felaktigt konfigurerade resurser
  • Utför automatiserade reparationer eller aviserar mänsklig personal om en insats
  • Samarbetar med andra kontrollplan (t.ex. är Beräkning, Virtuella molnnätverk och Blocklagring sammankopplade under LaunchInstance)
  • Hanterar outnyttjad kapacitet
  • Samverkar med människor, t.ex. när ny utrustning anländer och vid fysiska reparationer och underhållsåtgärder
  • Ger insyn i och kontroll över driften
 
 

Hur säkerställer Oracle att tjänsterna har hög återhämtningsförmåga och kontinuerlig tillgänglighet?

För alla typer av tjänster använder vi samma konstruktionsprinciper för att uppnå hög återhämtningsförmåga och tillgänglighet, eftersom de grundläggande utmaningarna kring att konstruera feltoleranta, skalbara och distribuerade system är samma för alla typer av tjänster.

För att kunna uppnå hög återhämtningsförmåga och tillgänglighet måste man först förstå och sedan ta itu med alla de orsaker till otillgänglighet – försämrad prestanda och olösta problem – som finns i system i molnskala. Det finns mängder med sådana orsaker, så vi grupperar dem i olika kategorier utifrån hur de ser ut i grunden.

Förut brukade analyser av tillgängligheten i IT-system i storföretagsklassen fokusera på kategorin maskinvarufel. Men i molnsystem är maskinvarufel ett ganska litet och väl utforskat problem. Det är nu relativt enkelt att undvika eller lindra de flesta enskilda felpunkterna för maskinvaran. Till exempel kan rack ha dubbel strömförsörjning med tillhörande strömfördelningsenheter, och många komponenter kan bytas ut utan att utrustningen måste stängas av. Storskaliga fel på och förluster av maskinvara kan förstås inträffa – till exempel vid naturkatastrofer. Men enligt vår erfarenhet, och efter vad man kan läsa i offentliga rapporter från andra molnleverantörer, inträffar fel på eller förluster av hela datacenter extremt sällan, jämfört med andra orsaker till otillgänglighet. Storskaliga maskinvarufel måste ändå hanteras (till exempel med katastrofåterställning och andra mekanismer), men de är verkligen inte det dominerande tillgänglighetsproblemet.

De dominerande orsakerna till otillgänglighet i system i molnskala är följande:

  1. Buggar i programvaran
  2. Konfigurationsfel
  3. Misstag gjorda av mänskliga operatörer
    Obs! Den viktigaste lärdomen från branschen är att dessa tre former av mänskliga fel är den överlägset största orsaken till otillgänglighet. Även om frekvensen kan minskas med hjälp av verktyg, automatisering och utbildning går det inte att helt undvika dem. Därför måste de behandlas som de primära problemen när arkitekturen, designen och implementeringen av systemen tas fram.
  4. Oacceptabla variationer av prestandan (fördröjning eller dataflöde) av alla olika orsaker, inklusive följande:
    • ”Stökiga grannar” i system med flera innehav (QoS-mekanismer som inte fungerar)
    • Oförmågan att effektivt avvisa överbelastningar (oavsiktliga händelser eller avsiktliga angrepp) och samtidigt fortsätta fungera
    • Sönderhackning, stora mängder meddelanden, stora mängder begäranden om att försöka igen eller andra kostsamma ”uppdykande” interaktioner
    • ”Frysning” (tomma cacheminnen) efter att systemet stängts av och sedan slagits på igen, framförallt vid samtidig avstängning och påslagning av flera system
    • Extra resurser vid skalförändring (t.ex. när de horisontella partitionerna görs om)
  5. Oförmågan att begränsa ”tryckvågen” (antalet kunder och system som påverkas) för något av föregående problem

Detta är universella utmaningar – de är en del av ”fysikens lagar” för distribuerade system i molnskala.

För samtliga föregående kategorier använder vi beprövade teknikstrategier för att ta itu med problemet. De viktigaste av dem är:

  • Principer för arkitekturdesign och systemdesign
  • Nya arkitekturkoncept (som vanligtvis uppstår av att dessa principer tillämpas)
  • Teknikprocedurer för tjänsterna
Principer för arkitekturdesign och systemdesign

Det finns många sådana principer, men vi fokuserar på dem som är mest relevanta för återhämtningsförmåga och tillgänglighet.

Återställningsorienterad databehandling

För att hantera programbuggar och misstag av programmerare som har en relativt lokal påverkan följer vi principen om återställningsorienterad databehandling1. På en hög nivå innebär det att vi i stället för att garantera att vi aldrig har ett problem (vilket är omöjligt att testa), så fokuserar vi på att hantera alla problem med minimal störning, på ett sätt som går att testa. Framförallt fokuserar vi på att minimera den genomsnittliga tiden för återställandet (MTTR), vilket är en kombination av medelidentifikationstiden, medeldiagnostiden och medellösningstiden.

Vårt mål är att genomföra återställningen så snabbt att mänskliga användare inte besväras av problemet. Följande punkter hjälper oss att uppnå detta mål:

  • Snabbt och automatiskt identifiera symptomen på buggar och operatörsmisstag tack vare många ”assertion”-uttryck i koden och aktiv övervakning och avisering på alla nivåer.
  • Paketera funktionerna i många separata isolerade enheter på detaljnivå (trådar, processer, fibrer, tillståndsmaskiner osv.) som är löst sammankopplade – det vill säga att de inte direkt delar minne som kan bli skadat.
  • När symptomen på en bugg eller ett operatörsmisstag identifieras ska den isolerade enhet som de finns i startas om automatiskt så snabbt som möjligt. Omstart är ett praktiskt sätt att försöka återställa systemet från ett godtyckligt fel, eftersom det försöker återupprätta ett tillstånd som har testats ingående, och på så sätt återupprättar invarianter.
  • Om återställning på den isolerade detaljnivån inte fungerar (om till exempel assertion-uttrycken fortsätter att utlösas för ofta på den nivån) går man vidare till nästa större enhet (process, körning, värd, logiskt datacenter, kontakta en mänsklig operatör).
  • Skapa mekanismer för att möjliggöra ett ”undo-kommando på systemnivå”, inklusive versionshantering av alla beständiga tillstånd och konfigurationer, för att snabbt kunna identifiera och ångra felaktiga åtgärder.

Minimera effekten av problemen

För att hantera buggar och misstag som kan ha mer långtgående effekter skapar vi mekanismer för att minimera ”tryckvågen” för eventuella problem. Det innebär att vi fokuserar på att minimera antalet kunder, system eller resurser som påverkas av eventuella problem, inklusive de särskilt svåra problemen med ”stökiga grannar” i system med flera innehav, obehandlad överbelastning, försämrad kapacitet och sönderhackning. Vi uppnår detta genom att använda olika isoleringsgränser och metoder för ändringshantering (se följande avsnitt).

Arkitekturkoncept som uppstår ur designprinciper

Det finns många sådana koncept, men vi fokuserar på koncept som syftar till att begränsa tryckvågen.

Placeringskoncept som ingår i vår publika API: regioner, tillgänglighetsdomäner och feldomäner

Eftersom feldomäner är relativt nya beskriver vi dem mer ingående.

Feldomäner används för att begränsa tryckvågen för problem som uppstår när ändringar görs aktivt i ett system – till exempel vid distribution, säkerhetskorrigering, omstart av hypervisorer och fysiskt underhåll.

För en specifik tillgänglighetsdomän garanterar det att resurserna ändras i högst en feldomän åt gången. Om något går fel under ändringsprocessen kan vissa av eller alla resurserna i den feldomänen vara otillgängliga ett tag, men de andra feldomänerna i tillgänglighetsdomänen påverkas inte. Varje tillgänglighetsdomän innehåller minst tre feldomäner, för att systemet ska kunna vara värd åt beslutsbaserade replikeringssystem (till exempel Oracle Data Guard) med hög tillgänglighet inom en enskild tillgänglighetsdomän.

Vad beträffar många vanliga tillgänglighetsproblem (programbuggar, konfigurationsfel, misstag av operatörer och prestandaproblem som inträffar under en ändringsprocess) innebär detta att varje feldomän fungerar som ett separat logiskt datacenter inom en tillgänglighetsdomän.

Feldomäner skyddar också mot vissa typer av lokala maskinvarufel. Feldomänerna är utformade på ett sådant sätt, att resurser som placeras i olika feldomäner garanterat (i den utsträckning som det är praktiskt möjligt) inte delar någon potentiell enskild felpunkt för maskinvaran inom tillgänglighetsdomänen. Till exempel delar resurser i olika feldomäner inte på samma nätverksväxel högst upp i racket, eftersom sådana växlar som standard inte är redundanta.

Men feldomänernas förmåga att skydda mot problem i maskinvara eller i den fysiska miljön stannar på den lokala nivån. Till skillnad från tillgänglighetsdomäner och regioner ger feldomäner ingen fysisk isolering av infrastrukturen i stor skala. I sällsynta fall som naturkatastrofer eller att hela infrastrukturen i en tillgänglighetsdomän skulle sluta fungera påverkas resurserna i olika feldomäner antagligen på samma gång.

I våra interna tjänster används feldomäner på samma sätt som kunderna bör använda dem. Till exempel lagrar tjänsterna Blockvolymer, Objektlagring och Fillager kopior av data i tre separata feldomäner. Alla komponenter för alla kontrollplan och dataplan finns i alla tre feldomänerna (eller i flera tillgänglighetsdomäner i en region med flera tillgänglighetsdomäner).

Tjänstceller

Tjänstceller används för att begränsa tryckvågen för problem som uppstår även när ändringar inte görs aktivt i ett system. Sådana problem kan uppstå eftersom arbetsbelastningen för ett molnsystem med flera innehav när som helst kan ändras på extrema sätt, och eftersom komplexa, partiella fel när som helst kan inträffa i alla stora distribuerade system. I sådana scenarier kan små dolda buggar eller nya prestandaproblem utlösas.

Dessutom begränsar tjänstceller tryckvågen i vissa sällsynta men svåra scenarier när systemet aktivt förändras. Ett klassiskt exempel är när distributionen i en enskild feldomän verkar ha gått bra – inga fel eller prestandaförändringar – men när det så snart som den andra eller sista feldomänen har uppdaterats uppstår ett prestandaproblem till följd av nya interaktioner inom systemet (i full molnskala med produktionsbelastningen).

Lägg märke till att användandet av tjänstceller är ett arkitekturmönster, och inte ett namngivet koncept i vare sig API:erna eller utvecklingsverktygen för Oracles moln. Alla system med flera innehav kan använda det här arkitekturmönstret – det behövs inget särskilt stöd från molnplattformen.

Tjänstceller fungerar så här:

  • Varje instans av tjänsten (till exempel i en viss region, eller i en viss tillgänglighetsdomän för tjänster av typen tillgänglighetsdomän - lokal) består av flera separata distributioner av tjänstens programvarustack. Varje separat distribution kallas cell. I den utsträckning det är praktiskt möjligt har varje cell sin egen infrastruktur som värd. Ett lägsta krav är att cellerna inte delar värd eller virtuell maskin.
  • En tjänst kan börja med bara några få celler per tillgänglighetsdomän eller region. När tjänsten skalförändras för att möta en ökande efterfrågan läggs fler celler till, för att bevara begränsningen av tryckvågen från ett eventuellt problem. En stor och populär tjänst kan ha många celler. Med andra ord fungerar celler som en n:m-multiplexor för kundernas arbetsbelastning till separata värdmiljöer – separata isolerade resurser. Celler har ingen uppenbar kardinalitet, som till exempel feldomäner har. (Som vi nämnt tidigare är ett uppenbart val för feldomäners kardinalitet att ha tre per tillgänglighetsdomän, så att systemet kan vara värd åt beslutsbaserade replikeringssystem med hög tillgänglighet inom en enskild tillgänglighetsdomän.)
  • Varje ”naturlig enhet” i en kunds arbetsbelastning tilldelas en viss cell. Hur man definierar ”naturlig enhet” beror på hur tjänsten i fråga ser ut. För vår interna, delade tjänst Arbetsflöde (som beskrivs senare) skulle den naturliga enheten till exempel kunna vara ”alla arbetsflöden i den här tillgänglighetsdomänen eller regionen för ett visst kontrollplan”.
  • Framför varje grupp av celler finns antingen ett minimalistiskt dirigeringslager eller ett API för att identifiera cellslutpunkter. Till exempel har systemet för Strömning/Meddelanden ett API för att identifiera slutpunkten för det aktuella dataplanet för ett visst ämne, och det interna metadatalagret har en separat slutpunkt per cell. Men andra cellbaserade tjänster har bara en dataplanslutpunkt och ett delat dirigeringslager. Dirigeringslagret är en potentiell orsak till korrelerade fel på flera celler, men det kan lindras genom att man gör dirigeringslagret extremt enkelt och förutsägbart och ger det höga prestanda (inga kostsamma operationer), och att man etablerar det med mycket extra kapacitet och avancerade mekanismer för QoS-kvot och bromsning.
  • Ägarna till tjänsterna kan flytta en arbetsbelastning från en cell till en annan efter behov. Här följer några scenarier som exempel:
    • För att försöka undvika problemet med ”stökiga grannar” i system med flera innehav genom att flytta en tung arbetsbelastning så att andra användare av en cell inte påverkas.
    • För att underlätta återställningen efter en överbelastning eller ett strömavbrott, som kan ha orsakats av ett DDoS-angrepp. Vi har kvot- och bromsmekanismer som försvar mot sådana angrepp, men ibland inträffar ytterligheter där ett visst användningsfall (API, åtkomstmönster) är mer påfrestande för tjänsten än kvot- eller bromssystemet för närvarande kan uppfatta. Celler kan användas som en mekanism för att lösa detta på kort sikt.
    • För att skilja kritiska arbetsbelastningar från varandra i olika celler, vilket ger en betydande minskning av sannolikheten för korrelerade fel. I vårt interna delade arbetsflöde för kontrollplan tilldelas till exempel de kritiska huvudkontrollplanen (t.ex. Plattform, Beräkning, Nätverk och Blockvolymer) alla till olika celler, och därför har de avsevärt mycket lägre felkorrelation än vad de hade haft om celler inte hade använts, eller om de hade tilldelats till samma cell.
      Obs! Om celler används på detta sätt blir det inte lika viktigt att ta hänsyn till tjänsternas interna beroenden för att kunna skapa motståndskraftiga applikationer. Det är fortfarande bra praxis att beakta beroendediagrammet (mer om det senare i dokumentet), men det behövs inte i samma utsträckning när det redan finns en aktiv dekorrelationsmekanism.

Resultatet är att varje tjänstcell blir ytterligare en typ av ”logiskt datacenter” (en logisk gruppering för felisolering och prestandaisolering) inom en och samma tillgänglighetsdomän eller region.

Kort sagt kompletterar tjänstceller och feldomäner varandra på följande sätt:

  • Feldomäner skyddar mot problem som uppstår när ett system ändras aktivt
  • Tjänstceller begränsar tryckvågen när potentiellt allvarliga problem uppstår i ett system – oavsett om det håller på att ändras aktivt eller inte

Vi kombinerar egenskaperna hos feldomäner och tjänstceller i en enhetlig strategi när vi genomför distributioner och säkerhetskorrigeringar.

Teknikprocedurer för tjänsterna

Eftersom både tester och verksamhetsoptimering är kritiska för att molnsystem ska vara driftsäkra har vi ett stort antal teknikprocedurer. Här följer några av de viktigare, som bygger på de koncept som nämndes i föregående avsnitt:

  • Vi distribuerar tjänsterna stegvis, med noggrann validering mellan stegen, och backar för undersökning om det händer något oväntat. Så här ser processen ut rent praktiskt:
    • I varje tillgänglighetsdomän distribuerar vi till en tjänstcell åt gången. För varje cell distribuerar vi till en feldomän åt gången, till dess vi är klara med alla feldomäner för den cellen. Sedan går vi vidare till nästa cell i den tillgänglighetsdomänen.
    • Efter varje steg i distributionen (efter varje feldomän och cell) kontrollerar vi att ändringen fungerar som tänkt – det vill säga att vi inte försämrat prestandan eller infört några fel, vare sig internt eller externt. Om någonting verkar vara fel eller oväntat backar vi för undersökning. Vi betonar kraftigt vikten av förberedelser och tester, inklusive automatiserade tester, av återställningsprocedurerna, inklusive ändringar som påverkar beständiga tillstånd eller scheman.
    • På detta sätt distribuerar vi ändringen en tillgänglighetsdomän i taget till samtliga regioner. Vi distribuerar till alla regionerna i en sfär på ett sådant sätt att vi inte samtidigt modifierar två regioner som någon kund kan använda som primär webbplats och katastrofåterställningswebbplats.
  • Vi kontrollerar regelbundet att felhanteringsmekanismer och andra lösningar fungerar som väntat och inte gör problemet värre i full skala. Utan sådana tester är det vanligt att felhanteringsmekanismer (som omförsök, algoritmer för kraschåterställning och omkonfigureringsalgoritmer för tillståndsmaskiner) har buggar, är för kostsamma eller interagerar på överraskande sätt, och på så sätt orsakar sönderhackning eller andra allvarliga prestandaproblem.
  • Vi kontrollerar vår förmåga att snabbt och säkert återställa systemet till den senast kända fungerande programvaran och konfigurationen, inklusive beständiga tillstånd och scheman, som vi beskrivit tidigare.
 
 

I Oracle-regioner som har flera tillgänglighetsdomäner, fördelas alla kritiska tjänster över tillgänglighetsdomänerna?

Ja. I varje region har samtliga tillgänglighetsdomäner samma uppsättning tjänster.

 
 

Hur undviker Oracle och Oracles kunder att ha en kritisk tjänst som är beroende av ett enda logiskt datacenter?

I regioner med en enda tillgänglighetsdomän kan kunderna använda feldomäner (logiska grupper med dekorrelerade fellägen mellan grupperna) och på så sätt få de flesta egenskaperna hos separata ”logiska datacenter”. Kunderna kan också använda flera regioner för katastrofåterställning (DR).

I våra regioner med flera tillgänglighetsdomäner kan kunderna använda feldomäner på samma sätt. De kan också använda en kombination av tjänster av typen tillgänglighetsdomän - lokal, failover-funktioner mellan tillgänglighetsdomäner (till exempel DBaaS med Dataskydd) och regionala tjänster (Objektlagring, Strömning) för att uppnå hög tillgänglighet över flera ”logiska datacenter” (tillgänglighetsdomäner) på de högre nivåerna. Slutligen kan kunderna också använda flera regioner för DR.

I samtliga fall kan kunderna använda konceptet med tjänstceller för att gå vidare och isolera till och med de mest allvarliga problemen, som sönderhackning.

 
 

Hur utför Oracle underhållsaktiviteter utan att någon kritisk tjänst tillfälligt blir otillgänglig för någon kund?

Vi uppnår detta via feldomäner, tjänstceller och våra driftrutiner med stegvis distribution och kontroll. Se diskussionen tidigare i detta dokument.

 
 

Distribueras serverlösa plattformstjänster över flera logiska datacenter för högre tillgänglighet?

Ja. Alla kategorier av tjänster distribueras över flera logiska datacenter – separata logiska grupperingar för felisolering och prestandaisolering – för återhämtningsförmåga och kontinuerlig tillgänglighet.

 
 

Om återhämtningsförmåga inte är standardkonfigurationen, kan kunderna välja en distribution med flera logiska datacenter (till exempel en konfiguration som har flera tillgänglighetsdomäner eller som sträcker sig över flera regioner)?

I regioner med en enda tillgänglighetsdomän kan vi erbjuda feldomäner som en mekanism för ”flera logiska datacenter”, som vi har diskuterat på annan plats i det här dokumentet.

I regioner med flera tillgänglighetsdomäner erbjuder vi tjänster och funktioner som ger en ännu högre nivå av fysisk hållbarhet med synkront replikerade data (med medelhög prestanda, en kostnad som beror på avståndet mellan tillgänglighetsdomänerna i regionen och ljusets hastighet).

Vi erbjuder inte automatisk hög tillgänglighet eller failover-mekanismer över flera regioner, eftersom det skulle skapa en tät sammankoppling mellan regionerna, vilket gör att flera regioner riskerar att få problem på samma gång. I stället har vi olika former av asynkron replikering mellan regionerna, och listan över funktioner växer ständigt, med till exempel asynkron kopiering och säkerhetskopiering för att möjliggöra katastrofåterställning över flera regioner.

 
 

Hur hjälper Oracle sina kunder att undvika korrelerade fel på applikationer som orsakas av interna beroenden mellan de olika infrastruktur- och plattformstjänsterna?

Detta är en komplicerad fråga, så för att förtydliga formulerar vi om det på några olika sätt:

  • Om en kund vill använda två Oracle-tjänster (tjänst A och tjänst B), och vill bygga en applikation som är motståndskraftig även om någon av de tjänsterna slutar fungerar, måste kunden då veta om tjänst A är beroende av tjänst B internt? Leder interna beroenden i hög grad till korrelerade fel? I så fall kan kunden behöva känna till dessa interna beroenden, för att kunna bestämma på vilka andra sätt som tjänst A och tjänst B kan användas (eller om man i stället ska använda den orelaterade tredje tjänsten C för dessa andra användningsfall) när de bygger sina egna återhämtningsmekanismer på applikationsnivån.
  • Hur försvarar sig kunden bäst mot eventuella korrelerade fel i Oracles tjänster?

Svaret består av två delar.

Arkitektoniska principer

Vi använder oss av arkitektoniska principer som ger en avsevärd minskning av korrelerade fel mellan tjänster som är beroende av varandra. I vissa fall minskar den här tekniken sannolikheten för korrelerade fel så mycket att den inte behöver tas med i beräkningen när det gäller att uppfylla ett servicenivåavtal för tillgänglighet.

Framförallt använder vi tjänstceller, som vi beskrivit tidigare i det här dokumentet. Celler underlättar arbetet med sådana här problem, för om den interna tjänsten A påverkas av ett problem i ett av sina beroenden, tjänst B, då är det troligt att problemet i tjänst B bara gäller en av dess celler. Andra tjänster på högre nivå (och kundens egna applikationer) som använder tjänst B använder antagligen andra celler, som inte påverkas. Detta är ett sannolikhetsargument som varierar med antalet celler, vilket är en dold intern parameter som förändras (ökar), så det kan inte kvantifieras eller garanteras utöver de fristående servicenivåavtalen för tjänsterna A och B. Men i praktiken kan detta leda till en betydande dekorrelation av fel mellan tjänster.

Många av våra delade interna tjänster (till exempel tjänsterna Arbetsflöde och Metadata för kontrollplan och tjänsten Strömning/Meddelanden) använder tjänstceller för att dekorrelera driftavbrott för de tjänster uppströms som använder dem.

Beroenden

Följande riktlinjer gäller för en högre nivå, eftersom implementeringen på låg nivå och detaljerna i tjänsterna ibland förändras. Men för de viktigaste dimensionerna – beräkning, lagring, nätverk och autentisering/auktorisering – finns följande beroenden.

För kontrollplan ser de vanliga beroendena ut som följer:

  1. Identitet/Plattform-dataplanet för autentisering och auktorisering
  2. Spårningstjänsten för granskning
  3. Interna tjänster som till exempel tillhandahåller arbetsflöde, metadatalagring och loggning
  4. Olika typer av lastbalanserare

Vissa kontrollplan har förstås tjänstspecifika beroenden. Till exempel är Beräkning-kontrollplanet, när en instans utan särskilt operativsystem eller en instans på en virtuell maskin startas, beroende av:

  • Objektlagring (för att hämta angiven operativsystemavbild)
  • Blockvolymer-kontrollplanet (för etablering och koppling av startvolymen)
  • Nätverk-kontrollplanet (för etablering och koppling av VNIC-enheter)

För dataplan för huvudtjänster är grundprincipen att varje dataplan avsiktligen utformats för att ha så få beroenden som möjligt för hög tillgänglighet, snabba diagnoser och snabba återställningar. Den principen ger följande resultat:

  • Nätverk-dataplanet är självständigt.
  • Blockvolymer-dataplanet är självständigt.
  • Beräkningsinstanser på servrar utan särskilt operativsystem och på virtuella maskiner är beroende av Blockvolymer-dataplanet (för startvolymer) och Nätverk-dataplanet.
  • Objektlagring-dataplanet är beroende av Identitet/Plattform-dataplanet för autentisering och auktorisering (på grund av vad branschen förväntar sig). Objektlagring-dataplanet är inte beroende av Blockvolymer eller Fillager.
  • Alla tjänster som har stöd för säkerhetskopiering och återställning är beroende av Objektlagring-dataplanet för den funktionaliteten.

För IaaS-dataplan är grundprincipen att de bara ska vara beroende av huvuddataplan eller dataplan på lägre nivå (för att undvika cirkelberoenden).

  • Databas-RAC med flera noder är beroende av Nätverk-dataplanet och Blockvolymer-dataplanet.
  • Containermotor för Kubernetes är förstås beroende av Kubernetes och dess beroenden (till exempel etcd) samt av Nätverk-dataplanet.
  • Allt stöd för säkerhetskopiering och återställning är beroende av Objektlagring-dataplanet.

1Ett offentligt forskningsprogram från Stanford och Berkeley, som leds av Armando Fox och Dave Patterson

 
×
Ring oss nu
1-800-633-0738 (USA)

Kontakt
×
Ring oss nu
1-800-633-0738 (USA)


Diskussionsforum om Oracle Cloud