SCSI vs. NFS

Protokół SCSI nie został stworzony do transmisji w sieci. Jego właściwe miejsce to magistrala na sztywno połączona z komputerem. SCSI w wersji sieciowej to emulacja tej pierwotnej koncepcji. Emulacja czyli kłamstwo. Oszukanym w tej intrydze jest system operacyjny. Wydaje mu się, że ma dyski lokalne, a tymczasem są to wolumeny, gdzieś daleko w macierzy, na dyskach, z których korzystają też inne systemy. Nienaturalność tego układu podkreślają problemy z nomenklatura. W OS konfigurujemy WOLUMEN na DYSKU, który na macierzy jest WOLUMENEM utworzonym na wielu DYSKACH fizycznych.  Często używając tych samych słów mówimy o różnych rzeczach co prowadzi do nieuchronnych nieporozumień.

Oczywiście założenia były bardzo szczytne i do pewnego momentu odzwierciedlały potrzeby. Zaczęło się od kabli. Magistrala SCSI potrzebuje dużo miedzi. Kable były przez to grube i krótkie, a złącza awaryjne. Idealnym rozwiązaniem na ten problem okazało się zastąpienie miedzi lekkim i cienkim światłowodem. Na potrzeby tego szybkiego, szeregowego medium został stworzony protokół Fiber Channel. Zapakowano w jego ramki pakiety SCSI i powoli zaczęły nam rosnąć w serwerowniach sieci SAN. Dzięki temu mamy dziś scentralizowany storage.

Blokowy dostęp do danych, jaki realizuje protokół SCSI jest bardzo wydajny. Efektywnie wykorzystuje dostępne pasmo. Gorzej jest z zarządzaniem po stronie systemu operacyjnego. Niby wszystko da się zrobić, ale wymaga to czasu, wiedzy, doświadczenia i szczególnej ostrożności. Na przykład powiększanie filesystemu:

- powiększam wolumen na macierzy

- powiadamiam o tym OS - rescan scsi

- powiadamiam o tym volume manager
- powiększam wolumen logiczny w OS
- powiększam filesystem

Nie w każdym systemie jest to możliwe, nie zawsze można zrobić to 'w locie', a dodatkowo warto byłoby mieć na wszelki wypadek backup.

Przykład drugi - wykonanie i udostępnienie kopii danych z użyciem kopii migawkowej. Ta operacja to w sumie 11 czynności. Sporo pracy. A jak mamy to zrobić dla aplikacji, która jest na wielu systemach plików, wielu grupach dyskowych, które składają się z wielu dysków? A co jeśli takich kopii mamy kilkadziesiąt i codziennie musimy je tworzyć/odświeżać/przywracać do zapamiętanego stanu? To jest rzeczywistość wielu administratorów storage. Z jednej strony mają nowoczesne macierze dyskowe oferujące ogromne możliwości, a z drugiej systemy operacyjne używające protokołu, który ogranicza i komplikuje dostęp do danych.

Alternatywą dla blokowego SCSI są protokoły plikowe, takie jak NFS. Od początku zaprojektowany do pracy w sieci. Zapewnia naturalny dla OS dostęp do danych. System ma “świadomość”, że korzysta z zasobu sieciowego. Nie wymaga dedykowanej sieci SAN. Zapewnia spójność danych przy dostępie z wielu systemów. Jest łatwy w implementacji i zarządzaniu. Dla przykładu opisywana wcześniej operacja zwiększenia zasobu wykonywana jest w jednym prostym kroku na macierzy. Po stronie systemu operacyjnego nie są potrzebne żadne dodatkowe akcje - dba o to sam protokół.

Mimo tylu niewątpliwych zalet NFS nie jest chętnie wykorzystywany w dużych środowiskach np. na potrzeby baz danych. Wynika to z niskiej przepustowości sieci Ethernet, która jest głównym medium dla tego protokołu. Tak było przynajmniej do niedawna. Sieci klasy Data Centre, oparte na technologii 10,40,100 Gb Ethernet są coraz częściej budowane w naszych serwerowniach. Powoduje to, że główny argument na korzyść sieciowego SCSI, tj. szybkość nie jest już aktualny.

W takiej sytuacji NFS staje się coraz bardziej atrakcyjny. Ma on też swoje wady, ale w odróżnieniu od SCSI ciągle się zmienia i dostosowuje. Najnowsza wersja - parallel NFS - rozwiązuje większość problemów, które hamowały jego szerszą ekspansję. Zapowiadane do przyszły rok aktualizacje różnych systemów i macierzy NAS mają na liście zmian wsparcie dla pNFS'a. Może się okazać, że będzie to przełomowy czas dla adaptacji tego protokołu jako głównej metody dostępu do danych.

Implementacja SCSI w protokole sieciowym było najprostszym i najszybszym rozwiązaniem na problemy tamtych czasów. Wydaje się jednak, że ten pomysł nie przetrwa próby czasu. Jest to coraz większe ograniczenie dla rozwoju nowoczesnej infrastruktury IT, a przy okazji dużo kosztuje. Czy to oznacza koniec SAN?