FreeNAS jest otwartoźródłowym projektem serwera NAS udostępniającego zasoby protokołami plikowymi (np. CIFS/NFS/FTP), a także blokowymi (iSCSI). Konfiguracja i zarządzanie odbywa się poprzez intuicyjny interfejs WEB, system można uruchamiać z pendrive lub innego nośnika umożliwiającego botowanie. Dane przechowywane są na dyskach tworzących grupy RAID zapewniając bezpieczeństwo (odporność na awarię jednego lub więcej dysków), a także wydajność (striping).
Podczas konfiguracji zasobów FreeNAS mamy możliwość wybrania rodzaju kompresji oraz deduplikacji dla zapisywanych danych. Zwykle pozostawiałem wyłączone opcje deduplikacji i kompresji dla zasobów, których przyszłe obciążenie I/O trudno ocenić, a przestrzeń dyskowa jest obszerna. Pora na syntetyczne sprawdzenie jak radzą sobie mechanizmy oszczędzania miejsca.
Domyślnie dla FreeNAS zalecana jest dostępna pamięć RAM 8GB. Można wstępnie przyjąć, że dla aktywnej opcji deduplikacji na każdy 1TB miejsca na dysku należy przeznaczyć 5GB dodatkowego RAM.
System plików ZFS
FreeNAS pozwala na konfigurację kilkoma kliknięciami systemu plików ZFS, który wspiera kompresję oraz deduplikację zapisywanych danych. W zależności od rodzaju danych możemy zaoszczędzić przestrzeń dyskową kosztem obciążenia CPU oraz zajętości RAM, a także szybkości zapisu/odczytu.
FreeNAS pozwala na skonfigurowanie mechanizmów kompresji i deduplikacji a także ich wyłączenie. Jaki wpływ na wydajność będą miały ustawienia?
Warunki testów wpływu konfiguracji ZFS na wydajność FreeNAS
FreeNAS 9.3 pracował jako maszyna wirtualna na platformie VirtualBox, który udostępniał dysk 8GB na system maszyny, cztery wirtualne procesory i 10GB RAM, maszyna fizyczna była wyposażona w fizyczny procesor i3-2120 3.3GHz.
FreeNAS wyposażony był w kartę sieciową 1GBE, która symulowała typowe domowe warunki, w środowiskach biznesowych można się spodziewać 10GBE a nawet FC lub w słabszej wersji trunk kilku połączeń 1GBE. Dla testu rozwiązań domowych połączenie 1GBE było wystarczające mimo, że ograniczało maksymalne przepustowości. Drugim ograniczeniem była wydajność wirtualnych procesorów, a także zasoby pamięci RAM (szczególnie dla deduplikacji).
Tutaj znajdziecie więcej informacji o deduplikacji.
W normalnym zastosowaniu FreeNAS powinien zapisywać dane na kilku dyskach pracujących w grupie RAID, co zapewni odporność na awarię jednego z nich. Do wyboru mamy:
RAID1 (mirror - dane zapisywane jednocześnie na dwóch dyskach, przy awarii jednego z nich dysponujemy drugim z identyczną zawartością)
RAID10 (mirror stripów - dane zapisywane są naprzemiennie (RAID0) na dwa dyski co daje wydajność, jednocześnie dwa kolejne dyski z taką samą zawartością tworzą mirror (RAID1))
RAID5 i RAID6 został określony jako RAID Z1 (odporność na awarię jednego dysku), RAID Z2 (odporność na awarię dwóch dysków), RAID Z3 (odporność na awarię trzech dysków).
W tego typu poziomach RAID dane zapisywane są sekwencyjnie (strip - wydajność) na kilku dyskach, natomiast bezpieczeństwo zapewnia mechanizm sum kontrolnych zapisywanych na kolejnym dysku.
Tutaj znajdziecie więcej podstawowych informacji o RAID.
Podczas testów FreeNAS pracował z wirtualnym dyskiem 64GB będącym plikiem na dysku SSD pozwalającym ograniczyć wpływ wydajności dysku na wyniki testu. W realnych warunkach należy się liczyć z dodatkowym obciążeniem CPU przez mechanizmy obliczania sum kontrolnych RAID (chyba, że korzystamy z zasobu udostępnianego przez kontroler sprzętowy).
Rodzaje danych testowych kopiowanych na zasób udostępniany przez FreeNAS (łącznie 40.8GB):
Do testów mechanizmów kompresji i deduplikacji, zostało przygotowanych kilka zestawów danych testowych.
ISO 10.8GB
Bardzo słabo kompresowalne dane,
obrazy płyt instalacyjnych różnych dystrybucji Linux.
Rozmiar po kompresji 7z LZMA2 10.6GB.
umcomp.dat 10GB
Niekompresowalny plik - zaszyfrowane dane.
Rozmiar po kompresji 7z LZMA2 10GB.
big.dat 10GB
Kompresowalny plik binarny.
Rozmiar po kompresji 7z LZMA2 2.35GB.
text.txt 10GB
Super kompresowalny plik tekstowy.
Rozmiar po kompresji 7z LZMA2 10MB.
W ramach testu ustawień ZFS, powyższe dane testowe były kopiowane na udział testowy. Po zakończeniu kopiowania oceniana była zajmowana przestrzeń dyskowa NAS oraz zajętość zasobów CPU i RAM podczas operacji kopiowania (FreeNAS udostępnia graficzny monitor zasobów). Na koniec wykonywany był test szybkości zapisu i odczytu, dane generowane w tym teście miały charakterystykę zgodną z plikiem testowym big.dat.
Dla testu deduplikacji, dodatkowo został sprawdzony stan zajętości po dwukrotnym skopiowaniu katalogu ISO.
Dane udostępniane były protokołem blokowym iSCSI. Na początek w konfiguracji protokołu iSCSI utworzony został portal udostępniający zasoby:
Z tym portalem na adresie interfejsu NAS będziemy się łączyć korzystając z inicjatora iSCSI w kliencie pod kontrolą Windows 7.
Następnie konfigurujemy inicjator iSCSI:
a także grupa autoryzowanych użytkowników:
W kolejnym etapie dodajemy element docelowy, konfigurujemy przynależność do portalu oraz inicjatora, jeżeli wybierzemy autoryzację przypiszemy także grupę użytkowników mogących połączyć się z określonym celem:
kolej na utworzenie ekstentu, który będzie powiązany z urządzeniem lub plikiem, możemy też określić rozmiar bloku:
na koniec łączymy extent z targetem, czyli mapujemy plik lub urządzenie do zasobu w iSCSI, możemy określić numer LUN lub pozostawić opcję automatycznej numeracji:
Tyle po stronie serwera FreeNAS, udostępniany zasób podłączymy w komputerze klienta pracującym pod kontrolą W7, zasób będzie widoczny jako kolejny dysk.
Wybieramy Panel sterowania->Narzędzia administracyjne->inicjator iSCSI.
Po połączeniu z FreeNAS tworzymy nową partycję i formatujemy ją:
Brak kompresji i deduplikacji
Na początek wypróbujmy ustawienia, w których rezygnujemy z kompresji i deduplikacji.
Udostępniamy pusty zasób:
Po skopiowaniu plików testowych nie jest niespodzianką, że zajmują one 40.8GB:
Szybkość zapisu wynosiła 40MB/s natomiast odczytu 59MB/s,
będzie to punkt odniesienia do kolejnych prób.
Interfejs FreeNAS udostępnia dane o zajętości pamięci RAM oraz obciążeniu procesora, tak wyglądało obciążenie zasobów podczas testu:
Obciążenie procesora na poziomie 40-50% oraz stała zajętość pamięci około 8GB.
Kompresja "w locie".
Zaczniemy od zalecanej kompresji lz4.
Umieszczone pliki iso, uncomp zajęły -> 19.9GB
rozmiar praktycznie identyczny jak pierwotny, czyli nie widać tutaj zysku z kompresji, lecz dane są trudno kompresowalne.
Dodajemy pliki big.dat otrzymujemy zajętość -> 30.4GB
na razie nie widać zysków z kompresji, umieściliśmy 3x10GB i zajętość jest na poziomie 30GB.
Umieszczamy plik text.txt zajętość -> 31GB
tutaj widać zysk z kompresji, mimo umieszczenia kolejnego 10GB pliku zajętość wzrosła o 0.6GB.
Całkowita zajętość 31GB około 76% 40.8GB, czyli zajętości bez mechanizmów kompresji.
Szybkość zapisu wynosiła 43MB/s, natomiast odczytu 52MB/s,
zapis o 3MB/s szybszy niż w przypadku próby kontrolnej, odczyt wolniejszy o 7MB/s. Ciekawym efektem jest szybszy zapis, prawdopodobnie na dysk trafiały skompresowane dane co wymagało mniejszej liczby operacji I/O.
W niewielkim stopniu wzrosło zapotrzebowanie na CPU, zalecana kompresja lz4 przyniesie oszczędności zajętego miejsca w przypadku kompresowalnych plików przy niewielkim zwiększeniu obciążenia systemu.
Sprawdźmy działanie gzip na poziomie kompresji domyślnej 6 (default level 6).
Pliki iso, uncomp.dat -> 20.2GB,
bez niespodzianek, brak kompresji.
Plik big.dat -> 28.2GB,
tutaj widać działanie lepszego mechanizmu kompresji niż lz4
Następnie plik text.txt -> 28.5GB,
łącznie lepiej o 2.5GB w porównaniu do lz4.
Całkowita zajętość 28.5GB około 70% 40.8GB, czyli zajętości bez mechanizmów kompresji.
Szybkość zapisu wynosiła 16MB/s, natomiast odczytu 52MB/s,
wyraźne spowolnienie zapisu (2.5x w porównaniu do braku kompresji) oraz szybkość odczytu na poziomie lz4.
Obciążenie CPU sięgające nawet 100%, zależne od rodzaju napływających danych, obciążenie RAM bez zmian. Wybór gzip na poziomie 6 trzeba dobrze przemyśleć, jeżeli głównie zależy nam na oszczędności miejsca, napływające dane są kompresowalne, akceptujemy niższą szybkość zapisu oraz większe obciążenie, można wybrać ten tryb kompresji.
Sprawdźmy działanie gzip na poziomie najszybszym (fastest).
Pliki iso.dat, uncomp.dat -> 21GB,
bez niespodzianek, praktycznie brak kompresji.
Plik big.dat -> 28.3GB,
prawie tak dobrze jak na poziomie gzip 6.
Następnie plik text.txt -> 28.5,
dla tych danych testowych wynik identyczny jak dla kompresji gzip 6.
Całkowita zajętość 28.5GB około 70% 40.8GB, czyli zajętości bez mechanizmów kompresji.
Szybkość zapisu wynosiła 32MB/s, natomiast odczytu 50MB/s,
szybkość zapisu dwukrotnie lepsza niż w przypadku gzip poziom 6,
ciekawa opcja konkurencyjna dla lz4, wolniejsza lecz oferująca nieco lepszy współczynnik kompresji.
Obciążenie CPU sięgające 80%.
Deduplikacja.
Dla prób deduplikacji zmieniłem nieco ustawienia, tak aby zwiększyć prawdopodobieństwo, że 4kB blok z hosta będzie odwzorowany bez zmian na poszczególnych etapach przetwarzania. W tym celu ustawiłem 4kB blok dla nowego woluminu zvol, 4kB blok dla extentu iSCSI oraz 4kB blok podczas formatowania partycji w systemie Windows:
Warto poeksperymentować i sprawdzić, czy ustawienia wielkości bloków będą miały wpływ na skuteczność działania deduplikacji oraz szybkość zapisu i odczytu.
Dla woluminu została uruchomiona deduplikacja ZFS:
Na początek umieszczamy na zasobie dwukrotnie pliki iso co daje 2x10.8GB=21.6GB. Dzięki deduplikacji pliki o rozmiarze 21.6GB zajmują na dysku ->12.9GB.
Widać prawie dwukrotną oszczędność w przypadku umieszczania dwóch identycznych kopii plików.
Możemy wykonać estymację skuteczności deduplikacji, wydając polecenie zdb -S nazwa woluminu:
Wydając polecenie zpool list możemy przyjrzeć się szczegółom:
Deduplikacja może funkcjonować wraz z mechanizmem kompresji uruchomionym na danym zasobie. Nie sprawdzałem takiego połączenia na uruchomionej maszynie wirtualnej. Warto wypróbować połączenie obu mechanizmów we własnym zakresie.
Tworzymy zasób ponownie i wykonajmy test taki sam jak dla kompresji, czyli kopiowanie zestawu plików testowych.
Pliki iso, uncomp.dat -> 25.1G
brak efektów oszczędności miejsca
big.dat -> 29.9
zajętość praktycznie równa oryginalnej wielkości
text.txt -> 35.4G
widać działanie mechanizmów oszczędzania miejsca.
Całkowita zajętość 35.4GB około 87% 40.8GB, czyli zajętości bez mechanizmów kompresji.
Zapis na poziomie 9MB/s, odczyt 49MB/s, zapis ponad czterokrotnie wolniejszy niż z wyłączonymi mechanizmami kompresji i deduplikacji.
Więcej informacji o woluminach ZFS z aktywną deduplikacją otrzymamy wydając polecenia zdb -D nazwa_woluminu oraz zpool iostat -v, aby sprawdzić aktywność na poszczególnych zasobach.
Zobaczmy jakich zasobów potrzebuje deduplikacja:
Wykorzystanie CPU dochodzi do 90%, zajętość pamięci dość mocno się zmienia i dochodzi do 10GB, niestety po raz pierwszy w czasie testów został aktywowany swap, co zapewne miało wpływ na test wydajnościowy. Deduplikacja może sprawdzić się jeżeli wielokrotnie zapisujecie podobne dane, należy liczyć się z dużym zapotrzebowaniem na pamięć RAM oraz CPU, a także obniżenie wydajności zapisu i odczytu.
Pełna moc.
Powyższe testy pozwoliły na sprawdzenie możliwości kompresji i deduplikacji w sposób dostępny dla większości domowych użytkowników komputerów.
Widać że CPU, RAM oraz przepustowość sieci ograniczały możliwości wydajnościowe FreeNAS. Co się stanie gdy zwolnimy hamulec?
Spróbujmy uruchomić FreeNAS na maszynie wirtualnej pracującej na jednym z serwerów kasetowych obudowy HP blade, oddając do dyspozycji NAS cztery wirtualne procesory obsługiwane przez procesory Xeon E5-2600 v2 oraz 32GB RAM, a także podłączmy zasób dyskowy na szybkiej macierzy EMC.
FreeNAS będzie udostępniał zasoby iSCSI po emulowanej karcie e1000, przepustowość sieci będzie prawdopodobnie wąskim gardłem tej konfiguracji testowej. Ruch po między kartą sieciową FreeNAS, a kartą 10GBE klienta będzie obsługiwany przez wirtualny przełącznik.
Brak kompresji.
FreeNAS uruchomiony na tak mocnej maszynie osiągał zapis z prędkością 89MB/s, odczyt 148MB/s, widać że emulacja kart sieciowych jest bardzo efektywna (prędkość odczytu przewyższa typową teoretyczną przepustowość dla fizycznego połączenia 1GBE). Obciążenie CPU na poziomie 40-50%.
Kompresja lz4.
Zapis z prędkością 88MB/s, odczyt 133MB/s, obciążenie CPU na poziomie 40-50%.
Kompresja gzip default.
Zapis z prędkością 34MB/s, odczyt 89MB/s, obciążenie CPU na poziomie 80%. Lepsze zasoby CPU pozwalają na zachowanie stabilności działania FreeNAS.
Deduplikacja
Zapis z prędkością 83MB/s, odczyt 166MB/s, obciążenie CPU na poziomie 70%. Udało się nie wykorzystywać zasobów swap. Widać że deduplikacja może sprawnie działać, jednak potrzebne są odpowiednie zasoby RAM i CPU.
Tutaj widać jakie wyzwanie stoi przed dostawcami gotowych rozwiązań pamięci masowych "uszytych na miarę", pozwalających na wydajne korzystanie z udostępnianych funkcji.
Wiele rozwiązań wspomaga CPU rozwiązaniami sprzętowymi, np. sprzętowa kompresja (karty kompresji inline), sprzętowe obliczanie sum kontrolnych RAID (kontrolery SAS), sprzętowe wspomaganie Thin Provisionin (np. wykrywanie zapisu zer) i wiele innych ciekawych rozwiązań zwiększających szybkość zapisu i odczytu (np. bufory flash).
Nie tylko FreeNAS.
Bezpłatna dystrybucja FreeNAS umożliwia w prosty sposób zapoznanie się z podstawowymi cechami zasobów udostępnianych przez NAS, dystrybucję możemy wykorzystać zarówno w domu, jak również zasobach testowych, a także produkcyjnych. Możemy znaleźć wiele innych rozwiązań podobnych do FreeNAS o różnym zakresie funkcjonalności, np. openfiler, nas4free, napp-it, dedykowane bardziej użytkownikom domowym np. openmediavault, amahi. Dostępne jest także dość tanie płatne oprogramowanie serverelements.com umożliwiające budowę swojego serwera pamięci masowej, a także bardziej zaawansowane rozwiązania udostępniające bezpieczną składnicę danych flexraid do budowy większych systemów, unRAID. Równolegle z FreeNAS zbudowany jest truenas, który dostępny jest w gotowych urządzeniach przeznaczonych do zastosowań biznesowych TrueNAS unified storage.
Czy korzystacie z ZFS, deduplikacji, lub kompresji w środowiskach produkcyjnych?
Cool? Ranking DIY
I zdaje się, że tak to jest robione.
