Az Odnoklassniki az Apache Cassandra legnagyobb felhasználója a RuNeten, és az egyik legnagyobb a világon. 2010-ben kezdtük el használni a Cassandra-t fotóértékelések tárolására, és mostanra a Cassandra petabájtnyi adatot kezel több ezer csomóponton, sőt, még a sajátunkat is kifejlesztettük. .
Szeptember 12-én szentpétervári irodánkban tartjuk . A rendezvény főelőadója az Odnoklassniki főmérnöke, Oleg Anastasyev lesz. Oleg az elosztott és hibatűrő rendszerek szakértője, több mint 10 éve dolgozik a Cassandrával és többször is. .
A meetup előestéjén Oleggel az elosztott rendszerek hibatűréséről beszélgettünk Cassandra-val, megkérdeztük, miről fog beszélni a meetupon, és miért érdemes ezen az eseményen részt venni.
Oleg 1995-ben kezdte programozói pályafutását. Szoftvert fejlesztett a banki, távközlési és közlekedési területen. 2007 óta az Odnoklassniki vezető fejlesztőjeként dolgozik a platform csapatában. Feladatai közé tartozik architektúrák és megoldások fejlesztése nagy terhelésű rendszerek, nagy adattárházak számára, valamint a portál teljesítményével és megbízhatóságával kapcsolatos problémák megoldása. A cégen belül fejlesztőket is képez.
- Oleg, szia! Májusban került sor Az apacs Cassandra-nak szentelt témában a résztvevők elmondása szerint késő estig tartottak a megbeszélések. Kérem, mondja el, milyen benyomásai vannak az első találkozásról?
A különböző hátterű fejlesztők különböző cégektől saját fájdalmaikkal, váratlan problémák megoldásával és elképesztő történetekkel érkeztek. A meetup nagy részét sikerült vitaformában lebonyolítani, de annyi megbeszélés volt, hogy a tervezett témáknak csak egyharmadát tudtuk érinteni. Nagy figyelmet fordítottunk arra, hogy valódi termelési szolgáltatásaink példáján keresztül hogyan és mit figyelünk.
Érdekelt és nagyon tetszett.
- A közleményből ítélve teljes mértékben a hibatűrésnek lesz szentelve, miért ezt a témát választotta?
A Cassandra egy tipikus elfoglalt elosztott rendszer, hatalmas mennyiségű funkcióval a felhasználói kérések közvetlen kiszolgálásán túl: pletykák, hibaészlelés, sémamódosítások terjesztése, fürtbővítés/csökkentés, entrópia elleni védekezés, biztonsági mentések és helyreállítás stb. Mint minden elosztott rendszerben, a hardver mennyiségének növekedésével a meghibásodások valószínűsége is nő, így a Cassandra termelési klaszterek működése megköveteli a szerkezetének mély megértését, hogy előre jelezze a viselkedést meghibásodások és kezelői intézkedések esetén. A Cassandra hosszú évek óta tartó használata után mi , amit készen állunk megosztani, és azt is szeretnénk megvitatni, hogy az üzletben a kollégák hogyan oldják meg a tipikus problémákat.
— Ha Cassandráról van szó, mit értesz hibatűrés alatt?
Mindenekelőtt természetesen a rendszer azon képessége, hogy túlélje a tipikus hardverhibákat: gépek, lemezek elvesztése vagy hálózati kapcsolat a csomópontokkal/adatközpontokkal. Maga a téma azonban sokkal tágabb, és különösen magában foglalja a hibák utáni helyreállítást, beleértve azokat a hibákat is, amelyekre az emberek ritkán vannak felkészülve, például a kezelői hibákat.
— Tudna példát mondani a legtöbbet terhelt és legnagyobb adatfürtre?
Az egyik legnagyobb klaszterünk az ajándék fürt: több mint 200 csomópont és több száz TB adat. De nem ez a legterheltebb, mivel egy elosztott gyorsítótár fedi le. Legforgalmasabb fürtjeink több tízezer RPS-t kezelnek az íráshoz és több ezer RPS-t az olvasáshoz.
- Azta! Milyen gyakran törik el valami?
! Összességében több mint 6 ezer szerverünk van, és hetente pár szervert és több tucat lemezt cserélünk (anélkül, hogy figyelembe vennénk a géppark párhuzamos frissítési és bővítési folyamatait). Minden hibatípushoz egyértelmű utasítások vannak, hogy mit és milyen sorrendben kell tenni, lehetőség szerint minden automatizált, így a hibák rutinszerűek, és az esetek 99%-ában észrevétlenül fordulnak elő a felhasználók számára.
– Hogyan kezeli az ilyen visszautasításokat?
A Cassandra működésének kezdetétől és az első incidensektől kezdve dolgoztunk a biztonsági mentések és az azokból való helyreállítás mechanizmusain, olyan telepítési eljárásokat építettünk, amelyek figyelembe veszik a Cassandra-fürtök állapotát, és például nem teszik lehetővé a csomópontok újraindítását. ha adatvesztés lehetséges. Terveink szerint a találkozón mindezt megbeszéljük.
– Mint mondta, nincsenek teljesen megbízható rendszerek. Milyen típusú kudarcokra készülsz fel, és milyen kudarcokra vagy képes túlélni?
Ha a Cassandra-fürtök telepítéséről beszélünk, a felhasználók semmit sem fognak észrevenni, ha több gépet veszítünk el egy DC-ben vagy egy teljes DC-ben (ez megtörtént). A DC-k számának növekedésével azon gondolkozunk, hogy megkezdjük a működőképesség biztosítását két DC meghibásodása esetén.
– Ön szerint mi hiányzik Cassandrának a hibatűrésből?
A Cassandra, mint sok más korai NoSQL áruház, megköveteli a belső szerkezetének és a dinamikus folyamatoknak a mély megértését. Azt mondanám, hogy hiányzik belőle az egyszerűség, a kiszámíthatóság és a megfigyelhetőség. De érdekes lesz hallani a találkozó többi résztvevőjének véleményét is!
Oleg, nagyon köszönöm, hogy időt szánt a kérdések megválaszolására!
Várunk mindenkit, aki szeretne kommunikálni az Apache Cassandra üzemeltetésének szakértőivel a szeptember 12-i meetupra szentpétervári irodánkban.
Gyertek, érdekes lesz!
Forrás: will.com