ZFS i Ceph w Proxmox: wybór storage, RAM i copy-on-write

Czym są ZFS i Ceph w Proxmox

Proxmox VE (Virtual Environment) uruchamia maszyny wirtualne i kontenery. Każda VM (Virtual Machine) widzi własny dysk, ale jej dane muszą gdzieś fizycznie leżeć. W tym artykule porównujemy dwa częste warianty: lokalny storage ZFS na hoście oraz rozproszony storage Ceph dla klastra.

ZFS łączy system plików i zarządzanie urządzeniami blokowymi. Tworzymy z nich pulę (storage pool), a w niej datasety i woluminy. W Proxmox backend zfspool wykorzystuje lokalną pulę ZFS danego hosta. Dysk VM jest wtedy zvolem w formacie raw, a nie plikiem qcow2. Pula może mieć mirror lub RAIDZ, więc może przetrwać awarię określonych dysków. Nie staje się przez to dostępna z innych hostów po awarii całego serwera.

Ceph buduje jeden rozproszony storage z dysków kilku serwerów. W Proxmox zwykle używamy RBD (RADOS Block Device), czyli dysku blokowego Ceph dla VM. VM widzi jeden dysk, lecz Ceph dzieli jego dane na obiekty, rozmieszcza je na dyskach wielu hostów i utrzymuje wymaganą liczbę kopii. Host uruchamiający VM może się zmienić, a dysk RBD pozostaje w tym samym klastrze Ceph.

To nie są zamienne nazwy tej samej funkcji. Backend zfspool udostępnia lokalną pulę ZFS jednego hosta; nie daje równoczesnego wspólnego dostępu z innych hostów. Ceph zarządza rozmieszczeniem danych między hostami. Zewnętrzna macierz lub serwer NFS/iSCSI może również dać Proxmox wspólny storage, ale jest to trzeci wariant architektury, z własną domeną awarii. Nie omawiamy tu jego szczegółowego projektu.

Jak ZFS przechowuje dyski VM

Na hoście z pulą tank dodajemy ją w Proxmox jako storage typu ZFS, na przykład pod ID local-zfs. Gdy VM korzysta z tego storage, Proxmox tworzy dla jej dysku zvol w puli. QEMU przekazuje do niego I/O VM, a ZFS zapisuje dane na dyskach należących do puli.

To prosty model dla jednego hosta lub małego środowiska, w którym lokalna wydajność, snapshoty i kontrola nad własnymi dyskami są ważniejsze niż wspólny dostęp z każdego węzła. Nazwa local-zfs może występować w konfiguracji całego klastra Proxmox, lecz na każdym hoście wskazuje fizycznie inną pulę. Taka wspólna nazwa nie scala danych.

Sumy kontrolne ZFS pozwalają wykrywać uszkodzenia danych. Naprawa wymaga jednak poprawnej kopii, na przykład w mirrorze lub RAIDZ. Sam ZFS nie jest backupem i nie zapewnia automatycznie dostępu do dysku VM po utracie hosta.

Podstawową pulę tworzymy w panelu na węźle Proxmox, który ma ją hostować, w sekcji Disks → ZFS, a następnie udostępniamy ją Proxmox jako storage typu ZFS. Wybór dysków podczas tworzenia puli niszczy ich dotychczasową zawartość. Przed tą operacją weryfikujemy fizyczne oznaczenia urządzeń i zachowujemy działającą drogę odtworzenia VM.

Jak Ceph RBD przechowuje dyski VM

W klastrze Ceph dyski przeznaczone dla storage obsługują procesy OSD. Obraz RBD dysku VM jest dzielony na obiekty. Gdy VM zapisuje blok, klient RBD oblicza, do którego obiektu należy ten fragment, a algorytm CRUSH (Controlled Replication Under Scalable Hashing) wyznacza OSD, które mają przechowywać jego kopie. OSD zapisują dane i potwierdzają operację zgodnie z konfiguracją puli.

Monitory Ceph dostarczają klientom aktualną mapę klastra, ale nie przenoszą przez siebie wszystkich zapisów VM. Dzięki temu RBD nie ma jednego centralnego serwera obsługującego każdy dysk. Po migracji VM na inny host docelowy QEMU korzysta z tego samego obrazu RBD; nie kopiujemy całej zawartości dysku tylko dlatego, że zmienił się host uruchamiający VM.

Odporność Ceph zależy od projektu, a nie od samej nazwy produktu. Liczą się między innymi liczba kopii w puli, reguły CRUSH, niezależność dysków i hostów, stan sieci, quorum monitorów oraz wolna pojemność potrzebna do odbudowy. Trzy niezależne hosty są rozsądnym punktem startowym dla środowiska, które ma przetrwać awarię jednego hosta, ale nie są automatyczną gwarancją dostępności.

Dyski OSD przeznaczamy wyłącznie dla Ceph. Nie tworzymy na tym samym urządzeniu lokalnej puli ZFS ani nie dodajemy go równocześnie do innego storage. W panelu Proxmox utworzenie OSD lub puli jest operacją administracyjną o skutkach dla danych, więc zaczynamy od planu hostów, sieci, pojemności i backupu, a nie od kliknięcia kreatora.

Kiedy wybrać lokalny ZFS, Ceph lub zewnętrzny storage

Nie ma jednego domyślnego wyboru dla każdego klastra. Najpierw określamy, czy potrzebujemy lokalnego storage, wspólnego dostępu do dysku VM, czy odporności na awarię hosta. Dopiero później wybieramy technologię.

Wspólny storage to tylko jeden element dostępności. Nawet przy RBD lub macierzy restart po awarii hosta nie przywraca RAM VM ani otwartych połączeń. Do uruchomienia VM na innym hoście potrzebne są także zasoby obliczeniowe, sieć i poprawnie skonfigurowane HA.

Podstawy zarządzania i diagnostyki

W powłoce root hosta Proxmox wykonujemy najpierw poniższe polecenia. Nie zmieniają konfiguracji; pokazują wyłącznie aktualny stan. Dla lokalnego ZFS są to:

pvesm status
zpool status -v
zpool list
zfs list -o name,type,used,avail,refer,mountpoint

pvesm status pokazuje storage skonfigurowany w Proxmox. W zpool status -v oczekujemy stanu ONLINE oraz braku błędów odczytu, zapisu i sum kontrolnych. zpool list pokazuje stan całej puli, a zfs list pozwala ocenić przestrzeń dostępną konkretnym datasetom i zvolom. Nie utożsamiamy wolnego miejsca widocznego w zpool z miejscem, które rzeczywiście może jeszcze otrzymać VM: znaczenie mają też rezerwacje, snapshoty i właściwość available danego zvola.

Na hoście należącym do klastra Ceph używamy następujących poleceń:

ceph -s
ceph health detail
ceph osd tree
ceph df

ceph -s pokazuje ogólny stan klastra, w tym quorum monitorów. ceph health detail rozwija ostrzeżenia, ceph osd tree pokazuje rozmieszczenie OSD na hostach, a ceph df pokazuje wykorzystanie pojemności. HEALTH_WARN nie oznacza automatycznie braku quorum, ale zawsze wymaga przeczytania szczegółu przed zmianą konfiguracji lub planowaną pracą serwisową.

W obu wariantach monitorujemy również stan fizycznych dysków, opóźnienia I/O i zapas pojemności. Do usuwania alarmu nie obniżamy pochopnie progów Ceph i nie wyłączamy mechanizmów trwałości ZFS. Najpierw ustalamy, czy problemem jest dysk, sieć, brak miejsca, presja RAM czy sama konfiguracja.

CoW, snapshoty i dlaczego miejsce nie zawsze wraca

CoW w ZFS nie kopiuje całego dysku VM przy każdym zapisie. Gdy aplikacja w VM zmienia fragment bazy danych, ZFS zapisuje nową wersję zmienionych bloków w dostępnym miejscu, a następnie aktualizuje odwołanie do nich. Stara wersja może zostać zwolniona, jeżeli nie korzysta z niej snapshot ani klon.

Snapshot przy utworzeniu nie zajmuje pełnego rozmiaru dysku VM. Początkowo współdzieli istniejące bloki z bieżącym stanem. Miejsce rośnie później, gdy dane zmieniają się po utworzeniu snapshotu i trzeba zachować ich wcześniejsze wersje. Z tego powodu długi łańcuch snapshotów przy intensywnych zapisach może zapełniać pulę szybciej, niż sugeruje rozmiar pojedynczej VM.

Usunięcie pliku wewnątrz VM również nie musi natychmiast zwolnić miejsca w zvolu na hoście. System gościa musi przekazać zwolnione bloki przez discard/TRIM, a Proxmox i urządzenie dyskowe VM muszą obsługiwać tę ścieżkę. Nawet wtedy blok zachowany przez snapshot pozostanie zajęty. To normalny skutek warstw VM, snapshotów i discardu, a nie sam „błąd CoW”.

Backend zfspool tworzy zvole raw, co jest właściwym punktem startowym dla dysków VM na ZFS. Plik qcow2 ma własne metadane i własny mechanizm copy-on-write. Umieszczenie go w katalogu leżącym na ZFS może dodać drugą warstwę CoW i zwiększyć write amplification, czyli ilość fizycznych zapisów względem zmian wykonanych przez aplikację. Nie znaczy to, że qcow2 zawsze jest błędem ani że raw wyłącza CoW ZFS; oznacza jedynie, że nie nakładamy warstw bez uzasadnienia i pomiaru.

Gdy miejsce znika szybciej niż oczekujemy, zaczynamy od stanu puli, zvolów i snapshotów. Nie usuwamy snapshotów ani nie uruchamiamy poleceń naprawczych bez potwierdzenia, które dane mają zostać zachowane.

zpool status
zpool list -o name,size,alloc,free,cap,frag,health
zfs list -t all -o name,type,used,refer,avail,creation

ARC i wykorzystanie RAM przez ZFS

Rosnące wykorzystanie RAM na hoście z ZFS często wynika z ARC. Cache stopniowo przechowuje często odczytywane dane i metadane, aby ograniczyć dostęp do dysków. Sam wysoki wykres „used” nie jest dowodem wycieku ani sygnałem, że CoW kopiuje dyski VM do pamięci.

Problem zaczyna się wtedy, gdy hostowi realnie brakuje pamięci: spada wartość available, rośnie swap, system reaguje na brak pamięci albo VM konkurują o RAM z hostem i cache. ARC jest osobnym mechanizmem od CoW i snapshotów. Przy strojeniu patrzymy na cały budżet hosta: pamięć VM, systemu, usług Ceph - jeśli współistnieją - oraz zapas na skoki obciążenia.

free -h
swapon --show
awk '$1 == "size" || $1 == "c" || $1 == "c_min" || $1 == "c_max" {
  printf "%-8s %.2f GiB\n", $1, $3 / 1024 / 1024 / 1024
}' /proc/spl/kstat/zfs/arcstats
journalctl -k -b | grep -Ei 'out of memory|oom-kill|killed process'

size pokazuje bieżący rozmiar ARC, a c_min i c_max jego efektywne granice. free -h oceniamy razem z wartością available, a nie wyłącznie z kolumną użytej pamięci. Utrzymujące się użycie swap albo komunikaty OOM (Out of Memory) są silniejszym sygnałem problemu niż sam rozmiar cache. Zmianę limitu ARC wykonujemy dopiero po pomiarze i z planem sprawdzenia po restarcie; pełne strojenie ARC należy do osobnego tematu ZFS.

Replikacja, HA i backup rozwiązują różne problemy

Replikacja ZFS w Proxmox okresowo przesyła zmiany lokalnego dysku VM do storage na innym hoście. Jest asynchroniczna, więc po awarii źródła może brakować zmian od ostatniej udanej synchronizacji. Nie tworzy jednego współdzielonego dysku.

HA (High Availability) może ponownie uruchomić VM na sprawnym hoście, ale nie przywraca jej RAM ani otwartych połączeń. Przy Ceph dysk RBD może pozostać dostępny po awarii hosta, lecz VM nadal przechodzi restart. Przy lokalnym ZFS HA wymaga dostępnej repliki lub innej drogi odtworzenia danych.

Backup jest niezależną kopią potrzebną po skasowaniu danych, błędzie aplikacji, ransomware lub utracie całego storage. Mirror, repliki Ceph i snapshoty mogą powielić błędny zapis, więc nie zastępują backupu. Dla VM planujemy backup na oddzielnym urządzeniu oraz regularny test odtworzenia.

Źródła i dalszy zakres

Podstawy backendu lokalnego opisuje Proxmox: ZFS pool backend, a model storage - Proxmox: storage. Architektura i RBD: Ceph Architecture, Ceph RBD oraz Ceph health checks. Zachowanie ZFS opisują OpenZFS: CoW, cache ARC i snapshoty.

Celowo nie rozwijamy tu pełnej konfiguracji Ceph, szczegółowego strojenia ZFS ani architektur z macierzą zewnętrzną. Te zagadnienia wymagają osobnych scenariuszy wdrożeniowych, pomiarów i testów odtworzenia.