географически распределенных объектных хранилищ (например, на MinIO), которые, по своей сути, выступали-бы в качестве CDN (Content Delivery Network)?
Или отправьте меня в нужном направлении, что еще почитать и изучить по этой теме.
На данном этапе цель выглядит, как "снизить время загрузки данных клиентом, обеспечить синхронизацию/репликацию данных между объектовыми хранилищами, иметь возможность горизонтального масштабирования". Объем данных для загрузки от нескольких килобайт, до нескольких гигабайт. Сейчас в основном клиенты (имеется ввиду клиентское приложение) на территории РФ, но постепенно в СНГ появляются и далее везде.
Попробуйте тут спросить https://t.me/sds_ru Но вообще, требования обозначьте. Вариантов море, начиная с rsync, afs, gfs, и до web3 файловых систем.
Вариантов немного 1. Geo DNS https://github.com/abh/geodns 2. Anycast https://www.imperva.com/learn/performance/anycast/ 3. Выбор самого быстрого сервера на стороне клиента
Но это больше про latency. Скорость загрузки чаще не зависит от latency напрямую. Для скорости вам нужен широкий канал вплоть до клиента. Измерять можно iperf3, нужно запускать на обеих сторонах
Под "увеличить скорость загрузки" подразумевается в большей степени избавление от "бутылочного горлышка" в виде единственного хранилища данных, которые загружаются клиентами. Какой-бы ни был широкий канал у хостера в ДЦ, он обязательно утилизируется на все 100% в какие-то моменты времени. Потому что данные, которые скачивают клиенты, разделяются на разные классы/категории. Какие-то данные клиенты качают/получают часто, какие-то редко, а какие-то данные имеют определенный период жизни (актуальности) и с определенной периодичностью должны быть обновлены клиентами. Вот по поводу последней категории данных как раз и есть опасения, что они в один прекрасный момент утилизируют весь канал в ДЦ. Поэтому и задумались уже сейчас о том, как постараться этого избежать. Тем более, что там речь про сотни мегабайт. А заодно и разнести географически хранилища с этими данными, чтобы не гонять их по всем сетям с одного конца страны в другой. И держим в уме, что клиенты начнут появляться в странах СНГ точно.
Я как хобби держу зеркало open source проектов. У меня пока один сервер и он отдает около 70ТБ в месяц. У него 10 Гбит сетевой интерфейс, 770 ГБ RAM, 8 ТБ NVME и около 80ТБ HDD. На всё потратил около 3000 баксов, сам сервер обходится в 120 баксов на колокейшене
Тут нюанс в том, что есть данные, которые обновляются с определенной периодичностью. И они весят несколько сотен мегабайт. При наступлении этого момента (когда пользователи должны скачать новые данные), канал может утилизироваться полностью, что повлечет снижение скорости доступа к другим сервисам.
$120 с каналом 10Гигабит наружу?
Ну у меня та же ситуация. У меня зеркало обновлений arch Linux, Kali, и тд, причем официальные. И как показала практика, у всех моих юзеров в моей зоне плохой интернет
Да! :) я измерял
Можно в личку, что за хостер. Будем иметь ввиду.
Железо бу? Чёт цена раз в 20 ниже корпоративной
HP dl380p gen8, память DDR3 хз сколько плашек, уже забыл, но он весь полный. Всё б/у кроме nvme и половины хард дисков 2 процессора E5-2660, по 8 ядер каждый
Возвращаясь к вариантам. 1 и 2 известны и понятны. А вот по 3 варианту какие-то есть примеры?
Он самый. Я в своем первом сообщении (https://t.me/devops_ru/1058559) о нем и упомянул.
Капец чёт супер дешман всё равно
Да просто брал всех хостеров из peeringdb и Google и писал им, только один дал нормальную цену
Почему? Сервер+процы+память $200, а все остальное - диски. ))
700гб оперативы за 200 баков???
Сам сервер я купил за 800 баксов. Это норм цена для этой модели. Там уже было 2 процессора и 64ГБ оперативы + 12 LFF caddy Всю память поменял где-то за 400 баксов, чтобы было максимум. Затем постепенно добавлял диски, как приходила зп 😅
Так там DDR3. Ее китайцы ведрами на Алике продают. ))
На стороне клиента, в JS, или на бэкенде, сделать логику, которая направляет клиента на нужный сервер по определенным критериям, исходя из его IP. См. MirrorBrain
24 плашки по 32ГБ.
Вот за это мерси. Вероятно, это самый лучший вариант для нас, т.к. доступ к данным пользователь получает только через авторизацию. А это идет через бэк.
Обсуждают сегодня