Odnoklassniki is die grootste gebruiker van Apache Cassandra op die RuNet en een van die grootstes ter wêreld. Ons het Cassandra in 2010 begin gebruik om fotograderings te stoor, en nou bestuur Cassandra petagrepe data op duisende nodusse, om die waarheid te sê, ons het selfs ons eie ontwikkel .
Op 12 September in ons St Petersburg kantoor hou ons . Die hoofspreker van die geleentheid sal die hoofingenieur van Odnoklassniki Oleg Anastasyev wees. Oleg is 'n kenner op die gebied van verspreide en foutverdraagsame stelsels; hy werk al meer as 10 jaar en herhaaldelik met Cassandra .
Op die vooraand van die ontmoeting het ons met Oleg gepraat oor die fouttoleransie van verspreide stelsels met Cassandra, gevra waaroor hy by die ontmoeting sou praat en hoekom dit die moeite werd was om hierdie geleentheid by te woon.
Oleg het sy programmeringsloopbaan in 1995 begin. Hy het sagteware in bankwese, telekommunikasie en vervoer ontwikkel. Hy werk sedert 2007 as 'n toonaangewende ontwikkelaar by Odnoklassniki op die platformspan. Sy verantwoordelikhede sluit in die ontwikkeling van argitekture en oplossings vir hoëladingstelsels, groot datapakhuise en die oplossing van probleme van portaalwerkverrigting en betroubaarheid. Hy lei ook ontwikkelaars binne die maatskappy op.
- Oleg, hallo! In Mei plaasgevind , opgedra aan Apache Cassandra, die deelnemers sê dat besprekings tot laat in die nag voortgeduur het, vertel my asseblief, wat is jou indrukke van die eerste ontmoeting?
Ontwikkelaars met verskillende agtergronde van verskillende maatskappye het met hul eie pyn, onverwagte oplossings vir probleme en wonderlike stories gekom. Ons het daarin geslaag om die meeste van die ontmoeting in 'n besprekingsformaat te hou, maar daar was soveel besprekings dat ons net 'n derde van die beplande onderwerpe kon aanraak. Ons het baie aandag gegee aan hoe en wat ons monitor deur die voorbeeld van ons regte produksiedienste te gebruik.
Ek was geïnteresseerd en het baie daarvan gehou.
- Te oordeel aan die aankondiging, sal geheel en al gewy word aan foutverdraagsaamheid, hoekom het jy hierdie onderwerp gekies?
Cassandra is 'n tipiese besige verspreide stelsel met 'n groot hoeveelheid funksionaliteit buiten die direkte diens van gebruikersversoeke: skinder, foutopsporing, verspreiding van skemaveranderings, groepuitbreiding/-vermindering, anti-entropie, rugsteun en herstel, ens. Soos in enige verspreide stelsel, namate die hoeveelheid hardeware toeneem, neem die waarskynlikheid van mislukkings toe, dus vereis die werking van Cassandra-produksieklusters 'n diepgaande begrip van sy struktuur om gedrag te voorspel in geval van mislukkings en operateursaksies. Nadat ons Cassandra vir baie jare gebruik het, het ons , wat ons gereed is om te deel, en ons wil ook bespreek hoe kollegas in die winkel tipiese probleme oplos.
— As dit by Cassandra kom, wat bedoel jy met foutverdraagsaamheid?
Eerstens, natuurlik, die stelsel se vermoë om tipiese hardeware-foute te oorleef: verlies van masjiene, skywe of netwerkverbinding met nodusse/datasentrums. Maar die onderwerp self is baie wyer en sluit veral herstel van mislukkings in, insluitend mislukkings waarop mense selde voorbereid is, byvoorbeeld operateurfoute.
— Kan jy 'n voorbeeld gee van die mees gelaaide en grootste datagroepering?
Een van ons grootste groepe is die geskenkgroepering: meer as 200 nodusse en honderde TB se data. Maar dit is nie die meeste gelaai nie, aangesien dit deur 'n verspreide kas gedek word. Ons besigste groepe hanteer tienduisende RPS vir skryf en duisende RPS vir lees.
- Sjoe! Hoe dikwels breek iets?
! In totaal het ons meer as 6 duisend bedieners, en elke week word 'n paar bedieners en 'n paar dosyn skywe vervang (sonder om die parallelle prosesse van opgradering en uitbreiding van die masjienvloot in ag te neem). Vir elke tipe mislukking is daar duidelike instruksies oor wat om te doen en in watter volgorde, alles word geoutomatiseer waar moontlik, so mislukkings is roetine en kom in 99% van gevalle ongemerk deur gebruikers voor.
— Hoe hanteer jy sulke weiering?
Van die begin van die werking van Cassandra en die eerste voorvalle het ons aan die meganismes vir rugsteun en herstel daarvan gewerk, ontplooiingsprosedures gebou wat die toestand van Cassandra-klusters in ag neem en byvoorbeeld nie toelaat dat nodusse herbegin word nie as dataverlies moontlik is. Ons beplan om oor dit alles by die ontmoeting te praat.
— Soos jy gesê het, is daar geen absoluut betroubare stelsels nie. Op watter tipe mislukkings berei jy jou voor en is jy in staat om te oorleef?
As ons praat oor ons installasies van Cassandra-klusters, sal gebruikers niks opmerk as ons verskeie masjiene in een DC of een hele DC verloor nie (dit het gebeur). Met die toename in die aantal GS'e, dink ons daaraan om te begin om bedryfbaarheid te verseker in die geval van 'n mislukking van twee GS'e.
— Wat dink jy kort Cassandra in terme van foutverdraagsaamheid?
Cassandra, soos baie ander vroeë NoSQL-winkels, vereis 'n diepgaande begrip van sy interne struktuur en die dinamiese prosesse wat plaasvind. Ek sou sê dit kort eenvoud, voorspelbaarheid en waarneembaarheid. Maar dit sal interessant wees om die menings van ander vergaderingdeelnemers te hoor!
Oleg, baie dankie dat jy die tyd geneem het om die vrae te beantwoord!
Ons wag vir almal wat met kundiges op die gebied van die bedryf van Apache Cassandra wil kommunikeer by die ontmoeting op 12 September in ons St. Petersburg-kantoor.
Kom, dit sal interessant wees!
Bron: will.com