Мы только что установили кластер из 6 серверов Proxmox, используя 3 узла в качестве хранилища Ceph и 3 узла в качестве вычислительных узлов.
У нас возникают странные и критические проблемы с производительностью и стабильностью нашего кластера.
Веб-доступ к виртуальным машинам и Proxmox имеет тенденцию зависать без видимой причины, от нескольких секунд до нескольких минут — при прямом доступе через консоль SSH, RDP или VNC.
Даже хосты Proxmox кажутся недосягаемыми, как видно из этого снимка мониторинга. Это также создает проблемы с кластером Proxmox, когда некоторые серверы не синхронизируются.
Например, при тестировании пинга между хост-узлами он будет отлично работать несколько пингов, зависать, продолжаться (без увеличения времени пинга - все еще <1 мс), снова зависать и т. д.
Изначально у нас были некоторые проблемы с производительностью, но они были устранены путем корректировки MTU сетевых карт до 9000 (улучшение чтения/записи +1300%). Теперь нам нужно сделать все это стабильным, потому что сейчас это не готово к производству.
Конфигурация оборудования
У нас есть сетевая архитектура, аналогичная описанной в официальном документе Ceph, с общедоступной сетью 1 Гбит/с и кластерной сетью 10 Гбит/с.
Те подключены к двум физическим сетевым картам для каждого из 6 серверов.
Узлы сервера хранения:
- Процессор: Xeon E-2136 (6 ядер, 12 потоков), 3,3 ГГц, Turbo 4,5 ГГц
- Оперативная память: 16 ГБ
- Место хранения:
- 2x RAID 1 256 ГБ NVMe, LVM
- системный корневой логический том: 15 ГБ (~55% свободно)
- подкачка: 7,4 ГБ
- WAL для OSD2: 80 ГБ
- Твердотельный накопитель SATA 4 ТБ (OSD1)
- Жесткий диск SATA 12 ТБ (OSD2)
- Контроллер сетевого интерфейса:
- Intel Corporation I350 Gigabit: подключение к общедоступной сети 1 Гбит/с
- Intel Corporation 82599 10 Gigabit: подключен к кластерной сети 10 Гбит/с (внутренней)
Узлы вычислительного сервера:
- Процессор: Xeon E-2136 (6 ядер, 12 потоков), 3,3 ГГц, Turbo 4,5 ГГц
- Оперативная память: 64 ГБ
- Место хранения:
- 2x RAID 1 256 ГБ SATA SSD
- системный корневой логический том: 15 ГБ (свободно ~65 %)
Программное обеспечение: (на всех 6 узлах)
- Proxmox 7.0-13, установленный поверх Debian 11
- Ceph v16.2.6, установленный с графическим интерфейсом Proxmox
- Ceph Monitor на каждом узле хранения
- Менеджер Ceph на узле хранения 1 + 3
Конфигурация Ceph
ceph.conf кластера:
[Глобальный]
auth_client_required = цефх
auth_cluster_required = цефх
auth_service_required = цефх
кластер_сеть = 192.168.0.100/30
фсид = 97637047-5283-4ae7-96f2-7009a4cfbcb1
mon_allow_pool_delete = истина
mon_host = 1.2.3.100 1.2.3.101 1.2.3.102
ms_bind_ipv4 = истина
ms_bind_ipv6 = ложь
osd_pool_default_min_size = 2
osd_pool_default_size = 3
общедоступная_сеть = 1.2.3.100/30
[клиент]
кольцо для ключей = /etc/pve/priv/$cluster.$name.keyring
[МДС]
кольцо для ключей = /var/lib/ceph/mds/ceph-$id/кольцо для ключей
[mds.asrv-pxdn-402]
хост = asrv-pxdn-402
mds в режиме ожидания для имени = pve
[mds.asrv-pxdn-403]
хост = asrv-pxdn-403
mds_standby_for_name = пве
[mon.asrv-pxdn-401]
публичный_адрес = 1.2.3.100
[mon.asrv-pxdn-402]
публичный_адрес = 1.2.3.101
[mon.asrv-pxdn-403]
публичный_адрес = 1.2.3.102
Вопросы:
- Правильна ли наша архитектура?
- Следует ли осуществлять доступ к мониторам и менеджерам Ceph через общедоступную сеть? (Что и дала нам конфигурация Proxmox по умолчанию)
- Кто-нибудь знает, откуда берутся эти помехи/нестабильности и как их исправить?
[редактировать]
- Правильно ли использовать размер пула по умолчанию, равный 3, при наличии 3 узлов хранения? Сначала я был склонен использовать 2, но не смог найти похожих примеров и решил использовать конфигурацию по умолчанию.
Замеченные проблемы
- Мы заметили, что arping каким-то образом возвращает эхо-запросы с двух MAC-адресов (общедоступного сетевого адаптера и частного сетевого адаптера), что не имеет никакого смысла, поскольку это отдельные сетевые адаптеры, связанные отдельным коммутатором.
Это может быть частью проблемы с сетью.
- Во время задачи резервного копирования на одной из виртуальных машин (резервное копирование на сервер резервного копирования Proxmox, физически удаленный) это каким-то образом влияет на кластер. ВМ застревает в режиме резервного копирования/блокировки, хотя резервное копирование, похоже, завершено должным образом (видно и доступно на сервере резервного копирования).
- С момента первой проблемы с резервным копированием Ceph пытался восстановить себя, но не смог этого сделать. Он находится в поврежденном состоянии, что указывает на отсутствие демона MDS. Тем не менее, я дважды проверяю, и на узлах хранения 2 и 3 есть работающие демоны MDS.
Он работал над восстановлением себя, пока не застрял в этом состоянии.
Вот статус:
root@storage-node-2:~# ceph -s
кластер:
идентификатор: 97637047-5283-4ae7-96f2-7009a4cfbcb1
здоровье: HEALTH_WARN
недостаточно доступных резервных демонов MDS
Медленные пульсации экранного меню на задней панели (самая длинная 10055,902 мс)
Медленные пульсации OSD на передней панели (самая длинная 10360,184 мс)
Избыточность ухудшенных данных: 141397/1524759 объектов ухудшились (9,273%), 156 страниц ухудшились, 288 страниц уменьшились
Сервисы:
пн: 3 демона, кворум asrv-pxdn-402, asrv-pxdn-401, asrv-pxdn-403 (возраст 4 мес.)
mgr: asrv-pxdn-401(активен с 16м)
mds: демоны 1/1 вверх
OSD: 6 OSD: 4 вверх (с 22ч), 4 в (с 21ч)
данные:
объемы: 1/1 здоровый
пулы: 5 пулов, 480 пг
объекты: 691,68 тыс. объектов, 2,6 ТиБ
использование: 5,2 ТиБ используется, 24 ТиБ / 29 ТиБ доступно
pgs: 141397/1524759 объектов деградировали (9,273%)
192 активных+чистых
156 активных+низкоразмерных+деградировавших
132 активные+низкорослые
[править 2]
root@storage-node-2:~# OSD-дерево ceph
ID КЛАСС ВЕС ТИП НАЗВАНИЕ СТАТУС ПЕРЕВЕС PRI-AFF
-1 43.65834 корень по умолчанию
-3 14.55278 хост asrv-pxdn-401
0 hdd 10.91409 osd.0 до 1.00000 1.00000
3 ssd 3.63869 osd.3 до 1.00000 1.00000
-5 14.55278 хост asrv-pxdn-402
1 hdd 10.91409 osd.1 до 1.00000 1.00000
4 ssd 3.63869 osd.4 до 1.00000 1.00000
-7 14.55278 хост asrv-pxdn-403
2 hdd 10.91409 osd.2 вниз 0 1.00000
5 ssd 3.63869 osd.5 вниз 0 1.00000
