Vyhlásenie o odmietnutí zodpovednosti

Nasledujúci text popisuje všeobecný smer vývoja našich produktov. Je určený len na informačné účely a nesmie byť súčasťou žiadnej zmluvy. Tieto informácie nie sú záväzkom na dodanie žiadneho materiálu, kódu alebo funkcionality a nemali by ste sa o ne opierať pri rozhodovaní o nákupe. Vývoj, vydanie a načasovanie ktorejkoľvek z funkcií či funkcionalít produktov Oracle sa môže zmeniť a závisí výlučne od spoločnosti Oracle Corporation.

V časti často kladených otázok nájdete odpovede na bežné otázky o spôsobe, akým spoločnosť Oracle dosahuje pružnosť a nepretržitú dostupnosť našich základných služieb infraštruktúry a hostiteľskej platformy. Zákazníci služby Oracle Cloud môžu mať na tieto otázky rôzne dôvody:

  • Pomáhajú zákazníkom uplatňovať potrebnú starostlivosť pri posudzovaní hostiteľskej platformy a služieb spoločnosti Oracle.
  • Mnohé z odpovedí popisujú výzvy a riešenia, ktoré sú nevyhnutné pre všetky systémy na úrovni cloudu, a môžu teda poskytnúť informácie o architektúre a dizajne systémov, ktoré chcú zákazníci vybudovať v cloude.

Často kladené otázky o pružnosti a nepretržitej dostupnosti služieb a platformy Oracle Cloud Infrastructure

Rozlišuje spoločnosť Oracle rôzne triedy služieb, ako napríklad kritické služby, nepretržite dostupné služby alebo služby s jedným umiestnením?

Takéto rozdiely nerobíme. Namiesto toho kategorizujeme naše služby podľa úrovne závislosti, rozsahu dostupnosti a dátovej vrstvy v porovnaní s riadiacou vrstvou. Pri navrhovaní týchto kategórií sme sa snažili vytvoriť rôzne užitočné kompromisy medzi dostupnosťou, odolnosťou, výkonom a pohodlím.

Úrovne závislosti

Tieto úrovne môžu byť považované za úrovne alebo vrstvy v architektonickom blokovom diagrame. Každá vrstva môže závisieť len od vrstiev pod ňou.

Zospodu nahor:

  • Základné služby: Tieto služby tvoria základ služby Oracle Cloud Infrastructure. Patrí medzi ne správa identity a prístupu (IAM), správa kľúčov, sieťové služby, computing, blokové zväzky, objektový ukladací priestor, telemetria a niekoľko zdieľaných interných služieb. Sú navrhnuté tak, aby mali minimálne závislosti, a to dokonca aj medzi sebou. (Podrobnosti o závislostiach nájdete v ďalšej časti tohto dokumentu.)
  • IaaS: Táto vrstva poskytuje funkcionalitu na úrovni infraštruktúry, ktorá je postavená na základných službách. Medzi služby v tejto vrstve patrí ukladací priestor súborov, databáza a Container Engine for Kubernetes.
  • SaaS: Táto vrstva je softvér ako služba s množstvom funkcií, ktorá je postavená na nižších vrstvách.
Rozsah dostupnosti

Na splnenie cieľov dostupnosti a odolnosti služby je pre každú službu zvolený jeden z nasledujúcich rozsahov dostupnosti:

  • Lokálna doména dostupnosti: Každá doména dostupnosti obsahuje jednu nezávislú inštanciu služby. Takéto služby ponúkajú vysokú odolnosť uložených dát pomocou synchrónnej replikácie medzi replikami v rámci tej istej domény dostupnosti (podrobnosti nájdete v časti o chybových doménach nižšie v tomto dokumente). Tieto služby dokážu v závislosti od ich charakteru tolerovať výpadok tretiny alebo ešte väčšej časti infraštruktúry v doméne dostupnosti. Služby lokálnej domény dostupnosti dosahujú túto úroveň odolnosti voči chybám pomocou dvoch rôznych druhov logických dátových centier v rámci domény – logických skupín izolácie chýb a izolácie výkonu. Podrobnosti nájdete v častiach o chybových doménach a bunkách služby nižšie v tomto dokumente. Nakoniec treba spomenúť, že tieto služby môžu naďalej normálne fungovať aj vtedy, keď doména dostupnosti nedokáže komunikovať s inými doménami dostupnosti. Vďaka tomu tolerujú stratu iných domén dostupnosti alebo úplné zlyhanie rozsiahlej siete v rámci oblasti.
  • Viaceré regionálne domény dostupnosti: Každá oblasť s viacerými doménami dostupnosti obsahuje jednu nezávislú inštanciu služby, pričom komponenty sa nachádzajú v každej doméne dostupnosti v danej oblasti. Tieto služby ponúkajú veľmi vysokú odolnosť uložených dát pomocou synchrónnej replikácie do viacerých domén dostupnosti v rovnakej oblasti. Tieto služby dokážu tolerovať výpadok ktorejkoľvek domény dostupnosti v oblasti alebo neschopnosť komunikovať s ňou.
  • Jedna regionálna doména dostupnosti: Ak oblasť obsahuje iba jednu doménu dostupnosti, pozorovateľné charakteristiky regionálnej služby sa zhodujú s charakteristikami lokálnej služby domény dostupnosti, ako je opísané vyššie. Rozdiel medzi službou lokálnych domén dostupnosti a službou jednej regionálnej domény dostupnosti sa stáva relevantným len vtedy, keď sa oblasť s jednou doménou rozšíri pridaním jednej alebo viacerých domén dostupnosti. Keď k tomu dôjde, každá regionálna služba sa automaticky rozšíri, aby primerane využila nové domény dostupnosti, pričom zostane jedinou inštanciou služby. Dátová vrstva Objektový ukladací priestor by sa, napríklad, rozšírila, aby využila ďalšie domény dostupnosti na zvýšenie odolnosti existujúcich dát. Naopak, v prípade služieb lokálnej domény dostupnosti získa každá z nových domén dostupnosti vlastnú novú a samostatnú inštanciu každej služby lokálnej domény dostupnosti.
  • Distribúcia naprieč oblasťami: Základným princípom služby Oracle Cloud Infrastructure je, aby bola každá oblasť do čo najväčšej možnej miery prevádzkovo nezávislá od tých ostatných. Slovo možnej naráža na skutočnosť, že oblasti musia nevyhnutne zdieľať aspoň určitú infraštruktúru, napríklad vzájomnú chrbticovú sieť. Ak to tak nie je, nevytvárame medzi oblasťami úzko prepojené mechanizmy, ako je napríklad transparentná vysoká dostupnosť alebo prepnutie pri zlyhaní, ktoré by mohli spôsobiť problémy ovplyvňujúce viacero oblastí súčasne. Namiesto toho poskytujeme dva mechanizmy na distribúciu služieb naprieč oblasťami s voľnou väzbou:
    • Obnovenie po havárii: Základom nášho prístupu a samotných investícií do cloudu je, že umožňujeme zákazníkom budovať systémy s charakteristikami obnovenia po havárii. Viaceré základné služby už ponúkajú mechanizmy obnovenia po havárii – napríklad zálohovanie blokových zväzkov a kopírovanie objektového ukladacieho priestoru medzi oblasťami. Funkcionalita obnovenia po havárii je dôležitou prioritou pri plánovaní všetkých našich služieb.
    • Predplatné medzi oblasťami: Momentálne poskytujeme predplatné medzi regiónmi iba pre dáta IAM. Koncepčne majú dáta IAM globálny rozsah. Zákazníci si môžu predplatiť (zaregistrovať) množinu oblastí a my automaticky replikujeme príslušné dáta IAM a následné aktualizácie do určených oblastí. Aby sa zabránilo úzkemu prepojeniu, replikácia je asynchrónna a eventuálne konzistentná. Zákazníci vykonávajú zmeny svojich dát IAM vo svojej „domovskej“ oblasti, ktorú nominujú. Ak sa súčasná domovská oblasť stane z nejakého dôvodu nedostupná alebo nevhodná, môže byť nominovaná iná oblasť.
Porovnanie kontrolnej a dátovej vrstvy

Dátová vrstva služby je kolekcia rozhraní a komponentov na spracovanie dát, ktoré implementujú funkcionalitu služby, ktorú majú používať aplikácie. Dátová vrstva virtuálnej cloudovej siete (VCN) napríklad obsahuje systém spracovania sieťových paketov, virtualizované smerovače a brány, zatiaľ čo dátová vrstva blokových zväzkov obsahuje implementáciu protokolu iSCSI a replikovaný ukladací systému odolný voči chybám pre objemové dáta.

Kontrolná vrstva služby je množina rozhraní API a komponentov zodpovedných za tieto úlohy:

  • riadenie zákazníckych požiadaviek na poskytovanie, prekonfigurovanie, škálovanie nahor alebo nadol a zrušenie prostriedkov,
  • rýchle a bezpečné vykonávanie automatických opráv rozsiahlych vozových parkov,
  • detekcia zlyhaných, degradovaných alebo nesprávne nakonfigurovaných zdrojov,
  • vykonávanie automatickej opravy alebo požiadanie ľudských operátorov o pomoc,
  • spolupráca s inými kontrolnými vrstvami (napr. computing, sieť VCN a blokový ukladací priestor sú pri príkaze LaunchInstance spojené),
  • správa nevyužitej kapacity,
  • koordinácia s ľuďmi, napr. pri príchode nového zariadenia a fyzickej oprave a údržbe,
  • poskytovanie prevádzkovej viditeľnosti a kontroly.
 
 

Ako spoločnosť Oracle zabezpečuje pružnosť a nepretržitú dostupnosť služieb?

Pri vytváraní všetkých typov služieb sa držíme rovnakého súboru princípov, aby sme dosiahli pružnosť a dostupnosť, pretože základné inžinierske výzvy pri budovaní odolných, škálovateľných a distribuovaných systémov sú rovnaké pre všetky typy služieb.

Aby sme dosiahli pružnosť a nepretržitú dostupnosť, musíme pochopiť a následne vyriešiť všetky príčiny nedostupnosti v systémoch na úrovni cloudu – degradovaný výkon a nevyriešené zlyhania. Existuje veľké množstvo takýchto príčin, preto ich zoskupujeme do kategórií podľa ich základnej povahy.

Tradične sa analýza dostupnosti podnikových IT systémov zameriavala na kategóriu zlyhania hardvéru. V prípade cloudových systémov je však zlyhanie hardvéru relatívne malý problém, ktorému dobre rozumieme. V súčasnosti je pomerne jednoduché vyhnúť sa alebo zmierniť väčšinu jednotlivých porúch hardvéru. Napríklad racky môžu mať dvojité napájanie a pridružené napájacie jednotky a mnohé komponenty sú vymeniteľné za chodu. Rozsiahle zlyhanie hardvéru a straty sú samozrejme možné – napríklad v dôsledku prírodných katastrof. Naše skúsenosti a správy z verejných dodatočných rozborov od iných dodávateľov cloudu však ukazujú, že k zlyhaniu alebo strate celého dátového centra dochádza v porovnaní s inými príčinami nedostupnosti veľmi zriedka. Rozsiahle zlyhanie hardvéru je stále potrebné riešiť (napríklad pomocou obnovenia po havárii a iných mechanizmov), ale zďaleka nejde o dominantný problém dostupnosti.

Hlavné príčiny nedostupnosti v systémoch na úrovni cloudu sú nasledovné:

  1. Softvérové chyby
  2. Chyby konfigurácie
  3. Chyby spôsobené ľudskými operátormi
    Poznámka: Hlavným ponaučením z priemyslu je, že tieto tri formy ľudských chýb sú zďaleka najväčšími príčinami nedostupnosti. Hoci frekvenciu ich výskytu možno znížiť pomocou nástrojov, automatizácie a školení, nemožno ich odstrániť. Preto je potrebné riešiť ich ako primárne problémy už pri architektúre, dizajne a implementácii systému.
  4. Neprijateľný rozdiel vo výkone (latencia alebo priepustnosť) z akéhokoľvek dôvodu vrátane nasledujúcich:
    • rušivé vplyvy s viacerými nájomcami (zlyhanie mechanizmov QoS),
    • neschopnosť efektívne odmietnuť preťaženie (náhodné alebo s úmyslom uškodiť) a zároveň pokračovať v užitočnej práci,
    • distribuovaný thrashing, prudký nápor správ, prudký nápor odpovedí a ďalšie nákladné a čoraz častejšie sa vyskytujúce interakcie,
    • studený šok (prázdne pamäte cache) po výkonovom cykle, najmä súčasný výkonový cyklus viacerých systémov,
    • režijné náklady pri škálovaní systému (napríklad opakované rozdeľovanie na menšie časti).
  5. Neobmedzenie zasiahnutej oblasti (počet dotknutých zákazníkov a systémov) pri ktoromkoľvek z predchádzajúcich problémov

Tieto výzvy sú univerzálne – sú súčasťou „fyzikálnych zákonov“ pre distribuované systémy na úrovni cloudu.

Pre každú z predchádzajúcich kategórií používame na riešenie problému osvedčené inžinierske stratégie. Najdôležitejšie z nich sú:

  • princípy architektúry a návrhu systému,
  • nové architektonické koncepty (ktoré zvyčajne vyplývajú z uplatňovania princípov),
  • postupy servisného inžinierstva.
Princípy architektúry a návrhu systému

Existuje množstvo týchto princípov, ale zameriame sa na tie, ktoré sú pre pružnosť a dostupnosť najrelevantnejšie.

Computing zameraný na obnovenie

Na riešenie softvérových chýb a chýb operátorov, ktorí majú relatívne lokalizovaný vplyv, sa riadime princípmi computingu zameraného na obnovenie1. Na vysokej úrovni to znamená, že namiesto toho, aby sme sa snažili zaručiť, že sa nikdy nevyskytne problém (čo nie je možné otestovať), zameriavame sa na riešenie všetkých problémov nerušivým spôsobom, ktorý sa dá otestovať. Zameriavame sa najmä na minimalizáciu priemerného času do obnovenia (MTTR), ktorý je kombináciou priemerného času na detekciu, priemerného času na diagnostiku a priemerného času na zmiernenie následkov.

Naším cieľom je vykonať obnovenie tak rýchlo, aby problém nezaťažil používateľov. Dosahujeme ho nasledujúcimi krokmi:

  • Pomocou rozšíreného používania kontrolných výrazov v kóde a aktívneho monitorovania a alarmov na všetkých úrovniach rýchlo a automaticky rozpoznávame príznaky chýb a chyby operátorov.
  • Balíme funkcie do množstva samostatných detailných jednotiek izolácie (vlákna, procesy, stavové mechanizmy a pod.), ktoré sú voľne spojené – nezdieľajú priamo pamäť, ktorá by sa mohla poškodiť.
  • Pri zistení príznakov chyby alebo chyby zo strany operátora čo najrýchlejšie reštartujeme uzatvárajúcu jednotku izolácie. Reštartovanie je praktický spôsob, ako sa pokúsiť o obnovenie z náhodného zlyhania, pretože ide o pokus o obnovenie stavu, ktorý je dobre otestovaný, takže obnovuje invarianty.
  • Ak obnovenie na detailnej úrovni izolácie nefunguje (napríklad kontrolný výraz pokračuje v príliš častej aktivácii pre danú úroveň, čo spôsobuje spin-crashing), eskaluje sa na ďalšiu väčšiu jednotku (proces, runtime, hostiteľ, logické dátové centrum , upozornenie ľudského operátora).
  • Vytvárame mechanizmy, ktoré umožňujú celosystémové zrušenie zmeny vrátane tvorby verzií všetkých perzistentných stavov a konfigurácií za účelom rýchlej identifikácie a zrušenia nesprávnych potvrdení.

Minimalizácia vplyvu problémov

Na riešenie chýb, ktoré by mohli mať rozsiahlejší vplyv, vytvárame mechanizmy na minimalizáciu zasiahnutej oblasti pri akomkoľvek probléme. To znamená, že sa zameriavame na minimalizáciu počtu zákazníkov, systémov alebo zdrojov, ktoré sú prípadným problémom ovplyvnené, vrátane obzvlášť náročných problémov s viacerými nájomcami, ako sú rušivé vplyvy, ponúknuté preťaženie, znížená kapacita a distribuovaný thrashing. Dosahujeme to pomocou rôznych hraníc izolácie a postupov riadenia zmien (viď nasledujúce časti).

Architektonické koncepty vyplývajúce z princípov dizajnu

Existuje množstvo týchto konceptov, ale zameriame sa na tie, ktoré slúžia na obmedzenie zasiahnutej oblasti.

Koncepty umiestnenia zakotvené v našom verejnom rozhraní API: oblasti, domény dostupnosti a chybové domény

Keďže chybové domény sú relatívne nové, opíšeme ich podrobnejšie.

Chybové domény sa používajú na obmedzenie zasiahnutej oblasti pri problémoch, ktoré nastávajú pri aktívnej zmene systému – napríklad pri nasadeniach, opravách, reštartoch hypervízora a fyzickej údržbe.

Zárukou je, že v danej doméne dostupnosti sa kedykoľvek menia zdroje v najviac jednej chybovej doméne. Ak nastane počas zmeny nejaký problém, niektoré alebo všetky zdroje v tejto chybovej doméne môžu byť na chvíľu nedostupné, ale ostatné chybové domény v doméne dostupnosti nebudú ovplyvnené. Každá doména dostupnosti obsahuje aspoň tri chybové domény, aby bolo možné v rámci jednej domény dostupnosti hostiť systémy replikácie na báze kvóra (napríklad Oracle Data Guard) s vysokou dostupnosťou.

Výsledkom je, že pri problémoch s dostupnosťou z hlavnej kategórie – softvérové chyby, chyby konfigurácie, chyby operátorov a problémy s výkonom, ku ktorým dochádza počas procesu zmeny – funguje každá chybová doména ako samostatné logické dátové centrum v rámci domény dostupnosti.

Chybové domény tiež chránia pred niektorými druhmi lokálneho zlyhania hardvéru. Vlastnosti chybových domén zaručujú, že zdroje umiestnené v rôznych chybových doménach v najväčšej praktickej miere nezdieľajú žiadne potenciálne samostatné miesta zlyhania hardvéru v rámci domény dostupnosti. Napríklad, zdroje v rôznych chybových doménach nezdieľajú rovnaký sieťový prepínač typu top-of-rack, pretože štandardný dizajn takýchto prepínačov nemá redundanciu.

Schopnosť chybových domén chrániť pred problémami s hardvérom alebo s fyzickým prostredím sa však končí na tejto lokálnej úrovni. Chybové domény na rozdiel od domén dostupnosti a oblastí neposkytujú žiadnu rozsiahlu fyzickú izoláciu infraštruktúry. V zriedkavých prípadoch prírodnej katastrofy alebo zlyhania infraštruktúry v celej doméne dostupnosti by boli pravdepodobne súčasne ovplyvnené zdroje vo viacerých chybových doménach.

Naše interné služby používajú chybové domény rovnakým spôsobom, ako by ich mali používať zákazníci. Napríklad služby blokových zväzkov, objektového ukladacieho priestoru a ukladacieho priestoru súborov ukladajú repliky dát v troch samostatných chybových doménach. Všetky komponenty všetkých kontrolných a dátových vrstiev sú hostené vo všetkých troch chybových doménach (alebo vo viacerých doménach dostupnosti v prípade oblasti s viacerými doménami dostupnosti).

Bunky služby

Bunky služby sa používajú na obmedzenie zasiahnutej oblasti pri problémoch, ku ktorým dochádza aj inokedy ako pri aktívnych zmenách systému. Takéto problémy môžu vznikať, pretože záťaž cloudového systému s viacerými nájomcami sa môže kedykoľvek extrémne zmeniť, a pretože v ktoromkoľvek veľkom distribuovanom systéme sa môže kedykoľvek vyskytnúť zložité čiastočné zlyhanie. Tieto scenáre môžu spúšťať nepatrné skryté chyby alebo vznikajúce problémy s výkonom.

Bunky služby okrem toho tiež obmedzujú zasiahnutú oblasť v niektorých zriedkavých, ale náročných prípadoch, kedy dochádza k aktívnej zmene systému. Klasickým príkladom je, že nasadenie na individuálnu chybovú doménu sa javí ako úspešné a nie sú očividné žiadne chyby alebo zmeny vo výkone. Hneď po aktualizácii druhej alebo poslednej chybovej domény však nové interakcie v rámci systému (na celej úrovni cloudu s produkčnou záťažou) spôsobia problém s výkonom.

Všimnite si, že použitie buniek služby je vzorom architektúry a nie konceptom, ktorý je explicitne pomenovaný v rozhraní API alebo súprave SDK služby Oracle Cloud. Tento vzor architektúry môže použiť ľubovoľný systém s viacerými nájomcami. Nevyžaduje špeciálnu podporu z cloudovej platformy.

Bunky služby pracujú nasledovne:

  • Každá inštancia služby (napríklad v konkrétnej oblasti alebo v prípade služieb lokálnej domény dostupnosti v konkrétnej doméne dostupnosti) pozostáva z viacerých samostatných nasadení softvérových zdrojov služby. Každé samostatné nasadenie sa nazýva bunka. Každá bunka je prakticky umiestnená vo vlastnej infraštruktúre. Minimálnym predpokladom je, že bunky nezdieľajú hostiteľov ani virtuálne počítače.
  • Službu možno spustiť s niekoľkými bunkami v každej doméne dostupnosti alebo oblasti. Keď sa služba prispôsobuje rastúcemu dopytu, pridávajú sa ďalšie bunky, aby bol zachovaný limit veľkosti zasiahnutej oblasti v prípade akýchkoľvek problémov. Veľká a populárna služba môže mať veľa buniek. Inými slovami, bunky poskytujú multiplexing (n na m) zákazníckych záťaží za účelom oddelenia hostiteľských prostredí – oddelených ostrovov izolácie zdrojov. Bunky nemajú zrejmú kardinalitu, napríklad takú, aká existuje pre chybové domény. (Ako už bolo spomenuté vyššie, jasnou voľbou pre kardinalitu chybových domén sú tri na jednu doménu dostupnosti, aby bolo možné v rámci jednej domény dostupnosti hostiť systémy replikácie na báze kvóra s vysokou dostupnosťou.)
  • Každá „prirodzená jednotka“ zákazníckej záťaže je priradená ku konkrétnej bunke. Definícia prirodzenej jednotky závisí od povahy konkrétnej služby. Napríklad pre našu internú zdieľanú službu toku činností (popísanú nižšie) môžu byť prirodzenou jednotkou „všetky toky činností v tejto doméne dostupnosti alebo oblasti pre konkrétnu kontrolnú vrstvu“.
  • Pred každou skupinou buniek je buď minimalistická smerovacia vrstva alebo rozhranie API na objavovanie koncových bodov buniek. Systém streamovania/posielania správ má napríklad rozhranie API na zistenie aktuálneho koncového bodu dátovej vrstvy pre konkrétnu tému a interný ukladací priestor metadát má samostatný koncový bod na bunku. Iné služby založené na bunkách však majú jediný koncový bod dátovej vrstvy a zdieľanú smerovaciu vrstvu. Smerovacia vrstva je potenciálnou príčinou súvisiaceho zlyhania viacerých buniek. Tento problém však zmierňuje fakt, že je extrémne jednoduchá, predvídateľná a výkonná (bez nákladných operácií) a má k dispozícii veľkú výkonnostnú kapacitu, sofistikované mechanizmy kvót QoS a obmedzovania.
  • Vlastníci služieb môžu podľa potreby presúvať záťaž z jednej bunky do druhej. Nasledujú niektoré vzorové scenáre:
    • Presunutie náročnej záťaže v záujme predchádzania problémom s rušivými vplyvmi s viacerými nájomcami tak, aby neboli ovplyvnení ostatní používatelia bunky.
    • Na obnovenie z preťaženia alebo brownoutu, ktorý mohol spôsobiť útok DDoS. Máme mechanizmy kvót a obmedzovania, ktoré bránia takýmto útokom. Niekedy sa však vyskytnú krajné situácie, kedy je konkrétny prípad použitia (rozhranie API, vzor prístupu) kladie na službu vyššie nároky, než aké systém kvót a obmedzovania momentálne dokáže spracovať. Bunky poskytujú mechanizmus krátkodobého zmiernenia.
    • Na rozdelenie kritických záťaží do rôznych buniek, čím sa významne zníži pravdepodobnosť súvisiaceho zlyhania. Náš interný zdieľaný tok činností pre kontrolné vrstvy napríklad funguje tak, že kontrolné vrstvy kritických základných služieb (napríklad platforma, výpočtové služby, sieťové služby a blokové zväzky) sú priradené k rôznym bunkám a korelácia ich zlyhania je teda podstatne nižšia, ako keby sme bunky nepoužili alebo keby boli vrstvy priradené k tej istej bunke.
      Poznámka: V prípade použitia týchto buniek nemusia zákazníci pri vytváraní pružných aplikácií brať do úvahy interné závislosti služieb v takej miere. Zváženie grafu závislosti je stále osvedčeným postupom (ďalšie informácie nájdete ďalej v tomto dokumente), ale ak je mechanizmus dekódovania už aktívny, nie je až tak potrebné.

Výsledkom je, že každá bunka služby je ďalším druhom logického dátového centra – logického zoskupenia izolácie výkonu a izolácie chýb – v rámci jednej domény alebo oblasti dostupnosti.

Stručne povedané, bunky služby a chybové domény sa navzájom dopĺňajú nasledujúcimi spôsobmi:

  • Chybové domény chránia pred problémami pri aktívnych zmenách systému.
  • Bunky služby obmedzujú zasiahnutú oblasť, keď má systém potenciálne závažné problémy – či už prechádza aktívnou zmenou, alebo nie.

Pri nasadeniach a opravách kombinujeme vlastnosti chybových domén a buniek služby do jednotnej stratégie.

Postupy servisného inžinierstva

Keďže testovanie aj špičková prevádzka sú pre spoľahlivosť cloudových systémov rozhodujúce, máme veľké množstvo inžinierskych postupov. Nižšie sú uvedené niektoré z tých najdôležitejších, ktoré využívajú koncepty uvedené v predchádzajúcej časti:

  • Služby nasadzujeme postupne, medzi jednotlivými krokmi uskutočňujeme podrobné overenia a v prípade nečakaných výsledkov vykonáme reflexný rollback. Konkrétne, proces je nasledovný:
    • V každej doméne dostupnosti nasadzujeme do bunky služby postupne. Pri každej bunke nasadzujeme naraz iba do jednej chybovej domény, až kým nenaplníme všetky chybové domény pre túto bunku. Potom prejdeme na ďalšiu bunku v tejto doméne dostupnosti.
    • Po každom kroku nasadenia (po každej chybovej doméne a bunke) overíme, či zmena funguje tak, ako má, teda či sme nezhoršili výkon ani nezaviedli žiadne chyby, či už interné, alebo externé. Ak sa zdá, že sa niekde stala chyba alebo sa vyskytne niečo neočakávané, túto zmenu reflexívne vrátime späť. Veľmi kladieme dôraz na prípravu a testovanie (vrátane automatizovaného testovania) postupov rollbacku spolu so zmenami, ktoré ovplyvňujú perzistentný stav alebo schémy.
    • Týmto spôsobom postupne nasadzujeme zmenu domény dostupnosti po jednej do každej oblasti. Nasadzujeme do všetkých oblastí vo sfére takým spôsobom, aby sme súčasne nemodifikovali žiadny pár oblastí, ktoré by mohol zákazník používať ako primárne lokality a lokality na obnovenie po havárii.
  • Pravidelne kontrolujeme, či mechanizmy na riešenie chýb a iné systémy zmiernenia fungujú podľa očakávaní a nezhoršujú problém. Bez takýchto testov je bežné, že mechanizmy na riešenie chýb (ako sú napríklad opakovania, algoritmy na obnovenie po zlyhaní a algoritmy na rekonfiguráciu automatov) majú chyby, sú príliš drahé alebo fungujú neočakávaným spôsobom, a spôsobujú tak distribuovaný thrashing alebo iné závažné výkonnostné problémy.
  • Overujeme našu schopnosť rýchlo a bezpečne vrátiť zmeny do poslednej známej dobrej verzie softvéru a konfigurácie vrátane perzistentného stavu a schémy, ako bolo opísané vyššie.
 
 

Sú v oblastiach spoločnosti Oracle, ktoré obsahujú viaceré domény dostupnosti, všetky najdôležitejšie služby distribuované naprieč doménami dostupnosti?

Áno. V každej oblasti ponúkajú všetky domény dostupnosti rovnaký súbor služieb.

 
 

Ako sa spoločnosť Oracle a jej zákazníci vyhýbajú situácii, kedy by bola kritická služba závislá od jedného logického dátového centra?

V oblastiach s jednou doménou dostupnosti môžu zákazníci dosiahnuť väčšinu vlastností samostatných logických dátových centier pomocou chybových domén (logické skupiny s dekorelovanými režimami zlyhania medzi skupinami). Zákazníci tiež môžu použiť viacero oblastí na obnovenie po havárii.

V oblastiach s viacerými doménami dostupnosti môžu zákazníci používať chybové domény rovnakým spôsobom. Zákazníci tiež môžu na dosiahnutie vysokej dostupnosti naprieč logickými dátovými centrami vyššej úrovne (doménami dostupnosti) použiť kombináciu služieb lokálnych domén dostupnosti, funkcií prepnutia medzi doménami dostupnosti pri zlyhaní (ako napríklad DBaaS s funkciou Data Guard) a regionálnych služieb (objektový ukladací priestor a streamovanie). Nakoniec treba spomenúť, že zákazníci môžu použiť viacero oblastí na obnovenie po havárii.

Vo všetkých prípadoch môžu zákazníci využiť koncept buniek služby na ďalšiu izoláciu aj tých najzávažnejších problémov, ako je napríklad distribuovaný thrashing.

 
 

Ako spoločnosť Oracle vykonáva údržbu bez toho, aby mal ktorýkoľvek zákazník dočasne nedostupnú ktorúkoľvek z kritických služieb?

Dosahujeme to prostredníctvom chybových domén, buniek služby a našich prevádzkových postupov pre postupné zavádzanie a overovanie. Prečítajte si diskusiu v tomto dokumente.

 
 

Nasadzujú sa služby bezserverovej platformy v rôznych logických dátových centrách v záujme vyššej dostupnosti?

Áno. Všetky kategórie služieb sú za účelom dosiahnutia pružnosti a nepretržitej dostupnosti nasadzované naprieč viacerými logickými dátovými centrami – oddelenými logickými zoskupeniami izolácie chýb a izolácie výkonu.

 
 

Ak nie je pružnosť nakonfigurovaná predvolene, majú zákazníci možnosť nasadenia viacerých logických dátových centier (napríklad konfiguráciu s viacerými doménami dostupnosti alebo konfiguráciu viacerých oblastí)?

Ako sa uvádza v iných častiach tohto dokumentu, v oblastiach s jednou doménou dostupnosti ponúkame chybové domény, ktoré fungujú ako mechanizmus viacerých logických dátových centier.

V oblastiach s viacerými doménami dostupnosti ponúkame služby a funkcie, ktoré poskytujú ešte vyššiu úroveň fyzickej odolnosti synchrónne replikovaných dát (pri miernom výkone a nákladoch z dôvodu vzdialenosti medzi doménami dostupnosti v oblasti a rýchlosti svetla).

Neponúkame mechanizmy automatickej vysokej dostupnosti alebo prepnutia pri zlyhaní naprieč oblasťami, pretože by sa tým vytvoril úzky vzťah medzi oblasťami a vzniklo by riziko, že sa môžu vyskytnúť problémy vo viacerých oblastiach súčasne. Namiesto toho umožňujeme rôzne formy asynchrónnej replikácie medzi oblasťami a ponúkame rozrastajúci sa zoznam funkcií, ako napríklad asynchrónne kopírovanie a zálohovanie, ktoré umožňujú obnovenie po havárii naprieč oblasťami.

 
 

Ako pomáha spoločnosť Oracle zákazníkom vyhnúť sa korelovanému zlyhaniu aplikácií spôsobenému vnútornými závislosťami medzi rôznymi službami infraštruktúry a platformy?

Je to zložitá otázka, takže aby sme ju objasnili, preformulujeme ju niekoľkými rôznymi spôsobmi:

  • Ak chce zákazník použiť dve služby Oracle (službu A a službu B) na vytvorenie pružnej aplikácie, musí v prípade, že niektorá z týchto služieb zlyhá, vedieť, či služba A interne závisí od služby B? Vedú interné závislosti vo významnej miere ku korelovanému zlyhaniu? Ak áno, potom je možné, že zákazník potrebuje vedieť o takýchto interných závislostiach, aby sa mohol rozhodnúť, ako pri budovaní vlastných mechanizmov pružnosti na aplikačnej úrovni inak využije služby A a B, alebo či má miesto toho pre tieto dodatočné prípady vyžiadať nesúvisiacu službu C.
  • Ako sa môže zákazník najlepšie brániť proti akémukoľvek korelovanému zlyhaniu služieb Oracle?

Odpoveď je rozdelená na dve časti.

Architektonické princípy

Používame architektonické princípy, ktoré výrazne znižujú korelované zlyhanie naprieč závislými službami. V niektorých prípadoch táto technika znižuje pravdepodobnosť korelovaného zlyhania do takej miery, že ho možno z hľadiska splnenia dohody o úrovni poskytovaných služieb dostupnosti ignorovať.

Používame najmä bunky služby, ako je opísané vyššie v tomto dokumente. Bunky pomáhajú s týmto problémom, pretože ak je interná služba A ovplyvnená problémom v jednej zo svojich závislostí (služba B), potom je problém so službou B pravdepodobne obmedzený na jednu bunku. Iné služby vyššej úrovne – a vlastné aplikácie zákazníka – ktoré využívajú službu B, pravdepodobne používajú iné, neovplyvnené bunky. Ide o pravdepodobnostný argument, ktorý sa líši podľa počtu buniek, čo je skrytý interný parameter, ktorý sa mení (zvyšuje), takže nad rámec samostatných dohôd o úrovni poskytovaných služieb A a B sa neposkytuje žiadna kvantifikácia ani záruka. V praxi to však môže výrazne dekorelovať zlyhania medzi službami.

Mnohé z našich zdieľaných interných služieb – napríklad služby toku činností a metadát pre kontrolné vrstvy a služba na streamovanie/posielanie správ – používajú bunky služby na dekoreláciu výpadkov spravovaných služieb, ktoré ich využívajú.

Závislosti

Nasledujúce usmernenia sú na úrovni prehľadu, pretože implementácia na nízkej úrovni a podrobnosti o službách sa môžu meniť a aj sa menia. Pre kľúčové dimenzie výpočtov, ukladania, sieťových služieb a autentifikácie/autorizácie však uvádzame nasledujúce závislosti.

V prípade kontrolných vrstiev sú spoločné závislosti nasledovné:

  1. Dátová vrstva identita/platforma pre autentifikáciu a autorizáciu
  2. Služba sledovania auditu
  3. Interné služby, ktoré poskytujú napríklad tok činností, ukladanie metadát a protokolovanie
  4. Zariadenia na vyrovnávanie záťaže rôznych typov

Niektoré kontrolné vrstvy sú, samozrejme, závislé od špecifických služieb. Napríklad kontrolná vrstva computingu pri spúšťaní inštancie servera Bare Metal alebo virtuálneho počítača závisí od nasledujúcich faktorov:

  • objektový ukladací priestor (na získanie zadaného obrazu operačného systému),
  • kontrolná vrstva blokových zväzkov (na poskytnutie a pripojenie spúšťacieho zväzku),
  • kontrolná vrstva sieťových služieb (na poskytnutie a pripojenie virtuálnych sieťových kariet).

Všeobecným princípom pre dátové vrstvy základných služieb je, že každá dátová vrstva je zámerne navrhnutá tak, aby mala minimálne závislosti, čím sa dosiahne vysoká dostupnosť, rýchly čas diagnostiky a rýchly čas obnovenia. Výsledky tohto princípu sú nasledovné:

  • Dátová vrstva sieťových služieb je sebestačná.
  • Dátová vrstva blokových zväzkov je sebestačná.
  • Servery Bare Metal computingu a inštancie virtuálnych počítačov závisia od dátovej vrstvy blokových zväzkov (pre spúšťacie zväzky) a dátovej vrstvy sieťových služieb.
  • Dátová vrstva objektového ukladacieho priestoru závisí pri autentifikácii a autorizácii od dátovej vrstvy identity/platformy (kvôli predpokladom odvetvia). Dátová vrstva objektového ukladacieho priestoru nezávisí od blokových zväzkov ani ukladacieho priestoru súborov.
  • Všetky služby, ktoré podporujú zálohovanie a obnovenie, sú pre danú funkciu závislé od dátovej vrstvy objektového ukladacieho priestoru.

Všeobecným princípom pre dátové vrstvy IaaS je závisieť len od základných dátových vrstiev alebo dátových vrstiev nižších úrovní (aby sa zabránilo cyklickým závislostiam).

  • Viacuzlová databázová konfigurácia RAC závisí od dátovej vrstvy sieťových služieb a dátovej vrstvy blokových zväzkov.
  • Container Engine for Kubernetes samozrejme závisí od služby Kubernetes a jej tranzitívnych závislostí (napríklad etcd) a dátovej vrstvy sieťových služieb.
  • Všetka podpora pre zálohovanie a obnovenie závisí od dátovej vrstvy objektového ukladacieho priestoru.

1Verejný výskumný program z univerzít Stanford a Berkeley, vedený Armandom Foxom a Daveom Pattersonom

 
×
Zavolajte nám
1-800-633-0738 (USA)

Kontakt
×
Zavolajte nám
1-800-633-0738 (USA)


Diskusné fóra služieb Oracle Cloud