Aktualizacja!. W komentarzach jeden z czytelników zasugerował spróbować (możliwe, że sam nad nim pracuje), więc dodałem sekcję na ten temat. Napisałem również , ponieważ proces znacznie różni się od innych.
Szczerze mówiąc, się poddałem i zrezygnowałem z (przynajmniej na razie). Będę korzystał z . Dlaczego? Z powodu przechowywania! Kto by pomyślał, że będę spędzać więcej czasu na zarządzaniu magazynami niż samym Kubernetesem. Używam , ponieważ to niedrogie i ma dobrą wydajność, a od samego początku wdrażałem klastry za pomocą . Nie próbowałem zarządzanych usług Kubernetes od Google/Amazon/Microsoft/DigitalOcean itp., ponieważ chciałem wszystko nauczyć się samodzielnie. A poza tym oszczędzam.
Więc tak, spędziłem mnóstwo czasu na próbie ustalenia, które magazynowanie wybrać, gdy rozważałem możliwy stos na Kubernetes. Wolę rozwiązania z otwartym kodem źródłowym, nie tylko ze względu na cenę, ale też zbadałem kilka płatnych możliwości z ciekawości, ponieważ mają bezpłatne wersje z ograniczeniami. Zanotowałem kilka danych z ostatnich testów, gdy porównywałem różne opcje, co może zainteresować tych, którzy badają magazynowanie w Kubernetes. Chociaż osobiście jak na razie pożegnałem się z Kubernetesem. Chciałbym jeszcze wspomnieć , w którym można bezpośrednio przygotowywać wolumeny Hetzner Cloud, ale jeszcze go nie przetestowałem. Badałem chmurowe magazyny definiowane programowo, ponieważ potrzebowałem replikacji i możliwości szybkiego podłączania trwałych wolumenów na dowolnym węźle, szczególnie w przypadku awarii węzłów i innych podobnych sytuacji. Niektóre rozwiązania oferują migawki z określonego momentu i kopie zapasowe off-site, co jest wygodne.
Przetestowałem 6–7 rozwiązań do przechowywania:
Jak już wspomniałem , testując większość opcji z listy, początkowo skupiłem się na OpenEBS. OpenEBS jest bardzo prosty w instalacji i użytkowaniu, ale szczerze mówiąc, po testach z rzeczywistymi danymi pod obciążeniem, jego wydajność mnie rozczarowała. To open source, a programiści na swoim zawsze bardzo pomagali, gdy potrzebowałem wsparcia. Niestety, ma bardzo niską wydajność w porównaniu do innych opcji, więc musiałem przeprowadzić testy ponownie. Obecnie OpenEBS ma 3 silniki magazynowania, ale publikuję wyniki benchmarku dla cStor. Na razie nie mam danych dla Jiva i LocalPV.
Mówiąc w skrócie, Jiva jest nieco szybsza, a LocalPV jest bardzo szybki, nie gorszy niż benchmark dysku bezpośrednio. Problem z LocalPV polega na tym, że dostęp do niego można uzyskać tylko na tym węźle, na którym został przygotowany, a replikacji w ogóle nie ma. Miałem pewne problemy z przywracaniem kopii zapasowej przez na nowym klastrze, ponieważ nazwy węzłów różniły się. Jeśli chodzi o kopie zapasowe, cStor ma , który pozwala na wykonanie off-site kopii zapasowych z momentem czasowym, co jest wygodniejsze niż kopie zapasowe na poziomie plików z Velero-Restic. Napisałem , aby ułatwić zarządzanie kopiami zapasowymi i przywracaniem z tym pluginem. Ogólnie rzecz biorąc, bardzo lubię OpenEBS, ale jego wydajność…
Rook również ma otwarty kod źródłowy, a w porównaniu do innych opcji na liście wyróżnia się tym, że jest orkiestratorem magazynów, który wykonuje złożone zadania zarządzania magazynem z różnymi backendami, takimi jak , i inne, co znacznie upraszcza pracę. Miałem problemy z EfgeFS, gdy testowałem go kilka miesięcy temu, więc głównie testowałem z Ceph. Ceph oferuje nie tylko magazyn blokowy, ale również magazyn obiektowy, zgodny z S3/Swift i rozproszonym systemem plików. Co mi się podoba w Ceph, to możliwość rozprzestrzenienia danych woluminu na kilku dyskach, aby wolumin mógł wykorzystać więcej miejsca na dysku, niż mieści się na jednym dysku. To wygodne. Jeszcze jedną fajną funkcjonalnością jest to, że po dodaniu dysków do klastra dane są automatycznie redistribuowane na wszystkich dyskach.
W Ceph są migawki, ale, jak sądzę, nie można ich bezpośrednio używać w Rook/Kubernetes. Prawda, nie zagłębiałem się w to szczególnie. A zdalnych kopii zapasowych brak, więc trzeba będzie użyć czegoś z Velero/Restic, ale tam są tylko kopie zapasowe na poziomie plików, a nie migawki w punkcie w czasie. Za to w Rook bardzo podobała mi się łatwość pracy z Ceph – prawie wszystkie skomplikowane rzeczy są ukryte, a także oferuje narzędzia do komunikacji z Ceph bezpośrednio w celu rozwiązywania problemów. Niestety, podczas stres-testu wolumenów Ceph cały czas miałem , przez który Ceph staje się niestabilny. Na razie nie jest jasne, czy to błąd w samym Ceph, czy problem w tym, jak Rook zarządza Ceph. Pokombinowałem z ustawieniami pamięci i było lepiej, ale problem ostatecznie nie został rozwiązany. Ceph ma niezłą wydajność, co widać w benchmarkach poniżej. Ma także dobry panel monitorowania.
Bardzo lubię Longhorn. Uważam, że to obiecujące rozwiązanie. Prawda, sami deweloperzy (Rancher Labs) przyznają, że na razie nie nadaje się do środowiska produkcyjnego, co widać. Ma otwarty kod źródłowy i niezłą wydajność (choć optymalizacją jeszcze się nie zajęli), ale wolumeny łączą się z podami bardzo długo, a w najgorszych przypadkach trwa to 15–16 minut, szczególnie po przywróceniu dużej kopii zapasowej lub aktualizacji obciążenia roboczego. Ma migawki i zdalne kopie zapasowe tych migawek, ale dotyczą one tylko wolumenów, więc nadal będziecie potrzebować czegoś jak Velero dla kopii zapasowych innych zasobów. Kopie zapasowe i przywracanie są bardzo niezawodne, ale niesamowicie wolne. Na poważnie, po prostu absurdalnie wolne. Wykorzystanie zasobów procesora i obciążenie systemu często skaczą przy pracy z średnimi ilościami danych w Longhorn. Jest wygodny panel monitorowania do zarządzania Longhorn. Już mówiłem, że lubię Longhorn, ale trzeba nad nim solidnie popracować.
StorageOS to pierwszy płatny produkt na liście. Ma wersję dla deweloperów z ograniczoną wielkością zarządzanej pamięci masowej do 500 GB, ale liczba węzłów, jak sądzę, nie jest ograniczona. W dziale sprzedaży powiedziano mi, że cena zaczyna się od 125 USD miesięcznie za 1 TB, jeśli dobrze pamiętam. Tam znajduje się podstawowy panel monitorowania i wygodne CLI, ale z wydajnością dzieje się coś dziwnego: w niektórych benchmarkach jest całkiem przyzwoita, ale w teście obciążeniowym prędkość zupełnie mi się nie podobała. Generalnie, nie wiem, co o tym powiedzieć. Dlatego nie zagłębiałem się w to szczególnie. Nie ma tu kopii zapasowych off site i trzeba będzie również użyć Velero z Restic do tworzenia kopii zapasowych woluminów. Dziwne, ponieważ produkt jest płatny. A programiści nie palili się do rozmowy na Slacku.
O Robinie dowiedziałem się na Redditi od ich dyrektora technicznego. Wcześniej nigdy o nim nie słyszałem. Może to dlatego, że szukałem darmowych rozwiązań, a Robin jest płatny. Mają dość hojną wersję darmową z 10 TB pamięci i trzema węzłami. Ogólnie rzecz biorąc, produkt jest naprawdę godny uwagi i z fajnymi funkcjami. Posiada świetne CLI, a najlepsze jest to, że można wykonać zrzut i backup całej aplikacji (w selektorze zasobów nazywa się to wydaniami Helm lub „flex apps”), w tym woluminów i innych zasobów, więc można obejść się bez Velero. I wszystko byłoby wspaniałe, gdyby nie jeden mały szczegół: jeśli przywracasz (lub „importujesz”, jak to nazywają w Robinie) aplikację na nowym klastrze – na przykład w przypadku przywracania po awarii – przywracanie oczywiście działa, ale kontynuowanie backupu aplikacji jest niemożliwe. W tej wersji po prostu nie da się tego zrobić, co potwierdzili deweloperzy. Jest to, delikatnie mówiąc, dziwne, zwłaszcza biorąc pod uwagę inne zalety (na przykład niesamowicie szybkie kopie zapasowe i przywracanie). Deweloperzy obiecują to naprawić w następnej wersji. Wydajność ogólnie jest dobra, ale zauważyłem pewną dziwność: jeśli uruchomić benchmark bezpośrednio na woluminie podłączonym do hosta, prędkość odczytu jest znacznie wyższa niż w tym samym woluminie, lecz wewnątrz poda. Wszystkie pozostałe wyniki są identyczne, ale teoretycznie nie powinno być różnicy. Choć nad tym pracują, rozczarowałem się problemem z przywracaniem i backupem – miałem wrażenie, że w końcu znalazłem odpowiednie rozwiązanie i byłem gotów za to zapłacić, gdybym potrzebował więcej miejsca lub więcej serwerów.
Nie mam tu wiele do powiedzenia. To płatny produkt, jednocześnie klasyczny i drogi. Wydajność jest po prostu niesamowita. Na razie to najlepszy wskaźnik. W Slacku powiedziano mi, że cena zaczyna się od 205 USD miesięcznie za węzeł, co wskazano w GKE Marketplace Google. Nie wiem, czy byłoby taniej, kupując bezpośrednio. W każdym razie, nie mogę sobie na to pozwolić, więc byłem bardzo rozczarowany, że licencja dewelopera (do 1 TB i 3 węzłów) jest praktycznie bezużyteczna w Kubernetes, chyba że zadowalasz się statycznym przygotowaniem. Miałem nadzieję, że licencja korporacyjna automatycznie zostanie zmieniona na poziom dewelopera na koniec okresu próbnego, ale tak się nie stało. Licencję dewelopera można używać tylko bezpośrednio z Dockerem, a konfiguracja w Kubernetes jest bardzo skomplikowana i ograniczona. Oczywiście preferuję oprogramowanie open source, ale gdybym miał pieniądze, na pewno wybrałbym Portworx. Jak na razie jego wydajność jest po prostu niezrównana z innymi opcjami.
Dodałem tę sekcję po publikacji posta, kiedy jeden z czytelników zasugerował, by spróbować Linstor. Spróbowałem i bardzo mi się spodobało! Ale muszę jeszcze to dokładniej zbadać. Na razie mogę powiedzieć, że wydajność jest niezła (wyniki benchmarków dodałem poniżej). W zasadzie uzyskałem taką samą wydajność jak dla dysku bezpośrednio, zupełnie bez strat. (Nie pytajcie, dlaczego Portworx ma lepsze wyniki niż benchmark dysku bezpośrednio. Nie mam pojęcia. Magia, prawdopodobnie.) Tak więc Linstor wydaje się bardzo efektywny. Instalacja nie jest jakoś szczególnie trudna, ale nie jest tak łatwa jak inne opcje. Musiałem najpierw zainstalować Linstor (moduł jądra i narzędzia/usługi) oraz skonfigurować LVM do thin provisioning i obsługi snapshotów poza Kubernetes, bezpośrednio na hoście, a następnie stworzyć zasoby potrzebne do korzystania z pamięci masowej w Kubernetes. Nie podobało mi się, że nie działało na CentOS i musiałem użyć Ubuntu. Oczywiście to nie jest wielka tragedia, ale jest trochę irytujące, ponieważ w dokumentacji (która zresztą jest świetna) wspomniano o kilku pakietach, których nie można znaleźć w podanych repozytoriach Epel. W Linstor są snapshoty, ale nie ma kopii zapasowych off-site, więc znów musiałem użyć Velero z Restic do tworzenia kopii zapasowych wolumenów. Wolałbym mieć snapshoty zamiast kopii zapasowych na poziomie plików, ale to można znieść, jeśli rozwiązanie jest wydajne i niezawodne. Linstor ma otwarty kod źródłowy, ale dostępne są płatne wsparcie. Jeśli dobrze rozumiem, można go używać bez ograniczeń, nawet jeśli nie masz umowy o wsparcie, ale to trzeba potwierdzić. Nie wiem, na ile Linstor jest sprawdzony dla Kubernetes, ale sam poziom przechowywania znajduje się poza Kubernetes i, sądząc po wszystkim, rozwiązanie nie pojawiło się wczoraj, więc prawdopodobnie zostało już przetestowane w warunkach rzeczywistych. Czy istnieje jakieś rozwiązanie, które skłoniłoby mnie do przemyślenia sprawy i powrotu do Kubernetes? Nie wiem, nie jestem pewien. Muszę jeszcze to zbadać, sprawdzić replikację. Zobaczymy. Ale pierwsze wrażenie jest pozytywne. Zdecydowanie wolałbym używać własnych klastrów Kubernetes zamiast Heroku, aby zyskać więcej swobody i nauczyć się czegoś nowego. Ponieważ instalacja Linstor nie jest tak prosta jak w przypadku innych, wkrótce napiszę o tym post.
Benchmarki
Niestety, zachowałem mało danych porównawczych, ponieważ nie pomyślałem, że będę o tym pisać. Mam tylko wyniki podstawowych benchmarków fio i tylko dla klastrów z jednym węzłem, więc obecnie nie mam danych dla konfiguracji replikowanych. Jednak na podstawie tych wyników można uzyskać przybliżone wyobrażenie o tym, czego można się spodziewać od każdej opcji, ponieważ porównywałem je na tych samych serwerach w chmurze, 4 rdzenie, 16 GB pamięci RAM, z dodatkowym dyskiem 100 GB do testowanych wolumenów. Przeprowadziłem benchmarki trzykrotnie dla każdego rozwiązania i obliczyłem średni wynik, dodatkowo resetując ustawienia serwera dla każdego produktu. Wszystko to nie jest naukowe, po prostu aby dać wam ogólny obraz. W innych testach kopiowałem 38 GB zdjęć i filmów z wolumenu i na wolumin, aby przetestować odczyt i zapis, ale niestety nie zachowałem tych danych. Krótko mówiąc: Portworx był znacznie szybszy.
Do benchmarku wolumenów 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 stworzyłem wolumen z odpowiednią klasą magazynu, a następnie uruchomiłem zadanie z fio w tle. Wziąłem 1 GB, aby oszacować wydajność i nie czekać zbyt długo. Oto wyniki:
Zaznaczyłem najlepszą wartość dla każdego wskaźnika na zielono, a najgorszą na czerwono.
Podsumowanie
Jak widać, w większości przypadków Portworx wypadł lepiej od innych. Ale dla mnie jest zbyt drogi. Nie wiem, ile kosztuje Robin, ale mają świetną wersję darmową, więc jeśli potrzebujesz płatnego produktu, możesz spróbować (mam nadzieję, że wkrótce naprawią problemy z przywracaniem i kopiami zapasowymi). Z trzech darmowych miałem najmniej problemów z OpenEBS, ale jego wydajność jest kiepska. Szkoda, że nie zachowałem więcej wyników, ale mam nadzieję, że przedstawione liczby i moje komentarze pomogą.
Źródło: habr.com
