r   e   k   l   a   m   a
r   e   k   l   a   m   a

Raspberry Pi jako domowy serwer plików – nie ma się czego wstydzić

Strona główna AktualnościSPRZĘT

Na początku trzeba powiedzieć sobie otwarcie – Raspberry Pi nie jest idealnym komputerkiem do budowy dysku sieciowego (NAS). Brak jej kontrolera SATA, wszystkie złącza USB i gniazdo Ethernetu zmuszone są do współdzielenia pojedynczego, półdupleksowego kontrolera USB 2.0 (tylko 480 Mbit/s), a zasilanie jest słabe. Czemu więc w ogóle próbować? Odpowiedź jest prosta: Raspberry Pi jest tanie i cieszy się świetnym wsparciem społeczności. Jak zaś pokażemy, w zastosowaniach czysto domowych może być całkiem dobrym NAS-em. Podpinając do niego nawet zwykły, tani dysk twardy 2,5” ze starego laptopa uzyskamy sprzęt wystarczający do tego, by np. strumieniować filmy w rozdzielczości FullHD – wystarczy jedynie Malinę odpowiednio skonfigurować.

Zasilanie: pół ampera to za mało

Pierwszym problemem, z jakim się spotkacie przy próbie podłączenia do Raspberry Pi zewnętrznego dysku, będzie jego zasilanie. W wypadku dysków 3,5” nie ma co się spodziewać, że Malina sobie z nimi poradzi, kieszenie na takie zewnętrzne dyski i tak są zresztą oferowane z własnymi zasilaczami. Wydawałoby się, że wypadku dysków 2,5” takich problemów nie będzie – w końcu po podpięciu ich do peceta zazwyczaj działają bez problemu. Jednak w standardowej konfiguracji Raspberry Pi oferuje na USB 2.0 zaledwie 0,6 A – za mało, by obsłużyć taki dysk twardy.

W niniejszym artykule udział wzięły:

r   e   k   l   a   m   a
  • Raspberry Pi 2 Model B
  • chińska ładowarka microUSB 5 V 2,1 A
  • przejściówka JMicron JM20329 SATA-USB Bridge
  • Dysk twardy Western Digital WD5000BPKT

Rozwiązania są dwa. Pierwsze sprzętowe, polega na wykorzystaniu aktywnego huba USB 2.0. Przeznaczony specjalnie do Raspberry Pi hub PiHut pozwala na podłączenie nawet siedmiu urządzeń USB i kosztuje ok. 65 zł. Zaletą tego rozwiązania jest to, że w ten sposób podłączyć będziemy mogli więcej niż jeden dysk i skonfigurować software'ową macierz RAID. Wadą – oczywiście cena, oraz zwiększenie plątaniny kabli, hub ma oczywiście swój własny zasilacz. Jeśli zamierzacie podłączyć po prostu jeden zewnętrzny dysk przez mostek USB-SATA, poradzić sobie można i bez aktywnego huba.

W tym celu zaczniemy (na wszelki wypadek od aktualizacji firmware Maliny. Po uruchomieniu Raspbiana, w teminalu wydajemy polecenie sudo rpi-update, a gdy zakończy pracę, sudo reboot. Po restarcie musimy przeedytować plik konfiguracyjny config.txt. Wydajemy więc polecenie sudo nano /boot/config.txt, dodając tam linijkę

max_usb_current=1

Opcja ta nie działała w starszych wersjach firmware (trzeba było ustawiać wtedy konfigurację szyny GPIO). Jeśli wiecie, że macie najnowszą wersję, możecie oczywiście aktualizację pominąć. Po restarcie (sudo reboot) i podłączeniu dysku po USB, powinien on się uaktywnić.

Jeśli się nie uaktywnił, należy sprawdzić stan pinu 38 szyny, wydając polecenie gpio -g read 38. Jeśli w wyniku otrzymamy 1, to znaczy, że natężenie prądu jest wystarczające i problem leży np. w kontrolerze lub dysku. Jeśli w wyniku otrzymamy 0, należy wydać polecenie gpio -g write 38 1. Jeśli i to nie pomoże, najpewniej mamy za słaby zasilacz dla Maliny – sam komputerek może potrzebować 0,8-1 A, a co dopiero dysk? Telefoniczna ładowarka tu nie wystarczy, najlepiej użyć przynajmniej tych tabletowych ładowarek 2,1 A.

Gdy usłyszymy charakterystyczny dźwięk uruchamianego dysku, możemy wydać polecenie sudo blkid, by zobaczyć listę wszystkich podpiętych urządzeń blokowych. W wypadku Raspbiana dysk twardy pojawi się na niej na końcu, jako urządzenie /dev/sda1.

Konfiguracja dysku

Pierwszym krokiem powinno być sformatowanie dysku. Najprawdopodobniej taki dysk zewnętrzny będzie już sformatowany w którymś z windowsowych systemów plików, FAT32 lub NTFS. Co prawda linuksowy system naszej Maliny może je obsłużyć, ale powiedzmy sobie szczerze, ich wydajność jest kiepska. O wiele lepiej będzie skorzystać z natywnych linuksowych systemów plików. Który wybrać? Z przeprowadzonego przez nas porównania, polegającego na kopiowaniu pliku 1 GB z karty microSD na zewnętrzny dysk, uzyskaliśmy następujące wyniki:

FAT32: 21 MB/s (i pamiętajmy o nieobsługiwaniu uprawnień dostępu)
NTFS: 3,7 MB/s (naprawdę źle)
EXT4: 28 MB/s
XFS: 30 MB/s

Stworzony dawno temu dla stacji roboczych z systemem Irix XFS jest dziś tak dojrzały i wydajny, że wybrano go jako domyślny system plików na biznesowej klasy systemu Red Hat Enterprise Linux. Z naszych doświadczeń wynika, że to obecnie najlepszy system plików do takich zastosowań jak dyski NAS. Jego jedyną wadą jest to, że stosunkowo trudno podpiąć sformatowany w nim dysk do komputera z Windowsem – dostępne narzędzia obsługują go tylko w trybie do odczytu. Co robić, Microsoft nigdy sobie nie radził z obsługą innych niż własne systemów plików. Jeśli zależy Wam na wydajności, polecamy więc XFS, jeśli na kompatybilności z „okienkami” – lepiej wybrać EXT4.

Aby zmienić system plików na zewnętrznym dysku, wykrytym jako /dev/sda1, wydajemy polecenie sudo cfdisk. W tej łatwiejszej w użyciu odmianie fdiska wybieramy z menu opcję Type, a następnie z listy Select Partition Type wybieramy 83 – Linux. Następnie zapisujemy zmiany, wybierając Write (i odpowiadajac na pytanie „yes”). O powodzeniu operacji będzie świadczył komunikat The partition table has been altered. Z programu wychodzimy przez Quit i bierzemy się do formatowania.

Do sformatowania w systemie EXT4 wykorzystuje się polecenie mkfs.ext4, zaś do sformatowania w systemie XFS – mkfs.xfs. By skorzystać z tego ostatniego, musimy jednak w Raspbianie doinstalować pakiet narzędzi XFS, poleceniem sudo apt-get install xfsprogs. Samo formatowanie polega na wydaniu polecenia sudo mkfs.xfs /dev/sda1 -f lub sudo mkfs.ext4 /dev/sda1 -f.

Teraz należy przygotować katalog, pod którym będzie zamontowany nasz dysk, poleceniem sudo mkdir /mnt/extdisk (oczywiście zamiast extdisk możecie użyć własnej nazwy). Możemy od razu założyć w nim podkatalogi, które będą oferowane jako zasoby sieciowe, np. publiczny i prywatny, na hasło – poleceniem mkdir /mnt/extdisk/public && mkdir /mnt/extdisk/files.

Zamontowanie podpiętego dysku zapewni dziś automatycznie system (choć w razie czego można zrobić to ręcznie, poleceniem sudo mount /dev/sda1 /mnt/extdisk, ale w sytuacji, gdy chcemy korzystać z Maliny jako NAS-a, trzeba to zrobić tak, by dysk był montowany podczas startu.

W tym celu zmodyfikujemy tablicę fstab, korzystając z unikatowego identyfikatora nośnika (UUID) – dość długiej szesnastkowej liczby. Zobaczymy ją, wydając polecenie sudo blkid, które wyświetli nam /dev/sda1: UUID="xxxx-xxxx-xxxx". Liczbę kopiujemy do schowka i otwieramy plik fstab poleceniem sudo nano /etc/fstab.

Musimy teraz na końcu dopisać linijkę UUID=xxxx-xxxx-xxxx /mnt/extdisk xfs nofail,defaults 0 0. Po zapisaniu pliku, sprawdzamy, czy konfiguracja jest poprawna poleceniem sudo mount -a. Jeśli nie pojawią się informacje o błędach, możemy zrestartować system poleceniem sudo reboot.

W razie problemów z UUID możemy we wpisie do fstab wykorzystać nazwę napędu, w powyższym wypadku będzie to /dev/sda1 /mnt/extdisk xfs nofail,defaults 0 0. Różnica jest taka, że używając UUID mamy pewność, że podłączenie innego nośnika niczego nie zmieni – system zawsze będzie się odwoływał do konkretnego dysku o takim identyfikatorze.

Po zrestartowaniu należy ustawić prawa własności i dostępu dla domyślnego użytkownika pi, tak by także w przyszłości były one zachowane. Zrobimy to poleceniami:

sudo chown -R pi:pi /mnt/extdisk/
sudo chmod -R 775 /mnt/extdisk/
sudo setfacl -Rdm g:pi:rwx /mnt/extdisk/
sudo setfacl -Rm g:pi:rwx /mnt/extdisk/

Wydawałoby się, że to już wszystko – a jednak nie. Przy specyfice pracy NAS nasz dysk zewnętrzny długo nie pożyje, jeśli nie damy mu czasem odpocząć. Zrobimy to za pomocą narzędzia hdparm. By sprawdzić, czy obsługuje on tryb standby, wydajemy polecenie sudo hdparm -y /dev/sda. Jeśli dysk ucichnie, a w konsoli pojawi się komunikat /dev/sda: issuing standby command, to wszystko dobrze. Sprawdzamy następnie obsługę buforu zapisu: sudo hdparm -I /dev/sda | grep cache. W odpowiedzi powinniśmy uzyskać * Write cache.

Jeśli tak jest, to pozostaje jedynie zmienić na stałe konfigurację w pliku hdparm.conf. W tym celu wydajemy polecenie sudo nano /etc/hdparm.conf i dopisujemy na końcu:

/dev/sda {
write_cache = on
spindown_time = 120
}

Wartość parametru spindown_time pomnożona przez pięć daje nam liczbę sekund: 120 oznacza więc 600 sekund, 10 minut. Możecie to oczywiście dowolnie modyfikować.

Jeśli korzystacie ze starego dysku, który nie obsługuje standby ani write cache, możecie skorzystać z narzędzia hd-idle. Autor przetestował hd-idle ze starożytnym dyskiem 30 GB Hitachi, podłączanym przez przejściówkę IDE-USB, więc jeśli macie tak stary sprzęt, możecie z nim spróbować. Opisanie tego narzędzia wychodzi jednak poza ramy artykułu – praktycznie wszystkie współcześnie spotykane dyski powinny działać z hdparm.

Igraszki w sieci (lokalnej)

Mając już skonfigurowane Raspberry Pi z zewnętrznym dyskiem, pozostaje nam udostępnić jego zasoby pamięci masowej w naszej sieci. Tu mamy do dyspozycji dwa rozwiązania – albo skorzystać z sieciowego systemu plików NFS, albo z windowsowego systemu SMB. Każde z nich ma swoje wady i zalety. NFS jest wydajniejsze, bardziej niezawodne i mniej obciąża system, jednak skorzystanie z niego na komputerach z Windowsem jest dość kłopotliwe. SMB działa jak działa, ale w środowisku Windows nie powinno być z nim żadnych problemów.

Jeśli korzystacie więc głównie z Windowsa, wykorzystajcie SMB. Jeśli zaś korzystacie z Maka, na swoim PC zainstalowaliście Linuksa, czy chcecie strumieniować wideo z Malinki do np. linuksowego odtwarzacza z Kodi, wybierzcie NFS. Oczywiście można zrobić jedno i drugie.

Samba

Zacznijmy od instalacji i konfiguracji serwera SMB. Na Linuksie nosi on nazwę Samba. Instalujemy go poleceniem sudo apt-get install samba samba-common-bin. Po kilku minutach, w trakcie których doinstalowane zostanie jeszcze kilkanaście pakietów, „windowsowa” technologia zagości na Malinie. Konfiguracja Samby znajduje się w pliku /etc/samba/smb.conf. Na początku możemy zmienić tu nazwę grupy roboczej (domyślnie WORKGROUP), oraz dodać w sekcji [global] wpisy security = user oraz load printers = no.

Zdefiniujemy teraz dwa zasoby SMB, publiczny i dla zalogowanych użytkowników.

[public]
comment = Katalog publiczny
read only = no
locking = no
path = /mnt/extdisk/public
create mask= 0666
directory mask = 0777
guest ok = yes
[Files]
comment = Pliki użytkowników
path = /mnt/extdisk/files
valid users = @users
force group = users
create mask = 0660
directory mask = 0771
read only = no

Dla domyślnego użytkownika pi należy teraz zdefiniować hasło, poleceniami sudo touch /etc/samba/smbpasswd && sudo smbpasswd -a pi, a następnie zrestartować serwer Samby poleceniem sudo service smbd restart. W chwilę później w sieci lokalnej powinniśmy zobaczyć udostępnione zasoby SMB.

Możecie wypróbować zastosowanie optymalizacji ruchu sieciowego SMB – niektórzy radzą dodać wpis
socket_options =TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536. Niestety u nas nie przyniosło to zauważalnych rezultatów.

NFS

Instalacja NFS jest jeszcze prostsza. Serwer instalujemy poleceniem sudo apt-get install nfs-kernel-server. Następnie otwieramy plik eksportowym, w którym ustalamy ścieżki dostępu i ich uprawnienia, poleceniem sudo nano /etc/exports.

Na komputerach z Linuksem i Makach podłączenie się do zasobu NFS wygląda tak samo, jak każdego innego systemu plików. Aby zobaczyć to, co udostępnia host o adresie np. 192.168.1.45, wydajemy polecenie showmount -e 192.168.1.45. Aby podłączyć zasób np. pod /mnt/nfs, wydajemy polecenie sudo mount -t nfs 192.168.1.45: /mnt/nfs (albo na Maku wykorzystujemy Findera, który sam ładnie znajduje zasoby NFS). Oczywiście można takie zasoby powiązać na stałe z klientem, na Linuksie modyfikując plik /etc/fstab, a na Maku wykorzystując systemowy Disk Utility. Więcej znajdziecie w dokumentacji – możliwości jest tu bardzo dużo, ich opis wykracza poza ten poradnik. A co z Windowsami? Tu polecamy zainteresować się projektem nekodrive, dzięki któremu zasób NFS będzie widziany przez „okienka” jako lokalny dysk.

Najprostszą metodą udostępnienia całej zawartości /mnt/extdisk będzie dodanie tam wiersza /mnt/extdisk *(rw,sync) – pozwala on każdemu klientowi, z dowolnego adresu IP, pisać i czytać zawartość tego katalogu. Jeśli z kolei chcemy ograniczyć się do własnej sieci lokalnej, możemy spróbować z /mnt/extdisk 192.168.10.0/24(rw,sync).

W nawiasach okrągłych podajemy właściwości danego zasobu. rw oznacza prawo do zapisu i odczytu, ro tylko odczytu. sync to bezpieczny tryb synchroniczny, w którym serwer czeka z zakończeniem poprzedniej operacji, async to nieso szybszy i nieco mniej bezpieczny tryb asynchroniczny. W razie problemów z przeszukiwaniem podkatalogów można zastosować opcję no_subtree_check. Opcja all_squash pozwala zaś ustawiać prawa do pliku na anonimowego użytkownika, co przydatne jest w publicznych katalogach. Z kompletną listą opcji eksportu NFS możecie zapoznać się w dokumentacji.

Teraz pozostaje jedynie wyeksportować konfigurację i uruchomić usługi sieciowe.

sudo exportfs -ra
sudo service rpcbind start
sudo service nfs-common start
sudo service nfs-kernel-server start

Wnioski: nie ma się czego wstydzić

Jak wygląda wydajność naszego prostego serwera plików na Raspberry Pi? Całkiem nieźle, jak na ograniczenia tego sprzętu. Dla kierunku serwer›klient, przy kopiowaniu w sieci lokalnej pliku o rozmiarach ok. 1 GB przez SMB osiągnęliśmy średnio 6,4 MB/s. Korzystając z NFS udało się uzyskać średnio ponad 11 MB/s. Przy kopiowaniu klient›serwer udało się uzyskać dla SMB ok. 6,2 MB/s, dla NFS 10,3 MB/s

Przy kopiowaniu katalogu z ok. setką zdjęć JPG z serwera uzyskaliśmy dla SMB ok 6,3 MB/s, dla NFS ok. 8,9 MB/s, w drugą stronę dla SMB 6,3 MB/s, zaś dla NFS 8,8 MB/s.

Biorąc pod uwagę to, że najlepsza teoretyczna przepustowość dla Ethernetu 100 Mb/s między Raspberry Pi i klientem wynosi 11,8 MB/s (teoretyczna – czyli bez jakiegokolwiek narzutu, przy bezpośrednim połączeniu kablowym między urządzeniami), wynik uzyskany za pomocą domyślnej konfiguracji NFS jest znakomity.

Uzyskane wyniki dla Samby niekoniecznie świadczą o zawodności serwera smbd. Problem leży tu bardziej po stronie linuksowego klienta. Kopiowanie tego samego pliku >1 GB przy użyciu laptopa z Windows 7 przyniosło wyniki na poziomie 8,2 MB/s (z serwera) i 7,7 MB/s (na serwer). Wciąż gorzej niż NFS, ale różnica nieco stopniała.

Jak widać, w domowych zastosowaniach Raspberry Pi może być prostym serwerem plików, szczególnie jeśli domowa sieć zrobiona jest na Ethernecie 100 Mb/s i/lub Wi-Fi 802.11 g/n. To nie Malina będzie tu wąskim gardłem, lecz kabelek, którego przepustowość łatwo wysycić z wykorzystaniem NFS czy strumieniowania mediów po DLNA. Oczywiście dzisiaj standardem jest gigabitowy Ethernet, w takiej sieci pełnowymiarowy dysk NAS (np. Synology) będzie znacznie lepszym wyborem, zarazem jednak znacznie droższym i bardziej energochłonnym.

Sytuacja jest o tyle ciekawa, że dość łatwo jest polepszyć wyniki Raspberry Pi jako serwera plików, dokupując moduł gigabitowego Ethernetu na USB. Obecnie w polskich sklepach internetowych ceny takiego sprzętu zaczynają się od ok. 70 zł, w sklepach chińskich znaleźć można taki moduł już nawet za 8 dolarów. Po jego podłączeniu do Maliny, limit przepustowości rośnie do ok. 22 MB/s, a realnie udaje się uzyskać ok. 18-20 MB/s.

Streaming, torrenty i inne atrakcje

Jednym z najczęstszych zastosowań NAS-ów jest strumieniowanie mediów i pobieranie torrentów. Raspberry Pi (przynajmniej w wersji 2) w przedstawionej konfiguracji całkiem dobrze się do tego nadaje. Lekki serwer minidlna pozwoli na wygodne strumieniowanie plików wideo, CherryMusic zamieni naszą kolekcję muzyki w internetowe radio, Transmission będzie bardzo wygodnym, zarządzanym przez przeglądarkę klientem BitTorrenta, zaś Ubooquity może posłużyć jako serwer e-booków. O tym, jak to wszystko zrobić już niebawem w naszym cyklu Raspberry Pi nie tylko dla majsterkowiczów.

Nie ma więc co skreślać Malinki z typowo NAS-owych zastosowań. Do biura oczywiście się nie nadaje, ale w domu, gdzie posłuży co najwyżej kilku użytkownikom, może być bardzo dobrym rozwiązaniem.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.