Comments 16
Вопрос: вы аккумуляторы и генераторы в ЦОД давно проверяли? Был опыт, у РТК в ЦОД по TIER3 упало питание. Не завелись ни аккумы, ни генераторы.
В каком ЦОДе упало? Обычная практика датацентров это запуск ДГУ раз в месяц/квартал
Именно поэтому для нас критично, что мы работаем на собственных площадках и сами контролируем инженерную инфраструктуру ЦОД от электроснабжения до регламентов эксплуатации. Это позволяет минимизировать зависимость от сторонних подрядчиков и быстрее реагировать на любые отклонения.
В индустрии давно считается лучшей практикой регулярно проводить тестирование аварийных сценариев.
Мое личное мнение - Абсолютно «непадающих» систем в мире не существует, SLA 100% это миф. Но именно постоянные испытания аварийных сценариев, эксплуатационная дисциплина и контроль собственной инфраструктуры позволяют существенно снижать вероятность подобных инцидентов.
Кейс 2: Data Lakehouse и горячее хранилище на 1 ПБ
для столь небольшого объема данных при довольно высокой нагрузке мы решили использовать NVMe-накопители, а в качестве алгоритма защиты данных — трехкратную репликацию (RFx3). Тесты профиля нагрузки заказчика показали, что Erasure Coding в данном случае не подходит. Причина — более медленные операции записи и чтения файлов
Интересно, о каком порядке латенси здесь идет речь? 200К рпс на 200 гигабит это работа объектами в сотни килобайт. На таких профилях нагрузки в случае ssd не удивлюсь, если львиная доля латенси идет даже не со стораджа, а с вашей мета базы.
Уровень 3 — Proxy Layer
Не становится узким местом у вас? Прокачивать весь траф через L7 (похоже, судя по слову 'кэширование') проксю? DSR не используете для отдачи трафа с меньшим количеством хопов?
Вообще в целом интересно было бы послушать, как у вас происходит эволюция требований в мире нагрузки для ML/AI. Трафик в сотни гигабит уже очень мало. Снимать с петабайта nvme дисков (особенно с mirror-3) можно уже 1-2 терабита, а то и больше.
Про латенси: В подобных архитектурах, да и вообще в индустрии промышленных S3-хранения latency практически никогда не определяться самими накопителями. В промышленных S3, по моему опыту, существенный вклад начинают вносить: сетевой стек, согласование реплик, распределение объектов и балансировка траифка, очереди и взаимодействие между компонентами системы - в общем решает архитектура решения.
Чуть подробнее про латенси и разные способы хранения данных я както описывал в этой статье https://habr.com/ru/companies/selectel/articles/987304/
Мое мнение кратко, S3 это просто один из инструментов хранения данных. Если вы инженер то нужно разбираться как в теоретических ТТХ выбранного вами инструмента, так и проводить его тестирование под ваш профиль нагрузки.
И если для вас важен супер низкий латенси, вам не нужен S3, посмотрите на хранилища выше по "пирамиде памяти".
В целом еще раз соглашусь с вами: тип диска это далеко не самое узкое место в сложных системах.
Про proxy layer: изначально он проектировался как горизонтально масштабируемый, аппаратно изолированный stateless-слой. Соответственно, масштабирование довольно легко происходит добавлением узлов. Плюс часть нагрузки снимается за счет внутренних механизмов балансировки запросов и кэширования данных.
Дополнительно, для наших клиентов у нас есть интеграция с CDN. Что позволяет: выносить значительную часть нагрузки ближе к edge.
proxy layer: изначально он проектировался как горизонтально масштабируемый, аппаратно изолированный stateless-слой.
А как он stateless если там кэш? А пермиссии он проверяет?
Ну я разумеется не имел ввиду что вообще нчиего не хранит в памяти. Речь скорее о том, что узел не хранит критичное долговременное состояние. Данные без котороых система не сможет продолжить работу.
Если нода в этом слое перезапустится то: данные, сессии и прова не потеряются. Любая другая нода слоя сможет спокойно подхватить работу и отработать эти запросы.
И если для вас важен супер низкий латенси, вам не нужен S3, посмотрите на хранилища выше по "пирамиде памяти".
я бы сказал, что это утверждение спорное, но чтобы спорить нужно все-таки иметь какую-то точку отсчета. Например, для для (распределенных) файловых систем ожидаются латенси ниже 1мс (сотни миросекунд у лидеров на рынке). Для S3 требования к латенси чуть более расслабленные. Средний пользователь aws s3 не ожидает латенси даже в десятки мс. Но это ровно до тех пор, пока ему интересен просто S3. Если мы начинаем подходить к действительно высоким нагрузкам, то ситуация резко меняется. Разница между 5ms на мегабайт против 50ms плоха даже не сама по себе - у клиентов S3 обычно батчевая нагрузка, которая закидывается бОльшей параллельностью. Но в какой-то момент повышать параллельность становится проблематичным: больше коннектов требуют больше ресурсов - если у вас клиент на питонячем boto3, то большое количество коннектов начнет заедать слишком много ресурсов и вы не сможете прокачать свою ноду/GPU целиком.
Да, тут можно много говорить о том, что в таких случаях нужно кэшировать на клиенте и будете правы в каком-то смысле. Но если вы продаете не только S3, но еще и компьют рядом, вам будет очень не сруки, если клиенты не смогут прокачать продаваемые им 400Г ноды.
Соответственно, масштабирование довольно легко происходит добавлением узлов.
Легко ровно до того момента, пока не надо считать влияние x2 нод на маржинальность. Опять же, это сильно зависит от объема трафика. Если речь про условный терабит/сек, то проблемы нет. Если же продавать быстрый тир на ssd, то каждая точка, через которую проходит трафик, добавляет буквально количество нод равное количеству стораджовых нод. В вашей архитектуре таких точек получается как минимум две. То есть на каждую стораджовую ноду с флеш-дисками, вам придется закладывать одну DPL ноду и одну проксю. В идеале промежуточных точек между клиентом и диском должно быть ровно ноль, но это уже разговор про что-нибудь вроде rdma или client-side 'proxy'
Сейчас вы скажете магические слова "коммерческая тайна", но всё-же - раз сказали "А", то скажите и "Б" - какова стоимость хранения выходит для клиентов в кейсах 1 и 2 за гигабайт в месяц? Насколько ваше решение конкурентоспособно по сравнению с тем же S3 Яндекса?
Здесь многое зависит от профиля нагрузки и модели доступа к данным.
Если сильно упростить, то в объектном хранилище стоимость складывается не только из «цены за гиабайт», но и из:
- объема самих данных;
- количества запросов;
- исходящего трафика;
- требований к отказоустойчивости и георезервированию;
- класса хранения («горячее»/«холодное»).
Поэтому два клиента с одинаковым объемом в 1 ПБ могут иметь очень разную итоговую экономику.
Если говорить про конкурентоспособность, мы регулярно сравниваем себя с крупными облачными S3-провайдерами. Собственная инфраструктура и приложение, собственные ЦОД и компетенции позволяют нам держать очень конкурентную экономику. Вы можете убедиться в этом по ссылке https://selectel.ru/prices/
Судя по описанию сервера - вы не используете db/wal разделы на ssd/nvme для osd.
Так ли это?
Если используете, то как решается проблема выхода из строя ssd/nvme на таких больших (по количеству дисков) серверах?
Спасибо за интерес к статье! Сегодня я сознательно не уходил глубоко в детали конкретных OSD-конфигураций, поэтому некоторые моменты действительно остались «за кадром». Это часть нашего ноу-хау.
Однако вопрос то абсолютно правильный. Проблема тут в том, что при большом количестве дисков отказ одного такого SSD может потенциально затронуть сразу группу OSD, а значит привести к массвому восстановлению данных и дополнительной нагрузке на кластер.
Для части сценариев размещение служебных данных непосредственно рядом с основными данными может быть оправдано с точки зрения простоты эксплуатации и стоимости. Для других нет. То есть универсальной схемы здесь нет. И это всегда про баланс между производительностью, стоимостью, отказоустойчивостью, расходами и сложностью эксплуатации.
Спасибо за вопрос!
Пишите в комментариях, какую часть архитектуры — шардинг метдаданных в oss на базе PostgreSQL, настройку балансировки запросов на proxy-layer или тюнинг Ceph — разобрать в следующей статье.
Спасибо за статью, голосую за последнее!
У вас ceph кластер растянут на несколько az или всегда внутри одной?
А вы проводили нагрузочное тестирование системы перед вводом в эксплуатацию? Интересно узнать, какой бенчмарк использовался и какие цифры удалось получить в пересчете на один хост.
Какое фактическое время восстановления избыточности при выходе из строя одного 20TB диска? Использование EC8+2 выглядит достаточно рискованным при 8 тысячах дисков (в примере №1 на 120PB).
Как мы в Selectel строим S3-хранилища: от железа до приложения