Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
но при условии, что у всех кладунов есть общее хранилище (например 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 часов файл грузил, а вы ему весь прогресс отменили своими "обновлениями"?).
Ключевая фича разбиения на блоки и отправки их по отдельности именно в том, что она уравнивает клиентов с высокой скопростью передачи и низкой. Потому что ни один из них не сможет занять кладун на длительное время своим подключением.
И размер блока гарантированно сказывается на колоколе нормального распределения нагрузки на кладуны.
Доклад Ильи был именно о том, что бы нагрузка была равномерной, и моя статья была про это же.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
МакКладун или почему балансеруны не нужны