Biztonsági mentési szolgáltatások
Egy informatikus számára nincs félelmetesebb az adatvesztésnél. Az adatvesztés megelőzésére a leghatékonyabb stratégia a tárkötetek virtuális gépek, adatbázisok és adatokat tároló más rendszerek biztonsági másolatának elkészítés, hogy az adataik visszaállíthatók legyenek. A felhőszolgáltatók éppen erre a célra kínálják az biztonsági mentési szolgáltatásokat. Általánosságban ezek a szolgáltatások használhatók a helyszínen tárolt és a felhőben tárolt adatok biztonsági mentésére is, a biztonsági másolatok pedig földrajzilag replikálhatók és elmondhatók, hogy védve legyenek egy egész adatközpontot vagy régiót érintő, adatvesztéssel járó eseményekkel szemben.
A nyilvános felhő nagy kapacitású rugalmas erőforrásokat kínál – ezek nem csupán nagy tárolóhelyek, hanem kitűnően méretezhető tárolókészletek. Legalább annyira sokoldalúak, bizonyos esetben sokoldalúbbak is, mint a biztonsági mentési tárrendszerek és szalagos meghajtók, amelyek szerepét átveszik. Olyan új lehetőségeket is kínálnak a vállalatoknak redundancia, feladatátvétel és biztonsági hálók implementálására, amelyeket a többségük nem engedhetett volna meg magának, amíg minden összetevőt a forgótőkéből kellett megvásárolni. A nyilvános felhőtárhely lehetőségei töltik be azt a szerepkört, amelyre az adatközpontokban mindig nagy szükség volt, de a közelmúltig nagyon nehéz volt betölteni.
Felhőalapú biztonsági mentési szolgáltatások
A nyilvános felhőszolgáltatók (CSP-k) által kínált modern biztonsági mentési szolgáltatások közös jellemzője az a mód, ahogyan kiterjesztik az ügyfelek infrastruktúráját. Ezeknek a szolgáltatásoknak a létrejötte előtt a vállalati biztonsági mentési stratégia általában két szintből állt: az adatbázisokat kiszolgáló adatkötetek biztonsági másolatának elkészítéséből és a kritikus fontosságú számítási feladatokat üzemeltető virtuálisgép-lemezképek biztonsági másolatának elkészítéséből. A biztonsági mentés elve az volt, hogy amikor egy rendszerhiba meghibásodáshoz vezet, ez az esemény egy kiszolgáló leállását okozza. Az azonnali teendő ilyenkor visszaállítani ennek a kiszolgálónak az állapotát egy biztonságimásolat-lemezképből.
A felhőalapú infrastruktúra elavulttá teszi a biztonsági mentés régi alapelvét. A modern rendszerekben a kiszolgálókat nem hardver, hanem szoftver alkotja. A virtuális kiszolgálókat vagy olyan hipervizoralapú virtuális infrastruktúrán üzemeltetik, mint a VMware NSX, vagy tárolókból állítják össze és virtualizált operációs rendszereken üzemeltetik. Az alkalmazások és szolgáltatások számítási feladatainak szoftver-rendszerképei mindkét esetben folyamatosan felügyelve, frissítve és védve vannak. Az aktív szoftverösszetevők valójában maguk is ezeknek a védett eredetiknek a replikái, vagy tárolók esetén a tároló-adattárakban őrzött eredeti igény szerint automatikusan összeállított termékei. Egy hardverhiba, amely leállít egy kiszolgáló-csomópontot, csak az ezen a csomóponton üzemeltetett kiszolgálókat teszi elérhetetlenné egy időre. Az infrastruktúra egyszerűen megkerüli a csomópontot a forgalom átirányításával, miközben mindent megtesz a helyreállítására. Az infrastruktúra kezelőjének nincs más feladata, mint amit eddig is el kellett látnia a rendszerfelügyelet keretében.
A modern adatközpontok felületes vizsgálata is elég azonban, hogy kiderüljön, nem minden modern infrastruktúra felhőalapú. Továbbra is futnak szolgáltatások közvetlenül a helyszíni adatközpontok hardverein. Még mindig működnek köztes szoftverrel kiegészülő ügyfél/kiszolgáló rendszerű hálózatok. Egy olyan hibrid rendszerben, amelynek egy néhány éve megtervezett része egy másik, az előző évszázadban tervezett részhez kapcsolódik, továbbra is muszáj elegendő információt tárolni a rendszer felépítéséről ahhoz, hogy katasztrófa esetén a rendszer újraalkotható legyen egy új helyen egy praktikus de körülményes módon, a szolgáltatási szint minimális befolyásolásával. A modern biztonsági mentési stratégiákkal ez a hely lehet a nyilvános felhő, még akkor is, ha a rendszerek, amelyekről a pillanatképek készülnek, a felhőn kívül helyezkednek el.
AWS Backup
2019 elején az Amazon Web Services újratervezte az ügyfelek hibrid felhőkörnyezeteihez kínált felhőalapú biztonsági mentési szolgáltatását. Az új AWS Backup (ennek böngészőalapú konzolja látható a 2. ábrán) középpontjában a tűzfalak szabályválasztójához hasonló szabályzatmotor áll. A biztonsági mentésekért felelős rendszergazda ezzel a motorral szabályokat írhat meg, amelyek megadják a következőket:
A rendszer mely erőforrásairól szükséges biztonsági másolatot készíteni
Hogyan és milyen gyakran kell lebonyolítani az egyes biztonsági mentéseket
Hol legyenek tárolva a biztonsági másolatok lemezképei
Hogyan és milyen gyakran kell figyelni a biztonságimásolat-képek integritását
Mennyi ideig kell megőrizni a biztonságimásolat-képeket
Milyen körülmények esetén kell helyreállítást és visszaállítást végezni
Az összes aktív szabályzatot magában foglaló teljes teendőlista a biztonsági mentési terv. Itt minden szabály a biztonsági mentést igénylő AWS felhőbeli erőforrásokra vonatkozik a címke értékével, amely a rendszergazda által megadott tetszőleges név. Ha egy erőforrást, például egy rugalmas blokktároló- (EBS-) kötetet fel szeretne venni a biztonsági mentési tervbe, a rendszergazdának csupán egy olyan címkenévvel kell ellátnia az erőforrást, amelyet az AWS Backup felismer. Az AWS-erőforrásért felelős rendszergazdának vagy kezelőnek így nem kell az AWS Backup-konzolt használnia ahhoz, hogy a felügyelete alá tartozó erőforrást egy meglévő biztonsági mentési terv részévé tegye.
![Figure 2: The AWS Backup console. [Courtesy Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
2. ábra: Az AWS biztonsági mentési konzolja. [Udvarias amazon]
Helyszíni erőforrások az AWS Storage Gateway segítségével építhetők be egy biztonsági mentési tervbe. A Storage Gateway az AWS Backup szempontjából a fizikai tárkötetek és eszközök körüli API-burkolóként viselkedik, így elérhetővé teszi azokat az AWS-szolgáltatások számára.
A Storage Gateway eredetileg lehetővé tette a meglévő fizikai tárolási összetevők helyettesítését az azonos interfészt használó felhőalapú megfelelőikkel. Egy helyszíni iSCSI-kötetet például be lehetett burkolni egy gyorsítótárazott kötetbe, az AWS szóhasználatával. Ez a burkoló anélkül teszi elérhetővé a felhőtárhelyet a meglévő helyszíni alkalmazások számára, hogy az ügyfeleknek át kellene tervezniük ezeket az alkalmazásokat. A gyakran használt adatok továbbra is tárolhatók a gyorsítótárként használt iSCSI-köteten, ezzel csökkentve az elérésük késését. Emellett az átjárókötetek tartalmának legutóbbi változásai is tárolhatók helyileg pillanatképekként. A Storage Gateway ugyanakkor a tárolt köteteket is támogatja, ahol a helyszíni eszköz továbbra is fenntarthatja a kötet teljes helyi másolatát, amelyet a Storage Gateway aztán a felhőbe tükröz. Az új AWS Backup azt használja ki hogy a Storage Gateway szerepet cserél a fizikai kötetekkel, így a helyi másolat lesz a felhőalapú kötet biztonsági másolata, ugyanakkor központi szabályzatkezelő konzolt biztosít a mindkét replika kezelését meghatározó szabályokkal.
A vészhelyreállítás szempontjából a felhőszolgáltatói ajánlatok egyik fő előnye az a képesség, hogy a vállalat kritikus fontosságú adatai gyorsan archiválhatók egy távoli helyen a földrajzi redundancia, más néven georedundancia megvalósításához. Az összes felhőszolgáltató közül az AWS az, amely a legtöbb rendelkezésre állási zónában működtet felhő-adatközpontokat. Az üzemeltet alkalmazások hirdetett natív képessége a más zónákban történő automatikus feladatátvétel, és ezt a képességet az adatok biztonsági másolatainak redundanciájára is kiterjesztik. Előfordult azonban, hogy a feladatátvételi zónák ugyanabban az AWS-régióban helyezkedtek el. Szélsőséges katasztrófahelyzetben (amilyeneket a biztosítók, így a kockázatkezelők is számításba vesznek), például az elektromos hálózat meghibásodása esetén előfordulhat az egymással szomszédos rendelkezésre állási zónák kiesése.
Szoftverfejlesztők vagy fejlesztői tapasztalatokkal rendelkező informatikai üzemeltetők a vállalat saját georedundáns útvonalaira vonatkozó egyéni szabályzatokat is írhatnak az AWS alacsony szintű útválasztási szolgáltatása, a Route 53 használatával. Ez a technika azonban rendkívül munkaigényes. Az AWS a közelmúltban kezdett kínálni egy könnyebben kezelhető, AWS Global Accelerator nevű szolgáltatást, amely szintén a forgalmat irányító szabályzatmotor, és a Route 53 szolgáltatásnak adja meg a szolgáltatások és tárhelyek üzemeltetésének helyét.1 A Global Accelerator egyfajta „über-elosztóként” is használható, lehetővé téve az üzemeltetett alkalmazásokhoz (és velük együtt a kritikus fontosságú adatokhoz) tartozó több hely különböző rendelkezésre állási zónák közötti szétosztását.
Az adatok biztonsági másolatainak kellően távoli régiókban való tárolásának biztosítására az Amazon szakemberei által javasolt másik mód egy gyűjtő (bucket) (az AWS általános célú biztonságimásolat-tárolója) létesítése a biztonsági mentések eredeti céljaként, majd a gyűjtő replikálása egy redundáns helyre egy tetszőleges kiválasztott rendelkezésre állási zónában. Az AWS külön szolgáltatásként kínál régióközi replikációt (Cross-Region Replication, CRR).2 Az AWS mennyiség alapján, a tárolt gigabájtok és a visszaállított gigabájtok számát is figyelembe véve számítja fel a biztonsági mentési szolgáltatásai díját.
Az architektúra szempontjából az AWS Backupot arra tervezték, hogy az AWS-erőforrások tükreként szolgáljon. Ebbe tervbe egyfajta dupla hátsó ajtón keresztül lehet helyszíni összetevőket beépíteni úgy, hogy először távoli (az Amazon nézőpontjából távoli) AWS-kötetekké konvertáljuk ezeket a helyi összetevőket, majd a helyszíni összetevők burkolójával kapcsoljuk össze a Backupot.
Azure Backup
Az Azure Backup egyaránt alkalmas helyszíni erőforrások (kiszolgálók és virtuális gépek) és az Azure-ban üzemeltetett erőforrások biztonsági mentésére. Nem célja az adatközpont meglévő biztonsági mentési szabályzatának megváltoztatása, csupán a helyi lemezeket és szalagos meghajtókat váltja fel felhőtárhellyel. A fájlok és kötetek biztonsági másolatainak felhőbeli tárolására az úgynevezett helyreállítási tár szolgál. Ennek böngészőalapú konzolja látható a 3. ábrán. A tároló azure portalon keresztüli beállítási folyamata során a rendszergazda letölti és telepíti a Microsoft Azure Recovery Services-ügynök vagy "MARS" nevű ügyféloldali ügynököt. A Windows Serverben a MARS alkalmazásként fut, és nagyon hasonlít a System Center bővítményre. (Másik lehetőségként előfordulhat, hogy egy rendszergazda inkább a System Center Data Protection Managert használja, ahol a MARS-funkciók már be vannak építve.) A rendszergazda megkeresi azokat a köteteket és szolgáltatásokat a hálózaton, amelyek adatai biztonsági mentést igényelnek, és a MARS az ügynökeit az összetevőkért felelős kiszolgálói címekre osztja el.
![Figure 3: The console for Azure Recovery Services Vault. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
3. ábra: Az Azure Recovery Services Vault konzolja. [Udvariasság Microsoft]
Az Azure Backup teljesítési modellje a vészhelyreállításra vonatkozó szolgáltatásiszint-célkitűzésekre épül, amely ésszerű metrikákat biztosít annak meghatározásához, hogy mennyi időt vészelhet át egy vállalat az üzleti motorhoz való hozzáférés nélkül, és mennyi adat elveszítése fogadható el katasztrófa esetén. Az egyes célkitűzésekről (helyreállításipont-célkitűzés, helyreállítási idő célkitűzése és adatmegőrzés) a vészhelyreállítással foglalkozó következő leckében lesz szó.
A helyreállításnak az a típusa, amellyel az Azure Backup foglalkozik (szemben a Microsoft vészhelyreállítási szolgáltatásával, az Azure Site Recoveryvel), nem a szolgáltatások helyreállítása, hanem kizárólag az adatreplikáció köré épül. Az ügyfelek felhasználhatják az Azure Backupot például a virtuálisgép-lemezképfájlok (VHD-k) replikáinak előállítására. Egy VHD visszaállítása azonban csupán az archivált lemezképfájlt állítja elő ismét egy helyi tárolóban, de nem indítja újra az erre a VHD-re épülő virtuális kiszolgálót.
Az Azure Backup csupán a felhasznált tárterületért számol fel havi díjat, a visszaállítás nem jár többletköltséggel. A tárhely díjszabási modellje az ahhoz elérhető redundanciához kötődik. Az Azure jelenleg két ilyen lehetőséget kínál: a helyileg redundáns tárolást (LRS), amely a legkevésbé költséges, és háromszor replikál adatokat egy Azure-adatközpontban, és georedundáns tárolást (GRS), amely az elsődleges régiótól földrajzilag távoli másodlagos régióba replikálja az adatokat.
A Google Cloud Storage biztonsági mentése
A Google többféle Cloud Storage-csomagot kínál a tárolt adatok jellegétől függően, például állandóan elérhető fájlokhoz, virtuálisgép-lemezképek blokktárolóihoz vagy videókhoz való objektumtárolókhoz. Egyik csomaghoz sem hirdet kimondottan megnevezett biztonsági mentési szolgáltatást, bár a tárolási szolgáltatások kétségtelenül használhatók – és használatosak is – biztonsági mentéshez és helyreállításhoz. A Google egyértelműen feltételezi, hogy a biztonsági mentés az leglényegesebb indokok között szerepel, ha egy nagyvállalat nagyméretű felhőtárhelybe kíván beruházni.
![Figure 4: The contents of a Google Cloud Storage bucket. [Courtesy Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
4. ábra: Egy Google Cloud Storage-gyűjtő tartalma. [Jóvoltból Google]
Ahogyan az AWS, a Google is gyűjtőnek nevezi az általános célú tárolóját. A 4. ábra annak az eljárásnak mutatja be egy lépését, amelyben helyi tárból importálnak adatokat egy Google Cloud Storage- (GCS-) gyűjtőbe. Hasonlóan ahhoz három fő paraméterhez, amelyre az Azure alapozza teljesítési modelljét, a GCS fő paraméterei a következők:
Teljesítmény, ami ebben a környezetben rendelkezésre állást jelent (milyen gyorsan válaszolnak a kiszolgálók az ügyfelek adatolvasási kéréseire)
Megőrzés, ami itt is arra utal, hogy az ügyfél mennyi ideig tervezi a felhőben tartani az adatokat
Hozzáférési mintázatok, ami a hozzáférhetőséggel áll összefüggésben (várhatóan milyen gyakran olvassa vagy tölti vissza az ügyfél a tárolt adatokat)
Egy gyűjtő inicializálásakor a GCS-ügyfél választja ki annak tárolási osztályát, amellyel a megőrzési szabályzatát is megadja. Ez a választás határozza meg, hogy mekkora körben lesznek elosztva tárolt adatok, amikor a gyűjtőt biztonsági másolatok készítésére kezdik használni. A GCS jelenleg három választható földrajzi elhelyezési módot kínál:
Regionális – A Google egy szolgáltatási területének egyetlen kijelölt régiójában tárolva
Kétrégiós – Két kijelölt szolgáltatási területen replikálva
Többrégiós – Redundánsan elosztva több szolgáltatási területen
A GCS ez után további alosztályokra osztja fel a gyűjtők tárolási osztályait az alapján, hogy milyen gyakran lesznek használva:
Standard / magas rendelkezésre állású – Az alkalmazások és felhasználók számára bármikor elérhetőnek szánt adatok
Ritka elérésű (Coldline) – Az ügyfél a havi tárolási díj egy része helyett hozzáférési és átviteli díj fizetését választhatja olyan adatok esetén, amelyekhez évente legfeljebb néhányszor kíván hozzáférni
Közeli (Nearline) – Köztes megoldás a körülbelül havonta egyszer elérni kívánt adatokhoz
A Google által a felhőinfrastruktúra üzleti értékesítésére használt marketingfogás, hogy úgy mutatja be szolgáltatásait, mint nem látható berendezéseket. Ebben az értelemben a Google kettős erőfeszítéssel kínálja magát a berendezést és annak külön szolgáltatáskén való használatát, mintha eladnánk egy tűzhelyt, majd a főzésre való előfizetést, mint értéktöbbletet.
A GCS ügyfelei így kiválaszthatják a tervezett tevékenységhez szükséges infrastruktúrát, majd testreszabhatják ennek az infrastruktúrának a beállításait, mint egy berendezés funkcióit. (Az AWS-hez és az Azure-hoz hasonlóan a Google is kínál állványra szerelhető berendezést adatközpontokhoz a helyi és a felhőbeli tárolók közötti gyors adatátvitel kifejezett céljára.) Ezek a funkciók idővel módosíthatók attól függően, hogy a tárterület használata hogyan változik. Tegyük fel például, hogy egy videókat készítő cégnek nagy biztonsági mentési tárra volt szüksége egy vágás alatt álló film változataihoz. A vágás során ezeket a másolatokat gyakran lekérhették, ezért az ügyfél Standard tárolást állíthatott be Regionális területen. Az elkészült videó nyilvános terjesztésének megkezdése után is szükséges lehet egy évre megőrizni a kópiákat, bár nem gyakran fogják használni őket. Ebben az esetben a Standard gyűjtőt Ritka elérésűre állíthatják át, az archiválás és a biztonság kedvéért Kétrégiós tárolással.
Hivatkozások
Amazon Web Services, Inc. Forgalomkezelés az AWS globális gyorsítóvalhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/.
Amazon Web Services, Inc. A replikációhttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html beállításának áttekintése.