NFS czy iSCSI?

Protokoły iSCSI i NFS mają swoje mocne i słabe strony. Każda z technologii - umożliwiających połączenie z pamięcią masową przez sieć Ethernet - ma swoich zwolenników i przeciwników. Czy można stwierdzić, że jedna z nich jest po prostu lepsza od drugiej?

NFS jest dziełem Sun Microsystems (firmy przejętej w 2009 r. przez Oracle) i powstał na początku lat 80. ubiegłego wieku jako uniwersalny protokół udostępniania plików, pozwalający klientom na ich zapisywanie i odczyt przez sieć. Jego konkurent - iSCSI -narodził się wiele lat później, bo w 2002 r. Został opracowany przez IETF jako oparta na IP, tańsza alternatywa dla Fibre Channel i podobnie jak FC operuje na poziomie bloków. Obie technologie mają sporo różnic - swoje wady i zalety. Trudno jednoznacznie powiedzieć, która z nich jest lepsza. Będzie to zależeć od konkretnego zastosowania. Skoro już wiemy, że nie ma oczywistego lidera - przyjrzyjmy się lepiej obu rozwiązaniom.

iSCSI i NFS z perspektywy sieci

Gdy spojrzymy na naszych konkurentów od strony sieci, na wyraźne prowadzenie wysunie się iSCSI. Jego ogromną zaletą jest wbudowana redundancja i możliwość agregacji łączy. Służy do tego MPIO - funkcja pozwalająca na obsługę przez pamięć masową wielu ścieżek danych. Skorzystanie z MPIO pozwoli zapewnić redundantne połączenie z danymi bądź poprawić przepustowość - wszystko to bez wnikania w konfigurację kart sieciowych i sztuczek z ich teamingiem.

Skoro wymieniliśmy MPIO jako przewagę iSCSI, nietrudno się domyślić, że czegoś takiego nie mamy w NFS, tutaj jednak z pomocą przyjdą nam wspomniane sztuczki z kartami sieciowymi. W typowej konfiguracji serwery z adresem IP przypisanym do spiętych kart sieciowych komunikują się z pamięcią masową przez dwa połączone w stos przełączniki. Od strony pamięci masowej wygląda to podobnie, z tą różnicą, że tu adres IP będzie przypięty nie do fizycznych interfejsów, a do aliasów (adresy fizycznych interfejsów są wykorzystywane do równoważenia ruchu). W takim scenariuszu błąd (przerwanie jednego z połączeń bądź awaria przełącznika) zostanie obsłużony na poziomie oprogramowania spinającego karty - czyli poza klientem NFS i serwerem.

W przypadku iSCSI wykorzystywane są oddzielne interfejsy sieciowe - każdy z własnym adresem IP (i na serwerze, i na pamięci masowej). Jeśli inicjator i cel iSCSI zostały prawidłowo skonfigurowane, serwer i storage zestawią wiele ścieżek - każdy z interfejsów serwera zestawi połączenie z każdym interfejsem sieciowym macierzy (przy dwóch interfejsach z każdej ze stron będzie ich więc cztery). W razie zerwania któregoś z redundantnych połączeń inicjator iSCSI zidentyfikuje niedziałające ścieżki i skieruje ruch przez dwie pozostałe.

Szczegóły współpracy inicjatora (serwer) i celu (pamięć masowa) zależą od konkretnego oprogramowania użytego na serwerze. Nieco inaczej zrobi to Microsoft iSCSI initiator, jeszcze inaczej rozwiązanie wbudowane w VMware vSphere, a jeszcze inaczej Dell EqualLogic SAN. Warto zajrzeć do dokumentacji producenta pamięci masowej i przejrzeć fora wsparcia technicznego pod kątem najlepszych praktyk odpowiednich dla naszej OS i pamięci masowej. Jeśli chcemy wycisnąć jak najwięcej z naszej sieci i pamięci masowej - proste dodanie adresów IP i skonfigurowanie inicjatora raczej nie wystarczy.

Zarówno w przypadku NFS, jak i iSCSI load balancing będzie miał małe znaczenie, jeśli korzystamy z łącza 10 GB/s. Wtedy wąskim gardłem będzie po prostu wydajność samej macierzy - jednak problem redundatnego łącza a tym samym poprawienie bezpieczeństwa, wart będzie rozpatrzenia i dla takich prędkości.