Sok érdekes „aftermath” cikk jelent meg az Amazon Elastic Computing Cloud (EC2) múlt heti, elég hosszúra (majd’ 4 naposra) sikeredett kieséséről. Saját nevet is kapott („amazonpocalypse”), érezhetően-láthatóan befolyásolta az internet működését (tehát kiderült, hogy az Amazon egyfajta Single Point of Failure-ré avanzsált), és végső soron az EC2 a cloud szerverhosting szolgáltatások zászlóshajójának tekinthető, úgyhogy a zemberek kicsit megálltak és esetenként talán el is gondolkoztak ezen a cloud nevű „félig lufi, félig bölcsek köve” jelenségen.
Az utózönge-cikkek természetesen egyöntetűen egyetértettek abban, hogy még egy ilyen illusztris cloud szolgáltatás is megfekszik, következésképpen célszerű a szolgáltatásaidat tükrözni, mégpedig szükség esetén (a szeretnéd, hogy működjön a szolgáltatásod) másik, független szolgáltatásba. Mert hiába egy Amazon redundancia, láthatjuk, hogy az is megfekszik. Igaz a dakota mondás: ne tartsd a tojásaidat egy kosárban.
Aztán persze egy ilyen leállás felveti azt a problémát is, hogy hol is van konkrétan az adatod. Amíg az ember a felhők közt jár (a cloudban, ugye), esetleg kevéssé gondol arra, hogy nem tudja, hogy hol van az adat. Egy ilyen leállás első pár órájában azt sem tudja, hogy megvan-e még az adat, és ez gyomorszorító érzés. Amazon alapszolgáltatás esetében egyébként (sejtem hogy még ma is) első körben a fórumokat ajánlják lelki támasznak, biosupport nincs; némi extra pénzmag (azt hiszem talán havi 400 dollár) és kb. 1 nap körömrágás árán viszont kaphatsz gold supportot, ahol akár már telefonálhatsz is. (Hiába, a valódi szekértelem sehol sincs ingyen!)
Az adatvesztés veszélyére a kézenfekvő válasz pedig természetesen a fizikai backup rendszer fenntartása — vagy egy szimpla offsite backup formájában (persze cégmérettől, és az adat fontosságától függően azért óva intenék mindenkit attól, hogy egy Time Machine jellegű tákolt megoldásra backupoljon), vagy valami komolyabb, fizikai valóságban megfogható, eltehető, előszedhető, visszaállítható mentés formájában, amire backup policy van, és hasonlók.
Mellékszál, de felmerül az is, hogy egyáltalán mi van akkor, amikor szerződést bontasz pl. egy Amazonnal, vagy tönkremegy alólad a cloud hosting cég. Kevéssé ismert tény, de a mostani leállás ráirányította a fényt, hogy tavaly és idén az USA-ban 4 nagy cloud szolgáltató húzza le a rolót. Mi történik azzal az adattal? Migrálható? Ha szerződést bontasz, az adatot valóban törlik, vagy csak úgy ottmarad, szanaszéjjel? Ezért is fontos kérdés, hogy fizikailag vajon hol van az adat. Szerződésbontás esetén hogyan garantálja a cloud szolgáltató, hogy valóban megsemmisíti, vagy legalább biztonságosan törli/tárolja az adataidat?
És még egy érdekesség: szintén kevéssé publikált fonákja az Amazon sztorinak, hogy a négynapos leállás ellenére nem sérült az EC2 SLA-ja. Mivel az ügyfél az EC2-re köt szerződést, az SLA is arra szól. A leállás viszont nem a szűken vett EC2-ben, hanem csatolt (igaz, létfontosságú) szolgáltatásokban történt. Az Amazon egyébként 99,95% rendelkezésre állást biztosít éves szinten, ami elég magas követelmény, de hát persze így könnyű.
A cloud szolgáltatásoknál tehát kb. a következő pár dologra érdemes figyelni:
- Először is, ha olyan az adatod, inkább építs/vásárolj/bérelj saját megoldást. („Olyan”: fontos, vagy magas biztonsági szintű.) Ha nem tudod vállalni azt, hogy esetleges szolgáltatóváltás esetén nem lehetsz biztos abban, hogy a régi szolgáltató nem lép fel iszonyat magas data privacy risk-ként, ne is vágd cloudba a fejszédet.
- Redundancia, redundancia, redundancia! És nem csak szolgáltató szinten belül: ha számít a szolgáltatás folytonossága, hozz létre több szolgáltatóra épülő redundáns rendszert. Nem olcsó, de nem is híg a leve.
- Legyen a live szolgáltatástól független backup megoldásod! Már ha egy heti inkrementálison csücsülsz, nyugodtabban alszol.
- Mindig legyen biosupport! Az idő 95%-ában nincs rá szükséged (bár egyébként egyszerűsíti az életet), de a maradék 5%-ban hálát adsz, hogy belefeccöltél.
- A szolgáltatóiddal (a live szolgáltatás, a backup szolgáltatás, és a support is) legyen jó, működő SLA-d. Cloud esetében talán ezt a legnehezebb elérni, hiszen reménytelen, hogy egy Amazon a te kedvedért extra klauzát épít be a szerződésbe.
Nagyjából összefoglalható úgy a dolog, hogy jó dolog a cloud, de az igazán biztonságos rendszer az, amibe bele tudsz rúgni: néhány nagyvas a datacenterben, és a support személyzet… (Itt kérek elnézést a rendszergazda kollegáktól.)
A fentiekhez disclaimer jelleggel azért hozzáteszem a következőket:
- A mostani leállás győztesei természetesen mi, felhasználók leszünk: a cloud szolgáltatók nyilván össze fogják magukat kapni, és ezek a szolgáltatások magasabb biztonsági szintre fognak idővel lépni. Persze az ördög nem alszik, a felhaszálói oldali redundancia szüksége nem múlik el.
- A fentiekkel nem azt akarom sugallni, hogy mostantól az állatorvos weboldala is saját szerveren kell majd fusson — nyilván igénye válogatja, hogy mire érdemes shared hostingot, mire cloudot, és mire skálázott saját megoldást választani. A biosupportot viszont a saját nyugalom megőrzése érdekében mindenkinek ajánlom, akármit is választ.
