Odnoklassniki jest największym użytkownikiem Apache Cassandra w RuNet i jednym z największych na świecie. Zaczęliśmy używać Cassandry w 2010 roku do przechowywania ocen zdjęć, a teraz Cassandra zarządza petabajtami danych w tysiącach węzłów, a nawet opracowaliśmy własne .
12 września w naszym biurze w Petersburgu odbędzie się . Głównym mówcą wydarzenia będzie główny inżynier Odnoklassniki Oleg Anastasiew. Oleg jest ekspertem w dziedzinie systemów rozproszonych i odpornych na błędy, z Cassandrą współpracuje od ponad 10 lat i wielokrotnie .
W przeddzień spotkania rozmawialiśmy z Olegiem o odporności na awarie systemów rozproszonych z Cassandrą, pytaliśmy, o czym będzie mówił na spotkaniu i dlaczego warto wziąć udział w tym wydarzeniu.
Oleg rozpoczął karierę programisty w 1995 roku. Tworzył oprogramowanie dla bankowości, telekomunikacji i transportu. Od 2007 roku pracuje jako wiodący programista w Odnoklassnikach w zespole platformowym. Do jego obowiązków należy opracowywanie architektur i rozwiązań dla systemów o dużym obciążeniu, dużych hurtowni danych oraz rozwiązywanie problemów związanych z wydajnością i niezawodnością portalu. Szkoli także programistów wewnątrz firmy.
- Olegu, cześć! W maju miało miejsce , dedykowanego Apache Cassandrze, uczestnicy mówią, że dyskusje trwały do późnych godzin nocnych, proszę powiedzieć, jakie są Wasze wrażenia z pierwszego spotkania?
Programiści o różnym pochodzeniu z różnych firm przyszli z własnym bólem, nieoczekiwanymi rozwiązaniami problemów i niesamowitymi historiami. Większość spotkania udało nam się przeprowadzić w formie dyskusyjnej, jednak dyskusji było tak dużo, że udało nam się poruszyć jedynie jedną trzecią zaplanowanych tematów. Dużo uwagi poświęciliśmy temu jak i co monitorujemy na przykładzie naszych realnych usług produkcyjnych.
Zainteresowałem się i bardzo mi się podobało.
- Sądząc po ogłoszeniu, będzie w całości poświęcona tolerancji błędów, dlaczego wybrałeś ten temat?
Cassandra to typowy, zajęty system rozproszony z ogromną ilością funkcjonalności wykraczającą poza bezpośrednią obsługę żądań użytkowników: plotki, wykrywanie awarii, propagacja zmian schematu, rozszerzanie/redukcja klastrów, ochrona przed entropią, tworzenie kopii zapasowych i odzyskiwanie itp. Jak w każdym systemie rozproszonym, wraz ze wzrostem ilości sprzętu wzrasta prawdopodobieństwo awarii, dlatego działanie klastrów produkcyjnych Cassandra wymaga głębokiego zrozumienia jego struktury, aby przewidzieć zachowanie w przypadku awarii i działania operatora. Po wielu latach używania Cassandry my , którymi jesteśmy gotowi się podzielić, a także chcemy omówić, w jaki sposób koledzy w sklepie rozwiązują typowe problemy.
— Jeśli chodzi o Cassandrę, co rozumiesz przez tolerancję na błędy?
Przede wszystkim oczywiście zdolność systemu do przetrwania typowych awarii sprzętowych: utraty maszyn, dysków, czy łączności sieciowej z węzłami/centrami danych. Ale sam temat jest znacznie szerszy i w szczególności obejmuje odzyskiwanie po awariach, w tym awariach, na które ludzie rzadko są przygotowani, np. błędach operatora.
— Czy możesz podać przykład najbardziej obciążonego i największego klastra danych?
Jednym z naszych największych klastrów jest klaster prezentowy: ponad 200 węzłów i setki TB danych. Ale nie jest najbardziej obciążony, ponieważ jest objęty rozproszoną pamięcią podręczną. Nasze najbardziej obciążone klastry obsługują dziesiątki tysięcy RPS w przypadku zapisu i tysiące RPS w przypadku odczytu.
- Wow! Jak często coś się psuje?
! Łącznie mamy ponad 6 tysięcy serwerów, a co tydzień wymienianych jest kilka serwerów i kilkadziesiąt dysków (bez uwzględnienia równoległych procesów modernizacji i rozbudowy parku maszynowego). Dla każdego rodzaju awarii są jasne instrukcje, co i w jakiej kolejności należy zrobić, wszystko jest w miarę możliwości zautomatyzowane, więc awarie mają charakter rutynowy i w 99% przypadków występują niezauważone przez użytkowników.
– Jak reagujesz na takie odmowy?
Od samego początku działania Cassandry i pierwszych incydentów pracowaliśmy nad mechanizmami tworzenia kopii zapasowych i odzyskiwania z nich, budowaliśmy procedury wdrożeniowe, które uwzględniają stan klastrów Cassandry i np. nie pozwalają na restart węzłów jeśli możliwa jest utrata danych. Planujemy o tym wszystkim porozmawiać na spotkaniu.
— Jak powiedziałeś, nie ma systemów całkowicie niezawodnych. Na jakie rodzaje awarii jesteś przygotowany i potrafisz sobie poradzić?
Jeśli mówimy o naszych instalacjach klastrów Cassandra, użytkownicy nic nie zauważą, jeśli stracimy kilka maszyn w jednym DC lub jednym całym DC (tak się stało). Wraz ze wzrostem liczby DC myślimy o rozpoczęciu zapewnienia funkcjonalności w przypadku awarii dwóch DC.
— Jak myślisz, czego brakuje Cassandrze pod względem tolerancji na błędy?
Cassandra, podobnie jak wiele innych wczesnych sklepów NoSQL, wymaga głębokiego zrozumienia swojej wewnętrznej struktury i zachodzących procesów dynamicznych. Powiedziałbym, że brakuje mu prostoty, przewidywalności i obserwowalności. Ale ciekawie będzie poznać opinie innych uczestników spotkania!
Oleg, bardzo dziękuję za poświęcenie czasu na udzielenie odpowiedzi na pytania!
Czekamy na wszystkich, którzy chcą porozumieć się z ekspertami w dziedzinie obsługi Apache Cassandra podczas spotkania 12 września w naszym biurze w Petersburgu.
Przyjdź, będzie ciekawie!
Źródło: www.habr.com