Odnoklassniki е най-големият потребител на Apache Cassandra в RuNet и един от най-големите в света. Започнахме да използваме Cassandra през 2010 г. за съхраняване на оценки на снимки и сега Cassandra управлява петабайти данни на хиляди възли, всъщност дори разработихме наши собствени .
На 12 септември в нашия офис в Санкт Петербург ще проведем . Основният говорител на събитието ще бъде главният инженер на Odnoklassniki Олег Анастасиев. Олег е експерт в областта на разпределените и отказоустойчиви системи, той работи с Cassandra повече от 10 години и многократно .
В навечерието на срещата разговаряхме с Олег за устойчивостта на грешки на разпределените системи с Касандра, попитахме за какво ще говори на срещата и защо си струва да присъстваме на това събитие.
Олег започва своята програмна кариера през 1995 г. Разработва софтуер в банкирането, телекомуникациите и транспорта. Работи като водещ разработчик в Odnoklassniki от 2007 г. в екипа на платформата. Неговите отговорности включват разработване на архитектури и решения за системи с голямо натоварване, големи хранилища за данни и решаване на проблеми с производителността и надеждността на портала. Той също така обучава разработчици в компанията.
- Олег, здравей! През май се проведе , посветен на Apache Cassandra, участниците казват, че дискусиите са продължили до късно през нощта, моля, кажете ми какви са впечатленията ви от първата среща?
Разработчици с различен опит от различни компании дойдоха със собствена болка, неочаквани решения на проблеми и невероятни истории. Успяхме да проведем по-голямата част от срещата в дискусионен формат, но имаше толкова много дискусии, че успяхме да засегнем само една трета от планираните теми. Обърнахме много внимание на това как и какво наблюдаваме, използвайки примера на нашите реални производствени услуги.
Беше ми интересно и много ми хареса.
- Съдейки по съобщението, ще бъде изцяло посветен на отказоустойчивостта, защо избрахте тази тема?
Cassandra е типична натоварена разпределена система с огромно количество функционалност извън директното обслужване на потребителски заявки: клюки, откриване на грешки, разпространение на промени в схемата, разширяване/намаляване на клъстери, анти-ентропия, архивиране и възстановяване и т.н. Както във всяка разпределена система, с увеличаването на количеството хардуер, вероятността от повреди се увеличава, така че работата на производствените клъстери Cassandra изисква задълбочено разбиране на нейната структура, за да се предвиди поведението в случай на повреди и действията на оператора. След като използвахме Cassandra в продължение на много години, ние , които сме готови да споделим, а също така искаме да обсъдим как колегите в магазина решават типични проблеми.
— Когато става дума за Касандра, какво имате предвид под толерантност към грешки?
На първо място, разбира се, способността на системата да оцелее при типични хардуерни повреди: загуба на машини, дискове или мрежова свързаност с възли/центрове за данни. Но самата тема е много по-широка и по-специално включва възстановяване от повреди, включително повреди, за които хората рядко са подготвени, например грешки на оператора.
— Можете ли да дадете пример за най-натоварения и най-голям клъстер от данни?
Един от най-големите ни клъстери е подаръчният клъстер: повече от 200 възли и стотици TB данни. Но не е най-натовареният, тъй като е покрит от разпределен кеш. Нашите най-натоварени клъстери обработват десетки хиляди RPS за запис и хиляди RPS за четене.
- Еха! Колко често нещо се чупи?
! Общо имаме повече от 6 хиляди сървъра и всяка седмица се сменят няколко сървъра и няколко десетки дискове (без да се вземат предвид паралелните процеси на надграждане и разширяване на машинния парк). За всеки тип повреда има ясни инструкции какво да се прави и в какъв ред, всичко е автоматизирано, когато е възможно, така че повредите са рутинни и в 99% от случаите се случват незабелязано от потребителите.
– Как се справяте с такива откази?
От самото начало на работата на Cassandra и първите инциденти работихме върху механизмите за архивиране и възстановяване от тях, изградихме процедури за внедряване, които отчитат състоянието на клъстерите на Cassandra и например не позволяват рестартиране на възли ако е възможна загуба на данни. Планираме да говорим за всичко това на срещата.
— Както казахте, няма абсолютно надеждни системи. За какви видове неуспехи се подготвяте и можете да се справите?
Ако говорим за нашите инсталации на Cassandra клъстери, потребителите няма да забележат нищо, ако загубим няколко машини в един DC или един цял DC (това се е случвало). С увеличаването на броя на DC мислим да започнем да осигуряваме работоспособност при повреда на два DC.
— Какво мислите, че липсва на Касандра по отношение на толерантността към грешки?
Cassandra, подобно на много други ранни NoSQL магазини, изисква задълбочено разбиране на вътрешната си структура и протичащите динамични процеси. Бих казал, че му липсва простота, предвидимост и наблюдателност. Но ще бъде интересно да чуем мненията на други участници в срещата!
Олег, много ти благодаря, че отдели време да отговориш на въпросите!
Очакваме всички, които искат да общуват с експерти в областта на управлението на Apache Cassandra на срещата на 12 септември в нашия офис в Санкт Петербург.
Заповядайте, ще бъде интересно!
Източник: www.habr.com