"Redmond, valami baj van ..."

 ( trey | 2019. február 1., péntek - 11:47 )

Részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Na az üzemeltető niggáknak is már csak kettőt kell aludni húsvétig. :D
"Joe, van mentésünk?" "Hátőőő"

-pilisig-

Ez ismét a "felhő" dicsérete. Mármint, hogy a fasz tudja, hogy valóban van-e mentés, az mennyire konzisztens, mennyire naprakész és mennyire tudja a szolgáltató időre, jól, pontosan visszaállítani.

Ha magam kezelem, azért nagyjából képben vagyok vele (meg az esetleges gyengeségeivel is).

--
trey @ gépház

A Cloud egyik elönye ugyebár a biztonság lenne, legalábbis ezt súlykolják marketing alapon.
Na, ettöl kezdve már bizonyíték is van rá, hogy ez nem igaz.

--
robyboy

Ezt elhitte valaki valaha is?

-pilisig-

Az emberiség 99%-a elhisz mindent, amit elé tolnak.

--
robyboy

a lényeg, hogy a döntéshozók elhiggyék, márpedig ők hajlamosak csodaszerként tekinteni a "cloud"-ra, mert hallottak róla a tévében

persze hogy elhiszik, mert latjak ha felneznek az egre.
a sajat mentesunket meg nem latjak :)

Szerintem sokan elhiszik, különösen azok akiknek reccsent meg már winchestere a 2000-es években. Felhőkben ahhoz képes eddig jóval kevesebb hasonló incidens történt. Az adataid olcsóbban vannak nagyobb biztonságban. Inkább olyan bakiktól kell tartani amik saját háttértáron nem fordulhatnak olyan könnyen elő, mint hogy publikusan hozzáférhetővé válnak a felhős fájljaid, Microsoft Azure-on különösen. :)
Ezért titkosítás eléggé javallott felhő mellett.

Az elreccsen a vinyó és a felhő mellett azért elég sok minden van még. Technológiailag is, költségileg is, szolgáltatásban is.

Azzal egyet értek, hogy egy mentésnek a felhő kiváló lehet.

Sajat menteseink AWS eseten mindig egy masik szolgaltato cloudjaban illetve sajat DC-ben voltak tarolva.

Anno mikor az AWS eloszor megkotlott lett ez bevezetve addig mi is hiszekenyek voltunk :D

Hát itt most pont a mentés vizsgázott. Letörlődött egy hibás automatizmus miatt x db adatbázis. Visszaállitották mindenkinek a mentést, ami legrosszabb esetben 5 perccel régebbi, mint a törlési időpontja. Aki ezt elfogadja, az használja igy, aki nem, az pedig nyit egy support ticketet és megpróbálják az adatbázis logból visszaszedni a hiányzó tranzakciókat.

A törlődés nagyon gáz, viszont maga a backup rendszer szerintem jól vizsgázott. Nagyon sokan örülnének, ha egy ilyen katasztrófa után bármely pillanatban lenne nekik egy 5 percnél nem régebbi mentésük az adataikról. (nyilván aki tuti biztosra ment az eleve replikált máshova is és nincs problémája, akár felhő akár helyi rendszer)

A panaszos tweet-ből:

"The database is back restored but is empty"

--
trey @ gépház

Ez valami kivétel lehet, fórumok tele vannak az 5 perccel régebbi backup visszaállásokról, ill. a hivatalos közlemény is ez.

Idézet:
I heard from other people that they have the same issue but there databases are not restored

?

Nem! Ez a Microsoft dícsérete.
A felhővel nincs semmi baj, csak normális rendszer kell alá.
Őszintén szólva nem lepne meg ha szép csendben a Microsoft O~S-re cserélné az Azure alatti rendszert szép csendesen ezután az incidens után.
Google cloud köszöni szépen és jól működik.
Amazon AWS köszöni szépen és jól működik.
Provlémák a Microsoft feljőjével vannak és ez már nem az első eset.
Már az sem lepne meg ha 5 év múlva Linux alapon menne a Microsoft desktop és szerver operációs rendszere is.

AWS is mar megallt parszor mint a szog...

A baj csak az, hogy sem a Google sem az AWS nem tud garantálni egyébként semmit, és náluk is bármikor beüthet a krach.

Adatmentés. Nemrég megtaláltak egy 100 éves filmfelvételt jó minőségben, amin látható 3 perc Ady Endre temetéséről.
Szenzációs!

Hol lesznek a mai felvételek, adatok 100 év múlva?

--
robyboy

Hát a felhők között! :-D

Ebben igazad van! De a Western Digital, Seagate, Kingston, Crucial sem garantálja, hogy holnap is eléred az adataidat a háttértáraikon. Történhetnek olyan események, villám, tűz vagy tüzet megelőző de mindent eláztató tűzvédelem, amikor a RAID sem segít.
Volt példa arra is, hogy egymás után döglöttek meg az egy szériából származó háttértárak gyártási hiba miatt. Ez a nagyobb szervezetet ugyanúgy érinti mint a kis egyéni raid rendszereket.
A valóban jó adatbiztonsághoz kell a több helyszín és leginkább a szalagos backup. Ez így együtt már szép összeg annak ellenére hogy a legolcsóbb pénz/GB adathordozótípus ma is a streamer szalag, plus a vele járó rendszeres munka.

Mint technológiának a felhőnek nincs alternatívája jelenleg, annyival hatékonyabb. A kérdés innentől, hogy saját felhő vagy külsős cég felhője. A nyílt forráskódnak hála, ownCloud-tól O~S-ig van választás. De saját felhőhöz is kell a jó backup stratégia.

Jeleg az arany középút szerintem két külsős felhő használata különböző szolgáltatóknál.
Ha nem bízol a privacy-ban (szerződés szerint a fizetsz nincs megfigyelés) akkor csak adattárolás titkosítottan. Ez esetben az adattároláson kívüli felhős szolgáltatásokról le kell mondanod és ezt az oldalt magadnál kell megoldani. Szerencsére erre is egyre jobb opensource megoldások vannak.

"Adatmentés. Nemrég megtaláltak egy 100 éves filmfelvételt jó minőségben, amin látható 3 perc Ady Endre temetéséről.
Szenzációs!"

De 100 évig senki sem látta. Ez alatt sokan leélték a komplett életüket anélkül, hogy esélyük lett volna Ady Endre temetéséről készült filmfelvétel megtekintésére.
Hofi Géza temetéséről készült filmfelvételt bárki meg tudja nézni a világ bármely pontjáról. Ez is előny azt ne felejtsük el.
Ami a hosszú távú adattárolást illeti. Pozitív példa: ma is megtalálhatóak 70-es években írt programkódok, akkor fontosnak és megőrzésre érdemesnek tartott állományok. Sőt korábbról is.
Negatív példa: Babylon-5 fimsorozat, amit jövőbiztosan 16:9-ben vettek fel és a nagy számú digitális animációt is archiválták. De ezeknek a mentéseknek jó részét elkutyulták az idők során. Ami megvan azzal sem tudnak mit kezdeni mert a hiányos dokumentáció miatt nem tudnak mit kezdeni a meglevő fájlokkal annyira egyedi cgi megoldással dolgoztak.
Ezért nem tudtak végül Bluray HD kiadást készíteni a sorozatból.

A magyar hangarchívumnál úgy 8 éve megvizsgálták a digitalizáció lehetőségét. Akkor elvetették és maradtak az analóg matrica gyártásnál. Szóval nyilván sok igazság van abban is amit írsz.
Mindig meg kell találni a optimális megoldást időállóság, karbantartási idény, elérhetővé tétel között. Sok esetben különböző megoldások kombinációja vezet a legjobb eredményre.

Nem zárható ki egy Blade Runner 2049 -féle "Blackout" esemény a jövőben, amikor masszív digitális adatveszteség történik globálisan.

Igen, fontos adatoknál a georedundancia létkérdés. Pont egy felhőmegoldástól várná el ezt egyébként az ember.
NAS-t én is tudok itthon -egy "telephelyen"- csinálni.

--
robyboy

+1 Pont ez az, aminek a költsége felhő esetén minimális volna. A georedundanciát "csak" jól kell megtervezni, és nagyon jól skálázódik utána, nem lesz tőle drágább. Egyesével pedig ezt a baromi drága megcsinálni. Ha ezt tudná a felhő, akkor érné meg. Ha a felhő csak egy "bazinagy" szerverközpont, az annyira nem vonzó.

Emlékszem, hogy amikor elkezdték a felhőt promózni, akkor még hitegettek ilyesmivel, hogy mennyire redundáns lesz, aztán ezek alábbhagytak. Inkább olcsón akarnak sokat kaszálni :-)

Backblaze és Crashplan nem valódi felhő szolgáltatók, viszont georedundanciára eléggé jók mert csak Amerikában vannak szervereik. :)
Csak nehogy kikényszerítse belőlük az EU az európai szervereket!

Egy checkboxot kell bekattintani, és georedundánsan is lehet deployolni, csak nem megijedni a felvillanó összegtől. A felhasználótól függ, hogy melyiket választja.

Vagy ha két felhő van két szolgáltatónál, ami biztonság oldalon sokat jelent, a második felhővel is megvalósítható a georedundancia.

A felhő szolgáltató egy telephelynek is tekinthető:
- mint most láttuk, van egy olyan komplex vezérlési rétege (helyi infrastruktúrában ez tipikusan hiányzik), amiben bármikor történhet hiba és előfizetői adatvesztéssel járhat. Van üzleti ügyfelem, akinek O365 dolgai vesztek oda, most ez az adatbázis mizéria, de nemrégen a Google is lapított emlékeim szerint valamilyen illetéktelen behatolásról (nem kapott nagy hírverést; lehet, hogy nem történt számot tevő kár, de akár történhetett is volna)
- mint szeptemberben láttuk Azure kapcsán, "alapvető" problémák is előfordulhatnak (hibás adatközpont tervezés).
- megszűnhet: ennek nagyok esetén kicsi az esélye, de az egyszerűbb szolgáltatásokat is ide lehetne érteni (pl. korábban rendőrség kivonult warez miatt és lefoglalt szervereket, ezen szerverek kapcsán esetleg üzleti ügyfelek is érintettek lehettek)

Normál infrastruktúrában mit kell csinálni egy telephellyel? Menteni. Miként kell menteni? Mindenki eldönti saját maga, hol van a műszaki minőség és a pénzügyi mennyiség (kockázat) közös nevezője.

Keresett már meg ügyfél teljesen önszántából: nem nyugodt, hogy minden levelük csak a Google-nél van meg, jó lenne valami mentési megoldás. Sokat nem akarnak rá áldozni, de nyugodtabb lenne. Lett és megnyugodott.
És szaporodnak a felhő mentő szoftverek.

Lehet volt a Googlenél is, de ilyenek mint a Microsoftnál nem volt. Ráadásul már nem ez az első eset. Ekkora bakit még a Google sem tudna a szőnyeg alá sörögetni.
Az egyik korábbi Microsoft okostelefonos próbálkozásnak is egy nagy adatvesztés vetett véget:
http://www.bbc.co.uk/blogs/technology/2009/10/the_sidekick_cloud_disaster.html

Annyi baj van az Azure-ral, hogy én komolyan nem merek számolni vele mint felhős megoldással.

"Keresett már meg ügyfél teljesen önszántából: nem nyugodt, hogy minden levelük csak a Google-nél van meg, jó lenne valami mentési megoldás. Sokat nem akarnak rá áldozni, de nyugodtabb lenne. Lett és megnyugodott.
És szaporodnak a felhő mentő szoftverek."

Fizetett a Gmail használatáért? Mert ez a első mielőtt drága egyedi megoldásokhoz nyúl valaki.
Googlenél pont számtalan jó megoldás létezik erre, kezdve a Google takeout-tal, ami értelmes formátumba teszi letölthetővé a felhasználói adatokat szolgáltatásonként. Persze gmail backupra jó egy sima imap is.

Google-nél dolgozol? :-)

Probléma mindenhol lehet. A legjobb helyeken is. Van, ahol megússzák kisebb problémákkal, akár kevesebbel, de garancia semmire nincs, legfeljebb valószínűségek, amibe sok minden belefér.

"Fizetett-e a Gmailért?" Első felhasználók között voltak, így még ingyenesen használják, mostanában fognak átmenni fizetősbe. De a történet szempontjából teljesen közömbös, mert nem emiatt aggasztotta. Hiába fizet, ha egyszer elvesznek az adatok (teljesen mindegy, hogy mi az oka).

Nekem úgy tűnik, hogy elviekben mozogsz csak üzemeltetésben, nem gyakorlatban, a felhőt inkább evangelizálod, mint alkalmazod:
- takeouttal nem fogsz naponta vagy akár hetente kézzel játszani minden felhasználóra, tudomásom szerint nem automatizálható, ráadásul mindig mindent menteni nem célszerű
- IMAP: akkor lehet jó, ha az IMAP tükrödet mented, de még akkor is macerás egyenként kezelni a fiókokat (azaz megvalósítasz egy helyi levelező szerver mentést, amitől szabadulni akartál). Ugyanis ha olyan hiba van, hogy eltűnnek a levelek, akkor az IMAP tükörből is el fognak tűnni a levelek.

Másik hozzászólásodban írod, hogy leghatékonyabb technológia a felhő. A felhő nem technológia, hanem szolgáltatási modell. A hatékonyságot elég nehéz általánosan mérni. Az valószínű (de nem biztos), hogy néhány fős cégnek nem éri meg saját levelező szervert üzemeltetni, más hasonló szolgáltatások is vannak, de ha mindent bedobsz a kalapba, számolsz, akkor más is jöhet ki.

""Fizetett-e a Gmailért?" Első felhasználók között voltak, így még ingyenesen használják, mostanában fognak átmenni fizetősbe. De a történet szempontjából teljesen közömbös, mert nem emiatt aggasztotta. Hiába fizet, ha egyszer elvesznek az adatok (teljesen mindegy, hogy mi az oka)."

Egyáltalán nem mindegy. Más stratégiába vannak a fizetős és ingyenes ügyfelek, adattárolás, adatkezelés szempontból. Fizetős Google ügyfelek adataival nem kufárkodik a Google, egy esetleges krach esetén sokkal nagyobb valószínűséggel maradnak meg a fizetős ügyfelek adatai mint az ingyenes felhasználóké. Bár a pontos részleteket sosem fogja nyilvánosságra hozni a Google.

"takeouttal nem fogsz naponta vagy akár hetente kézzel játszani minden felhasználóra, tudomásom szerint nem automatizálható, ráadásul mindig mindent menteni nem célszerű"

Automatizálható, én megcsináltam. Egyedi megoldás.
Ha érdekel egy tipp, tervezés közben érdemes szolgáltatásonként megvizsgálni milyen szolgáltatásról van szó. Nem mindig az az optimális ha brute-force nekiesünk a takeout-nak.
Differential mentés aránylag egyszerűen megoldható incrementallal már nem biztos, hogy érdemes vesződni. Természetesne jó lenne ha ezt a Google Takeout saját oldalán tudná. Sávszélt is spórolna ezzel mindenki.

"IMAP: akkor lehet jó, ha az IMAP tükrödet mented, de még akkor is macerás egyenként kezelni a fiókokat (azaz megvalósítasz egy helyi levelező szerver mentést, amitől szabadulni akartál). Ugyanis ha olyan hiba van, hogy eltűnnek a levelek, akkor az IMAP tükörből is el fognak tűnni a levelek."

Természetesen imap tükör nem archiválási megoldás. A helyi imap tökörről készített rendszeres backup már az. Pláne ha az szalagra kerül.
De lehetne más megközelítéssel ZFS snapshotokban is gondolkodni.

"Másik hozzászólásodban írod, hogy leghatékonyabb technológia a felhő. A felhő nem technológia, hanem szolgáltatási modell. A hatékonyságot elég nehéz általánosan mérni. Az valószínű (de nem biztos), hogy néhány fős cégnek nem éri meg saját levelező szervert üzemeltetni, más hasonló szolgáltatások is vannak, de ha mindent bedobsz a kalapba, számolsz, akkor más is jöhet ki."

Cloud computing, cloud technology, eléggé széles körben használjuk ezeket a szóösszetételeket. De ne indítsunk megint n+1 nyelvészvitát.
Egy levelezőszerver még nem felhő. A freemail nem felhős szolgáltatás volt (már jó ideje nem követem mit bénáznak ott, szóval az aktuális állapotot nem ismerem). A Gmail az első perctől kezdve felhős szolgáltatás volt. A különbség azonnal érezhető volt. Egy jól megtervezett felhőn kevesebb mint tized annyi ember erőforrással oldhatóak meg azok a feladatok amik az egyedi szerveknél sok időt igényelnek, és ezért gyakran hanyagolják is. Jól lehet automatizálni feladatokat. Saját infrastruktúrán is jó megoldás egy O~S.

"Nekem úgy tűnik, hogy elviekben mozogsz csak üzemeltetésben, nem gyakorlatban, a felhőt inkább evangelizálod, mint alkalmazod"

Programozó vagyok nem rendszergazda. De azt tapasztalom, hogy sokkal jobban képben vagyok mint a tisztelt magyar rendszergazdák, tisztelet a kivételeknek. Sokszor azért ragaszkodnak elavult, gyenge hatékonyágú megoldásokhoz, mert a tisztelt rendszergazdák nem hajlandóak haladni a korral.

Google-nél dolgozol? (ez elég fontos kérdés)

"Más stratégiába vannak a fizetős és ingyenes ügyfelek, adattárolás, adatkezelés szempontból."

Ettől még elveszhet az adat, magad is leírod, hogy "nagyobb valószínűséggel maradnak meg".

Takeout: lehet, hogy meg lehet csinálni, én hirtelen nem találtam meg (sőt, nem is kerestem igazán, az ügyfél nézte a lehetőséget), ha faragni kell, akkor már megint ott tartunk, hogy távolodunk a felhő fő alapelvétől: nyűgöt adjuk át másnak, mindenki foglalkozzon azzal, amihez ért. (engem arra kért meg, hogy keressek "dobozos" megoldást)

IMAP: nem csak ZFS pillanatkép van, de teljesen mindegy miként oldjuk meg, az IMAP önmagában nem megoldás, azaz nem ennyire egyszerű. A mentés akkor mentés, ha vissza is lehet állítani, azaz a folyamatokat ki kell dolgozni köré, ergó dolgozni kell vele.

Tény, hogy kár a felhő definícióján lovagolni, ráadásul két oldala: aki csinálja, és aki fizet érte. Előbbinek technológiákat kell alkalmaznia, utóbbit az érdekli, hogy igényeihez rugalmas szolgáltatást kapjon.

"Sokszor azért ragaszkodnak elavult, gyenge hatékonyágú megoldásokhoz, mert a tisztelt rendszergazdák nem hajlandóak haladni a korral."

Sok megoldás esetén nemcsak azzal van gond, hogy nem hatékony, hanem a "megoldás" is problémás (ha készült egyáltalán megoldás valamilyen implicit/explicit igényre).

Ez önmagában nem jelenti azt, hogy nem felhővel ne lehetne "jobban" megoldani valamit, hanem azt mutatja, hogy híg a szakma. Üzleti oldalról sokan bíznak abban, hogy a felhőben normális szakértelmet kap (az is kiadás, hogy olyan ember/szolgáltató kerüljön adott céghez, aki normálisan tud dolgozni). A Microsoft egyelőre rombolja ezt a képet.

Az biztos, hogy a felhő a jövő nagyon fontos része, de az ma még nem igaz, hogy a felhő mindenre jobb, olcsóbb és egyszerűbb megoldást tud kínálni.
Például a szeptemberi Azure bénázásnál kétféle érintett ügyfélről is lehetett olvasni:
- egyiknek az volt a fontos, hogy visszaálljon a szolgáltatás - akár adatvesztéssel
- másiknak az volt a fontos, hogy ne legyen adatvesztés, az idő kevésbé kritikus
Hely infrastruktúra esetén egy ilyen helyzetet rugalmasabban lehet kezelni, akár eseti jelleggel is (normális infrastruktúra esetén ezen esetek száma azért eléggé minimális).

"Google-nél dolgozol? (ez elég fontos kérdés)"

Miért fontos?

"Ettől még elveszhet az adat, magad is leírod, hogy "nagyobb valószínűséggel maradnak meg". "

Nálad sokkal nagyobb valószínűséggel fog elveszni. Teljesen más lehetőségei vannak egy nagy és magas megbízhatóságú multinak mint akár egy közepes, sőt nagy magyar vállalatnak. De 100% biztonság sehol sincs és nem is lesz.

"Takeout: lehet, hogy meg lehet csinálni, én hirtelen nem találtam meg (sőt, nem is kerestem igazán, az ügyfél nézte a lehetőséget), ha faragni kell, akkor már megint ott tartunk, hogy távolodunk a felhő fő alapelvétől: nyűgöt adjuk át másnak, mindenki foglalkozzon azzal, amihez ért. (engem arra kért meg, hogy keressek "dobozos" megoldást)"

Igen a felhő a kényelemről is biztonságról szól a nagyobb hatékonyság mellett. A Microsoftot most vegyük ki a megbízható felhőszolgáltatók listájáról mert ami ott megy az már valóban szánalmas. A "dobozos" mentés már extra biztonság a felhő különben magas biztonságán túl.
Egy teljesen saját infrastruktúrához képest már a Google vagy Amazon felhő önmagában biztonságosabb megoldás még "dobozos" mentés nélkül is.
Kicsit olyan ez mint az autó vs repülőgép. Minden statisztika több évtizedre visszamenőleg azt mutatja sokkal biztonságosabb repülőgéppel utazni mint autóval (a magánrepülőket most hagyjuk maradjunk a légitársaságoknál). Mégis sokan érzik úgy, biztosabb ha ő maguk fogják a kormányt. Baleset esetén legalább csak magukat hibáztathatják. Még egy repülőgépben az utas teljesen ki van szolgáltatva a pilótának.
"Dobozos" mentésnél sem mindegy, hogy mi az elvárás a felhő megreccsenése esetén?
Azonnal vagy órákon belül vissza kell állítani a szolgáltatást saját vason. Vagy ráér egy hét múlva is ha a felhőben valóban nagy a baj. Előbbi esetnek nagyok a költségei akkor is ha nem történik semmi.

"IMAP: nem csak ZFS pillanatkép van, de teljesen mindegy miként oldjuk meg, az IMAP önmagában nem megoldás, azaz nem ennyire egyszerű. A mentés akkor mentés, ha vissza is lehet állítani, azaz a folyamatokat ki kell dolgozni köré, ergo dolgozni kell vele."

Az IMAP éppen az egyszerűbb problémákhoz tartozik. Készenlétben kell tartani egy saját email szervert ahova rendszeres időközönként fel vannak töltve az emailek. Akár az üzemkész állapotban levő saját email szerverről is lehet készíteni rendszeresen pillanatképeket. Ha törlődnek emailek a felhős szerverről vissza lehet lépni a saját korábbi pillanatképhez.
A saját korábbi pillanatkép nemcsak az email szerver fájljairól készülhet hanem virtuális gép esetén magáról az email szerver image-ről is. Ott mindenképp működőképes korábbi állapototokhoz lehet visszatérni szerver szintjén is átgondolt tervezés esetén.
A Google-nél valójában nem lehet törölni semmit, ilyen a Google FS. Ha valóban támadás miatt történne tömeges email törlés Gmail-en, különösen fizetett ügyfélnek visszaállítják az így elveszett leveleit még a Google-nél.
De egy saját mentési stratéga mindig jó ha van emellett is.

"Sok megoldás esetén nemcsak azzal van gond, hogy nem hatékony, hanem a "megoldás" is problémás (ha készült egyáltalán megoldás valamilyen implicit/explicit igényre).

Ez önmagában nem jelenti azt, hogy nem felhővel ne lehetne "jobban" megoldani valamit, hanem azt mutatja, hogy híg a szakma. Üzleti oldalról sokan bíznak abban, hogy a felhőben normális szakértelmet kap (az is kiadás, hogy olyan ember/szolgáltató kerüljön adott céghez, aki normálisan tud dolgozni). A Microsoft egyelőre rombolja ezt a képet."

Sajnos ebben sok igazság van. A Microsoft a történelmi előzmények miatt túlzottan beágyazott Magyarországon. Teljesen más terület, de a Windows Phone zsákutcába is sokkal több magyar ment bele mint a világátlag, különösen az IT-hoz közeli emberek.
Azt továbbra is fenntartom, hogy Amazon vagy Google felhőben jobb szakértelmet kapnak magyar vállalatok mint sok esetben náluk cégen belül. De ez nem akadálya annak, hogy cégen belül nem annyira jó szakembereikkel csináljanak további, saját kézben tartott backup stratégiát.
Csak a sorrendre kell ügyelni!
Első és minimum a fizetős szolgáltatás a felhőben. Fura, de Magyarországon ezt sem árt leírni.
Második egy további felhőszolgáltató használata. Ez még mindig olcsóbb és biztosabb mint a saját "dobozos" megoldás.
És ha ez sem elég, akkor jöhet harmadik védelmi vonalnak a saját megoldás.

"Az biztos, hogy a felhő a jövő nagyon fontos része, de az ma még nem igaz, hogy a felhő mindenre jobb, olcsóbb és egyszerűbb megoldást tud kínálni.
Például a szeptemberi Azure bénázásnál kétféle érintett ügyfélről is lehetett olvasni:
- egyiknek az volt a fontos, hogy visszaálljon a szolgáltatás - akár adatvesztéssel
- másiknak az volt a fontos, hogy ne legyen adatvesztés, az idő kevésbé kritikus
Hely infrastruktúra esetén egy ilyen helyzetet rugalmasabban lehet kezelni, akár eseti jelleggel is (normális infrastruktúra esetén ezen esetek száma azért eléggé minimális)."

Főleg Office miatt nincs könnyű helyzet. Bár eddig ebbe nem mentünk bele, de felhőn belül sem mindegy, hogy csak fájlszervernek használjuk és mondjuk email szervernek vagy szofisztikáltabb felhős szolgáltatásokat is használunk?
A Microsoft jelenleg eléggé megkerülhetetlen Office-ban. Bár például az amerikai iskolarendszer elég jól át tudott állni Google Docs-ra és ez máshol is opció ahol nem kell kifele nagy mennyiségű és összetett dokumentumot cserélni naponta külsősökkel.
Az Office 365 felhőnek nincs sem saját felhős sem 3rd party felhős alternatívája. Egyetlen alternatíva a natív MS Office. A dokumentumok más felhőbe való backupolása ennek ellére ha nem is ad zökkenőmentes menekülőutat de legalább biztosítja az adatvesztés nélküli működés fenntartását MS reccsenések időszakaiban. Extra munka mindenképp van vele.
Szóval akinek van mentése a dokumentumairól most nem kell sem adatvesztéstől tartania, sem a Microsoft szolgáltatásának visszaállására várnia. Folytatja a munkát natív Office csomaggal Amazon vagy Google felhőben levő dokumentumokkal.

Google munkahely nyilván az esetleges elfogultság miatt fontos, bár furcsa, hogy ez miért kérdéses...

"De 100% biztonság sehol sincs és nem is lesz."

Éppen ezért akart az ügyfél mentést a Google-nél tárolt adatokról. Innen indult a gondolat, remélhetőleg nem bűn, ha valaki még nyugodtabban szeretne aludni viszonylag kis többlet költségért.
És valószínűleg egyre többen, mivel látszólag nő a felhő mentő szoftverek kínálata.

"Egy teljesen saját infrastruktúrához képest már a Google vagy Amazon felhő önmagában biztonságosabb megoldás még "dobozos" mentés nélkül is. "

Valószínűleg igen, de ha valahol van telephelyen kívüli mentés is, akkor az tipikusan elég jó (még ha technológiailag nem is közelíti meg a normális felhőket), a kérdés az ár és az egyéb szempontok (sok lehet).

"Készenlétben kell tartani egy saját email szervert..."

Pont ezt akartuk elkerülni a felhővel. A sok hókuszpókkal végül kvázi ott vagyunk, mintha helyi infrastruktúrát építenénk.

"Van üzleti ügyfelem, akinek O365 dolgai vesztek oda" --> Ebben az esetben mit tettél?
a. ihat rá hidegvizet.
b. volt esetleg plusz mentés?

a.-ra tippelnék, ugyanis az ember ha már felhő szolgáltatást választ, jelen esetben O365-öt ahol az adatok eleve replikálva tárolódnak (by default nem geo redundanica, de raid), így nem készít mentést.

A felhő nem ígér neked mentést, konkrétan nem adnak, garancia sincs az adatokra. Melyiknél van bármi erre utaló az ÁSZF-jükben? Általában az állandó működést és a "gondtalanságot" adná a felhő, de foglalkozni azzal is kell, saját példányos mentés sem árt. Miért bízna meg bárki egy bármilyen 3rd partyban úgy, hogy garantál adatot. Lásd a 7+ éves pénzügyi vagy a mégkomolyabb munkaügyi adatmegörzési időket. Ezeket neked kell teljesíteni, nem egy random szolgáltatónak. A bónusz, hogy mindenki saját maga tudja, hogy mennyire értékesek az adatai és ennek megfelelően tudja kelezgetni őket.

Hatékony megoldás két felhő használata. Mellette opcionálisan rendszeres data takeout. Sajnos differential vagy incremental takeout lehetőséget még senkinél sem láttam, ezt saját infrastruktúrán kell megvalósítani. Kell hozzá 2x annyi tárhely mint amennyi adatod van, streamer de ez már valóban eléggé biztonságos megoldás.

Nekem gyanús, hogy a Veeam tud mindenféle helyekről elég hatékonyan menteni. :)

Nálatok nem indiánok üzemeltetnek fényesen?

"there databases" - leülhet, egyes.
másik kedvenc a "would of" és társai.

Azt hiszem, erre mondják itt, hogy sikerült megfogni a lényeget :D

--
trey @ gépház

sőt, "databases where deleted"

Jó, hát biztos trumpli twitteréről tanult angolul...

...és a data is többesszámban nyilvánvaló, hogy "datas"

Szerintem teljesen rendben van
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Grat.

A felhök feloszlanak :)

--
robyboy

Ha valaki onpremise-ből se csinál meg cloudból se csinál offsite backupot akkor az egyesre vizsgázott üzemeltetésből.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Ez igaz, de semmit nem von le a hír értékéböl, ugyanis pont a Cloud lenne Backup leginkább.
Amúgy sem értettem sosem, miért is kellene ismeretlen helyre költöztetni szenzitív adatokat?

--
robyboy

Tán mert nem akarnak szívni saját vassal, se helyben, se szerverteremben, ha meg már lúd, legyen kövér és ne kelljen a szolgáltatás alatti oprendszerrel se bajlódni, csak a szolgáltatás kell.

"Amúgy sem értettem sosem, miért is kellene ismeretlen helyre költöztetni szenzitív adatokat?"

A saját infrát meg kell tervezni, beszerezni, üzemeltetni, bővíteni, hibaelhárítani. Ha nagy ez az infra, embereket kell felvenni csak azért, hogy a vasat simogassák. A felfelé skálázódás drága és lassú, a lefelé skálázódás után meg a kihasználatlan vasban fog állni a pénz. Sehogy se jó.
A cloud infra szerintem egy tök jó dolog, és igen, tartunk benne szenzitív adatokat. Ez is egy olyan kockázat, mint amilyen kockázatok a saját infrában is megvannak. Ha igénytelen, figyelmetlen a saját rendszergazdánk, akkor lehet hogy sokkal nagyobb a kockázat.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

RAID + rendszeres backup + rendszeres szalagos archiválás. Ezek nélkül meg sem fogja közelíteni a saját infrastruktúra biztonsága egy normális felhő adatbiztonságát.

A felhőszolgáltatók sem egyformák. Ha saját infrastruktúrán valaki WD Green merevlemezeket használ mindenféle redundancia nélkül ne lepődjön meg ha megreccsennek az adatai. A Microsoft Azure a sokadik baki után kivívta magának a WD Green szintet adatbiztonságban.
Majd ha rendszeresen lesznek hasonló incidensek Amazonnál és Google-nél is majd akkor lehet általános következtetéseket levonni a felhőkkel kapcsolatban.
De itt a Microsofttal van probléma nem a cloud-dal.

Miért pont szalag? Ha egy másik helyen levő gépre archiválok rendszeresen, akkor az nem jó?

Az nem archiválás.
A szalag "kikapcsolt állapotban" is hosszú ideig megőrzi a rajta levő adatot.
Egy működő gépet feltörhetnek, elrontott frissítéssel, szoftverhiba következtében veszthet adatot.
Még egy szekrénybe elzárt merevlemez sem archiválási megoldás. Nincs rá garancia, hogy x idő múlva felpörög az a merevlemez.
Egyébként ár/GB arány a szalagnál a legalacsonyabb. A kezdeti beszerzési költségek magasak.

Pár havonta (3-6) cserélni a merevlemezt és zárt tűzvédett páncélban felmalmozni, és adott időnél régebbieket szépen forgatni vissza vagy selejtezni. Az aktív hdd-k száma így bármennyi lehet és bármennyire fokozható a megbízhatóság. Nem beszélve a HDD típusának megfelelő megválasztásáról.

Olcsóbban fogsz kijönni egy steamerrel. Nem kell feltétlenül LTO-8.
Merevlemezes archiváláshoz kelleni fog egy GoogleFS képességű fájlrendszer, amin OS szinten lehetetlen törölni fájlokat. Raid1(0) vagy Raid5,6 sem árt hozzá és természetesen csak linuxos softraid vagy ZFS.
A hardveres raid kártyák csak rontanak az adatbiztonságon.

Számomra nem mindig az az olcsó, ami forintosan kevesebbe kerül, hanem aminél több időt tudok spórolni (beszerzésnél, hozzáértésnél, hibánál való csere ideje és lehetősége stb). Oszd vissza 1 hdd árát fél évre órabérre. Szinte nulla.

Ha egyáltalán nem archiválsz akkor az 0 idő, tehát zéró órabér.
De nincs is rá szükség ha nem fontosak az adatok. Csak ne nevezzük archiválásnak ami nem az.
Valószínűleg a Microsoft is lazán kezelte témát, ezért van most baj. Ennél a szolgáltatásnál ez szükséges lett volna. De valóban nem szükséges mindenhol.

Visszajutottunk a kiindulási pontba. A megbízható felhő (Google, Amazon) igényli a legkevesebb órabért. Teljesen automatizálható a felhős mentés. Két párhuzamosan használt felhő nagyobb adatbiztonságot jelent mint a saját infrastruktúra még akkor is ha nincs kispórolva belőle a valódi archiválás.
És nem kell felesleges munkaórákat pazarolni merevlemezek szerelésére.

Igen, a fogalmak mellé mentek. Backup-ra írtam a fentit.

Mondjuk ha a backup ugyanabban a rendszerben tarolodik mint az eles akkor az nem annyira jo megoldas.

+1

Hmm,ezért szeretünk redundánsan menteni magunknak is biztos ami biztos. Mármint legalább a fontos adatokat. Ami nagyon kell az lokál f&P szerveren, és ütemezett mentéssel máshová. A kliens adatok meg OneDrive-ban elvannak. Ha valami gigszer van akkor mi szóltunk hogy csak a szerveres adatokért van felelősségünk. Slussz passz issue solved.

- Az élet, a világmindenség, meg minden (DA) -

"A kliens adatok meg OneDrive-ban elvannak. "

Ez nem túl jó választás, akár ennek a cikknek a fényében is.

Bocsánat, de muszáj voltam valami értelmes módon modellezni a problémát.
Úgy érzem, hogy mivel minden if -et lezártam, ennél nem lehet sokkal bonyolultabb:

if [ $timeOfOutage -lt $slaValueFromContract ]; then
    echo "And the beat goes on! (Scoooooter!)"
else
    if [ $lossOfOutage -lt $penaltyValueFromContract ]; then
        echo "Yes! Free money!"
    else
        echo "The contract is wrong."
        bonusOfFinancialDepartment=$(($defaultBonus-($lossOfOutage-$penaltyValueFromContract)))
    fi
fi

:))

sub

Én azt nem értem, hogy ha magamnak kell megoldanom a tisztességes redundanciát, és backupot, ha azt akarom, hogy _egyetlen tranzakció se vesszen el_, akkor tulajdonképpen mit is nyerek az üzemeltetésen a clouddal? Hogy a legnehezebb feladatot továbbra is magamnak kell megoldanom?

Mi volt egyébként ezeknek az adatbázisoknak az ígérete? Oké, hogy lehet némi downtime, de elvesző adat is lehetséges a szerződés szerint? (Fogalmam sincs, és nem is nézek utána, csak puffogok :-)

> [...] _egyetlen tranzakció se vesszen el_ [...]

Akkor saját hiper-redundáns rendszert építesz, a felhő árához képest irdatlan drágán. Arra adhatsz sokkilences rendelkezésreállást, felelősségvállalással, mindennel.
A felhővel azt nyered hogy nem te üzemelteted a sok vasat, sok datacenterben sok rendszergazdával.

"A felhővel azt nyered hogy nem te üzemelteted a sok vasat, sok datacenterben sok rendszergazdával."

Valamit valamiért effektus.

--
robyboy

Igen, ennek az ellenkezőjét nem is állította senki.

Persze az is igaz, hogy a legtöbb helyen csak addig fontos a sokkilences SLA, amíg nem kell érte sokkilences pénzt kifizetni.

Mennyi is az a "sok 9" mondjuk a Microsoft esetén (nehogy meglepődj, én a múltkor éppen megnéztem)?

--
trey @ gépház

> a felhő árához képest irdatlan drágán

Szerintem ugyanazt mondjátok. :) Lehet 100%-os SLA-t is vállalni (láttam olyan rendszert közelről), de az nem annyiba fog kerülni, mint egy publikus felhőben futtatott VM.

Ez sem feltétlen igaz. A Microsoft Office 365 az elmúlt negyedévekben kb. 3 9-est (99,97, 99,98) tudott felmutatni.

SLA sértés esetén milyen kötbért is fizet? Hidd el, tudunk konkurálni vele. Olyan szerződést mi is tudunk csinálni, hogy 99,7 a szint, de ha nem teljesítünk, akkor egy-két havi díjat elengedünk, egyébként meg STFU.

Azért ha abban gondolkodsz, hogy azon a vason hány virtuális gépet lehet eladni ilyen feltételek mellett...

--
trey @ gépház

> A Microsoft Office 365 az elmúlt negyedévekben kb. 3 9-est (99,97, 99,98) tudott felmutatni.

De öt dollárba kerül fejenként. Ebből ki kell hozni a gépektől kezdve az üzemeltetők bérén keresztül a tárhelyen át a supporting mindent, mindezt levelezésre, file share-re, videoconfra, stb. Szerintem ár-érték arányban rendben van a háromkilences. Ez elvileg havi <45 perc, beleértve a tervezett, off-hours leállásokat.

Ennél lehet _sokkal_ jobb rendelkezésre állást biztosítani, de az nem publikus felhő lesz, és (sejtéseim szerint) nem 5 dollár havonta. Az a kérdés, mire van szükség.

"de az nem publikus felhő lesz"

Szerencsére!

--
trey @ gépház

Ezt nem értem. Miért? Az csak jó, ha van miből választani. Például örülnék, ha lehetne SLA szintek között (értelemszerűen különböző árcédulával) választani. Miért "szerencse", hogy ezt nem lehet?

"akkor tulajdonképpen mit is nyerek az üzemeltetésen a clouddal?"

Leginkább, hogy más bassza el és nem Te. Az nagy előny ha van kire mutogatni :D

Csak nekem van merevedesem attol ha valaki ilyen masszivan lebuntet es megeroszakol egy idegen nyelvet?

homo grammaricus :)
Ha megértetted, amit ír, akkor nem volt annyira rossz.

- Csupán a költői szabadságával élt az író!

De ha ez a magyarázat nem felel meg, akkor ímhol a következő:

- Csak felgyorsította a nyelvtan evolúcióját!

Ha még ez sem felel meg, akkor:

- Igen.

Mervedésem nekem nincs tőle, "agypéniszem" viszont igen. :D (Mondjuk a hupon rendszeresen előforduló nyelvi förmedvényektől is naponta többször kapok rohamot. :( )

- - -
TransferWise

vicces ezt olvasni, főleg úgy hogy sokan körberöhögik azt a fajta "felfogást", vagy IBSZ-t hogy nem tárolunk adatokat cloudban, főleg nem 3rd party cloudban.

Hát.. na.. bizony, nehéz elhinni, de vannak olyan helyek ahol tiltva van az ilyen fajta adattárolás / szerverüzemeltetés / bármiegyéb .... *.gov* ..

Halkan megjegyzem hogy a *.gov*-os peldad invalid.
Legismertebb cafolat: https://aws.amazon.com/govcloud-us/

Egy csomó kormányzati cucc van Office365-ben is, külön garanciákat adnak, mert azért az elég jólfizető vevőkör.

A hiba maga nem valószínű, hogy felhő specifikus, egy jól irányzott paranccsal, elírással, klikkel, nagyon szépen végig lehet on-premisis darálni az adataid. Sokkal inkább a mentés, cloud esetén mondjuk úgy hogy saját hatókörben elérhető, tehát klódfüggetlen, van-e...

Így legalább nem kell külön tökölni a hárombetűsöknek azzal hogy kinél vannak az érzékeny infók :)

:) Egész jól emlékeztem: https://azure.microsoft.com/en-us/global-infrastructure/government/ és https://azure.microsoft.com/en-us/global-infrastructure/regions/

Jól sejtem a Gov-osok külön DC-k.

"Government exclusivity

Only US federal, state, local, and tribal governments and their partners have access to this dedicated instance that only screened US citizens operate."

Szal nem viccelnek, rámentek erősen a kormányzati sztorira kint.

Van nem 3rd party cloud? :D

https://kof.hu/pricing-table

Ez de adja :D Akkor inkább az MS :P

"A Kormányzati Felhő infrastruktúra-szolgáltatást (InfrastucturA as a Service – IaaS) biztosít."

https://kof.hu/technologia

Természetesen jelszóval védett PDF-ben (ki töri fel először?) van az SLA, árak:
https://kof.hu/aszf

Hahó ez a NISZ, mindenen jelszó van :) Szerződj aztán megmondjuk (TM), az NTG-nél én is szívtam vele (ennyi erővel az összes ISP átvehetné ezt a módszert :))

Arról nem beszélve, hogy lé nélkül van insane biztonsági szabályzat amit lével a saját rendszereik se teljesítenek (sql injection is fun in a system that is used by everyone but not by chance). Tényleg nincs egy nyomorult teszter a cégnél (hogy melyiknél jó kérdés , de ha már össze shoppingoltuk a rendszereket a haveroktól oldjuk már meg). Igen tudom van hibajegy foci. De az ember nem akar azon vitatkozni egy biorobottal azon , hogy mi meg mi a nem helyes input. Legalább implementáljunk egy "skip scripted response" gombot.

Törölve

Törölve

Kirakták a dev oldalt publikusra? :D