iSCSI w systemach Windows, cz. II

Autor: Grzegorz Tworek

Opublikowano: 23 sierpnia 2007

Zawartość strony

	Bezpieczeństwo iSCSI
	iSNS
	Konfiguracja inicjatora
	Start systemu z dysków iSCSI
	Cele iSCSI
	Klastry
	Zrób to sam
	Podsumowanie
	Przeczytaj pozostałe części tego artykułu

Bezpieczeństwo iSCSI

Choć iSCSI realizowane na dedykowanym łączu światłowodowym można uznać za stosunkowo bezpieczne (a na pewno niewiele słabiej chronione niż tradycyjne SCSI) to już w przypadku użycia zwykłego Ethernetu – bezpieczeństwo połączenia staje się dość istotne. Aspekty, które należy rozważyć to nieuprawniony dostęp do urządzenia oraz podsłuchanie transmisji. Jest to o tyle istotne, że przejęcie dostępu do iSCSI porównać można do kradzieży całego dysku z serwera. Fizyczna ochrona dysku często bywa znacznie łatwiejsza niż skuteczne zabronienie nieuprawnionym użytkownikom dostępu przez sieć TCP/IP. Jest to jeden z powodów, dla których warto rozważyć stworzenie dedykowanej sieci wyłącznie na potrzeby iSCSI.

W przypadku iSCSI, nieuprawniony dostęp ogranicza się poprzez zastosowanie haseł. Standard iSCSI używa protokołu CHAP (RFC 1994), który może być uznany za stosunkowo bezpieczny, jednak jak każdy tego rodzaju protokół uwierzytelniania poddaje się pewnym atakom wykraczającym poza zakres niniejszego artykułu. Należy jednak pamiętać, że iSCSI używa haseł tylko wtedy, kiedy administrator włączy opcję uwierzytelniania. Domyślnie, target iSCSI wpuści każdego, kto o to poprosi. Uwierzytelnianie hasłem może być dwukierunkowe, czyli zarówno inicjator musi się przedstawić w sposób akceptowalny dla celu jak i cel potwierdzić systemowi, że naprawdę jest tym, o kogo chodzi. Nietrudno wyobrazić sobie sytuację, w której system korzysta z danych umieszczonych na kilku dyskach pod różnymi adresami IP i podmienienie któregoś z urządzeń przez atakującego wykonywane jest w celu osiągnięcia konkretnych korzyści.

Specyfikacja iSCSI wymaga, żeby minimalna długość hasła wynosiła 12 znaków. Wiele urządzeń próbuje nie dopuścić do zastosowania krótszego hasła, jednak nie jest to niemożliwe. Windows, podłączając się do takiego urządzenia poprosi o hasło, jednak zwróci uwagę, że hasło jest zbyt krótkie. W tym momencie starsze wersje systemu Windows 2003 zapisywały w dzienniku zdarzeń niesławny event 35 z iScsiPrt. Wpis ten informował administratora, że hasło CHAP jest niezgodne ze specyfikacją i zawierał owo hasło w jawnej formie.

Rys. 1. Event 35 z iScsiPrt.

Drugim ograniczeniem, które można nałożyć na urządzenia iSCSI jest zezwolenie na połączenia wyłącznie z inicjatorów o danej nazwie. W praktyce jednak należy uznać, że jest to metoda utrzymania porządku a nie ochrona informacji. Każdy inicjator ma taką nazwę jak zechce i wyłączenie oryginalnego inicjatora, przejęcie jego nazwy i podłączenie się do urządzenia iSCSI nie jest szczególnie skomplikowanym atakiem.

Aby nie komplikować protokołu iSCSI przyjęto, że komunikacja nie jest w żaden sposób szyfrowana.

Rys. 2. Komunikacja nie szyfrowana.

Oznacza to, że transmisja informacji może być bardzo łatwo podsłuchana. Nie jest to stan, który w poważnych środowiskach daje się zaakceptować. Aby zabezpieczyć iSCSI przed podsłuchaniem należy użyć protokołu IPSec. Jest to proste podejście, w którym od protokołu iSCSI wymaga się sprawnego dostępu do urządzeń a zabezpieczenia pozostawia się tym, którzy naprawdę dobrze się na nich znają. Transmisja zabezpieczona IPSec uznawana jest za dobrze chronioną i doskonale się sprawdza również w warunkach iSCSI. Warto przypomnieć, że dla różnych rodzajów ruchu IP można stworzyć różne reguły IPSec, więc niema przeciwwskazań do stworzenia dedykowanej reguły dla portu 3260 tylko na jeden adres IP. Reguła taka nie będzie kolidować z innymi stosowanymi w sieci zabezpieczeniami.

Ciekawą możliwością zabezpieczenia tak dostępu jak i poufności transmisji jest zastosowanie mechanizmów BitLocker. W przypadku nieuprawnionego podłączenia, bez użycia klucza dostęp do danych nie będzie możliwy. Jeżeli podłączy się uprawniony komputer – podsłuch danych nic nie da, ponieważ przesyłane one będą wyłącznie w zaszyfrowanej formie. Rozwiązanie takie, choć skuteczne, to jednak wykorzystuje zabezpieczenia nie wynikające z samego iSCSI.

Należy pamiętać, że iSCSI nie jest rozwiązaniem magicznym. Działa tak jak działają inne urządzenia sieciowe, ma jakiś adres IP, jakieś porty, realizuje usługi. Dlatego nie należy wierzyć, że to po prostu działa i lepiej nie dotykać. Tak jak każdy inny element systemu – iSCSI wymaga zaplanowania, analizy, skutecznego zabezpieczenia i stałej kontroli. Pozostawienie wartości domyślnych tylko dlatego, że „działa, więc lepiej nie dotykać” nie jest najlepszym pomysłem i zazwyczaj świadczy o braku wiedzy administratora.

 Do początku strony

iSNS

Aby uwolnić administratora od konieczności wpisywania ręcznie adresów IP dla każdego podłączanego urządzenia powstał iSNS Server (Internet Storage Name Service, RFC 4171). Rolę tego serwera porównać można najprościej do DNS. Po co pamiętać numery IP skoro wystarczą nazwy? Poza tym w przypadku jakiejś zmiany nie trzeba przekonfigurować wszystkich urządzeń. Jeżeli nazwa jest cały czas ta sama – adres IP znajdzie się sam.

W przypadku iSNS sytuacja wygląda podobnie. Jeden serwer w sieci odpowiada za to, żeby dostarczać każdemu chętnemu stale aktualną informację o tym, jakie urządzenia iSCSI są osiągalne i jak się z nimi porozumieć. Jak każda tego rodzaju usługa, logicznie składa się z trzech elementów: serwera, klientów i bazy danych.

W przypadku implementacji na systemach Windows, serwer iSNS jest serwisem systemowym działającym na Windows 2000 SP4 lub nowszym.

Zgodnie z RFC, usługi iSNS i sam protokół (nazywany ISNSP) nie zawiera żadnych mechanizmów uwierzytelniających. Z tego powodu powinien być używany w odseparowanych segmentach sieci lub zabezpieczany przy pomocy IPSec. Skutki ataku na iSNS porównać można do skutków ataku na DNS. Ich efekt obejmuje pełne spektrum od unieruchomienia serwerów aż po kradzież lub nieuprawnioną modyfikację danych. Samo zarządzanie iSNS, w systemach Microsoft wymaga praw administratora i odbywać się może przez GUI dostępne z panelu sterowania, przez narzędzia commandline oraz przez WMI.

Instalując iSNS Server, administrator może zobaczyć pytanie czy skonfigurować odpowiednią opcję DHCP. Jeżeli serwer Microsoft DHCP jest dostępny a użytkownik ma odpowiednie prawa (DHCP Server Administrator) to program instalacyjny ustawi opcję tak, aby każdy host pobierający adres razem z adresem otrzymywał informację o lokalizacji serwera iSNS. Użycie powiadamiania przez DHCP o lokalizacji serwera w oczywisty sposób usprawnia wdrożenie i ogranicza ryzyko popełnienia błędu. W chwili obecnej iSNS zapisywany jest w opcji numer 43 w ramach opcji dowolnie zarządzanych przez producentów (vendor-specific). Wprawdzie trwają prace nad ustaleniem opcji iSNS, jako standardu uznanego przez IANA. Microsoft deklaruje użycie ogólnoświatowego standardu jak tylko on powstanie.

W czasie instalacji iSNS Server warto wiedzieć o fakcie, że wszystkie działania programu instalacyjnego zapisywane są w pliku %windir%\isnsins.log. Plik ten może służyć pomocą jeżeli coś pójdzie inaczej niż administrator oczekiwał.

Podczas działania iSNS przyjmuje informacje o „znających” go węzłach iSCSI i zapisuje je w swojej bazie danych. Węzeł może korzystać z tej bazy, aby dowiadywać się o innych węzłach. Większość implementacji inicjatora i duża część celów współpracuje z iSNS i może wspierać się posiadanymi przez ten serwer informacjami. Sposób rejestrowania węzła iSCSI w serwerze iSNS zależy od typu urządzenia, a dla przypadku związanego z systemami Microsoft, zostanie omówiony w dalszej części artykułu.

Aby ułatwić zarządzanie, węzły mogą być grupowane w domeny (DD – discovery domains), które z kolei można łączyć w grupy domen (DDS – discovery domain sets).

Istnienie domen ma na celu odseparowanie informacji na temat różnych urządzeń. Przykładowo, mając jeden serwer iSNS można w nim przechowywać dane o dyskach iSCSI księgowości oraz o dyskach działu kadr. Aby użytkownikom z księgowości nie wyświetlać informacji o cudzych urządzeniach, najlepiej stworzyć dla nich grupę, w której znajdą się tylko te urządzenia, z którymi mają do czynienia. Ograniczy to znacząco ilość problemów z administracją. Oczywiście, jeżeli użytkownik sam wstuka nazwę celu iSCSI nie z jego grupy – połączenie zostanie nawiązane. W chwili instalacji serwera iSNS istnieje domyślna domena, do której trafiają wszystkie zarejestrowane węzły. Dzięki temu bez żadnej dodatkowej konfiguracji serwer obsługuje scenariusz „każdy widzi każdego”. Jeżeli w danym środowisku jest to niewskazane – warto zmodyfikować strukturę DD i w efekcie ograniczyć zakresy widoczności węzłów. Warto wiedzieć, że domena domyślna (default domain) jest swojego rodzaju domeną wirtualną. Jeżeli jakikolwiek węzeł zostanie dodany do innej domeny – znika z domeny domyślnej. W chwili, kiedy nie ma ustalonej przynależności – pojawia się w niej. Jeżeli zostanie ręcznie usunięte z domeny domyślnej – nie pojawi się na żadnej liście urządzeń.

Grupy domen służą do zarządzania domenami. Każda domena należy początkowo do domyślnej grupy i podobnie jak węzły wirtualnie pojawia się w niej i znika w zależności czy należy do innych grup. Grupy mogą być włączane lub wyłączane w zależności od tego, czy iSNS Server powinien udostępniać informacje na temat należących do nich węzłów czy nie. Wyłączona grupa nie publikuje informacji o żadnym węźle należącym do zawartych w niej domen. Nowo utworzona grupa domen zawsze domyślnie jest wyłączona i administrator powinien samodzielnie ją włączyć.

Podsumowując działanie domen warto wprost zaznaczyć, że inicjator jest w stanie wykryć cel tylko, jeżeli należą do tej samej domeny, a domena ta należy do grupy, która jest włączona.

Dzięki istnieniu domen i grup możliwe jest zorganizowanie urządzeń iSCSI w jakąś sensowną strukturę. Ponieważ w wielu środowiskach ilość węzłów iSCSI może sięgać wielu tysięcy, bez takiej możliwości zarządzanie nimi mogłoby być stosunkowo trudne.

Jak wspomniano powyżej, zarządzanie serwerem iSNS dostępne jest na trzy sposoby: dla twardych administratorów, dla prawdziwych administratorów oraz dla miękkich administratorów. Twardzi administratorzy nie czytają takich artykułów, więc opis zarządzania iSNS Server przy pomocy WMI zostanie pominięty. Prawdziwi administratorzy mają do dyspozycji narzędzie isnscli.exe. Obsługuje ono następujące operacje:

• LN – ListNodes. Zwraca informacje o wszystkich zarejestrowanych węzłach (inicjatorze lub celu) iSCSI.
• LND – ListNodeDetails. Zwraca szczegółowe informacje o wskazanym węźle.
• LA – ListAllNodeWithDetails. Połączeniefunkcjonalności LN i LND. Zwraca szczegółowe informacje o każdym zarejestrowanym węźle.
• LDD – ListDiscoveryDomains. Wyświetla listę domen.
• LDDNM – ListDiscoveryDomainNodeMembers. Wyświetla serwery zarejestrowane we wskazanej domenie.
• LADD – ListAllDiscoveryDomainsWithNodeMembers. Połączenie funkcjonalności LDD i LDDNM. Wyświetla wszystkie domeny i należące do nich węzły.
• CreateDD – CreateDiscoveryDomain. Tworzy domenę o podanej nazwie.
• DeleteDD – DeleteDiscoveryDomain. Usuwa domenę o podanym identyfikatorze.
• AddNodeToDD – AddNodeToDiscoveryDomain. Dodaje węzeł do wskazanej domeny.
• RemoveNodeFromDD – RemoveNodeFromDiscoveryDomain. Usuwa wskazany węzeł domeny.
• LDDS – ListDiscoveryDomainSets. Wyświetla grupy domen.
• LDDSM – ListDiscoveryDomainSetMembers. Wyświetla domeny należące do danej grupy
• LADDS – ListAllDiscoveryDomainsSetsWithMembers.Połączenie LDDS i LDDSM. Wyświetla listę grup oraz listę domen należących do każdej grupy.
• CreateDDS – CreateDiscoveryDomainSet. Tworzy grupę domen o podanej nazwie.
• DeleteDDS – DeleteDiscoveryDomainSet. Usuwa grupę o podanym identyfikatorze.
• AddDDToDDS – AddDiscoveryDomainToDiscoveryDomainSet. Dodaję domenę do grupy.
• RemoveDDFromDDS – RemoveDiscoveryDomainFromDiscoveryDomainSet. Usuwa domenę z grupy.
• EnableDDS – EnableDiscoveryDomainSet. Włącza grupę.
• DisableDDS – DisableDiscoveryDomainSet. Wyłącza grupę.

Dla miękkich administratorów dostępne jest GUI. Zarządzanie iSNS przez GUI włącza się w panelu sterowania. Polega ono na klikaniu myszką w przyciski, więc nie warto poświęcać mu zbyt wiele uwagi.

Rozważając bezpieczeństwo iSNS, warto skupić się na dwóch aspektach: wiarygodność i niezawodność. W przypadku wiarygodności stwierdzić należy, że iSNS nie ma żadnej. Nasłuchuje informacji od urządzeń iSCSI i publikuje ją. Jeżeli ktoś zechce poinformować serwer iSNS o milionie nowych urządzeń – w bazie pojawi się milion urządzeń. Nie istnieje żadna metoda weryfikacji i aby zagwarantować względne bezpieczeństwo, zaleca się użycie IPSec do ochrony komunikacji pomiędzy iSNS a iSCSI.

W przypadku analizowania niezawodności iSNS należy zwrócić uwagę, że serwer taki łatwo może stać się punktem, którego awaria sparaliżuje działanie całej sieci. Ponieważ nie istnieje żadna metoda replikowania informacji pomiędzy kilkoma serwerami iSNS, wskazane jest zapewnienie niezawodności poprzez instalację na klastrze. iSNS Server jest świadomy istnienia klastrów, wykrywa je w czasie instalacji i instaluje się w sposób gwarantujący przenoszenie z węzła na węzeł w przypadku awarii. Choć dla ograniczenia klastrowanych zasobów typu dysk można wskazać dysk quorum jako lokalizację bazy iSNS, to jednak jest to rzadko spotykane, ponieważ w środowiskach iSCSI problem braku współdzielonych zasobów nie istnieje. Baza danych przechowywana jest w katalogu \MSiSNS dysku klastra i nie koliduje w żaden sposób z quorum. Warto wiedzieć, że przenosząc samodzielny serwer iSNS na klaster można skopiować istniejącą już bazę danych. W tym celu należy zatrzymać działający serwis iSNS, przełączyć zasób klastra w tryb offline a następnie przenieść pliki MSISNS*.DAT z katalogu %homedrive%\Documents and Settings\LocalService starego serwera do katalogu \MSiSNS. Analogiczna procedura może być również zastosowana przy przenoszeniu bazy z jednego serwera standalone na drugi oraz przy przenoszeniu z klastra na klaster.

W czasie instalacji warto zwrócić uwagę, czy iSNS dodał się do listy dozwolonej komunikacji w systemowym firewallu. Bez tego, serwer może mieć poważne problemy z funkcjonowaniem. Najlepiej, żeby firewall wpuszczał cały ruch związany z serwisem isnssrv.exe, jednak można samodzielnie zezwolić na ruch 3205/TCP oraz 3205/UDP.

 Do początku strony

Konfiguracja inicjatora

Można wyróżnić trzy podejścia do tematu inicjatora iSCSI.

• iSCSI współdzielące interfejs sieciowy. Rozwiązanie takie można zastosować na każdym komputerze wyposażonym w kartę sieciową, ale ma ono wszystkie uroki rozwiązań najprostszych i najtańszych. Jest zawodne, niewydajne i niebezpieczne. Można za to przećwiczyć je w domowych warunkach w ciągu kilkunastu minut.
• iSCSI mające własny interfejs i własną sieć Ethernet do dyspozycji. Stosunkowo niedrogie, ponieważ nie wymaga specjalizowanego sprzętu. Nadal obsługiwane przez programowy inicjator iSCSI ale znacznie bezpieczniejsze niż rozwiązanie współdzielące sieć.
• Specjalna dedykowana, zazwyczaj światłowodowa karta sieciowa wyposażona w BIOS iSCSI. Tradycyjnie nazywana kartą HBA (Host Bus Adapter). Sama obsługuje cały protokół iSCSI i przedstawia systemowi podłączone przez nią urządzenia. Rozwiązanie to jest stosowane w poważnych systemach. Z jednej strony niewiele się różni od rozwiązań zbudowanych w oparciu o Ethernet a z drugiej, funkcjonuje w tak innych realiach, że w niniejszym artykule opisane zostanie jedynie hasłowo.

Dla potrzeb artykułu warto skupić się na podejściu najprostszym. Inicjatorem iSCSI jest inicjator programowy, czyli specjalny serwis systemowy uruchomiony w systemie operacyjnym. Windows Vista oraz Windows 2008 wyposażone są w inicjator iSCSI i jedyne, co trzeba zrobić to wskazać, że chce się go używać. W przypadku Windows XP oraz Windows 2003, należy pobrać inicjator iSCSI ze stron Microsoft i zainstalować go. Niezależnie od tego skąd wziął się na komputerze programowy inicjator –jego konfiguracja wygląda tak samo. Jak zwykle do dyspozycji są trzy metody. WMI, command line oraz GUI. Ponieważ GUI jest dość złożone, zostanie tu skrótowo omówione na przykładzie Windows Vista.

Zarządzanie iSCSI uruchamia się w panelu sterowania, przez ikonkę o wiele mówiącej nazwie „iSCSI Initiator”. Jest ona skrótem do %systemroot%\system32\iscsicpl.exe. Oczywiście uruchomienie konfiguracji iSCSI wyświetla zapytanie od UAC i wymaga praw administratora. Pierwsze włączenie apletu powoduje wyświetlenie okna dialogowego z pytaniem, czy serwis iSCSI ma być uruchamiany automatycznie. Kolejne pytanie dotyczy zezwolenia iSCSI na komunikację przez systemowy firewall. W praktyce, jedyną słuszną odpowiedzią na oba pytania jest „Yes”.

Efekty odpowiedzi obejrzeć można uruchamiając na koncie administratora polecenia:

sc.exe query MSiSCSI

oraz

netsh advfirewall firewall show rule name=all |findstr /i iscsi

Pierwszy ekran konfiguracji iSCSI (zakładka „General”) wyświetla opcje ogólne inicjatora. Pozwalają one na:

• Zmianę nazwy iQN. (jak wspomniano wcześniej, domyślnie jest to iqn.1991-05.com.microsoft:computername). Nazwę można zmienić dowolnie pod warunkiem, że będzie ona zgodna ze standardami iQN.
• Ustawienia hasła, którym cel uwierzytelni się w inicjatorze. Jest to opcjonalne i w pewnych sytuacjach może zapewnić dodatkowe zabezpieczenie w stosunku do standardowego uwierzytelniania inicjatora w celu. Według RFC, minimalna długość hasła to 12 znaków.
• Ustawienia parametrów IPSec. Parametry te są dostępne również w standardowym interfejsie IPSec i świadomy użytkownik raczej tam powinien je modyfikować, samodzielnie decydując, jaki jest zakres obowiązywania IPSec, jakie algorytmy, skąd pochodzą klucze itp.

Kolejny ekran (zakładka „Discovery”) pozwala na odnalezienie celów. Metody są dwie:

• Przez podanie adresów IP urządzeń iSCSI. W sekcji „Target portals”, należy samodzielnie dodać każde urządzenie, z którego podłączane będą cele.
• Przez podanie adresu IP serwera iSNS. Serwer ten opublikuje inicjatorowi informacje na temat celów z tej samej domeny. Czym są domeny i kiedy informacja o nich jest publikowana dokładniej napisano w poprzednim rozdziale.

Jeżeli inicjator wie już z kim może nawiązać komunikację (przez adresy IP albo dzięki serwerowi iSNS) – wyświetla listę celów w zakładce „Targets”. Wraz z nazwami celów wyświetlane są ich statusy, z których wspomnieć należy o „inactive” oznaczającym, że cel istnieje i czeka na połączenia oraz „connected”, który pojawia się przy podłączonym już urządzeniu.

Aby podłączyć urządzenie, na zakładce tej, wybrać należy właściwy cel i kliknąć „Log On...”

Rys. 3. Właściwości inicjatora.

Po pojawieniu się okna logowania należy:

Sprawdzić czy połączenie następuje z właściwym celem i ewentualnie zaznaczyć opcję automatycznego połączenia urządzenia przy każdym restarcie. Opcja Multipath (opisana wcześniej w rozdziale „Jak działa iSCSI”) nie powinna być zaznaczana dopóki środowisko faktycznie nie wspiera MPIO.

Rys. 4. Wskazany cel logowania.

Przycisk „Advanced...” pozwala na konfigurację dodatkowych opcji, w tym:

• Lokalnego interfejsu sieciowego, który wykorzystywany jest do nawiązania połączenia iSCSI
• Adresu IP, z którego nawiązywane jest połączenie. Może to być istotne zwłaszcza, jeżeli na urządzeniu docelowym skonfigurowano filtry lub reguły IPSec na konkretne adresy IP.
• Portalu, czyli adresu IP urządzenia, które odpowiada za udostępnianie wybranego celu iSCSI.
• Włączenie sum kontrolnych dla danych oraz dla nagłówków iSCSI. Pozwala to na lepszą niezawodność kosztem wydajności.
• Logowanie do celu iSCSI (CHAP logon information). Praktycznie najważniejsza opcja. Dzięki niej można podać nazwę użytkownika (domyślnie jest to nazwa inicjatora) oraz hasło wymagane przez cel iSCSI.
• Dodatkowe logowanie celu w inicjatorze. Opisane powyżej i ustawiane również na zakładce „General”
• Użycie serwera RADIUS do autentykacji

Rys. 5. Konfiguracja dodatkowych opcji.

Zauważyć można pewne niedociągnięcia interfejsu, ponieważ opcje związane z RADIUS są dostępne (ma to sens) jednak po zaznaczeniu i odznaczeniu CHAP – są one wyłączane.

Aby podać dane uwierzytelniające dla celów wymagających tego, należy w ekranie „Advanced Settings” zaznaczyć „CHAP logon information” i wypełnić pola „user name” oraz „Target secret”.

Zakładka IPSec służy do szczegółowego ustawiania parametrów zabezpieczenia transmisji.

Po podłączeniu, dla urządzeń o statusie „Connected” zobaczyć można szczegółowe informacje. Są one dostępne po wybraniu przycisku „Details”. Poza danymi czysto informacyjnymi, cenną opcją jest przycisk „Log off...”, pozwalający na odłączenie urządzenia. Należy pamiętać, że odłączenie to jest dość brutalne i nieoczekiwane dla systemu operacyjnego. Porównać je można do odpięcia dysku twardego w czasie pracy komputera. Jeżeli system nie zapisał danych – zostaną one utracone. Aby odłączyć się od urządzenia należy otworzyć okno detali, zaznaczyć identyfikator inicjatora i kliknąć „Log off...”

Rys. 6. Właściwości celu.

Mimo tradycyjnych trzech kropek na przycisku, po jego naciśnięciu nie jest wyświetlane żadne dodatkowe okno dialogowe, nie ma żadnego potwierdzenia a urządzenie odłączane jest natychmiast.

Zalogowanie się (podłączenie) do urządzenia iSCSI sprawia, że pojawia się ono w managerze urządzeń. Jeżeli urządzeniem jest dysk – należy założyć na nim partycje i sformatować go. Trzeba się mocno postarać, żeby zorientować się, że urządzenie takie nie jest podłączone lokalnie. Ciekawostką jest, że system Windows również nie do końca wie, z jakim dyskiem ma do czynienia, ponieważ proponuje użycie nowego dysku jako urządzenia ReadyBoost. Zazwyczaj nie spełnia ono wymagań wydajnościowych, ale sam fakt składania takiej propozycji świadczy o naprawdę skutecznym ukryciu prawdziwego charakteru napędu.

Pozostałe opcje zarządzania programowym inicjatorem iSCSI pozwalają na ustawienie urządzeń, które muszą być podłączone przed startem systemu. Ustawienie takie ma sens, ponieważ na urządzeniach tych mogą być przechowywane istotne dane, które muszą być dostępne nim uruchomione zostaną inne usługi. Przykładem takiej sytuacji jest serwer SQL, który nim zacznie się uruchamiać musi mieć dostęp do dysków na których przechowuje pliki baz danych.

Drugim często używanym narzędziem pozwalającym na zarządzanie programowym inicjatorem iSCSI jest iscsicli.exe. Narzędzie to wbudowane zostało w system i obsługuje się je w sposób podobny do netsh. Można pracować w trybie interaktywnym, wpisując najpierw iscsicli.exe a później na przykład ListiSNSServers lub wpisując od razu iscsicli.exe ListiSNSServers. Narzędzie iscsicli powinno być uruchamiane z podwyższonymi uprawnieniami. Uruchomienie go z command line bez podniesionych uprawnień spowoduje, że pojawi się zapytanie od UAC, po czym wyświetli się nowe okno, które zniknie natychmiast po wyświetleniu komunikatu.

 Do początku strony

Start systemu z dysków iSCSI

Rozważania na temat iSCSI uzupełnić należy paroma słowami na temat startu systemu z dysku iSCSI.

W wielu środowiskach rozwiązanie takie jest potrzebne, przez co zostało ono dość dokładnie obmyślane i opisane w RFC4173. Start systemu z iSCSI jest oczywiście możliwy, ale jak łatwo się domyślić – inicjatorem nie może być w tej sytuacji serwis systemowy MSiSCSI. Metod startu systemu z dysków iSCSI jest kilka: użycie karty HBA, użycie specjalnego BIOSu karty Ethernet oraz użycie programu ładowanego przez PXE karty Ethernet.

Start systemu z karty HBA nie jest niczym ani trudnym ani rzadko spotykanym. Karty takie mają własny BIOS i przy jego pomocy podłączają wskazane cele i uruchamiają z nich system. Pierwsze skonfigurowanie takiego serwera bywa czasem wyzwaniem gdyż opcje są nieoczywiste, jednak należy uznać, że nie jest to przypadek szczególnie interesujący. Karty HBA realizują łączność iSCSI tak prosto, że niniejszy artykuł niemal całkowicie je pomija. Poza prostotą charakteryzują się one niemałą ceną, co również powoduje, że w domowych i laboratoryjnych warunkach są dość rzadko spotykane.

Od strony celu iSCSI sytuacja w żaden sposób nie jest wyjątkowa. Cel ma za zadanie udostępnić dysk, o który poprosi go inicjator. Czy na dysku tym znajduje się system operacyjny czy bazy SQL – nie sprawia celowi różnicy. Każdy cel iSCSI oznaczony logiem „Designed for Windows” będzie się nadawał do startu systemu.

Po stronie inicjatora, Microsoft zaleca zaimplementowanie BIOSu który będzie świadomy iSCSI oraz będzie implementował iBFT (iSCSI Boot Firmware Table). Dużo ciekawych rzeczy w zakresie startu z iSCSI obiecywane było w Windows 2008, ale wydaje się, że należy poczekać na wersję finalną nim zacznie się je chwalić. Należy jednak mieć świadomość, że rozwiązania takie wymagają kart Ethernet świadomych iSCSI. Bez tego, zwykła karta z PXE niewiele będzie mogła zdziałać

W przypadku kart Ethernet sytuacja wygląda najtrudniej, ale i najciekawiej. Karty takie mają własny BIOS, ale nie służy on do podłączania dysków. Mogą za to pobrać mini system operacyjny, uruchomić go i z jego pomocą podłączyć dyski iSCSI, z których następnie zostanie załadowany pełny system. Nietrywialną kwestią takim przypadku jest również sama instalacja systemu. Programowi instalacyjnemu nie ma jak wskazać dysku iSCSI i trzeba sobie radzić innymi sposobami.

Wśród komercyjnych rozwiązań zapewniających start przez PXE oraz iSCSI, wymienić należy produkty firmy emBoot, które cały proces bardzo upraszczają. Dostępne są wersje trial i można je w razie potrzeby użyć do testów. Aby użyć takiego rozwiązania należy skonfigurować stację zarządzającą a następnie zainstalować Windows2003 na dyskach lokalnych. Po instalacji dyski te kopiowane są na dyski iSCSI i późniejsze starty systemu odbywają się już przez iSCSI. Uruchamiany jest program ładujący z PXE, ze stacji zarządzającej pobierany jest kod zawierający obsługę TCP/IP, UNDI (Universal Network Driver Interface), iSCSI oraz iBF. Dzięki programowi ładującemu nawiązywane jest połączenie z iSCSI i system ładuje się dalej w sposób normalny.

 Do początku strony

Cele iSCSI

Znalezienie inicjatora iSCSI jest znacznie prostsze niż znalezienie celu. Artykuł ten nie dotyczy poważnych rozwiązań SAN ani kart HBA i można je tu pominąć. W domowych albo laboratoryjnych warunkach sensowne wydaje się zastosowanie programowego celu zamiast rozwiązań sprzętowych. W zasadzie, poszukiwania takiego oprogramowania powinny pójść w dwóch kierunkach:

• Windows Storage Server 2003 R2. Rozwiązanie zbudowane przez Microsoft, ale nie sprzedawane w postaci samodzielnego pakietu oprogramowania. Jedyną drogą zaopatrzenia się w Storage Server jest zakup sprzętu, na którym serwer taki pracuje jako OEM. W czasie pisania niniejszego artykułu serwery takie oferowane były przez kilkudziesięciu producentów, w tym tak znanych jak DELL, HP, IBM czy Fujitsu Siemens
• Oprogramowanie target iSCSI firm trzecich. Godny polecenia wydaje się StarWind, który zainstalować można nawet na Windows XP i zapewnia całą funkcjonalność potrzebną w niewielkich rozwiązaniach. Dostępna jest wersja trzydziestodniowa, która wystarcza zazwyczaj do eksperymentów. Ciekawą funkcjonalnością StarWind jest wirtualizacja, która pozwala udostępnić nie tylko cały dysk, ale i emulować taki dysk poprzez plik, którego rozmiar jest dynamicznie zwiększany w miarę potrzeb. Oczywiście możliwe jest udostępnienie przez iSCSI dowolnego istniejącego urządzenia SCSI.

 Do początku strony

Klastry

Jak powszechnie wiadomo, klastry Microsoft Cluster Services (MSCS) działają dobrze wtedy, kiedy dysponują współdzielonym dyskiem SCSI. Naturalne w tej sytuacji jest pytanie czy iSCSI nadaje się do takich zastosowań. Odpowiedź brzmi: TAK! Można skonfigurować cel iSCSI (dysk) deklarując, że ma on służyć do współdzielenia.

Dysk taki podłączany jest we wszystkich węzłach klastra i spełnia wszystkie wymagania MSCS. Sprawdza się jako quorum, można na nim zainstalować MS SQL, Exchange itp. Sposób postępowania w niczym nie różni się od procedur istniejących dla urządzeń SCSI podłączanych bezpośrednio.

Użycie dysków iSCSI wydaje się jedyną możliwością zbadania MSCS w domowych warunkach. Dwuwęzłowy klaster całkiem sprawnie działa na trzech wirtualnych maszynach, z których jedna pełni rolę Active Directory oraz celu iSCSI a dwie są węzłami.

 Do początku strony

Zrób to sam

Chcąc samodzielnie pobawić się iSCSI należy:

• Uruchomić serwer iSNS, ale można się bez niego obejść.
• Uruchomić target iSCSI. Dowolny, zgodny z RFC. Może to być macierz SAN, może być Windows Storage Server 2003 R2 a może być StarWind na wirtualnej maszynie z WindowsXP. Wszystko zależy od faktycznych potrzeb.
• Jeżeli serwer iSNS istnieje, skonfigurować cel iSCSI tak, żeby się rejestrował w bazie iSNS
• Udostępnić przez iSCSI wybrane urządzenia
• W Windows Vista uruchomić iSCSI Initiator i wskazać gdzie jest cel. Można to zrobić przez podanie adresu serwera iSNS lub przez wpisanie adresu IP celu iSCSI.
• Podłączyć udostępnione urządzenia
• Zainicjować urządzenia. Sformatować dyski, zainstalować sterowniki do napędu taśm itp.

Gotowe! Można cieszyć się funkcjonalnością iSCSI i urządzenia jednego komputera oglądać w drugim. Kolejne kroki powinny, stosownie do zainteresowań, objąć:

• Skonfigurowanie jedno i dwukierunkowe uwierzytelniania przez CHAP. Należy pamiętać, że hasła krótsze niż 12 znaków nie będą działać poprawnie.
• Zarządzanie i eksperymenty z domenami iSNS.
• Zabezpieczenie transmisji iSCSI oraz iSNS przez IPSec.
• Uruchomienie klastra MSCS.

 Do początku strony

Podsumowanie

iSCSI nie jest ani nowym wynalazkiem ani pomysłem firmy Microsoft. Sprawia jednak, że życie administratora systemów Windows staje się łatwiejsze. Dzięki iSCSI można mądrzej zarządzać posiadanym sprzętem i przestrzenią dyskową, ponieważ takie zasoby mogą być wykorzystywane nie tylko przez bezpośrednio podłączone komputery, ale praktycznie przez każdego, z kim można nawiązać wydajną łączność TCP/IP. iSCSI jest rozwiązaniem stosowanym w największych środowiskach i przy największych możliwych wymaganiach dotyczących bezpieczeństwa i niezawodności. Istnieje bezpośredni związek pomiędzy stabilnością rozwiązania a ponoszonymi nakładami. . Fakt, że iSCSI daje się zbadać na istniejącym już sprzęcie sprawia, że warto się technologią zainteresować i dokładnie ją poznać. Środowisko produkcyjne, w którym ma zostać wykorzystane iSCSI wymaga przeglądu obecnej architektury, a następnie dobrego zaplanowania poziomu wdrożenia nowej technologii składowania danych w życie oraz określenia budżetu potrzebnego na realizację projektu. W zamian za krótki poświęcony czas na udoskonalenie obecnego środowiska IT, otrzymuje się wiele lat niezakłóconej pracy.

 Do początku strony

Przeczytaj pozostałe części tego artykułu

• iSCSI w systemach Windows, cz. I

---

Grzegorz Tworek (Konsultant ISCG, MVP) Inżynier systemowy, komputerowiec w drugim pokoleniu. Od wielu lat aktywnie promuje idee związane z bezpieczeństwem informatyki, zwłaszcza w powiązaniu z systemami Microsoft. Autor artykułów i książek na temat security, prelegent na rozmaitych konferencjach. Aktywnie uczestniczy w działaniach SEClub. Równie duży zapał do tworzenia jak i do psucia systemów sprawia, że w projektach najchętniej uczestniczy jako audytor. W lipcu 2007 został nagrodzony tytułem Most Valuable Professional w kategorii Enterprise Security. Prowadzi polski blog TechNet.

Do początku strony

---