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 szabad időablakra várakoznunk például Európából, amikor a weboldalukat akarjuk böngészni. 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 a Facebook eleinte az Amazon Web Services hálózatát használta fel, hogy a világ minden táján elérhető legyen, de mára saját infrastruktúrát épített ki.

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 - nem tudják garantálni, hogy az adatok csak egy földrészen legyenek tárolva, hiszen az egész koncepció az adatok szétszórására épül, így lesz az adatvesztés lehetősége relatíve 0 (ez azért érdekes, mert az EU kiköti, hogy az EU polgáraihoz köthető adatok csak az EU területén üzemelő szervereken tárolhatók, így egy bizalmas adatokat tároló cég [pl. bank] nem helyezheti ki azokat a felhőszolgáltatóhoz az erre vonatkozó garancia hiányában).

É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.
• Ngios - 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 infrastukrúra vezérlése magas szintű leírónyelv segítségével. Egy erre alkalmas alkalmazások mikroarchitektúrára épülnek, ahol az egységek külön-külön konténerekbe vannak csomagolva. A IaC segítségével megadhatjuk, hogy mit szeretnénk elindítani, szabályokat definiálhatunk az egységek közötti kommunikációt illetően, az annak megfelelő struktúra pedig megjelenik 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 igénylésére is, ahol a költségekre vonatkozóan az a szabály, hogy amíg használatban van, addig nincs plusz költsége, de minden olyan lefoglalt darabért fizetünk, ami nincs egyetlen futó szerverhez sem csatolva. 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, Simple DB stb.

Simple Storage System (S3)

Nagy objektumok tárolására alkalmaz 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 alapon működik, de akár BitTorrent hozzáférés is elérhető. Az egyes fájlokhoz MD5 hash 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 1 gigabájttól 1 terabájtig állítható. 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, de egy EBS csak egy EC2-höz lehet aktívan hozzárendelve. 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.

Simple DB

Nem relációs adatbázis séma, 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 másolatot készít. 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.

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 szolgáltatás hídként szolgál a meglévő informatikai infrastruktúra és az AWS között. A meglévő infrastruktúra általában VPN kapcsolaton keresztül csatlakozik a felhőhöz egy jól meghatározott, elkülönített erőforrás csoporthoz. A VPC lehetővé teszi, hogy ezek közé tűzfalat, IDS-t telepítsünk, hogy zökkenőmentesen tudjanak együttműködni.

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, amelyek Docker környezetben kerülnek telepítésre. A konténer 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 28+ adatközponttal rendelkezik szerte a világban. Egy rendelkezésre állási zóna (availability zone) egy adatközpontot jelent, amelyben 50.000-80.000 szerver található (nagyjából 25-30 MW teljesítménnyel). Minden régió legalább két rendelkezésre állási zónával rendelkezik, 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 találta fel 1938-ban. 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.

Virtualizáló szoftverek

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

Adattárolás a felhőben

Oldalszám: 215-230.

Felhőbiztonság

Oldalszám: 257-291.