Vastuuvapautuslauseke

Seuraavassa on yleisiä tietoja tuotteistamme. Ne on tarkoitettu vain tiedoksi, eikä niitä voi sisällyttää sopimuksiin. Tiedot eivät ole sitoumus toimittaa materiaalia, koodia tai toiminnallisuutta, eikä niiden nojalla tulisi tehdä ostopäätöksiä. Kuvattujen Oraclen tuotteiden ominaisuuksien ja toimintojen kehitys, ajoitus ja hinnoittelu voivat muuttua ja ovat yksinomaisesti Oraclen päätettävissä.

Tässä asiakirjassa on vastauksia usein kysyttyihin kysymyksiin siitä, miten Oracle toteuttaa tärkeimpien infrastruktuuripalvelujensa ja isännöintialustansa vikasietoisuuden ja jatkuvan käytettävyyden. Oracle Cloud -asiakkaat voivat olla kiinnostuneita näistä vastauksista useista syistä:

  • Ne auttavat asiakkaita arviomaan Oraclen isännöintialustaa ja palveluja huolellisesti.
  • Monissa vastauksissa käsitellään haasteita ja ratkaisuja, jotka ovat erittäin tärkeitä kaikkien pilvitason järjestelmien kannalta ja voivat näin auttaa pilvialustaan kehitettävien järjestelmien arkkitehtuurin ja rakenteen suunnittelussa.

Oracle Cloud Infrastructure -palvelujen ja -ympäristön vikasietoisuus ja jatkuva käytettävyys – usein kysytyt kysymykset

Erotteleeko Oracle toisistaan erilaiset palvelut, kuten tärkeät palvelut, jatkuvasti käytettävissä olevat palvelut tai yhden sijainnin palvelut?

Emme tee tällaisia erotteluja. Sen sijaan luokittelemme palvelumme riippuvuustason ja käytettävyysalueen mukaan sekä sen mukaan, toimitaanko niissä tietotasolla vai ohjaustasolla. Näiden luokkien tarkoituksena on antaa mahdollisuus luoda erilaisia hyödyllisiä käytettävyys-, kestävyys-, suorituskyky- ja kätevyysyhdistelmiä.

Riippuvuustasot

Näitä tasoja voidaan ajatella arkkitehtuurilohkokaavion kerroksina tai tasoina. Kukin taso on riippuvainen vain alapuolella olevista tasoista.

Alhaalta ylös:

  • Ydinpalvelut: Nämä palvelut muodostavat Oracle Cloud Infrastructure -ympäristön perustan. Ne käsittävät Identity and Access Management (IAM)-, Key Management-, Networking-, Compute-, Block Volumes-, Object Storage- ja Telemetry-palvelut sekä useita jaettuja sisäisiä palveluja. Ne on suunniteltu niin, että niillä on mahdollisimman vähän riippuvuuksia keskenään ja muiden tasojen kanssa. (Tietoja riippuvuuksista on jäljempänä tässä asiakirjassa.)
  • IaaS: Tämä taso tarjoaa lisää ydintason palvelujen varaan kehitettyjä infrastruktuuritoimintoja. Tämän tason palveluita ovat muun muassa File Storage, Database ja Container Engine for Kubernetes.
  • SaaS: Tämä taso on monipuolinen palveluna tarjottava ohjelmisto, joka on rakennettu alempien tasojen varaan.
Käytettävyysalue

Jotta palvelun käytettävyys- ja kestävyystavoitteet voidaan täyttää, kullekin palvelulle valitaan jokin seuraavista käytettävyysalueista:

  • Saatavuusalueen paikallinen palvelu: Kukin saatavuusalue sisältää yhden riippumattoman palveluinstanssin. Tällaiset palvelut mahdollistavat tallennettujen tietojen erittäin hyvän kestävyyden käyttämällä synkronista replikointia saman saatavuusalueen replikoiden välillä (lisätietoja on jäljempänä tässä asiakirjassa olevassa vika-alueita käsittelevässä osassa). Nämä palvelut kestävät vähintään infrastruktuurin kolmasosan laajuiset käyttökatkot saatavuusalueella. Saatavuusalueen paikalliset palvelut saavuttavat tämän vikasietoisuustason käyttämällä saatavuusalueen sisällä kahdentyyppisiä loogisia palvelinkeskuksia eli vikojen ja suorituskyvyn suhteen eristettyjä loogisia ryhmiä. Lisätietoja on vika-alueita ja palvelusoluja käsittelevissä osissa jäljempänä tässä asiakirjassa. Nämä palvelut voivat jatkaa toimintaansa tavalliseen tapaan silloinkin, jos saatavuusalue ei voi olla yhteydessä muihin saatavuusalueisiin. Ne siis pysyvät toiminnassa, vaikka muut saatavuusalueet vikaantuisivat tai alueen suuralueverkossa tapahtuisi mittava häiriö.
  • Useiden saatavuusalueiden alueellinen palvelu: Kukin useita saatavuusalueita käsittävä alue sisältää yhden itsenäisen palveluinstanssin, jonka osia sijaitsee kullakin alueen saatavuusalueella. Nämä palvelut mahdollistavat tallennettujen tietojen erittäin hyvän kestävyyden replikoimalla tiedot synkronisesti useille saman alueen saatavuusalueille. Palvelut kestävät minkä tahansa alueella olevan yksittäisen saatavuusalueen käyttökatkoksen tai yhteyshäiriön.
  • Yhden saatavuusalueen alueellinen palvelu: Jos alue käsittää vain yhden saatavuusalueen, alueellisen palvelun havaittavissa olevat ominaisuudet ovat samat kuin edellä kuvatulla saatavuusalueen paikallisella palvelulla. Saatavuusalueen paikallisen palvelun ja yhden saatavuusalueen alueellisen palvelun välinen ero on merkitsevä vasta, kun yhden saatavuusalueen aluetta laajennetaan lisäämällä siihen uusia saatavuusalueita. Tällaisessa tilanteessa kukin alueellinen palvelu laajentuu automaattisesti käyttämään uusia saatavuusalueita pysyen kuitenkin samalla yhtenä palveluinstanssina. Esimerkiksi Object Storage -tietotaso laajenee käyttämään uusia saatavuusalueita parantaakseen tallennettujen tietojen kestävyyttä. Saatavuusalueen paikallisten palvelujen tapauksessa puolestaan jokainen uusi saatavuusalue saa oman, erillisen instanssin kustakin saatavuusalueen paikallisesta palvelusta.
  • Useille alueille hajautettu palvelu: Oracle Cloud Infrastructure -ympäristön periaate on, että kukin alue on mahdollisuuksien mukaan toiminnallisesti riippumaton muista alueista. Mahdollisuuksien mukaan tarkoittaa, että alueet jakavat väistämättä ainakin osan infrastruktuurista, kuten alueen sisäisen runkoverkon. Emme kuitenkaan rakenna alueiden välisiä yhteysmekanismeja, kuten läpinäkyvää korkeaa käytettävyyttä tai vikasietoisuutta, jotka voisivat aiheuttaa useisiin alueisiin samanaikaisesti vaikuttavia ongelmia. Tarjoamme sen sijaan kaksi löyhiä yhteyksiä käyttävää menetelmää palvelujen jakeluun alueilla:
    • Järjestelmäpalautus: Asiakkaillemme annettava mahdollisuus rakentaa järjestelmäpalautusominaisuuksia sisältäviä järjestelmiä on pilvipalvelujemme kulmakivi. Useat ydinpalvelut tarjoavat jo järjestelmäpalautustoimintoja. Esimerkiksi Block Volumes käyttää alueiden välistä varmuuskopiointia ja Object Storage alueiden välistä kopiointia. Järjestelmäpalautustoiminnot ovat korkeassa prioriteettiasemassa kaikkien palvelujemme suunnitelmissa.
    • Alueiden väliset tilaukset: Tarjoamme alueiden välisiä tilauksia toistaiseksi vain IAM-tiedoille. Käsitteellisesti IAM-tiedot ovat maailmanlaajuisia. Asiakkaat voivat tilata joukon alueita, ja replikoimme asianmukaiset IAM-tiedot ja myöhemmät päivitykset määritetyille alueille automaattisesti. Jotta vältetään liian tiiviit yhteydet, replikointi tehdään asynkronisesti niin, että lopuksi saavutetaan tietojen yhdenmukaisuus. Asiakkaat tekevät IAM-tietoihinsa muokkauksia nimeämällään kotialueella. Jos nykyinen kotialue ei jostain syystä ole käytettävissä tai muuten sovellu tarkoitukseen, voidaan nimetä jokin muu alue.
Ohjaustaso vs. tietotaso

Palvelun tietotaso on joukko tietojenkäsittelyliityntöjä ja -osia, jotka toteuttavat sovellusten käyttöön tarkoitetut palvelun toiminnot. Esimerkiksi virtuaalisen pilviverkon (VCN) tietotaso sisältää verkkopakettien käsittelyjärjestelmän, virtualisoidut reitittimet sekä yhdyskäytävät, kun taas Block Volumes -tietotaso sisältää iSCSI-protokollan toteutuksen sekä vikasietoisen, replikoidun tallennusjärjestelmän suurille datamäärille.

Palvelun ohjaustaso on joukko API-rajapintoja ja osia, jotka vastaavat seuraavista tehtävistä:

  • resurssien käyttöönottoa, uudelleenmääritystä, skaalausta ja lopetusta käsittelevien asiakaspyyntöjen käsittely
  • suurien ohjelmamäärien automaattiset korjaukset nopeasti ja turvallisesti
  • vikaantuneiden, heikentyneiden tai virheellisesti määritettyjen resurssien havaitseminen
  • automaattiset korjaukset tai käyttäjien kutsuminen apuun
  • yhteistyö muiden ohjaustasojen kanssa (esimerkiksi Compute, VCN ja Block Storage yhdistetään palveluun LaunchInstance-kutsun yhteydessä)
  • käyttämättömän kapasiteetin hallinta
  • koordinointi ihmisten kanssa esimerkiksi uusien laitteiden saapuessa tai fyysisten korjaus- ja huoltotoimien aikana
  • toimintojen näkyvyys ja hallinta.
 
 

Miten Oracle varmistaa, että palvelut ovat vikasietoisia ja jatkuvasti käytettävissä?

Käytämme kaikentyyppisissä palveluissa samoja suunnitteluperiaatteita saavuttaaksemme hyvän vikasietoisuuden ja käytettävyyden, sillä vikasietoisten, skaalattavien ja hajautettujen järjestelmien kehitykseen liittyvät perushaasteet ovat samat kaikentyyppisille palveluille.

Vikasietoisuus ja jatkuva käytettävyys edellyttävät kaikkien käytettävyyden heikkenemisen (suorituskyvyn heikkenemisen ja käsittelemättömien vikojen) syiden ymmärtämistä ja käsittelyä pilvitason järjestelmissä. Tällaisia syitä on useita, joten ryhmittelemme ne luokkiin niiden perusluonteen mukaisesti.

Yrityksen IT-järjestelmien käytettävyysanalyysi on perinteisesti keskittynyt laitteistovikoihin. Pilvijärjestelmissä laitteistovika on kuitenkin melko pieni ja hyvin ymmärretty ongelma. Useimpien yksittäisten laitevikapisteiden välttäminen ja vikojen korjaaminen on melko helppoa. Esimerkiksi telineissä voi olla kaksi virransyöttöyksikköä ja niihin liittyvät virranjakelulaitteet, ja monet osat voidaan vaihtaa käytön aikana. Laaja-alaiset laitteistoviat ja menetykset ovat tietenkin edelleen mahdollisia, esimerkiksi luonnonkatastrofien tapauksessa. Kokemuksemme perusteella (ja muiden pilvipalvelujen tarjoajien julkisten ongelmanratkaisuraporttien mukaan) kokonaisen palvelinkeskuksen häiriö tai menetys on erittäin harvinaista muihin käyttökatkosten syihin verrattuna. Laaja-alainen laitteistovika täytyy silti käsitellä (esimerkiksi järjestelmäpalautuksen tai muun mekanismin avulla), mutta se ei suinkaan ole suurin käytettävyysongelma.

Pilvitason järjestelmien käyttämättömyysongelmien pääsyyt ovat seuraavat:

  1. Ohjelmistoviat
  2. Määritysvirheet
  3. Käyttäjien tekemät inhimilliset virheet
    Huomautus: Yksi alalla opituista asioista on se, että nämä kolme inhimillisen erehdyksen muotoa ovat ehdottomasti suurimmat syyt käytettävyysongelmille. Vaikka niiden esiintymistiheyttä voidaan pienentää työkaluilla, automaatiolla ja koulutuksella, niitä ei voida poistaa kokonaan. Siksi niihin täytyy ehdottomasti kiinnittää huomiota järjestelmän arkkitehtuurin ja rakenteen suunnittelun ja toteutuksen aikana.
  4. Ei-hyväksytty vaihtelu suorituskyvyssä (viipeessä tai kapasiteetissa) esimerkiksi seuraavista syistä:
    • usean asiakastilin "metelöivät naapurit" (palvelun laatumekanismien vika)
    • kyvyttömyys hylätä vahingossa tai tahallaan lähetetty liikakuormitus tehokkaasti ja jatkaa samalla hyödyllistä työtä
    • ruuhkautuminen, viestimyrskyt, uudelleenyritysmyrskyt ja muut kalliit hätätoimenpiteet
    • tyhjät välimuistit virran katkaisun ja uudelleenkytkennän jälkeen, erityisesti jos tämä tehdään samaan aikaan useille järjestelmille
    • järjestelmän skaalauksen aiheuttamat yleiskustannukset (esimerkiksi uudelleensirpalointi).
  5. Jonkin edellä mainitun ongelman vaikutuspiirissä olevien asiakkaiden ja järjestelmien koon rajoittaminen

Nämä haasteet ovat samat kaikille hajautetuille pilvijärjestelmille.

Ratkaisemme ongelman kussakin edellä mainitussa luokassa käyttämällä hyväksi havaittuja suunnittelustrategioita. Tärkeimpiä näistä ovat:

  • arkkitehtuuri- ja järjestelmäsuunnittelun periaatteet
  • uudet arkkitehtuurikonseptit (jotka tyypillisesti syntyvät periaatteiden käytöstä)
  • palvelusuunnittelun toimintatavat.
Arkkitehtuuri- ja järjestelmäsuunnittelun periaatteet

Tällaisia periaatteita on useita, mutta keskitymme niihin, jotka ovat merkityksellisimpiä vikasietoisuuden ja käytettävyyden kannalta.

Palautukseen tähtäävä tietojenkäsittely

Voidaksemme käsitellä ohjelmistovirheet ja käyttäjien virheet, joiden vaikutus on lähinnä paikallinen, noudatamme palautukseen tähtäävän tietojenkäsittelyn periaatteita1. Korkealla tasolla tämä tarkoittaa, että emme yritä taata täyttä ongelmattomuutta (mitä olisi mahdotonta testata) vaan keskitymme käsittelemään kaikki ongelmat häiriöitä aiheuttamatta tavalla, joka voidaan testata. Keskitymme erityisesti minimoimaan keskimääräisen palautusajan, joka on havaitsemisen, vianmäärityksen ja korjauksen palautusaikojen yhdistelmä.

Tavoitteenamme on palauttaa järjestelmä niin nopeasti, ettei ongelma haittaa ihmisten toimia. Seuraavat toimet auttavat meitä saavuttamaan tämän tavoitteen:

  • Virheiden ja häiriöiden oireiden nopea ja automaattinen havaitseminen käyttämällä koodiväittämiä sekä aktiivista valvontaa ja hälytyksiä kaikilla tasoilla.
  • Toimintojen pakkaus useaan erilliseen, tarkasti määritettyyn eristysyksikköön (säikeeseen, prosessiin, kuituun, tilakoneeseen ja niin edelleen), jotka yhdistetään toisiinsa löyhästi niin, että ne eivät suoraan jaa muistia.
  • Kun järjestelmä havaitsee ohjelmistovirheen tai käyttäjän virheen, sitä ympäröivä eristysyksikkö käynnistetään automaattisesti uudelleen mahdollisimman nopeasti. Uudelleenkäynnistys on käytännöllinen tapa palautua satunnaisesta häiriöstä, sillä siinä yritetään muodostaa uudelleen testattu ja toimivaksi havaittu tila, joten se palauttaa invariantteja.
  • Jos palautus tarkkaan erotellulla eristystasolla ei onnistu (jos esimerkiksi tasoon kohdistuu väittämiä liian usein), siirrytään seuraavaan suurempaan yksikköön (prosessiin, ajonaikaiseen ympäristöön, palvelimeen, loogiseen palvelinkeskukseen tai ihmiskäyttäjän kutsuun).
  • Mekanismit, jotka mahdollistavat toiminnon kumoamisen koko järjestelmän tasolla, jolloin virheelliset tallennukset voidaan tunnistaa ja kumota nopeasti. Esimerkki tällaisesta mekanismista on kaikkien pysyvien tilojen ja määritysten versionhallinta.

Ongelmien vaikutusten minimointi

Käsitelläksemme virheet, joilla saattaisi olla laaja-alaisia vaikutuksia, kehitimme mekanismeja ongelmien vaikutusalueiden minimointiin. Keskitymme minimoimaan niiden asiakkaiden, järjestelmien tai resurssien määrän, joihin ongelmat voisivat vaikuttaa. Tyypillisiä haastavia ongelmia ovat useiden asiakastilien ympäristöissä esiintyvät "metelöivät naapurit", tarjottu ylikuorma, heikentynyt kapasiteetti ja ruuhkautuminen. Käytämme vaikutuksen minimointiin erilaisia eristysrajoja ja muutoksenhallintakäytäntöjä (katso seuraavat osat).

Suunnitteluperiaatteista syntyvät arkkitehtuurikonseptit

Tällaisia konsepteja on useita, mutta keskitymme niihin, jotka rajoittavat ongelmien vaikutusaluetta.

Julkisen API-rajapinnan sijoitusperiaatteet: alueet, saatavuusalueet ja vika-alueet

Koska vika-alueet ovat melko uusia, kuvaamme niitä yksityiskohtaisemmin.

Vika-alueita käytetään rajoittamaan järjestelmän aktiivisen muutoksen yhteydessä tapahtuvien ongelmien vaikutusaluetta. Aktiivinen muutos voi olla esimerkiksi käyttöönotto, korjauspaketin käyttö, hypervisorin uudelleenkäynnistys tai fyysinen huoltotoimenpide.

Järjestely takaa sen, että resurssit, jotka ovat enintään yhdellä tietyn saatavuusalueen vika-alueella, muuttuvat tiettynä ajankohtana. Jos jotain menee vikaan muutosprosessin aikana, vika-alueen resurssit tai osa niistä eivät ehkä ole käytettävissä hetkeen, mutta ongelma ei vaikuta muihin saatavuusalueen vika-alueisiin. Kukin saatavuusalue sisältää vähintään kolme vika-aluetta, mikä mahdollistaa tehokkaiden replikointijärjestelmien (kuten Oracle Data Guard -sovelluksen) isännöinnin yhdellä saatavuusalueella ja varmistaa korkean käytettävyyden.

Kukin vika-alue toimii siis erillisenä loogisena palvelinkeskuksena saatavuusalueen sisällä tilanteissa, joissa muutosprosessin aikana ilmenee käytettävyysongelmia, kuten ohjelmistovirheitä, määritysvirheitä, käyttäjien virheitä tai suorituskykyongelmia.

Vika-alueet on myös suojattu tietyntyyppisiltä paikallisilta laitteistovioilta. Vika-alueiden ominaisuudet takaavat, että saatavuusalueen mahdolliset yksittäiset laitteistoviat eivät vaikuta eri vika-alueille sijoitettuihin resursseihin (niin pitkälti kuin tämä on käytännössä mahdollista). Eri vika-alueilla olevat resurssit eivät esimerkiksi jaa samaa ylätason verkkokytkintä, sillä tällaisten kytkimien vakiorakenne ei mahdollista vikasietoisuutta.

Vika-alueiden kyky suojata palveluja laitteiden tai fyysisen ympäristön ongelmilta päättyy kuitenkin tälle paikalliselle tasolle. Toisin kuin alueet ja saatavuusalueet, vika-alueet eivät tarjoa infrastruktuurin laajamittaista fyysistä eristystä. Mahdollinen (mutta harvinainen) luonnonmullistus tai koko saatavuusalueen laajuinen infrastruktuurivika vaikuttaisi todennäköisesti useiden vika-alueiden resursseihin samanaikaisesti.

Sisäiset palvelumme käyttävät vika-alueita samalla tavalla kuin asiakkaidenkin tulisi niitä käyttää. Esimerkiksi Block Volumes-, Object Storage- ja File Storage -palvelut tallentavat tietojen replikat kolmelle erilliselle vika-alueelle. Kaikkia kaikkien ohjaus- ja tietotasojen osia isännöidään jokaisella kolmesta vika-alueesta (usean saatavuusalueen alueella useilla saatavuusalueilla).

Palvelusolut

Palvelusoluja käytetään rajoittamaan sellaisten ongelmien vaikutusaluetta, jotka voivat ilmene silloinkin, kun järjestelmää ei muuteta aktiivisesti. Tällainen ongelma voi syntyä, koska usean asiakastilin pilvijärjestelmän työmäärä voi muuttua äärimmäisillä tavoilla milloin tahansa ja missä tahansa laajassa jakelujärjestelmässä voi milloin tahansa tapahtua monimutkaisia osittaisia häiriöitä. Tällaiset tilanteet voivat laukaista piilotettuja virheitä tai uusia suorituskykyongelmia.

Lisäksi palvelusolut rajoittavat vaikutusaluetta joissakin harvinaisissa mutta haastavissa tilanteissa, joissa järjestelmää muutetaan aktiivisesti. Yksi esimerkki tästä on tilanne, jossa käyttöönotto yksittäisellä vika-alueella näyttää onnistuneen – ei ilmene virheitä tai suorituskyvyn muutoksia – mutta heti, kun toinen tai viimeinen vika-alue on päivitetty, uudet vuorovaikutustilanteet järjestelmän sisällä (täydessä pilvimittakaavassa tuotantotyömäärällä) aiheuttavat suorituskykyongelmia.

Huomaa, että palvelusolujen käyttö on arkkitehtuuriratkaisu, ei Oracle Cloud -palvelujen API-rajapinnassa tai SDK:ssa eksplisiittisesti nimetty suunnitelma. Mikä tahansa monen käyttäjätilin järjestelmä voi käyttää tätä arkkitehtuurimallia, eikä se edellytä erityistä tukea pilvialustalta.

Palvelusolut toimivat seuraavasti:

  • Kukin palvelun instanssi – esimerkiksi tietyllä alueella tai tietyllä saatavuusalueella (saatavuusalueen paikallisten palvelujen tapauksessa) – koostuu palvelun ohjelmistopinon useista erillisistä käyttöönotoista. Kutakin erillistä käyttöönottoa sanotaan soluksi. Kutakin solua isännöidään sen omassa infrastruktuurissa niin pitkälti kuin mahdollista. Soluilla ei koskaan ole yhteistä isäntäkonetta tai virtuaalikonetta.
  • Palvelu voi toimia aluksi muutamassa solussa kullakin alueella tai saatavuusalueella. Kun palvelua laajennetaan kysynnän kasvaessa, siihen lisätään uusia soluja, jotta ongelmien vaikutusalueiden enimmäiskoko pysyy ennallaan. Laajassa ja suositussa palvelussa voi olla useita soluja. Solut toisin sanoen mahdollistavat asiakkaan työmäärien monistuksen erillisiin isännöintiympäristöihin, joiden resurssit on erotettu muista. Toisin kuin vika-alueilla, soluilla ei ole selvää kardinaliteettia. (Kuten edellä mainittiin, vika-alueiden kardinaliteetiksi valitaan yleensä kolme vika-aluetta saatavuusalueetta kohti, jotta voidaan mahdollistaa tehokkaiden replikointijärjestelmien isännöinti yhdellä saatavuusalueella ja varmistaa korkea käytettävyys.)
  • Kukin asiakkaan työmäärän luonnollinen yksikkö määritetään tiettyyn soluun. Se, mitä luonnollisella yksilöllä tarkoitetaan, vaihtelee palvelun luonteen mukaan. Esimerkiksi sisäisesti jaetussa työnkulkupalvelussamme (joka kuvataan jäljempänä) luonnollinen yksikkö voisi olla "kaikki tällä alueella tai saatavuusalueella olevat työnkulut, jotka liittyvät tiettyyn ohjaustasoon".
  • Kunkin soluryhmän edessä on joko minimalistinen reitityskerros tai API-rajapinta, jonka avulla löydetään solujen päätepisteet. Esimerkiksi Streaming/Messaging-järjestelmässä on API-rajapinta, jonka avulla voidaan löytää tietyn aiheen nykyisen tietotason päätepiste, ja sisäisessä metatietovarastossa on erillinen päätepiste kullekin solulle. Muilla soluihin perustuvilla palveluilla on kuitenkin vain yksi tietotason päätepiste ja yhteinen reitityskerros. Reitityskerros voi mahdollisesti aiheuttaa häiriön useisiin soluihin, mutta tätä vaikutusta pienennetään pitämällä kerros erittäin yksinkertaisena, ennustettavana ja tehokkaana (ei kalliita toimintoja) sekä varaamalla siihen suuri määrä varakapasiteettia, edistynyt palvelun laadun kiintiö ja kuristusmekanismeja.
  • Palvelun omistajat voivat siirtää työmäärän tarvittaessa solusta toiseen. Seuraavassa on joitakin esimerkkitilanteita:
    • Usean asiakkaan "metelöivä naapuri" -ongelman ratkaisu siirtämällä raskas työmäärä niin, että se ei vaikuta muihin solun käyttäjiin.
    • Esimerkiksi palvelunestohyökkäyksen aiheuttamasta ylikuormituksesta tai ominaisuuksien karsinnasta palautuminen. Suojaamme palveluja tällaisilta hyökkäyksiltä kiintiö- ja kuristusmekanismeilla, mutta joskus ilmenee rajatapauksia, joissa tietty API-rajapinta tai käyttötapa on palvelulle raskaampi kuin kiintiö- tai kuristusjärjestelmä ymmärtää. Solut toimivat keinona pienentää lyhyen aikavälin kuormitusta.
    • Kriittisten työmäärien erottelu eri soluihin, jolloin voidaan pienentää liittyvien vikojen mahdollisuutta merkittävästi. Esimerkiksi sisäisessä jaetussa ohjaustasojen työnkulkupalvelussamme kriittiset ydinohjaustasot (kuten Platform, Compute, Networking ja Block Volumes) määritetään kukin omaan soluunsa, joten vikakorrelaatiota on paljon vähemmän kuin jos soluja ei käytettäisi tai tasot määritettäisiin samaan soluun.
      Huomautus: Solujen käyttö tällaiseen tarkoitukseen pienentää tarvetta ottaa palvelujen sisäisiä riippuvuudet huomioon vikasietoisia sovelluksia kehitettäessä. Riippuvuuksien tarkastelu on kuitenkin silti hyvä käytäntö (lisää tästä on jäljempänä tässä asiakirjassa), mutta sille on vähemmän tarvetta, kun erottelumekanismi on jo käytössä.

Tuloksena kukin palvelusolu on eräänlainen looginen palvelinkeskus eli erillinen vikojen ja suorituskyvyn suhteen eristetty looginen ryhmä yhden alueen tai saatavuusalueen sisällä.

Yhteenvetona voidaan sanoa, että palvelusolut ja vika-alueet täydentävät toisiaan seuraavilla tavoilla:

  • Vika-alueet suojaavat ongelmilta, kun järjestelmää muutetaan aktiivisesti.
  • Palvelusolut rajoittavat mahdollisesti vakavien ongelmien vaikutusaluetta riippumatta siitä, muutetaanko järjestelmää aktiivisesti.

Yhdistämme vika-alueiden ja palvelusolujen ominaisuudet yhtenäiseksi strategiaksi, kun teemme käyttöönottoja ja korjauksia.

Palvelusuunnittelun toimintatavat

Koska sekä testaus että toiminnot ovat erittäin tärkeitä pilvijärjestelmien luotettavuuden kannalta, käytämme monenlaisia suunnitteluprosesseja. Seuraavassa on joitakin tärkeimmistä. Niissä hyödynnetään edellisessä osassa mainittuja konsepteja:

  • Otamme palvelut käyttöön asteittain, teemme huolellisen tarkistuksen vaiheiden välissä ja perumme muutoksen heti, jos tapahtuu jotain yllättävää. Konkreettisin termein kuvattuna prosessi on seuraavanlainen:
    • Otamme kullakin saatavuusalueella käyttöön yhden palvelusolun kerrallaan. Otamme kussakin solussa käyttöön yhden vika-alueen kerrallaan, kunnes olemme saaneet kaikki solun vika-alueet valmiiksi. Sen jälkeen siirrymme seuraavaan saman saatavuusalueen soluun.
    • Käyttöönoton jokaisen vaiheen jälkeen (jokaisen vika-alueen ja solun jälkeen) tarkistamme, että muutos toimii halutulla tavalla eli että emme ole heikentäneet suorituskykyä tai tuoneet järjestelmään sisäisiä tai ulkoisia virheitä. Jos järjestelmässä näyttää olevan jotain väärää tai odottamatonta, peruutamme muutoksen heti. Painotamme peruutustoimien (kuten pysyvään tilaan tai pysyviin rakenteisiin vaikuttavien muutosten) valmistelua ja testausta, automaattinen testaus mukaan lukien.
    • Otamme tällä tavalla muutoksen käyttöön kunkin alueen yhdellä saatavuusalueella kerrallaan. Otamme muutoksen käyttöön kaikilla alueilla niin, että emme muokkaa samanaikaisesti yhtään alueparia, jonka alueita asiakas saattaisi käyttää ensisijaisena alueena ja järjestelmäpalautusalueena.
  • Tarkistamme säännöllisesti, että virheenkäsittelymekanismit ja muut korjaustoimet toimivat odotetulla tavalla eivätkä pahenna ongelmaa. Ilman tällaista testausta on yleistä, että virheenkäsittelymekanismeissa (kuten uudelleenyrityksissä, kaatuneen järjestelmän palautusalgoritmeissa ja tilakoneen uudelleenmääritysalgoritmeissa) on virheitä tai ne ovat liian kalliita tai toimivat yllättävillä tavoilla, mikä aiheuttaa ruuhkautumista tai muita vakavia suorituskykyongelmia.
  • Tarkistamme kykymme palata nopeasti ja turvallisesti takaisin viimeisimpään hyväksi tiedettyyn ohjelmistoon ja konfigurointiin, pysyvä tila ja rakenne mukaan lukien, edellä kuvatulla tavalla.
 
 

Jos Oracle-alue sisältää useita saatavuusalueita, hajautetaanko kaikki kriittiset palvelut saatavuusalueille?

Kyllä. Kaikki kunkin alueen saatavuusalueet tarjoavat samat palvelut.

 
 

Miten Oracle ja sen asiakkaat välttävät sen, että jokin tärkeä palvelu olisi riippuvainen yhdestä loogisesta palvelinkeskuksesta?

Yhden saatavuusalueen käsittävillä alueilla asiakkaat voivat käyttää vika-alueita (loogisia ryhmiä, joiden välisillä vikatiloilla ei ole korrelaatiota) ja saavuttaa niiden avulla useimmat erillisten loogisten palvelinkeskusten ominaisuudet. Asiakkaat voivat myös käyttää useita alueita järjestelmäpalautukseen.

Useita saatavuusalueita käsittävillä alueilla asiakkaat voivat käyttää vika-alueita samalla tavalla. Asiakkaat voivat myös käyttää saatavuusalueen paikallisia palveluja, saatavuusalueiden välisiä vikasieto-ominaisuuksia (kuten DBaaS-palvelua ja Data Guard -toimintoa) sekä alueellisia palveluja (Object Storage- ja Streaming-palveluja) ja saavuttaa näin täyden korkean käytettävyyden korkean tason loogisissa palvelinkeskuksissa (saatavuusalueilla). Lisäksi asiakkaat voivat käyttää useita alueita järjestelmäpalautukseen.

Kaikissa tapauksissa asiakkaat voivat eristää vakavimmatkin ongelmat, kuten ruuhkautumisen, palvelusolujen avulla.

 
 

Miten Oracle tekee ylläpitotoimet niin, että asiakkaat voivat käyttää tärkeitä palveluja jatkuvasti?

Onnistumme tässä käyttämällä vika-alueita, palvelusoluja ja omia lisäävän käyttöönoton ja tarkistuksen toimintatapojamme. Katso aiempana tässä asiakirjassa oleva kuvaus.

 
 

Otetaanko palvelimettomia alustapalveluita käyttöön useissa loogisissa palvelinkeskuksissa käytettävyyden parantamiseksi?

Kyllä. Kaikki palveluluokat otetaan käyttöön useissa loogisissa palvelinkeskuksissa – erillisissä vikojen ja suoritustason suhteen eristetyissä loogisissa ryhmissä –, mikä mahdollistaa vikasietoisuuden ja jatkuvan käytettävyyden.

 
 

Jos vikasietoisuus ei ole oletuskonfiguraatio, annetaanko asiakkaille mahdollisuus ottaa käyttöön useita loogisia palvelinkeskuksia (esimerkiksi usean saatavuusalueen konfiguraatio tai alueiden välinen konfiguraatio)?

Yhden saatavuusalueen alueilla vika-alueet ovat tapa käyttää useita loogisia palvelinkeskuksia, kuten toisaalla tässä asiakirjassa kuvataan.

Usean saatavuusalueen alueilla tarjoamme palveluja ja toimintoja, jotka mahdollistavat vieläkin korkeamman fyysisen kestävyyden tason synkronisesti toisinnetuille tiedoille (pienin suorituskykykustannuksin, jotka johtuvat saatavuusalueiden välisistä etäisyyksistä alueella ja valon nopeudesta).

Emme tarjoa automaattisia korkean käytettävyyden tai vikasietoisuuden mekanismeja alueiden välillä, sillä silloin alueiden välille syntyisi läheinen liitossuhde. Tämä puolestaan lisäisi useiden alueiden samanaikaisten ongelmien riskiä. Sen sijaan mahdollistamme erityyppiset asynkroniset replikoinnit alueiden välillä ja tarjoamme jatkuvasti kasvavan valikoiman toimintoja, kuten asynkronisen kopioinnin ja varmuuskopioinnin, joilla alueiden välinen järjestelmäpalautus voidaan varmistaa.

 
 

Miten Oracle auttaa asiakkaita välttämään sovellusten häiriöt, jotka johtuvat eri infrastruktuuri- ja alustapalvelujen välisistä sisäisistä riippuvuuksista?

Tämä on monimutkainen kysymys, jota on hyvä tarkastella parista eri näkökulmasta:

  • Jos asiakas haluaa käyttää kahta Oracle-palvelua (palvelua A ja palvelua B) ja kehittää sovelluksen, joka on vikasietoinen, jos jompikumpi näistä palveluista vikaantuu, täytyykö asiakkaan tietää, onko palvelu A sisäisesti riippuvainen palvelusta B? Johtavatko sisäiset riippuvuudet korreloivaan häiriöön merkittävissä määrin? Jos näin on, asiakkaan täytyy ehkä tietää tällaisista sisäisistä riippuvuuksista voidakseen päättää, mihin muuhun tarkoituksiin palveluja A ja B voi käyttää – vai kannattaako sen sijaan käyttää näihin tarkoituksiin muihin liittymätöntä palvelua C – kehittäessään omia vikasietomekanismejaan sovellustasolla.
  • Miten asiakas voi parhaiten suojautua Oracle-palvelujen korreloivia häiriöitä vastaan?

Vastaus on kaksiosainen.

Arkkitehtuuriperiaatteet

Käytämme arkkitehtuuriperiaatteita, jotka vähentävät riippuvaisten palvelujen korreloivia häiriöitä merkittävästi. Joissakin tapauksissa tämä tekniikka pienentää korreloivien häiriöiden todennäköisyyttä siinä määrin, että ne voidaan käytettävyyden palvelutasosopimusten täyttämisen näkökulmasta unohtaa.

Käytämme erityisesti palvelusoluja, kuten aiemmin tässä asiakirjassa kuvataan. Solut auttavat tässä ongelmassa, sillä jos sisäisestä palvelusta A riippuvaisen palvelun B ongelma vaikuttaa palveluun A, palvelun B ongelma rajoittuu todennäköisesti yhteen soluun. Muut palvelua B käyttävät korkean tason palvelut ja asiakkaan omat sovellukset käyttävät todennäköisesti muita soluja, joihin häiriö ei vaikuta. Tämä on tilastollinen argumentti, joka vaihtelee solujen määrän mukaan. Solujen määrä puolestaan on piilotettu sisäinen parametri, joka muuttuu (kasvaa), joten sille ei anneta määrää tai muuta takuuta kuin palvelujen A ja B omat palvelutasosopimukset. Käytännössä tämä voi kuitenkin merkittävästi vähentää ongelmien vaikutuksia palvelujen välillä.

Monet jaetuista sisäisistä palveluistamme – esimerkiksi ohjaustasojen työnkulku- ja metatietopalvelut sekä Streaming/Messaging-palvelu – torjuvat niitä käyttävien palvelujen käyttökatkosten vaikutukset palvelusolujen avulla.

Riippuvuudet

Seuraavat ohjeet ovat korkean tason ohjeita, sillä palvelujen matalan tason toteutukset ja tiedot voivat muuttua. Tärkeissä tietojenkäsittelyn, tallennuksen, verkkoyhteyksien ja todennuksen/valtuutuksen ulottuvuuksissa on kuitenkin seuraavat riippuvuudet.

Ohjaustasojen yleiset riippuvuudet ovat seuraavat:

  1. Käyttäjätietojen/alustan tietotaso todennusta ja valtuutusta varten
  2. Tarkastusten seurantapalvelu
  3. Sisäiset palvelut, jotka huolehtivat esimerkiksi työnkulusta, metatietojen tallennuksesta ja kirjauksesta
  4. Erityyppiset kuormantasaajat

Joillakin ohjaustasoilla on selvästi palvelukohtaisia riippuvuuksia. Esimerkiksi tietojenkäsittelyn ohjaustaso on käyttöjärjestelmätöntä instanssia tai virtuaalikoneinstanssia käynnistettäessä riippuvainen seuraavista palveluista:

  • Object Storage (määritetyn käyttöjärjestelmän näköistiedoston nouto)
  • Block Volumes -ohjaustaso (käynnistysaseman valmistelu ja liittäminen)
  • Networking-ohjaustaso (VNIC-sovittimien valmistelu ja liittäminen).

Ydinpalvelujen tietotasojen yleinen periaate on, että jokainen tietotaso on tarkoituksellisesti suunniteltu mahdollisimman vähin riippuvuuksin, jotta voidaan saavuttaa korkea käytettävyys sekä nopea vianmääritys ja palautus. Tämä periaate tuottaa seuraavat tulokset:

  • Networking-tietotaso on muista riippumaton taso.
  • Block Volumes -tietotaso on muista riippumaton taso.
  • Käyttöjärjestelmättömät käsittelyinstanssit ja virtuaalikoneinstanssit ovat riippuvaisia Block Volumes -tietotasosta (käynnistysasemat) ja Networking-tietotasosta.
  • Object Storage -tietotaso on riippuvainen käyttäjätietojen/alustan tietotasosta todennuksen ja valtuutuksen suteen (alan odotusten vuoksi). Object Storage -tietotaso ei ole riippuvainen Block Volumes- tai File Storage -tietotasoista.
  • Kaikki varmuuskopiointia ja palautusta tukevat palvelut ovat riippuvaisia Object Storage -tietotasosta näiden toimintojen toteutuksessa.

IaaS-tietotasojen yleinen periaate on se, että tietotaso on riippuvainen vain ydintietotasoista tai alemmista tietotasoista (jotta vältetään kehäriippuvuudet).

  • Tietokannan monisolmuinen RAC on riippuvainen Networking-tietotasosta ja Block Volumes -tietotasosta.
  • Container Engine for Kubernetes on riippuvainen Kubernetesista ja sen omista riippuvuuksista (esimerkiksi etcd:stä) sekä Networking-tietotasosta.
  • Kaikki varmuuskopioinnin ja palautuksen tuki on riippuvainen Object Storage -tietotasosta.

1Stanfordin ja Berkeleyn julkinen tutkimusohjelma Armando Foxin ja Dave Pattersonin johdolla

 
×
Soita meille
1-800-633-0738 (Yhdysvallat)

Ota yhteyttä
×
Soita meille
1-800-633-0738 (Yhdysvallat)


Oracle Cloud -keskustelufoorumit