Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 25
но при условии, что у всех кладунов есть общее хранилище (например nfs, главное, что бы у всех кладунов в группе было оно общим, а так же общая БД).
И вот это условие убивает на корню геораспределённые системы.
И из статьи не понятно, но думаю, что "кладун" - это не один сервер с одним диском на который заливается объект целиком, а распределённое хранилище, которое при заливке "нарезает" объёкт, управляет репликацией и т.д.
Репликация между локациями - это уже отдельный процесс, Илья рассказывал именно о том, как залить файл в облако. То что происходит дальше - это вообще отдельная песня =)
Раз уж зашла речь про геораспределенные системы.
Тут вы абсолютно не правы. Решение такое же будет.
В случае, если у вас есть сервера в Москве, Владивостоке и Пекине, то по хорошему ваш "disk.cloud.ru" будет указывать на разные IP адреса (во всяком случае все нормальные геораспределенные системы так проектируются), не пытаются сливать всех в один балансировщик в Москве. Т.е. у вас будут разные балансировщики в разных частях планеты, и каждый работать будет со своими "кладунами". Репликация - это отдельный процесс и он не всегда должен осуществляться, есть вообще такие законы как приземление информации и вы не можете перезаливать файлы пользователя куда-нибудь в Чили.
Так что минус все же ваш.
Гео - это не только города в разных частях планеты, но и разные ДЦ в одном регионе.
Например, в Московской области, где между ДЦ будет RTT 3-5 мс. Каждый ДЦ - свой кладун.
Мы же не хотим побить пользовательские данные? Тогда нам не подходят асинхронные репликации в бд и общем сторадже -> получаем неприемлимые тормоза на сколько-нибудь значимых объёмах записи.
Конечно, можно написать, что "у вас будут разные балансировщики", т.е. балансировщик на уровне Мск, который отправит на нужный (ближайший или менее загруженный) кладун в регионе, то тогда чем эта схема отличается от схемы Яндекса?)
Раз уж вы так настойчиво желаете выйти за границы ДЦ.
В случае множества ДЦ в одном регионе придется в любом случае каким-то образом выбирать конкретный для конкретного пользователя, а еще лучше и для конкретного запроса.
Заливать файл частью в один ДЦ, а другую во второй - идея плохая, так как объединять файл размером 100 ГБ+ ничего хорошего не даст. И тоже самое касается маршрутизации, если ДЦ1 перекидывает в ДЦ2 тем или иным образом запросы.
И повторюсь, даже в приведенном вами случае (кладун=ДЦ) все равно получается, что изложенное в статье имеет место быть. В докладе Ильи была информация о том, что канал кладуна - 4 гбит/с. До ДЦ явно не может быть 4 гбит/с, из чего было предположение о том, что работа в рамках одного ДЦ и статья писалась с этим пунктом. В этом случае общий сетевой диск и общая БД - это разумное решение.
Кладун всегда знает свою нагрузку, тем более что Илья и ко сделали потрясающую работу по сбору такой статистики (и они могут ее хранить и анализировать локально в ДЦ). Если по каким-то причинам кладун не может обработать запрос клиента - всегда можно отправить http-код на переотправку запроса (если речь про загрузку маленького файла или подготовку загрузки большого) и балансировщик на уровне мск переведет из-за round-robin запрос на другой ДЦ. В случае с балансерунами будет все тот же RTT 3-5 мс, что бы собрать статистику со всех ДЦ в одном месте. Решение с балансерунами плохо масштабируется, не говоря о том, что балансерун может выдать ссылку на кладуна, которого уже нет в живых.
Нет смысла перекладывать работу кладуна куда-то еще - это переусложнение и увеличение нагрузки на инфраструктуру.
почему-то расчет SHA-512 занимает много времени, консольная утилита делает быстрее на порядок
Глянул код, есть две рекомендации - использовать BufReader для уменьшения сисколлов, да и размер я бы увеличил - 4кб буфер уж сильно часто будет дёргать чтение. Если верно нашёл, у гнушного sha512sum размер буфера по-умолчанию 32кб.
А зачем выдумывать какие-то странные слова? Балансерун, кладун, макладун.
Так-то multipart upload/download придумано давно и используется повсеместно.
По поводу странных слов.
Вышел к народу Яндекс-воин, достал свой меч-клаждунец...
...и обалансрался народ от неожиданности.
Возможно "старших" по диску приберегли на июньский YoungCon, поэтому не стали дёргать на данное мероприятие, а отдали "малышне". Ну либо просто боевое крещение - а расскажи-ка публике о том, с чем работаешь. Пропусти через себя.
И вот такой пропущенный фарш и получили.
Ну поиск не знает упоминаний об Илье Абрамове, кроме как засвет такого тёзки в тренировках по алгоритмам (от Яндекса) сего года, да и аватарка докладчика намекает на что-то студенческое, поэтому если первый блин - простительно, но в будущем конечно Илье стоит избегать сленга, а стараться описать архитектуру общепринятыми словами. Вот тогда и должно прийти понимание, что речь не о велосипеде, а о каких-то стандартных для индустрии вещах.
По поводу эффективности.
Если "кладуны" - это старая история, то кажется это сходится с моим свежием ощущением рукожопного рукожопства создателей клиента Яндекс.Диска для Windows. Типа - сами не поняли, как работать с тем, что наворотили.
Кейс - загрузить в папочках десятки тысяч небольших файлов. Началось всё бодро - клиент считает хеши, чтоб не грузить повторно в облако уже известное облаку, потом аплоадит, потом обновляет иконки папок - зелёные галочки должны показать, что синхронизация завершена и локалка консистентна с удалённой папкой.
А дальше начался треш. Лютый и длительный жор процессорного времени, хотя подсчёт хеша альтернативными утилитами проходил за десятки секунд. Когда наконец клиент проперделся - у папок вместо зелёных галочек появились и синие знаки вопроса (типа загрузка не завершена) и даже красные крестики (ошибка). Перезапуск и синхронизации, и клиента ничего не даёт. При этом проверка показала, что всё благополучно загружено и чудит именно официальная чудо-программулина. Помог радикальный способ - удаление скрытой системной папки .sync с кэшированными данными о файлах. Видимо кэш перестроился, хоть это опять и заняло ужас сколько времени, и на какое-то время помогло. А потом снова неконсистентность.
В итоге терпение иссякло, в нейросетку было засунуто официальное API Диска и неофициальное SDK для Python, в итоге родилась пара скриптов - на аплоад и на сверку.
Ооооо, это такой кайф, когда те же операции выполняются не несколько часов, а ещё и отображается честный прогресс. Так почему официальное приложение из себя представляет такое убожество, не может решить ту же самую задачу?
Яндекс какое-то время назад выпустил четвёртую версию, которая вообще ещё не умеет синхронизировать локальную папку Диска с удалённой, только скачивать файлы в реалтайме по запросу, при их открывании. То ли это из-за недавно озвученной тарифной политики (вы нам нагрузку создаёте - мы прогу оставим только для пользователей с подпиской 36), то ли просто-напросто из-за того, что третья версия клиента рукожопая, а когда начали четвёртую мутить, то даже затруднились всё это рукожопство переписать.
У нас вообще с обработкой множества файлов умеют в крупных российских компаниях работать?) А то второй случай под нервный смех заставил сомневаться в таких навыках...
Второй шок я испытал ночью, когда после посещения картинной галереи захотел залить в альбом VK восемь сотен фоток. Ладно, тут речь про Мэйл.ру, у них кармически свойство превращать даже золото в отходы жизнедеятельности.
Раньше сотнями через мобильное приложение загружал, в несколько заходов (выбиралось по 100 файлов за раз), сейчас лимита не было, но файлы при загрузке перемешались. Сначала загрузилось N с конца, потом пошло всё остальное с начала.
Хорошо, добрался до компа, стал грузить в браузере. Та же история! Чуваки, вы жжёте напалмом что ли? У вас что за сортировка используется, которая стандартные имена вида IMG202605... внезапно миксует по какому-то разделителю или что за чанки-приколы такие? Ещё и в процессе отобразилось меньше файлов, чем я перетащил в аплоад (без каких-либо ошибок).
Чем дело кончилось - да тем же самым, утопающий спасает сам себя. Очередной скрипт, который через неофициальное апи (ибо для использования официального надо пописать в баночку, верифицироваться через Госуслуги, а потом ещё переварить разношёрстную противоречивую документацию) грузит последовательно по одному файлу, благодаря чему порядок следования фотографий сохраняется.
Только вот рядовой пользователь себя так не спасёт, да и не обязан этим заниматься. Он просто честно скажет, что сервис дерьмовый и не будет его использовать.
PS: вот буквально свежак, как мэйлсрушечка занимается разработкой
заявление старшего вице-президента VK по медиастратегии и развитию сервисов Степана Ковальчука. «Я поставил команде [VK Видео] такой KPI: сделать принципиально новые оригинальные фичи, которые потом скопирует YouTube»
Команда сосать - из пальца. Таких товарищей надо привязывать к стулу и принудительно заставлять читать классику - а-ля "Психбольница в руках пациентов" и т.д. Потому что сперва надо думать о пользователе, а потом о том, как на нём зарабатывать.
Загрузка файла параллельными блоками глобально не решит проблему. Да, с помощью такой параллельной загрузки суммарную скорость загрузки пользователя будет “размазана” по нескольким узлам. Однако с точки зрения системы проблема хоть и сгладится, но никуда не уйдёт: всё ещё будет большое количество загрузок, у которых скорость различается, просто вместо 1 загрузки большого файла будет N загрузок “файлов” (блоков) поменьше (с пропорционально меньшей скоростью).
Решит. Ситуация следующая. У вас есть N клиентов с случайным размером файла и скоростью подключения. Каждый клиент загрузит Ki количество блоков.
Если все они будут делать это одним потоком в одну сессию http-подключения, то в зависимости от самых разных ситуаций получаем следующие эффекты:
Скорость загрузки может плавать (в один момент она 1 гбит/с, а через минуту упала до 1 мбит/с). Для интернета это норма. Сам клиент может начать использовать свой канал для других целей и т.д.;
В случае потери подключения загрузку придется начинать заново. Если на каждом ki блоке вероятность обрыва соединения Pi, и даже если она очень мала - на больших файлах получаем гарантированный разрыв соединения. Какова вероятность успешной загрузки, если требуется залить файл размером 1 ТБ, а вероятность обрыва соединения на каждый 1 мбайт равна 10^-4? Не говоря о том, что делать размер тела http терабайтом ни один админ в здравом уме не станет;
В частности это означет, что даже если мы изначально правильно разложили клиентов по кладунам, в ходе загрузки клиенты будут периодически перегружать их или недогружать;
Так как некий балансерун решает за кладуна, сможет он или нет обеспечить пользователю загрузить файл, то всегда будем получать расхождение и проблемы, вообще в коллективах людей такое называется микромеджментом. Оно никогда до добра не доводило;
Разумеется, можно доработать загрузку так, что бы файл загружался с места последней передачи, но в этом случае могут быть проблемы с целостностью данных, нужно будет где-то хранить выровненное количество записанных байт и отдавать его пользователю, сделать так, что бы пользователь мог продолжить закачку файла - реально, но пункты выше это все равно не отменит. Так же есть большие сомнения, что периодически не будут всплывать артефакты и порча данных при передаче.
Теперь берем вариант при отправке каждого блока по отдельности (отдельным http-подключением):
Каждый блок может быть отправлен повторно, разрыв соединения никак не сказывается и не дает увеличения нагрузки на сервера;
Нет ограничений на размер отправляемого файла, кроме стоимости подписки клиента. Ему нужно залить файл на 5 ТБ? Если заплатил за эту услугу, почему не предоставлять?
Если правильно подобрать размер блока, то скорость подключения клиента перестает играть роль, за счет round-robin все будут сглажены и хвосты нормального распределения нагрузки на кладуны будут меньше, почти в шпильку превратится колокол;
У клиента появляется возможность поставить загрузку файла на паузу и продолжить ее в удобное для него время;
Кладуны можно в ходе загрузки файла спокойно обновлять, перезагружать или выполнять другие задачи по техническому обеспечению, такой подход не ставит инженеров в неудобное положение и не заставляет их откладывать задачи на потом (или вы хотите потом в тех поддержке гневные тикеты о том, что некий пользователь 10 часов файл грузил, а вы ему весь прогресс отменили своими "обновлениями"?).
Ключевая фича разбиения на блоки и отправки их по отдельности именно в том, что она уравнивает клиентов с высокой скопростью передачи и низкой. Потому что ни один из них не сможет занять кладун на длительное время своим подключением.
И размер блока гарантированно сказывается на колоколе нормального распределения нагрузки на кладуны.
Доклад Ильи был именно о том, что бы нагрузка была равномерной, и моя статья была про это же.
В видео https://www.youtube.com/watch?v=e_pY0btswmk говорилось, что файл сначала попадает на сервер загрузки, а потом отправляется сразу в два ДЦ. Отправка в 2 ДЦ происходит быстро, учитывая их скорости и хорошую связность между ДЦ. Если файл слишком большой, придётся немного подождать: для финализациии 50-гигабайтного файла, например, после 100% загрузки приходилось ждать 1-1,5 мин., чтобы уже можно было работать с файлом (например, сделать публичную ссылку для него). У Яндекса дата-центры не только в МСК: https://www.tadviser.ru/index.php/Статья:Яндекс_(ИТ-инфраструктура) . Например, по "vla" и "klg" в некоторых сгенерированных ссылках на скачивание можно понять, что это явная отсылка к Владимиру и Калуге.
Тем более, грузить файл 50гб одним запросом - это моветон. В случае разбиения файла на блоки фиксированного размера - при получении сразу все будет реплицироваться на 2,3-N ДЦ и не надо будет возится с тем, что будет что-то "потрачено".
Я не говорю о том, что если в процессе загрузки файла ДЦ отвалится, можно будет продолжать загрузку в другой ДЦ как ни в чем ни бывало. Это большой плюс для любого пользака, потому что ему сразу скажут - грузи в один из этих ДЦ, мы уже сами позаботимся о репликации. Блоки в 4 МБ можно эффективно пересылать.
Делать "подождите 1,5 минуты" после загрузки файла, пока что-то куда-то реплицируется - бесполезная трата времени пользователя. Хотя скорее всего тут уже речь идет о проверке "антивирусом, ИИ и прочим".
Главная цель моей статьи была о том, что вместо ограничения скорости (пусть она и называется балансировкой), можно сделать ограничение количества запросов. Уже сколько раз людей на собесах в яндекс гоняли по поводу RPS-ограничителей. Явно могут сделать такое.
>>> бесполезная трата времени пользователя.
Не все грузят файлы такого объёма (~ 50 ГБ). К слову, в тарифе "Для работы" у них теперь максимальный размер файла до 100 ГБ. С файлами небольшого размера всё происходит быстро/мгновенно.
> Хотя скорее всего тут уже речь идет о проверке “антивирусом, ИИ и прочим”.
Ну, после загрузки через браузер там у них проверка хеша идёт на сервере загрузки (если такой файл уже есть, то отправляться потом в 2 ДЦ он не будет (дедупликация). При загрузке через программу проверка идёт ещё до загрузки (что логичнее, чтобы впустую не гонять трафик). В Облаке Mail при загрузке через браузер проверку сделали до загрузки (раньше тоже была после), в старой программе у них было так же (до), а в новой проверка уже после загрузки.
Там (в Яндекс Диске) файл вроде бы сначала попадает на сервер загрузки в МСК, потом уже оттуда, после полной загрузки, отправляется во Владимир и Калугу, например. С сервера загрузки потом удаляется.
Если есть дедупликация файлов, то не думали о том, что бы бить все так же на блоки, скажем 4мб, и уже дедуплицировать их? Коллизии хешей в случае файлов произвольной длины будут чаще, чем у фиксированного.
В этом случае пауза после загрузки или до нее будет существенно меньше. А читать файл целиком или по карте блоков (если они 4 мб) - пользак вряд ли заметит разницу. К тому же будет плюс - возможность более простой реализации версионирования файлов.
Надо будет сделать тест кстати, сравнить, насколько сильно снизит производительность чтения. По идее открытие множества файлов может негативно сказаться на производительности.
К слову, дозагрузка при обрыве соединения (после восстановления) у них есть как при загрузке через браузер, так и через программу (как и у Облака Mail). То есть заново файл не начинает загружаться. А ещё где-то кто-то в комментах писал, что они в ДЦ для файлов используют кластерные файловые системы (там как раз разбивка на блоки).
Восстановление дозагрузки будет работать только если сам клиент будет продолжать загрузку. Вроде был RFC на то, как формируется запрос в этом случае.
Ceph или аналоги - это единственный способ предоставлять доступность файлов в рамках ДЦ. Хранить на одном физическом сервере - это уже не более 0.9 доступности. Разбиение на блоки там действительно есть, но они на уровне блоков ФС, т.е. 512, 4096 байт.
Маловероятно, что кластерную ФС кто-то делает между ДЦ, скорость записи будет очень низкой же из-за (уже упоминавшеногося в коментах выше) RTT.
Я тестировал обычным отключением от интернета. После восстановления загрузка продолжалась.
>>> Хранить на одном физическом сервере - это уже не более 0.9 доступности.
>>> Маловероятно, что кластерную ФС кто-то делает между ДЦ
Там общение было в плане того, что один и тот же файл может в разное время раздаваться с разного сервера, хотя по факту на нём файла может и не быть (как раз сценарий кластерной ФС). Или фронт-серверы там меняются периодически. Найти бы ещё то обсуждение...
В целом ваш "баттл" с Ильёй Абрамовым понравился... Ждём ответку от Илюши...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
МакКладун или почему балансеруны не нужны