+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблемы с производительностью Ceph, Proxmox Виртуальная Среда

troycarpenter

Guest

10.12.2018 23:05:00

Всем привет, я уже несколько лет использую Proxmox и теперь у меня есть кластер из 13 узлов, в который я добавил Ceph в прошлом году (после обновления до версии 5.2), используя свободные места для дисков в некоторых узлах Proxmox. В прошлую пятницу я обновил все узлы до версии 5.3. Система Ceph всегда казалась медленной, и я никогда действительно не понимал, что должны означать цифры по чтению/записи/IOPS относительно производительности кластера. Теперь я начинаю регулярно видеть сообщения о заблокированных медленных запросах, но меня беспокоит то, что, когда это случается, количество заблокированных запросов иногда поднимается до 2000, прежде чем вернуться к нулю (что означает, что предупреждающее сообщение исчезает). А сегодня это, похоже, вышло из-под контроля и добралось до 7000, и дело не только в медленных запросах, но и в [чем-то более плохом, чем медленные запросы]. После около 30 минут все снова пришло в норму. У меня три сервера, на каждом из которых размещено по 5 OSD по 5 ТБ, и три других сервера с 3 OSD по 4 ТБ. Все узлы имеют выделенную сеть 10G для трафика Ceph. По тесту iperf сеть, похоже, работает на полной скорости (с MTU 9000). На всех узлах у меня около 60 гостевых виртуальных машин, которые используют систему Ceph в качестве хранилища образов дисков. Я не хочу углубляться в детали своей конфигурации, чтобы не углубляться в «кроличьи норы», и стараюсь придерживаться хороших методов устранения неполадок по этой проблеме, но если есть что-то важное, я могу ответить на вопросы. Что я могу мониторить, чтобы диагностировать эту проблему? Что еще мне нужно учесть? Я не нашел хорошей документации с конкретными шагами по устранению неполадок, только множество записей, касающихся конкретных проблем, обычно заканчивающихся фразой «Я исправил это перезагрузкой сервера». Спасибо. Трой

troycarpenter Guest	#2 0 23.01.2019 20:17:00 Потому что вся документация говорит, что всё, что ниже уровня корпоративных SSD, будет разочарованием. Согласен, у менеджеров по продукту хорошая ценовая политика.

sb-jw Guest	#3 0 23.01.2019 21:51:00 Конечно, почему бы тебе не купить PM883 вместо старых?

troycarpenter

Guest

18.01.2019 21:37:00

Спасибо за информацию и большое сообщение для обсуждения. Было бы здорово, если бы существовал краткий справочник по устранению неполадок в Ceph, особенно что проверять в каком порядке. Например, как проверить сеть Ceph, OSD и производительность физического оборудования. Как читать информацию на панели управления (Чтения/Записи/IOPS), чтобы понять, что означают цифры и сообщает ли они мне что-то полезное. В этой системе всего 6 узлов Ceph, разделенных на две группы. Первая группа из трех узлов имеет почти одинаковое оборудование и хостит OSD с 9 по 26: Код: использование ЦП 2.39% из 24 ЦП(а) задержка ввода-вывода 20.83% использование ОЗУ 32.74% (41.15 GiB из 125.70 GiB) ЦП(ы) 24 x Intel® Xeon® CPU E5-2650 v4 @ 2.20GHz (1 сокет) Версия ядра Linux 4.15.18-9-pve #1 SMP PVE 4.15.18-30 (Чт, 15 Ноя 2018 13:32:46 +0100) Версия PVE Manager pve-manager/5.3-5/97ae681d Система загрузки (/dev/sda) Intel S3510 SSD Ceph DB (/dev/sdb) Intel S3510 SSD Диски Ceph, всего 5 в корпусе ST5000LM000-2AN170 (плохой выбор, оглядываясь назад) Каждый узел также запускает различные ВМ. Вторая группа из трех узлов хостит OSD с 0 по 8: Код: использование ЦП 2.39% из 12 ЦП(а) задержка ввода-вывода 12.67% использование ОЗУ 40.74% (25.31 GiB из 62.66 GiB) ЦП(ы) 12 x Intel® Xeon® CPU E5-2620 v3 @ 2.40GHz (1 сокет) Версия ядра Linux 4.15.18-9-pve #1 SMP PVE 4.15.18-30 (Чт, 15 Ноя 2018 13:32:46 +0100) Версия PVE Manager pve-manager/5.3-5/97ae681d Система загрузки (/dev/sda) HP spinner У ДИСКА ЖУРНАЛА Ceph НЕТ!!! (Я знаю, это плохо, и хочу, чтобы вы это видели) Диски Ceph, всего 3 в корпусе WDC-WD40EFRX Каждый узел также запускает различные ВМ. Моя первоначальная мысль — заменить WD REDS во второй группе на SM863a MZ-7KM1T9N SSD и вести журнал непосредственно на SSD. Однако, учитывая цену более 6 тысяч долларов за диски, я хочу удостовериться, что exhaustively попытался разобраться в проблеме и помогут ли эти диски в чем-то. У трех серверов всего по 4 отсека для дисков, так что у меня нет места для отдельного диска журналы. Я также не нашел убедительных рекомендаций по настройке KRBD в настройках хранилища. Когда он был активирован, ВМ работали медленнее, но количество ошибок медленных запросов снизилось почти до нуля. Удаление настройки сделало загрузку на некоторых ВМ быстрее, но число медленных запросов теперь регулярно колеблется, как показано ниже. У меня есть один вопрос...может ли проблема с производительностью одного OSD вызвать накопление запросов на других OSD? Например: Код: 2019-01-18 12:38:01.742550 mon.gatimaan [INF] Кластер теперь в порядке 2019-01-18 12:38:12.810271 mon.gatimaan [WRN] Проверка состояния не удалась: 49 медленных запросов заблокированы > 32 сек. Вовлеченные osd 23 (REQUEST_SLOW) 2019-01-18 12:38:18.053586 mon.gatimaan [WRN] Обновление проверки состояния: 121 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,15,20,23 (REQUEST_SLOW) 2019-01-18 12:38:23.303980 mon.gatimaan [WRN] Обновление проверки состояния: 202 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,5,8,10,11,12,13,15,20,23 (REQUEST_SLOW) 2019-01-18 12:38:28.304355 mon.gatimaan [WRN] Обновление проверки состояния: 258 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,5,6,8,10,11,12,13,14,15,20,23 (REQUEST_SLOW) 2019-01-18 12:38:33.304687 mon.gatimaan [WRN] Обновление проверки состояния: 362 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,5,6,8,9,10,11,12,13,14,15,16,18,19,20,23 (REQUEST_SLOW) 2019-01-18 12:38:38.305054 mon.gatimaan [WRN] Обновление проверки состояния: 413 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,3,5,6,8,9,10,11,12,15,16,18,19,20,23 (REQUEST_SLOW) 2019-01-18 12:38:43.305326 mon.gatimaan [WRN] Обновление проверки состояния: 374 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,5,6,8,10,11,12,13,16,17,19,20,23 (REQUEST_SLOW) 2019-01-18 12:38:48.305643 mon.gatimaan [WRN] Обновление проверки состояния: 328 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,5,6,10,11,12,16,19,20,23 (REQUEST_SLOW) 2019-01-18 12:38:53.305995 mon.gatimaan [WRN] Обновление проверки состояния: 270 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,5,10,11,12,20,23 (REQUEST_SLOW) 2019-01-18 12:38:57.285793 mon.gatimaan [INF] Проверка состояния очищена: REQUEST_SLOW (было: 252 медленных запросов заблокированы > 32 сек. Вовлеченные osd 0,10,11,12,20,23) 2019-01-18 12:38:57.285814 mon.gatimaan [INF] Кластер теперь в порядке Где OSD 20 и 23 часто встречаются в этом инциденте.

sb-jw Guest	#5 0 19.01.2019 11:26:00 Почему бы не взять PM883 (вместо SM)? Они сейчас очень дешевые и имеют TBW 1,4PB. Так что PM/SM863a — это старая модель.

AlexLup Guest	#6 0 21.01.2019 13:24:00 Одна из техник заключается в том, чтобы остановить OSD 20 и 23 на некоторое время и посмотреть, будут ли какие-либо проблемы после этого. Затем можно снова включить их, чтобы выяснить, какой OSD является виновником. Я также бы заглянул на почтовую рассылку Ceph с логами (часто там требуется, чтобы логирование OSD было настроено на 20), чтобы получить помощь экспертов! У самого меня Ceph установлен на куче старых HDD с аналогичными проблемами, но меня это устраивает, так как была внедрена кэш-уровневая системы.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры