Aktualizacja!. W komentarzach jeden z czytelników zasugerował próbę (być może sam nad tym pracuje), więc dodałem sekcję o tym rozwiązaniu. Ja też pisałem , ponieważ proces ten bardzo różni się od pozostałych.
Szczerze mówiąc, poddałem się i poddałem (przynajmniej na razie). Użyję . Dlaczego? Ze względu na przechowywanie! Kto by pomyślał, że będę majstrował przy przechowywaniu więcej niż przy samym Kubernetesie. używam ponieważ jest niedrogi i ma dobrą wydajność i od samego początku wdrażam klastry z jego pomocą . Nie próbowałem zarządzanych usług Kubernetes od Google/Amazon/Microsoft/DigitalOcean itp., itp., bo wszystkiego chciałem się nauczyć sam. Jestem też oszczędny.
Więc tak, spędziłem dużo czasu, próbując zdecydować, którą pamięć masową wybrać, oceniając możliwy stos Kubernetes. Preferuję rozwiązania typu open source, nie tylko ze względu na cenę, ale z ciekawości sprawdziłem kilka płatnych opcji, ponieważ mają darmowe wersje z ograniczeniami. Porównując różne opcje, zanotowałem kilka liczb z ostatnich testów i mogą one zainteresować osoby uczące się o pamięci masowej Kubernetes. Chociaż osobiście pożegnałem się na razie z Kubernetesem. Chcę też wspomnieć , który może bezpośrednio udostępniać woluminy Hetzner Cloud, ale jeszcze tego nie próbowałem. Zainteresowałem się pamięcią masową zdefiniowaną programowo w chmurze, ponieważ potrzebowałem replikacji i możliwości szybkiego montowania trwałych woluminów w dowolnym węźle, szczególnie w przypadku awarii węzła i innych podobnych sytuacji. Niektóre rozwiązania oferują migawki z określonego momentu i kopie zapasowe poza siedzibą firmy, co jest wygodne.
Przetestowałem 6-7 rozwiązań pamięci masowej:
Jak już powiedziałem Po przetestowaniu większości opcji z listy początkowo zdecydowałem się na OpenEBS. OpenEBS jest bardzo łatwy w instalacji i obsłudze, ale szczerze mówiąc, po testach z rzeczywistymi danymi pod obciążeniem, byłem rozczarowany jego wydajnością. To jest oprogramowanie typu open source, a programiści działają samodzielnie zawsze bardzo pomocny, gdy potrzebowałem pomocy. Niestety ma bardzo słabą wydajność w porównaniu do innych opcji, więc testy trzeba było powtórzyć. OpenEBS ma obecnie 3 silniki pamięci masowej, ale zamieszczam wyniki testów porównawczych dla cStor. Nie mam jeszcze numerów do Jiva i LocalPV.
Krótko mówiąc, Jiva jest trochę szybsza, a LocalPV jest ogólnie szybki, nie gorszy od bezpośredniego testu porównawczego dysku. Problem z LocalPV polega na tym, że dostęp do woluminu można uzyskać tylko w węźle, w którym został przygotowany, i nie ma w ogóle replikacji. Miałem pewne problemy z przywróceniem kopii zapasowej przez w nowym klastrze, ponieważ nazwy węzłów były inne. Jeśli mówimy o kopiach zapasowych, cStor ma , dzięki któremu możesz tworzyć kopie zapasowe migawek poza siedzibą firmy w określonym momencie, co jest wygodniejsze niż tworzenie kopii zapasowych na poziomie plików za pomocą Velero-Restic. napisałem , aby ułatwić zarządzanie kopiami zapasowymi i przywracaniem za pomocą tej wtyczki. Ogólnie bardzo podoba mi się OpenEBS, ale jego wydajność...
Rook jest również oprogramowaniem typu open source i różni się od pozostałych opcji na liście tym, że jest koordynatorem pamięci masowej, który wykonuje złożone zadania zarządzania pamięcią masową z różnymi backendami, np. , i inne, co znacznie ułatwia pracę. Miałem problemy z EfgeFS, kiedy próbowałem go kilka miesięcy temu, więc testowałem głównie z Ceph. Ceph oferuje nie tylko pamięć blokową, ale także pamięć obiektową kompatybilną z S3/Swift i rozproszonym systemem plików. To, co podoba mi się w Ceph, to możliwość rozłożenia danych woluminów na wiele dysków, dzięki czemu wolumen może zająć więcej miejsca na dysku, niż mieści się na pojedynczym dysku. To jest wygodne. Kolejną fajną funkcją jest to, że po dodaniu dysków do klastra następuje automatyczna redystrybucja danych na wszystkich dyskach.
Ceph ma migawki, ale o ile wiem, nie można ich używać bezpośrednio w Rook/Kubernetes. To prawda, nie zagłębiałem się w to. Ale nie ma żadnych kopii zapasowych poza siedzibą, więc będziesz musiał użyć czegoś z Velero/Restic, ale istnieją tylko kopie zapasowe na poziomie plików, a nie migawki z określonego momentu. To, co naprawdę podobało mi się w Rooku, to łatwość pracy z Cephem - ukrywa prawie wszystkie skomplikowane rzeczy i oferuje narzędzia umożliwiające bezpośrednią rozmowę z Cephem w celu rozwiązania problemów. Niestety podczas testu obciążeniowego woluminów Ceph ciągle miałem problemy , co powoduje, że Ceph staje się niestabilny. Nie jest jeszcze jasne, czy jest to błąd samego Cepha, czy problem w sposobie, w jaki Rook zarządza Ceph. Majstrowałem przy ustawieniach pamięci i było lepiej, ale problem nie został całkowicie rozwiązany. Ceph ma przyzwoitą wydajność, co widać w poniższych benchmarkach. Ma też dobry pulpit nawigacyjny.
Bardzo lubię Longhorna. Moim zdaniem jest to obiecujące rozwiązanie. To prawda, że sami programiści (Rancher Labs) przyznają, że nie jest to jeszcze odpowiednie dla środowiska pracy i to widać. Jest to oprogramowanie typu open source i ma przyzwoitą wydajność (chociaż jeszcze go nie zoptymalizowano), ale połączenie woluminów z kapsułą zajmuje bardzo dużo czasu, a w najgorszych przypadkach zajmuje to 15-16 minut, szczególnie po przywróceniu dużej kopii zapasowej lub zwiększenie obciążenia pracą. Zawiera migawki i zewnętrzne kopie zapasowe tych migawek, ale dotyczą one tylko woluminów, więc nadal będziesz potrzebować czegoś takiego jak Velero do tworzenia kopii zapasowych innych zasobów. Kopie zapasowe i przywracanie są bardzo niezawodne, ale nieprzyzwoicie powolne. Poważnie, po prostu niesamowicie wolno. Użycie procesora i obciążenie systemu często gwałtownie wzrastają podczas pracy ze średnią ilością danych w Longhorn. Dostępny jest wygodny pulpit nawigacyjny do zarządzania Longhorn. Mówiłem już, że lubię Longhorna, ale wymaga trochę pracy.
Pierwszym płatnym produktem na liście jest StorageOS. Ma wersję deweloperską z ograniczonym zarządzanym rozmiarem pamięci wynoszącym 500 GB, ale nie sądzę, że istnieje ograniczenie liczby węzłów. Dział sprzedaży powiedział mi, że koszt zaczyna się od 125 dolarów miesięcznie za 1 TB, jeśli dobrze pamiętam. Jest podstawowy pulpit nawigacyjny i wygodny interfejs CLI, ale z wydajnością dzieje się coś dziwnego: w niektórych benchmarkach jest całkiem przyzwoicie, ale w teście obciążeniowym w ogóle nie podobała mi się prędkość. Generalnie nie wiem co powiedzieć. Więc tak naprawdę niewiele zrozumiałem. Nie ma tutaj żadnych kopii zapasowych poza siedzibą firmy, a do tworzenia kopii zapasowych woluminów będziesz musiał także używać Velero z Restic. To dziwne, bo produkt jest płatny. A twórcy nie byli chętni do komunikacji na Slacku.
O Robin dowiedziałem się na Reddicie od ich dyrektora technicznego. Nigdy wcześniej o nim nie słyszałem. Może dlatego, że szukałem darmowych rozwiązań, ale Robinowi się płaci. Mają całkiem hojną bezpłatną wersję z 10 TB pamięci i trzema węzłami. Ogólnie rzecz biorąc, produkt jest całkiem przyzwoity i ma fajne funkcje. Istnieje świetny interfejs CLI, ale najfajniejsze jest to, że możesz tworzyć migawki i kopie zapasowe całej aplikacji (w selektorze zasobów nazywa się to wydaniami Helma lub „aplikacjami elastycznymi”), w tym woluminami i innymi zasobami, więc możesz obejść się bez Velero. I wszystko byłoby cudownie, gdyby nie jeden mały szczegół: jeśli przywrócisz (lub „zaimportujesz”, jak to się nazywa w Robin) aplikację na nowym klastrze - na przykład w przypadku odzyskiwania po awarii - przywrócenie, oczywiście działa, ale dalsze tworzenie kopii zapasowych aplikacji jest zabronione. W tej wersji jest to po prostu niemożliwe, co potwierdzili twórcy. Jest to delikatnie mówiąc dziwne, szczególnie biorąc pod uwagę inne zalety (na przykład niesamowicie szybkie tworzenie kopii zapasowych i przywracanie). Twórcy obiecują naprawić wszystko do następnej wersji. Wydajność jest ogólnie dobra, ale zauważyłem dziwność: jeśli uruchomię test porównawczy bezpośrednio na woluminie podłączonym do hosta, prędkość odczytu jest znacznie większa niż w przypadku uruchomienia tego samego woluminu z poziomu modułu. Wszystkie pozostałe wyniki są identyczne, ale teoretycznie nie powinno być żadnej różnicy. Chociaż nad tym pracują, zmartwił mnie problem z przywracaniem i tworzeniem kopii zapasowych - myślałem, że w końcu znalazłem odpowiednie rozwiązanie i byłem nawet skłonny za to zapłacić, gdy potrzebowałem więcej miejsca lub więcej serwerów.
Nie mam tu wiele do powiedzenia. Jest to produkt płatny, równie fajny i drogi. Wykonanie jest po prostu niesamowite. To jak dotąd najlepszy wskaźnik. Slack powiedział mi, że ceny zaczynają się od 205 dolarów miesięcznie za węzeł, zgodnie z cennikiem Google GKE Marketplace. Nie wiem, czy będzie taniej, jeśli kupisz bezpośrednio. I tak nie mogę sobie na to pozwolić, więc byłem bardzo, bardzo rozczarowany, że licencja programisty (do 1 TB i 3 węzłów) jest praktycznie bezużyteczna w Kubernetesie, chyba że zadowalasz się statycznym udostępnianiem. Miałem nadzieję, że pod koniec okresu próbnego licencja zbiorcza automatycznie przejdzie na wersję deweloperską, ale tak się nie stało. Licencji programistycznej można używać wyłącznie bezpośrednio z Dockerem, a konfiguracja w Kubernetesie jest bardzo uciążliwa i ograniczona. Oczywiście wolę open source, ale gdybym miał pieniądze, zdecydowanie wybrałbym Portworx. Jak dotąd jego wydajność po prostu nie ma porównania z innymi opcjami.
Dodałem tę sekcję po opublikowaniu posta, gdy jeden z czytelników zasugerował wypróbowanie Linstora. Spróbowałem i spodobało mi się! Ale nadal musimy kopać głębiej. Teraz mogę powiedzieć, że wydajność nie jest zła (poniżej dodałem wyniki benchmarków). Zasadniczo uzyskałem tę samą wydajność, co dysk bezpośrednio, bez żadnych narzutów. (Nie pytaj, dlaczego Portworx ma lepsze wyniki niż bezpośrednio test porównawczy dysków. Nie mam pojęcia. Chyba magia.) Zatem Linstor wydaje się jak dotąd bardzo skuteczny. Instalacja nie jest aż tak trudna, ale nie jest tak łatwa jak inne opcje. Najpierw musiałem zainstalować Linstora (moduł jądra i narzędzia/usługi) oraz skonfigurować LVM pod kątem cienkiego udostępniania i obsługi migawek poza Kubernetesem, bezpośrednio na hoście, a następnie utworzyć zasoby potrzebne do korzystania z pamięci masowej z Kubernetes. Nie podobało mi się to, że nie działało na CentOS i musiałem używać Ubuntu. Oczywiście nie straszne, ale trochę denerwujące, ponieważ dokumentacja (która swoją drogą jest doskonała) wspomina o kilku pakietach, których nie można znaleźć w określonych repozytoriach Epel. Linstor ma migawki, ale nie kopie zapasowe znajdujące się poza siedzibą firmy, więc tutaj ponownie musiałem użyć Velero z Restic do tworzenia kopii zapasowych woluminów. Wolałbym migawki zamiast kopii zapasowych na poziomie plików, ale można to tolerować, jeśli rozwiązanie jest wydajne i niezawodne. Linstor jest oprogramowaniem typu open source, ale ma płatne wsparcie. Jeśli dobrze rozumiem, można z niego korzystać bez ograniczeń, nawet jeśli nie masz umowy wsparcia, ale trzeba to doprecyzować. Nie wiem na ile Linstor jest przetestowany pod Kubernetesem, ale sama warstwa magazynująca jest poza Kubernetesem i najwyraźniej rozwiązanie nie pojawiło się wczoraj, więc zapewne zostało już przetestowane w realnych warunkach. Czy jest tu rozwiązanie, które sprawi, że zmienię zdanie i wrócę do Kubernetesa? Nie wiem. Nadal musimy kopać głębiej i badać replikację. Zobaczmy. Ale pierwsze wrażenie jest dobre. Zdecydowanie wolałbym używać własnych klastrów Kubernetes zamiast Heroku, aby mieć więcej swobody i uczyć się nowych rzeczy. Ponieważ Linstor nie jest tak łatwy w instalacji jak inne, napiszę o tym wkrótce post.
Wzorce
Niestety nie zachowałem zbyt wielu notatek z porównania, bo nie sądziłem, że będę o tym pisał. Mam tylko wyniki z podstawowych testów porównawczych Fio i tylko dla klastrów z jednym węzłem, więc nie mam jeszcze liczb dla zreplikowanych konfiguracji. Ale z tych wyników można mniej więcej zorientować się, czego się spodziewać po każdej opcji, ponieważ porównywałem je na tych samych serwerach chmurowych, 4 rdzeniach, 16 GB RAM-u, z dodatkowym dyskiem 100 GB na testowane woluminy. Dla każdego rozwiązania przeprowadziłem trzykrotnie testy porównawcze i obliczyłem średni wynik, a także zresetowałem ustawienia serwera dla każdego produktu. To wszystko jest całkowicie nienaukowe, chcę tylko dać ogólny pogląd. W innych testach skopiowałem 38 GB zdjęć i filmów z woluminu, aby przetestować czytanie i pisanie, ale niestety nie zapisałem liczb. W skrócie: Portworkx był znacznie szybszy.
Do testu porównawczego głośności użyłem tego manifestu:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Najpierw utworzyłem wolumin z odpowiednią klasą pamięci, a następnie uruchomiłem zadanie z fio za kulisami. Wziąłem 1 GB, aby oszacować wydajność i nie czekać zbyt długo. Oto wyniki:
Najlepszą wartość dla każdego wskaźnika zaznaczyłem na zielono, a najgorszą na czerwono.
wniosek
Jak widać, w większości przypadków Portworx spisał się lepiej niż inne. Ale dla mnie jest to drogie. Nie wiem, ile kosztuje Robin, ale mają świetną darmową wersję, więc jeśli chcesz płatny produkt, możesz go wypróbować (miejmy nadzieję, że wkrótce rozwiążą problem z przywracaniem i tworzeniem kopii zapasowych). Z trzech darmowych najmniej problemów miałem z OpenEBS, ale jego wydajność jest fatalna. Szkoda, że nie zapisałem więcej wyników, ale mam nadzieję, że liczby i moje komentarze okażą się pomocne.
Źródło: www.habr.com