Odnoklassniki ir lielākais Apache Cassandra lietotājs vietnē RuNet un viens no lielākajiem pasaulē. Mēs sākām izmantot Cassandra 2010. gadā, lai saglabātu fotoattēlu vērtējumus, un tagad Cassandra pārvalda datu petabaitus tūkstošiem mezglu, patiesībā mēs pat izstrādājām paši savu. .
12. septembrī mūsu Sanktpēterburgas birojā rīkosim . Pasākuma galvenais runātājs būs Odnoklassniki galvenais inženieris Oļegs Anastasjevs. Oļegs ir eksperts sadalīto un defektu tolerantu sistēmu jomā, viņš strādā ar Cassandra vairāk nekā 10 gadus un atkārtoti .
Tikšanās priekšvakarā ar Oļegu runājām par sadalīto sistēmu kļūdu toleranci ar Kasandru, jautājām, par ko viņš runās meetupā un kāpēc ir vērts apmeklēt šo pasākumu.
Oļegs savu programmēšanas karjeru sāka tālajā 1995. gadā. Viņš izstrādāja programmatūru banku, telekomunikāciju un transporta jomā. Kopš 2007. gada viņš platformas komandā strādā par vadošo Odnoklassniki izstrādātāju. Viņa pienākumos ietilpst arhitektūru un risinājumu izstrāde lielas slodzes sistēmām, lielām datu noliktavām un portāla veiktspējas un uzticamības problēmu risināšana. Viņš arī apmāca izstrādātājus uzņēmumā.
- Oļeg, sveiks! maijā notika , kas veltīts Apache Cassandra, dalībnieki stāsta, ka diskusijas ritēja līdz vēlai naktij, lūdzu, pastāstiet man, kādi ir jūsu iespaidi par pirmo tikšanos?
Izstrādātāji ar dažādu pieredzi no dažādiem uzņēmumiem ieradās ar savām sāpēm, negaidītiem problēmu risinājumiem un pārsteidzošiem stāstiem. Lielāko daļu tikšanās izdevās novadīt diskusiju formātā, taču diskusiju bija tik daudz, ka varējām pieskarties tikai trešdaļai no plānotajām tēmām. Mēs pievērsām lielu uzmanību tam, kā un ko uzraugām, izmantojot mūsu reālo ražošanas pakalpojumu piemēru.
Man tas interesēja un ļoti patika.
- Spriežot pēc sludinājuma, būs pilnībā veltīts defektu tolerancei, kāpēc izvēlējāties šo tēmu?
Cassandra ir tipiska noslogota izplatīta sistēma ar milzīgu funkcionalitāti, kas ne tikai apkalpo lietotāju pieprasījumus: tenkas, kļūmju noteikšana, shēmas izmaiņu izplatīšana, klasteru paplašināšana/samazināšana, antientropija, dublēšana un atkopšana utt. Tāpat kā jebkurā dalītā sistēmā, palielinoties aparatūras daudzumam, palielinās atteices iespējamība, tāpēc Cassandra ražošanas klasteru darbībai ir nepieciešama dziļa izpratne par to struktūru, lai prognozētu uzvedību kļūmju un operatora darbību gadījumā. Pēc Cassandra lietošanas daudzus gadus mēs , ar kuru esam gatavi dalīties, kā arī vēlamies pārrunāt, kā kolēģi veikalā risina tipiskas problēmas.
— Runājot par Kasandru, ko jūs domājat ar kļūdu toleranci?
Pirmkārt, protams, sistēmas spēja pārdzīvot tipiskas aparatūras kļūmes: mašīnu, disku vai tīkla savienojamības zudumu ar mezgliem/datu centriem. Taču tēma pati par sevi ir daudz plašāka un jo īpaši ietver atveseļošanos no neveiksmēm, tostarp kļūmēm, kurām cilvēki reti ir gatavi, piemēram, operatora kļūdas.
— Vai varat minēt visvairāk ielādētā un lielākā datu klastera piemēru?
Viena no mūsu lielākajām kopām ir dāvanu kopa: vairāk nekā 200 mezglu un simtiem TB datu. Bet tas nav visvairāk ielādēts, jo to sedz izplatīta kešatmiņa. Mūsu noslogotākās kopas apstrādā desmitiem tūkstošu IPS rakstīšanai un tūkstošiem IPS lasīšanai.
- Oho! Cik bieži kaut kas saplīst?
! Kopumā mums ir vairāk nekā 6 tūkstoši serveru, un katru nedēļu tiek nomainīti pāris serveri un vairāki desmiti disku (neņemot vērā paralēlos mašīnparka jaunināšanas un paplašināšanas procesus). Katram kļūmes veidam ir skaidri norādījumi, kā un kādā secībā rīkoties, kad vien iespējams, viss tiek automatizēts, tāpēc kļūmes ir ikdienišķas un 99% gadījumu notiek lietotājiem nepamanītas.
— Kā tiekat galā ar šādiem atteikumiem?
Kopš Cassandra darbības sākuma un pirmajiem incidentiem mēs strādājām pie dublēšanas un atkopšanas no tiem mehānismiem, veidojām izvietošanas procedūras, kas ņem vērā Cassandra klasteru stāvokli un, piemēram, neļauj restartēt mezglus. ja ir iespējams datu zudums. Par to visu plānojam runāt tikšanās reizē.
— Kā jūs teicāt, absolūti uzticamu sistēmu nav. Kāda veida neveiksmēm jūs gatavojaties un spējat tikt galā?
Ja mēs runājam par mūsu Cassandra klasteru instalācijām, lietotāji neko nepamanīs, ja mēs pazaudēsim vairākas mašīnas vienā DC vai vienu visu DC (tas ir noticis). Pieaugot DC skaitam, tiek domāts par darbības uzsākšanu divu DC atteices gadījumā.
— Kas, jūsuprāt, Kasandrai trūkst kļūdu tolerances ziņā?
Cassandra, tāpat kā daudzi citi agrīnie NoSQL veikali, prasa dziļu izpratni par tās iekšējo struktūru un notiekošajiem dinamiskajiem procesiem. Es teiktu, ka tajā trūkst vienkāršības, paredzamības un novērojamības. Bet būs interesanti dzirdēt arī citu tikšanās dalībnieku viedokļus!
Oļeg, liels paldies, ka atradāt laiku, lai atbildētu uz jautājumiem!
Gaidām visus, kas vēlas komunicēt ar Apache Cassandra darbības jomas ekspertiem uz meetup 12. septembrī mūsu Sanktpēterburgas birojā.
Nāc, būs interesanti!
Avots: www.habr.com