Решит. Ситуация следующая. У вас есть 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 - "мы документы РФ не принимаем". Обновить приложение и подтвердить почту мало. Активность проявлять тоже мало.
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут. Организация решает не везде, но то что она дает мультипликативный эффект - да.
Все под управлением кубернетис, внутри него крутится (кроме БД, редиса и кафки). Если вы про миграцию между кубернетис кластерами, то на этот вопрос пока не могу ответить, но могу сказать, что без отключения шарда на время - перенос невозможен, за исключением случаев, когда БД/редис не мигрируют никуда. Возможно вы имели ввиду перенос сущностей между шардами?
Поддержка кафки добавлена две недели назад. Пока никак ничего не масштабируется. Конфигурация "как есть" и "что бы работало". Даже НТ не делал.
Но за вопрос про кафку спасибо, будет что изучить.
Решит. Ситуация следующая. У вас есть 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 расскажите. Там сессия закончилась - будь добр выключиться. Никаких демонов.
Для успешного запуска вируса нужно всего лишь запускаться от рута. Дальше уже дело техники.
Нельзя просто так взять и скопировать чужую 3D модель.
Да, поправил. Спасибо. Видимо при копировании потерялось