Досвід побудови та експлуатації великої файлового сховища

Данило Подільський

Данило Подільський (Git in Sky)
Розповідь про те, що кожен інженер повинен зробити у своєму житті після того, як він народив дитину, посадив дерево і побудував будинок – це зробити своє файлове сховище.

Доповідь мій називається «Досвід побудови та експлуатації великої файлового сховища». Велике файлове сховище ми будуємо і експлуатуємо останні три роки. В той момент, коли я подавав тези, доповідь називалася «Вночі через ліс. Досвід побудови експлуатації бла-бла-бла». Але програмний комітет попросив мене бути серйозніше, тим не менш, насправді це доповідь «Вночі через ліс».



Цей образ придумав колега Чистяков для конференції «Страйк», і там ми робили доповідь «Вночі через ліс» про докера, а я – про нові SQL-бази.

З тих пір, як я ходжу на конференції, мені стало зрозуміло, що я хочу чути не історії успіху, а історії жаху і кошмару, який нас всіх чекає на шляху до успіху. Тому що успіх чужий мені нічого не дасть. Звичайно, якщо хто-то вже щось зробив, саме знання про те, що це можливо зробити, допомагає мені рухатися, але в реальності я б хотів знати, де там міни і пастки.

Ще один кайфовий образ – книга «Пікнік на узбіччі». Там є науково-дослідний інститут, який досліджує цю зону. У них є літаючі боти, у них є автоматичні маркери, у них є те, і це, у них є роботизовані системи, а є сталкери, які бродять по цій зоні просто так, розкидаючи гайки туди-сюди. Так ось, так вже вийшло, що ми працюємо в тому сегменті, де затребувані сталкери, а не науково-дослідний інститут. Ми працюємо в тому сегменті, де highload найбільш важливий. Ми працюємо в сегменті нищебродов. Highload – це, взагалі-то, для нищебродов, тому що дорослі хлопці просто не допускають, щоб навантаження на сервера у них перевищувала 30%. Якщо ви вирішили, що ваш flow watermark 70%, по-перше, у вас почався highload, по-друге, ви нищеброд.



Отже. Для початку, що таке файлове сховище і навіщо воно взагалі може опинитися в нашому житті?


Файл – це шматок інформації (це його офіційне визначення), з ім'ям, за яким цей шматок інформації можна витягти. Але це ж не єдиний на світі шматок інформації, який забезпечений ім'ям, чому ж файл відрізняється від всіх інших? Тому що файл занадто великий, щоб звертатися з ним як з одним шматком. Дивіться: якщо ви хочете підтримувати, наприклад, 100 тис. одночасних з'єднань (це не так вже й багато) і ви віддаєте файли розміром до 1 Мб. Це означає, що якщо ви хочете звертатися з файлом як з одним шматком інформації, ви змушені завантажити всі 100 тис. файлів за 1 Мб пам'яті, 100 Гб пам'яті. Неможливо. Відповідно, вам доведеться щось зробити. Або обмежити кількість одночасних з'єднань (для корпоративних застосувань це нормально), або звертатися з файлом так, як ніби він складається з шматочків інформації, з окремих дрібних шматочків, з чанків. Слово чанк буде вживатися в доповіді далі.

Наріжний камінь здорового харчування . Було перекреслено. Файл – це наріжний камінь сьогоднішнього обміну інформацією, всі про це знають. Ми все, що можна, оформляємо як файл просто за звичкою. Тому що до недавнього часу у нас не було ніяких коштів зберігати інформацію інакше як файлах на диску. Про це теж буде пізніше – чому цей підхід сьогодні погано спрацьовує і краще б від нього відмовитися, але поки не вдається.

Файлове сховище – це місце, де файли зберігаються. Насправді, може бути, навіть більш важливо, що там зберігаються файли – це те місце, звідки до файлів надається доступ, звідки вони віддаються.



Що таке файлове сховище, ми зрозуміли. Що таке велике файлове сховище? Експлуатуючи велике файлове сховище, я виявив, що це не характеристика самого сховища. Наприклад, у Васі Пупкіна є архів підліткового кіно на 5 ПБ. Це велике файлове сховище? Ні, бо воно нікому не потрібно, тому що Вася Пупкін не може дивитися всі 5 ПБ одночасно. Він дивиться один маленький фільм. Там є ще кілька характеристик у цього пупкинского сховища, наприклад, якщо він його втратить, він розплачеться і скачає все заново з Інтернету.

Багато файлів. Можна припустити, що якщо багато байт – це не велике, тоді багато файлів – це велике? Немає. Є сховища, в яких дуже багато записів. У нас є бази, в яких мільярд рядків і, тим не менш, вони не є великими. Чому? Тому що якщо у вас є мільярд рядків в базі, у вас є зручні і надійні засоби управління цими рядками. Для файлів такого засобу немає. Всі наші активно використовуються сьогодні файлові системи – ієрархічні. Це означає, що для того, щоб з'ясувати, що відбувається у нас на файловій системі, нам треба пройтися по ній, всі наявні каталоги відкрити, їх почитати. Іноді у нас немає, навіть зазвичай у нас немає індексів на каталозі, тому ми змушені прочитати його від початку до кінця, знайти потрібний файл – все це чудово уявляють собі.

Так от, велике – це опис ситуації, в якій ви опинилися зі своїм файловим сховищем, а не самого сховища. Дуже часто, і це мій улюблений фокус, можна перетворити велике файлове сховище в нормальний, просто перенісши його на SSD. Там значно більше IOPS'ів та стандартні засоби управління інформацією, які використовуються на файлових системах, починають працювати досить швидко, щоб управління таким файловим сховищем не являло собою проблему.



Парадокс файлового сховища. З точки зору бізнесу ці файлові сховища не навіщо не потрібні. Коли у вас є досить великий проект, який приймає від користувачів файли, віддає користувачам файли, показує користувачам рекламу – все, загалом, зрозуміло. А чому приблизно половина бюджету проекту складають якісь залізяки невиразні, на яких лежать якісь невиразні байти? Бізнес, в принципі, розуміє, навіщо це, але насправді файлові сховища не потрібні. У бізнес-вимоги ніколи не буде написано «зберігати файли». У бізнес-вимоги буде написано «віддавати файли». Існує ТЗ, в якому буде написано «зберігати файли» – це ТЗ на систему резервного копіювання. Але це теж брехня. Коли ми хочемо систему резервного копіювання, ми не хочемо систему резервного копіювання, ми хочемо систему аварійного відновлення. Тобто ми знову хочемо файли читати, а не зберігати.

На жаль, творці файлових сховищ цього не розуміють. Може бути, тільки творці S3 додумалися до цієї простої речі. Всіх інших цікавить, щоб файли були складені, щоб вони ні в якому разі не зруйнувалися, і якщо виникає небезпека руйнування, то треба припинити всяку діяльність, ні в якому разі не віддавати файл, який може бути побитий, і ні в якому разі не завантажувати нові файли, якщо у нас є небезпека руйнування наявної інформації.

Це традиційний підхід, але, тим не менш, до того, чим ми займаємося, він відношення не має. Файлове сховище – річ необхідна, ніяк без неї не обійдешся, вона і потрібна, і немає. А без неї ніяк, тому що файлики повинні десь бути, щоб ти міг їх віддавати.



Основне джерело досвіду спілкування з файловими сховищами в моєму житті – це проект Setup.Ru. Setup.Ru – це масовий хостинг з деякими фишечками, там сайти генера за шаблоном. Є шаблон, користувач заповнює, натискає «згенерувати», генерується від 20 до 200 файлів, вони всі складаються в сховище. Користувачі завантажують картинки, різноманітні інші двійкові файли. Загалом, це необмежене джерело цього всього. На даний момент у сховищі Setup лежать 450 млн. файлів, поділених на 1,5 млн. сайтів. Це досить багато. Як ми дійшли до життя такого – це основний зміст моєї доповіді. Як ми рухалися до того, що у нас там є зараз. 20 млн. файлів в добу – це обсяг оновлення Setup сьогодні в піке. Саме по собі, 20 млн. – це вже багато. У перший раз ми зіткнулися з проблемами, коли у нас було 6,5 млн. файлів, але тим не менш.



У 2012 році файлове сховище Setup було організовано дуже просто. Генератори контенту публікували на два сервера з метою забезпечення відмовостійкості. Синхронізація – якщо у нас один з цих серверів помирав, ми брали інший такий же, копіювали rsynk'ом з одного на інший всю цю масу файлів, і все у нас було добре. Для гарячого контенту у нас використовувався SSD, тоді ще Hetzner. Це все в Hetzner, вибачте. Це до питання про те, що ми саме сталкери. Тобто Hetzner – це таке смішне місце, така зона, ми звідти виносимо час від часу відьмин холодець, продаємо його на чорному ринку і з цього живемо.

У чому ми побачили проблему, коли з цією схемою познайомилися в 2012 році? В той момент, коли у нас один з дублюючих серверів помер, ми деякий час поспіль живемо без файловера, відповідно, поки йде rsynk, ми змушені молитися і трястися від страху. Зі статистикою по файловій системі теж проблеми. Якщо по SSD все ще це вдавалося збирати, по 60 Гб (64 Гб тоді були SSD в Hetzner і ніяких інших), то за HDD ми дуже швидко до весни 2012-го зрозуміли, що ми не знаємо, що у нас лежить на дисках, і ніколи не дізнаємося. Правда тоді ми ще не думали, що це стане проблемою.



Влітку 2012 року у нас здох черговий сервер. Ми звичним рухом замовили новий, запустили rsynk, і він ніколи не закінчився. Вірніше, ніколи не закінчився скрипт, який запускав rsynk в циклі, поки не виявив, що всі файли скопійовані. Виявилося, що файлів вже досить багато, що обхід дерева займає шість годин, що копіюються файли плюс шести годинах, ще 12. І за 18 годин контент встигає змінитися настільки, що репліка наша неактуальна. «Вночі через ліс», тобто ніхто не очікував, що ця палиця догодить нам в око. Так ось. Зараз-то це очевидно, а тоді ми були дуже здивовані, типу: як же так?

Тоді ж ваш покірний слуга придумав скласти файли в базу. Чому він це придумав, звідки взагалі взялася ця ідіотська ідея? Тому що все-таки ми зібрали якусь статистику. 95% файлів були менше 64 Кб. 64 Кб – це навіть при 100 тис. одночасних з'єднань – цілком підьомний розмір, щоб звертатися з цим як з одним шматком. Інші файли, які були заховані в базу, великі файли були заховані в BLOB'и. Пізніше я буду говорити про те, що це головна помилка цього рішення. Буду говорити, чому.

Це все було зроблено в Postgres'e. Ми тоді вірили у майстер-майстер реплікацію, а в Postgres немає ніякої майстер-майстер реплікації (і ніде немає, насправді, ні в однієї СУБД немає майстер-майстер реплікації), тому ми написали свою, яка враховувала особливості нашого контенту і поновлення цього контенту, і могла нормально функціонувати.

І навесні 2013 року ми, нарешті, зіткнулися з проблемами того, що ми понаписували.



Файлів стало до того часу 25 млн. Виявилося, що при такому обсязі оновлень, який до того часу відбувався в системі, транзакції займають істотне час. Тому деякі транзакції, які були коротше, встигали закінчитися раніше, ніж почалися раніше, але більш довгі. В результаті – автоінкрементний лічильник, на який ми орієнтувалися в нашій майстер-майстер реплікації, виявився з дірочками. Тобто деякі файли ніколи наша майстер-майстер реплікація не бачила. Це був великий сюрприз для мене особисто. Я пив три дні.

Потім, нарешті, придумав, що треба всякий раз, коли ми запускаємо майстер-майстер реплікацію, від цього останнього лічильника відняти. Спочатку доводилося забирати 1000, 2000 потім, потім і 10000. Коли я вписав в це поле 25 тис., я зрозумів, що треба щось робити, але до того моменту я не знав, що робити. Ми натрапили знову на ту ж саму проблему – контент змінювався швидше, ніж ми його синхронізували.

Виявилося, що ця наша майстер-майстер реплікація працює досить повільно, і працює повільно, насправді, не вона, працює повільно вставка в Postgres, особливо повільно працює вставка в BLOB'и. Тому в якийсь момент, вночі, коли кількість публікацій зменшувалася радикально, база сходилася. Але вдень вона весь час була трошки неконсистентная, трохи. Наші користувачі помітили це наступним чином: вони завантажують картинку, вони хочуть її тут побачити, а її немає, тому що вони завантажили її на один сервер, а запитують вони її через round-robin з іншого. Ну, довелося вчити наші сервера, замінювати бізнес-логіку, довелося діставати картинку з того ж сервера, на який ми її завантажили. Це відгукнулося нам потім проблемами зі сдохшим сервером – коли сервер здох, треба лізти туди, де цей router й міняти параметри routing'а.



Восени 2013 року файлів стало 50 Мб. І тут ми натрапили на те, що наша база, загалом-то, не тягне, тому що там досить складний був join для того, щоб віддати користувачеві саме останню версію файлу, яку він завантажив. І у нас перестало вистачати наших восьми ядер. Що з цим робити, ми не знали, але колега Чистяков знайшов рішення – колега Чистяков на тригерах зробив нам materialized view, тобто за запитом файлик з в'юхи, в якій був довгий join, переїжджав в окрему таблицю, звідки в подальшому отримували. Зрозуміло, як це було влаштовано, і це все теж стало працювати чудово. Реплікація майстер-майстер до того часу вже працювала дуже погано, але цей костылик ми подкостылили, і все, начебто, було добре. До весни 2014 року.



120 млн. файлів. Контент перестав поміщатися на одну машину в Hetzner. Взяти машини, в яких було б більше, ніж чотири по три т-гвинти нам не вдалося. Тому було придумано наступне. Дрібні файли залишилися в Postgres, великі файли переїхали на leofs. Тут же з'ясувалося, що leofs – досить повільне сховище. Ми тоді ж спробували різні інші кластерні сховища, вони все досить повільні. Але ще виявилось, що ні одне з них не транзакційних. Сюрприз, правда?

Транзакційна файлова система потрібна для того, щоб змінити весь сайт цілком. Якщо користувач опублікував новий сайт, він не хоче, щоб він протягом півгодини по файлику змінювався. Нехай навіть сайт буде публікуватися півгодини, користувач хоче, щоб новий сайт був опублікований весь цілком.

Жодне з тестованих нами сховищ цю функціональність нам не дало. Ми могли б її реалізувати на POSIX-сумісних кластерних файлових сховищах з допомогою символьних посилань, як це робиться на стандартній файловій системі, але, виявилося, що жодна з них не забезпечує нам достатньої кількості IOPS'ів, щоб віддавати наші 500 запитів в секунду. Тому дрібні файли залишилися в Postgres, а замість великих файлів і BLOB' ів, виявилися посилання на leofs сховища. І все знову стало добре. Зараз це зрозуміло, що це ми ще один костылик подпихнули під нашу систему, але, тим не менш, все стало добре на деякий час.



2015 рік, початок. На leofs скінчилося місце. Там вже було 400 млн. файлів – мабуть, користувачі наші весь час нарощують оберти. У нас на leofs скінчилося місце, ми вирішили, що треба додати парочку нод, ми їх додали. Деякий час поспіль ребалансинг йшов, потім він як би закінчився, і виявилося, що майстер-нода тепер не знає, де у неї файли лежать.

Добре, ми відключили ці дві нові ноди. Виявилося, що тепер вона зовсім нічого не знає. Ми підключили ці дві нові ноди назад, і виявилося, що тепер ребалансинг не йде взагалі. Ось так ось.

Технічний керівник команди setup найняв перекладача з японської, і ми подзвонили в Токіо. В 8 ранку. Поговорити з компанією Rakuten. Компанія Rakuten поговорила з нами годину, і вибачте мене, я буду її лаяти, тому що так зі мною ще не зверталися в моєму житті, а я 20 років в бізнесі… Компанія Rakuten поговорила з нами годину, уважно вислухала наші проблеми, почитала наші баг-репорти в їх трекері, після чого сказала: «Знаєте, у нас закінчився час, дякую, вибачте». І тут ми зрозуміли, що до нас прийшов хутровий звір, тому що у нас 400 млн. файлів, у нас (з урахуванням replication factor 3) контенту 20 Тб. Насправді це не зовсім так, але реального вмісту там 8 Тб. Ну, от що робити?

Спочатку ми панікували, пробували розставляти по коду leofs метрики, пробували зрозуміти, що відбувається, колега Чистяков не спав ночами. Ми намагалися з'ясувати, чи не хоче хто-небудь з пітерських Erlang'істів помацати це паличкою. Пітерські Erlang'істи виявилися розумними людьми, вони не стали чіпати це паличкою.

Тут виникла ідея, що добре, гаразд, нехай, але ж є дорослі хлопці, у дорослих хлопців буває СГД. Ми беремо СГД, і на цю СГД кладемо всі наші файли і ведемо себе як дорослі хлопці. Ми погодили бюджет. Ми пішли в Hetzner. Нам не дали СГД. Більше того, коли ми придумали, що ми візьмемо дев'яти-дискову машину, піднімемо на ній iSCSI на FreeBSD, iSCSI по внутрішній Гбитной мережі, пробросим це все наші віддають сервера, піднімемо там старе сховище на Postgres в тому вигляді, в якому воно було. І навіть порахували, ніби як, до 128 Гб оперативки ми ще півроку влазили. Виявилося, що ці дев'яти-дискові машини неможливо підключити до нашого кластеру по внутрішній мережі, тому що вони стоять зовсім в інших стійках. «Вночі через ліс» – ніхто не очікував, що ця яма попадеться нам під ноги. І ніхто не очікував, що ми все-таки в зоні. Що це чергова давилка. Коротше, по загальній мережі Hetzner ідея з квазі-СГД по iSCSI не спрацювала. Там занадто велика була latency, у нас розвалювався кластерна файлова система.



2015 року, весна. 450 млн. файлів. На leofs місце закінчилося зовсім, тобто взагалі. Rakuten навіть не став з нами розмовляти. Спасибі їм. Але жах, найстрашніший з нами сталося навесні 2015 року. Все було добре ще вчора, а сьогодні disc saturation в сервері Postgres піднявся до 70% і вже не опустився вниз. Через тиждень він піднявся до 80%, і зараз, до перемикання на наш останній варіант, він весь час тримався від 95 до 99%. Це означає, що, по-перше, диски скоро помруть, по-друге, все дуже погано в сенсі швидкості віддачі і швидкості публікації. І тут ми зрозуміли, що треба вже зробити крок вперед. Що ситуація така, що нас з цього проекту виженуть все одно, після цього проект закриють, тому що ці 450 млн. файлів – це і є весь проект. Загалом, ми зрозуміли, що треба йти ва-банк.

Про рішення, які ми розробили навесні 2015 року і впровадили, які зараз функціонують, я розповім трохи пізніше. А поки – чого ми навчилися за той час, поки все це експлуатували?



По-перше, відмовостійкість. Відмовостійкість – це не зберігати файли. Нікому не потрібно знати, що у тебе надійно заховані 450 млн. користувальницьких файлів, якщо користувачі не справляються отримати до них доступ.

Файловий кеш. Я до нього ставився злегка з презирством, поки не виявив, що якщо у тебе справді високе навантаження, ти нікуди не дінешся, ти повинен hot set заховати в пам'ять. Там set hot не такий вже і великий. Насправді, hot set становить близько 70 тис. сайтів, і близько 10 млн. файлів. Тобто якщо б у Hetzner можна було взяти за дешево машину з 1 Тб оперативної пам'яті, ми б все це сховали в пам'ять, і у нас знову не було б проблем, якби ми були дорослі хлопчики, а не сталкери з смітника.

Розподілені системи зберігання. Якщо у вас є гроші на велику СГД, яка сама по собі має синхронізацію з іншого такий СГД… Коли я останній раз перевіряв, шасі коштувало близько 50 тис. євро. Та диски які туди потрапило не вставиш. Може бути, зараз це стало дорожче, а, може бути, подешевшало, на цьому ринку багато гравців – IBM, Hewlett-Packard, IMC… Тим не менш, ми пробували кілька дешевих рішень – CEF, leofs і ще парочку якихось, назв яких я не запам'ятав.

Якщо ваше сховище заявлено як eventual consistency – це означає, що ви потрапили до проблеми. В які проблеми ви потрапили з eventual consistency, я розповідав тільки що. А які проблеми ми потрапляємо зі strong consistency? Ми туди запихаємо файл, він чомусь не запихивается і обламується. Користувач повторює спробу, публікація лягає в чергу. Через деякий час чергу розростається, ще через деякий час виявляється, що ваше файлове сховище лягло під тією навантаженням, яку створюють користувачі, які весь час як мавпочки тикають в кнопку. У корпоративному середовищі можна було б пояснити, що так робити не можна, але вони заплатили гроші, вони хочуть тикати в кнопку.

Окремою проблемою виявився ребалансинг. Перше, що люди навчаються робити з системою CEF – вони навчаються прикручувати йому ребалансинг, щоб в той момент, коли він потрібен, він не з'їдав 100% пропускної спроможності диска і внутрішньої мережі.

А ще воно гальмує. Всі розподілені системи зберігання, які ми спробували, лячно гальмують. В сенсі – на них IOPS'ів менше 100. Якщо це POSIX-система – це, взагалі, вирок. Якщо це об'єктне сховище, то це може бути добре. У нас до leofs був прибудований Varnish, щоб найпопулярніший контент все-таки віддавати з кеша, а не вимагати кожного разу звідти.



Чого ще ми навчилися? Того, що дрібні файли – це не файли. Дрібні файли – це записи в базі даних. Все, що можна забрати зі сховища одним шматком і одним шматком віддати користувачеві – це все не файл, це все дуже зручний контент, з яким можна звертатися.

PostgreSQL BLOB. Ніколи його не використовувати. Можна, звичайно, було прочитати про це в документації, але я чомусь не прочитав. PostgreSQL BLOB не потрапляє в стандартну реплікацію PostgreSQL. Ні в ту, ні в сяку. Реально це таблиця Postgres, внутрішня, якої поділений на шматочки лежить цей самий файл, але ця таблиця не потрапляє в реплікацію ніколи. Може, вони виправлять цю проблему, але це те, на що ми натрапили, коли у нас вже лежали 4 Тб даних в цьому самому Postgres, і що-небудь робити було запізно.

Матеріалізація view – це виявилося срібною кулею. Якщо у вас починає пригальмовувати на join'ах, на CPU база, то матеріалізація view може вам допомогти. Це дуже легко – 3-4 тригера, і все у вас добре. Головне – не забувати перевіряти, що дані змінилися, і відповідно, дані в матеріалізованій view'хе треба б инвалидировать.

Самописні реплікація. Я їй дуже пишався, поки не виявив, як вона працює. Не треба, не пишіть самописную реплікацію. Мені говорили про це, починаючи з 2012 року. У 2012 восени на HighLoad++ я все це розповідав з великою гордістю, про те, як чудово у нас працює файлове сховище на Postgres. І мені відразу сказали, що буде погано. Я знав, що буде погано, я не знав, що так скоро.

Коли ми починали з усім цим возитися, ми знали, що дорослі хлопчики начебто ВКонтакте ніколи не видаляють файли. Вони лише позначають їх як віддалені. Ми подумали, що нам навіть позначати їх як віддалені не треба, у нас все буде добре і так. Поки до нас не прийшов Роскомнагляд і не попросив видалити ось це, це і це. Ми видалили сайт, видалення сайту ми передбачили. Але виявилося, що в пошуковиках ховаються прямі посилання на контрафактні картинки, тому далі почався справжній кошмар.

І знову привіт компанії Rakuten – Java краще, ніж Erlang. Не в сенсі, що сама Java краще, ніж Erlang. А в сенсі, що Java-програмісти недостатньо кмітливі. Java-програмісти полізли б у цю клоаку і полагодили б нам, може бути, leofs.



Чому ми не навчилися? Ми не змогли навчитися великий відмовостійкої СГД. У замовника просто немає такого бюджету, і ми його розуміємо. А навіть, якщо замовник знайшов бюджет, йому довелося б знайти бюджету на переїзд з Hetzner, тому що в Hetzner нічого такого не дають.

Розподілені POSIX-сумісні файлові системи. Взагалі, POSIX-сумісна файлова система – це система, яка забезпечує випадковий доступ. Фактично цим вона відрізняється від об'єктного сховища, випадковий доступ на запис по файлу. Це не навіщо не потрібно під наші завдання. Тому вона не потрібна. Але її ніхто не використовує, вона в бетах.



Тепер про те, як ми вирішили проблему і, будемо сподіватися, вирішили її на найближчий рік як мінімум, а може бути і на два. А потім, звичайно, все почнеться по новій.

  • Ми взяли кластерну NoSQL СУБД. Ми взяли Aerospike, але можна взяти будь-яку. Ми взяли Aerospike тому що у нього прекрасні показники по latency. Він
    минулої осені став безкоштовним, тому ми ним скористалися.
  • Ми самі рубаємо файлики на чанкі і кожен чанк ми зберігаємо окремо, окремим рядком у базі даних і окремо його витягуємо, коли він нам потрібен.
  • Ми написали версіонування. Ту саму транзакционность. Фактично це модернізація ідеї символьних посилань. Тобто у нас є якась transaction id, до якої
    відносяться всі файли під нею завантажені, а потім в таблиці з сайтами змінюється посилання на транзакцію.
  • Самописний dedup. Якщо вже ми самі ріжемо на чанкі, то ми можемо порахувати для кожного чанка ш1, ми можемо цей ш1 зберігати в базі, як ключ доступу до цього
    чанку. Загалом, dedup зменшив нам це. Розповім детальніше. У нас був dedup, він був на файловому рівні, ми вважали суму для файлу і дублировавшиеся файли
    зберігалися в базі тільки один раз. Використання почанкового dedup зменшило нам обсяг бази з восьми Тб до шести. Це чистий обсяг даних, без реплікації.
  • Самописні транзакції. Тут зрозуміло, що в розподілених базах даних немає транзакцій. Нам довелося написати свої, які чисто під ту задачу, яку ми
    вирішуємо.
  • І зрозуміло, LZ4-стиснення ми туди прикрутили.
Так от, це працює. Зараз це все в бою. Зараз це все зберігає в собі ті самі 450 млн. файлів, 1,5 млн. сайтів, відповідає на 600 запитів в секунду. І воно при цьому не завантажено, воно може більше. І приймає 20 млн. апдейтів на добу.



Серверів в цьому кластері вісім, і це пов'язано з тим, що у нас на меншу кількість серверів не поміщається контент. У нас replication factor 3, у нас там диски, два по три. Ми дуже сміливі хлопці, тому вони стоять у нас в RAID 0. Відповідно, ми маємо вісім серверів за 3 Т. На даний момент кожен сервер заповнений вже на 66%, відповідно, ми збираємося взяти ще два і підключити в той же самий кластер і дочекатися закінчення ребалансинга.

1,5 До запитів в секунду – це те, на чому я тестував. Вперся я при цьому не в кластер з восьми машин, зрозуміло справа, а продуктивність одного тестового сервера. Ну, я вирішив, що 1,5 До – це в 2,5 рази більше, ніж у нас зараз є, тому я на цьому місці продовжувати тестування не став.



Але все-таки, «Вночі через ліс». Ми дуже гладко з цієї нашої NoSQL базою переводили користувачів, і все було дуже добре, поки не виявилося, що ми залили по 2 Тбайта кожен сервер. Фантастика – ось кластер ще 5 хвилин тому працював, а ось він вже не працює. Ось він віддає 500-ті помилки, ось він віддає 404-ті помилки, ось він віддає 403-ие помилки. Не працює публікація. В логах дуже дивні повідомлення: «Я не змогла знайти такий-то сектор».

Спасибі підтримки Aerospike, я не спав всього одну ніч. На ранок вони мені відповіли, виявилося, що не можна сконфігурувати один файл сховища нізькорівневої в Aerospike більше, ніж 2 Т. Можна при цьому їх сконфігурувати кілька, зараз налаштований на три файлу по 1 Т. Але перший наш кластер Aerospike був налаштований на кожній ноде один файл на 3 Т. Як тільки ми дісталися до двох Т, воно негайно все припинило функціонувати. І причому, дуже неприємним чином – ми втратили певну кількість завантаженого користувачами контенту, якого на старому сторадже вже не було, а на новому він вже обламався.

Це те саме «Вночі через ліс» – ти впав в яр і лежиш у багнюці, ти не бачиш небо, ти не розумієш, куди вилізти, пекельні створіння вже виють. А рестарт однієї ноди займає три години, тому що вона будує в пам'яті індекс, вона змушена рахувати з диска всі дані. 100 Мб в секунду – це простий SATA диск. І повний ребалансинг. Ми перевірили це, ми вирубали одну ноду, стерли з неї дані, включили її назад, одна нода повна, відновлення кластера при заміні однієї ноди займає 60 годин. Це означає, що ніякого replication factor менше трьох ми собі дозволити не можемо.

Ця доповідь — розшифровка одного з кращих виступів на професійній конференції з експлуатації та devops RootConf. Ми вже готуємо конференцію 2017 року, хоча що значить готуємо? Відкрили реєстрацію на квитки і доповіді. Зараз всі сили кинуті на HighLoad++, вона з'їдає всі наші сили і сон :(

В цьому році багато цікавого по темі сховищ даних, ось самі спірні і зубодробильні доповіді:



Також деякі з цих матеріалів використовуються нами в навчальному онлайн-курс по розробці високонавантажених систем HighLoad.Guide — це ланцюжок спеціально підібраних листів, статей, матеріалів, відео. Вже зараз у нашому підручнику понад 30 унікальних матеріалів. Підключайтеся!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.