Odnoklassniki RuNet-də Apache Cassandra-nın ən böyük istifadəçisi və dünyanın ən böyük istifadəçilərindən biridir. Biz 2010-cu ildə fotoşəkil reytinqlərini saxlamaq üçün Cassandra-dan istifadə etməyə başladıq və indi Cassandra minlərlə qovşaqda petabaytlarla məlumat idarə edir, əslində biz hətta özümüzü də inkişaf etdirdik. .
Sentyabrın 12-də Sankt-Peterburq ofisimizdə keçirəcəyik . Tədbirin əsas məruzəçisi Odnoklassniki-nin baş mühəndisi Oleq Anastasyev olacaq. Oleq paylanmış və nasazlığa dözümlü sistemlər sahəsində mütəxəssisdir, o, 10 ildən artıqdır ki, Cassandra ilə işləyir və dəfələrlə .
Görüş ərəfəsində biz Oleqlə Kassandra ilə paylanmış sistemlərin nasazlıqlara qarşı dözümlülüyü barədə danışdıq, görüşdə nə danışacağını və niyə bu tədbirdə iştirak etməyə dəyər olduğunu soruşduq.
Oleq proqramlaşdırma karyerasına hələ 1995-ci ildə başlayıb. O, bank, telekommunikasiya və nəqliyyat sahələrində proqram təminatı hazırlayıb. O, 2007-ci ildən Odnoklassniki-də platforma komandasında aparıcı developer kimi çalışır. Onun vəzifələrinə yüksək yüklü sistemlər, böyük məlumat anbarları üçün arxitektura və həllərin işlənib hazırlanması, portalın performansı və etibarlılığı problemlərinin həlli daxildir. O, həmçinin şirkət daxilində tərtibatçıları öyrədir.
- Oleq, salam! May ayında baş verdi , Apache Cassandra-ya həsr olunmuş, iştirakçılar deyirlər ki, müzakirələr gecə saatlarına qədər davam edib, zəhmət olmasa deyin, ilk görüşlə bağlı təəssüratlarınız necədir?
Fərqli şirkətlərdən fərqli mənşəli tərtibatçılar öz ağrıları, problemlərə gözlənilməz həllər və heyrətamiz hekayələri ilə gəldilər. Görüşün çox hissəsini müzakirə formatında keçirə bildik, lakin o qədər müzakirələr oldu ki, planlaşdırılan mövzuların yalnız üçdə birinə toxuna bildik. Biz real istehsal xidmətlərimizdən nümunə götürərək necə və nəyə nəzarət etdiyimizə çox diqqət yetirdik.
Maraqlandım və çox xoşuma gəldi.
- Elana əsasən, tamamilə səhvlərə dözümlülüyünə həsr olunacaq, niyə bu mövzunu seçdiniz?
Cassandra, istifadəçi istəklərinə birbaşa xidmət göstərməkdən əlavə, böyük həcmdə funksionallığı olan tipik məşğul paylanmış sistemdir: dedi-qodu, nasazlıqların aşkarlanması, sxem dəyişikliklərinin yayılması, klasterin genişləndirilməsi/azaldılması, antientropiya, ehtiyat nüsxələr və bərpa və s. Hər hansı bir paylanmış sistemdə olduğu kimi, avadanlıqların miqdarı artdıqca, nasazlıqların baş vermə ehtimalı artır, buna görə də Cassandra istehsal klasterlərinin işləməsi uğursuzluqlar və operator hərəkətləri zamanı davranışı proqnozlaşdırmaq üçün onun strukturunu dərindən başa düşməyi tələb edir. Uzun illər Cassandra istifadə etdikdən sonra biz , paylaşmağa hazırıq və biz də mağazadakı həmkarların tipik problemləri necə həll etdiyini müzakirə etmək istəyirik.
— Söhbət Kassandradan gedirsə, günaha dözümlülük dedikdə nəyi nəzərdə tutursunuz?
Hər şeydən əvvəl, əlbəttə ki, sistemin tipik hardware nasazlıqlarından sağ çıxmaq qabiliyyəti: maşınların, disklərin və ya qovşaqlar/məlumat mərkəzləri ilə şəbəkə bağlantısının itirilməsi. Ancaq mövzunun özü daha genişdir və xüsusən də uğursuzluqların bərpasını, o cümlədən insanların nadir hallarda hazır olduqları uğursuzluqları, məsələn, operator səhvlərini əhatə edir.
— Ən çox yüklənmiş və ən böyük məlumat klasterinə misal verə bilərsinizmi?
Ən böyük klasterlərimizdən biri hədiyyə klasteridir: 200-dən çox qovşaq və yüzlərlə TB məlumat. Ancaq paylanmış bir önbellek ilə əhatə olunduğu üçün ən çox yüklənmiş deyil. Ən işlək klasterlərimiz yazı üçün on minlərlə RPS və oxumaq üçün minlərlə RPS idarə edir.
- Heyrət! Vay! Bir şey nə qədər tez-tez pozulur?
! Ümumilikdə 6 mindən çox serverimiz var və hər həftə bir neçə server və bir neçə onlarla disk dəyişdirilir (maşın parkının yenilənməsi və genişləndirilməsinin paralel prosesləri nəzərə alınmadan). Hər bir uğursuzluq növü üçün nə etmək və hansı qaydada etmək barədə aydın təlimatlar var, mümkün olduqda hər şey avtomatlaşdırılır, buna görə də uğursuzluqlar müntəzəmdir və 99% hallarda istifadəçilər tərəfindən nəzərə alınmadan baş verir.
- Bu cür imtinalarla necə davranırsınız?
Cassandra-nın istismarının əvvəlindən və ilk insidentlərdən biz ehtiyat nüsxələrin çıxarılması və onlardan bərpa mexanizmləri üzərində işləmişik, Cassandra klasterlərinin vəziyyətini nəzərə alan və məsələn, qovşaqların yenidən işə salınmasına imkan verməyən yerləşdirmə prosedurlarını qurmuşuq. məlumat itkisi mümkündürsə. Bütün bunları görüşdə danışmağı planlaşdırırıq.
— Dediyiniz kimi, tamamilə etibarlı sistemlər yoxdur. Hansı uğursuzluqlara hazırlaşırsan və öhdəsindən gələ bilirsən?
Cassandra klasterlərinin quraşdırılması haqqında danışsaq, bir DC və ya bir DC-də bir neçə maşını itirsək, istifadəçilər heç nə hiss etməyəcəklər (bu baş verdi). DC-lərin sayının artması ilə iki DC-nin sıradan çıxması halında işləmə qabiliyyətini təmin etməyə başlamağı düşünürük.
— Sizcə, Kassandranın qüsurlara dözümlülük baxımından nələri çatışmır?
Cassandra, bir çox digər erkən NoSQL mağazalar kimi, onun daxili strukturunu və baş verən dinamik prosesləri dərindən başa düşməyi tələb edir. Deyərdim ki, sadəlik, proqnozlaşdırıla bilənlik və müşahidə oluna bilənlik yoxdur. Ancaq digər görüş iştirakçılarının fikirlərini eşitmək maraqlı olacaq!
Oleq, sualları cavablandırmaq üçün vaxt ayırdığınız üçün çox sağ olun!
Sentyabrın 12-də Sankt-Peterburq ofisimizdə keçiriləcək görüşdə Apache Cassandra əməliyyatı sahəsində ekspertlərlə ünsiyyət qurmaq istəyən hər kəsi gözləyirik.
Buyurun, maraqlı olacaq!
Mənbə: www.habr.com