Аднакласнікі - самы буйны карыстач Apache Cassandra у Рунэце і адзін з найбуйнейшых у свеце. Мы пачалі выкарыстоўваць Cassandra ў 2010 для захоўвання адзнак фота, а цяпер пад кіраваннем Cassandra знаходзяцца петабайты дадзеных на тысячах нод, больш за тое, мы нават распрацавалі сваю ўласную .
12 верасня ў сваім пецярбургскім офісе мы правядзем . Асноўным спікерам мерапрыемства стане галоўны інжынер Аднакласнікаў Алег Анастасьеў. Алег - эксперт у галіне размеркаваных і адмоваўстойлівасць сістэм, ён працуе з Cassandra ўжо больш за 10 гадоў і неаднаразова .
У перадпачатку мітапа мы пагаварылі з Алегам пра адмоваўстойлівасць размеркаваных сістэм з Cassandra, пацікавіліся пра што ён будзе распавядаць на мітапе і чаму варта наведаць гэтае мерапрыемства.
Алег пачаў кар'еру праграміста ў далёкім 1995 годзе. Распрацоўваў ПЗ у банкаўскай сферы, тэлекоме, транспарце. Працуе вядучым распрацоўшчыкам у Аднакласніках з 2007 года ў камандзе платформы. У яго абавязкі ўваходзіць распрацоўка архітэктур і рашэнняў для высоканагружаных сістэм, вялікіх сховішчаў даных, вырашэнне праблем прадукцыйнасці і надзейнасці партала. Таксама займаецца навучаннем распрацоўшчыкаў ўнутры кампаніі.
- Алег, прывітанне! У маі адбыўся , прысвечаны Apache Cassandra, удзельнікі кажуць, што абмеркаванні ішлі да позняй ночы, скажы, калі ласка, якія ў цябе ўражанні ад першага мітапу?
Прыйшлі распрацоўшчыкі з розным бэкграўндам з розных кампаній са сваім болем, нечаканымі рашэннямі праблем і дзіўнымі гісторыямі. Нам удалося правесці большую частку мітапа ў фармаце дыскусіі, але абмеркаванняў было так шмат, што мы змаглі закрануць толькі трэць намечаных тэм. Шмат увагу надалі таму, як і што мы маніторым на прыкладзе нашых рэальных production-сэрвісаў.
Мне было цікава і вельмі спадабалася.
- Мяркуючы па анонсе, будзе цалкам прысвечаны адмоваўстойлівасці, чаму выбралі менавіта гэтую тэму?
Cassandra гэта тыповая нагружаная размеркаваная сістэма з вялікай колькасцю функцыянальнасці акрамя непасрэднага абслугоўвання карыстацкіх запытаў: gossip, выяўленне збояў, распаўсюджванне змен схемы, пашырэнне/памяншэнне кластара, anti-entropy, бекапы і аднаўленне і г.д. Як і ў любой размеркаванай сістэме з ростам колькасці жалеза расце верагоднасць збояў, таму эксплуатацыя production кластараў Cassandra патрабуе глыбокага разумення яе прылады для прадказання паводзін у выпадку збояў і дзеянняў аператара. У працэсе шматгадовага выкарыстання Cassandra мы , якой гатовы падзяліцца, а таксама хочам абмеркаваць, як калегі па цэху вырашаюць тыповыя праблемы.
- Калі гаворка заходзіць аб Cassandra, што ты разумееш пад адмоваўстойлівасцю?
У першую чаргу, вядома, здольнасць сістэмы перажываць тыповыя збоі жалеза: страту машын, дыскаў ці сеткавай складнасці з нодамі/датацэнтрамі. Але сама тэма значна шырэй і ў прыватнасці ўключае ў сябе аднаўленне пасля адмоваў, у тым ліку адмоваў, да якіх людзі рэдкія бываюць гатовыя, напрыклад, памылак аператара.
- Можаш прывесці прыклад самага нагружанага і самага вялікага кластара дадзеных?
Адзін з нашых самых вялікіх кластараў - гэта кластар падаруначкаў: больш за 200 нод і сотні ТБ дадзеных. Але ён не з'яўляецца самым нагружаным, паколькі прычынены размеркаваным кэшам. Нашы самыя нагружаныя кластара трымаюць дзясяткі тыс. RPS на запіс і тысячы RPS на чытанне.
- Ого! Як часта нешта ламаецца?
! Сумарна ў нас больш за 6 тыс. сервераў, і кожны тыдзень пары сервераў і некалькі дзясяткаў дыскаў ідуць пад замену (без уліку паралельных працэсаў апгрэйду і пашырэнні парка машын). Для кожнага віду адмовы прапісана дакладная інструкцыя, што і ў якім парадку рабіць, усё па магчымасці аўтаматызавана, таму адмовы з'яўляюцца руцінай і ў 99% выпадкаў адбываюцца незаўважна для карыстальнікаў.
- Якія вы змагаецеся з падобнымі адмовамі?
З самага пачатку эксплуатацыі Cassandra і першых інцыдэнтаў мы прапрацавалі механізмы рэзервовых дзід і ўзнаўленні з іх, пабудавалі працэдуры deploy, якія ўлічваюць стан кластараў Cassandra і, напрыклад, не даюць перазапускаць вузлы, калі магчымая страта дадзеных. Пра ўсё гэта мы плануем паразмаўляць на мітапе.
- Як ты сказаў, абсалютна надзейных сістэм не існуе. Да якіх відаў адмоваў вы рыхтуецеся і здольныя перажыць?
Калі казаць аб нашых усталёўках кластараў Cassandra, карыстачы нічога не заўважаць, калі мы страцім некалькі машын у адным ДЦ або цалкам адзін ДЦ (такое здаралася). З ростам колькасці ДЦ, думаем аб тым, каб пачаць забяспечваць працаздольнасць у выпадку збою двух ДЦ.
- Чаго на твой погляд не хапае Cassandra ў плане адмоваўстойлівасці?
Cassandra як і шматлікія іншыя раннія NoSQL сховішчы патрабуе глыбокага разумення яе ўнутранай прылады і адбывалых дынамічных працэсаў. Я б сказаў, што ёй не хапае прастаты, прадказальнасці і назіральнасці. Але будзе цікава пачуць меркаванне іншых удзельнікаў мітапу!
Алег, вялікі дзякуй, што знайшоў час адказаць на пытанні!
Мы чакаем усіх, хто жадае пагутарыць з экспертамі ў вобласці эксплуатацыі Apache Cassandra на мітап 12 верасня ў свой пецярбургскі офіс.
Прыходзьце, будзе цікава!
Крыніца: habr.com