Felelősség kizárása

Az alábbiakban termékirányításunk általános jellemzőit foglaljuk össze. Ez kizárólag tájékoztatásul szolgál, és semmilyen módon nem foglalható szerződésbe. Nem jelent felelősségvállalást bármely anyag, kód vagy funkcionalitás megvalósítására, és nem szolgálhat hivatkozási alapként a beszerzési döntések meghozatalánál. Az Oracle termékeinél ismertetett jellemzők vagy funkciók fejlesztése, kiadása, időzítése és árképzése változhat, és ez szigorúan az Oracle Corporation döntési körébe tartozik.

Ebben a szakaszban olyan általános kérdésekre találhatók válaszok, hogy az Oracle hogyan éri el a rugalmasságot és a folyamatos rendelkezésre állást az infrastruktúra alapvető szolgáltatásainál és az üzemeltető platformnál. Az Oracle Cloud ügyfeleit számos okból érdekelhetik ezek a válaszok:

  • Segítik abban az ügyfeleket, hogy kellő körültekintéssel járjanak el az Oracle üzemeltető platformjának és szolgáltatásainak elérésekor.
  • Számos válasz foglalkozik a valamennyi felhőalapú rendszernél lényeges kihívásokkal és megoldásokkal, így tájékoztatást nyújthatnak azon rendszerek architektúrájáról és kialakításáról, amelyeket az ügyfelek ki szeretnének építeni a felhőben.

Az Oracle Cloud Infrastructure szolgáltatásainak és platformjának rugalmassága és folyamatos rendelkezésre állása – Gyakori kérdések

Különbséget tesz-e az Oracle a különböző szolgáltatásosztályok között, például alapvető fontosságú szolgáltatások, folyamatosan rendelkezésre álló szolgáltatások vagy egyetlen helyen futó szolgáltatások?

Nem teszünk ilyen megkülönböztetéseket. Ehelyett szolgáltatásainkat függőségi szint, a rendelkezésre állás hatóköre és adatsík vagy vezérlősík összevetés szerint kategorizáljuk. Ezek a kategóriák azért lettek kialakítva, hogy különféle hasznos kompromisszumos megoldásokat biztosítsanak a rendelkezésre állás, a tartósság, a teljesítmény és a megfelelés között.

Függőségi szintek

Ezek a szintek rétegként vagy fokozatként foghatók fel egy architekturális blokkdiagramon. Minden réteg kizárólag az alatta lévő rétegektől függhet.

Alulról fölfelé:

  • Alapvető szolgáltatások: ezek a szolgáltatások képezik az Oracle Cloud Infrastructure alapját. Ezek a következők: Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry és számos megosztott belső szolgáltatás. Úgy lettek kialakítva, hogy minimális függőséggel rendelkezzenek, lehetőleg még egymás között se. (Lásd később a dokumentum függőségeket ismertető részét.)
  • IaaS: ez a réteg további olyan infrastruktúra szintű funkciókat biztosít, amelyek az alaprétegre épülnek. A réteg szolgáltatásai közé tartozik a File Storage, a Database és a Container Engine for Kubernetes.
  • SaaS: ez a réteg az alsóbb rétegekre épülő szolgáltatott szoftver.
Rendelkezésre állás hatóköre

A szolgáltatásoknál a rendelkezésre állás és a tartósság céljának eléréséhez a következő rendelkezésre állási hatókörök valamelyikét választják minden szolgáltatásnál:

  • Rendelkezésre állási tartomány – helyi: minden rendelkezésre állási tartomány tartalmazza a szolgáltatás egy független példányát. Az ilyen szolgáltatások a tárolt adatok kiemelkedő tartósságát kínálják a replikák közötti szinkron módú replikálás használatával ugyanazon rendelkezésre állási tartományon belül (a részleteket lásd a dokumentum tartalék tartományokat ismertető későbbi szakaszában). Ezek a szolgáltatások elviselik a rendelkezésre állási tartományban az infrastruktúra harmadának vagy nagyobb részének kiesését, ez a szolgáltatás jellegétől függ. A rendelkezésre állási tartomány helyi szolgáltatásai a hibatűrés ilyen szintjét a rendelkezésre állási tartományon belül a logikai adatközpont két különböző típusának használatával érik el – hibaelkülönítés és teljesítményelkülönítés logikai csoportja. A részleteket lásd a dokumentum tartalék tartományokkal és a szolgáltatáscellákkal foglalkozó későbbi szakaszában. Végül: ezek a szolgáltatások a szokásos módon folytatni tudják a működést akkor is, ha a rendelkezésre állási tartomány nem képes kommunikálni egyetlen másik rendelkezésre állási tartománnyal sem. Ily módon ezek a szolgáltatások elviselik a másik rendelkezésre állási tartományok kiesését a vagy a régión belül a nagykiterjedésű hálózat teljes hibáját.
  • Több rendelkezésre állási tartomány – regionális: a több rendelkezésre állási tartománnyal rendelkező minden régió tartalmazza a szolgáltatás egy független példányát, emellett az összetevők megtalálhatók az adott régió minden rendelkezésre állási tartományában. Ezek a szolgáltatások a tárolt adatok rendkívüli tartósságát kínálják szinkron módú replikálás használatával ugyanazon régió több rendelkezésre állási tartományában. Ezek a szolgáltatások elviselik a tartományban lévő egyetlen rendelkezésre állási tartomány kiesését vagy az azzal való kommunikáció megszakadását.
  • Egyetlen rendelkezésre állási tartomány – regionális: ha a régió csak egyetlen rendelkezésre állási tartományt tartalmaz, a regionális szolgáltatás alapvető jellemzői megegyeznek a rendelkezésre állási tartomány helyi szolgáltatásánál korábban megismertekkel. A rendelkezésre állási tartomány helyi szolgáltatása és az egyetlen rendelkezésre állási tartomány regionális szolgáltatása közötti megkülönböztetés csak akkor válik fontossá, ha az egyetlen rendelkezésre állási tartományt tartalmazó régiót egy vagy több rendelkezésre állási tartománnyal bővítik. Ebben az esetben minden regionális szolgáltatás működése automatikusan az új rendelkezésre állási tartományok megfelelő használatával egészül ki, de megmarad a szolgáltatás egyetlen példányának. Például az Object Storage adatsíkja a további rendelkezésre állási tartományok használatával bővülhet a meglévő adatok tartósságának javítása érdekében. A rendelkezésre állási tartomány helyi szolgáltatásainál viszont minden új rendelkezésre állási tartomány megkapja az egyes helyi szolgáltatások saját új és különálló példányát.
  • Régiók között elosztva: az Oracle Cloud Infrastructure alapelve, hogy minden régió működése a lehető legnagyobb mértékben független legyen a többi régiótól. A lehető legnagyobb mértékben megszorítás arra a tényre utal, hogy a régióknak feltétlenül meg kell osztaniuk egymással bizonyos infrastruktúrát, például a régiók közötti gerinchálózatot. Egyébként nem alakítunk ki szoros csatolású mechanizmusokat a régiók között, ilyen például a transzparens magas rendelkezésre állás vagy a feladatátvétel, ami több régiót egyidejűleg érintő problémákat okozna. Ehelyett a szolgáltatások régiók közötti elosztásához két laza csatolású mechanizmust biztosítunk:
    • Vészhelyreállítás (DR): ügyfeleinknek DR jellemzőkkel rendelkező rendszerek kialakításának lehetővé tétele felhőbeli megoldásunk és beruházásunk alappillére. Számos alapvető szolgáltatás már kínál DR mechanizmusokat – ilyen például a Block Volumes régiók közötti biztonsági mentése és az Object Storage régiók közötti másolása. Fejlesztési tervének magas prioritású elemeként valamennyi szolgáltatásunk rendelkezik DR funkcióval.
    • Régiók közötti előfizetések: ezt a funkciót jelenleg csak az IAM adatainál biztosítjuk. Fogalmilag az IAM adatai globális hatókörrel rendelkeznek. Az ügyfelek feliratkozhatnak (jóváhagyás) a régiók készletére, és mi automatikusan replikáljuk az IAM megfelelő adatait és a későbbi frissítéseket a megadott régiókba. A szoros csatolás elkerülése érdekében a replikálás aszinkron módon történik és lényegében következetes. Az ügyfelek IAM adataik módosítását az általuk kijelölt „saját” régióban hajtják végre. Ha az aktuális saját régió elérhetetlenné vagy valamilyen okból alkalmatlanná válik, másik régiót lehet megnevezni.
Vezérlősík vagy adatsík

A szolgáltatás adatsíkja olyan adatfeldolgozási felületek és összetevők gyűjteménye, amelyek az alkalmazások által használni kívánt szolgáltatás funkcióit valósítják meg. Például a felhőalapú virtuális hálózat (VCN) adatsíkja tartalmazza a hálózati csomagok feldolgozó rendszerét, a virtualizált útválasztókat és átjárókat, míg a Block Volumes adatsíkja tartalmazza az iSCSI protokoll megvalósítását és a hibatűrő replikált tárolórendszert a kötetadatokhoz.

A szolgáltatás vezérlősíkja a következő feladatokért felelős API felületek és összetevők készlete:

  • Erőforrások előkészítésére, újrakonfigurálására, méretezésére és megszüntetésére vonatkozó ügyfélkérelmek kezelése
  • Nagy állományok automatikus javításának végrehajtása gyorsan és biztonságosan
  • Hibás, csökkent teljesítményű és helytelenül konfigurált erőforrások észlelése
  • Automatikus javítás végrehajtása vagy segítségül személyes kezelő keresése
  • Együttműködés más vezérlősíkokkal (például a Compute, VCN, Block Storage összekapcsolása LaunchInstance esetében)
  • Kihasználatlan kapacitás kezelése
  • Koordinálás az emberekkel, például új berendezés érkezésekor, fizikai javításkor és karbantartáskor
  • A műveletek átláthatóságának és felügyeletének biztosítása
 
 

Hogyan biztosítja az Oracle a szolgáltatások rugalmasságát és folyamatos elérhetőségét?

A szolgáltatások valamennyi típusánál a műszaki alapelvek ugyanazon készletét használjuk a rugalmasság és a rendelkezésre állás eléréséhez, hiszen hibatűrő, méretezhető, elosztott rendszerek alapvető műszaki kihívásai az összes szolgáltatástípusnál azonosak.

A rugalmasság és a folyamatos rendelkezésre állás eléréséhez elengedhetetlen megismerni majd foglalkozni az elérhetetlenség – csökkent teljesítmény és nem kezelt hibák – valamennyi okával a felhőalapú rendszerekben. Az ilyen okok száma szinte végtelen, ezért alapvető jellegük szerint kategóriákba soroltuk ezeket.

A vállalati informatikai rendszerek elérhetőségének elemzése hagyományosan a hardverhiba kategóriára összpontosít. A felhőalapú rendszereknél azonban a hardverhiba viszonylag csekély jelentőségű és jól kezelt probléma. Jelenleg aránylag egyszerűen elkerülhetők vagy csökkenthetők a hardverhibára érzékeny pontok. Például az állványok kettős tápellátással és kapcsolódó tápelosztó rendszerrel rendelkezhetnek, valamint számos összetevő üzem közben cserélhető. Jelentős hardverhiba vagy kiesés természetesen lehetséges – például természeti katasztrófa következtében. Tapasztalatunk és más felhőszolgáltatók nyilvános kiértékelő jelentései alapján azonban nyilvánvaló, hogy a teljes adatközpont hibája vagy kiesése rendkívül ritkán fordul elő az elérhetetlenség más okaihoz viszonyítva. A nagymérvű hardverhibát természetesen kezelni kell (például vészhelyreállítással vagy más mechanizmussal), de ez messze nem a domináns rendelkezésre állási probléma.

A felhőalapú rendszerekben az elérhetetlenség leggyakoribb okai a következők:

  1. Szoftverhibák
  2. Konfigurációs hibák
  3. Kezelők emberi hibái
    Megjegyzés: az iparágból származó alapvető tanulság, hogy az emberi hibák ezen formái vitathatatlanul az elérhetetlenség legfőbb okai. Bár ezek gyakorisága csökkenthető eszközökkel, automatizálással és képzéssel, de teljesen nem küszöbölhetők ki. Ezért ezeket kiemelten kell kezelni a rendszer architektúrájánál, kialakításánál és megvalósításánál.
  4. Elfogadhatatlan változás a teljesítményben (késés vagy átviteli sebesség) bármilyen okból, beleértve a következőket:
    • Több-bérlős „zajos szomszédok” (a QoS mechanizmus hibája)
    • Véletlen vagy rosszindulatú túlterhelés hatékony elutasításának hiánya hasznos munkavégzés közben
    • Elosztott szemét, üzenetroham, újrapróbálkozási roham és más költséges „hirtelen megjelenő” kapcsolati tevékenységek
    • Hidegsokk (üres gyorsítótárak) ki- és bekapcsolás után, különösen több rendszer egyidejű ki- és bekapcsolása után
    • Többletterhelés a rendszer méretezésekor (például horizontális újraskálázás)
  5. Az „ártalmas hatósugár” (érintett ügyfelek és rendszerek száma) sikertelen korlátozása bármelyik előző problémánál

Ezek a kihívások általános érvényűek – a felhőalapú elosztott rendszereknél ezek a „fizikai alaptörvényei” közé tartoznak.

Az előző kategóriák mindegyikénél bizonyítottan megfelelő műszaki stratégiákat alkalmazunk a probléma megoldásához. Ezek közül a legfontosabbak a következők:

  • Az architektúra- és a rendszertervezés alapelvei
  • Az architektúra új megoldásai (ezek jellemzően az alapelvek alkalmazásából adódnak)
  • Szolgáltatáskialakítási eljárások
Az architektúra- és a rendszertervezés alapelvei

Az alapelvek közül számos már létezik, de a rugalmasság és a rendelkezésre állás szempontjából legfontosabbakra összpontosítunk.

Helyreállítás-orientált számítástechnika

A szoftverhibák és az emberi tévedések – amelyek viszonylag korlátozott hatásúak – kezelésénél a helyreállítás-orientált számítástechnika1 alapelveit követjük. Magas szinten ez azt jelenti, hogy ahelyett hogy megkísérelnénk garantálni, hogy soha nem ütközünk problémába (amit lehetetlen tesztelni), inkább a problémák diszkrét kezelésére összpontosítunk oly módon, ami tesztelhető. Különösen a helyreállításig eltelt átlagos idő (MTTR) erőteljes csökkentésére összpontosítunk, amely az észlelésig eltelt átlagos idő, a diagnosztizálásig eltelt átlagos idő és a problémamegoldásig eltelt átlagos idő kombinációja.

Célunk az, hogy a helyreállítás olyan gyors legyen, hogy a felhasználóknak ne okozzon kellemetlenséget a probléma. A cél elérésében a következő pontok nyújtanak segítséget:

  • A hibákra és az emberi tévedésekre utaló jelek gyors és automatikus észlelése a helyességi feltételek széles körű használatával a kódban, valamint aktív figyeléssel és riasztással minden szinten.
  • A funkciók szétosztása számos különálló, részletes elkülönítési egységekbe (szálak, folyamatok, száloptikák, állapotgépek stb.), amelyek laza csatolásúak, azaz közvetlenül nem osztoznak memórián, ami sérültté válhat.
  • A hibákra és az emberi tévedésekre utaló jelek észlelésekor az érintett elkülönítési egység lehető leggyorsabb automatikus újraindítása. Az újraindítás célszerű módszer a tetszőleges hibából való helyreállításra, mivel megfelelően tesztelt állapotot kísérel meg újból beállítani, és így visszaállítja az állandókat.
  • Ha az elkülönítés részletes szintjén nem működik a helyreállítás (például a helyességi feltételek az adott szinten továbbra is túl gyakran hibát jeleznek, így gyors összeomlást okozva), kiterjesztés a következő nagyobb egységre (folyamat, futtatókörnyezet, gazdagép, logikai adatközpont, személyes kezelő keresése).
  • Mechanizmusok kialakítása „rendszerszintű visszavonás” engedélyezéséhez, beleértve az összes állandósult állapot és konfiguráció verziókövetését, így gyorsan azonosíthatók és visszavonhatók a hibás végrehajtások.

A problémák hatásainak minimálisra csökkentése

A szélesebb körű hatásokkal rendelkező hibák és emberi tévedések kezeléséhez mechanizmusokat alakítunk ki az egyes problémák „ártalmas hatósugarának” lehető legkisebbre csökkentésére. Azaz arra összpontosítunk, hogy minimálisra csökkentsük az egyes problémák által érintett ügyfelek, rendszerek és erőforrások számát, beleértve a különösen nagy kihívást okozó problémákat, például több-bérlős „zajos szomszédok”, felajánlott túlterhelés, csökkent teljesítmény és elosztott szemét. Ennek eléréséhez különféle elkülönítési határokat és változáskezelési megoldásokat használunk (lásd a következő szakaszokban).

Az architektúra tervezési alapelvekből adódó alapfogalmai

A fogalmak közül számos már létezik, de most az ártalmas hatósugár korlátozására összpontosítunk.

Legfontosabb elhelyezési fogalmak nyilvános API felületünkön: régiók, rendelkezésre állási tartományok és tartalék tartományok

Mivel a tartalék tartomány viszonylag új fogalom, ezt részletesebben ismertetjük.

A tartalék tartományok az ártalmas hatósugár korlátozására szolgálnak olyan problémáknál, amelyek a rendszer tényleges módosításakor fordulnak elő – például telepítések, javítás, hipervizori újraindítás és fizikai karbantartás során.

A garanciát az jelenti, hogy adott rendelkezésre állási tartománynál bármely időpontban az erőforrások legfeljebb egy tartalék tartományban módosulnak. Ha valamilyen hiba történik a módosítási folyamatnál, az adott tartalék tartományban néhány vagy az összes erőforrás egy időre elérhetetlenné válhat, de a rendelkezésre állási tartományban lévő többi tartalék tartományt ez nem érinti. Minden rendelkezésre állási tartomány legalább három tartalék tartományt tartalmaz, hogy lehetőség legyen kvórum alapú, nagy rendelkezésre állású replikációs rendszerek (például Oracle Data Guard) üzemeltetésére egyetlen rendelkezésre állási tartományon belül.

Ily módon a rendelkezésre állási problémák – a módosítási eljárások során előforduló szoftverhibák, konfigurációs hibák, emberi tévedések és teljesítményproblémák – domináns kategóriájánál minden tartalék tartomány különálló logikai adatközpontként működik a rendelkezésre állási tartományon belül.

A tartalék tartományok emellett védelmet biztosítanak az azonosított hardverhibák bizonyos fajtái ellen is. A tartalék tartományok tulajdonságai garantálják, hogy a különböző tartalék tartományokban elhelyezett erőforrások gyakorlatilag nem osztoznak a rendelkezésre állási tartományon belüli egyetlen hardverhibára érzékeny ponttal sem. a különböző tartalék tartományokban lévő erőforrások nem osztoznak ugyanazon „állvány tetején lévő” hálózati kapcsolón, mert az ilyen kapcsolók szabványos kialakításánál hiányzik a redundancia.

A tartalék tartományok azon képessége azonban, hogy védelmet nyújtanak a hardverben vagy a fizikai környezetben előforduló problémákkal szemben, az adott helyi szinten véget ér. A rendelkezésre állási tartományokkal és a régiókkal ellentétben a tartalék tartományok nem biztosítják az infrastruktúra jelentős fizikai elkülönítését. A természeti katasztrófa vagy az infrastruktúra teljes rendelkezésre állási tartományt érintő hibájának rendkívül ritka esetében a több tartalék tartományban lévő erőforrások valószínűleg egyidejűleg érintettek lesznek.

Belső szolgáltatásaink ugyanúgy használják a tartalék tartományokat, ahogy az ügyfeleknek kell használniuk ezeket. Például a Block Volumes, az Object Storage és a File Storage szolgáltatás az adatok replikáit tárolja három különálló tartalék tartományban. Az összes vezérlősík és adatsík valamennyi összetevője üzemel mindhárom tartalék tartományban (illetve a több rendelkezésre állási tartományt tartalmazó régiókban minden rendelkezésre állási tartományban).

Szolgáltatáscellák

A szolgáltatáscellák az ártalmas hatósugár korlátozására szolgálnak olyan problémáknál, amelyek nem a rendszer tényleges módosításakor fordulnak elő. Ilyen problémák azért merülhetnek fel, mert a több-bérlős felhőalapú rendszerek munkaterhelése bármikor szélsőséges módon változhat, valamint mert összetett részleges hibák bármikor előfordulhatnak a nagy elosztott rendszerekben. Ezek az esetek nehezen észlelhető rejtett hibákat és „hirtelen megjelenő” teljesítményproblémákat válthatnak ki.

Emellett a szolgáltatáscellák korlátozzák az ártalmas hatósugarat egyes ritka, de nagy kihívást jelentő esetekben is, amikor a rendszer tényleges módosítása történik. Klasszikus példa erre, amikor egyedi tartalék tartományra való telepítés sikeresnek tűnik – nincs hiba vagy teljesítményváltozás –, de a második vagy az utolsó tartalék tartomány módosítása után a rendszeren belüli új kapcsolati tevékenységek (teljes felhő éles környezeti munkaterheléssel) teljesítményproblémát okoznak.

Fontos tudni, hogy a szolgáltatáscellák használata architekturális minta, és nem az Oracle Cloud API felületén vagy SDK készletében kifejezetten elnevezett fogalom. Bármely több-bérlős rendszer használhatja ezt a mintát, ehhez nem szükséges a felhőalapú platform különleges támogatása.

A szolgáltatáscellák működése a következő:

  • A szolgáltatás minden példánya (például adott régióban vagy adott rendelkezésre állási tartományban a rendelkezésre állási tartomány helyi szolgáltatásainál) a szolgáltatás szoftverkészletének több különálló telepítéséből áll. Minden különálló telepítés elnevezése cella. Minden cella – amennyire ez gyakorlatilag megvalósítható – saját infrastruktúrán üzemel. Legalábbis a cellák nem osztoznak gazdagépeken és virtuális gépeken.
  • A szolgáltatás kezdetben néhány cellát tartalmazhat minden egyes rendelkezésre állási tartományban vagy régióban. Amint a szolgáltatás bővül a növekvő igények kielégítésére, további cellák felvételére kerül sor a lehetséges problémák ártalmas hatósugara méretkorlátjának fenntartása érdekében. A nagy, népszerű szolgáltatások számos cellával rendelkezhetnek. Más szavakkal: a cellák az ügyfél munkaterheléseinek n-m arányú multiplexelését biztosítja az üzemeltetési környezetek elkülönítéséhez – ezek az erőforrás-elkülönítés különálló szigetei. A cellák nem rendelkeznek olyan nyilvánvaló számossággal, ahogy az a tartalék tartományoknál létezik. (Korábban szó volt arról, hogy a tartalék tartományok számosságának nyilvánvaló választása három rendelkezésre állási tartományonként, hogy lehetőség legyen kvórum alapú replikációs rendszerek üzemeltetésére egyetlen rendelkezésre állási tartományon belül.)
  • Az ügyfél munkaterhelésének minden „természetes egysége” hozzá van rendelve adott cellához. A „természetes egység” definíciója az adott szolgáltatás jellegétől függ. Például belső megosztott Workflow szolgáltatásunknál (ismertetését lásd később) a természetes egység a következő lehet: „az adott rendelkezésre állási tartományban vagy régióban lévő összes munkafolyamat adott vezérlősíknál”.
  • A cellák minden csoportja előtt egy minimalista irányítási réteg vagy API található a cellavégpontok észleléséhez. Például a Streaming/Messaging rendszer API felülettel rendelkezik az adatsík aktuális végpontjának felderítéséhez adott témakörnél, és a belső Metadata tár cellánként különálló végponttal rendelkezik. Más cella alapú szolgáltatások azonban az adatsík egyetlen végpontjával és megosztott irányítási réteggel rendelkeznek. Az irányítási réteg több cella kapcsolódó hibájának lehetséges oka lehet, de ez mérsékelhető az irányítási réteg rendkívül egyszerűen, kiszámíthatóan és nagy teljesítményűen tartásával (nincs költséges művelet), valamint nagy belső kapacitással, kifinomult QoS kvótával és szabályozási mechanizmussal való előkészítéssel.
  • A szolgáltatás tulajdonosa szükség szerint áthelyezheti a munkaterheléseket az egyik cellából egy másikba. Néhány példaként szolgáló eset a következő:
    • A több-bérlős „zajos szomszédok” probléma elkerülésének elősegítése a jelentős munkaterhelés áthelyezésével, hogy a cella többi felhasználóját ez ne érintse.
    • Olyan túlterhelésből vagy kiesésből való helyreállítás elősegítése, amelyet vélhetőleg elosztott szolgáltatásmegtagadásos támadás okozott. Kvóta és szabályozási mechanizmusokkal rendelkezünk az ilyen támadások elleni védekezésre, de időnként olyan peremhálózati esetek fordulnak elő, amelyekben adott használati eset (API, hozzáférési minta) sokkal intenzívebb a szolgáltatásra, mint amit a kvóta és a szabályozó rendszer jelenleg értelmezni képes. A cellák mechanizmust biztosítanak a rövid távú mérséklésre.
    • Az alapvető fontosságú munkaterhelések elkülönítése különböző cellákba a kapcsolódó hiba valószínűségének jelentős csökkentéséhez. Például belső megosztott Workflow szolgáltatásunkban a vezérlősíkoknál a „kritikus maghoz” tartozó vezérlősíkok (például Platform, Compute, Networking és Block Volumes) mindegyike különböző cellákhoz van hozzárendelve, így jelentősen kisebb a kapcsolódó hiba előfordulásának esélye, mintha nem használnának cellákat, vagy ha ugyanazon cellához lennének hozzárendelve.
      Megjegyzés: a cellák ilyen használata csökkenti annak igényét, hogy az ügyfeleknek fontolóra kelljen venniük a szolgáltatások belső függőségeit rugalmas alkalmazások kialakításához. A függőségi grafikon vizsgálata továbbra is javasolt módszer (erről lásd a dokumentum későbbi részét), de ez kevésbé szükséges, ha a szétválasztási mechanizmus már aktív.

Ennek eredményeként minden szolgáltatáscella még a „logikai adatközpont” másik típusa is – a teljesítményelkülönítés és hibaelkülönítés logikai csoportosítása – egyetlen rendelkezésre állási tartományon vagy régión belül.

Összegezve: a szolgáltatáscellák és a tartalék tartományok a következő módon egészítik ki egymást:

  • A tartalék tartományok olyan problémák ellen nyújtanak védelmet, amelyek a rendszer tényleges módosításakor fordulnak elő.
  • A szolgáltatáscellák az ártalmas hatósugarat korlátozzák, amikor a rendszer potenciálisan súlyos problémákat észlel – függetlenül attól, hogy a rendszer tényleges módosítása történik-e vagy sem.

Telepítések és javítás végrehajtásakor a tartalék tartományok és a szolgáltatáscellák tulajdonságait egyesítjük egységes stratégiába.

Szolgáltatáskialakítási eljárások

Mivel a tesztelési és a működési tökéletesség egyaránt alapvető fontosságú a felhőalapú rendszerek megbízhatósága szempontjából, számos műszaki eljárással rendelkezünk. Az alábbiakban a fontosabbak közül sorolunk fel néhányat, amelyek az előző szakaszban említett fogalmakat hasznosítják:

  • A szolgáltatásokat növekményes módon telepítjük a lépések közötti alapos érvényesítéssel és visszamenőleges javítással, ha bármilyen váratlan történik. Ténylegesen a folyamat a következő:
    • Minden rendelkezésre állási tartományban egyidejűleg egy szolgáltatáscellába telepítünk. Minden cellánál egyidejűleg egy tartalék tartományba telepítünk mindaddig, míg be nem fejezzük az összes tartalék tartományt az adott cellánál. Ezután áttérünk az adott rendelkezésre állási tartomány következő cellájára.
    • A telepítés minden lépése után (minden tartalék tartomány és cella után) ellenőrizzük, hogy a változtatás a kívánt módon működik – azaz nincs teljesítménycsökkenés, és nem keletkeztek belső vagy külső hibák. Ha bármilyen helytelen vagy váratlan esemény történik, visszagörgetjük a változtatást. Nagy hangsúlyt helyezünk a visszagörgetési eljárások előkészítésére és tesztelésére (az automatikus tesztelést is beleértve), az olyan változtatásoknál is, amelyek az állandósult állapot vagy a sémákat érintik.
    • Ily módon minden régiónál a változtatást egyidejűleg egy rendelkezésre állási tartományban telepítjük. Adott tartomány összes régiójába oly módon telepítünk, hogy egyidejűleg nem módosítjuk olyan régiók párosítását, amelyeket az ügyfelek elsődleges és vész-helyreállítási helyként használhatnak.
  • Rendszeres időközönként ellenőrizzük a hibakezelési mechanizmusok és más kockázatcsökkentő intézkedések várt módon való működését, és nem engedjük a probléma továbbterjedését. Az ilyen tesztelés nélkül gyakori, hogy a hibakezelési mechanizmusok (például újrapróbálkozások, összeomlás utáni helyreállítási algoritmusok és állapotgépet újrakonfiguráló algoritmusok) hibákat fognak tartalmazni, túl költségessé válnak, vagy váratlan módon működnek együtt, és így elosztott szemét vagy más súlyos teljesítményproblémát okoznak.
  • Ellenőrizzük képességünket a legutóbbi ismert helyes szoftver és konfiguráció gyors és biztonságos visszaállításának végrehajtására, beleértve a korábban ismertetett állandósult állapotot és sémát is.
 
 

Az Oracle több rendelkezésre állási tartományt tartalmazó régióiban az összes alapvető fontosságú szolgáltatás el van osztva a rendelkezésre állási tartományok között?

Igen. Minden régióban az összes rendelkezésre állási tartomány a szolgáltatások ugyanazon készletét kínálja.

 
 

Hogyan tudja az Oracle és ügyfele elkerülni, hogy olyan alapvető fontosságú szolgáltatással rendelkezzen, amely egyetlen logikai adatközponttól függ?

Az egyetlen rendelkezésre állási tartományt tartalmazó régiókban az ügyfelek tartalék tartományokat (logikai csoportok nem kapcsolódó hibaállapotokkal) használhatnak a különálló „logikai adatközpontok” szinte valamennyi tulajdonságának eléréséhez. Az ügyfelek emellett több régiót használhatnak vészhelyreállításra (DR).

A több rendelkezésre állási tartományt tartalmazó régiókban az ügyfelek tartalék tartományokat használhatnak ugyanilyen módon. Az ügyfelek emellett használhatják a rendelkezésre állási tartomány helyi szolgáltatásainak, a rendelkezésre állási tartományok közötti feladatátvételi szolgáltatások (például DBaaS és Data Guard), valamint a regionális szolgáltatások (Object Storage, Streaming) kombinációját is átfogó magas rendelkezésre állás eléréséhez a magasabb szintű „logikai adatközpontok” (rendelkezésre állási tartományok) között. Végül az ügyfelek több régiót is használhatnak vészhelyreállításra (DR).

Valamennyi esetben az ügyfelek szolgáltatáscellákat használhatnak akár a legsúlyosabb problémák, például elosztott szemét további elkülönítéséhez.

 
 

Hogyan hajtja végre az Oracle a karbantartási tevékenységeket úgy, hogy az alapvető fontosságú szolgáltatások ideiglenesen sem válnak elérhetetlenné az ügyfelek számára?

Ennek elérése a tartalék tartományok, a szolgáltatáscellák, valamint a növekményes telepítési és érvényesítési eljárásaink segítségével lehetséges. Az ismertetést lásd a dokumentum korábbi részében.

 
 

A kiszolgáló nélküli platformszolgáltatások telepítése több logikai adatközpontban történik a még fokozottabb rendelkezésre állás érdekében?

Igen. A rugalmasság és a folyamatos rendelkezésre állás érdekében a szolgáltatások összes kategóriájának telepítése több logikai adatközpontban (hibaelkülönítés és teljesítményelkülönítés logikai csoportja) történik.

 
 

Ha a rugalmasság nem az alapértelmezett konfiguráció, választhatják-e az ügyfelek a több logikai adatközpontos telepítést (például több rendelkezésre állási tartományt érintő vagy régiók közötti konfiguráció)?

Az egyetlen rendelkezésre állási tartományt tartalmazó régiókban tartalék tartományokat kínálunk a „több logikai adatközpont” mechanizmusaként (ezt a dokumentum korábbi részében ismertettük).

A több rendelkezésre állási tartományt tartalmazó régiókban olyan szolgáltatásokat és funkciókat kínálunk, amelyek a szinkron módon replikált adatok fizikai tartósságának még magasabb szintjét biztosítják (mérsékelt teljesítménnyel és áron a rendelkezésre állási tartományok közötti távolság és a fénysebesség miatt).

Nem kínálunk régiók közötti automatikus magas rendelkezésre állási és feladatátvételi mechanizmust, mivel ez szoros csatolású kapcsolatot hozna létre a régiók között, és azzal a kockázattal járna, hogy egyidejűleg több régióban jelentkezhetnének ugyanazok a problémák. Ehelyett lehetővé tesszük a régiók közötti aszinkron módú replikálás különféle formáit, és a régiók közötti vészhelyreállítás végrehajtásához a funkciók egyre bővülő listáját kínáljuk, például aszinkron másolás és biztonsági mentés.

 
 

Hogyan segít az Oracle az ügyfeleknek, hogy elkerüljék az alkalmazások kapcsolódó hibáját, amelyet a különféle infrastruktúra- és platformszolgáltatások közötti belső függőségek okoznak?

Ez bonyolult kérdés, így tisztázásához különböző módokon újrafogalmazzuk:

  • Ha az ügyfél az Oracle két szolgáltatását (A szolgáltatás és B szolgáltatás) kívánja használni, és olyan alkalmazást szeretne kialakítani, amely rugalmas, ha bármelyik szolgáltatásban hiba következik be, akkor az ügyfélnek ismernie kell-e, hogy az A szolgáltatás belsőleg függ-e a B szolgáltatástól? A belső függőségek jelentős mértékben vezetnek-e kapcsolódó hibához? Ha igen, akkor az ügyfélnek szüksége lehet arra, hogy tudjon az ilyen belső függőségekről annak eldöntéséhez, hogy más esetekben használja-e az A és a B szolgáltatást – vagy inkább vonjon be egy kapcsolódó C szolgáltatást a további eseteknél –, amikor saját rugalmassági mechanizmusait alakítja ki az alkalmazás szintjén.
  • Hogyan védekezhet az ügyfél legjobban az Oracle szolgáltatások kapcsolódó hibái ellen?

A válasz két részből áll.

Az architektúra alapelvei

Az architektúrával kapcsolatban olyan alapelveket alkalmazunk, amelyek jelentősen csökkentik a kapcsolódó hibát a függő szolgáltatásoknál. Egyes esetekben ez a módszer olyan mértékben csökkenti a kapcsolódó hiba valószínűségét, hogy az figyelmen kívül hagyható a rendelkezésre állásra vonatkozó szolgáltatásiszint-szerződésnek (SLA) való megfelelés szempontjából.

Különösen fontos a dokumentumban korábban ismertetett szolgáltatáscellák használata. A cellák azért segítenek a probléma megoldásában, mert ha a belső A szolgáltatás érintett valamelyik függőségében, például a B szolgáltatásban lévő problémában, akkor a B szolgáltatással kapcsolatos probléma nagy valószínűséggel egyetlen cellára korlátozódik. Más magasabb szintű szolgáltatások – és az ügyfél saját alkalmazásai –, amelyek a B szolgáltatást használják, valószínűleg más, nem érintett cellákat használnak. Ez valószínűségi argumentum, amely a cellák számával változik, amely viszont rejtett belső paraméter, és változik (növekszik), így az A és a B szolgáltatáshoz tartozó önálló SLA szerződésen kívül nem adható mennyiségi meghatározás vagy garancia. A gyakorlatban azonban ez többnyire a szolgáltatások között nem kapcsolódó hibát jelent.

Számos megosztott belső szolgáltatásunk – például a Workflow és a Metadata szolgáltatás a vezérlősíkoknál, valamint a Streaming/Messaging szolgáltatás – szolgáltatáscellákat használ a kiesések leválasztásához az ezeket használó felsőbb rétegbeli szolgáltatásoknál.

Függőségek

A következő útmutató magas szintű, mivel a szolgáltatások alacsony szintű megvalósítása és részletei változhatnak. De a számítás, tárolás, hálózatkezelés és hitelesítés/engedélyezés kulcsdimenzióinál jelezzük a következő függőségeket.

A vezérlősíkoknál az általános függőségek a következők:

  1. Az Identity/Platform adatsíkja hitelesítésnél és engedélyezésnél
  2. Az ellenőrzés nyomkövetési szolgáltatása
  3. Belső szolgáltatások, amelyek például munkafolyamatot, metaadat-tárolót és naplózást biztosítanak
  4. Különféle típusú terheléselosztók

Egyes vezérlősíkok nyilvánvalóan szolgáltatásra jellemző függőségekkel rendelkeznek. Például a Compute vezérlősíkja bare metal vagy VM példány indításakor függ a következőtől:

  • Object Storage (az operációs rendszer megadott lemezképének lekéréséhez)
  • Block Volumes vezérlősíkja (a rendszerindító kötet előkészítésénél és csatolásánál)
  • Networking vezérlősíkja (VNIC kártyák előkészítésénél és csatolásánál)

Alapvető szolgáltatások adatsíkjainál az általános elv az, hogy minden adatsíkot szándékosan minimális függőséggel alakítanak ki a magas rendelkezésre állás, a diagnosztizálásig eltelt rövid idő és a gyors helyreállítás elérése érdekében. Ennek az alapelvnek az eredményei a következők:

  • A Networking adatsíkja önálló.
  • A Block Volumes adatsíkja önálló.
  • A Compute bare metal és VM példányok a Block Volumes adatsíkjától (rendszerindító köteteknél) és a Networking adatsíkjától függenek.
  • Az Object Storage adatsíkja függ az Identity/Platform adatsíkjától hitelesítésnél és engedélyezésnél (iparági elvárások miatt). Az Object Storage adatsíkja nem függ a Block Volumes és a File Storage szolgáltatástól.
  • Minden szolgáltatás, amely támogatja a biztonsági mentést és a visszaállítást, függ az Object Storage adatsíkjától az adott funkciónál.

Az IaaS adatsíkjainál az általános elv az, hogy csak az alapvető vagy alacsonyabb szintű adatsíkoktól függjenek (a körkörös függőségek elkerülése érdekében).

  • A Database többcsomópontos RAC fürtjei a Networking adatsíkjától és a Block Volumes adatsíkjától függenek.
  • A Container Engine for Kubernetes nyilvánvalóan függ a Kubernetes szolgáltatástól és átmeneti függőségeitől (például etcd), valamint a Networking adatsíkjától.
  • A biztonsági mentés és a visszaállítás minden támogatása függ az Object Store adatsíkjától.

1A Stanford és a Berkeley nyilvános kutatási programja Armando Fox és Dave Patterson vezetésével

 
×
Hívjon bennünket:
1-800-633-0738 (USA)

Kapcsolat
×