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.

Jerzy Kopaczewski ·
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 chmurowy. 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.