Ang Odnoklassniki ay ang pinakamalaking user ng Apache Cassandra sa RuNet at isa sa pinakamalaki sa mundo. Sinimulan naming gamitin si Cassandra noong 2010 upang mag-imbak ng mga rating ng larawan, at ngayon ay namamahala si Cassandra ng mga petabyte ng data sa libu-libong mga node, sa katunayan, gumawa pa kami ng sarili naming .
Sa Setyembre 12 sa aming opisina sa St. Petersburg kami ay gaganapin . Ang pangunahing tagapagsalita ng kaganapan ay ang punong inhinyero ng Odnoklassniki Oleg Anastasyev. Si Oleg ay isang dalubhasa sa larangan ng mga distributed at fault-tolerant system; siya ay nagtatrabaho kasama si Cassandra nang higit sa 10 taon at paulit-ulit .
Sa bisperas ng meetup, nakipag-usap kami kay Oleg tungkol sa fault tolerance ng mga distributed system kay Cassandra, tinanong kung ano ang sasabihin niya sa meetup at kung bakit sulit na dumalo sa kaganapang ito.
Sinimulan ni Oleg ang kanyang karera sa programming noong 1995. Gumawa siya ng software sa pagbabangko, telecom, at transportasyon. Siya ay nagtatrabaho bilang isang nangungunang developer sa Odnoklassniki mula noong 2007 sa platform team. Kasama sa kanyang mga responsibilidad ang pagbuo ng mga arkitektura at solusyon para sa mga high-load system, malalaking data warehouse, at paglutas ng mga problema sa pagganap at pagiging maaasahan ng portal. Nagsasanay din siya ng mga developer sa loob ng kumpanya.
- Oleg, kumusta! Noong Mayo naganap , na nakatuon kay Apache Cassandra, sinabi ng mga kalahok na nagpatuloy ang mga talakayan hanggang hating-gabi, mangyaring sabihin sa akin, ano ang iyong mga impression sa unang pagkikita?
Ang mga developer na may iba't ibang background mula sa iba't ibang kumpanya ay dumating na may sariling sakit, hindi inaasahang solusyon sa mga problema at kamangha-manghang mga kuwento. Nagawa naming isagawa ang karamihan sa meetup sa isang format ng talakayan, ngunit napakaraming mga talakayan kung kaya't sa ikatlong bahagi lamang ng mga nakaplanong paksa ang aming nagawa. Nagbigay kami ng maraming pansin sa kung paano at kung ano ang aming sinusubaybayan gamit ang halimbawa ng aming mga tunay na serbisyo sa produksyon.
Ako ay interesado at talagang nagustuhan ito.
- Sa paghusga sa pamamagitan ng anunsyo, ay ganap na nakatuon sa fault tolerance, bakit mo pinili ang paksang ito?
Ang Cassandra ay isang tipikal na abalang ipinamamahaging system na may malaking halaga ng functionality na higit pa sa direktang pagseserbisyo sa mga kahilingan ng user: tsismis, pag-detect ng pagkabigo, pagpapalaganap ng mga pagbabago sa schema, pagpapalawak/pagbawas ng cluster, anti-entropy, pag-backup at pagbawi, atbp. Tulad ng sa anumang distributed system, habang tumataas ang dami ng hardware, tumataas ang posibilidad ng mga pagkabigo, kaya ang pagpapatakbo ng mga cluster ng produksyon ng Cassandra ay nangangailangan ng malalim na pag-unawa sa istraktura nito upang mahulaan ang pag-uugali sa kaso ng mga pagkabigo at pagkilos ng operator. Matapos gamitin si Cassandra sa loob ng maraming taon, kami , na handa naming ibahagi, at gusto rin naming talakayin kung paano nireresolba ng mga kasamahan sa shop ang mga karaniwang problema.
β Pagdating kay Cassandra, ano ang ibig mong sabihin ng fault tolerance?
Una sa lahat, siyempre, ang kakayahan ng system na makaligtas sa karaniwang mga pagkabigo sa hardware: pagkawala ng mga makina, disk, o koneksyon sa network na may mga node/data center. Ngunit ang paksa mismo ay mas malawak at partikular na kasama ang pagbawi mula sa mga pagkabigo, kabilang ang mga pagkabigo kung saan ang mga tao ay bihirang handa, halimbawa, mga error sa operator.
β Maaari ka bang magbigay ng halimbawa ng pinaka-load at pinakamalaking kumpol ng data?
Ang isa sa aming pinakamalaking cluster ay ang gift cluster: higit sa 200 node at daan-daang TB ng data. Ngunit hindi ito ang pinaka-load, dahil sakop ito ng isang ipinamahagi na cache. Ang aming mga pinaka-abalang cluster ay humahawak ng libu-libong RPS para sa pagsusulat at libu-libong RPS para sa pagbabasa.
- Wow! Gaano kadalas masira ang isang bagay?
! Sa kabuuan, mayroon kaming higit sa 6 na libong mga server, at bawat linggo ng isang pares ng mga server at ilang dosenang mga disk ay pinalitan (nang hindi isinasaalang-alang ang mga parallel na proseso ng pag-upgrade at pagpapalawak ng fleet ng makina). Para sa bawat uri ng pagkabigo, may malinaw na mga tagubilin sa kung ano ang gagawin at sa anong pagkakasunud-sunod, ang lahat ay awtomatiko hangga't maaari, kaya ang mga pagkabigo ay nakagawian at sa 99% ng mga kaso ay nangyayari nang hindi napapansin ng mga gumagamit.
β Paano mo haharapin ang gayong mga pagtanggi?
Sa simula pa lang ng operasyon ng Cassandra at sa mga unang insidente, nagtrabaho kami sa mga mekanismo para sa pag-backup at pagbawi mula sa kanila, nagtayo ng mga pamamaraan sa pag-deploy na isinasaalang-alang ang estado ng mga kumpol ng Cassandra at, halimbawa, hindi pinapayagan ang mga node na ma-restart. kung posible ang pagkawala ng data. Plano naming pag-usapan ang lahat ng ito sa meetup.
β Gaya ng sinabi mo, walang ganap na maaasahang mga sistema. Anong mga uri ng mga kabiguan ang iyong pinaghahandaan at kayang hawakan?
Kung pag-uusapan natin ang tungkol sa aming mga pag-install ng mga kumpol ng Cassandra, walang mapapansin ang mga user kung mawawalan kami ng ilang makina sa isang DC o isang buong DC (nangyari na ito). Sa pagtaas ng bilang ng mga DC, iniisip namin ang tungkol sa pagsisimula upang matiyak ang kakayahang magamit kung sakaling mabigo ang dalawang DC.
β Ano sa palagay mo ang kulang ni Cassandra sa mga tuntunin ng pagpapahintulot sa kasalanan?
Ang Cassandra, tulad ng maraming iba pang maagang mga tindahan ng NoSQL, ay nangangailangan ng malalim na pag-unawa sa panloob na istraktura nito at ang mga dinamikong prosesong nagaganap. Masasabi ko na kulang ito sa pagiging simple, predictability at observability. Ngunit magiging kawili-wiling marinig ang mga opinyon ng iba pang mga kalahok sa pagpupulong!
Oleg, maraming salamat sa paglalaan ng oras upang sagutin ang mga tanong!
Hinihintay namin ang lahat ng gustong makipag-ugnayan sa mga eksperto sa larangan ng pagpapatakbo ng Apache Cassandra sa meetup noong Setyembre 12 sa aming tanggapan sa St. Petersburg.
Halika, ito ay magiging kawili-wili!
Pinagmulan: www.habr.com