Ansvarsfraskrivelse

Denne delen beskriver vår generelle produktretning. Den er bare til informasjon og kan ikke legges inn i noen kontrakt. Det er ikke en forpliktelse til å levere materiale, kode eller funksjonalitet, og skal ikke vektlegges ved kjøpsbeslutninger. Utvikling, utgivelse, tidspunkt og prising av funksjoner som er beskrevet for Oracles produkter, kan endres og fastsettes etter eget skjønn fra Oracle Corporation.

Vanlige spørsmål gir svar på spørsmål om hvordan Oracle oppnår motstandsdyktighet og kontinuerlig tilgjengelighet i de viktigste infrastrukturtjenestene og på vertsplattformen. Oracle Cloud-kunder kan være interessert i disse svarene av flere årsaker:

  • De hjelper kunder å praktisere due diligence ved vurdering av Oracles vertsplattform og tjenester.
  • Mange av svarene drøfter utfordringer og løsninger som er grunnleggende for alle systemer i skyskala, og kan derfor gi opplysninger om arkitekturen og utformingen av systemer kundene vil bygge i skyen.

Vanlige spørsmål om motstandsdyktighet og kontinuerlig tilgjengelighet for Oracle Cloud Infrastructure-tjenester og plattform

Skiller Oracle mellom ulike tjenesteklasser, for eksempel kritiske tjenester, kontinuerlig tilgjengelige tjenester eller tjenester på ett sted?

Vi har ikke slike skiller. I stedet kategoriserer vi tjenestene etter avhengighetsnivå, tilgjengelighetsomfang og dataplan kontra kontrollplan. Disse kategoriene er utformet slik at de gir ulike nyttige avveininger mellom tilgjengelighet, holdbarhet, ytelse og nytteverdi.

Avhengighetsnivåer

Disse nivåene kan regnes som lag eller nivåer i et arkitektonisk blokkdiagram. Hvert lag kan bare være avhengig av lagene under.

Fra øverst til nederst:

  • Kjernetjenester: Disse tjenestene danner grunnlaget for Oracle Cloud Infrastructure. De omfatter Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry og flere delte interne tjenester. De er utformet til å ha et minimum av avhengigheter, også mellom hverandre. (Du finner flere opplysninger om avhengigheter senere i dette dokumentet.)
  • IaaS: Dette laget gir flere funksjoner på infrastrukturnivå som bygger på kjernen. Tjenester i dette laget omfatter File Storage, Database og Container Engine for Kubernetes.
  • SaaS: Dette laget er rik programvare som en tjeneste, som bygger på lavere lag.
Tilgjengelighetsomfang

Ett av følgende tilgjengelighetsomfang velges for hver enkelt tjeneste, slik at målene for tilgjengelighet og holdbarhet for en tjeneste oppfylles:

  • Tilgjengelighetsdomene lokalt: Hvert enkelt tilgjengelighetsdomene inneholder én uavhengig forekomst av tjenesten. Slike tjenester gir god holdbarhet for lagrede data gjennom bruk av synkron replikering mellom replikater i det samme tilgjengelighetsdomenet (du finner flere opplysninger i delen om feildomener senere i dette dokumentet). Disse tjenestene tåler et avbrudd i en tredjedel av infrastrukturen eller mer i tilgjengelighetsdomenet, avhengig av tjenestens art. Lokale tjenester i tilgjengelighetsdomenet oppnår dette nivået av feiltoleranse ved å bruke to ulike typer logiske datasentre, som er logiske grupper for feilisolasjon og ytelsesisolasjon, i tilgjengelighetsdomenet. Hvis du vil ha flere opplysninger, kan du se delene om feildomener og tjenesteceller senere i dette dokumentet. Disse tjenestene kan også fortsette å fungere som normalt selv om tilgjengelighetsdomenet ikke kan kommunisere med andre tilgjengelighetsdomener. De tåler derfor tap av andre tilgjengelighetsdomener eller fullstendig svikt i fjernnettet i regionen.
  • Flere regionale tilgjengelighetsdomener: Hver enkelt region med flere tilgjengelighetsdomener inneholder én uavhengig forekomst av tjenesten, med komponenter i hvert enkelt tilgjengelighetsdomene i regionen. Disse tjenestene gir svært god holdbarhet for lagrede data gjennom bruk av synkron replikering til flere tilgjengelighetsdomener i samme region. Disse tjenestene tåler et avbrudd i eller manglende mulighet til å kommunisere med ett tilgjengelighetsdomene i regionen.
  • Ett regionalt tilgjengelighetsdomene: Hvis en region bare inneholder ett tilgjengelighetsdomene, samsvarer de observerbare egenskapene til en regional tjeneste med egenskapene til en lokal tjeneste i tilgjengelighetsdomenet, som beskrevet tidligere. Forskjellen mellom en lokal tjeneste i et tilgjengelighetsdomene og en regional tjeneste i ett tilgjengelighetsdomene blir bare relevant når en region med ett tilgjengelighetsdomene utvides ved å legge til ett eller flere tilgjengelighetsdomener. Når dette skjer, utvides hver enkelt regionale tjeneste automatisk og bruker de nye tilgjengelighetsdomenene på egnet måte, samtidig som én forekomst av tjenesten beholdes. Dataplanet Object Storage utvides for eksempel til å bruke de ekstra tilgjengelighetsdomenene til å forbedre holdbarheten for eksisterende data. For lokale tjenester i tilgjengelighetsdomener mottar imidlertid hvert av de nye tilgjengelighetsdomenene sin egen nye og separate forekomst av hver lokal tjeneste i tilgjengelighetsdomenet.
  • Distribuert på tvers av regioner: Et grunnleggende prinsipp i Oracle Cloud Infrastructure er at hver enkelt region er så driftsuavhengig fra andre regioner som mulig. Forbeholdet som mulig gjenspeiler det faktum at regioner nødvendigvis må dele minst en del av infrastrukturen, for eksempel det grunnleggende nettverket mellom regionene. Ellers bygger vi ikke mekanismer med tette koblinger mellom regioner, for eksempel transparent høy tilgjengelig eller failover, som kan føre til problemer som påvirker flere regioner samtidig. I stedet angir vi to mekanismer for distribusjon av tjenester på tvers av regioner med løse koblinger:
    • Nødgjenoppretting: Det at kundene kan bygge systemer med nødgjenopprettingsegenskaper, er svært viktig i metodene våre og investeringen i skyen. Flere kjernetjenester tilbyr allerede mekanismer for nødgjenoppretting, for eksempel sikkerhetskopiering mellom regioner for Block Volumes og kopiering mellom regioner for Object Storage. Alle tjenestene våre har nødgjenopprettingsfunksjoner som høyt prioriterte elementer i veikartet.
    • Abonnementer mellom regioner: Vi tilbyr for øyeblikket bare abonnementer mellom regioner for IAM-data. Konseptet IAM-data har globalt omfang. Kunder kan abonnere på (samtykke til) et sett med regioner, og vi replikerer automatisk de relevante IAM-dataene og etterfølgende oppdateringer til de angitte regionene. Tette tilkoblinger unngås ved at replikeringen er asynkron og til slutt konsekvent. Kunder gjør endringer i IAM-dataene i en "hjemmeregion" som de nominerer. Hvis den gjeldende hjemmeregionen av én eller annen grunn blir utilgjengelig eller uegnet, kan en annen region nomineres.
Kontrollplan kontra dataplan

Dataplanet for en tjeneste er samlingen med grensesnitt og komponenter for databehandling som implementerer tjenestefunksjoner som er ment for bruk i applikasjoner. Dataplanet for det virtuelle skynettverket (VCN) inkluderer for eksempel systemet for behandling av nettverkspakker, virtuelle rutere og innfallsporter, mens dataplanet for Block Volumes inkluderer implementeringen av iSCSI-protokollen og det feiltolerante replikerte lagringssystemet for volumdata.

Kontrollplanet for en tjeneste er settet med API-er og komponenter som har ansvaret for følgende oppgaver:

  • Håndtering av kundeforespørsler om klargjøring, ny konfigurasjon, opp-/nedskalering eller avslutning av ressurser
  • Utførelse av automatisk oppdatering av store flåter på en rask og sikker måte
  • Oppdagelse av mislykkede, degraderte eller feilkonfigurerte ressurser
  • Utførelse av automatiske reparasjoner, eller tilkalling av menneskelige operatører for hjelp
  • Samarbeid med andre kontrollplan (Compute, VCN, Block Storage kobles for eksempel under LaunchInstance)
  • Håndtering av ubrukt kapasitet
  • Koordinasjon med mennesker, for eksempel ved ankomst av nytt utstyr, og fysiske reparasjoner og vedlikehold
  • Driftsoversikt og -kontroll
 
 

Hvordan sørger Oracle for at tjenestene er motstandsdyktige og kontinuerlig tilgjengelige?

Vi bruker det samme settet med konstruksjonsprinsipper for alle typer tjenester for å oppnå motstandsdyktighet og tilgjengelighet, ettersom de grunnleggende konstruksjonsutfordringene ved å bygge feiltolerante, skalerbare, distribuerte systemer er de samme for alle typer tjenester.

Hvis vi skal oppnå motstandsdyktighet og kontinuerlig tilgjengelighet, må vi forstå og deretter takle alle årsakene til utilgjengelighet i systemer i skyskalaen, for eksempel redusert ytelse og ubehandlede feil. Det finnes svært mange slike årsaker, så vi grupperer dem i kategorier i henhold til grunnleggende art.

Analyse av tilgjengeligheten til IT-systemer i foretak har tradisjonelt fokusert på kategorien maskinvarefeil. For skysystemer er imidlertid maskinvarefeil et ganske lite og godt forstått problem. Det er nå ganske enkelt å unngå eller redusere de fleste punktene for maskinvarefeil. Kabinetter kan for eksempel ha dobbel strømmatinger og tilknyttede strømdistribusjonsenheter, og mange komponenter kan enkelt byttes ut. Maskinvarefeil og tap i stor skala er selvsagt mulig, for eksempel på grunn av naturkatastrofer. Erfaringen vår og rapporter i offentlige gjennomganger fra andre skyleverandører viser imidlertid at feil eller tap i et helt datasenter forekommer ekstremt sjelden i forhold til andre årsaker til utilgjengelighet. Maskinvarefeil i stor skala må likevel håndteres (for eksempel med nødgjenoppretting og andre mekanismer), men det er langt fra det største tilgjengelighetsproblemet.

De dominerende årsakene til utilgjengelighet i systemer i skyskalaen er følgende:

  1. Programvarefeil
  2. Konfigurasjonsfeil
  3. Menneskelige feil
    Merknad: Den viktigste lærdommen fra bransjen er at disse tre formene for menneskelige feil er de desidert vanligste årsakene til utilgjengelighet. Selv om frekvensen kan reduseres med verktøy, automatisering og opplæring, kan de ikke fjernes. De må derfor takles som primære bekymringer ved arkitekturen, utformingen og implementeringen av systemet.
  4. Uakseptabelt avvik i ytelse (ventetid eller gjennomstrømming) av hvilken som helst årsak, inkludert følgende:
    • Flere leiere med "støyende naboer" (feil i QoS-mekanismer)
    • Ikke mulig å avvise overbelastning (utilsiktet eller ondsinnet) på en effektiv måte samtidig som nyttig arbeid utføres
    • Distribuerte ødeleggelser, store mengder meldinger, store mengder nye forsøk og andre dyre nødsamhandlinger
    • Kuldesjokk (tomme hurtigbufre) etter at strømmen slås av og på igjen, spesielt når dette skjer samtidig i flere systemer
    • Kostnader ved skalering av systemet (for eksempel ny fragmentering)
  5. Mislykket begrensning av nedslagsfeltet (antallet påvirkede kunder og systemer) for problemene ovenfor

Disse utfordringene er universelle. De er en del av de fysiske lovene for distribuerte systemer i skyskalaen.

Vi bruker anerkjente konstruksjonsstrategier til å takle problemet for hver av kategoriene ovenfor. De viktigste av disse er følgende:

  • Prinsipper for arkitektur og systemutforming
  • Nye arkitektoniske begreper (som vanligvis oppstår ved bruk av prinsippene)
  • Prosedyrer for tjenestekonstruksjon
Prinsipper for arkitektur og systemutforming

Det finnes mange slike prinsipper, men vi skal fokusere på prinsippene som er mest relevante for motstandsdyktighet og tilgjengelighet.

Databehandling med fokus på gjenoppretting

Vi følger prinsippene om databehandling med fokus på gjenoppretting for å håndtere programvarefeil og operatørfeil som har relativt lokal innvirkning1. På høyt nivå betyr dette at vi fokuserer på å håndtere alle problemer diskret, på en måte som kan testes, i stedet for å garantere at vi aldri har noe problem (noe som er umulig å teste). Vi fokuserer spesielt på å redusere gjennomsnittstiden for gjenoppretting (MTTR), som er en kombinasjon av gjennomsnittstiden for å oppdage, gjennomsnittstiden for å diagnostiere og gjennomsnittstiden for å redusere.

Målet vårt er å gjenopprette så raskt at menneskelige brukere ikke forstyrres av problemet. Disse punktene hjelper oss å nå dette målet:

  • Rask og automatisk oppdagelse av symptomene på programfeil og operatørfeil, med gjennomgripende bruk av deklarasjoner i koder samt aktiv overvåking og alarmering på alle nivåer.
  • Pakkefunksjoner i mange separate finjusterte isolasjonsenheter (tråder, prosesser, fibre, tilstandsmaskiner og så videre) som er løst koblet. Det vil si at de ikke direkte deler minne som kan bli skadet.
  • Hvis symptomer på programfeil eller operatørfeil blir oppdaget, startes den omsluttende isolasjonsenheten automatisk på nytt så raskt som mulig. Omstart er en praktisk måte å prøve å gjenopprette fra en tilfeldig feil på, ettersom det forsøker å gjenopprette en tilstand som er godt testet, og dermed gjenoppretter konstanter.
  • Hvis gjenoppretting på det finjusterte isolasjonsnivået ikke fungerer (for eksempel hvis deklarasjoner fortsatt utløses for ofte på nivået, noe som fører til stadige krasj), eskaleres det til neste større enhet (prosess, kjøretid, vert, logisk datasenter, tilkalling av menneskelig operatør).
  • Byggemekanismer aktiverer en systemomfattende angrefunksjon, inkludert versjonskontroll av alle vedvarende tilstander og konfigurasjoner, slik at ugyldige lagringer raskt kan identifiseres og angres.

Minimere innvirkningen av problemer

Vi bygger mekanismer som minimerer nedslagsfeltet til alle problemer, for å takle programfeil og andre feil som kan ha bred innvirkning. Det vil si at vi fokuserer på å minimere antallet kunder, systemer eller ressurser som påvirkes av et problem, inkludert svært utfordrende problemer med flere leiere med "støyende naboer", overbelastning, redusert kapasitet og distribuerte ødeleggelser. Vi oppnår dette ved å bruke ulike isolasjonsgrenser og fremgangsmåter for endringsstyring (se delene nedenfor).

Arkitektoniske begreper som oppstår fra utformingsprinsipper

Det finnes mange slike begreper, men vi skal fokusere på begreper for begrensning av nedslagsfeltet.

Plasseringsbegreper nedfelt i vårt offentlige API: regioner, tilgjengelighetsdomener og feildomener

Ettersom feildomener er relativt nytt, skal vi beskrive dette mer detaljert.

Feildomener brukes til å begrense nedslagsfeltet for problemer som oppstår når et system blir aktivt endret, for eksempel implementeringer, oppdatering, omstarter av hypervisoren og fysisk vedlikehold.

Garantien er at i et gitt tilgjengelighetsdomene blir ressurser i minst ett feildomene endret på ethvert tidspunkt. Hvis noe går galt med endringsprosessen, kan det hende at noen av eller alle ressursene i feildomenet er utilgjengelige en stund, med de andre feildomenene i tilgjengelighetsdomenet påvirkes ikke. Hvert tilgjengelighetsdomene inneholder minst tre feildomener, slik at det er mulig at kvorumbaserte replikeringssystemer (for eksempel Oracle Data Guard) har vertskap med høy tilgjengelighet i ett tilgjengelighetsdomene.

For en dominerende kategori med tilgjengelighetsproblemer, for eksempel programvarefeil, konfigurasjonsfeil, operatørfeil og ytelsesproblemer som oppstår under en endringsprosedyre, er resultatet at hvert enkelt feildomene fungerer som et separat logisk datasenter i et tilgjengelighetsdomene.

Feildomener beskytter også mot enkelte typer feil i lokal maskinvare. Egenskapene til feildomener garanterer at ressurser som er plassert i ulike feildomener, ikke deler noen potensielle enkeltpunkt for maskinvarefeil i tilgjengelighetsdomenet, så langt det overhodet er praktisk mulig. Ressurser i ulike feildomener deler for eksempel ikke samme nettverksbryter øverst i kabinettet, ettersom standardutformingen av slike brytere ikke har redundans.

Muligheten til at feildomener beskytter mot problemer i maskinvare eller i det fysiske miljøet stopper imidlertid på dette lokale nivået. I motsetning til tilgjengelighetsdomener og regioner, gir ikke feildomener fysisk isolasjon av infrastruktur i stor skala. I sjeldne tilfeller med naturkatastrofer eller infrastrukturfeil i hele tilgjengelighetsdomenet vil ressurser i flere feildomener sannsynligvis bli påvirket samtidig.

Våre interne tjenester bruker feildomener på samme måte som kundene bør bruke dem. Tjenestene Block Volumes, Object Storage og File Storage lagrer for eksempel replikaer av data i tre separate feildomener. Alle komponenter i alle kontrollplan og dataplan har vertskap i alle de tre feildomenene (eller i flere tilgjengelighetsdomener, hvis det er snakk om en region med flere tilgjengelighetsdomener).

Tjenesteceller

Tjenesteceller brukes til å begrense nedslagsfeltet for problemer som oppstår selv når et system ikke blir aktivt endret. Slike problemer kan oppstå fordi arbeidsmengden i et skysystem med flere leiere kan endres ekstremt når som helst, og fordi komplekse delvise feil når som helst kan forekomme i alle store distribuerte systemer. Disse scenarioene kan utløse subtile skjulte feil eller nye ytelsesproblemer.

I tillegg begrenser tjenesteceller også nedslagsfeltet i noen sjeldne, men utfordrende scenarioer der systemet blir aktivt endret. Et klassisk eksempel er når implementering til et individuelt feildomene synes å være vellykket, uten feil eller endringer i ytelsen. Men så snart det andre eller siste feildomenet er oppdatert, fører nye samhandlinger i systemet (i full skala med produksjonsarbeidsmengde) til et ytelsesproblem.

Merk at bruk av tjenesteceller er et arkitektonisk mønster, og ikke et konsept som er eksplisitt navngitt i API-et eller SDK-en for Oracle Cloud. Alle systemer med flere leiere kan bruke dette arkitektoniske mønsteret. Det krever ikke spesialstøtte fra skyplattformen.

Tjenesteceller fungerer på følgende måte:

  • Hver enkelt forekomst av tjenesten (for eksempel i en bestemt region, eller i et bestemt tilgjengelighetsdomene for lokale tjenester i tilgjengelighetsdomener) består av flere separate implementeringer av tjenestens programvarestakk. Hver enkelt separate implementering kalles en celle. Hver enkelt celle har vertskap i sin egen infrastruktur i så stor grad som praktisk mulig. Et minimumskrav er at celler ikke deler verter eller virtuelle maskiner.
  • En tjeneste kan starte med en håndfull celler i hvert tilgjengelighetsdomene eller hver region. Etter hvert som tjenesten skaleres for å dekke økende behov, blir flere celler lagt til for å opprettholde grensen for størrelse på nedslagsfelt ved problemer. En stor, populær tjeneste kan ha mange celler. Celler gir med andre ord n-til-m-multipleksing av kundenes arbeidsmengder til separate vertsmiljøer, som er separate øyer med ressursisolasjon. Celler har ingen tydelig kardinalitet, slik feildomener har. (Som nevnt tidligere er et åpenbart valg for kardinalitet for feildomener tre per tilgjengelighetsdomene, slik at kvorumbaserte replikeringssystemer kan ha vertskap med høy tilgjengelighet i ett tilgjengelighetsdomene.)
  • Hver enkelt "naturlige enhet" i en kundearbeidsmengde tilordnes til en bestemt celle. Definisjonen av "naturlig enhet" avhenger av den bestemte tjenestens natur. For vår interne tjeneste med delt arbeidsflyt (beskrevet senere) kan den naturlige enheten for eksempel være "alle arbeidsflyter i dette tilgjengelighetsdomenet eller denne regionen for et bestemt kontrollplan".
  • Foran hver gruppe med celler ligger enten et minimalistisk distribusjonslag eller et API for oppdagelse av cellesluttpunkter. Streaming/Messaging-systemet har for eksempel et API for oppdagelse av gjeldende dataplansluttpunkt for et bestemt emne, og det interne metadatalageret har et separat sluttpunkt per celle. Andre cellebaserte tjenester har imidlertid ett dataplansluttpunkt og et delt distribusjonslag. Distribusjonslaget er en potensiell årsak til korrelerte feil i flere celler, men dette kan begrenses ved å holde distribusjonslaget svært enkelt, forutsigbart og med høy ytelse (ingen dyre operasjoner) og klargjøre det med mye kapasitet for utvidelse og avanserte mekanismer for QoS-kvote og regulering.
  • Tjenesteeiere kan ved behov flytte en arbeidsmengde fra én celle til en annen. Her er noen eksempler på scenarioer:
    • For å unngå problemet med "støyende nabo" i forbindelse med flere leiere ved å flytte en stor arbeidsmengde slik at ikke andre brukere av en celle blir påvirket.
    • For å gjenopprette fra en overbelastning eller reduksjon i strømforsyningen som kanskje skyldes et angrep med distribuert tjenestenekt. Vi har mekanismer for kvoter og regulering som forsvarer mot slike angrep, men noen ganger forekommer det kanttilfeller der et bestemt brukstilfelle (API, tilgangsmønster) er mer krevende for tjenesten enn systemet for kvoter eller regulering for øyeblikket forstår. Celler gir en mekanisme for kortsiktig forebygging.
    • For å skille viktige arbeidsmengder i ulike celler, noe som reduserer sannsynligheten for korrelert feil betydelig. For vår interne delte arbeidsflyt for kontrollplan blir for eksempel kontrollplanene for den "kritiske kjernen" (for eksempel Platform, Compute, Networking og Block Volumes) tilordnet til ulike celler og opplever dermed betydelig færre korreleringsfeil enn hvis ikke celler hadde vært i bruk, eller hvis de hadde vært tilordnet til samme celle.
      Merknad: Denne bruken av celler reduserer behovet for at kunder må vurdere de interne avhengighetene mellom tjenester når de skal bygge motstandsdyktige applikasjoner. Det er fortsatt anbefalt å vurdere avhengighetsdiagrammet (mer om det senere i dokumentet), men det er mindre behov for det når det allerede finnes en aktiv dekorrelasjonsmekanisme.

Resultatet er at hver enkelt tjenestecelle er enda en type "logisk datasenter", altså en logisk gruppering av ytelsesisolasjon og feilisolasjon, innenfor ett tilgjengelighetsdomene eller én region.

Kort sagt utfyller tjenesteceller og feildomener hverandre på følgende måter:

  • Feildomener beskytter mot problemer når et system blir aktivt endret.
  • Tjenesteceller begrenser nedslagsfeltet når et system opplever potensielt alvorlige problemer, uansett om det blir aktivt endret eller ikke.

Vi kombinerer egenskapene til feildomener og tjenesteceller i en helhetlig strategi når vi utfører implementeringer og oppdatering.

Prosedyrer for tjenestekonstruksjon

Ettersom både testing og utmerket drift er viktig for et pålitelig skysystem, har vi mange konstruksjonsprosedyrer. Her følger noen av de viktigste, som bruker konseptene som ble nevnt i delen ovenfor:

  • Vi implementerer tjenester trinnvis, med nøye validering mellom trinnene og refleksiv tilbakestilling hvis det skjer noe overraskende. Konkret sagt er prosessen som følger:
    • Vi implementerer til én tjenestecelle om gangen i hvert enkelt tilgjengelighetsdomene. Vi implementerer til ett feildomene om gangen for hver celle til vi har fullført alle feildomener for den aktuelle cellen. Deretter fortsetter vi til neste celle i tilgjengelighetsdomenet.
    • Etter hvert enkelt trinn i implementeringen (etter hvert feildomene og hver celle) validerer vi at endringen fungerer som den skal, altså at ytelsen ikke har gått ned og at feil ikke er innført, verken internt eller eksternt. Hvis noe ser ut til å være galt eller uventet, tilbakestiller vi endringen refleksivt. Vi legger stor vekt på klargjøring og testing av tilbakestillingsprosedyrer, inkludert automatiske tester. Dette gjelder også endringer som påvirker vedvarende tilstand eller skjemaer.
    • På denne måten implementerer vi endringen i ett tilgjengelighetsdomene om gangen til hver enkelt region. Vi implementerer til alle regionene i et område på en måte som gjør at vi ikke samtidig endrer regionpar som en kunde kanskje bruker som primært område eller nødgjenopprettingsområde.
  • Vi verifiserer jevnlig at feilhåndteringsmekanismer og annen forebygging fungerer som forventet og ikke gjør problemet stadig verre. Uten slik testing er det vanlig at feilhåndteringsmekanismer (for eksempel nye forsøk, algoritmer for gjenoppretting etter krasj og algoritmer for ny maskinkonfigurasjon for tilstand) har feil, er for dyre eller samhandler på overraskende måter, slik at de fører til distribuerte ødeleggelser eller andre alvorlige ytelsesproblemer.
  • Vi verifiserer muligheten for rask og sikker tilbakestilling til den sist kjente gode programvaren og konfigurasjonen, inkludert vedvarende tilstand og skjema, som tidligere beskrevet.
 
 

Blir alle viktige tjenester distribuert til alle tilgjengelighetsdomener i Oracle-regioner med flere tilgjengelighetsdomener?

Ja. Alle tilgjengelighetsdomener i hver enkelt region tilbyr samme tjenestesett.

 
 

Hvordan unngår Oracle og Oracles kunder at en viktig tjeneste er avhengig av ett logisk datasenter?

I regioner med ett tilgjengelighetsdomene kan kundene bruke feildomener (logiske grupper med dekorrelasjonsfeilmodi mellom grupper) til å oppnå de fleste egenskapene fra separate "logiske datasentre". Kundene kan også bruke flere regioner til nødgjenoppretting.

I regioner med flere tilgjengelighetsdomener kan feildomener brukes på samme måte. Kundene kan også bruke en kombinasjon av lokale tjenester i tilgjengelighetsdomener, funksjoner for failover mellom tilgjengelighetsdomenes (for eksempel DBaaS med Data Guard) og regionale tjenester (Object Storage, Streaming) til å oppnå full tilgjengelighet på tvers av "logiske datasentre" på høyere nivå (tilgjengelighetsdomener). I tillegg kan kundene også bruke flere regioner til nødgjenoppretting.

I alle tilfellene kan kundene bruke konseptet med tjenesteceller til å isolere selv de mest alvorlige problemene ytterligere, for eksempel distribuerte ødeleggelser.

 
 

Hvordan gjennomfører Oracle vedlikeholdsaktiviteter uten at viktige tjenester midlertidig blir utilgjengelige for kundene?

Vi oppnår dette via feildomener, tjenesteceller og våre driftsprosedyrer for trinnvis implementering og validering. Se drøftingen tidligere i dette dokumentet.

 
 

Implementeres plattformtjenester uten tjener på tvers av flere logiske datasentre for større tilgjengelighet?

Ja. Alle tjenestekategorier implementeres på tvers av flere logiske datasentre, som er separate logiske grupperinger for feilisolasjon og ytelsesisolasjon. Dette gir motstandsdyktighet og kontinuerlig tilgjengelighet.

 
 

Får kundene velge med en implementering i flere logiske datasentre (for eksempel en konfigurasjon med flere tilgjengelighetsdomener eller på tvers av regioner) hvis motstandsdyktighet ikke er standardkonfigurasjonen?

I regioner med ett tilgjengelighetsdomene tilbyr vi feildomener som mekanisme for "flere logiske datasentre", som drøftet tidligere i dette dokumentet.

I regioner med flere tilgjengelighetsdomener tilbyr vi tjenester og funksjoner som gir et enda høyere nivå med fysisk varighet for synkront replikerte data (med beskjeden ytelse, kostnad på grunn av avstanden mellom tilgjengelighetsdomener i regionen og lysets hastighet).

Vi tilbyr ikke automatisk høy tilgjengelighet eller failover-mekanismer på tvers av regioner, ettersom dette ville opprette en relasjon mellom regioner med tett tilkobling, noe som gir risiko for at flere regioner opplever problemer samtidig. Vi gir i stedet mulighet til flere typer asynkron replikering mellom regioner og tilbyr stadig flere funksjoner, for eksempel asynkron kopiering og sikkerhetskopiering for nødgjenoppretting på tvers av regioner.

 
 

Hvordan hjelper Oracle kundene med å unngå korrelerte feil i applikasjoner som skyldes interne avhengigheter mellom ulike infrastruktur- og plattformtjenester?

Dette er et komplisert spørsmål, så vi tydeliggjør dette ved å si det på nytt på noen ulike måter:

  • Hvis en kunde vil bruke to Oracle-tjenester (tjeneste A og tjeneste B) og vil bygge en applikasjon som er motstandsdyktig hvis de andre tjenestene feiler, må kunden da vite om tjeneste A er internt avhengig av tjeneste B? Fører intern avhengighet til korrelert feil av betydelig grad? I så fall må kunden kanskje vite om slike interne avhengigheter for å kunne beslutte hva tjeneste A og tjeneste B ellers skal brukes til, eller om det i stedet skal hentes inn en urelatert tjeneste C til disse tilleggstilfellene, når egne mekanismer for motstandsdyktighet bygges på applikasjonsnivå.
  • Hvordan forsvarer kunden seg best mulig mot eventuelle korrelerte feil i Oracle-tjenester?

Svaret er todelt.

Arkitektoniske prinsipper

Vi bruker arkitektoniske prinsipper som reduserer korrelerte feil betydelig på tvers av avhengige tjenester. I noen tilfelle reduserer denne teknikken sannsynligheten for korrelerte feil til en grad som kan ignoreres med tanke på å oppfylle en servicenivåavtale (SLA) om tilgjengelighet.

Vi bruker spesielt tjenesteceller, som beskrevet tidligere i dette dokumentet. Celler hjelper med dette problemet fordi hvis den interne tjenesten A blir påvirket av et problem i én av avhengighetene, tjeneste B, så er problemet med tjeneste B svært sannsynlig begrenset til én celle. Andre tjenester på høyere nivå, og kundens egne applikasjoner, som bruker tjeneste B, bruker sannsynligvis andre celler som ikke er påvirket. Dette er et sannsynlighetsargument som varierer etter antall celler, som er en skjult intern parameter som ikke endres (øker). Det er dermed ingen mengdeangivelse eller gitt garanti utover de frittstående servicenivåavtalene for tjeneste A og B. Men i praksis kan dette dekorrelere feil mellom tjenester betydelig.

Mange av våre delte interne tjenester, for eksempel tjenestene Workflow og Metadata for kontrollplan samt tjenesten Streaming/Messaging, bruker tjenesteceller til å dekorrelere avbrudd for oppstrømstjenestene som bruker dem.

Avhengigheter

Veiledningen nedenfor er for høyt nivå, ettersom implementering på lavt nivå og detaljer om tjenester kan og vil endre seg. For nøkkeldimensjonene maskin, lagring, nettverk og godkjenning/autorisasjon angir vi imidlertid avhengighetene nedenfor.

For kontrollplan er dette de vanlige avhengighetene:

  1. Dataplanet Identity/Platform for godkjenning og autorisasjon
  2. Revisjonssporingstjenesten
  3. Interne tjenester som for eksempel tilbyr arbeidsflyt, metadatalagring og logging
  4. Belastningsfordeling av ulike typer

Enkelte kontrollplan har selvsagt tjenestespesifikke avhengigheter. Når kontrollplanet Compute starter en OS-fri forekomst eller VM-forekomst, er det for eksempel avhengig av følgende:

  • Object Storage (for henting av den angitte operativsystemavbildningen)
  • Kontrollplanet Block Volumes (for klargjøring og tilknytning av oppstartsvolumet)
  • Kontrollplanet Networking (for klargjøring og tilknytning av VNIC-er)

For dataplan for kjernetjenester er hovedprinsippet at hvert enkelt dataplan med hensikt er utformet med så få avhengigheter som mulig, slik at det er mulig å oppnå høy tilgjengelighet, kort diagnostiseringstid og kort gjenopprettingstid. Resultatene av dette prinsippet er som følger:

  • Dataplanet Networking er selvstendig.
  • Dataplanet Block Volumes er selvstendig.
  • OS-frie forekomster og VM-forekomster av Compute er avhengig av dataplanet Block Volumes (for oppstartsvolumer) og dataplanet Networking.
  • Dataplanet Object Storage er avhengig av dataplanet Identity/Platform for godkjenning og autorisasjon (på grunn av bransjeforventninger). Dataplanet Object Storage er ikke avhengig av Block Volumes eller File Storage.
  • Alle tjenester som støtter sikkerhetskopiering og gjenoppretting, er avhengig av dataplanet Object Storage for denne funksjonen.

For IaaS-dataplan er hovedprinsippet avhengighet bare av kjernedataplan eller dataplan på lavere nivå (for å unngå sirkelavhengigheter).

  • Database-RAC med flere knutepunkt er avhengig av dataplanet Networking og dataplanet Block Volumes.
  • Container Engine for Kubernetes er selvsagt avhengig av Kubernetes og dennes transitive avhengigheter (for eksempel etcd) og dataplanet Networking.
  • Alle tjenester for sikkerhetskopiering og gjenoppretting er avhengige av dataplanet Object Storage.

1Et offentlig forskningsprogram fra Stanford og Berkeley, ledet av Armando Fox og Dave Patterson

 
×
Ring oss nå
1-800-633-0738 (De forente stater)

Kontakt
×
Ring oss nå
1-800-633-0738 (De forente stater)


Oracle Cloud-diskusjonsfora