Восстановление дозагрузки будет работать только если сам клиент будет продолжать загрузку. Вроде был RFC на то, как формируется запрос в этом случае.
Ceph или аналоги - это единственный способ предоставлять доступность файлов в рамках ДЦ. Хранить на одном физическом сервере - это уже не более 0.9 доступности. Разбиение на блоки там действительно есть, но они на уровне блоков ФС, т.е. 512, 4096 байт.
Маловероятно, что кластерную ФС кто-то делает между ДЦ, скорость записи будет очень низкой же из-за (уже упоминавшеногося в коментах выше) RTT.
Если есть дедупликация файлов, то не думали о том, что бы бить все так же на блоки, скажем 4мб, и уже дедуплицировать их? Коллизии хешей в случае файлов произвольной длины будут чаще, чем у фиксированного.
В этом случае пауза после загрузки или до нее будет существенно меньше. А читать файл целиком или по карте блоков (если они 4 мб) - пользак вряд ли заметит разницу. К тому же будет плюс - возможность более простой реализации версионирования файлов.
Надо будет сделать тест кстати, сравнить, насколько сильно снизит производительность чтения. По идее открытие множества файлов может негативно сказаться на производительности.
Тем более, грузить файл 50гб одним запросом - это моветон. В случае разбиения файла на блоки фиксированного размера - при получении сразу все будет реплицироваться на 2,3-N ДЦ и не надо будет возится с тем, что будет что-то "потрачено".
Я не говорю о том, что если в процессе загрузки файла ДЦ отвалится, можно будет продолжать загрузку в другой ДЦ как ни в чем ни бывало. Это большой плюс для любого пользака, потому что ему сразу скажут - грузи в один из этих ДЦ, мы уже сами позаботимся о репликации. Блоки в 4 МБ можно эффективно пересылать.
Делать "подождите 1,5 минуты" после загрузки файла, пока что-то куда-то реплицируется - бесполезная трата времени пользователя. Хотя скорее всего тут уже речь идет о проверке "антивирусом, ИИ и прочим".
Главная цель моей статьи была о том, что вместо ограничения скорости (пусть она и называется балансировкой), можно сделать ограничение количества запросов. Уже сколько раз людей на собесах в яндекс гоняли по поводу RPS-ограничителей. Явно могут сделать такое.
Решит. Ситуация следующая. У вас есть N клиентов с случайным размером файла и скоростью подключения. Каждый клиент загрузит Ki количество блоков.
Если все они будут делать это одним потоком в одну сессию http-подключения, то в зависимости от самых разных ситуаций получаем следующие эффекты:
Скорость загрузки может плавать (в один момент она 1 гбит/с, а через минуту упала до 1 мбит/с). Для интернета это норма. Сам клиент может начать использовать свой канал для других целей и т.д.;
В случае потери подключения загрузку придется начинать заново. Если на каждом ki блоке вероятность обрыва соединения Pi, и даже если она очень мала - на больших файлах получаем гарантированный разрыв соединения. Какова вероятность успешной загрузки, если требуется залить файл размером 1 ТБ, а вероятность обрыва соединения на каждый 1 мбайт равна 10^-4? Не говоря о том, что делать размер тела http терабайтом ни один админ в здравом уме не станет;
В частности это означет, что даже если мы изначально правильно разложили клиентов по кладунам, в ходе загрузки клиенты будут периодически перегружать их или недогружать;
Так как некий балансерун решает за кладуна, сможет он или нет обеспечить пользователю загрузить файл, то всегда будем получать расхождение и проблемы, вообще в коллективах людей такое называется микромеджментом. Оно никогда до добра не доводило;
Разумеется, можно доработать загрузку так, что бы файл загружался с места последней передачи, но в этом случае могут быть проблемы с целостностью данных, нужно будет где-то хранить выровненное количество записанных байт и отдавать его пользователю, сделать так, что бы пользователь мог продолжить закачку файла - реально, но пункты выше это все равно не отменит. Так же есть большие сомнения, что периодически не будут всплывать артефакты и порча данных при передаче.
Теперь берем вариант при отправке каждого блока по отдельности (отдельным http-подключением):
Каждый блок может быть отправлен повторно, разрыв соединения никак не сказывается и не дает увеличения нагрузки на сервера;
Нет ограничений на размер отправляемого файла, кроме стоимости подписки клиента. Ему нужно залить файл на 5 ТБ? Если заплатил за эту услугу, почему не предоставлять?
Если правильно подобрать размер блока, то скорость подключения клиента перестает играть роль, за счет round-robin все будут сглажены и хвосты нормального распределения нагрузки на кладуны будут меньше, почти в шпильку превратится колокол;
У клиента появляется возможность поставить загрузку файла на паузу и продолжить ее в удобное для него время;
Кладуны можно в ходе загрузки файла спокойно обновлять, перезагружать или выполнять другие задачи по техническому обеспечению, такой подход не ставит инженеров в неудобное положение и не заставляет их откладывать задачи на потом (или вы хотите потом в тех поддержке гневные тикеты о том, что некий пользователь 10 часов файл грузил, а вы ему весь прогресс отменили своими "обновлениями"?).
Ключевая фича разбиения на блоки и отправки их по отдельности именно в том, что она уравнивает клиентов с высокой скопростью передачи и низкой. Потому что ни один из них не сможет занять кладун на длительное время своим подключением.
И размер блока гарантированно сказывается на колоколе нормального распределения нагрузки на кладуны.
Доклад Ильи был именно о том, что бы нагрузка была равномерной, и моя статья была про это же.
Раз уж вы так настойчиво желаете выйти за границы ДЦ.
В случае множества ДЦ в одном регионе придется в любом случае каким-то образом выбирать конкретный для конкретного пользователя, а еще лучше и для конкретного запроса.
Заливать файл частью в один ДЦ, а другую во второй - идея плохая, так как объединять файл размером 100 ГБ+ ничего хорошего не даст. И тоже самое касается маршрутизации, если ДЦ1 перекидывает в ДЦ2 тем или иным образом запросы.
И повторюсь, даже в приведенном вами случае (кладун=ДЦ) все равно получается, что изложенное в статье имеет место быть. В докладе Ильи была информация о том, что канал кладуна - 4 гбит/с. До ДЦ явно не может быть 4 гбит/с, из чего было предположение о том, что работа в рамках одного ДЦ и статья писалась с этим пунктом. В этом случае общий сетевой диск и общая БД - это разумное решение.
Кладун всегда знает свою нагрузку, тем более что Илья и ко сделали потрясающую работу по сбору такой статистики (и они могут ее хранить и анализировать локально в ДЦ). Если по каким-то причинам кладун не может обработать запрос клиента - всегда можно отправить http-код на переотправку запроса (если речь про загрузку маленького файла или подготовку загрузки большого) и балансировщик на уровне мск переведет из-за round-robin запрос на другой ДЦ. В случае с балансерунами будет все тот же RTT 3-5 мс, что бы собрать статистику со всех ДЦ в одном месте. Решение с балансерунами плохо масштабируется, не говоря о том, что балансерун может выдать ссылку на кладуна, которого уже нет в живых.
Нет смысла перекладывать работу кладуна куда-то еще - это переусложнение и увеличение нагрузки на инфраструктуру.
Тут вы абсолютно не правы. Решение такое же будет.
В случае, если у вас есть сервера в Москве, Владивостоке и Пекине, то по хорошему ваш "disk.cloud.ru" будет указывать на разные IP адреса (во всяком случае все нормальные геораспределенные системы так проектируются), не пытаются сливать всех в один балансировщик в Москве. Т.е. у вас будут разные балансировщики в разных частях планеты, и каждый работать будет со своими "кладунами". Репликация - это отдельный процесс и он не всегда должен осуществляться, есть вообще такие законы как приземление информации и вы не можете перезаливать файлы пользователя куда-нибудь в Чили.
Репликация между локациями - это уже отдельный процесс, Илья рассказывал именно о том, как залить файл в облако. То что происходит дальше - это вообще отдельная песня =)
Проблема - нужно множество доменов шардировать не статически (через некую захардкоженную функцию, которая в будущем создаст массу проблем при изменении конфигурации), а динамически. Изначально для каждого домена был свой сервис с информацией о шардах. Поддерживать их невозможно для одного человека, для этого и был выбран путь универсализации.
И касательно решардинга, это в общем-то продолжение ответа на первый вопрос. Если коротко, то сейчас нет, но этот функционал закладывался на этапе проектирования сервиса универсального шардирования, но не реализовывался. Как раз за счет централизации конфигурации, в шардируемых сервисах можно будет добавлять поддержку миграции сущностей между шардами. Описываемый универсальный сервис - это реестр, где искать данные. В этом плане удобно, что мигрирующие сущности можно модифицировать в реестре и сообщать всем клиентам, что информация лежит в шарде А, но сейчас осуществляется переезд в Б. Сам же шард А всегда может сообщать каким-нибудь http кодом, что эта сущность переехала (не важно, инвалидацией кеша информации о шарде сущности или же через редирект). Т.е. для пользователя будет в худшем случае чуть больше время запроса на время миграции. Сейчас этим заниматься не вижу смысла. Если коротко, то вот такие есть домены:
При этом решардинг не нужен только для контрактов - потому что каждый новый контракт (считай платеж) всегда попадает в рандомный шард и горячих шардов в принципе возникнуть не может, кроме случаев, когда все они такими станут одновременно. Так что статья по этому вопросу будет, но не сейчас - есть более приоритетные задачи.
Данная доработка была необходима, так как создавала трудности для реализации фичи, которую опишу в следующей статье.
Я лишь указал, что сравнивать размер данных сырого protobuf и сжатого json - не очень актуально. А жать данные - да, это всегда вопрос утилизации проца. Но иногда бывает так, что потери в проце становятся ничтожными, в сравнении с потерями от передачи сырых данных.
Столкнулся с такой же проблемой, аккаунт уже удалили.
Если глубже почитать их документы, то если вы из РФ, то вам не дадут возможности пройти проверки из-за всяких документов и прочего. В основном касается денежных всяких вопросов, которые пройти невозможно. Это как с godaddy - "мы документы РФ не принимаем". Обновить приложение и подтвердить почту мало. Активность проявлять тоже мало.
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут. Организация решает не везде, но то что она дает мультипликативный эффект - да.
Все под управлением кубернетис, внутри него крутится (кроме БД, редиса и кафки). Если вы про миграцию между кубернетис кластерами, то на этот вопрос пока не могу ответить, но могу сказать, что без отключения шарда на время - перенос невозможен, за исключением случаев, когда БД/редис не мигрируют никуда. Возможно вы имели ввиду перенос сущностей между шардами?
Поддержка кафки добавлена две недели назад. Пока никак ничего не масштабируется. Конфигурация "как есть" и "что бы работало". Даже НТ не делал.
Но за вопрос про кафку спасибо, будет что изучить.
Восстановление дозагрузки будет работать только если сам клиент будет продолжать загрузку. Вроде был RFC на то, как формируется запрос в этом случае.
Ceph или аналоги - это единственный способ предоставлять доступность файлов в рамках ДЦ. Хранить на одном физическом сервере - это уже не более 0.9 доступности. Разбиение на блоки там действительно есть, но они на уровне блоков ФС, т.е. 512, 4096 байт.
Маловероятно, что кластерную ФС кто-то делает между ДЦ, скорость записи будет очень низкой же из-за (уже упоминавшеногося в коментах выше) RTT.
Если есть дедупликация файлов, то не думали о том, что бы бить все так же на блоки, скажем 4мб, и уже дедуплицировать их? Коллизии хешей в случае файлов произвольной длины будут чаще, чем у фиксированного.
В этом случае пауза после загрузки или до нее будет существенно меньше. А читать файл целиком или по карте блоков (если они 4 мб) - пользак вряд ли заметит разницу. К тому же будет плюс - возможность более простой реализации версионирования файлов.
Надо будет сделать тест кстати, сравнить, насколько сильно снизит производительность чтения. По идее открытие множества файлов может негативно сказаться на производительности.
Тем более, грузить файл 50гб одним запросом - это моветон. В случае разбиения файла на блоки фиксированного размера - при получении сразу все будет реплицироваться на 2,3-N ДЦ и не надо будет возится с тем, что будет что-то "потрачено".
Я не говорю о том, что если в процессе загрузки файла ДЦ отвалится, можно будет продолжать загрузку в другой ДЦ как ни в чем ни бывало. Это большой плюс для любого пользака, потому что ему сразу скажут - грузи в один из этих ДЦ, мы уже сами позаботимся о репликации. Блоки в 4 МБ можно эффективно пересылать.
Делать "подождите 1,5 минуты" после загрузки файла, пока что-то куда-то реплицируется - бесполезная трата времени пользователя. Хотя скорее всего тут уже речь идет о проверке "антивирусом, ИИ и прочим".
Главная цель моей статьи была о том, что вместо ограничения скорости (пусть она и называется балансировкой), можно сделать ограничение количества запросов. Уже сколько раз людей на собесах в яндекс гоняли по поводу RPS-ограничителей. Явно могут сделать такое.
Решит. Ситуация следующая. У вас есть N клиентов с случайным размером файла и скоростью подключения. Каждый клиент загрузит Ki количество блоков.
Если все они будут делать это одним потоком в одну сессию http-подключения, то в зависимости от самых разных ситуаций получаем следующие эффекты:
Скорость загрузки может плавать (в один момент она 1 гбит/с, а через минуту упала до 1 мбит/с). Для интернета это норма. Сам клиент может начать использовать свой канал для других целей и т.д.;
В случае потери подключения загрузку придется начинать заново. Если на каждом ki блоке вероятность обрыва соединения Pi, и даже если она очень мала - на больших файлах получаем гарантированный разрыв соединения. Какова вероятность успешной загрузки, если требуется залить файл размером 1 ТБ, а вероятность обрыва соединения на каждый 1 мбайт равна 10^-4? Не говоря о том, что делать размер тела http терабайтом ни один админ в здравом уме не станет;
В частности это означет, что даже если мы изначально правильно разложили клиентов по кладунам, в ходе загрузки клиенты будут периодически перегружать их или недогружать;
Так как некий балансерун решает за кладуна, сможет он или нет обеспечить пользователю загрузить файл, то всегда будем получать расхождение и проблемы, вообще в коллективах людей такое называется микромеджментом. Оно никогда до добра не доводило;
Разумеется, можно доработать загрузку так, что бы файл загружался с места последней передачи, но в этом случае могут быть проблемы с целостностью данных, нужно будет где-то хранить выровненное количество записанных байт и отдавать его пользователю, сделать так, что бы пользователь мог продолжить закачку файла - реально, но пункты выше это все равно не отменит. Так же есть большие сомнения, что периодически не будут всплывать артефакты и порча данных при передаче.
Теперь берем вариант при отправке каждого блока по отдельности (отдельным http-подключением):
Каждый блок может быть отправлен повторно, разрыв соединения никак не сказывается и не дает увеличения нагрузки на сервера;
Нет ограничений на размер отправляемого файла, кроме стоимости подписки клиента. Ему нужно залить файл на 5 ТБ? Если заплатил за эту услугу, почему не предоставлять?
Если правильно подобрать размер блока, то скорость подключения клиента перестает играть роль, за счет round-robin все будут сглажены и хвосты нормального распределения нагрузки на кладуны будут меньше, почти в шпильку превратится колокол;
У клиента появляется возможность поставить загрузку файла на паузу и продолжить ее в удобное для него время;
Кладуны можно в ходе загрузки файла спокойно обновлять, перезагружать или выполнять другие задачи по техническому обеспечению, такой подход не ставит инженеров в неудобное положение и не заставляет их откладывать задачи на потом (или вы хотите потом в тех поддержке гневные тикеты о том, что некий пользователь 10 часов файл грузил, а вы ему весь прогресс отменили своими "обновлениями"?).
Ключевая фича разбиения на блоки и отправки их по отдельности именно в том, что она уравнивает клиентов с высокой скопростью передачи и низкой. Потому что ни один из них не сможет занять кладун на длительное время своим подключением.
И размер блока гарантированно сказывается на колоколе нормального распределения нагрузки на кладуны.
Доклад Ильи был именно о том, что бы нагрузка была равномерной, и моя статья была про это же.
Раз уж вы так настойчиво желаете выйти за границы ДЦ.
В случае множества ДЦ в одном регионе придется в любом случае каким-то образом выбирать конкретный для конкретного пользователя, а еще лучше и для конкретного запроса.
Заливать файл частью в один ДЦ, а другую во второй - идея плохая, так как объединять файл размером 100 ГБ+ ничего хорошего не даст. И тоже самое касается маршрутизации, если ДЦ1 перекидывает в ДЦ2 тем или иным образом запросы.
И повторюсь, даже в приведенном вами случае (кладун=ДЦ) все равно получается, что изложенное в статье имеет место быть. В докладе Ильи была информация о том, что канал кладуна - 4 гбит/с. До ДЦ явно не может быть 4 гбит/с, из чего было предположение о том, что работа в рамках одного ДЦ и статья писалась с этим пунктом. В этом случае общий сетевой диск и общая БД - это разумное решение.
Кладун всегда знает свою нагрузку, тем более что Илья и ко сделали потрясающую работу по сбору такой статистики (и они могут ее хранить и анализировать локально в ДЦ). Если по каким-то причинам кладун не может обработать запрос клиента - всегда можно отправить http-код на переотправку запроса (если речь про загрузку маленького файла или подготовку загрузки большого) и балансировщик на уровне мск переведет из-за round-robin запрос на другой ДЦ. В случае с балансерунами будет все тот же RTT 3-5 мс, что бы собрать статистику со всех ДЦ в одном месте. Решение с балансерунами плохо масштабируется, не говоря о том, что балансерун может выдать ссылку на кладуна, которого уже нет в живых.
Нет смысла перекладывать работу кладуна куда-то еще - это переусложнение и увеличение нагрузки на инфраструктуру.
Все были студентами. И все учились. Как уже писал в конце - работу они проделали большую и тяжелую. Не всякий "выпускник" такое же проделает.
Это термины докладчика, а не мои =)
Для молотка - везде гвозди.
Раз уж зашла речь про геораспределенные системы.
Тут вы абсолютно не правы. Решение такое же будет.
В случае, если у вас есть сервера в Москве, Владивостоке и Пекине, то по хорошему ваш "disk.cloud.ru" будет указывать на разные IP адреса (во всяком случае все нормальные геораспределенные системы так проектируются), не пытаются сливать всех в один балансировщик в Москве. Т.е. у вас будут разные балансировщики в разных частях планеты, и каждый работать будет со своими "кладунами". Репликация - это отдельный процесс и он не всегда должен осуществляться, есть вообще такие законы как приземление информации и вы не можете перезаливать файлы пользователя куда-нибудь в Чили.
Так что минус все же ваш.
Полагаю, что вы правы =)
Спасибо за совет.
Репликация между локациями - это уже отдельный процесс, Илья рассказывал именно о том, как залить файл в облако. То что происходит дальше - это вообще отдельная песня =)
https://gitlab.com/mireapay
Проблема - нужно множество доменов шардировать не статически (через некую захардкоженную функцию, которая в будущем создаст массу проблем при изменении конфигурации), а динамически.
Изначально для каждого домена был свой сервис с информацией о шардах. Поддерживать их невозможно для одного человека, для этого и был выбран путь универсализации.
И касательно решардинга, это в общем-то продолжение ответа на первый вопрос.
Если коротко, то сейчас нет, но этот функционал закладывался на этапе проектирования сервиса универсального шардирования, но не реализовывался. Как раз за счет централизации конфигурации, в шардируемых сервисах можно будет добавлять поддержку миграции сущностей между шардами. Описываемый универсальный сервис - это реестр, где искать данные. В этом плане удобно, что мигрирующие сущности можно модифицировать в реестре и сообщать всем клиентам, что информация лежит в шарде А, но сейчас осуществляется переезд в Б. Сам же шард А всегда может сообщать каким-нибудь http кодом, что эта сущность переехала (не важно, инвалидацией кеша информации о шарде сущности или же через редирект). Т.е. для пользователя будет в худшем случае чуть больше время запроса на время миграции.
Сейчас этим заниматься не вижу смысла. Если коротко, то вот такие есть домены:
HQ-account
HQ-wallet
Node-wallet
Node-balance
Node-contract
Node-contract-history
Node-debt
При этом решардинг не нужен только для контрактов - потому что каждый новый контракт (считай платеж) всегда попадает в рандомный шард и горячих шардов в принципе возникнуть не может, кроме случаев, когда все они такими станут одновременно. Так что статья по этому вопросу будет, но не сейчас - есть более приоритетные задачи.
Данная доработка была необходима, так как создавала трудности для реализации фичи, которую опишу в следующей статье.
Я лишь указал, что сравнивать размер данных сырого protobuf и сжатого json - не очень актуально.
А жать данные - да, это всегда вопрос утилизации проца. Но иногда бывает так, что потери в проце становятся ничтожными, в сравнении с потерями от передачи сырых данных.
В общем случае бинарный формат хранения с сжатием gzip даст больше сохраненного места, чем json с сжатием.
Что мешает сжимать protobuf?
Столкнулся с такой же проблемой, аккаунт уже удалили.
Если глубже почитать их документы, то если вы из РФ, то вам не дадут возможности пройти проверки из-за всяких документов и прочего. В основном касается денежных всяких вопросов, которые пройти невозможно. Это как с godaddy - "мы документы РФ не принимаем".
Обновить приложение и подтвердить почту мало. Активность проявлять тоже мало.
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут.
Организация решает не везде, но то что она дает мультипликативный эффект - да.
<deleted>
Все под управлением кубернетис, внутри него крутится (кроме БД, редиса и кафки). Если вы про миграцию между кубернетис кластерами, то на этот вопрос пока не могу ответить, но могу сказать, что без отключения шарда на время - перенос невозможен, за исключением случаев, когда БД/редис не мигрируют никуда. Возможно вы имели ввиду перенос сущностей между шардами?
Поддержка кафки добавлена две недели назад. Пока никак ничего не масштабируется. Конфигурация "как есть" и "что бы работало". Даже НТ не делал.
Но за вопрос про кафку спасибо, будет что изучить.
Про демонов вы еще CI/CD расскажите. Там сессия закончилась - будь добр выключиться. Никаких демонов.