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

ceph storage все pgs snaptrim каждую ночь тормозят виртуальные машины, Proxmox Виртуальная Среда

abzsol

Guest

18.06.2020 01:35:00

Привет, мы делаем снимки виртуальных машин каждую ночь в полночь и удаляем 16-й снимок. После удаления снимка все pgs переходят в статус snaptrim, и это длится 9-10 часов, в течение которых виртуальные машины становятся неработоспособными.
Спойлер: iostat -xd
Спойлер: ceph -s
root@pve01:~# ceph -s
cluster: id: 7ced7402-a929-461a-bd40-53f863fa46ab
health: HEALTH_OK
services:
mon: 3 демона, кворум pve02,pve03,pve01 (возраст 5 дн)
mgr: pve01(активен, с 5 дн), резервы: pve03, pve02
osd: 12 osd: 12 включены (с 5 дн), 12 в сети (с 5 дн)
data:
пулы: 1 пул, 512 pgs
объекты: 4.58M объектов, 8.2 TiB
использование: 27 TiB использовано, 15 TiB / 42 TiB доступно
pgs:
486 active+clean+snaptrim_wait
24 active+clean+snaptrim
2 active+clean+scrubbing+deep+snaptrim_wait
io: client: 3.1 MiB/s чтение, 3.6 MiB/s запись, 2.10k op/s чтение, 166 op/s запись
другие вещи: на прошлой неделе мы добавили 3 диска, по одному для каждого узла, и новые диски не GPT и имеют наибольшее использование пространства на osd. кластер был создан на версии 5.2, а последний добавленный диск — на 6.1 или 6.2.
Может это быть проблемой?

abzsol

Guest

01.12.2020 11:40:00

Привет, обновился до 6.3 и ceph 15.2.6. Та же проблема. Когда снимок удаляется, все виртуальные машины становятся неотзывчивыми, пока все pg не достигнут состояния "active+clean". Пытался использовать код: ceph tell 'osd.*' injectargs '--osd-snap-trim-sleep 3', но ничего не изменилось. Пока мы отключили снимки.

Dominic Guest	#3 0 01.12.2020 12:20:00 Максимальная задержка в 1 секунду вполне может быть источником вашей проблемы. Поэтому будет полезно поискать в логах Ceph проблемы с задержкой и обновить ваше оборудование, чтобы их избежать.

abzsol

Guest

01.12.2020 12:38:00

Привет, @Dominic, спасибо за ответ. Оборудование очень мощное, и когда оно работает нормально, проблем с производительностью нет. Проблемы начинаются только когда удаляется снимок, тогда оно зависает. Спойлер: Наша конфигурация: 3 узла: 2x Xeon® Silver 4114, 128 ГБ ОЗУ, 2x300GB SAS для ОС, 4x 3.8 ТБ SSD (Intel SSD D3-S4510), 1x 1Gbit ring0 к свитчу 1, 1x 1Gbit ring1 к свитчу 2, 2x 10GB SFP+ соединены в Active/Passive с openvswitch к свитчам 1 и 2. На этих соединениях у нас: 1 ovs мост для ceph, 1 ovs мост для виртуальных машин, 1 ovs мост для доступа к интерфейсу proxmox на 10GBIT BOND.

abzsol

Guest

07.12.2020 00:04:00

Привет, @Dominic, может, моя проблема связана с этим? https://forum.proxmox.com/threads/c...le-snaptrim-regression-on-ceph-14-2-10.74103/ Код: ceph tell osd.0 config show | grep _buffered "bluefs_buffered_io": "false" Спойлер: pveversion -v proxmox-ve: 6.3-1 (используется ядро: 5.4.73-1-pve) pve-manager: 6.3-2 (используется версия: 6.3-2/22f57405) pve-kernel-5.4: 6.3-1 pve-kernel-helper: 6.3-1 pve-kernel-5.3: 6.1-6 pve-kernel-5.0: 6.0-11 pve-kernel-5.4.73-1-pve: 5.4.73-1 pve-kernel-5.4.44-2-pve: 5.4.44-2 pve-kernel-5.4.41-1-pve: 5.4.41-1 pve-kernel-4.15: 5.4-9 pve-kernel-5.3.18-3-pve: 5.3.18-3 pve-kernel-5.3.18-2-pve: 5.3.18-2 pve-kernel-5.3.13-1-pve: 5.3.13-1 pve-kernel-5.0.21-5-pve: 5.0.21-10 pve-kernel-4.15.18-21-pve: 4.15.18-48 pve-kernel-4.15.18-9-pve: 4.15.18-30 ceph: 15.2.6-pve1 ceph-fuse: 15.2.6-pve1 corosync: 3.0.4-pve1 criu: 3.11-3 glusterfs-client: 5.5-3 ifupdown: 0.8.35+pve1 ksm-control-daemon: 1.3-1 libjs-extjs: 6.0.1-10 libknet1: 1.16-pve1 libproxmox-acme-perl: 1.0.5 libproxmox-backup-qemu0: 1.0.2-1 libpve-access-control: 6.1-3 libpve-apiclient-perl: 3.0-3 libpve-common-perl: 6.2-6 libpve-guest-common-perl: 3.1-3 libpve-http-server-perl: 3.0-6 libpve-storage-perl: 6.3-1 libqb0: 1.0.5-1 libspice-server1: 0.14.2-4~pve6+1 lvm2: 2.03.02-pve4 lxc-pve: 4.0.3-1 lxcfs: 4.0.3-pve3 novnc-pve: 1.1.0-1 openvswitch-switch: 2.12.0-1 proxmox-backup-client: 1.0.5-1 proxmox-mini-journalreader: 1.1-1 proxmox-widget-toolkit: 2.4-3 pve-cluster: 6.2-1 pve-container: 3.3-1 pve-docs: 6.3-1 pve-edk2-firmware: 2.20200531-1 pve-firewall: 4.1-3 pve-firmware: 3.1-3 pve-ha-manager: 3.1-1 pve-i18n: 2.2-2 pve-qemu-kvm: 5.1.0-7 pve-xtermjs: 4.7.0-3 qemu-server: 6.3-1 smartmontools: 7.1-pve2 spiceterm: 3.1-1 vncterm: 1.6-2 zfsutils-linux: 0.8.5-pve1 ОБНОВЛЕНИЕ: после изменения bluefs_buffered_io на true с помощью команды: ceph tell 'osd.*' injectargs '--bluefs_buffered_io true', кластер больше не зависает во время snaptrim, пробовал удалить 2 снимка возрастом 4 месяца. Виртуалки стали медленнее, но уже не зависают. Это ошибка? Если я правильно понимаю, эта проблема появилась с ceph 14.2.10 и была решена в 14.2.11 с восстановлением значения на true. Это все еще актуально для octopus? Спасибо.

Dominic

Guest

07.12.2020 11:11:00

В журнале изменений Ceph 14.2.10 вы можете увидеть, что значение параметра bluefs_buffered_io по умолчанию установлено на false. Похоже, с тех пор его не трогали. В журнале изменений Ceph Nautilus нет упоминаний о том, чтобы его снова активировали, а в исходном коде Ceph Octopus он по-прежнему установлен на false. Вы также можете использовать команду: ceph daemon osd.0 config help bluefs_buffered_io, чтобы проверить значение по умолчанию.

abzsol Guest	#7 0 07.12.2020 13:29:00 Спасибо за ваш ответ, по умолчанию стоит false. Мы разделим кластер и публичную сеть, сбросим значения на false и посмотрим, решится ли проблема.

David Herselman

Guest

11.12.2020 07:32:00

Похоже, есть желание отправить запрос на изменение, чтобы снова вернуть значение по умолчанию на 'true'. Хотя есть некоторые рабочие нагрузки, которые выигрывают от этого, будучи отключённым, большинство людей, вероятно, предпочтут снова активировать эту функцию, особенно в небольших кластерах с вращающимися элементами. Возможно, лучший способ решить эту проблему — повысить осведомлённость и позволить тем, кто управляет своими кластерами, сравнить производительность с этой опцией в включённом и отключённом состоянии...

abzsol

Guest

23.12.2020 19:50:00

Мы теперь разделили трафик VMS, публичный ceph и приватный ceph: 2x LACP 1gbit для vms, 2x 10 gbit активный/резервный для приватного ceph, 2x 10 gbit активный/резервный для публичного ceph, но проблема все еще существует. Если мы удаляем снимок, все vms становятся недоступными до завершения процесса snaptrim. iostat -xd

abzsol Guest	#10 0 26.12.2020 15:42:00 это, похоже, решилось изменением профиля питания в HPE ILO с "режима динамической экономии энергии" на "режим управления ОС" https://forum.proxmox.com/threads/s...interruptions-solved-but-want-to-share.81357/

Читают тему

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