Обновить
8K+
5
Alexander Pivkin@Running_thru

Пользователь

13,1
Рейтинг
1
Подписчики
Отправить сообщение

Какой живой камент! Постараюсь ответить на каждый тейк

Заголовок обещает «как тестируем Ceph в MWS Cloud Platform». Но статья этого не даёт. Нет ни одного реального примера из продакшена:

Действительно, ретроспективно оценивая статью, как будто бы видно несовпаления в обещании и содержании. Прошу не судить строго, это моя первая статья и обязательно учту это в будущем.

А бывает что дружит, представляете(?) — и на HDDs IOPS'ы поднимает зачастую заметно больше, чем несчастный IOMMU.

Вот этот момент очень интересный, потому что я никогда, вот прям буквально никогда не встречал такого, чтобы аппаратный раид контроллер хоть как то бы ускорял цеф. И что я только ни делал - ни уменьшение/увеличение кеша, ни уменшьение/увеличение таймера сброса кеша - ничего из этого не оказывало чудодейственного влияния. Поделитесь, пожалуйста, на каких случаях кнтроллер может заметно поднять иопсы?

«Распределённая система с сетевой репликацией требует сети по полной» — от-оно-чо. Полезнее хотя бы примерно так: «на NVMe-кластерах 10GbE становится бутылочным горлышком раньше дисков уже при умеренной записи — пример:». А «прожорлив» — это из лексикона статьи в корпоративном блоге, где нельзя писать конкретику, потому что её нет.

Ну это же введение вроде как было, для общего погружения тех, кто не знаком и напоминания тем, кто знаком) Кстати, прежде 10Гб сети, скорее упор в ЦПУ произойдёт, при должном упорстве.

Ещё раз благодарю за живой комментарий!)

Мой опыт говорит о том, что lazy режим (когда iommu.strict=0) процентов эдак на 5-10% повышает максимальные иопсы просто вследствие того, что не приходится каждый раз обновлять кеш, хранящий сопоставление виртуальных адресов к физическим. Но это я замечал только на скоростных кластерах с твердотельными дисками.

Однако, повторюсь, что своими руками тестил разные кластера с различными ЦПУ, где на одном включение iommu моментально вызывало спинлоки на ОСД, а на другой модели ЦПУ кластер выдывал скорости, захватывающие дух.

На кластерах же с хдд это прям совсем незаметная настройка, потому что всё упирается в блины. На блинах разве что кеши ЛВМ крутить.

конечно могу! Включаем - тестируем, выключаем - тестируем, сравниваем результаты. Ещё и на батчевание TLB кеша iommu.strict рекомендовал бы обратить внимание

Я это делаю на регулярной основе) К примеру, включать iommu или нет? Выяснилось, что это зависит от процессора. Воочию наблюдал, как включение этой опции драматически поднимало и пропускную способность кластера и максимальные иопсы, хотя в интернетах восновном рекомендуют её выключать просто потому что.

Osdbench на этапе тестирования помогает найти ту, что тормозит весь кластер. А если кластер большой, то без этой утилиты поиск превращается в забег по всем нодам в поисках чего нибудь необычного либо в логах, либо в иостате, либо ещё где.

Так что на общий вопрос "удалось ли найти и починить что-то", с уверенностью могу ответить, что что-то найти и починить удалось)

Классическая статья Виталия, заслуженно снискавшая популярность! Полагаю, что вы спрашиваете именно моё мнение, а не нагугленные за и против?
Лично я выступаю за хостовую установку цефа только в одном случае - когда вот прям точно надо выжать абсолютный максимум из высокоскоростного оборудования, а именно из твердотельных дисков. Контейнеры имеют, хоть и не большие, но всё-таки сопутствующие накладные расходы.

Ну а в остальном, что цефадм, что рук в кубернетесе - это скорее про удобство управления, именно управления кластером. Даже не смотря на то, что придётся по ходу дела овладеть тонкостями сопутствующих технологий и, скорее всего, слегка изменить подход к отлову ошибок.

Информация

В рейтинге
572-й
Зарегистрирован
Активность

Специализация

Системный администратор, DevOps-инженер
Средний
От 100 500 ₽
Linux
Английский язык
CI/CD
Высоконагруженные системы