Logo
Proxmox Ceph private-cloud storage

Proxmox Ceph OSD oznaczony out: dlaczego recovery jest wolne i jak je przyspieszyć

Przyspieszenie recovery Ceph w Proxmox, gdy OSD jest oznaczony out i backfill PG pełza mimo dostępnej przepustowości dysków.

·
Ceph OSD padł i został oznaczony jako out. Recovery ruszyło, ale pełza z prędkością 10-50 MB/s mimo dysków NVMe zdolnych do gigabajtów na sekundę. Klaster działa w trybie zdegradowanym dłużej niż powinien. Oto jak to odblokować.

Jeśli potrzebujesz szerszego doradztwa w architekturze prywatnej chmury, zobacz naszą stronę konsulting Proxmox private cloud. Jeśli uruchamiasz Kubernetes na Proxmox, nasze case study Kubernetes na Proxmox pokrywa pełny projekt warstwy storage.

Objawy

Ceph pokazuje zdegradowane PG, a recovery jest aktywne, ale ekstremalnie wolne:

# Sprawdź health klastra
ceph health detail
# HEALTH_WARN 1 osds down; Degraded data redundancy: 847/25410 objects degraded

# Sprawdź prędkość recovery
ceph -s
# recovery: 12 MiB/s, 3 objects/s

# OSD jest oznaczony out
ceph osd tree | grep -i down
# 4   hdd  3.63000  osd.4    down  0  1.00000

# Status PG pokazuje backfilling
ceph pg stat
# 256 pgs: 241 active+clean, 15 active+recovering+degraded

Recovery powinno zakończyć się w minuty na nowoczesnym sprzęcie, ale zamiast tego trwa godzinami. Klaster pozostaje w stanie HEALTH_WARN, co oznacza, że każda kolejna awaria dysku w tym oknie grozi utratą danych.

Przyczyna

Ceph celowo ogranicza ruch recovery, żeby nie zagłodzić I/O klientów. Domyślne ustawienia są konserwatywne:

  • osd_recovery_max_active domyślnie 3 (tylko 3 równoległe operacje recovery per OSD)
  • osd_recovery_sleep domyślnie 0 (ale niektóre dystrybucje ustawiają 0.1s)
  • osd_max_backfills domyślnie 1 (tylko 1 operacja backfill per OSD jednocześnie)
  • osd_recovery_op_priority jest niższy niż priorytet operacji klienckich

Te domyślne wartości są rozsądne dla klastrów HDD pod ciężkim ruchem klienckim. Na klastrach NVMe lub SSD, albo podczas okien serwisowych z niskim ruchem klientów, są zbyt konserwatywne i wydłużają okno degradacji.

Dodatkowo domyślne wdrożenie Ceph w Proxmox dziedziczy te wartości bez dostrojenia do faktycznego sprzętu.

Rozwiązanie

Krok 1: Sprawdź obecne parametry recovery

# Sprawdź aktywne ustawienia recovery
ceph config get osd osd_recovery_max_active
ceph config get osd osd_max_backfills
ceph config get osd osd_recovery_sleep
ceph config get osd osd_recovery_op_priority

Krok 2: Tymczasowo zwiększ przepustowość recovery

Dla klastrów NVMe/SSD podczas okna serwisowego lub niskiego ruchu:

# Zwiększ liczbę równoległych operacji recovery
ceph config set osd osd_recovery_max_active 5

# Pozwól na więcej jednoczesnych backfilli
ceph config set osd osd_max_backfills 3

# Usuń sztuczny sleep między operacjami recovery
ceph config set osd osd_recovery_sleep 0

# Podnieś priorytet recovery (63 = równy z operacjami klienckimi)
ceph config set osd osd_recovery_op_priority 63

Dla klastrów HDD (niższe wartości):

ceph config set osd osd_recovery_max_active 3
ceph config set osd osd_max_backfills 2
ceph config set osd osd_recovery_sleep 0.05

Krok 3: Monitoruj postęp recovery

# Obserwuj prędkość recovery w czasie rzeczywistym
watch -n 5 'ceph -s | grep -E "recovery|degraded|misplaced"'

# Oczekiwane: prędkość recovery powinna znacząco wzrosnąć
# Klaster NVMe: 200-500 MiB/s
# Klaster SSD: 100-300 MiB/s
# Klaster HDD: 50-150 MiB/s

Krok 4: Przywróć domyślne wartości po zakończeniu recovery

Gdy klaster wróci do HEALTH_OK:

# Resetuj do bezpiecznych wartości domyślnych
ceph config rm osd osd_recovery_max_active
ceph config rm osd osd_max_backfills
ceph config rm osd osd_recovery_sleep
ceph config rm osd osd_recovery_op_priority

Krok 5: Jeśli OSD powinien wrócić online (dysk jest sprawny)

Jeśli dysk jest w porządku i OSD po prostu się wysypał tymczasowo:

# Uruchom OSD (na węźle Proxmox, gdzie się znajduje)
systemctl start ceph-osd@4

# Oznacz jako in (jeśli nie został oznaczony automatycznie)
ceph osd in osd.4

# Zweryfikuj, że dołączył
ceph osd tree | grep osd.4

Stałe dostrojenie dla klastrów NVMe:

Jeśli Twój klaster jest w pełni NVMe i chcesz szybszego recovery jako domyślną:

# Ustaw jako trwałą konfigurację (przeżywa restarty)
ceph config set osd osd_recovery_max_active 5 --force
ceph config set osd osd_max_backfills 3 --force

Lub w GUI Proxmox: Datacenter → Ceph → Configuration → OSD → ustaw parametry.

Weryfikacja

# 1. Zweryfikuj, że health klastra jest przywrócony
ceph health
# Oczekiwane: HEALTH_OK

# 2. Zweryfikuj brak zdegradowanych PG
ceph pg stat
# Oczekiwane: wszystkie PG "active+clean"

# 3. Zweryfikuj, że wszystkie OSD są up i in
ceph osd tree | grep -c "up"
# Oczekiwane: zgadza się z całkowitą liczbą OSD

# 4. Zweryfikuj, że ustawienia recovery wróciły do domyślnych
ceph config get osd osd_recovery_max_active
# Oczekiwane: 3 (domyślne)

# 5. Sprawdź brak slow requests podczas recovery
ceph daemon osd.0 perf dump | jq '.osd.op_latency.avgcount'
# Oczekiwane: brak anormalnego skoku w czasie odpowiedzi (latency) operacji klienckich

Jeśli ceph health pokazuje HEALTH_OK i wszystkie PG są active+clean, recovery jest zakończone. Klaster wrócił do pełnej redundancji.

Zdegradowany klaster Ceph jest jedną awarią dysku od utraty danych. Domyślne ograniczanie recovery wydłuża to okno ryzyka z minut do godzin na nowoczesnym sprzęcie. Dla klastrów produkcyjnych dostrojenie parametrów recovery do faktycznej wydajności dysków to różnica między 15-minutowym HEALTH_WARN a całonocnym oknem, w którym druga awaria oznacza dzwonienie do dostawcy backupów.

 

Jerzy Kopaczewski

Prowadzisz Proxmox + Ceph na produkcji?

Umów bezpłatną 30-minutową rozmowę. Projektujemy i utrzymujemy klastry Proxmox z Ceph dostrojonym do Twojego sprzętu i profilu workload.