GAMF::Felhőalapú-szolgáltatások::Előadás

Bérelt szervertől (VPS) a felhő megoldásokig

A legalapvetőbb feladat, amit egy szerverre szeretnénk bízni, hogy szolgálja ki a weboldalunkat. Szerencsére ehhez ingyenesen elérhető tárhelyek is rendelkezésünkre állnak, mint például a nethely. Az ingyenes változatok gyakran reklámokkal tűzdelik tele weboldalunkat és/vagy olyan tárhely korlátokkal vehetjük igénybe, amelyekkel egy komolyabb alkalmazás esetén nem ússzuk meg a fizetős változatok megrendelését. Azonban jó ha tudjuk, hogy ezek a szolgáltatások főleg PHP alkalmazások futtatására alkalmasak, a ma népszerű NodeJS kódokat nem tudják futtatni.

VPS

Ha nem csupán egy tárhelyet szeretnénk bérelni - ennek oka lehet, hogy nem tudja a tárhely szolgáltató futtatni alkalmazásunkat (pl. NodeJS), vagy annyira komplikált/bonyolult az üzemeltetése, hogy nem fér bele a sablonos keretekbe -, akkor bérelhetünk virtuális szervereket is: VPS-t (Virtual Private Server). Ekkor egy virtuális „vasat” kapunk, amire korlátozott, de széles választékból telepíthetünk operációs rendszert és kedvünk szerint konfigurálhatjuk azt. Ez a legelterjedtebb megoldás, azonban ezen szolgáltatásoknak is meg vannak a szintjei:

1. VPS bérlés - a fent említett módon, virtuális környezetben létezik szerverünk
2. Dedikált szerver - Egy komplett szerverhez kapunk hozzáférést. Többnyire igen drága szolgáltatás.

A szolgáltató ezeket a rendszereket általában monitorozzák, illetve webes felületet biztosítanak, hogy újra tudjuk indítani/telepíteni, távoli asztallal rá tudjunk csatlakozni stb. A rendszert azonban nekünk kell karbantartanunk, így a vírusok, támadások ellen többségében nekünk kell kivédenünk (természetesen egy valamirevaló szolgáltató rendelkezik IDS/IPS rendszerekkel, de ügyeljünk rá, hogy ezek nem adnak százszázalékos védelmet). Ilyenkor mi telepítjük fel és frissítjük a webkiszolgálót, az adatbáziskezelőt, amennyiben szükségünk van rá és az alkalmazáshoz szükséges minden csomagot nekünk kell naprakészen tartanunk.

Saját globális hálózat

Míg egy kis cégnek elegendő egyetlen VPS, amelyen fut a webkiszolgáló és az SQL szerver is, egy nagyobb cégnek, gyakrabban látogatott alkalmazásoknak célszerű szét darabolni az elemeit - külön SQL szerver, külön fájl szerver és külön kiszolgáló. Ennek a háromnak folyamatosan kommunikálni kell egymással (lényeges a közöttük kialakított hálózat minősége), de egy támadás a webkiszolgáló felé valószínűleg nem fogja elérhetetlenné tenni a fájlszerverünket és az adatbázisunkat, ezzel együtt pedig az adatokat is megvédtük a behatolók elől. Ezzel le is írtunk egy mini felhőt. Sok alkalmazás esetében azonban ez sem volt elegendő: hol adatvédelmi okból, hol a rendelkezésreállás javítása miatt clustereket hoztak létre, esetleg datacentereket létesítettek a világ több pontján. Ezek gyakorlatilag egyeznek a ma privát felhőként emlegetett megoldással, komplexitásuk megközelíti a ma igénybevehető szolgáltatások mögött található rendszerek bonyolultságát.

Felhőszolgáltatás

A fentebb említett cluster illetve datacenter kialakítások igen költségesek. Mivel a szolgáltatók ezeket már kiépítették világszerte, így célszerű ebbe bekapcsolódni ahelyett, hogy a sajátunkat kezdenénk el megtervezni. Egy szolgáltatás igénybevételével hozzáférhetünk a teljes hálózathoz, így például nagyon egyszerűen biztosíthatjuk, hogy Amerikában ugyanolyan gyorsan töltsön be weboldalunk, mint Magyarországon - természetesen nem ugyanarról a szerverről. Emlékezzünk vissza, hogy ezekkel a tulajdonságokkal régebben nagyon kevés cég (Google, Microsoft) rendelkezett és csakis azért kezdtek el adatközpontokat létesíteni a világ más pontjain, hogy ne kelljen az óceán fenekén húzódó optikai kábeleken keresztül, nagy távolságon és sok hálózati ugráson át elérnünk a szolgáltatást (ami jelentős késleltetést (latency) okozna), amikor például Európából akarjuk böngészni a weboldalukat. Ha ma megnézzük az elérhető felhőszolgáltatókat, akkor pontosan ezeket a „mamut cégeket” fogjuk megtalálni a piacon.

Ritka ugyan, de manapság is előfordul, hogy saját felhőt alakítanak ki maguknak cégek: például az Instagram eleinte az Amazon Web Services hálózatát használta fel, hogy a világ minden táján elérhető legyen, majd a Facebook általi felvásárlása (2012) után fokozatosan átköltöztették a Facebook saját infrastruktúrájára.

A felhőszolgáltatások előnyei egyben hátrányként is szolgálnak:

• A felhőben általában csak az elhasznált erőforrásokért fizetünk (gyakran idő alapon) - ez gyakorlatilag nagyon nehézzé teszi a költségtervezést
• A felhő biztosítja számunkra, hogy az adataink mindig elérhetők legyenek - a nagy szolgáltatók (pl. AWS) ma már régió szintjén garantálják, hogy az általunk kiválasztott adatközpont-régión belül maradnak az adatok (pl. van kifejezetten EU-s régió is), de érdemes tudni, hogy egyes globális/menedzselt szolgáltatásaik alapértelmezetten több régió között replikálhatnak, ha ezt nem konfiguráljuk explicit módon régióhoz kötötten. Emiatt egy bizalmas adatokat kezelő cégnek (pl. bank) az EU-s adatvédelmi (GDPR) elvárások miatt mindig tudatosan, szerződéses garanciákkal (Data Processing Agreement, adott régióra korlátozás) kell konfigurálnia a felhős környezetét, nem elég csak "belefutni" az alapértelmezett beállításokba.

Érdemes azt is megjegyezni, hogy az alacsony költségek igen relatívak. Sok cég még ma sem engedheti meg magának, a felhőbe költöztesse az alkalmazásait. Ennek egyik oka az említett adatbiztonsági szabályozás az EU tagjaként, de benne lehet a bizalmatlanság és a vélt forgalomhoz becsült árak és a szintén említett kiszámíthatatlanság. Sok cégnek még ma is jobban megéri egy VPS szolgáltatást igénybe venni, főleg ha nem akar a határokon kívülieket megszólítani. Az alacsony költségek főleg ott értelmezhetők, ahol speciális eszközök (TensorCore, GPU) kellenek rövid időre, illetve a cég felhőszolgáltató hiányában saját globális hálózatot építene ki magának a Google-höz és a Microsoft-hoz hasonlóan.

Ajánlott VPS szolgáltatók

A szolgáltatás árak egy cég számára talán nem magasak, ám egy tanuló informatikus számára, aki csupán azért szeretne bérelni egy szervert, hogy kipróbálja az iskolában tanultakat (esetleg máshol olvasottakat), neki minden fillér számítani fog. Amennyiben az egy éves próbaidőszakon túl is szeretnél szerverekkel, azok konfigurációjával foglalkozni, akkor a következő szolgáltatókat ajánlom figyelmedbe:

• Contabo - egy német cég, igen alacsony bérleti árakkal (évi 20.000HUF kb., természetesen Euróban). Hátránya, hogy Németországban lesz a szervered, ami földrajzilag távol esik, főleg ha VPN szerű alkalmazásokkal is próbálkozni szeretnél. Hozzá kell tenni, hogy a BIX (Budapest Internet Exchange), ami Magyarország fő kilépési pontja a világháló felé, Frankfurtból kapja szolgáltatását. Innen nézve Németország nincs is olyan messze...

Alkalmazások, amelyek segítségével felügyelhetjük a szerverünket

Az alkalmazások a felhőben létrehozott IaaS szolgáltatásokra is telepíthetők

• Zabbix - Telemetria rendszer, amely alkalmas konténerek és alkalmazások monitorozására a szerver alapvető (CPU, RAM, HDD) tulajdonságain túl.
• Nagios - a Zabbixhoz hasonló Telemetria rendszer
• OpenVAS - A szerveren futó alkalmazások verziószámát összeveti a CVE adatbázissal (pl. cve.mitre.org és naplózza a talált hibákat. Segítségével értesülhetünk a hibákat tartalmazó szoftvereinkről és még idejében frissíthetjük, lecserélhetjük azokat, mielőtt egy hacker találna rá. Nagyon fontos, hogy az információkat bejelentkezés nélkül szedi össze, tehát csupán a publikum számára is elérhető információk alapján keres. További információkért keresd fel az nmap scripts oldalt.

Felhő ökoszisztéma

Oldalszám: 13-40.

A skálázásnak mélyreható következményei vannak a menedzsmentet tekintve: egyik oldalon a rendszernek rugalmasnak kell lennie, tudnia kell kezelni a hirtelen megnövekvő terhelést is; míg a másik oldalon optimalizálnia kell az energiafelhasználást. Természetesen ezeket a nehézségeket el kell rejteni a felhasználó elől egy jól átlátható, könnyen használható felület mögé.

Szolgáltatási szintek

IaaS, azaz Infrastructure as a Service

Ez a szolgáltatásszint a tárhelyet, hálózatot és egyéb alapvető számítási erőforrásokat foglal magában. Ez esetben a bérlő természetesen nem fér hozzá a felhő belső infrastruktúrájához, de testreszabhatja a vásárolt virtuális gép erőforrásait: tárhelyméret, CPU, memória, operációs rendszer, terhelés elosztás (...) és saját virtuális hálózatot, internet kilépési pontot konfigurálhat köré. Ez a szolgáltatásszint hasonlít a korábban tárgyalt VPS-hez. A modell akkor lehet hasznos, ha egy induló vállalkozásnak számítási kapacitásra van szüksége, de nem akar saját szervereket karbantartani, vagy ha a szervezet gyorsan növekszik.

PaaS, azaz Platform as a Service

Lehetővé teszi, hogy a bérlő saját alkalmazásokat futtasson a felhőben, természetesen azzal a megkötéssel, hogy a szolgáltató támogatja az adott programkészletet. Ebben az esetben a bérlőnek nem kell üzemeltetési kérdésekkel foglalkoznia - operációs rendszer, CPU, memória, tárhely, hálózat (...) - csupán a saját programjára és az ahhoz kapcsolódó konfigurációs lehetőségekre kell koncentrálnia. Ez a szolgáltatásszint nem ésszerű választás, ha az alkalmazásnak hordozhatónak kell lennie, ha szabadalom alatt álló programozási nyelvet használunk vagy ha az alkalmazás erőforrásait konfigurálni szeretnénk. Gyakran szoftverfejlesztők használják, amikor több fejlesztő dolgozik együtt és mind a fejlesztési mind a tesztelési szolgáltatásokat automatizálni kell.

SaaS, azaz Software as a Service

A szolgáltatások ezen szintjén sem az alkalmazás kódját, sem az alatta futó infrastruktúrát nem ismerjük. Tipikus példa az email vagy a keresés, ahol használjuk az alkalmazást, esetleg testreszabhatjuk (kinézet, logó, név stb.), de többnyire nem rendelkezünk információkkal (vagy teljesen lényegtelen a használat szempontjából), hogy milyen programnyelven készültek és milyen közegben működnek. Lehetnek ilyen alkalmazások továbbá asztali / telefonos alkalmazások, de például számlázó végpontok is. Fontos figyelembe venni, hogy a felhőbe érkező kérések nem valósidőben kerülnek feldolgozásra, így csak azon programok esetén használható, amelyek ezt nem követelik meg.

DBaaS, azaz Database as a Service

Ez a szolgáltatás garanciát ad azonnali skálázhatóságra, teljesítményre; a legújabb technológiákat használja és rendelkezik hibakezeléssel. A legfontosabb tulajdonságai:

1. Self-service: különösebb konfigurálás nélkül elindítható. Nem csökkentett teljesítménnyel rendelkezik és nincs telepítési díj.
2. Eszköz és helyfüggetlen adatbázis erőforrás
3. Rugalmasság és skálázhatóság
4. Annyit fizetsz, amennyit használsz
5. Zökkenőmentes váltás a verziók / technológiák között

A szolgáltatás réteges architektúrát alkalmaz:

• UI réteg: interneten keresztül elérhetővé teszi a szolgáltatást
• Alkalmazás réteg: A szoftver szolgáltatásait és a tároló réteget is eléri
• Adatbázis réteg: hatékony és megbízható szolgáltatást nyújt - például menti az utolsó lekérdezéseket, hogy ismétlődés esetén ne kelljen újra lefuttatnia azokat
• Adat tároló réteg: adatok titkosítása, biztonsági mentések és lemezfigyelők találhatók itt

IaC, azaz Infrastructure as Code

Az infrastruktúra vezérlése magas szintű leírónyelv (deklaratív konfigurációs fájlok) segítségével, kézi kattintgatás helyett. Fontos leszögezni, hogy az IaC önmagában nem követeli meg sem a mikroszolgáltatás-architektúrát, sem a konténerek használatát - ugyanígy leírható vele akár egyetlen monolitikus alkalmazáshoz tartozó hagyományos virtuális gép, hálózat vagy adatbázis is. Az IaC segítségével megadhatjuk, hogy milyen erőforrásokat (EC2, VPC, RDS stb.) szeretnénk elindítani, milyen kapcsolatban álljanak egymással, és ez a leírt állapot verziókezelhető, újrafelhasználható és automatizáltan alkalmazható a felhőben. A legsűrűbben használt eszköz az Ansible és a Terraform.

Összefoglalás

Megosztott biztonsági felelősség (SSR) modell a szolgáltató (félkövér) és az ügyfelek között

SaaS	PaaS	IaaS
Felhaszálói hozzáférés	Felhaszálói hozzáférés	Felhaszálói hozzáférés
Adatok	Adatok	Adatok
Alkalmazások	Alkalmazások	Alkalmazások
Operációs rendszer	Operációs rendszer	Operációs rendszer
Hálózati forgalom	Hálózati forgalom	Hálózati forgalom
Hypervisor	Hypervisor	Hypervisor
Infrastruktúra	Infrastruktúra	Infrastruktúra

Felhők típusai

Privát felhő

Az adatok nincsenek megosztva harmadik féllel, a kontrollt teljes egészében a struktúrát kialakító rendszergazda kezében van. Természetesen nem korlátozódik a cég helyszínén üzemeltetett szerverekre a fogalom, szóba jöhetnek harmadik féltől bérelt VPS, VDS, de komplett bérelt szerverek is, de általában az eszközök VPN alagúton keresztül cserélnek információt, ezzel védve az adatokat.

Publikus felhő

Az adatokat egy harmadik fél által kialakított hálózaton keresztül használjuk, ami a csomagokat a publikus IP hálózaton keresztül továbbítják egymás között. Óriási előnye, hogy nincs üzemeltetési költsége a szolgáltatást igénybe vevőnek, általában a CPU idő után kell fizetni, tehát flexibilis költséget hoz magával.

Hibrid felhő

A publikus és a privát felhő kombinációja, így a kiemelt biztonságot igénylő adatok nem kerülnek ki az internetre, míg a kevésbé érzékeny adatok továbbíthatók a publikus felhő segítségével, ezzel kihasználva annak minden előnyét.

AWS szolgáltatásai

Az AWS első körben IaaS szolgáltatásokat nyújt, nagy sebességű hálózaton összekötött feldolgozóegységet és tárolóegységeket tartalmazó infrastruktúrát és az ezeket támogató szolgáltatáshalmazt kínál.

Feldolgozás, adattárolás és kommunikációs szolgáltatások

Elastic Compute Cloud (EC2)

Egy szolgáltatás, amely egyszerű felület segítségével teszi lehetővé, hogy szerver példányokat futtassunk a felhőben. Létrehozáskor meg kell adnunk az operációs rendszert, amely lehet Linux alapú, OpenSolaris, FreeBSD, NetBSD, de akár a Windows Server különböző verziói közül is választhatunk. Szintén ki kell választanunk, hogy melyik régióban és melyik rendelkezésreállási zónában szeretnénk futtatni, ahogy az erőforrásigény szerint létrehozott különböző típusok közül is választatnunk kell. A nagyobb teljesítmény magasabb költségekkel rendelkezik.

A létrehozott szerver rendelkezik belső és külső IP címekkel és a hozzájuk tartozó domain nevekkel is. Ezeket a címeket leállításkor elveszíti és újraindításkor kap újat. A címek tehát dinamikusak, ami egy szerver esetében ritka jelenség. Van lehetőségünk azonban statikus IP címek (Elastic IP) igénylésére is. Figyelem, 2024 februárja óta megváltozott az árazási modell: korábban csak a nem használt (egyetlen futó szerverhez sem csatolt) statikus IP-kért kellett fizetni, ma viszont az AWS minden publikus IPv4 címért számláz óránként, függetlenül attól, hogy csatolva van-e egy futó szerverhez. Az IP címtartományok zónánként változnak.

A szerver példányok létrehozhatók előre definiált képfájlokból - Amazon Machine Image (AMI) -, vagy egy a felhasználó által létrehozott készletből. Az AMI képfájlok másolatot készítenek egy meglévő rendszerről - könyvtárak, applikációk, amelyeket a felhasználó saját maga telepített fel - kivéve a alsóbb szintű konfigurációs paramétereket, mint például a hostname vagy a MAC címek.

Egy EC2-ben létrehozott szerver interakcióba léphet egyéb más szolgáltatásokkal is, mint például S3, EBS, DynamoDB stb.

Simple Storage Service (S3)

Nagy objektumok tárolására alkalmas szolgáltatás. A minimálisan szükséges funkciókkal rendelkezik: írás, olvasás és törlés. A szolgáltatás lehetővé teszi egy alkalmazás számára, hogy korlátlan mennyiségű objektumot kezeljen 1 bájt mérettől egészen 5 terabájtig. Az objektumok úgynevezett bucket-ban tárolódnak, amelynek egyedi azonosítója van és a felhasználó által kiválasztott régióban helyezkedik el. Az objektumokhoz állíthatunk be hozzáférési listát (ACL), amellyel kontrollálhatjuk, hogy ki milyen fájlokhoz, milyen módon férhet hozzá. Elérését egy REST illetve egy SOAP API biztosítja, alapvetően HTTP(S) alapon. (Régebben BitTorrent protokollon keresztüli hozzáférés is elérhető volt, de ezt az AWS 2021-ben megszüntette.) Az egyes fájlokhoz MD5 hash (ETag) készül, így letöltés után ellenőrizhető a fájlok helyessége.

Elastic Block Store (EBS)

Tartós tár, amelyet az EC2-höz csatolva használunk: egy fizikai lemezként megjelenő meghajtó. Mérete kötettípustól függően akár 16 tebibájtig (gp3, io1/io2) is terjedhet. A meghajtók a rendelkezésreállási zónán belül csoportosításra kerülnek, majd replikációkat hoznak létre az egyéb zónákban. Egy EC2 több EBS-t is használhat, és jellemzően egy EBS is csak egy EC2-höz lehet aktívan hozzárendelve (kivétel az io1/io2 Multi-Attach funkció, ami korlátozott esetekben több példányhoz is engedi csatolni ugyanazt a kötetet). Használható pillanatképek létrehozására egy szerverpéldányból, hogy később ezt felhasználva új EC2 példányt indíthassunk belőle.

DynamoDB

Az AWS natív NoSQL (kulcs-érték és dokumentum modellű) adatbázis szolgáltatása, amely web szolgáltatásokon keresztül teszi lehetővé a fejlesztők számára az adatok manipulálását. A szolgáltatás több, földrajzilag távol eső helyeken is képes másolatot készíteni (globális táblák). Támogatja a nagy teljesítményigényű alkalmazásokat, automatikusan skálázza a használat alapján az erőforrásokat, a táblában található indexeket és kezeli az adatbázis replikációkat. (Az AWS korábbi, hasonló célú szolgáltatása a SimpleDB volt, ezt azonban évek óta nem ajánlják új projektekhez, helyette a DynamoDB használata javasolt.)

Simple Queue Service (SQS)

Szolgáltatások szinkronizációjára szolgáló üzenetsor, amelybe bejelentkezés nélkül lehet adatokat küldeni. Az üzenetsorok megoszthatók különböző regisztrációk között is. Az egyes üzenetek feldolgozás alatt zárolásra kerülnek, hogy elkerüljék azok többszöri feldolgozását. Amennyiben az üzenet feldolgozása valamilyen okból kifolyólag sikertelen eredménnyel zárul, akkor feloldják, ezáltal újra kivehető a sorból. A hozzáférés IP és idő alapon is tiltható.

CloudWatch

Egy monitorozó rendszer, amely telemetria adatokat gyűjt. Segítségével optimalizálható az alkalmazás. Anélkül, hogy a felhasználó bármit telepítene, tucatnyi metrika közül választhat, majd megtekintheti a hozzájuk tartozó grafikonokat. Az alap monitorozás ingyenes, amely 5 percenként gyűjt adatot, de készíthetünk bővebb, 1 perces mintavételezéssel is jelentést. A szolgáltatás monitorozza a az EBS elérésének idejét, az adatbázis hozzáférés idejét és az SQS-ben tárolt adatokat is és természetesen még sok egyéb paramétert.

Virtual Private Cloud

A VPC egy saját, elkülönített, logikailag izolált virtuális hálózat az AWS felhőjén belül: hétköznapibb értelemben modellezhetjük egy routerként, amelynek vannak alhálózatai, route táblája és egy internet kilépési pontja (Internet Gateway), amin keresztül a benne futó erőforrások (EC2 stb.) kommunikálnak egymással és a külvilággal. A VPC-n belül tűzfalként funkcionáló Security Groupokat és hálózati ACL-eket is definiálhatunk. Nem kötelező eleme egy VPC-nek, hogy egy meglévő céges hálózathoz kapcsolódjon - ha viszont erre is szükség van, arra külön szolgáltatás áll rendelkezésre: a VPN-alapú Site-to-Site VPN, illetve a dedikált vonalas Direct Connect köti össze a VPC-t egy meglévő, helyi infrastruktúrával.

Auto Scaling

Az Auto Scaling segítségével megadhatunk olyan szabályokat, amelyek segítségével az erőforrásaink dinamikusan változnak. Csoportokat hozhatunk létre, amelyben monitorozhatjuk az EC2 példányainkat, majd triggerek segítségével újabb és újabb példányokat indíthatunk el vagy éppen állíthatunk le, annak függvényében, hogy a csoportban megszabott szabályok szerint az erőforrás kevés vagy sok. A csoportban szereplő EC2 példányokra állíthatunk be teszteket, aminek segítségével információt nyújthatunk a terheléselosztást végző Load Balancer szolgáltatásnak: így biztosíthatjuk, hogy csak olyan gépek szerepeljenek annak listájában, amelyek elérhetők. A leggyakoribb trigger a CPU: ha a csoport CPU kihasználtsága magas, akkor újabb EC2 példány indul, ami egyúttal csökkenti a csoport CPU terhelését. Ha a csoport CPU terhelése nagyon alacsony (pl. 0%), akkor kevesebb EC2 példány is képes kiszolgálni az aktuális forgalmat, tehát leállít egyet. A létrehozáskor megadhatjuk, hogy milyen értékek között változhat a példányok darabszáma.

Cloud Formation

Segítségével JSON fájlban írhatjuk le az alkalmazás futtatásához szükséges infrastruktúrát. Benne leírhatjuk a szükséges erőforrások paramétereit, mint például az instance típusa, az SQL portja vagy mérete.

Elastic Beanstalk

Ez a szolgáltatás automatikusan skálázza az erőforrásokat az alkalmazás igényeihez igazítva. Ezt úgy éri el, hogy az Amazon egyéb szolgáltatásait automatikusan paraméterezi: EC2, S3, SNS, Load Balancer, Auto Scaling Group stb.

Lambda Service

Egy esemény alapú számítási erőforrás. Serverless-nek is nevezik a megvalósítást. Ez esetben egy-egy függvényt írunk meg, amit a Lambda egy erősen izolált, könnyűsúlyú mikro-virtuális gépben (AWS Firecracker) futtat le. 2020 óta lehetőség van a függvényt Docker (OCI) image formájában is csomagolni és feltölteni, de ez csak a csomagolás/terjesztés módja - maga a futtatókörnyezet ekkor sem egy hagyományos Docker daemon, hanem ugyanaz a Firecracker alapú izolált környezet. A függvény egy esemény hatására elindul és végrehajtja a benne lévő kódot, majd le is áll - ezért serverless, mert nem kell, hogy folyamatosan fusson egy szerver. Az eredmény általában adatbázisba kerül, de használhat egyéb szolgáltatásokat is, mint például az SQS, SNS stb. Egy alkalmazás több Lambda kifejezésből épül fel általában. Ez esetben a fizetés idő alapú: amennyi ideig használjuk az erőforrást, annyi idő után fogunk fizetni.

Régiók és rendelkezésre állási zónák

Az Amazon mára több száz adatközponttal rendelkezik szerte a világban, ezekből épülnek fel a rendelkezésre állási zónák (availability zone) - egy zóna jellemzően egy vagy több, egymáshoz nagyon közeli adatközpontot takar, amelyben nagyságrendileg tízezres nagyságrendű szerver található. (A pontos szerver- és adatközpont-számokat az AWS nem publikálja, ezek becslések.) Minden AWS régió minimum három rendelkezésre állási zónával rendelkezik (ez már évek óta az AWS hivatalos vállalása új régiók indításakor), melyek nagy sebességű hálózaton vannak összekapcsolva. A régiók nem osztanak meg erőforrásokat és nem kommunikálnak az interneten keresztül. A tárhelyek esetében automatikus replikáció jön létre a régiókon belül: az S3 a rendelkezésre állási zónák között, az EBS csak az adott rendelkezésre állási zónán belül. A kritikus alkalmazásokat célszerű több régióban definiálni biztonság szempontból. Az egyes régiók között lehet különbség számlázás (árak) és az elérhető szolgáltatások tekintetében.

AWS hálózatok

Minden régió redundáns kapcsolaton keresztül lett összekapcsolva a többi régióval. Ezen kívül privát link kerül kiépítésre a Direct Connect ügyfelek számára. A legtöbb főbb régió privát linken keresztül került összekötésre, aminek segítségével minimalizálható a szakadások lehetősége.

A rendelkezésre állási zónákon belül akár 25Tbps sebességgel képesek kommunikálni egymással a szolgáltatások, miközben a késleltetés 1-2 ms.

Átjárhatóság a felhőszolgáltatók között

Miközben a legtöbb szolgáltató arra törekszik, hogy minél több ügyfelet szólítson meg, minden szolgáltatónak vannak erősségei és gyengeségei. Emiatt könnyedén bekövetkezhet, hogy egy cégnek, amelynek addig megfelelő volt XY szolgáltató, hirtelen annak gyengébb minőségű szolgáltatásaival kellene dolgoznia, így a váltás, esetleg az újdonságok más szolgáltatónál történő elhelyezését helyezi kilátásba. Ekkor használjuk a vendor lock-in kifejezést, ami arra utal, hogy csak rengeteg idő és energia befektetéssel oldhatjuk fel a problémát, ráadásul elképzelhető, hogy épp olyan kellemetlenségekkel jár az új szolgáltatóhoz költöztetés más (régebbi) funkciók esetében, mintha az addigi szolgáltatónál helyeztük volna el az újításokat.

Egy tervezet szerint a szolgáltatók lehetőséget biztosítanak az egymást közötti átjárásra. A problémát messze nem egyszerű feloldani, hiszen nincs szabvány az adattárolásra, kommunikációs megoldásokra - sőt, az egyes szolgáltatók vonakodnak ezeket az információkat egymás között megosztani, hiszen egy hatékonyabb algoritmus sok pénzt spórolhat meg a gazdájának, ami előnybe is hozza a piacon. A szolgáltatók között úgynevezett Intercloud exchange interfészen keresztül lehetne kommunikálni.

Adatközpontok belső hálózata

Oldalszám: 175-212.

Ennek a fejezetnek a tanulmányozása előtt érdemes átolvasni a következő oldalakat is:

• Tipikus vállalati hálózati struktúra
• Hálózat rendelkezésreállás számítás
• BGP protokoll

CLOS hálózati topológia elmélete

A clos hálózati topológiát Charles Clos írta le 1953-ban ("A Study of Non-Blocking Switching Networks", Bell System Technical Journal). A vezetékes telefonokhoz készült, hogy két végpont minden esetben tudjon egymással kommunikálni, független attól, hogy hány ügyfél telefonál egyszerre.

A fenti képen látható a használt modell: van egy bemeneti ág (inbound) és egy kimeneti ág (outbound). Mind a Spine (gerinc), mind a Leaf (a fa levelei) switchek. A szabály szerint a Spine esetlegesen üresen maradt portjaira NEM köthetünk semmilyen végponti eszközt, csak és kizárólag a Leaf szintre. A hálózati topológia blokkolásmentes, ha a Spine-Leaf között több vagy egyenlő link van, mint a Leaf-ek és a rájuk kötött végponti eszközök között.

A példában 3 fokozatú (3-stage clos) hálózat látható. Minden ennél nagyobb fokozat elérhető, ha a középső (Spine) switcheket egy 3 fokozatú clos hálózattal helyettesítjük. Független a fokozatok számától mindig igaz, hogy a hálózaton a forrás és a cél között pontosan a fokozatok számával megegyező távolság alakul ki (jelen példában 3 - bemeneti leaf, spine, kimeneti leaf).

CLOS a gyakorlatban

Az adatközpontok hálózatában a vállalatoknál használt hálózati struktúra nem megfelelő, hiszen azt Észak-Dél irányú kommunikációra optimalizálták - kliens gépek internet hozzáférésének biztosítása stb. Az a struktúra azt feltételezi, hogy a vállalat szerverei egy Distribution rétegben foglalnak helyet, a szerver és a adattár (Storage) között csak egy switch található. Az adatközpontokban ez az állítás nem igaz: a központ bármely pontján lehet az adattár, akár több rack szekrény távolságban is. Ráadásul az észak-dél irányú kommunikációt biztosító struktúra bővítése igen költséges széltében és egy adatközpont általában ebben az irányban fejleszt.

A fenti okok miatt adatközpontokban olyan hálózati struktúrát kell alkalmazni, ami:

• széltében viszonylag kis költségek mentén bővíthető (végtelenségig),
• észak-dél irányú kommunikáció helyett nyugat-kelet irányra van optimalizálva.

Ezeknek a kritériumoknak megfelel például a Clos hálózat:

• a Clos hálózati modell felső fokozatát tükrözzük a Spine fokozatra, így a fentebb látható struktúrát kapjuk
• a spine L3 switch, tipikusan 100Gbps linkekkel
• a Leaf L3 switch 40Gbps sávszélességgel, amely vagy megegyezik a ToR (Top of Rack) switchekkel (3-stage clos) vagy erre csatlakozik (ez esetben 5-stage clos hálózat alakul ki).
• Az L3 kapcsolatot érdemes a ToR szintig letolni - tehát a Spine-Leaf-ToR között is L3 kapcsolat van (routing) -, így kiküszöbölhetők az L2 hátrányai:
  • a spanning tree kikapcsolja a hurkot okozó portot, így a redundánsan kialakított portokból csak az egyik használható
  • L2 hálózaton sok olyan nem kívánatos kommunikáció zajlik, ami csökkenti a sávszélességet
• point-point IP címeket használunk a Spine-Leaf-ToR hálózatban
• VXLAN segítségével kapcsolódunk a Leaf-ekre, így a szerverek nagyon gyorsan mozgathatók akár a rack szekrények között is (pl. egy virtuális gép áttelepítése során nem okoz problémát, hogy az IP tartományt is mozgassuk vele).
• Egy blokkolásmentes Clos hálózat minden portját ugyanakkora sávszélességgel érünk el, fix távolsággal (ez könnyedén kezelhető). Emiatt az adattárak bárhol lehetnek
• ne feledjük el, hogy az internetelérést biztosító router is a Leaf-re van kötve (nem a spine felett helyezkedik el!)

Az L3 kapcsolaton általában BGP protokollt alkalmaznak az IP cím tartományok hirdetésére. Lehet ehelyett mást is alkalmazni, azonban egy adatközpont többnyire publikus címeket is továbbít az internet felé, amire csak a BGP képes, így adja magát, hogy a belső hálózat címeihez is ezt használják. A BGP előnye, hogy támogatja az ún. ECMP szabályokat (Equal Cost Multipath routing), így a Spine és a Leaf fokozat között található összes kapcsolatot képes kihasználni - kvázi összeadva a sávszélességüket. Hátránya, hogy az eszközök számával exponenciálisan növekszik a konfigurációs igény is, de ezt különböző AS-ek kialakításával lehet mérsékelni.

A gyakorlatban nem törekednek a blokkolásmentes hálózat kialakítására, hiszen jelentősen növeli a költségeket, ha több ezer portra van szükségünk. Ugyanakkor azt se felejtsük el, hogy a Spine és a Leaf között nagyobb sávszélességet (100Gbps), mint a végpontok és a Leaf között (40Gbps). Ebből kifolyólag kevesebb Spine eszközzel is tudjuk biztosítani a szükséges sávszélességet - ennek következtében több elérhető port marad a Leaf fokozaton. A tipikus kialakítás, hogy a Spine-Leaf között a szükséges sávszélesség 3-át alakítják ki. Példa:

• Egy Rack-ben 10 szerver található, melyek fejenként 4x10Gbps kapcsolaton csatlakoznak a Leaf switch-re (egyben ToR)
• A rack szekrény sávszélessége így összesen 400Gbps
• A Spine-Leaf sávszélességét tehát 400/3=134Gbps sebességre kell optimalizálni
• Ha a Spine-Leaf között 100Gbps linkekkel számolunk, akkor összesen 2 Spine elegendő a szükséges sávszélesség eléréséhez (2-nél kevesebb Spine elhelyezése megszünteti a redundanciát is!).

A hálózat bővítése

A hálózatot két módon lehet bővíteni:

• Új Leaf switch elhelyezésével (A Leaf-et rá kell kötni az összes Spine switchre) a kapacitás növelhető - több portunk lesz
• Új Spine switch elhelyezésével jelentősen növelhetjük a rendszer sávszélességét.

A hálózat bővítésének felső korlátját a Leaf switchek portszáma jelöli ki: egy eszköz portszámának a felénél több spine nem telepíthető. (Ha többet telepítünk, akkor maradnak kihasználatlan vonalak maximális terhelés mellett is.) A fent látható hálózat nem bővíthető tovább (a Spine switchek telítettek, a Leaf switchek felét elfoglalja a Spine-Leaf kapcsolat).

Fat-tree topológia

A Fat-tree egy speciális clos topológia. Korábban szó esett arról, hogy egy Clos hálózat Spine fokozata kicserélhető egy 3 fokozatú Clos hálózattal - így kettővel növekedik az addigi hálózat fokszáma. Alább láthatjuk ezt a bővítést 3-ról 5 fokozatra.

A képen be van keretezve a 3 fokozatú hálózat Spine rétege, de ne feledjük, hogy egy Clos hálózatnak egyetlen ilyen fokozata van: tehát a fenti képen a fehérrel jelölt switchek képezik ezt a fokozatot. A képen a színezés miatt jól látható, hogy egy Leaf egyetlen Spine-hoz kapcsolódik csoporton belül (azonos színárnyalattal lettek jelölve, pl. zöld, kék stb.), mindegyik csoport két eszközből áll (világosak és sötétebbek). Természetesen az összes switchez kapcsolódik valamelyik Leaf, és egy Leaf továbbra is négy Spine-hoz kapcsolódik - mivel összesen 4 Spine csoport látható.

Ezzel a kapcsolással lehetőségünk nyílik a portok megtöbbszörözésére - a belső réteg arra szolgál, hogy az egyébként 2x2 portos switchekből 2x4 portos eszközöket hozzunk létre. A kapcsolás blokkolásmentes, tehát teljes egészében úgy működik, mintha egy 8 portos switcheket használtunk volna - igaz, ez sokkal költségesebb. Ne feledjük el, hogy ez a Clos hálózati topológia célja: blokkolásmentes óriás hálózatok felépítése.

A Fat-tree szintén ezt a bővítést használja ki: N darab spine switchet csoportokba rendez és szerverek egy csoportját - úgynevezett POD-okat - csatlakoztatja hozzá úgy, hogy minden POD minden switchel kapcsolatban álljon. ez az alábbi képen látható.

A kialakítás során alkalmazunk egy pár trükköt, hogy a fenti struktúra alakuljon ki az 5 fokozatú Clos hálózatból:

• A középső switcheket megcseréljük alul és felül is - így alakul ki 2-2 POD (mindegyikbe kettő leaf lesz)
• A Spine fokozatra tükrözünk, így összesen 8 Leaf switch lesz, amelyet bármelyik irányba használhatunk
• N Leaf-re N darab (a példában 2) switch-et kapcsolunk, amelyek mind össze vannak kötve minden szemben lévő eszközzel
• A rétegekeket átnevezzük:
  • A spine fokozat lesz a Core réteg
  • A Leaf fokozat lesz az Aggregation réteg.
  • A Leaf-ekre kapcsolt újabb switchek lesznek az Edge réget.
• A Core rétegben a Spine switchek átrendezhetők - ez a képen is így látható (az eredeti elrendezés szerint minden POD Leaf eszköze a Spine csoport első eszközére, minden POD második Leaf eszköze a Spine csoport második eszközére lenne kapcsolva), hogy minden POD egy Leaf eszköze egyetlen Spine switch csoporthoz kapcsolódjon. Ezek a csoportok Plane névre hallgatnak, amelyek innentől kezdve könnyedén telepíthetőek - egy újabb plane telepítéséhez újabb switch szükséges minden POD-ba az Aggregation rétegbe (és ezzel együtt az edge rétegbe is), majd minden újonnan telepített switchhez csatlakoztatni kell az új Plane eszközt (a csoportosítás nélkül a Spine switchek szét lennének szórva a rack szekrények között).

A fenti képen a 3 rétegű Fat-tree topológia látható, de a Clos topológiához hasonlóan több réteggel is létrehozható.

Összefüggések

L = rétegek száma,
k = használt switcheken található portok száma

Tulajdonság	Általános	3 réteg
Spine eszközök maximális száma	(k/2)^(L-1)	(k/2)^2
Maximális végpontok száma	2*(k/2)^(L)	2*(k/2)^3
Összes felhasznált switch	(2*L-1)*(k/2)^(L-1)	5*(k/2)^2
Edge rétegbeli switchek száma	2*(k/2)^(L-1)	2*(k/2)^2
Maximális POD	2*(k/2)^(L-2)	k

Méretezés

Tegyük fel, hogy egy hálózatot szeretnénk létrehozni, amelyben az alábbiakat kell teljesítenünk:

• 12 db szervert szeretnénk üzemeltetni,
• a szerver és az Edge között 10Gbps linkekkel
• a leaf és a spine között 25Gbps linkekkel
• 16 portos switcheket fogunk felhasználni

Ha mindezt 3 rétegű Fat-tree topológiában szeretnénk létrehozni, akkor a következő tulajdonságokat írhatjuk le:

• F(16, 3):
  • Maximum (16/2)^2 = 64 Core switch
  • Maximum 2*(16/2)^3 = 1024 végpont lesz
  • 16 POD hozható létre

Elsőként el kell döntenünk, hogy ezek a korlátok hogyan befolyásolják a jövőnket: várhatóan mikor lépünk túl ezen. Ha kevés, vagy hamarosan kevés lesz, akkor növelnünk kell a switch portszámát (k) vagy a rétegeket. Tegyük fel, hogy számunkra ez megfelelő választás. Azonban nincs pénzünk az egésznek a kiépítésére (hiszen tudjuk, hogy összesen 256 darab switch árát kellene kifizetni), ráadásul nem is indokolt a jelenlegi terheltség mellett. Ez esetben el kell döntenünk, hogy mit szeretnénk elérni. Például a teljes kapacitás 1/4-t garantáljuk - figyelem! nem blokkolásmentes hálózatot építünk ki, de a terheltség növekedésével tudunk fejleszteni. Nézzük hogyan méretezhetjük be a hálózatunkat a kívánt szintre:

• A 12 szerver 10Gbps sebességgel összesen 120Gbps sávszélességet igényel.
• A 120Gbps 1/4-dét szeretnénk kiépíteni, tehát: 120/x = 4/1 => 4x = 120 => x = 30Gbps.
• A switchek között 25Gbps sebesség érhető el, tehát 30Gbps/25Gbps darab Spine switch-re lesz szükségünk, hogy elérjük a minimális szintet. Mivel az eredmény tört, ezért 2 Spine switch szükségeltetik minden Spine-csoportba, amivel a lefedett sebesség 50Gbps lesz.
• A kettő Spine-switchez 2 Leaf tartozik (Aggregation) és 2 Edge switch - ezeket később a Core switchek növelésével szintén növelnünk kell
• A 64 darab Core switch összesen 8 csoportban helyezhető el (8x8). Jelenleg minden csoportban csak 2 eszközre van szükségünk. (Valójában ez egészen addig igaz, amíg a 16 POD mindegyike létezik és azok között 30Gbps sebességet szeretnénk garantálni. Jelenleg egy POD-ban elfér a 12 szerver (1 POD 16x25Gbps csatlakozással rendelkezik).

Ha a switch-ek kapacitása nagyobb, mint a használt sávszélesség (pl. 25Gbps helyett 50 vagy 100Gbps a gerincen), akkor a Fat-tree konfiguráció többszörözhető (pl. F(16,3)-ból F(32,3) lesz 50Gbps esetén és F(64,3) lesz 100Gbps esetén).

Erőforrás virtualizálás

Oldalszám: 135-173.

Virtuális gépek

„Software Stack”

Egy szerver rétegekből épül fel: legalul a fizikai hardver, fölötte az operációs rendszer (kernel + driverek), majd az azon futó szolgáltatások/alkalmazások. Virtualizáció esetén ez a "software stack" kiegészül egy újabb réteggel: a hardver fölé egy hypervisor (Virtual Machine Monitor, VMM) kerül, ami több, egymástól elszigetelt virtuális gépet (VM) hoz létre, mindegyikben saját, önálló vendég operációs rendszerrel és saját szoftverstack-kel. A hypervisor feladata, hogy a fizikai erőforrásokat (CPU, memória, hálózat, tárolás) szétossza és elszigetelje a rajta futó VM-ek között.

A hypervisorokat két nagy csoportba szokás sorolni:

• 1-es típus (bare-metal): közvetlenül a hardveren fut, nincs alatta „host” operációs rendszer (pl. VMware ESXi, Microsoft Hyper-V, Xen, KVM). Ez a jellemző megoldás szerverkörnyezetben, felhőszolgáltatóknál is.
• 2-es típus (hosted): egy már futó operációs rendszeren belül, alkalmazásként fut (pl. VirtualBox, VMware Workstation asztali gépen). Kényelmesebb fejlesztői/tesztelési célra, de nagyobb overhead-del jár.

Környezetek

QEMU

Nyílt forráskódú gépemulátor és virtualizáló szoftver. Önmagában, hardveres gyorsítás nélkül is képes teljes rendszereket emulálni - akár eltérő processzorarchitektúrát is (pl. ARM emulálása x86-os gépen), ez viszont jelentős teljesítménybeli veszteséggel jár, mivel minden processzorutasítást szoftveresen kell értelmeznie. Linux alatt tipikusan a KVM-mel párosítva használják: ekkor a KVM végzi a CPU/memória virtualizációját hardveres gyorsítással, míg a QEMU az eszközök (hálózati kártya, lemez, grafikus kártya stb.) emulálásáért felel - így érhető el közel natív teljesítmény, teljes eszközemulációval kombinálva.

XEN

A Cambridge-i Egyetemen indult, ma nyílt forráskódú, bare-metal (1-es típusú) hypervisor. Az egyik úttörője volt a paravirtualizációnak: a korai x86-os processzorok még nem támogatták hardveresen a virtualizációt, ezért a Xen a vendég operációs rendszer forráskódjának (kernel) módosításával érte el a hatékony működést. Történelmi jelentősége van az AWS szempontjából is: az Amazon EC2 hosszú éveken át Xen alapokon futott, mielőtt áttértek volna a saját fejlesztésű, KVM-alapokra épülő Nitro rendszerre.

Virtualizációk típusai

Paravirtualizáció

A vendég operációs rendszer "tudatában van" annak, hogy virtualizált környezetben fut: a kritikus, hardverközeli műveleteket (pl. memóriakezelés, megszakítások) nem a valódi hardver felé, hanem közvetlenül a hypervisor felé, egy erre kialakított interfészen (hypercall) keresztül kéri. Ez elkerüli a drága hardveremulációt, cserébe a vendég operációs rendszer kernelét módosítani kell, ami nem minden esetben lehetséges (pl. zárt forráskódú, nem támogatott rendszerek esetén).

Hardware Virtual Machine (HVM)

A modern processzorok hardveres virtualizációs kiegészítéseit (Intel VT-x, AMD-V) kihasználó megoldás. Ezekkel a kiegészítésekkel a processzor hardveresen ismeri fel és kezeli a privilegizált utasításokat, így a hypervisornak nem kell szoftveresen emulálnia vagy a vendég kernelt módosítania - teljesen változtatás nélküli ("unmodified"), akár zárt forráskódú operációs rendszer (pl. Windows) is virtualizálható vele, közel natív teljesítménnyel.

Kernel-based Virtual Machine (KVM)

A Linux kernelbe épített modul, ami magát a Linux kernelt alakítja hypervisorrá: a HVM hardveres kiegészítéseket (VT-x/AMD-V) használja ki, és a Linuxot 1-es típusú hypervisorként viselkedteti. Önmagában csak a CPU és memória virtualizációját végzi, az eszközök emulálásához jellemzően a fentebb már említett QEMU-val párosítják. Nyílt forráskódú, ingyenes, és mivel a Linux kernel részét képezi, rendkívül elterjedt (többek között ezt használja a Proxmox, az OpenStack alapértelmezett hypervisoraként, és ez az alapja az AWS jelenlegi Nitro rendszerének is).

Privát felhő platformok

Eucalyptus

Az egyik legkorábbi (2008-as) nyílt forráskódú privát felhő platform, ami kifejezetten az AWS API-jaival (EC2, S3) kompatibilis felületet biztosított, így az AWS-re írt eszközök/scriptek egy saját, helyben üzemeltetett felhőn is futtathatók voltak. A HP felvásárlása (2014) után a fejlesztése lelassult, mára inkább csak történeti jelentősége van, éles környezetben aktívan nem igazán terjedt el.

Open-Nebula

Nyílt forráskódú, viszonylag könnyűsúlyú felhő-menedzsment platform privát és hibrid felhők kialakítására. Az OpenStacknál egyszerűbb architektúrájú, gyorsabban üzembe helyezhető, cserébe kevésbé moduláris/rugalmas nagy, komplex, sok komponensből álló környezetekhez.

OpenStack

A legszélesebb körben elterjedt nyílt forráskódú IaaS felhőplatform, amivel saját, AWS-hez hasonló szolgáltatáskínálatú privát vagy hibrid felhő építhető ki. Moduláris felépítésű, önálló, de egymással együttműködő szolgáltatásokból áll, például:

• Nova - számítási erőforrások (VM-ek) kezelése
• Neutron - hálózatkezelés
• Cinder - blokk tárolás
• Swift - objektum tárolás
• Glance - image-ek (virtuálisgép-sablonok) kezelése
• Keystone - azonosítás- és jogosultságkezelés
• Horizon - webes admin felület

Nagyvállalati és telekommunikációs környezetekben (pl. saját adatközponttal rendelkező szolgáltatóknál) különösen elterjedt, ahol fontos szempont, hogy ne legyenek egy adott nyilvános felhőszolgáltatóhoz kötve (vendor lock-in elkerülése).

Virtualizáló szoftverek

A fentebb tárgyalt virtualizációs típusokat (paravirtualizáció, HVM) a gyakorlatban konkrét, telepíthető hypervisor-termékek valósítják meg. Néhány elterjedt, elsősorban vállalati/szerver környezetben használt példa:

• Red Hat Virtualization (RHV), KVM alapú
• Hyper-V, Windows
• z/VM, IBM VM OS
• VMware ESXi
• Oracle VM Server

Adattárolás a felhőben

Oldalszám: 215-230.

Tárolási modellek

A felhős tárolási szolgáltatásokat érdemes három alapmodell mentén elkülöníteni, amelyeket korábban az AWS szolgáltatásainál konkrét termékeken keresztül is érintettünk:

• Objektum tárolás (pl. AWS S3): fájlokat (objektumokat) tárol laposan, mappastruktúra nélkül (a "mappákat" csak a fájlnevek elé fűzött prefixek szimulálják), HTTP(S) API-n keresztül érhető el. Nagy mennyiségű, ritkán módosuló adathoz (képek, videók, biztonsági mentések, statikus weboldalak) ideális, de nem csatolható fájlrendszerként egy operációs rendszerbe.
• Blokk tárolás (pl. AWS EBS): egy nyers, particionálható, fájlrendszerrel ellátható "virtuális merevlemezt" ad, amit egyetlen szerverhez csatolunk. Adatbázisok, operációs rendszer image-ek jellemző felhasználási területei, mivel alacsony késleltetésű, blokk szintű elérést biztosít.
• Fájl tárolás (pl. AWS EFS - Elastic File System): hálózati fájlrendszer (NFSv4 alapokon), amit egyszerre több szerver is csatolhat és közösen írhat/olvashat, szemben az EBS-sel, ami jellemzően csak egy EC2-höz kapcsolódik aktívan. Megosztott konfigurációkhoz, közös feltöltési könyvtárakhoz kifejezetten hasznos (pl. egy Auto Scaling Group több példánya számára közös feltöltött fájlok tárolására).

Konzisztencia modellek

Elosztott, több gépen/zónán replikált tárolók esetén fontos kérdés, hogy egy írás után azonnal, minden olvasó ugyanazt az (új) adatot látja-e:

• Erős konzisztencia (strong consistency): egy sikeres írás után minden következő olvasás garantáltan a legfrissebb adatot adja vissza, függetlenül attól, melyik replikát/zónát érte el a kérés.
• Végső konzisztencia (eventual consistency): egy írás után rövid ideig előfordulhat, hogy egy másik replikáról olvasva még a régi adatot kapjuk vissza, de egy idő után (jellemzően másodperceken belül) minden replika konzisztenssé válik.

Érdemes tudni, hogy az AWS S3 sokáig csak végső konzisztenciát biztosított egyes műveleteknél, 2020 végétől azonban minden művelethez (GET, PUT, LIST, DELETE) erős, olvasás-írás utáni konzisztenciát garantál, külön felár nélkül.

Helyi fájlrendszerek a tárolás mögött

A blokk tárolók (pl. egy EBS kötet) önmagukban csak nyers, particionálatlan tárterületet adnak - ahhoz, hogy fájlokat tudjunk rajtuk tárolni, fájlrendszert kell rájuk telepíteni. A választott fájlrendszer jelentősen befolyásolja a teljesítményt, a megbízhatóságot és az üzemeltethetőséget, ezért érdemes ismerni a leggyakoribb Linux alatti lehetőségeket:

ext4

A legtöbb Linux disztribúció (pl. Ubuntu) alapértelmezett fájlrendszere. Naplózó (journaling) fájlrendszer, ami azt jelenti, hogy a metaadat-módosításokat előbb egy naplóba írja, csak utána a végleges helyükre, így egy váratlan áramkimaradás vagy összeomlás esetén is konzisztens állapotba állítható vissza gyorsan. Kiforrott, jól ismert, kompatibilis és jó alapértelmezett választás, ha nincs speciális igényünk.

XFS

Eredetileg az SGI IRIX rendszeréhez készült, ma a Red Hat Enterprise Linux (és az AlmaLinux, RockyLinux) alapértelmezett fájlrendszere. Kifejezetten nagy fájlokra és nagy párhuzamos írási/olvasási terhelésre lett optimalizálva (pl. adatbázisok, nagy médiafájlok), jól skálázódik több CPU maggal is. Hátránya, hogy natívan nem támogat pillanatképeket (snapshot) - ehhez alsóbb szintű megoldásra (pl. LVM snapshot) van szükség -, és a fájlrendszer méretét utólag csak növelni lehet, csökkenteni nem.

BTRFS

Modern, copy-on-write (CoW) elvű Linux fájlrendszer (az openSUSE alapértelmezettje, sok NAS gyártó - pl. Synology - is használja). A CoW elv miatt egy módosításkor sosem írja felül a régi adatot a helyén, hanem az új verziót máshova írja, majd a mutatókat frissíti - ennek köszönhetően pillanatképek (snapshot) készítése szinte azonnali és nulla extra hellyel jár (amíg az adat nem változik). Beépített adatintegritás-ellenőrzést (checksumming) végez minden blokkon, támogat tömörítést és több lemez összekapcsolását (hasonlóan egy RAID-hoz). Fontos korlát: a BTRFS RAID5/RAID6 módja évek óta ismert, nem javított "write hole" hibával küzd, éles környezetben emiatt továbbra sem ajánlott ezekben a módokban használni.

ZFS

Eredetileg a Sun Microsystems Solaris rendszeréhez készült, ma nyílt forráskódú, közösségi fejlesztésű folytatása az OpenZFS (Linux, FreeBSD, TrueNAS stb. alatt is elérhető). A ZFS egyszerre fájlrendszer és kötetkezelő (a hagyományos LVM+fájlrendszer páros helyett), ezért sok funkciót natívan, nagyon hatékonyan valósít meg:

• Copy-on-write elv, akárcsak a BTRFS-nél, így itt is azonnali, olcsó pillanatképek/klónok készíthetők
• Beépített, blokkonkénti ellenőrzőösszeg (checksum) minden adaton és metaadaton, ami az esetleges "silent data corruption" (csendes adatsérülés) hibákat is kiszűri
• Saját RAID megvalósítás (RAIDZ1/2/3), amely - szemben a hagyományos RAID5/6-tal - nem szenved a "write hole" jelenségtől
• Beépített tömörítés és (opcionális) deduplikáció
• Az ARC (Adaptive Replacement Cache) nevű, RAM-alapú olvasási gyorsítótár jelentősen felgyorsítja a gyakran használt adatok elérését

A ZFS erőforrásigénye (elsősorban RAM) magasabb a fentieknél, cserébe kiemelkedően megbízható, ezért elsősorban dedikált tárolószervereken, NAS-okon, adatbázis-szerverek mögött terjedt el.

Összefoglalás

Fájlrendszer	Copy-on-write	Natív snapshot	Natív RAID	Jellemző felhasználás
ext4	Nem	Nem	Nem	Általános célú, alapértelmezett választás
XFS	Nem	Nem	Nem	Nagy fájlok, párhuzamos I/O, adatbázisok
BTRFS	Igen	Igen	Igen (RAID5/6 kerülendő)	Desktop/NAS, gyors pillanatképek
ZFS (OpenZFS)	Igen	Igen	Igen (RAIDZ)	Dedikált tárolószerverek, NAS, kritikus adatok

Felhőbiztonság

Oldalszám: 257-291.

Megosztott felelősség modell

A felhőbiztonság megértésének alapja a korábban (a Felhő ökoszisztéma fejezetnél) már bemutatott megosztott biztonsági felelősség (Shared Responsibility Model): a szolgáltató mindig a felhő infrastruktúráját (fizikai biztonság, hypervisor, hálózati gerinc stb.) védi, míg az ügyfél felelőssége a felhőn belüli konfiguráció - annál több, minél alacsonyabb szintű szolgáltatást (IaaS) használ. A leggyakoribb, valós felhős biztonsági incidensek túlnyomó többsége nem a szolgáltató oldalán, hanem az ügyfél helytelen konfigurációjából (pl. nyilvánosan elérhető S3 bucket, túl megengedő jogosultság) fakad.

Identitás- és hozzáférés-kezelés (IAM)

Az AWS IAM (Identity and Access Management) szolgáltatásán keresztül szabályozható, hogy ki, milyen szolgáltatáshoz, milyen módon férhet hozzá. Alapelvek:

• Legkisebb jogosultság elve (least privilege): mindenki csak azt a jogosultságot kapja meg, ami a feladatához feltétlenül szükséges - ne adjunk soha alapból AdministratorAccess-t egy alkalmazásnak vagy felhasználónak.
• Felhasználók vs. szerepkörök (roles): önálló felhasználó helyett gyakran célszerűbb egy EC2-höz/Lambdához szerepkört (role) rendelni, amihez időben korlátozott, automatikusan lejáró hitelesítő adatok tartoznak - így nincs statikus kulcs, amit ellophatnak.
• Többfaktoros azonosítás (MFA): különösen a root és adminisztrátori fiókoknál alapkövetelmény.
• Hozzáférési kulcsok (Access Key) kezelése: ezek statikus, hosszú élettartamú titkok, ezért soha nem szabad forráskódba, verziókezelőbe (pl. GitHub) beleégetni őket - sajnos ez a felhős adatszivárgások egyik leggyakoribb oka.

Hálózati biztonság

A VPC-n belül több rétegben is szabályozható a forgalom:

• Security Group: a korábban már tárgyalt, EC2 (vagy más erőforrás) szintjén ható, stateful tűzfal - ha egy bejövő kapcsolatot engedélyezünk, a rá érkező válaszforgalmat automatikusan is engedi, külön szabály nélkül.
• Network ACL (NACL): alhálózat szintjén ható, stateless szűrő - itt a bejövő és kimenő szabályokat külön-külön, explicit módon kell megadni, mivel nem emlékszik a kapcsolat állapotára.
• Mélységi védelem (defense in depth): a gyakorlatban ezeket egymásra rétegezve érdemes alkalmazni (VPC szegmentálás, publikus/privát alhálózatok, Security Group + NACL együtt), hogy egyetlen hibásan beállított szabály se jelentsen azonnal teljes kompromittálódást.

Titkosítás

• Nyugalmi állapotú adatok (encryption at rest): a tárolt adatok titkosítása, jellemzően az AWS KMS (Key Management Service) által kezelt kulcsokkal - EBS kötetek, S3 objektumok, RDS adatbázisok mind támogatják, sok esetben egyetlen checkbox bekapcsolásával.
• Adatátviteli titkosítás (encryption in transit): a hálózaton mozgó adatok védelme, jellemzően TLS/HTTPS segítségével - egy publikus alkalmazásnál ez ma már alapkövetelmény, nem opció.

Monitorozás és naplózás

• CloudTrail: minden API-hívást naplóz (ki, mikor, milyen szolgáltatáson, milyen műveletet hajtott végre) - utólagos vizsgálathoz (audit), illetéktelen hozzáférés kiderítéséhez nélkülözhetetlen.
• GuardDuty: gépi tanuláson és fenyegetettségi adatbázisokon alapuló, folyamatos anomália-/fenyegetésfelismerő szolgáltatás (pl. szokatlan API-hívási minták, ismert rosszindulatú IP-kről érkező forgalom jelzése).
• CloudWatch: a korábban már tárgyalt monitorozó szolgáltatás biztonsági szempontból is releváns - riasztásokat (alarm) állíthatunk be szokatlan erőforrás-felhasználásra, ami akár egy kompromittálódás jele is lehet.

DDoS és alkalmazásszintű védelem

• AWS Shield: hálózati/szállítási rétegbeli (L3/L4) DDoS védelem, ami alapszinten minden ügyfélnek automatikusan, ingyenesen jár.
• AWS WAF (Web Application Firewall): alkalmazásrétegbeli (L7) szűrés, amivel pl. SQL injection, XSS és egyéb tipikus webes támadásminták ellen védekezhetünk, illetve rate limitinget is beállíthatunk vele.
• CloudFront (CDN): a felhasználókhoz földrajzilag közelebb elhelyezett gyorsítótárazó réteg, ami a látható eredeti szerver elrejtésével és a terhelés elosztásával is csökkenti a támadási felületet.

Tipikus felhős biztonsági hibák

A gyakorlatban tapasztalt incidensek jelentős része néhány visszatérő hibára vezethető vissza:

• Nyilvánosan (publikusan) elérhetőre állított S3 bucket, amiben bizalmas adat van
• Túl megengedő (pl. 0.0.0.0/0 minden portra nyitott) Security Group szabályok
• Forráskódba/verziókezelőbe kerülő, hardcode-olt hozzáférési kulcsok
• Az EC2 metaadat-szolgáltatás (Instance Metadata Service) régebbi, v1 verziójának használata, ami SSRF-sebezhetőség esetén jogosultsági adatok kiszivárgásához vezethet - emiatt ma már az újabb, tokenalapú IMDSv2 használata javasolt/kötelező sok szervezetnél
• Elavult, javítatlan szoftverek/csomagok futtatása a szerverpéldányokon (ezért is hasznos a korábban említett OpenVAS-szerű, CVE-alapú sebezhetőség-vizsgálat)

Megfelelőség (compliance)

A felhőszolgáltatók számos iparági és jogi szabványnak (pl. ISO 27001, SOC 2, PCI-DSS) való megfelelést tanúsítanak az infrastruktúrájukra, ez azonban csak a megosztott felelősség modell "szolgáltatói" felét fedi le - az, hogy egy konkrét alkalmazás/adatkezelés megfelel-e például a GDPR-nak, továbbra is az üzemeltető felelőssége, a megfelelő régióválasztástól kezdve a hozzáférés-szabályozásig.