Aplikacje uruchomione w kontenerach zazwyczaj potrzebują trwałej przestrzeni dyskowej (ang. persistent storage), aby przechowywać przetwarzane czy wytworzone dane. Choć oczywiście jest szereg aplikacji, które nie potrzebują przestrzeni dyskowej innej, niż tymczasowa. Nimi się jednak nie będziemy zajmowali. Persistent storage daje nam gwarancję, że zapisane tam dane nie ulegną skasowaniu, gdy kontener przestanie działać. Silnik Docker Engine sam z siebie wprowadza taki mechanizm w postaci wolumenów (ang. volumes). Jednak w przypadku klastrów Swarm wolumeny mają jedną podstawową wadę – są to obiekty lokalnie definiowane na wskazanym węźle. Ograniczone do lokalnego systemu plików hosta. A w Swarm usługi mogą być przecież rozrzucone pomiędzy wiele węzłów, czy to w postaci zwielokrotnionych replik, czy po prostu w wyniku awarii lub ręcznego wymuszenia przebalansowania zadań, przeniesione na inny węzeł. Gdy korzystamy z Docker Swarm musimy zastosować inne podejście.
NFS
Sieciowe systemy plików nie są niczym nowym. Spotykamy je praktycznie w każdej sieci, w której za pomocą odpowiednich protokołów wolumeny na zdalnych serwerach są dostępne dla pozostałych komputerów pracujących w sieci. Bez wolumenów sieciowych nie istnieją dzisiejsze centra przetwarzania danych, ale nie istnieją też małe sieci firmowe, w których system NAS stanowi jeden z centralnych i krytycznych punktów. Najczęściej wykorzystywanymi protokołami – za pomocą których świadczona jest usługa zdalnego systemu plików – są SMB i NFS. Drugi z nich wykorzystamy uruchamiając kontenery w ramach klastra Docker Swarm.
Rozpoczynamy od przygotowania odpowiednich wolumenów po stronie samego serwera plików. Wystarczy, że dodamy dedykowane folder lub foldery do listy eksportowanych w protokole NFS folderów z danego serwera. Przetestujmy, czy jesteśmy w stanie poprawnie podłączyć tak udostępniony folder na komputerach, które będą działały jako klaster Docker Swarm. W ten sposób zweryfikujemy poprawność działania i potencjalnie wyeliminujemy problemy związane z komunikacją pomiędzy serwerem plików a węzłem Dockera. Gdy weryfikacja przebiegnie pomyślnie podłączamy wolumeny NFS do uruchomionego w Docker Swarm serwisu:
docker service create –mount type=volume,volume-
opt=o=addr=100.0.0.10,volume-opt=device=:/var/nfs,volume-
opt=type=nfs,source=moj_folder,target=/opt/dane -replicas 3 –name
moj_serwis alpine moj_obraz_kontenera
Parametry, które przekazujemy do Docker Engine mają taki sam format i składnię, jak parametry ich montowania bezpośrednio w systemie operacyjnym. Uruchamianie serwisów z linii poleceń nie jest praktyczne, dlatego powołujemy je zazwyczaj w postaci stosów, których konfigurację definiujemy w odpowiednim pliku. Odpowiednią konfigurację wolumenów NFS także umieszczamy w pliku definicji stosu. Poniżej fragment takiej konfiguracji:
services:
moj_serwis:
volumes:
– rrd_data:/opt/dane
volumes:
rrd_data:
driver_opts:
type: „nfs”
o: „addr=100.0.0.10”
device: „:/var/nfs/moj_folder”
GlusterFS
Alternatywną metodą jest zastosowanie skalowalnych sieciowych systemów plików. Do tej rodziny należy choćby GlusterFS. Jest to darmowy projekt open-source, za pomocą którego zbudujemy sieciowy system plików o wysokiej wydajności. Nie musimy do tego celu wykorzystywać zaawansowanych macierzy czy wysokowydajnych serwerów. W większości przypadków sprawdzą się urządzenia, które z powodu wieku wycofaliśmy z użycia. Co więcej GlusterFS możemy uruchomić jako system plików na tych samych maszynach co klaster Docker Swarm, jednak w tym wypadku musimy się liczyć ze zużyciem zasobów i wprowadzić ich odpowiednią ochronę.
GlusterFS jest systemem plików uruchamianym w przestrzeni użytkownika (FUSE). Nie wymaga zatem integracji w kod jądra systemu lub uruchamiania dodatkowych modułów, zależnych od wersji kernela. Klaster GlusterFS składa się zawsze z co najmniej trzech węzłów. W tak zdefiniowanym klastrze tworzone są logiczne wolumeny (Distributed Volume), w ramach których zapis plików następuje na poszczególnych serwerach w przestrzeni zaalokowanej do wolumenu. Takie fragmenty są nazywane „cegłami” (bricks). GlusterFS najlepiej sprawdza się z systemem plików XFS, który nie jest domyślnym w Linuksie. Jeżeli jednak nie mamy możliwości sformatowania i zmiany systemu plików to, o ile nasz system używa rozszerzonych atrybutów, to także się nada.
Podstawą działania GlusterFS są wolumeny. Rozróżniamy kilka typów, wśród których są trzy podstawowe:
- Distributed GlusterFS Volume – jest to domyślny tryb pracy wolumenu. W trybie tym dane są rozrzucane pomiędzy wszystkie węzły klastra. Nie wprowadza on żadnej redundancji, gdyż dane są zawsze zapisane w dokładnie jednej „cegle”.
- Replicated GlusterFS Volume – można powiedzieć, że jest to odpowiednik RAID1. Dane zapisywane są na każdym z węzłów klastra, czyli pojedyncza „cegła” znajduje się na każdym z nich, co zapewnia redundancję.
- Distributed Replicated GlusterFS Volume – w trybie tym pliki woluminu są dystrybuowane w replikowanych zestawach cegieł. Liczba cegieł musi być wielokrotnością liczby replik. Ten typ wolumenu jest używany, gdy wymagana jest wysoka dostępność danych ze względu na nadmiarowość i skalowanie tworzonego storage.
Pamiętajmy, że aby wykorzystać GlusterFS musimy do Dockera doinstalować dodatkową wtyczkę.
Zostaw komentarz
Musisz się zalogować lub zarejestrować aby dodać nowy komentarz.