Aplikacje oparte na technologii iSCSI stają się alternatywą dla kosztownych systemów pamięci masowych wykorzystujących połączenia Fibre Channel. Będąc niedrogim sposobem na konsolidowanie pamięci masowych, iSCSI pozwala administratorom korzystać z elastyczności, szybkiego routingu czy skalowalności dobrze im znanych technologii IP i Ethernet.

To sposób niedrogi, ponieważ nie wymaga instalowania dodatkowych urządzeń sieciowych ani modyfikowania warstwy sprzętowej komunikujących się ze sobą stacji (źródłowej i docelowej). Aplikacje iSCSI korzystają z usług standardowych przełączników oraz routerów IP i można je szybko uruchamiać, instalując na stacjach (serwerach i pamięciach masowych wyposażonych w interfejsy Ethernet, co dzisiaj jest standardem) odpowiednie oprogramowanie.

Protokół iSCSI korzysta z usług interfejsu SCSI (Small Computer Systems Interface), który pozwala komputerowi wymieniać dane (operacje I/O) z pamięciami masowymi. Komputery wyposażone w interfejs SCSI komunikują się z takimi pamięciami masowymi, jak macierze dyskowe czy napędy taśmowe. Jednak technologia SCSI ma jedną istotną wadę - połączenie sprzęgające serwer SCSI z pamięcią masową ma ograniczoną długość. Obie strony muszą się znajdować blisko siebie.

Ograniczeń takich nie ma w sieciach opartych na protokole IP. Stąd pomysł połączenia technologii SCSI z protokołem IP. W taki sposób powstała technologia iSCSI (przesyłanie danych SCSI przez sieci IP), która nie narzuca żadnych ograniczeń dotyczących odległości, jaka dzieli stację źródłową (komputer) i stację docelową (pamięć masowa).

Architektura SCSI jest oparta na modelu klient/serwer. Technologia iSCSI nie zmienia tej zasady, z tą tylko różnicą, że dane są przesyłane na dowolną odległość przez sieć IP. W architekturze SCSI klientem jest najczęściej komputer pełniący rolę serwera plików, a serwerem jest pamięć masowa. Klient (serwer plików) wysyła do serwera (pamięć masowa) polecenia zapisywania/odczytywania danych CDB (Command Descriptor Block). Protokół iSCSI kapsułkuje i transferuje je do stacji docelowej (pamięć masowa) przez sieć IP.

W aplikacjach iSCSI mamy klientów (np. serwery plików) i serwery (pamięci masowe). Obie strony są wyposażone w karty sieciowe Ethernet i obsługują protokół iSCSI. Pamięci masowe można wtedy podpinać bezpośrednio do przełączników Ethernet lub routerów IP. Aby klient iSCSI mógł wymieniać dane z pamięcią masową, musi znać jej adres IP lub nazwę. Są to najczęściej nazwy, zamieniane na numery IP przez usługę sieciową podobną do DNS. Usługa nosi nazwę Internet Storage Name Service (iSNS).

Model protokołu iSCSI

Warstwa iSCSI komunikuje się bezpośrednio z protokołem SCSI obsługiwanym przez system operacyjny. Gdy system operacyjny komputera lub aplikacja chce zapisać dane, SCSI generuje polecenia CDB, które są zagnieżdżane przez protokół iSCSI i następnie transportowane przez połączenie IP do pamięci masowej. Protokół iSCSI monitoruje transfer danych i potwierdza, że cała operacja I/O zakończyła się powodzeniem.

Adresowanie i konwencja nazewnictwa

Ponieważ obie strony (klient i serwer) należą do sieci IP, reprezentują obiekty sieciowe (Network Entity), które można identyfikować na podstawie przypisanych im adresów IP. Jak widać na rys. 2, jeden obiekt sieciowy może zawierać jeden lub kilka węzłów iSCSI (iSCSI Node). Węzeł iSCSI to urządzenie SCSI wchodzące w skład obiektu sieciowego, do którego można uzyskać dostęp przez sieć. Kombinacja dwóch parametrów - adres IP przypisany węzłowi iSCSI i numer portu TCP - to Network Portal (portal sieciowy). Każdy węzeł iSCSI można identyfikować za pomocą unikalnej nazwy iSCSI. Maksymalna długość takiej nazwy wynosi 255 bajtów. Używając dwóch parametrów (adres IP i numer portu TCP), można wygenerować unikalny adres sieciowy identyfikujący określone urządzenie iSCSI.

Podczas gdy wartość takiej kombinacji (adres IP i numer portu TCP) może ulec zmianie w momencie przeniesienia urządzenia do innego segmentu sieci, nazwa iSCSI powędruje w nowe miejsce razem z urządzeniem, dzięki czemu będzie je tam można zidentyfikować i odszukać.

Nazwy iSCSI są używane do identyfikowania urządzeń w momencie nawiązywania połączenia między klientem i serwerem, ale nie są wykorzystywane do wyznaczania pakietom marszrut (routing). Powodem jest to, że nazwy mogą być bardzo długie (do 255 bajtów) i obciążałyby sieć niepotrzebnie dodatkowymi pakietami. Dlatego nazwy są używane tylko do ustanawiania połączenia z określonym węzłem iSCSI. Kolejne zadania (transakcje) korzystają już z wartości będącej kombinacją dwóch parametrów: adresu IP i numeru portu TCP.

Standardowa nazwa iSCSI składa się z trzech części. Pierwsza określa typ nazwy. Może to być np. wyrażenie fqn (fully qualified name). Druga część określa firmę/urząd zarządzający serwerem DNS (może to być np. wyrażenie nazwafirmy.com). Trzecia to unikalna nazwa urządzenia (np. macierz.finanse.20). Pełna nazwa urządzenia wygląda wtedy tak: fqn.com.nazwafirmy.macierz.finanse.20.

W sieciach Fibre Channel pamięci masowe są identyfikowane za pomocą 64-bitowych nazw World Wide Name (WWN). Na poziomie sieciowym stosowany jest natomiast 24-bitowy adres Fibre Channel. WWN wspiera też nazewnictwo stosowane w środowiskach iSCSI, stosując format EUI (opracowany przez IEEE). Nazwa urządzenia iSCSI może wtedy wyglądać tak: eui.736A32A325D92356 (eiu plus WWN).

Zarządzanie sesjami iSCSI

Każdą sesję iSCSI musi poprzedzać operacja logowania. Nosi ona nazwę iSCSI Login Phase i jest podobna do operacji Fibre Channel Port Login (PLOGI). Obiekt sieciowy iSCSI może zawierać jeden portal lub kilka portali sieciowych (adres IP i numer portu TCP). Obiekt sieciowy może też zawierać jeden węzeł lub kilka węzłów iSCSI, każdy noszący unikalną nazwę iSCSI. Gdy stacja źródłowa loguje się do stacji docelowej, podaje jej nazwę iSCSI i identyfikator sesji (ISID). Stacja docelowa odpowiada, generując swój unikalny identyfikator sesji (TSID). Mamy wtedy do czynienia z sesją ISID/TSID, która może się składać z wielu połączeń TCP obsługujących komunikację między stacjami.

Po zakończeniu operacji logowania (Login Phase) następuje czas na właściwą transakcję SCSI. Ta operacja nosi nazwę Full Feature Phase.

Zapisywanie/odczytywanie danych

Każda sesja iSCSI składa się z wielu poleceń i odpowiedzi wymienianych między stacją źródłową a docelową. Na rysunku (str. 58) pokazano przykładową operację zapisywania danych. Polecenia oraz dane CDB wymieniane między stacjami mają postać PDU (Protocol Data Unit; jednostka danych protokołu). Kluczową rolę odgrywa tu PDU o nazwie Ready to Transmit (R2T). Jeśli stacja źródłowa nie otrzyma żadnej odpowiedzi od stacji docelowej, może do niej wysłać polecenie SCSI odpowiadające poleceniu Ping stosowanemu w środowisku IP, sprawdzając w ten sposób statut stacji docelowej.

Jeśli stacja docelowa nie odpowiada lub transmitowane przez nią dane zawierają za dużo błędów, stacja źródłowa może przerwać połączenie i otworzyć nową sesję.

Zarządzanie błędami

Standardowe połączenia SCSI są niezawodne i z reguły nie występują w nich błędy. Inaczej ma się sprawa w sieciach IP, przez które protokół iSCSI przesyła informacje i dane SCSI. Tutaj błędy są rzeczywistością, z którą trzeba się w jakiś sposób uporać.

Dlatego w środowisku iSCSI obie strony (klient i serwer) muszą mieć możliwość buforowania poleceń i odpowiedzi do czasu, gdy uzyskają pewność, że operacja zakończyła się powodzeniem. I tak np. w przypadku zapisywania danych klient musi mieć możliwość przechowywania danych w buforze do momentu, gdy serwer wyśle do niego wiadomość R2T. Oznacza ona, że dane zostały zapisane i serwer (pamięć masowa) jest gotowy do przyjęcia kolejnej porcji danych.

System iSCSI zarządzający błędami działa na dwóch poziomach. Na najniższym system musi mieć możliwość wykrywania błędów i odzyskiwania danych SCSI. System realizuje to zadanie, retransmitując zagubione lub uszkodzone PDU. Na wyższym poziomie mamy już do czynienia z protokołem TCP. Należy pamiętać, że każda sesja iSCSI może otwierać wiele połączeń TCP. Każde takie połączenie może generować błędy i system musi dysponować mechanizmami, które mogą zamykać połączenia TCP i następnie je odzyskać (otwierając nowe połączenie).

W środowisku tym może się też zdarzyć i tak, że cała sesja iSCSI musi zostać zamknięta. Ma to miejsce wtedy, gdy wszystkie próby odzyskania danych transmitowanych w ramach sesji nie powiodły się. Protokół iSCSI zamyka wtedy aktualne połączenia TCP, anuluje wszystkie zadania, oczekując na wykonanie oraz wszystkie polecenia SCSI, a następnie inicjuje nową sesję (co oznacza ponowne logowanie do serwera).

Bezpieczeństwo

Ponieważ protokół iSCSI działa w sieciach IP, które z natury nie są bezpieczne, użytkownicy muszą stosować różne mechanizmy ochrony danych. Mechanizmy szyfrowania danych operujące poniżej iSCSI (takie jak IPSec) nie wymagają dodatkowych negocjacji między końcowymi urządzeniami iSCSI. Mechanizmy te są transparentne dla górnych warstw aplikacji iSCSI.

Inaczej ma się sprawa przy wprowadzaniu mechanizmów uwierzytelniania (takich jak Kerberos lub Public/Private Key). Faza Login Phase protokołu iSCSI udostępnia wtedy stacjom pole tekstowe, które służy obu stronom do wynegocjowania rodzaju mechanizmu. Jeśli negocjacja kończy się powodzeniem, wszystkie PDU wymieniane między stacjami są w odpowiedni sposób formatowane, zgodnie z uzgodnionym wcześniej mechanizmem bezpieczeństwa. Serwer iSNS (Internet Storage Name Service) może wtedy też obsługiwać aktywnie taki mechanizm, pełniąc np. rolę repozytorium, w którym są przechowywane klucze publiczne.

Podsumowanie

SCSI musi dysponować połączeniami charakteryzującymi się dużą stabilnością pracy, które gwarantują danym integralność oraz oferują duże przepustowości. Sieci IP nie należą niestety do takiego medium - pakiety są tu nieraz gubione, a przepustowość sieci IP jest często niewystarczająca i na dodatek potrafi się zmieniać w czasie. Dlatego w przypadku aplikacji iSCSI problemy związane z utratą pakietów rozwiązuje protokół TCP, a większe przepustowości można uzyskać stosując zaawansowane technologie sieciowe. Dużą rolę odgrywają wewnętrzne mechanizmy iSCSI, które monitorują połączenia TCP i potrafią retransmitować jednostki PDU.

Warto, aby aplikacje iSCSI obsługiwały stacje dysponujące adapterami sieciowymi z technologią TOE (motor TCP/IP off-load). Procesory zainstalowane w takich stacjach nie zajmują się wtedy obsługą protokołu TCP/IP i lepiej sobie radzą z właściwymi aplikacjami. Wdrożenia oparte na technologii iSCSI pracują też dużo wydajniej w środowiskach LAN z połączeniami Ethernet 1 Gb/s.