Ceph w klastrze Proxmox: wysoka dostępność bez osobnego SAN

Ceph w klastrze Proxmox może rozdzielać dane VM na lokalne SSD wielu hostów i zastąpić osobny SAN. Decyduje los kopii po awarii hosta: czy kworum, wolna pojemność i sieć wystarczą do odtworzenia wymaganej nadmiarowości na czas? Poniższy rachunek rozdziela dostępność danych, automatyczne restarty VM i rzeczywisty czas odtwarzania.

Ten artykuł koncentruje się na mechanice Ceph w eksploatacji. Konkretny wykaz sprzętu HPE wymaga własnego projektu; wybór między Ceph, replikacją ZFS i zewnętrzną pamięcią masową wymaga osobnego porównania zastosowań. Scenariusz bazowy zakłada lokalne SSD klasy enterprise jako pojedyncze OSD Ceph, replikowaną pulę VM i host jako domenę awarii. Nośniki rozruchowe i zewnętrzna kopia nie należą do puli.

Jak lokalne SSD zapewniają dostęp do danych VM?

Ceph rozdziela obiekty danych przez grupy rozmieszczenia na OSD. Reguła CRUSH określa, na których hostach leżą kopie. W przykładzie ustawiamy wyraźnie size=3 i min_size=2: trzy kopie łącznie z główną, I/O przy co najmniej dwóch dostępnych kopiach. Kopie na trzech OSD tego samego hosta nie zapewnią potrójnej ochrony przed jego awarią. Kworum monitorów, stan OSD i dostępność danych VM trzeba sprawdzać oddzielnie. Klaster Proxmox potrzebuje co najmniej trzech głosów dla niezawodnego kworum HA; dochodzą kworum monitorów Ceph i reguły HA maszyn wirtualnych.

Po awarii jednego z dokładnie trzech hostów poprawne rozmieszczenie pozostawia dwie kopie na hostach. Przy podanych założeniach pula może obsługiwać zdegradowane I/O, ale trzecia kopia w trzeciej domenie hosta powstaje dopiero po powrocie lub zastąpieniu hosta. Przy czterech Ceph może odbudować ją na czwartym, jeśli są wolne miejsce i wydajność. To praktyczna różnica między „dane pozostają dostępne” a „nadmiarowość jest odtworzona w trakcie awarii”. Nawet z Ceph VM może przestać działać i dopiero uruchomić się na innym hoście; nie oznacza to zerowej przerwy.

Liczyć pojemność z rezerwą na awarię

Załóżmy cztery lokalne SSD danych po 1,92 TB dziesiętnego na host. Trzy hosty dają 23,04 TB surowej pojemności, cztery 30,72 TB. Przy trzech kopiach, przed metadanymi, migawkami i rezerwami, daje to teoretycznie 7,68 lub 10,24 TB danych logicznych. Hipotetyczny limit planistyczny 70 procent daje początkowo 5,38 lub 7,17 TB. Nie jest to domyślna wartość Ceph ani obiecana pojemność użytkowa.

Aby czterohostowy klaster także po awarii jednego hosta, po zakończeniu odbudowy, pozostał poniżej własnego limitu 70 procent, w przykładzie planuje się najwyżej około 5,38 TB logicznych, nie 7,17 TB. Liczą się też najbardziej zapełnione OSD i progi Ceph dla nearfull, backfillfull i full. Jeden pełny OSD może blokować zapis lub backfill, mimo dobrego wyniku łącznego. Dziesiętne TB nie są binarnymi TiB.

Jak długo trwa odbudowa?

Przy przykładowych 5 TB danych logicznych i trzech kopiach klaster czterohostowy zawiera 15 TB surowych danych, idealnie po 3,75 TB na host. Po awarii jednego dla trzeciej kopii trzeba przesłać około 3,75 TB na pozostałe trzy hosty. Przy zmierzonej efektywnej szybkości odbudowy 250 MB/s rachunek 3,75 TB ÷ 250 MB/s = około 4 godziny 10 minut jest dolną granicą arytmetyczną; przy 125 MB/s około 8 godzin 20 minut. Peering, rozkład, konkurencyjne I/O VM, limity recovery i nowe zapisy wydłużają realny czas. Nominalna szybkość karty 25 Gbit nie jest takim pomiarem.

DAXS wymagałby testu awarii przy aktywnym obciążeniu aplikacji: obserwować ceph health detail, ceph osd df i przebieg grup rozmieszczenia, zapisać rzeczywiste odtwarzane bajty i czas oraz mierzyć opóźnienia i dostępność VM. W normalnej pracy PG powinny wrócić do active+clean . Test ma też pokazać, czy awaria przełącznika, łącza lub toru zasilania jednocześnie dotyka kworum Corosync lub ruchu Ceph. Proxmox zaleca co najmniej 10 Gbit/s wyłącznie dla Ceph, więcej przy szybkich SSD; plan portów zależy od przepustowości OSD, celu odtwarzania i rozdzielonych dróg fizycznych.

Co kosztuje dodatkowa domena odbudowy?

Dla budżetu niech h oznacza cenę ofertową w pełni wyposażonego hosta, n redundantną sieć już przygotowaną na cztery przyłącza, a b zewnętrzny serwer kopii z nośnikami. Na host hipotetycznie przypada p euro rocznie za serwis, energię i kolokację. Tylko w modelu zakładamy instalację i odbiór 100 godzin × 90 € = 9 000 € oraz utrzymanie 60 godzin × 90 € = 5 400 € rocznie. Dla trzech i czterech hostów przyjmujemy tę samą pracę, którą w ofercie trzeba oszacować ponownie. Oficjalne ceny Proxmox VE Standard i Proxmox Backup Server Standard wynoszą odpowiednio 550 € za obsadzone gniazdo CPU rocznie i 2 240 € za serwer kopii rocznie. Przyjmujemy dokładnie jedno obsadzone gniazdo na host. Wszystko netto; zastąpić realnymi ofertami i nakładem pracy.

Wzór dodaje rocznie gniazda Proxmox, PBS i 5 400 € utrzymania: przy trzech hostach 9 290 € plus 3p, przy czterech 9 840 € plus 4p. Cena jednostkowa hosta wyższa o 1 000 € zwiększa oba czterohostowe horyzonty o 4 000 €; roczne koszty na host wyższe o 1 000 € dodają 12 000 lub 20 000 €. Jeśli wariant czterohostowy wymaga innych przełączników, różnicę dodać do n . Kopie Ceph nadal nie są backupem: osobny system, kopia zewnętrzna i przetestowane odtworzenie należą do odbioru. Artykuł DAXS Proxmox Backup Server: weryfikacja, retencja i odtwarzanie opisuje tę kontrolę.

Decyzję podejmuje się po pomiarze opóźnień, przerwy i odbudowy oraz uzyskaniu wiarygodnej oferty sprzętu, sieci i utrzymania. DAXS może doprecyzować z firmą ten protokół pomiarów i odbioru przez Kontakt .

Źródła: Proxmox VE Administration Guide: klaster i Ceph · Ceph: size i min_size · Ceph: kontrole stanu i zapełnienie · Ceph: recovery i backfill · Proxmox VE: ceny · Proxmox Backup Server: ceny.