"Ok, ha eddig sem volt úgy mentve-archiválva, akkor tényleg kérdéses, hogy miért most kezdtek el ragaszkodni hozzá."
Eddig host szinten volt mentés és archiválás minden érintett gépről, amelyiken átment az adat; minden host virtualizálva volt, hogy hardverhiba vagy egyéb esetben könnyen át lehessen mozgatni másik fizikai vasra. Ez volt a HA alapja.
Egy Cassandra node-ot viszont nem mentünk és nem archiválunk host szinten (mert replikálja magát a datacenter-rack-node koordináta rendszerben), általánosságban nem virtualizáljuk, mert érdemes egy egész fizikai gépet adni egy node-nak (dedikált lokális memória, SSD, SATA erőforrásokkal), nem mozgatjuk fizikai gépek között (mert hiba esetén nem lesz jó a datacenter-rack-node koordináta rendszerben a quorum és a replikáció).
http://www.datastax.com/documentation/cassandra/2.0/cassandra/architect…
"Ugyanakkor az, hogy a törlés/felülírás költséges művelet, még nem jelenti azt, hogy egy tetszőleges szoftverhiba miatt nem eshet szét az egész. Főleg az tud problémás lenni, ha leáll a replikálás, esetleg valami split brain állapot áll be és utána nem tud visszaszinkronizálni. Ezekre ráadásul nagyon nehéz tesztet csinálni."
Ha leszakad egy datacenter, akkor is csak annyi van, hogy mindenki írja a naplót a saját környezetében, amikor meg helyreáll a kapcsolat, akkor összefésülik az adatokat a node-ok (replikált idősoros timeuuid kulcsok!). Addig meg a lekérdezések esetleg hiányosak lesznek, nem nagy dolog... amikor az MQ-DB2 bedolgozás állt meg valami adatbázis túlterhelés vagy hiba miatt, akkor fél napig nem volt friss adat, nem lényeges... olyan is volt, hogy az MQ állt meg, akkor egyáltalán nem volt adat addig... :)
"Nyilván, ha garantáltan sosem törölsz/update-elsz akkor van esély rá, hogy megoldható utólag az adatok összefésülése, de nem kívánom senkinek, hogy ilyennel kelljen szopnia. 50TB adaton egy próbálkozás is napokat vehet igénybe és utána ellenőrizni sem egyszerű, hogy tényleg minden a helyére került."
Faék egyszerűségű a Cassandra adatstruktúrája és a működésmódja... ehhez képest egy DB2 vagy MQ circular transaction log betelés vagy egy linear transaction log tárhely elfogyás utáni helyreállítás az igazi művészet... :)
"Üzemeltetői oldalról sem vagyok benne biztos, hogy "visszalépés" egy ilyen rendszer működtetése. De mindenképpen kilóg az eddig bevezetett rendszerből, és ezt valóban nem szokták jó szemmel nézni."
Hát... amikor a kocsmában kérdezik az IT-s haverok, hogy mivel is foglalkozol, akkor jobb azt mondani, hogy VMWare ESX-el oldjuk meg a magas rendelkezésre állást vagy EMC high-end storage-t adminisztrálunk és több száz TB adatot mozgatunk, vagy DB2 adatbázis üzemeltetünk, vagy IBM MQ cluster-t konfigurálunk, amin naponta több tíz millió adat megy át... van miről mesélni, vannak sztorik, vannak heroikus küzdelmek...
...a másik munka meg az, hogy hiba esetén kivesszük a gépet a rack-ből, fogunk egy másikat, felmásolunk rá egy image-t és betesszük a régi helyére, a többihez meg nem nyúlunk... :)
"Sokminden múlik azon is, hogy ki fúrta meg. Valami manager, mindenféle ITIL-es processekre hivatkozva, vagy a drága játékszerekkel foglalkozó egyszeri operátor."
Az elsőhöz rengeteg tudás, vizsga, tapasztalat és ismeret kell, amit megfizetnek... a másodikhoz elég egy technikus, tehát nyilván FTE vonzata is van egy ilyen átállásnak... és bizony benne van, hogy ha ilyen módon megtakarít a cég mondjuk 250 millió forint OPEX-et a hardveren és a licenceken évente, akkor ezt azért nem vállalják be, mert akkor "Józsit" is ki kellene rúgni, mert megszűnik a munkahelye.
Technológiailag a megoldás alkalmazható lett volna... ahogy rengeteg példa van arra, ahol Cassandra van rendszeresítve idősoros adatok tárolására... :)