„Az Oracle maximális elérhetősége architektúrája referenciaarchitektúra A DBaaS (Database as a Service) megközelítés alapja ORACLE HIVATALOS DOKUMENTUM | SZEPTEMBER..."

Elérhetőségi architektúra (MAA)

Referencia architektúrák a maximális rendelkezésre állás érdekében

Oracle (Oracle Maximum Availability Architecture)

A DBaaS megközelítés alapja (adatbázis, mint szolgáltatás)

HIVATALOS ORACLE DOKUMENTUM | 2015. SZEPTEMBER

Bevezetés 1

Magas rendelkezésre állású referenciaarchitektúrák – Áttekintés 2

Bronz: Egypéldányos 4 Oracle Database magas rendelkezésre állás és adatvédelem 4 Bronz Database Consolidation 5 Lifecycle Management and Provisioning Database as a Service (DBaaS) 5 Oracle Engineered Systems Suite 5 Bronze Tier Következtetés: Adatvédelem, RTO és RPO 6 Ezüst: magas rendelkezésre állás Automatic Failover 7 Oracle Real Application Cluster (Oracle RAC) 8 Oracle RAC One Node 8 Silver Következtetés: Adatvédelem, RTO és RPO 9 Gold: Átfogó magas rendelkezésre állási és katasztrófa-helyreállítási képességek 9 Oracle Active Data Guard – Valós idejű adatvédelem és Magas rendelkezésre állás 10 Oracle GoldenGate 11 Oracle Site Guard 12 Gold Következtetés: Adatvédelem, RTO és RPO 13 Platina: Nincs leállás a platinaszintű szolgáltatásra kész alkalmazásoknál 14 Alkalmazás-folytonossági technológia 14 Oracle Active Data Guard Far Sync 15

Nulla állásidő-karbantartás GoldenGate és Active-Active Replikáció 15-ös kiadás alapú újradefiniálással 16 Oracle Global Data Services Solution 16 Platina Következtetés: Adatvédelem, RTO és RPO 17 Következtetés 17

AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

Bevezetés a modern világ a vállalatokra erős nyomás nehezedik, hogy kevesebbel többet tegyenek, csökkentsék a kockázatot és növeljék a rugalmasságot. Az IT-technológiák aktív konszolidációja és a DBaaS (adatbázis, mint szolgáltatás) nyilvános és privát felhőben történő bevezetése olyan stratégia, amelyhez sok vállalat fordul e cél elérése érdekében. Mindkét fejlesztés jelentősen befolyásolja a magas rendelkezésre állást és adatvédelmet szolgáló architektúrák tervezését és megvalósítását.

Az adatbázis-konszolidáció következtében az állásidő és az adatvesztési problémák jelentősen súlyosbodnak. Az egyetlen fejlesztő vagy egy kis munkacsoport által használt egyetlen önálló környezet meghibásodásának hatása gyakran elhanyagolható. A szervezet teljes fejlesztőcsapatát támogató konszolidált környezet ilyen meghibásodása, vagy több részleg által használt alkalmazás meghibásodása megzavarhatja a vállalat működését. Ebben a példában azok a szolgáltatási szintek, amelyek magas rendelkezésre állást és adatvédelmet biztosítanak egy összevont környezet számára, sokkal fontosabbak, mint az önálló környezetek korábbi szolgáltatási szintjei.

Az adatkonszolidáció és a DBaaS megközelítés az informatikai szolgáltatások és folyamatok szabványosítását is megköveteli. A szabványosítás fontos feltétele a költségek csökkentésének és a működés összetettségének. A megfelelő szabványosítással a szervezet agilitása is jelentősen növelhető, így az IT-szolgáltatások gyorsan reagálhatnak a változó üzleti igényekre.

Az Oracle Maximum Availability Architecture négy magas rendelkezésre állású referenciaarchitektúrát határoz meg, amelyek megfelelő szintű szabványosítást biztosítanak, miközben a rendelkezésre állási és adatvédelmi kihívások teljes skáláját kezelik minden méretű és üzletágú szervezet számára.

Ez a cikk részletesen áttekinti az egyes referenciaarchitektúrákat és a megfelelő elérhető szolgáltatási szinteket. A cikk elsősorban műszaki szakembereknek szól: építészeknek, informatikai igazgatóknak és adatbázis-adminisztrátoroknak, akik a DBaaS megközelítés tervezéséért és megvalósításáért felelősek. Az ajánlott bevált gyakorlatok egyformán érvényesek minden Oracle Database által támogatott platformra, kivéve, ha kifejezetten meg van említve, hogy ez az optimalizálás csak az Oracle Engineered Systemsre vonatkozik.

1 | A MAA REFERENCE ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJA

Magas rendelkezésre állású referenciaarchitektúrák – Áttekintés Az Oracle MAA Best Practices négy magas rendelkezésre állású referenciaarchitektúrát határoz meg, hogy segítse a rendszer teljes rendelkezésre állását és az adatvédelmet minden méretű és üzletágú szervezet számára. Ezeket az architektúrákat vagy magas rendelkezésre állási szinteket PLATINUM (PLATINUM), GOLD (GOLD), EZÜST (EZÜST) és BRONZ (BRONZ) néven jelölik.

ábrán leírt szolgáltatási szinteket nyújtják. egy.

–  –  –

Rizs. 1. Szolgáltatási szintek a magas szintű rendelkezésre állás és adatvédelem érdekében Minden réteg saját MAA referenciaarchitektúrát használ az Oracle HA eszközeinek optimális készletének telepítéséhez, amely megbízhatóan biztosítja a kívánt szolgáltatási szintet minimális költséggel és bonyolultsággal. Bármilyen típusú nem tervezett leállást kezelnek, beleértve az adatsérülést, az összetevők meghibásodását, a rendszer- vagy adatközpont-kimaradást, valamint a karbantartási, migrációs vagy egyéb célú tervezett kieséseket. Az egyes architektúrák általános leírását az 1. ábra mutatja be. 2.

Rizs. 2. Referenciaarchitektúrák a magas rendelkezésre állás és adatvédelem érdekében

A bronzszintű adatbázisok azok, ahol egy egyszerű újraindítás vagy biztonsági másolatból történő visszaállítás „elég magas rendelkezésre állásnak” minősül. A Bronze szint az Oracle Database egyetlen példányán alapul, és a MAA architektúra legjobb gyakorlatait használja, amely magában foglalja az Oracle Enterprise Edition licencében található számos adatvédelmi és magas rendelkezésre állási szolgáltatást.

Az Oracle által az Oracle Recovery Manager (RMAN) segítségével optimalizált biztonsági mentések biztosítják

2 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

adatvédelem, és helyreállításra használják, ha az adatbázis újraindítása nem lehetséges.

A Silver szint további magas szintű rendelkezésre állást biztosít azon adatbázisok számára, amelyek minimális leállást igényelnek, ha egy adatbázispéldány vagy kiszolgáló meghibásodik, valamint a legtöbb ütemezett karbantartási leállás esetén. A Silver szintet klaszterezési technológia egészíti ki – Oracle RAC vagy RAC One Node. Az RMAN adatbázis-mentéseket biztosít az adatok védelmére és a rendelkezésre állás helyreállítására, ha a leállítás lehetetlenné teszi a fürt újraindítását.

A Gold szint jelentősen javítja a kritikus üzleti alkalmazások szolgáltatási szintjét, ahol egyetlen komponens meghibásodása nem eredményezi a teljes rendszer meghibásodását. A Gold szintet adatbázis-replikációs technológiák egészítik ki: Active Data Guard és Oracle GoldenGate. Ezek a technológiák egy vagy több éles adatbázis-replikát szinkronizálnak, hogy valós idejű adatvédelmet és magas rendelkezésre állást biztosítsanak. Az adatbázis-replikáció lényegesen magasabb szintű rendelkezésre állást és adatvédelmet biztosít, mint a tárolási szintű replikációs technológiák. Ezenkívül csökkenti a költségeket és növeli a befektetés megtérülését az összes replika folyamatos aktív használatával.

A Platinum szint számos új funkciót kínál az Oracle Database 12c-ben, valamint a korábban elérhető, továbbfejlesztett termékeket. új verzió. Tartalmazza az Application Continuity technológiát a folyamatban lévő tranzakciók megbízható visszajátszásához, az Active Data Guard Far Sync teljes védelmet az adatvesztés ellen, ha a replikát eltávolítják a fő adatbázisból, új GoldenGate-bővítményeket a frissítésekhez és leállás nélküli migrációkhoz, valamint a Global Data Services szolgáltatást az automatikus kezeléshez. és terheléselosztás az adatbázis-replikációhoz. Bár minden egyes technológia megvalósítása jelentős erőfeszítést igényel, jelentős előnyökkel jár a kritikus fontosságú alkalmazások számára, ahol az állásidő és az adatvesztés elfogadhatatlan.

Az alábbi táblázat összefoglalja az egyes referenciaarchitektúrákba beépített magas rendelkezésre állási (HA) és adatvédelmi attribútumokat.

MAGAS ELÉRHETŐSÉG ÉS ADATVÉDELEM

–  –  –

A MAA referenciaarchitektúrákat eredendően az ütköző problémák megoldására tervezték.

Egyrészt nem minden alkalmazásnak ugyanazok a követelményei a magas rendelkezésre állás és az adatvédelem tekintetében. Másrészt a szabványos architektúra működési követelmény, és elengedhetetlen a vállalkozások számára a bonyolultság és a költségek csökkentése érdekében.

A MAA referenciaarchitektúra mindkét valóságot kezeli, és olyan infrastruktúrát biztosít, amely az Oracle Database-hez optimalizált, és lehetővé teszi a megfelelő HA-szint beállítását a különböző szolgáltatási szintű követelményekhez. Ez megkönnyíti az adatbázis áthelyezését a következő szintre, ha az üzleti követelmények megváltoznak, vagy ha

3 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

átmenet egyik hardverplatformról a másikra.

A következő szakaszok részletesebben ismertetik az egyes referencia-architektúrákat.

Bronz: egyetlen példány A bronzszintet biztosítja alapszolgáltatás DB a legalacsonyabb költségekkel. A megvalósítás költségeit és bonyolultságát csökkenti az alacsonyabb elérhetőség és adatvédelem. ábrán A 3. ábra a bronz szint általános nézetét mutatja.

A Bronze szint egyetlen Oracle Database példányt használ; nem használunk fürtözési technológiát arra az esetre, ha a kiszolgáló meghibásodik, hogy automatikusan átálljon egy olyan készenléti állapotba, amelyen fut Oracle Database példány. Ha egy kiszolgáló vagy adatbázis meghibásodik, a helyreállítási idő célkitűzése (RTO) attól függ, hogy milyen gyorsan tudja biztosítani a cserehardvert vagy a biztonsági másolatból történő visszaállítást. A legrosszabb forgatókönyv szerint teljes leállás A számítási helynek több időbe telik ezeknek a feladatoknak a végrehajtása a készenléti csomóponton, és bizonyos esetekben ez napokig is eltarthat.

Bronz szint: egyetlen példány RTO percektől napokig, RPO a legutóbbi óta Tartalékmásolat Rizs. 3. A Bronze Oracle Recovery Manager (RMAN) High Availability Reference Architecture rendszert az Oracle Database rendszeres biztonsági mentéseihez használják.

A lehetséges adatvesztés, az úgynevezett helyreállítási pontobjektum (RPO), az utolsó biztonsági mentés óta generált összes adat. Az adatbázis biztonsági másolatait a távoli adatközpontban vagy a felhőben is tárolják biztonsági mentési célokra, valamint a fő adatközpontban bekövetkező katasztrófa esetén a katasztrófa utáni helyreállításhoz.

A bronz szint a következő részekben ismertetett fő összetevőkből áll.

Magas szintű rendelkezésre állás és adatvédelem az Oracle Database-ben A Bronze szint az Oracle Database Enterprise Edition következő magas rendelkezésre állási és adatvédelmi szolgáltatásait használja további költségek nélkül.

Az Oracle Restart automatikusan újraindítja az adatbázist, a Listenert és más összetevőket."

Az Oracle hardver- vagy szoftverhiba után, vagy minden alkalommal, amikor az adatbázis-gépet újraindítják.

Az Oracle korrupcióvédelmi ellenőrzése fizikai »

sérülés és logikai blokkon belüli sérülés. A rendszer észleli a RAM-ban lévő adatsérülést, és nem írja ki a lemezre. Sok esetben automatikusan rögzíthetők. További információkért lásd: Blokkkorrupció megelőzése, észlelése és javítása a Oracle Database (az Oracle Database hibás blokkjainak megelőzése, észlelése és javítása).

Automatic Storage Management (ASM) – Oracle integrált fájlrendszer »

4 | AZ ORACLE MAA REFERENCE ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJA

és egy kötetkezelő automatikus tükrözéssel a lemezhibák elleni védelem érdekében.

Oracle Flashback Technologies – olyan funkciók csoportja, amelyek gyors javításokat biztosítanak »

különféle hibákra van szükség egy adott tranzakció, tábla vagy teljes adatbázis visszaállításához.

Az Oracle Recovery Manager (RMAN) költséghatékony és megbízható biztonsági mentést biztosít »

másolás és visszaállítás az Oracle Database számára optimalizálva.

Az online karbantartás egy olyan szolgáltatás, amely magában foglalja az újradefiniálást és az átszervezést »

non-stop adatok adatbázis-karbantartáshoz, fájlátvitelhez és javításhoz.

Adatbázis-konszolidáció a bronzszinten A bronzszinten telepített adatbázisok fejlesztési és tesztelési célú adatbázisokat, valamint kis munkacsoport- és osztályalkalmazásokat tartalmaznak, amelyek gyakran az első jelöltek az adatbázis-konszolidációra és az adatbázis-szolgáltatásként (DBaaS) való kiépítésre.

Az Oracle Multitenant egy MAA módszer az adatbázis-konszolidációhoz és virtualizációhoz, kezdve az Oracle Database 12c-vel. További konszolidációs lehetőségek a következők.

Operációs rendszer virtualizáció – több virtuális gép egyetlen fizikai gazdagépen »

Sémakonszolidáció – különböző alkalmazássémák ugyanabban az adatbázisban »

Platformkonszolidáció – több különálló adatbázis ugyanazon a fizikai gépen vagy egyben »

Az Oracle RAC Cluster Az Oracle Multi-bérlő és más konszolidációs módszerek közötti kompromisszumokat az Oracle Maximum Availability Architecture fehér könyve tárgyalja „A magas rendelkezésre állású legjobb gyakorlatok az adatbázis-konszolidációhoz”.

Lifecycle Management and Database as a Service (DBaaS) Oracle Enterprise Manager Cloud Control – lehetővé teszi a felhasználók számára, hogy maguk telepítsék az IT-erőforrásokat egy erőforráskészlet-modell szerint a különböző többbérlős architektúrákhoz. Ezek a képességek szükségesek a DBaaS (adatbázis mint szolgáltatás) megközelítés megvalósításához, egy olyan paradigmához, amelyben a végfelhasználók (DBA-k, alkalmazásfejlesztők, QoS mérnökök, projektmenedzserek stb.) adatbázis-szolgáltatást igényelhetnek, használhatják életciklus projektet, majd engedje el, és helyezze vissza az erőforráskészletbe. A Cloud Control Database as a Service (DBaaS) a következőket kínálja:

Közös konszolidált platform adatbázis-szolgáltatás nyújtására »

Önkiszolgáló modell ezen erőforrások telepítéséhez »

Az adatbázis-erőforrások rugalmas növelése és csökkentése »

Csak a használt adatbázis-erőforrásokért kell fizetni »

Oracle Engineered Systems Suites Az Oracle Engineered Systems csomagok csökkentik az életciklus költségeit azáltal, hogy szabványosítanak egy előre integrált és optimalizált platformon az Oracle Database és alkalmazások számára. Az Oracle Engineered Systems programcsomagjai a következőket tartalmazzák.

Oracle Virtual Compute Appliance – drámaian leegyszerűsíti a telepítést és a telepítést az ügyfelek számára »

virtuális infrastruktúrák bármely Linux, Oracle Solaris vagy Microsoft Windows alkalmazáshoz és ezek kezeléséhez.

Oracle Database Appliance – alacsony költségű átfogó szoftvercsomag, tárolórendszerek »

adat-, szerver- és hálózati létesítmények, amelyek csökkentik a bonyolultságot, és az egyszerűsítés révén időt és pénzt takarítanak meg

5 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

bevetés, Karbantartás valamint adatbázis- és alkalmazástámogatás. Az Oracle Database Appliance támogatja mind a fizikai, mind a virtuális telepítést.

Az Oracle Exadata Database Machine a legproduktívabb, »

méretezhető és megfizethető platform az Oracle Database futtatásához. Az Oracle Exadata Database Machine minden típusú alkalmazással működik, beleértve az online tranzakciófeldolgozást (OLTP), az adattárházat (DW) és a vegyes terhelésű alkalmazáskonszolidációt, ideális alapot biztosítva az adatbázis-konszolidációhoz.

Oracle SuperCluster – célirányosan épített rendszerek, amelyek ideálisak adatbázis-konszolidációhoz és »

alkalmazások, privát felhőalapú telepítések és Oracle szoftverek egyetlen, egységes platformon. Az Oracle SuperCluster a világ leggyorsabb processzorait használja a SPARC architektúrán és az Exadata tárhelyen.

Az Oracle ZFS Storage Appliance azonnali lemezmegtakarítási előnyöket kínál »

helyet, kezelést és költségmegtakarítást használó ügyfelek számára hálózati rendszer tároló (NAS). Az Oracle ZFS funkciókban gazdag kezelési, megfigyelési, hibaelhárítási, pillanatfelvételi, klónozási, replikációs és további tárolási szolgáltatásokat tartalmaz, amelyek természetesen kiegészítik az összes Oracle Engineered Systemet.

Bronz szintű következtetés: Adatvédelem, RTO és RPO Az alábbi táblázat összefoglalja az összes bronz szintű adatvédelmi funkciót. A 2. táblázat első oszlopa jelzi, hogy mikor kerül sor a fizikai és logikai adatok sérülésének ellenőrzésére.

A kézi ellenőrzéseket a rendszergazda kezdeményezi, vagy rendszeres időközönként »

ütemezett feladat, amely időszakos ellenőrzéseket végez.

Az adatbázis megnyitásakor a háttérfolyamatok folyamatosan menet közbeni ellenőrzéseket végeznek.

A háttérellenőrzéseket meghatározott rendszeres időközönként végezzük, de csak »

időszakokban, amikor az erőforrásokat nem használják fel.

Minden ellenőrzés egyedi az Oracle Database számára, és az Oracle adatblokkok és adatbázisnaplók szerkezetének specifikus ismereteit használja fel.

BRONZ ADATVÉDELEM

–  –  –

Vegye figyelembe, hogy a HARD ellenőrzés és az Automatikus merevlemez-tisztítás és -javítás funkció az Exadata tárolórendszer egyedi jellemzői. A HARD ellenőrzéssel az Oracle Database nem írja ki a fizikailag sérült blokkokat a lemezre. Az automatikus merevlemez-tisztítás és -javítás rendszeres időközönként észleli és megjavítja a rossz vagy elhasználódott szektorokkal rendelkező merevlemezeket (tárolórendszer-fürt), valamint egyéb fizikai és logikai hibákat is észlel és javít, ha vannak szabad erőforrások.

Az Exadata kérést küld az ASM-nek, hogy javítsa ki a hibás szektorokat egy másik tükörmásolatból származó adatok beolvasásával. Alapértelmezés szerint a lemeztisztítás (scrub) kéthetente történik.

6 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

A következő táblázat a bronz szintű RTO-kat és RPO-kat mutatja be különböző ütemezett és nem ütemezett kimaradásokhoz.

HELYREÁLLÍTÁSI IDŐ (RTO) ÉS LEHETSÉGES ADATVESZTÉS (RPO) BRONZ SZINTEN

–  –  –

Ezüst: Magas rendelkezésre állás automatikus feladatátvétellel Az ezüst szint a Bronze rétegen alapul, de magában foglalja a fürtözési technológiát a nem tervezett leállások és az ütemezett karbantartás során a nagyobb rendelkezésre állás érdekében (4. ábra). A Silver szint Oracle RAC vagy Oracle RAC One Node fürtözési technológiát használ az adatközpont magas szintű rendelkezésre állása érdekében. Ez automatikus feladatátvétellel érhető el abban az esetben, ha az egyik adatbázispéldány leáll, vagy az adatbázispéldányt tároló kiszolgáló teljes meghibásodása esetén. Az Oracle RAC egy másik jelentős előnyt is biztosít – kiküszöböli a különféle tervezett leállásokat, mivel képes egyenként karbantartani az Oracle RAC fürtcsomópontjait. Ezüst szint: magas rendelkezésre állás gyors feladatátvételi RTO-val másodpercek alatt szerverhiba esetén, RPO az utolsó óta biztonsági mentés 4. Silver High Availability Reference Architecture

7 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

A Silver szint a következő szakaszokban ismertetett magas rendelkezésre állási funkciókat tartalmazza.

Oracle Real Application Clusters (Oracle RAC) Az Oracle RAC javítja az alkalmazások elérhetőségét az adatközponton belül az adatbázispéldány vagy a példányt tároló kiszolgáló meghibásodása esetén. Az Oracle RAC segítségével készenléti kiszolgálóra való váltás azonnali. Szinte észrevehetetlen a szolgáltatás visszaállításának ideje a fennmaradó példányokon és a meghibásodott csomópont felhasználóinak újracsatlakoztatása.

Ezenkívül kiküszöböli az összes Oracle RAC csomóponton felváltva végrehajtható ütemezett karbantartási feladatok leállását. A felhasználók befejezik a munkájukat, és bezárják a munkameneteiket azon a csomóponton, ahol a karbantartást végzik. Amikor újracsatlakoznak, hozzáférést kapnak egy másik csomóponton már futó adatbázispéldányhoz.

Az Oracle RAC-fürt működésének rövid áttekintése segít megérteni előnyeit. Két összetevőből áll: az Oracle Database példányai és maga az Oracle Database.

Az adatbázispéldány kiszolgálófolyamatok és memóriastruktúrák halmaza, amelyek futnak »

egy gazdagépen (vagy szerveren), és tegyen elérhetővé egy adott adatbázist az ügyfelek számára.

Adatbázis – megosztott fájlok (adatfájlok, indexfájlok, »

vezérlőfájlok és egy inicializálási fájl), amelyek a lemezen és együtt vannak tárolva, megnyithatók és adatok olvasására és írására használhatók.

Az Oracle RAC aktív-aktív architektúrát használ, amely több adatbázispéldánnyal is rendelkezhet »

különböző csomópontokon futó adatok, amelyek egyszerre olvasnak és írnak adatokat ugyanabba az adatbázisba.

Az Oracle RAC-fürt aktív-aktív architektúrája a következő előnyöket nyújtja.

A magas rendelkezésre állás szintjének növelése. Szerver vagy adatbázis példányhiba nem érinti »

a kapcsolatok más példányokhoz és a sikertelen példányokhoz fűződő kapcsolatok gyorsan áttelepülnek más olyan példányokra, amelyek már futnak és a fürt többi kiszolgálóján megnyílnak.

Méretezhetőség. Az Oracle RAC fürt ideális olyan alkalmazásokhoz és konszolidált környezetekhez, ahol »

skálázhatóságot és képességet igényel a feldolgozási teljesítmény dinamikus növelésére és a prioritások megváltoztatására egynél több szerveren. Egy adatbázis példányai futhatnak egy vagy több fürtcsomóponton. Hasonlóképpen, ugyanaz az adatbázis-szolgáltatás egy vagy több adatbázispéldányon is elérhető lehet. További csomópontok, adatbázis-példányok és adatbázis-szolgáltatások a fürt leállítása nélkül újradefiniálhatók. Az Oracle RAC ideális kiegészítője az Oracle Multitenantnak, mivel a munkaterhelés könnyen elosztható a fürtök között.

Megbízható teljesítmény. Az Oracle Quality of Service (QoS) segítségével hozzárendelhető »

erőforrásokat magas prioritású adatbázis-szolgáltatásokhoz, és folyamatosan magas teljesítményt biztosít a konszolidált adatbázis-környezetekben. A számítási teljesítmény dinamikusan átcsoportosítható a változó követelményekhez való gyors alkalmazkodás érdekében.

Magas rendelkezésre állás a tervezett karbantartás során. A magas rendelkezésre állást »

az Oracle RAC csomópontok egyenkénti módosítása. Ez magában foglalja a hardver, az operációs rendszer vagy a hálózati karbantartást, amikor egy kiszolgálót offline állapotba kell kapcsolni, az Oracle Grid Infrastructure szoftververem vagy adatbázis javítását, valamint azt a karbantartást, amikor egy adatbázispéldányt át kell helyezni egy másik szerverre a feldolgozási teljesítmény vagy a terheléselosztás növelése érdekében.

Az Oracle RAC a MAA legjobb gyakorlata a kiszolgálók magas rendelkezésre állásához.

Oracle RAC One Node Az Oracle RAC One Node ezüst alternatívát kínál az Oracle RAC-fürthöz, ha a kiszolgáló magas rendelkezésre állása szükséges, de nem szükséges a méretezhetőség és az azonnali feladatátvétel. Az Oracle RAC One Node licenc fele az Oracle RAC árának, és olcsóbb alternatíva, ha a percek alatti RTO elegendő szerverhiba esetén.

8 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

Az Oracle RAC One Node egy aktív-passzív átkapcsolási technológia. Ugyanazon az infrastruktúrán alapul, mint az Oracle RAC, de az Oracle RAC One Node esetén normál működés közben egyszerre csak egy adatbázispéldány van nyitva.

A nyílt adatbázist kiszolgáló kiszolgáló meghibásodása esetén az Oracle RAC One Node automatikusan elindít egy új adatbázispéldányt a második csomóponton, hogy gyorsan újraindítsa a szolgáltatást.

Az Oracle RAC One Node számos előnnyel rendelkezik más aktív-passzív fürtözési technológiákkal szemben.

Oracle RAC One Node konfigurációban az Oracle Database HA Services, a Grid Infrastructure és az adatbázisfigyelők mindig a második csomóponton futnak. Feladatátvétel során csak az adatbázispéldányt és az adatbázis-szolgáltatásokat kell elindítani, ami felgyorsítja a szolgáltatás újraindítását és percek alatt lehetővé teszi a szolgáltatások újraindítását.

Az ütemezett karbantartáshoz az Oracle RAC One Node ugyanazokat az előnyöket nyújtja, mint az Oracle RAC. Egy RAC One Node-fürtben egy ütemezett karbantartási időszak alatt két aktív adatbázis-példány lehetővé teszi a felhasználók számára, hogy zökkenőmentesen, nulla leállás nélkül váltsanak át egyik csomópontról a másikra. A csomópontokat folyamatosan karbantartják, ezalatt az adatbázis-szolgáltatások továbbra is elérhetők maradnak a felhasználók számára.

Ezüst szintű következtetés: Adatvédelem, RTO és RPO Az adatvédelem szintje megegyezik a bronz szinttel. Az ezüst szint javítása a bronz szinthez képest a szerverhiba esetére vonatkozó RTO-val és néhány gyakrabban elvégzett ütemezett karbantartással kapcsolatos. A bronz szinthez képest javítani kívánt területek a következő táblázatban félkövéren vannak szedve.

HELYREÁLLÍTÁSI IDŐ (RTO) ÉS LEHETSÉGES ADATVESZTÉS (RPO) EZÜST SZINTEN

–  –  –

Gold: Átfogó magas rendelkezésre állási és feladatátvételi képességek A Gold szint a Silver szintre épül, de adatbázis-replikációs technológiát használ, hogy egyetlen hibapontot kiküszöböljön, amely az egész rendszert lerombolhatja, és nagymértékben javítja az adatvédelmet és a rendelkezésre állást minden típusú nem tervezett meghibásodás esetén. , beleértve az adatsérülést, az adatbázis-hibákat és az adatközpont-hibákat. A replikált másolat nagymértékben csökkenti az ütemezett karbantartási időszakok leállási idejét is. Általános formaábrán látható az Arany szint. 5.

9 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

Az RTO másodpercekre vagy percekre csökken, az RPO pedig nullára vagy nulla közelébe csökken a konfigurációtól függően.

Arany szint: Átfogó magas rendelkezésre állási és átállási képességek RTO másodpercektől percekig, RPO nulláig vagy nullához közel 5. Gold High Availability Reference Architecture Ne feledje, hogy a Gold réteg az Oracle RAC-t használja a szerver magas rendelkezésre állásának szabványaként, a Silver szinten elérhető kevésbé működő Oracle RAC One Node helyett.

Az Arany szint a következő szakaszokban ismertetett magasabb szolgáltatási szintekhez kínál funkciókat.

Oracle Active Data Guard – Valós idejű adatvédelem és magas rendelkezésre állás Az Oracle Active Data Guard egy vagy több szinkronizált fizikai replikát (készenléti adatbázist) tart fenn egy távoli gazdagépen, hogy kiküszöböljön egyetlen olyan hibát, amely az elsődleges adatbázis meghibásodását okozhatja. A MAA bevált gyakorlatai alapján javasolt ugyanazt a konfigurációt használni az elsődleges és a készenléti adatbázishoz (CPU, memória, I/O stb.), hogy a készenléti adatbázis a feladatátvétel után az eredetivel azonos teljesítményt nyújtson. fő.

Az Active Data Guard a következő funkciókkal egészíti ki a Gold réteget.

Választható védelem nulla vagy közel nulla adatvesztés esetén. Az Active Data Guard fellép »

a változtatások replikálása a fő adatbázisból a biztonsági másolatba valós időben. A változtatások közvetlenül a fő adatbázis újraindítási pufferéből kerülnek kiküldésre, hogy minimalizálják a replikációs késleltetést és a fő adatbázisra gyakorolt ​​hatást, valamint hogy teljesen elszigeteljék a replikációs folyamatot az éles adatbázis I/O veremében előforduló sérülésektől.

A rendszergazdák a Maximális elérhetőség biztonsági módban választhatják ki a szinkron átvitelt.

elérhetőség), hogy garantáljuk a nulla adatvesztést. Vagy dönthetnek úgy, hogy aszinkron módon, Maximum Performance módban, közel nulla adatvesztés mellett továbbítanak. A Maximális teljesítmény mód egy másodpercnél rövidebbre korlátozhatja az adatvesztés lehetőségét, ha a hálózati sávszélesség elegendő a replikált adatok méretéhez.

A Data Guard és az Active Data Guard az egyetlen Oracle replikációs technológia, amely védelmet nyújt »

nulla adatvesztéssel.

A készenléti Oracle Active Data Guard adatbázis gyorsan átveheti a termelési terhelést »

és állítsa vissza a szolgáltatást, ha adatbázishiba vagy helyleállás miatt az elsődleges adatbázis elérhetetlenné válik. Az Oracle Database mindig fut, nem kell újraindítani, és az elsődleges adatbázis-szerep átvitele kevesebb, mint 60 másodperc alatt befejeződik, még erősen terhelt rendszereken is.

10 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

A Gold szint a Data Guard Fast-Start Failover funkciót használja az automatikus feladatátvételhez »

biztonsági mentési adatbázisok. Ez felgyorsítja a helyreállítást azáltal, hogy kiküszöböli a késedelmet az adminisztrátor értesítésében, hogy az reagálhasson a hibákra. A Fast Start Failover szerepkör-alapú adatbázis-szolgáltatásokat és Oracle-ügyfélértesítési technológiát használ annak érdekében, hogy az alkalmazások gyorsan le tudjanak kapcsolódni a meghibásodott elsődleges adatbázissal, és automatikusan csatlakozzanak az új elsődleges adatbázishoz. Az adatbázis-szerepkör átvitele történhet manuálisan a parancssori felületen vagy az Oracle Enterprise Manageren keresztül.

átlátszó replikáció. A Data Guard és az Active Data Guard teljes, egyirányú fizikai munkát végez »

Oracle Database replikáció a következő jellemzőkkel: nagy teljesítmény, egyszerű kezelés, támogatás minden típusú adathoz, alkalmazáshoz és munkaterheléshez, például DML, DDL, OLTP, kötegelt feldolgozásés adattárház, valamint konszolidált adatbázisok. A Data Guard és az Active Data Guard szorosan integrálódik az Oracle RAC, ASM, RMAN és Oracle Flashback technológiáival.

Töltsd ki a termelési adatbázisból a nagyobb ROI érdekében. Oracle készenléti adatbázisok »

Az Active Data Guard csak olvashatóként nyitható meg, ha a replikáció folyamatban van. A frissített, aktív készenléti állapot ideális a nehéz SQL-lekérdezések átviteléhez és a jelentéskészítéshez a fő adatbázisból.

Ez javítja a készenléti rendszerek megtérülését és az elsődleges adatbázis teljesítményét azáltal, hogy kihasználja az egyébként tétlen számítási teljesítményt. Folyamatosan ellenőrzik az alkalmazásokat is, hogy a készenléti adatbázisok készen állnak-e a terhelés átvételére arra az esetre, ha az elsődleges adatbázis leállna.

A fő adatbázis felszabadítása a biztonsági mentési feladatokból. Az elsődleges és tartalék rendszerek »

egymás pontos fizikai másolatai, ami lehetővé teszi a biztonsági mentési feladatok átvitelét a fő adatbázisból a biztonsági másolatba. A készenléti adatbázison létrehozott biztonsági másolat felhasználható a fő vagy a készenléti adatbázis visszaállítására. Ez rugalmasságot biztosít a rendszergazdáknak a helyreállítási folyamatban, és a termelési rendszereknek nem kell viselniük a biztonsági mentés terhét.

Csökkentett állásidő a tervezett karbantartáshoz. A készenléti adatbázisok használhatók a »

új javításkészlet (például egy javítás a 11.2.0.2-es verzióról a 11.2.0.4-re való átálláshoz) vagy az Oracle új verziójára (például 11.2-ről 12.1-re) történő átálláshoz egyenként: először a készenléti adatbázis frissül , ami után az új verzióval gyártásra kerül. A teljes állásidő arra az időre csökken, ameddig az elsődleges adatbázis-szerep átkerül a készenléti adatbázisba, és a frissítés befejezése után a felhasználók az új elsődleges adatbázisra váltanak át.

Az Oracle Active Data Guard készenléti adatbázis folyamatos adatellenőrzést végez annak érdekében, hogy ne »

a kár nem másolható az eredeti adatbázisból. Az Oracle Active Data Guard észleli az elsődleges vagy a készenléti adatbázisban előforduló fizikai és logikai blokkok sérülését. Egyedülálló eszköz az írási blokk sérüléseinek (az I/O alrendszer által sikeresnek nyilvánított írási műveletek elvesztésének vagy elvesztésének) észlelésére is. További információkért lásd: My Oracle Support Note 1302539.1 – A korrupció észlelésének, megelőzésének és automatikus javításának legjobb gyakorlatai.

Automatikus blokkhelyreállítás. Az Oracle Active Data Guard automatikusan kijavítja a sérüléseket »

blokkszint, amelyet véletlenszerű I/O hibák okoznak, amelyek mind az elsődleges, mind a készenléti adatbázisban előfordulhatnak. Ez úgy történik, hogy lekérjük a blokk jó másolatát a másik adatbázisból. Nincs szükség az alkalmazások módosítására, és a javítás átlátható a felhasználók számára.

A fentiek azt is megmagyarázzák, hogy a Gold réteg miért használ replikációs technológiát a szinkronizált másolat fenntartására, nem pedig a távoli tárolótükrözési termékeket (SRDF, Hitachi TrueCopy stb.). Ezekről a különbségekről az Oracle Active Data Guard vs. Storage Remote Mirroring (az Oracle Active Data Guard és a Remote Storage Mirroring összehasonlítása).

Oracle GoldenGate Az Oracle GoldenGate szoftver logikai replikációt biztosít az elsődleges adatbázis (forrásadatbázis) szinkronizált másolatának (céladatbázis) karbantartásához. Az Oracle GoldenGate beolvassa a módosításokat a forrásadatbázis-lemezről, az adatokat platformfüggetlen fájlformátumba konvertálja, átviszi a fájlt a céladatbázisba, majd az adatokat a céladatbázisban natív SQL utasításokká alakítja (frissíti, beszúrja és törli). . A céladatbázis ugyanazokat az adatokat tartalmazza, de ez már nem a forrásadatbázis, hanem egy másik adatbázis (például a biztonsági mentések nem cserélhetők fel). A logikai replikáció több

11 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

összetettebb, mint a fizikai replikáció, de nagyobb rugalmasságot biztosít a különböző replikációs forgatókönyvekhez és a heterogén platformokhoz.

Az adatelosztás szempontjából a logikai replikációt úgy tervezték, hogy költséghatékony legyen »

a forrásadatbázis részhalmazainak replikációja az adatok más céladatbázisokhoz való elosztása érdekében. Használható több forrásadatbázisból származó adatok egyetlen céladatbázisba (például Operational Data Store) történő összevonására is.

Magas rendelkezésre állás szempontjából a logikai replikáció karbantartható »

az eredeti adatbázis teljes másolata a magas rendelkezésre állás vagy feladatátvételi védelem érdekében, azonnal végrehajtható a feladatátvétel a készenléti adatbázisba.

Az Oracle GoldenGate logikai replikációja rugalmas karbantartást és »

egyenkénti migráció, ha ez nem lehetséges a Data Guard replikációjával. Például az Oracle GoldenGate replikációt biztosít egy platformon lévő forrásadatbázisból big-endian byte-sorrendet használó céladatbázisba egy kis végű (cross-endian) replikációval rendelkező platformon. Ez lehetővé teszi, hogy kihasználja a platformok közötti migráció előnyeit a replikáció irányának megfordításával, hogy gyorsan visszatérhessen egy korábbi verzióhoz az áttelepítés után.

Az Oracle GoldenGate logikai replikáció egy összetettebb folyamat, több előfeltétellel, mint a Data Guard. Ezt azonban ellensúlyozza az Oracle GoldenGate egyedülálló képessége a replikáció modern formáinak biztosítására. A MAA legjobb gyakorlatai: Oracle Active Data Guard és Oracle GoldenGate dokumentum további információkkal szolgál a legjobb replikációs technológia kiválasztásához, vagy mindkét technológia kiegészítőként való használatához.

Oracle Site Guard Az Oracle Site Guard lehetővé teszi az adminisztrátorok számára, hogy koordinálják a teljes Oracle környezet (több adatbázis és alkalmazás) ütemezett és nem ütemezett váltásait (egy elsődleges erőforrás váratlan kiesése esetén) egy termelési hely és egy távoli hely között. Az Oracle Site Guard az Oracle Enterprise Manager Life-Cycle Management Pack csomag része.

Az Oracle Site Guard a következő előnyöket nyújtja.

Csökkentse a hibákat a csomóponti hibára adott azonnali válaszokkal. Oracle Site Guard »

csökkenti az emberi hiba valószínűségét balesetek esetén. A helyreállítási stratégiákat az alkalmazáson belül fejlesztik, tesztelik és hibamentesen végzik. Ha egy rendszergazda Site Guard műveletet kezdeményez a katasztrófa utáni helyreállítás érdekében, nincs szükség emberi közreműködésre.

Számos alkalmazás, adatbázis és különféle replikációs technológia koordinálása. Oracle webhely »

A Guard automatikusan kezeli a különböző összetevők közötti függőséget a webhely indításakor vagy leállításakor.

A Site Guard az Oracle Active Data Guarddal integrálva koordinálja több adatbázis egyidejű feladatátvételét. A Site Guard egyszerű integrációs mechanizmust is biztosít bármely távoli tárolótükrözési termékhez. A szoftver integrálható tárolóeszközökkel az erőforrások ütemezett vagy feladatátvételéhez. Ehhez a tárolórendszerekhez meghatározott szerepátviteli parancsfájlok kerülnek meghívásra.

Gyorsítsa fel a helyreállítást. Az Oracle Site Guard Automation minimalizálja a kézi beállítást »

helyreállítási műveletek koordinálása. Ez még ahhoz az esethez képest is felgyorsítja a helyreállítást, amikor minden kézi művelet sikeresen befejeződött. A Site Guard időt takarít meg azáltal, hogy kiküszöböli az összetett manuális eljárások során gyakran előforduló emberi hibákat.

12 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

Arany következtetés: Adatvédelem, RTO és RPO A következő táblázat a Gold Data Protection, RTO és RPO képességeit mutatja be.

A javítandó területek félkövérrel vannak kiemelve.

ARANY ADATVÉDELEM

–  –  –

13 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

Platinum: Nincs állásidő a platinakész alkalmazásokhoz A Platinum az arany szintre épül, és magas szintű rendelkezésre állást és adatvédelmet biztosít azon alkalmazások számára, ahol a kimaradások vagy adatvesztés abszolút elfogadhatatlan. A platinaszint számos új funkciót kínál az Oracle Database 12c-ben, valamint az új verzióban továbbfejlesztett, korábban elérhető termékeket.

A Platinum átláthatóvá teszi a kimaradásokat az alkalmazás és a felhasználók számára, és még a leálláskor folyamatban lévő tranzakciókat is a rendszer a visszaállítást követően menet közben újra megpróbálja. Nulla állásidő a karbantartáshoz, az áttelepítésekhez és az alkalmazásfrissítésekhez. A nulla adatvesztés garantált, ha az elsődleges adatbázis bármilyen okból meghibásodik, függetlenül az elsődleges és a tartalék csomópont közötti távolságtól. A Platinum szint emellett automatikusan kezeli az adatbázis-szolgáltatások elérhetőségét és a terheléselosztást a replikák között több csomóponton keresztül. A platina szint általános nézete az ábrán látható. 6.

Platina szint Nincs állásidő a platinaszintű alkalmazásokhoz

–  –  –

Rizs. 6. Platina magas rendelkezésre állású referenciaarchitektúra Sok alkalmazásnál kisebb változtatásokra lesz szükség a platina szintű kimaradások teljes kiküszöbölése érdekében. Ezért mondjuk, hogy a Platinum nulla állásidőt biztosít csak a Platina-kompatibilis alkalmazásokhoz. Kérjük, vegye figyelembe, hogy nincs szükség az alkalmazás módosítására a nulla adatvesztéshez.

A platinaszint a következő szakaszokban ismertetett magas rendelkezésre állási funkciókat használja.

Alkalmazásfolytonossági technológia Az alkalmazásfolytonossági technológia megvédi az alkalmazásokat az adatbázis-munkamenetek megszakításától a példány, a kiszolgáló, a tároló, a hálózat, bármely más összetevő vagy akár a teljes adatbázis meghibásodása miatt. Az Application Continuity technológia megismétli azokat a tranzakciókat, amelyek a kapcsolat megszakításakor futnak, az alkalmazás számára ez csak egy kis késés a végrehajtásban, a felhasználó számára észrevehetetlen.

A teljes Oracle RAC-fürt meghibásodása esetén, amikor az adatbázis elérhetetlenné válik, az Application Continuity technológia újrajátssza a munkamenetet, beleértve a kívánt tranzakciót is, miután a feladatátvétel a készenléti adatbázisba az Oracle Active Data Guard segítségével történik. A készenléti adatbázissal való alkalmazásfolytonossághoz a Data Guard maximális elérhetősége és a Data Guard gyorsindítási feladatátvétele szükséges.

14 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

Az Oracle Active Data Guard A Far Sync Data Guard és az Active Data Guard az egyetlen replikációs technológia az Oracle számára, amely adatvesztés nélküli feladatátvételt biztosít az Oracle Database számára. Nulla adatvesztés érhető el a Data Guard Maximum Availability módban történő szinkron átvitellel. Szinkron átvitel használata esetén az elsődleges és a készenléti csomópont közötti adatátvitel hálózati késleltetése befolyásolja az adatbázis teljesítményét. Minél nagyobb a távolság a csomópontok között, annál nagyobb a várakozási idő és annak hatása az adatbázis teljesítményére. Mivel az elsődleges és a tartalék adatközpont gyakran távol van egymástól, sok adatbázis esetében nem praktikus az adatvesztés nélküli választás.

Az Active Data Guard Far Sync kiküszöböli a fenti korlátokat, és nulla adatvesztést biztosít az elsődleges adatbázis teljesítményének csökkenése nélkül, még akkor is, ha az elsődleges és a készenléti adatbázis több száz vagy akár több ezer kilométerre van egymástól. Ez egy „könnyű” átviteli mechanizmus révén érhető el, amely könnyen telepíthető és átlátható az Oracle Active Data Guard feladatátvételi vagy ütemezett feladatátvételi műveletei számára. Ha a Far Sync-et az Oracle Advanced Compression Option-jával együtt használják, az adatok tömörítése is megtörténik az elsődleges helyen kívüli továbbításhoz a hálózati sávszélesség megtakarítása érdekében.

Ha a Data Guard Fast-Start-Failover módban (automatikus feladatátvétel) használja a Far Sync alkalmazást, az Application Continuity láthatatlanná teheti a kimaradásokat az adott pillanatban folyamatban lévő tranzakciók számára, függetlenül az elsődleges és a tartalék csomópont közötti távolságtól.

Így a Far Sync a Platinum szint két fő további előnyét nyújtja: adatvesztés nélküli feladatátvételt bármely adatbázis számára, valamint az Application Continuity technológia használatának lehetőségét a csomópontok közötti távolságtól függetlenül. Az Active Data Guard Far Sync egy új mód az Oracle Database 12c-ben. A Far Sync előnyeinek kihasználásához nincs szükség alkalmazásmódosításra.

Nulla állásidő-karbantartás GoldenGate és aktív-aktív replikáció segítségével

A platina szint kihasználja az Oracle GoldenGate fejlett replikációs funkcióit a nulla leállási karbantartás és a kétirányú replikáció révén történő migráció érdekében. Fontolja meg a következő forgatókönyvet.

A karbantartást először a céladatbázison hajtják végre.

A forrás- és a céladatbázis szinkronizálva van a különböző adatbázis-verziókhoz logikai replikáció segítségével »

Oracle GoldenGate. Ez lehetővé teszi a platformok közötti áttérést és a nagy átállást. Lehetővé teszi az olyan összetett alkalmazásfrissítéseket is, amelyek megváltoztatják a kiszolgálóobjektumokat, ahol a replikációs motornak adatokat kell konvertálnia egy régi verzióról egy új verzióra, vagy fordítva.

Amikor a platform új verziója stabilizálódik és stabil, a kétirányú replikáció lehetővé teszi »

a felhasználóknak fokozatosan és leállás nélkül kell áttérniük az új platformra, ahogy befejezik a munkameneteiket a régi verzióban, és csatlakoznak az újhoz. A kétirányú Oracle GoldenGate replikáció szinkronban tartja a régi és az új verziót a migráció során. Lehetővé teszi továbbá a régi verzió gyors visszaállítását, ha váratlan problémákat tapasztal az új verzióval a terhelés hozzáadása során.

A kétirányú aktív-aktív replikáció a szolgáltatás rendelkezésre állásának növelésére is használható, ha állandó kapcsolatra van szükség ugyanazon adatok több olvasási/írási másolatával.

A kétirányú replikáció átláthatatlan az alkalmazás számára. Fel kell ismerni és feloldani az ütközéseket, amikor egyidejűleg több adatbázisban is változtatásokat hajtanak végre ugyanazon a rekordon. Figyelembe kell vennie a különböző típusú hibák és replikációs késések hatását is. Ha a GoldenGate kétirányú replikációt használják a háttéradatbázis-objektumokat módosító alkalmazásfrissítésekhez, a különböző verziók közötti replikációhoz fejlesztői szintű ismerete szükséges az új verzióban módosítandó vagy hozzáadott adatbázis-objektumokról. Az alkalmazás minden új verziója verzióleképezést igényel.

15 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

A GoldenGate replikáció egy aszinkron folyamat, és nem tud nulla adatvesztést biztosítani. Ezért a platinaszintű réteg nem használja az Oracle GoldenGate-et helyek közötti replikációhoz, ha a távoli replikának el kell kerülnie az adatvesztést az elsődleges adatbázis vagy az elsődleges hely nem tervezett leállása esetén.

A nulla adatvesztési követelmény teljesítése érdekében a Platinum szint GoldenGate kétirányú replikációt használ az Oracle Active Data Guarddal együtt.

A helyi GoldenGate replikát a tervezett karbantartáshoz adatvesztés nélkül használják, az Oracle Active Data Guard redundanciája pedig megbízhatóan kiküszöböli az adatvesztést a feladatátvétel során a karbantartás során bekövetkező nem tervezett leállás esetén.

Az Edition Based Redefinition (EBR) szolgáltatás olyan frissítéseket biztosít az alkalmazáshoz, amelyek megváltoztatják a hálózat háttéradatbázis-objektumait anélkül, hogy megzavarnák az alkalmazás elérhetőségét. A frissítések telepítésekor az alkalmazás régi és frissített verziója egyszerre használható. A meglévő munkamenetek továbbra is használhatják az alkalmazást a frissítés előtti módon, amíg a felhasználók úgy nem döntenek, hogy leállítják, és az új munkamenetek már használhatják új kiadás. Ha a frissítetlen alkalmazást használó munkamenetek már nem maradtak, akkor az leállítható.

Az EBR lehetővé teszi az alkalmazások interaktív frissítését az alábbiak szerint.

A programkód változtatásokat vezet be az új kiadás.

Az adatok módosításai biztonságos módon kerülnek bevezetésre, csak új oszlopokba írva vagy új »

táblázatok láthatatlanok a régi kiadásban. Egy speciális kiadás nézetben a táblázat minden revízióhoz speciális módon jelenik meg, így minden revízió csak a saját oszlopait látja.

A keresztkiadás a régi alkalmazásban végzett adatmódosításokat továbbítja oszlopokra »

frissített alkalmazás, és fordítva.

Az Oracle GoldenGate zökkenőmentes alkalmazásfrissítésekhez hasonlóan az EBR megvalósítása és használata mély alkalmazásismeretet és jelentős fejlesztői erőfeszítést igényel. Az Oracle GoldenGate-tel ellentétben az EBR használatához elegendő egyszeri befektetés. Ezután minimális erőfeszítéssel használhatja az EBR-t az alkalmazás további verzióihoz. Az EBR a gyakorlatban már bizonyított a legösszetettebb alkalmazásoknál is. Például az Oracle E-Business Suite 12.2 az EBR-t használja a non-stop javításhoz. Az EBR funkciót további költségek nélkül hozzáadtuk az Oracle Database-hez.

Oracle Global Data Services megoldás Az Oracle Global Data Services (GDS) egy átfogó automatizált terheléskezelési megoldás replikált adatbázisokhoz, Oracle Active Data Guard vagy Oracle GoldenGate használatával. A GDS magasabb rendszerkihasználást, valamint magasabb szintű teljesítményt, skálázhatóságot és rendelkezésre állást biztosít a replikált adatbázisok számára.

A GDS a következő szolgáltatásokat nyújtja egy sor replikált adatbázishoz:

–  –  –

16 | AZ ORACLE MAA REFERENCIA ARCHITECTURES A DBAAS (ADATBÁZIS MINT SZOLGÁLTATÁS) MEGKÖZELÍTÉS ALAPJÁT

Platinum Következtetés: Adatvédelem, RTO és RPO A platina szint ugyanazt a korrupció elleni védelmet nyújtja, mint az arany szint. A Platinum és Gold szintek közötti különbségek a helyreállítási időhöz (RTO) és a lehetséges adatvesztéshez (RPO) kapcsolódnak Platina-kompatibilis alkalmazások esetén.

A platina szint RTO és RPO értéke a következő táblázatban látható.

HELYREÁLLÍTÁSI IDŐ (RTO) ÉS LEHETSÉGES ADATVESZTÉS (RPO) A PLATINUM-nál

–  –  –

Következtetés A szervezeteknek olyan megoldásokra van szükségük, amelyek megfelelnek az adatvédelmi és rendelkezésre állási követelmények teljes skálájának.

Az Oracle MAA bevált gyakorlatai négy magas rendelkezésre állású referenciaarchitektúrát határoznak meg:

BRONZ, EZÜST, ARANY és PLATINA. Minden MAA referenciaarchitektúra az Oracle magas rendelkezésre állású szolgáltatásainak optimális készletét használja ki, hogy megbízhatóan nyújtsa a kívánt szolgáltatási szintet a legalacsonyabb költséggel és bonyolultsággal. Az Oracle-be integrált magas rendelkezésre állású és adatvédelmi szoftverek telepítése magas rendelkezésre állású architektúrák szabványos készletével, közös infrastruktúra használatával egyedi megoldás adatbázis, mint szolgáltatás (DBaaS) megközelítés támogatása nyilvános vagy privát felhőkben.

A ConsultantPlus által biztosított dokumentum Az Orosz Föderáció Igazságügyi Minisztériumában 1996. július 29-én bejegyzett N 1136 KÖRNYEZETVÉDELMI ÉS TERMÉSZETI ERŐFORRÁSOK MINISZTÉRIA sütőfelület Minőség és tapasztalat rozsdamentes acél Utasítások ... "az előfizetési szerződés szövegében használt a Tricolor TV szolgáltatási feltételeiben, és használt ... " http://www.litres.ru/pages/biblio_book/?art=8954488 Sri Aurobindo. Levelek a jógáról - II: Aditi; Szentpétervár; ISBN 5-7938-0029-8 Absztrakt Jelenleg...»

«A "SAFMAR" JÓTÉKONYSÁGI ALAPÍTVÁNY PROGRAMJA 2014 Tartalom Az Alapítványról 3 Az Alapítvány alapítójának címe 4 Vezető testületek 5 Az Alapítvány 2014. évi költségvetése 6 Célprogramok 6 Az Alapítvány programjai 7 Program...»

2017 www.site - "Ingyenes e-könyvtár- különféle dokumentumok

Az oldal anyagai áttekintésre kerültek fel, minden jog a szerzőket illeti.
Ha nem ért egyet azzal, hogy anyaga felkerüljön erre az oldalra, kérjük, írjon nekünk, 1-2 munkanapon belül eltávolítjuk.

Elérhetőség

Alapfogalmak

Az információs rendszer bizonyos szolgáltatások (szolgáltatások) körét nyújtja felhasználóinak. Azt mondják, hogy ezeknek a szolgáltatásoknak a kívánt elérhetőségi szintje akkor érhető el, ha a következő mutatók a megadott határokon belül vannak:

• Szolgáltatási hatékonyság. Egy szolgáltatás hatékonyságát a maximális kérés szolgáltatási ideje, a támogatott felhasználók száma stb. határozzák meg. Szükséges, hogy a hatásfok ne essen egy előre meghatározott küszöb alá.
• nem elérhető idő. Ha az információs szolgáltatás hatékonysága nem felel meg a megszabott korlátozásoknak, a szolgáltatás elérhetetlennek minősül. Elõírt, hogy az elérhetetlenségi idõszak maximális idõtartama és egy bizonyos idõszakra (hónapra, évre) vonatkozó teljes elérhetetlenségi idõ ne haladja meg az elõre meghatározott határokat.

Lényegében az szükséges, hogy az információs rendszer szinte mindig a kívánt hatékonysággal működjön. Egyes kritikus rendszereknél (például vezérlőrendszereknél) az állásidőnek nullának kell lennie, „majdnem” nélkül. Ebben az esetben az elérhetetlenségi helyzet bekövetkezésének valószínűségéről beszélünk, és megköveteli, hogy ez a valószínűség ne haladja meg az adott értéket. A probléma megoldására speciális hibatűrő rendszereket hoztak létre és hoznak létre, amelyek költsége általában nagyon magas.

A túlnyomó többségnek kereskedelmi rendszerek kevésbé szigorú követelményeket támasztanak, de a modern üzleti élet itt meglehetősen szigorú megszorításokat támaszt, amikor a kiszolgált felhasználók száma ezerben mérhető, a válaszidő ne haladja meg a néhány másodpercet, az elérhetetlenségi idő pedig ne haladja meg az évi több órát.

A kliens/szerver technológiába épített modern konfigurációknál meg kell oldani a magas rendelkezésre állás biztosításának feladatát. Ez azt jelenti, hogy a teljes láncot védeni kell – a felhasználóktól (esetleg távoli) a kritikus szerverekig (beleértve a biztonsági szervereket is).

Az akadálymentesítést fenyegető fő veszélyekkel korábban foglalkoztunk.

A GOST 27.002 szerint a meghibásodás olyan eseménynek minősül, amely a termék teljesítményének megsértését jelenti. Jelen munka keretében a termék egy információs rendszer vagy annak komponense.

A legegyszerűbb esetben úgy tekinthetjük, hogy egy összetett termék bármely komponensének meghibásodása általános meghibásodáshoz vezet, és a meghibásodások időbeli eloszlása ​​az események egyszerű Poisson-folyamata. Ebben az esetben kerül bevezetésre a meghibásodási ráta és a meghibásodások közötti átlagos idő fogalma, amelyeket a kapcsolat kapcsol össze

Rizs. 13.1.

ahol én- alkatrészszám,

λ i – meghibásodási arány,

T i az átlagos idő a kudarcok között.

A független komponensek meghibásodási aránya összeadódik:

Rizs. 13.2.

és a meghibásodások közötti átlagos időt egy összetett termék esetében az arány adja meg

Rizs. 13.3.

Már ezek az egyszerű számítások azt mutatják, hogy ha van olyan komponens, amelynek meghibásodási aránya jóval nagyobb, mint a többié, akkor ez az összetevő határozza meg a teljes meghibásodások közötti átlagos időt. tájékoztatási rendszer. Ez elméleti igazolása annak az elvnek, hogy először a leggyengébb láncszemet erősítsük meg.

A Poisson-modell egy másik nagyon fontos szempont alátámasztását teszi lehetővé, hogy a magas rendelkezésre állású rendszerek kiépítésének empirikus megközelítése nem valósítható meg ésszerű időn belül. Egy szoftverrendszer hagyományos tesztelési/hibakeresési ciklusában optimista becslések szerint minden hibajavítás exponenciális (körülbelül fél tizedes nagyságrenddel) csökkenését eredményezi a hibaarányban. Ebből következik, hogy ahhoz, hogy a tapasztalatok alapján ellenőrizni lehessen, hogy a szükséges rendelkezésre állási szintet elérték, függetlenül az alkalmazott tesztelési és hibakeresési technológiától, a meghibásodások közötti átlagos idővel csaknem egyenlő időt kell tölteni. Például ahhoz, hogy a meghibásodások közötti átlagos idő 105 óra legyen, több mint 104,5 órára lenne szükség, ami több mint három év. Ez azt jelenti, hogy a magas rendelkezésre állású rendszerek felépítéséhez más módszerekre van szükségünk, olyan módszerekre, amelyek hatékonysága a számítástechnika és programozás több mint ötven éves fejlődése során analitikusan vagy gyakorlatilag bizonyított.

A Poisson-modell olyan esetekben alkalmazható, amikor az információs rendszer egyetlen hibapontot tartalmaz, vagyis olyan komponenseket, amelyek meghibásodása az egész rendszer meghibásodásához vezet. A redundáns rendszerek tanulmányozására más formalizmust alkalmaznak.

A probléma megfogalmazásával összhangban feltételezzük, hogy a termék által nyújtott információs szolgáltatások hatékonyságának van mennyiségi mérőszáma. Ebben az esetben bemutatjuk az egyes elemek eredményességét és a teljes komplex rendszer működésének eredményességét jelző indikátorok fogalmait.

A rendelkezésre állás mértékeként az információs rendszer által nyújtott szolgáltatások hatékonyságának elfogadhatóságának valószínűségét vehetjük figyelembe a vizsgált időszakban. Minél nagyobb a rendszer hatékonysági határa, annál nagyobb a rendelkezésre állása.

Ha a rendszer konfigurációjában redundancia van, annak a valószínűsége, hogy a szóban forgó időszakban az információs szolgáltatások hatékonysága nem esik a megengedett határ alá, nemcsak az összetevők meghibásodásának valószínűségétől függ, hanem a működési időtől is. amelyek működésképtelenek maradnak, mivel ebben az esetben a teljes hatékonyság csökken, és minden további meghibásodás végzetes lehet. A rendszer rendelkezésre állásának maximalizálása érdekében minimálisra kell csökkentenie az egyes összetevők állásidejét. Ezenkívül szem előtt kell tartani, hogy általában véve a javítási munkákhoz szükség lehet a hatékonyság csökkentésére vagy akár az egészséges alkatrészek ideiglenes leállítására is; ezt a fajta befolyást is minimalizálni kell.

Az „IT infrastruktúra mint szolgáltatás”, az IaaS szolgáltatások egyre népszerűbbek a vállalati ügyfelek körében, és már használják is őket.és a kritikus feladatokhoz. Ideje kitalálnimit garantálnak és milyen felelősséget vállalnak ezen szolgáltatások szolgáltatói olyan esetekben, amikor a virtuális informatikai infrastruktúra lelassítja a munkát, vagy teljesen elérhetetlenné válik.

Interjút készítettünk vezető vállalati szintű IaaS infrastruktúra-szolgáltatókkal, és elemeztük kínálatukat. Ugyanakkor a „vállalati szint” a következőket jelenti: a felhőplatform olyan adatközpontban van telepítve, amely megfelel a Tier III követelményeinek (az Uptime Institute tanúsítványának megléte nemszükséges), és magas szintű hibatűrést biztosít a magas rendelkezésre állási (HA) mechanizmusok és a virtuális gépek katasztrófa esetén történő áthelyezése révén.

ELÉRHETŐSÉG ÉS VÁLASZIDŐ

Az IaaS szolgáltatás fő paraméterei, amelyeket általában az SLA-szerződésben feltüntetnek, a rendelkezésre állás szintje, a különböző incidensekre adott válaszidő és azok megoldásának időtartama, valamint az állásidő esetén történő kompenzáció sémája és paraméterei. .

Miután úgy döntött, hogy virtuális IT-infrastruktúrát használ, nyugodtan számíthat a 99,5%-os vagy magasabb rendelkezésre állásra. Legalábbis az általunk megkérdezett szolgáltatók egyike sem említett alacsonyabb számot. Sőt, számos cég képviselője hangsúlyozta, hogy a válaszukban feltüntetett érték (lásd 1. táblázat) jellemző, és a megrendelő kérésére a rendelkezésre állás szintje növelhető különféle technikai eszközökkel.

A vállalati szintű IaaS-platformokat általában olyan (saját vagy külső) adatközpontokban tárolják, amelyek megfelelnek a Tier III-as hibatűrésnek, amelyről ismert, hogy 99,98%-os rendelkezésre állást kínál. Az IaaS virtuális infrastruktúrák szolgáltatók által jelzett elérhetőségi értékei nem haladják meg a fizikai oldal megfelelő jellemzőit, ami teljesen természetes.

A kivétel a Dataline által biztosított 99,99%-os rendelkezésre állás metro klaszter módban. A katasztrófának ez a változata A felhő a cég két adatközpontját fedi le – a metróklaszterről bővebben a Journal of Networking Solutions / LAN 2013. októberi számában megjelent „Katasztrófabiztos felhő „nem felhős” áron” című anyagában olvashat ( ).

Elvileg a szállító az SLA-ban tetszőlegesen magas, legalább 100%-os rendelkezésre állást határozhat meg, de akkor többet veszít, mint keres, mert minden épeszű vevő követelni fogja, hogy a szerződésben szigorú kompenzációs rendszer szerepeljen a szerződésben foglaltak elmulasztása esetén. megállapodott feltételek. Amíg bármelyik tipikus séma még nincs kidolgozva - minden szállító mást kínál, ezért a vevőnek értékelnie kell a javasolt ellentételezést, figyelembe véve az IT szolgáltatások leállása esetén felmerülő esetleges anyagi veszteségeket.

Sok cég kínál némi visszatérítést havi fizetés(százalékban) a szolgáltatás minden további (az SLA-ban meghatározottat meghaladó) elérhetetlensége után. Például, ha az SLA-ban meghatározott 99,95%-os rendelkezésre állási szint (leállás nem haladja meg a havi 1 órát), minden további órányi szolgáltatás leválasztás után az Inoventica kész a havi fizetés 2%-át visszatéríteni. A Cloud4Y a standard verzióban 1%-ot kompenzál az 1 órás leállásért (a számítások a szolgáltatás teljes költségét az ezt megelőző teljes naptári hónapra), de legfeljebb a szolgáltatás költségének 50%-át.

Számos szolgáltató részletes számításokat készített arra vonatkozóan, hogy a kompenzáció hogyan változik a rendelkezésre állási szint szerint (lásd a 2. táblázatot). Ennek a szintnek a jelentős csökkenése esetén igen jelentős kompenzációt ajánlanak fel. Például, ha az érték kevesebb, mint 95%, az Onlanta (Lanit cégcsoport) lehetővé teszi a szolgáltatás fizetési szintjének 40%-ra történő csökkentését. Az IT-Grad cég pedig, ha a rendelkezésre állási szint 96,71% alá süllyed, 50%-os kompenzációt ígér. Nyilvánvaló, hogy a szolgáltatók valószínűtlennek tartják a szolgáltatások minőségének ilyen mértékű romlását.

„Két független kompenzációs elvet vezettünk be: a szolgáltatási paraméterek célmutatóinak megsértéséért és a kérések feldolgozásának célmutatóiért” – mondja Vitalij Mzokov, a Servionika (I-Teco csoport) felhőszolgáltatások és infrastrukturális megoldások vezetője. - A szolgáltatási paraméterek célmutatóinak megsértése progresszív skálán kerül kompenzációra. A rendelkezésre állás tényleges szintjétől függően kompenzációs mutató kerül kiszámításra, amely a szolgáltatás igénybevételére vonatkozó számla összegének százalékában van kifejezve. A kérések feldolgozása során felmerülő célok megsértéséért járó kártérítést az ügyfél várakozási ideje alapján számítják ki, legfeljebb egy perces pontossággal.

A Servionika által elfogadott gyakorlat szerint a vevői kérések típusait, valamint a kérésekre adott maximális válaszidőre és a probléma megoldásának maximális idejére vonatkozó általános célokat a szolgáltatási interakciós szabályzat tartalmazza. És magában az SLA-szerződésben ezek a mutatók egy adott szolgáltatáshoz vannak megadva.

„A szerződés értelmében a megrendelő több szolgáltatást is igénybe vehet tőlünk. Ezért a rendelet az általános mutatókat egy megjegyzéssel írja le: „Az SLA-ban meghatározott célmutatók egy adott szolgáltatásra átfedésben vannak a rendeletben meghatározott mutatókkal.” Ez azért történik, hogy szükség esetén a reakcióidő és a megoldási idő pontosítása (hosszabbítása vagy csökkentése) lehetővé váljon – magyarázza Vitalij Mzokov. - Bármilyen megkeresésre 15 percen belül kötelesek vagyunk válaszolni. A maximális megoldási idő a kérés típusától és prioritásától függően 1 órától (1. prioritású incidenseknél) 48 óráig (olyan kéréseknél, amelyeknél az ügyfél információigényének teljes körű feldolgozását igényli – például információszolgáltatást) tarifákról és egyéb szolgáltatásokról, különféle pontosításokról és utasításokról).

Az alkalmazás válaszideje általában a prioritásától függ. Például itt vannak a Linxdatacenter által alkalmazott prioritási szintek:

• Kritikus - a szolgáltatás nem teljesen elérhető, sürgős intézkedéseket kell hozni a helyreállításhoz, a reakcióidő 15 perc, a helyreállítási idő nem haladja meg a 4 órát;
• Magas – a szolgáltatás részben nem elérhető, válaszidő akár 1 óra, magas prioritású;
• Normál - a szolgáltatás paramétereinek pontosítása, aktuális, nem sürgős kérdések, válaszidő legfeljebb 1 óra, 24 óra áll rendelkezésre a válasz elkészítésére.

A 3. táblázat egy másik példát mutat be – a Cloud4Y által használt lekérdezések kategorizálása; reakcióidő - legfeljebb 30 perc.

Azonnal próbál dolgozni a T-Systemsben. Vsevolod Jegupov, a T-Systems RUS ICT részlegének értékesítési igazgatója szerint a cég szakemberei "az esetek 80%-ában 30 másodpercen belül válaszolnak" (!). De mint a legtöbb válaszadónk, ő is megjegyezte, hogy a válaszidő a helyzet kritikusságától függ.

MONITORING ESZKÖZÖK

Az SLA-szerződésben nem elegendő a vonzó rendelkezésre állási szintet és a merev kompenzációs sémákat meghatározni, hanem kényelmes és hatékony vezérlőeszközt is kell biztosítani az ügyfél számára. És itt a beszállítók megközelítései jelentősen eltérnek.

Vitalij Mzokov a Servionika gyakorlatára hivatkozva megjegyzi, hogy az ügyfelek jobban érdekeltek abban, hogy átlátható és pontos jelentéseket kapjanak az üzemeltetőtől, mintsem a független megfigyeléshez szükséges speciális eszközök elsajátítása. A Servionika főszabály szerint havi jelentést készít egy egyeztetett paraméterkészletről, de az ügyfél kérésére a szerződés gyakoribb jelentéstételt is előírhat.

Sok cég alapértelmezés szerint havonta egyszer ad szolgáltatás állapotjelentést, de ezt gyakrabban is megteheti - az ügyfelek kérésére. Az Onlanta által kínált jelentésre egy példa látható az 1. ábrán. Mikhail Lyapin, felhő részlegének vezetője szerint az Onlanta az egyetlen vállalat Oroszországban, amely ilyen részletességű jelentést készít az ügyfeleknek a felhőalapú erőforrások elérhetőségéről. Elmondása szerint a legtöbb szolgáltató beéri a virtuális gépek elérhetőségi szintjével kapcsolatos statisztikákkal.

Számos vállalat kínál ügyfeleinek online önkiszolgáló konzolt. Ruslan Zaedinov vezérigazgató-helyettes, a Croc adatközponti és felhőalapú számítástechnikai részlegének vezetője szerint minden IaaS-szolgáltatás fogyasztója hozzáfér egy ilyen konzolhoz, amely beépített képességgel rendelkezik bizonyos összetevők működésének online megfigyelésére. Például a virtuális gépek esetében az ügyfél informatikusai nyomon követhetik, hogy a processzor mennyire elfoglalt, hogyan működik az I/O, mennyi memóriát használ, stb. Ezek az adatok valós időben, valamint - kérés - statisztikai formában bármely időszakra vonatkozóan.

A TELJESÍTMÉNYT GARANTÁLNI KELL

Nyilvánvaló, hogy a szolgáltató IaaS platformjának terhelésének növekedésével a virtuális gép teljesítményszintje csökkenhet. A szolgáltatók mindent megtesznek annak érdekében, hogy ez ne forduljon elő. Ebben minden cég egyetért. Néhányan azonban teljesítményparamétereket tartalmaznak az SLA-ban, míg mások szükségtelennek tartják az ilyen mértéket.

Vitalij Slizen, az Inoventica igazgatótanácsának tagja a következőket mondja erről: „Még a terhelés növekedésével sem észlelünk [teljesítményromlást], hiszen időben bővítjük és modernizáljuk az adatközpontok kapacitásait módon. Külön-külön ezek a paraméterek (VM és tárolási teljesítmény) nem jelennek meg az SLA-ban, mivel ezek betartása elsődleges felelősségünk, függetlenül az ügyfelek kérésétől. Az Inoventica szakemberei folyamatosan figyelemmel kísérik a bérelt infrastrukturális létesítmények összes fő paraméterét, ami lehetővé teszi számukra, hogy gyorsan tájékozódjanak a lehetséges problémákról, és időben előre jelezzék azokat.

Igor Drozdov, a Linxdatacenter értékesítési technikai támogatási menedzsere is a degradáció hiányáról beszél: „Cégünk garantált számítási erőforrásokat biztosít a használatra. A felhőben vannak lefoglalva, és az ügyfelek számának növekedésével bővülnek, így a virtuális gépek és a tárhely teljesítménye folyamatosan magas szinten marad. Ezen kívül időszerű szerverfrissítéseket hajtunk végre, és speciális VMware-termékekkel teljesítményfigyelést végzünk.”

Az Orange Business Services szintén azon szolgáltatók közé tartozik, amelyek nem szabályozzák a teljesítményparamétereket a szabványos SLA-ban. Ugyanakkor, amint azt Dmitrij Dorodnyik, az Orange Business Services oroszországi és a FÁK-országok egységes kommunikációs és informatikai termékfejlesztési részlegének vezetője megjegyezte, „ha egy ügyfél bizonyos számítási erőforrásokat igényel virtuális gépeihez, akkor alkalmazzuk szabvány azt jelenti modern virtualizációs platformok, amelyek az erőforrásokért folytatott versengés esetén lehetővé teszik a virtuális gépek más szerverekre való áthelyezését.

Vsevolod Egupov úgy véli, hogy nincs értelme teljesítményjellemzőket belefoglalni az SLA-ba, mivel a leromlás befolyásolja a szerződésben szabályozott szolgáltatás elérhetőségi szintjét. A T-Systemsnél a virtuális gépek és tárolórendszerek teljesítményét a kapacitásmenedzsment részleg ellenőrzi, amelynek szakemberei felelősek annak leromlásának megakadályozásáért.

Sok vállalat úgy véli, hogy van értelme teljesítményjellemzőkkel kiegészíteni az SLA-kat. A szűk keresztmetszet virtualizált informatikai környezetben, sok szakértő a tárolási teljesítményt tartja szem előtt, így a legtöbb szállító fizet a legtöbbet fokozott figyelmet tárolási jellemzők, például bemeneti/kimeneti műveletek másodpercenként (IOPS)és a lemezelérési idő (latencia).

A Dataline az egyes SLA-kban felsorolja a tárolási és a virtuális gépek teljesítménymutatóit (lásd: 4. táblázat). Ugyanakkor, amint Dmitrij Tishin, a vállalat szolgáltatásfejlesztési osztályának vezetője megjegyzi, „az ügyfél által a rendszerrel szemben támasztott követelményektől függően a mutatók módosíthatók”. Az IOPS értékeket a NetApp DFM figyelőrendszer méri, a lemezelérési időt pedig szabványos virtualizációs szoftvereszközök (vCenter) mérik. A virtuális géppel kapcsolatos probléma esetén az ügyeleti műszak és a virtualizációs csapat mérnökei megfelelő figyelmeztetést kapnak. Ezenkívül a Dataline monitorozást is biztosít különféle lehetőségek az operációs rendszer és a benne futó szolgáltatások szintjén. Ha az ügyfél a vállalat operációs rendszer- és szolgáltatásadminisztrációs szolgáltatását veszi igénybe, az ilyen megfigyelés alapértelmezés szerint megtörténik.

A virtuális gépek teljesítményének romlásának megakadályozása érdekében a Dataline szakemberei egy sor intézkedést alkalmaznak. Tehát egy fürtnél a Distributed Resource Scheduler (DRS) mechanizmust használják, amely a fő paraméterek szerint figyeli a fizikai szerverek terhelését - ha elér egy bizonyos terhelést a szerveren, a virtuális gépek egy része automatikusan átkerül egy másikra. . A fürt fenntartja a szerverredundanciát, így a teljes fürt terhelése nem haladja meg a 70%-ot. Az eszközszállítókkal kötött szolgáltatási szerződések keretében a klaszterek erőforráskapacitása ütemezetten növelhető.

A Safedata szabályozza a teljesítményjellemzőket is, például az IOPS-t és a MIPS-t az SLA-ban. „Nem csökkenthetjük a teljesítményt az SLA-ban meghatározott értékek alá” – mondja Anton Antonov, a Safedata értékesítési osztályának vezetője. "Ha a szolgáltatás leromlása következik be, amikor a fizikai szerverek terhelése növekszik, további biztonsági mentési EXSi gazdagépek kerülnek működésbe."

Az SLA Cloud4Y-ban szabályozott tárolólemez-rendszer teljesítményjellemzői az 5. táblázatban láthatók. Jevgenyij Bessonov, a Cloud4Y Marketing Osztály vezetője szerint a garanciális feltételek megsértése esetén kompenzációt terveznek, amelyet külön megbeszélnek, vagy az általános feltételek szerint fizetnek: 1 órára a havi költség 1%-a.

„Garantáljuk a virtuális gépek teljesítményét az alsó határon, anélkül, hogy felülről korlátoznánk” – mondja Ruslan Zaedinov. "Így, ha a szerver, ahol a virtuális gép található, a garantáltnál nagyobb ingyenes számítási erőforrásokkal rendelkezik, akkor azok elérhetőek lesznek az ügyfél számára." Ami a tárolórendszereket illeti, jelenleg minden Croc-ügyfél közös kommunikációs csatornát használ a tárolórendszerekkel. Ez sokáig nem okozott gondot, most azonban a növekvő vásárlói igények kielégítésére a cég a felhőalapú tárolást a Fibre Channel és SATA lemezekről flash meghajtókra költözteti, amelyekhez az Infiniband hálózaton keresztül, virtuális gépekről közvetlenül hozzá lehet férni. Ezzel párhuzamosan olyan szoftverek bevezetése zajlik, amelyek garantálják az adattároló rendszer felhőben való átvitelét. Az SLA megfelelő módosításait idén ősszel hajtják végre.

Az ügyféllel egyetértésben a Servionika az egyes projektek SLA-jában rögzíti a felhőplatform egyes összetevőinek teljesítménymutatóit. Ezen túlmenően a megállapodás meghatározza ezen mutatók mérési módszereit és a mérések gyakoriságát. Bármelyik operátor írhat „garantált 100 500 OP 1 GB lemezterületre”, de nem mindenki tudja bizonyítani, hogy ez a kritérium teljesül. A felhőplatform üzemeltetője és fogyasztója közötti legátláthatóbb kapcsolatért vagyunk” – hangsúlyozza Vitalij Mzokov. A virtuális gépek és tárolórendszerek teljesítményét a Servionika SLA-ban az IOPS és a Latency indikátorok határozzák meg.

Ahogy Maxim Zakharenko mondta, főigazgató"Oblakotéka" szolgáltató, az általuk megkötött szerződésekben a csúcsteljesítmény-mutatókat úgy szabályozzák, hogy az I/O sávszélesség és a hálózat terhelése ne haladja meg a 80%-ot. A felügyelet a Microsoft SCOM rendszerrel történik. Megjegyzi, hogy a különböző rendszerek esetében más-más mutatók fontosak: webhelyek esetén - válaszidő, IT infrastruktúrák üzemeltetése - processzor, memória, virtuális hálózat stb. csúcskihasználtságának mutatói. A cég garantált biztonsági mentési paramétereket is tartalmaz az SLA-jában, módszereiben. valamint a felhasználói adatok biztosítására és tárolására vonatkozó feltételek ("Őszinte elválás").

END-TO-END SLA

Nem számít, milyen magas maga a hibatűrő adatközpontban található IaaS platform megbízhatósága, az ehhez a platformhoz vezető hozzáférési csatornák szűk keresztmetszetekké válhatnak az ügyfél számára. A jó hír az, hogy az általunk megkérdezett szolgáltatók közül sok olyan végponttól végpontig terjedő SLA-t alkalmaz, amely magában foglalja az IaaS szolgáltatást és a hozzáférési csatornákat is. Ugyanakkor szerintük megfelelő szervezésés a csatorna redundanciája, a kommunikációs rendelkezésre állás szintje nem alacsonyabb, mint az SLA platformé, ezért ez a fontos jellemző nem csökken a végpontok közötti SLA-knál.

Amint azonban Vsevolod Jegupov megjegyzi, a rendelkezésre állási szint csökkentése vagy megőrzése a kommunikációs csatornák megszervezésétől függ – ha a csatorna le van foglalva, az elérhetőség nem romlik. Ellenkező esetben a végpontok közötti SLA rendelkezésre állási szintje a csatorna rendelkezésre állási szintjére csökken. A T-Systems RUS saját adatközpont-hálózattal rendelkezik szerte a világon. Az orosz ügyfeleket elsősorban Németországban és Ausztriában található adatfeldolgozó központokból szolgálják ki. A cég SLA-t írt alá a Rostelecom-mal, a Beeline-nal, és más távközlési szolgáltatókkal is együttműködik.

Azok az IaaS szolgáltatók, akik egyben távközlési szolgáltatók is, kihasználják ezt. Így nemzetközi távközlési szolgáltatóként az Orange Business Services végponttól végpontig terjedő SLA-kat alkalmaz, amelyek lefedik az IaaS-t és a távközlési szolgáltatásokat. Az ilyen SLA-k elérhetőségi szintje 99,95%. De amint Dmitrij Dorodnykh kifejti, ez a jellemző az ügyfél földrajzi elhelyezkedésétől függ - például a középső régióban ez a szint magasabb, mint az Urálon túl és Szibériában. Az utolsó mérföldnek lehetnek saját SLA paraméterei. A kommunikációs csatornákon az SLA vezérlési sémák és mechanizmusok már évtizedek óta kidolgozottak, így az Orange Business Services számára nem jelent problémát a monitorozás kérdése.

Mint Vitaly Slizen megjegyzi, az Inoventica saját gerinchálózati kommunikációs csatornákkal és földrajzilag elosztott adatközpont-hálózattal rendelkezik, amely lehetővé teszi a geoclusterek megvalósítását. Ez lehetővé teszi az adatok és a szolgáltatási teljesítmény megtakarítását még az egyik adatközpont fizikai megsemmisülése esetén is. Elmondása szerint az Inoventica "az egyetlen olyan vállalat az orosz piacon, amely teljes körű szolgáltatási láncot nyújt" DPC - csatorna - szolgáltatás - kliens (AWP) "az SLA-nak megfelelően, amely a minimumcsomagátviteli késleltetés (oda-vissza késés) kevesebb, mint 10 ms, és szinte nulla csomagvesztés. Jelenleg az Inoventica komplex megoldása az Orosz Föderáció öt szövetségi körzetében áll az ügyfelek rendelkezésére.

Azok az IaaS szolgáltatók, amelyek nem szolgáltatók, aktívan együttműködnek velük. Így a Servionika SLA-t hozott létre, hogy együttműködjön az adatközpontját kiszolgáló távközlési szolgáltatókkal (több mint 10 nagy távközlési szolgáltató). A vállalat ezen SLA-k feltételeit a kommunikációs szolgáltatásokat igénybe vevő ügyfelekkel kötött szerződésekben közvetíti. Az SLA betartásának ellenőrzését pedig a TrustInfo adatközpont műszaki szolgálatai biztosítják. „Szerződéseinkben ugyanazokat az SLA paramétereket határozzuk meg, mint az üzemeltetőké, azaz felelősséget vállalunk munkájuk minőségéért és a kommunikációs csatornák zavartalan biztosításáért” – jegyzi meg Vitalij Mzokov.

Az ügyfelek kommunikációs csatornáinak biztosítására a Dataline a távközlési szolgáltatók szolgáltatásait veszi igénybe alvállalkozói konstrukció keretében. Ezzel a konstrukcióval a cég az üzemeltetővel kötött szerződése keretein belül ellenőrzi a minőséget, miközben az ügyfél átfogó szolgáltatást kap tőle, és csak egy partnerrel áll kapcsolatban. Egy ilyen átfogó szolgáltatás elérhetőségi szintje nem csökken. A Dataline saját adatátviteli hálózattal rendelkezik Moszkvában, ahol a következő jellemzők garantáltak: az elveszett csomagok százaléka nem haladja meg a 0,2%-ot, a hálózat átlagos késése nem haladja meg az 5 ms-ot.

Ruslan Zaedinov szerint a Croc széles csatornákat használ, amelyek sávszélessége minden ügyfél számára elegendő a felhőben. Műszakilag hatékony garanciákat biztosít a csatornák keresztfoglalása a különböző Croc adatközpontok között, saját optikai gyűrűvel. Azon szervezetek számára, amelyek számára kritikus a kommunikációs csatorna fix sávszélessége, a vállalat külön csatornákon keresztül egyedi kapcsolatot valósít meg a felhővel, garantált áteresztőképesség vagy akár "sötét" optikán. Egy ilyen kapcsolat leggyakrabban fel van szerelve egyéni eszközökkel titkosítás, beleértve a hitelesítetteket is.

Tehát az IaaS szolgáltatásokat Oroszországban meglehetősen sok vállalat kínálja, és teljesen érthető és dokumentált (SLA) szabályok szerint. Az iparág még nem ért egyet abban, hogy az SLA-knak foglalkozniuk kell-e a virtualizált IT-infrastruktúrák teljesítményjellemzőivel, de a garantált rendelkezésre állási arány még a legigényesebb vállalati ügyfelek számára is elég jónak tűnik. Ezenkívül a szolgáltatók megértik az ügyfelek végpontok közötti SLA-k iránti igényét, és dolgoznak azok fejlesztésén.

Alekszandr Barskov- A Journal of Network Solutions / LAN vezető szerkesztője. Kapcsolatba léphet vele:

A magas rendelkezésre állás olyasvalami, amit az emberek szeretnek számokban mutogatni. Mindenki hozzászokott már a marketing lépésekhez, és a 99% elérhetősége fantasztikusan magasnak tűnik. Csak a vásárlók kis része érti meg, hogy a 98-99%-os elérhetőség nagyon rossz, néha értéktelen adat.

Tekintse meg ezeket a számokat, és meg fogja érteni, miben tér el a 90%-os elérhetőség a 99,999%-os elérhetőségtől:

Elérhetőség	Leállás havonta	Évente leállás
90%	3 nap	37 nap
98%	14,6 óra	7,3 nap
99%	7,3 óra	3,7 nap
99,8%	1,5 óra	18 óra
99,9%	44 perc	8,8 óra
99,99%	4,4 perc	53 perc
99,999%	26 mp	5,3 perc

A fenti táblázatból kiderül, hogy egy 99%-os hálózati rendelkezésre állást garantáló adatközpont havi 7 óra állásidőt enged meg magának. Képzelje el ezt a helyzetet: az adatközpontban egész nap javítanak valamit, az oldala nem elérhető, Ön veszteséget szenved, és az adatközpontnak nem tud reklamálni - ebben a helyzetben is biztosítja az ígért elérhetőséget.

99%-os hálózati elérhetőséget rossznak tartok. Inkább azokat az adatközpontokat részesítem előnyben, amelyek legalább 99,9%-os hálózati rendelkezésre állást biztosítanak.

Valószínűleg vannak olyan internetes projektek, amelyek évente 37 nap leállást képesek túlélni (több mint egy hónapot!). Ennek ellenére a legtöbb online áruház, portál és oldal (főleg azok, amelyek tranzakciói az oldalon keresztül zajlanak) nem engedhetnek meg maguknak olyan luxust, mint az évi 18 óra. A hírnevet mindig nehéz helyreállítani, és ha „a rendszergazdának szabadnapja van” okokból elveszik, az teljesen sértő.

Az „öt kilences” a magas rendelkezésre állás

Az „öt kilences” kifejezés 99,999%-os rendelkezésre állást jelent, és a marketing szakirodalomban ugyanolyan gyakran megtalálható, mint a szakirodalomban. Úgy gondolják, hogy az "öt kilences" rendelkezésre állási szinttel rendelkező webhely vagy rendszer magas rendelkezésre állást jelent.

Mindenkinek magas rendelkezésre állásra van szüksége

A táblázat azt mutatja, hogy a 99,999%-os rendelkezésre állás mindössze 5,3 perc leállást jelent évente. De még a 100%-os rendelkezésre állást garantáló adatközpontok is gyakran alkalmaznak marketingtrükköket.
Például vonja le az ütemezett karbantartási időt a rendelkezésre állási időből. Például egy adatközpont 99,99%-os rendelkezésre állást ígér, de abban a pillanatban ütemezett munka valami cserénél azt írja, hogy "2 órán belül karbantartási munka folyik" és ezt nem tartja elérhetetlennek. Innen a következtetés – figyelmesen olvassa el a szolgáltatási szint megállapodást (SLA).

Ha egyetlen szerveren szeretné biztosítani webhelye legmagasabb rendelkezésre állását, válasszon olyan adatközpontot, amely jó elérhetőséggel rendelkezik GARANTÁLT SLA-val (szolgáltatási szint megállapodás).

Jegyzet! Az SLA-nak garantálnia kell a meghibásodott hardver cseréjének idejét. És ideális esetben válaszidő a problémára.

Ezenkívül az adminisztrátornak figyelemmel kell kísérnie a szolgáltatás működését, és gyorsan reagálnia kell az elérhetetlenségre.

Egy kicsit arról, hogy mitől magas a rendelkezésre állás

Az elérhetőség lehet hálózat és szolgáltatás.

Hálózat elérhetősége amikor a szerver elérhető a hálózaton keresztül.
A szolgáltatás elérhetősége amikor a szerver ki tudja szolgálni az ügyfeleket.

A szolgáltatás elérhetősége nem lehet jobb, mint a hálózati elérhetőség, ha nem használ alternatív kapcsolatokat (saját hálózati elérhetőséggel).

A szolgáltatás elérhetősége a következőktől függ:

• a szerver hálózati elérhetősége
• az adminisztrátor problémára adott reakciójának sebessége
• az adatközpont-támogatás válaszának sebessége egy problémára
• a hibás hardver cseréjének sebessége az adatközpontban

Az elérhetetlenség a következőkből áll:

• hálózati hozzáférési problémák
• problémák a hardverrel
• problémák a szerver terhelésével ("lelassul", nem tud megbirkózni)
• szoftverhibák (programozók „jambjai”)

És havi (kivéve hardver meghibásodás esetén) és még inkább éves rendelkezésre állása 99,8% egy jó DC-ben egy szerveren további hibatűrési intézkedések nélkül. A 99,9%-os elérhetőséghez már szerencse is kell.

Ha 99,8% feletti garantált rendelkezésre állásra van szüksége, akkor foglalkoznia kell a hibatűréssel. És a szerver ne legyen egyedül. De ez egy külön beszélgetés témája.

|

A méretezhetőség és a magas rendelkezésre állás egyre népszerűbb, ahogy a kritikus rendszerek kiszolgálására tervezett megbízható, nagy teljesítményű infrastruktúrák iránti kereslet növekszik. Az állásidő csökkentése és az egyes meghibásodási pontok kiküszöbölése ugyanolyan fontos, mint a megnövekedett rendszerterhelés kezelése. A magas rendelkezésre állás az infrastruktúra minősége, amely képes ezeket kiküszöbölni.

Ez a cikk pontosan elmagyarázza, mit jelent a „magas rendelkezésre állás” kifejezés, és hogyan teheti ez a minőség megbízhatóbbá az infrastruktúrát.

Magas rendelkezésre állás

A programozásban az "elérhetőség" kifejezést arra használják, hogy leírják, mennyi ideig áll rendelkezésre egy szolgáltatás, és mennyi időbe telik a rendszernek, hogy válaszoljon a felhasználói kérésekre. A magas rendelkezésre állás egy rendszer vagy alkatrész minősége, amely magas szintű teljesítményt biztosít egy bizonyos ideig.

Hozzáférhetőség mérése

A rendelkezésre állást gyakran százalékban fejezik ki, ami azt jelzi, hogy egy adott rendszertől vagy komponenstől egy adott időszak alatt milyen üzemidőt várnak. Ebben az esetben a 100%-os rendelkezésre állás azt jelenti, hogy a rendszer soha nem áll le; ennek megfelelően egy éven belül 99%-os rendelkezésre állást biztosító rendszerben akár 3,65 napos leállás is előfordulhat (1%).

Ezeket az értékeket számos tényező alapján számítják ki, beleértve az ütemezett és nem tervezett karbantartást, valamint az esetleges rendszerhiba megoldásához szükséges időt.

Hogyan működik a magas rendelkezésre állás?

A magas rendelkezésre állást a hibákra való gyors reagálás mechanizmusaként használják. Ez a mechanizmus meglehetősen egyszerű, de általában speciális szoftvert és konfigurációt igényel.

Mikor van szükség magas rendelkezésre állásra?

A leállások és a szolgáltatáskimaradások minimalizálása elengedhetetlen a hibatűrő gyártási rendszerek kiépítéséhez. Bármennyire is megbízható a rendszer és szoftver, a rendszer olyan problémákat tapasztalhat, amelyek az alkalmazás vagy a kiszolgáló összeomlását okozhatják.

Az infrastruktúra magas rendelkezésre állása jó stratégia ezen események valószínűségének és hatásának csökkentésére. A magas rendelkezésre állású rendszerek meghibásodás után automatikusan helyreállíthatják a szervert vagy az összetevőt.

Mi tesz egy rendszert magasan elérhetővé?

A magas rendelkezésre állás egyik célja az infrastruktúra egyetlen meghibásodási pontjának kiküszöbölése. Az egyetlen meghibásodási pont olyan verem-összetevő, amelynek meghibásodása miatt az egész rendszer leépül, vagy az adatok elérhetetlenné válnak; vagyis minden olyan összetevő, amely az alkalmazás működésének előfeltétele, egyetlen hibapontnak minősül.

Az egyes meghibásodási pontok kiküszöbölése érdekében a verem minden rétegét fel kell készíteni a redundanciára. Példaként képzeljük el, hogy van egy infrastruktúrája, amely két azonos redundáns webszerverből áll, terheléselosztóval. A kliensektől érkező forgalom egyenletesen oszlik el a webszerverek között, de ha valamelyik szerver leáll, a terheléselosztó az összes forgalmat a fennmaradó webszerverre irányítja át.

Ebben a helyzetben a webszerver nem egyetlen hibapont, mert:

• A fürtben van egy „tartalék” komponens, amely minden feladatot képes ellátni.
• Egy másik szinten létezik egy mechanizmus (terheléselosztó), amely képes észlelni az összetevők hibáit, és viselkedését módosítani az alkalmazás időben történő visszaállításához.

De mi van, ha a terheléselosztó meghibásodik?

A leírt forgatókönyvben (ami meglehetősen gyakori) az egyetlen hibapont pontosan a terheléselosztó.

Ennek a kudarcpontnak a megszüntetése nem olyan egyszerű. Természetesen könnyedén beállíthat egy további terheléselosztót, amely redundanciát biztosít, de a rendszerben a terheléselosztók felett nincs olyan alkatrész, amely átvehetné a hibafelismerést és -helyreállítást.

A redundancia önmagában nem garantálja a magas rendelkezésre állást.

Az infrastruktúra hibáinak észleléséhez és kijavításához speciális összetevőnek kell lennie.

A hibaészlelés és helyreállítás a top-to-bottom módszerrel valósítható meg: a felső réteg figyeli az alsó réteg hibáit. Térjünk vissza példánkhoz; egy ilyen klaszterben a terheléselosztó a felső réteg. Ha az egyik webszerver (az alsó réteg) elérhetetlenné válik, a terheléselosztó leállítja a kérések átirányítását.

Ez a megközelítés meglehetősen egyszerű, de megvannak a korlátai: mindig lesz olyan pont az infrastruktúrában, ahol a felső réteg hiányzik vagy nem érhető el (mint a terheléselosztó esetében). Hibaészlelési szolgáltatás létrehozása egy külső kiszolgálón lévő terheléselosztóhoz olyan, mint egy új, egyetlen hibapont létrehozása.

Ebben a forgatókönyvben elosztott megközelítésre van szükség. Több duplikált csomópontot kell klaszterezni, ahol mindegyik csomópont egyformán képes lesz észlelni és kijavítani a hibát.

A terheléselosztás esetén azonban a névszerverek működéséhez további bonyolultság társul. A terheléselosztó hibájából történő helyreállítás általában a terheléselosztó feladatátvételét jelenti egy másik (redundáns) erőforrásra, és ehhez meg kell változtatni a DNS-t (meg kell adni a készenléti terheléselosztó tartománynevét vagy IP-címét). Az ilyen változtatások jelentős időt vehetnek igénybe, és hosszú leállást eredményezhetnek.

Ilyen helyzetben használhatja a körbefutó egyensúlyozást. Ez a megközelítés azonban nem megbízható, mert a feladatátvétel az alkalmazás ügyféloldalán történik.

Megbízhatóbb és hibatűrőbb megoldás a rugalmas IP-címeket támogató rendszerek. Ha szükséges, az IP-cím módosításra kerül, ami megakadályozza a hiba továbbterjedését és gyorsítótárazását. Ebben az esetben a tartománynév ugyanazzal az IP-címmel maradhat társítva, és maga az IP-cím mozog a szerverek között.

Milyen összetevőkre van szükség a magas rendelkezésre állás támogatásához?

A magas rendelkezésre állás beállításához több rendszerösszetevőt is telepítenie kell. A magas rendelkezésre állás azonban sokkal nagyobb mértékben függ a következő tényezőktől:

• Környezet: Ha az összes fürtkiszolgáló ugyanazon a földrajzi területen található, külső körülmények(földrengés, árvíz stb.) a rendszer teljes meghibásodásához vezethet. A különböző adatközpontokban és földrajzi területeken lévő szerverek jelenléte növeli a hibatűrést.
• Hardver: A magas rendelkezésre állású kiszolgálóknak ellenállónak kell lenniük az áramkimaradásokkal és a hardverhibákkal szemben, beleértve a merevlemezeket és a hálózati interfészeket.
• Szoftver: a teljes szoftvercsomag (beleértve operációs rendszerés magát az alkalmazást) fel kell készíteni az alkalmi összeomlások kezelésére, amelyek rendszer-újraindítást igényelhetnek.
• Adatok: Az adatvesztést és az inkonzisztenciát több tényező is okozhatja. A magasan elérhető rendszereknek figyelembe kell venniük az adatok védelmének szükségességét hiba esetén.
• Hálózat: A nem tervezett hálózati leállások egy másik lehetséges meghibásodási pont a rendkívül megbízható rendszerekben. Fontos, hogy ilyen esetre legyen egy tartalék hálózati stratégia.

Milyen szoftverek szükségesek a magas rendelkezésre álláshoz?

A magas rendelkezésre állású rendszer minden rétegének más-más igénye lesz. Alkalmazási szinten a terheléselosztás elengedhetetlen eleme egy magas rendelkezésre állású rendszernek.

(High Availability Proxy) egy népszerű eszköz a terheléselosztás beállítására, mivel lehetővé teszi a terhelés több szintű kezelését, valamint különféle fajták szerverek, beleértve az adatbázisszervereket.

Az is fontos, hogy a rendszerveremben megbízható eszközt építsenek be az alkalmazás belépési pontjára. Egyetlen hibapont kiküszöböléséhez, amint azt korábban említettük, rugalmas IP-címekkel rendelkező terheléselosztó fürtöt kell megvalósítania. A Corosync-et és a Pacemaker-t használják ilyen rendszerek létrehozására.

Következtetés

A magas rendelkezésre állás az infrastruktúra megbízhatóságának nagyon fontos szempontja, amelynek középpontjában a magas szintű működési teljesítmény biztosítása áll bizonyos időszak idő. Első pillantásra a magas rendelkezésre állás megvalósítása meglehetősen bonyolultnak tűnhet, de számos előnnyel járhat egy fokozott megbízhatóságot igénylő rendszer számára.

Címkék: