Microsoft iscsi Software Target

Transkrypt

1 Microsoft iscsi Software Target Autor: Grzegorz Tworek Niniejszy artykuł jest uzupełnieniem treści opublikowanego w sierpniu 2007 roku artykułu "iscsi w systemach Windows". Artykuł tamten przybliżał ideę i sposób działania protokołu iscsi oraz sposób działania inicjatora. Wyjaśniono w nim wiele pojęd i typowych dla iscsi zjawisk. Powtarzanie całego wstępu teoretycznego w niniejszym artykule nie ma sensu, dlatego najlepiej go czytad tak, jak gdyby był rozwinięciem i aktualizacją rozdziału "Cele iscsi". Windows Storage Server 2008 Od pewnego czasu, wśród produktów serwerowych Microsoft, dawała się zauważyd linia Windows Storage Server. Z jednej strony, Storage Server wydawał się bardzo zbliżony do typowego Windows Server, z drugiej zaś, niedostępny był w żadnym kanale dystrybucyjnym jako samodzielny produkt. Jedynym sposobem nabycia Storage Server, było zakupienie sprzętu, na którym system ten był już zainstalowany na zasadach licencji OEM. Idea ta zawsze wydawała się kontrowersyjna i znacząco utrudniała poznanie produktu przez inżynierów i specjalistów, którzy musieli czasem opierad na nim infrastrukturę. Sytuacja ta zmieniła się na początku 2009 roku, kiedy powstała wersja beta Windows Storage Server Podczas spotkania MVP z menedżerami Microsoft, kilkanaście osób praktycznie wymusiło udostępnienie ISO tej wersji systemu, oraz ustalono, że finalna wersja zostanie opublikowana przez MSDN, co nastąpiło ostatecznie w maju 2009 roku. W chwili obecnej wszystkie osoby mające dostęp do subskrypcji MSDN i TechNet mogą z nich pobrad Windows Storage Server Ważne jest jednak, aby pamiętad, że licencja pozwala na użycie tej wersji oprogramowania jedynie do celów testowych i edukacyjnych. Budowanie produkcyjnych rozwiązao na tej wersji serwera nie jest dozwolone, nawet wewnątrz firmy, która ma licencję MSDN lub TechNet. Wraz z Windows Storage Server 2008, udostępniony został Microsoft iscsi Software Target w wersji 3.2 i właśnie to oprogramowanie jest tematem niniejszego artykułu. Instalacja Aby zainstalowad programowy cel (target) iscsi, należy pobrad zawierający go plik ISO ze stron Microsoft. Plik ten po nagraniu, rozpakowaniu lub zamontowaniu w wirtualnej maszynie umożliwia dostęp między innymi do programu instalacyjnego w postaci MSI. Podczas instalacji sprawdzane jest kilka wymogów sprzętowych i programowych, w tym dwa, najistotniejsze w praktyce: Czy system operacyjny jest systemem x64? Czy system operacyjny jest jedną z wersji Windows Storage Server? 1

2 Wymagania te oznaczają tak naprawdę, że instalacja na jakimkolwiek systemie innym niż Windows Storage Server 2008 nie jest możliwa. Co ważne, wśród czterech edycji Windows Storage Server 2008, cel iscsi instalowad można tylko na wersjach Workgroup, Standard i Enterprise. Oczywiście postad MSI pozostawia pole do popisu dla eksperymentatorów i zmuszenie inicjatora do działania na innej platformie nie jest trudne (wymaga tak naprawdę tylko usunięcia trzech wpisów w tabelach MSI). Wydaje się to jednak niepotrzebne, ponieważ każdy mający dostęp do samego celu iscsi ma również dostęp do wersji Storage Server, na których instalacja nie wymaga takich sztuczek. Sama instalacja jest bardzo prosta i w zasadzie sprowadza się do kilkukrotnego naciśnięcia "Next". Oczywiście, można proces ten zautomatyzowad wykorzystując program msiexec i parametry /quiet lub /passive. W normalnych warunkach, instalacja nie wymaga restartu komputera i w kilkanaście sekund od jej rozpoczęcia można zacząd udostępniad dane przez iscsi. Uruchomienie Po instalacji, w systemie dodawany jest serwis systemowy Microsoft iscsi Software Target o nazwie symbolicznej WinTarget i wykorzystujący do działania plik %windir%\system32\wintarget.exe. Serwis ten jest zależny od serwisów RPC, VSS, Event Log oraz WMI. Instalator przygotowuje i uruchamia wszystko, co jest potrzebne, więc żadne dodatkowe działania nie są wymagane do uruchomienia celu iscsi. Należy tylko pamiętad o firewallu, ponieważ działający cel iscsi wcale nie oznacza, że inicjator może się z nim połączyd. Konsola zarządzająca programowym celem iscsi ma typową dla systemów Windows postad MMC i znajduje się w pliku iscsitarget.msc. Skrót do konsoli zarządzającej dodawany jest do Menu Start w narzędziach administracyjnych. Od wersji 3.2 począwszy, konsola zarządzająca integrowana jest z programem Server Manager, tak więc zgodnie z polityką Microsoft, całe zarządzanie serwerem nadal możliwe jest z jednej konsoli. Zaskakujący w obecnych czasach jest brak rozsądnego narzędzia do zarządzania celem iscsi z linii poleceo (nie wspominając już o PowerShell). Należące do pakietu narzędzie wtcli.exe ma tak niewielkie możliwości, że można je tutaj z czystym sumieniem pominąd i przyjąd, że jedyną metodą zarządzania jest korzystanie z konsoli graficznej. Rysunek 1: Konsola iscsi Target 2

3 Jak łatwo zauważyd, w konsoli dostępne są trzy grupy obiektów, które można konfigurowad: iscsi Targets, Devices oraz Snapshots. Zostaną one kolejno omówione w dalszej części artykułu. Możliwości Ponieważ w świecie IT można spotkad wiele różnych celów iscsi, oczywiste jest, że różnią się one między sobą tak wymaganiami jak i funkcjonalnością. Wymagania Microsoft iscsi Software Target 3.2 są jasne i zostały już opisane. Jeżeli chodzi o funkcjonalnośd, to również można ją prosto opisad w kilku punktach: Udostępniad można jedynie statyczne dyski VHD o pojemności do 16TB Istnieje rozbudowany i powiązany z VSS mechanizm zarządzania snapshotami dysków Istnieje możliwośd lokalnego montowania dysków oraz snapshotów Porównując możliwości z wieloma innymi produktami dostępnymi na rynku, można dojśd do wniosku, że funkcjonalnośd celu iscsi w implementacji Microsoft jest mocno ograniczona. Z jednej strony tak jest, z drugiej jednak, praktycznie spotykane środowiska produkcyjne rzadko wymagają czegokolwiek więcej. Pewne zastrzeżenia można mied do braku możliwości udostępniania całego urządzenia (na przykład całego wolumenu dyskowego), jednak mając świadomośd, że Microsoft iscsi Software Target 3.2 pracuje tylko z plikami VHD, dośd prosto można podejśd do projektowanej infrastruktury w taki sposób, że ograniczenie to nie jest problemem. Prawdziwa siła celu iscsi w wykonaniu Microsoft tkwi w mechanizmach związanych ze snapshotami (migawkami), które zostaną szerzej opisane w dalszej części artykułu. Mechanizmy te pozwalają na zautomatyzowanie wykonywania snapshotów, przez co wykonywanie kopii zapasowych jest znacząco uproszczone i może odbywad się na tej samej maszynie, na której pracuje cel iscsi zamiast na korzystającym z niego inicjatorze. Ścisłe powiązanie mechanizmów tworzących snapshoty z VSS (Volume Shadow Copy Service) sprawia, że utworzone przez cel iscsi snapshoty zawierają zawsze spójne dane. Ciekawym ograniczeniem implementacji jest zablokowanie możliwości podłączenia inicjatora z tego samego komputera, na którym działa cel. Trudno zastanawiad się nad celowością takiego ograniczenia, jednak możliwośd lokalnego mapowania dysków i snapshotów sprawia, że nie jest ono w żaden sposób uciążliwe. Co ważne, podczas próby lokalnego połączenia inicjator zwraca mało mówiący komunikat błędu, a cel wpisuje bardziej precyzyjne informacje do dziennika zdarzeo. 3

4 Rysunek 2: Wpisy w dzienniku zdarzeo generowane przez cel iscsi Jak widad, nie dośd, że podany jest dokładny powód błędu, to jeszcze opis zawiera poradę sugerującą, co w takiej sytuacji zrobid. Ogólnie wydaje się, że generowane przez cel iscsi wpisy w dzienniku zdarzeo są użyteczne i naprawdę warto do nich zaglądad. Zarządzanie celami Domyślnie, cel iscsi udostępnia dyski na wszystkich interfejsach, na wszystkich adresach sieciowych IPv4 oraz IPv6 na porcie Specyfikacja mówi, że cel iscsi nie powinien pracowad na więcej niż czterech interfejsach sieciowych równocześnie, ale wydaje się, że w praktyce nie jest to kłopotliwe ograniczenie. Warto pamiętad, że w systemie Windows działa firewall, który może uniemożliwid połączenie z celem. Warto sprawdzid jego konfigurację i dodad stosowne reguły dotyczące portu Jeżeli z jakiegoś powodu, niektóre adresy sieciowe mają byd wyłączone z nasłuchiwania, można nimi zarządzad po wybraniu "Properties" z menu kontekstowego w gałęzi "Microsoft iscsi Software Target" konsoli zarządzającej. Jest to szczególnie użyteczne w produkcyjnych środowiskach, gdzie dobrą praktyką jest odseparowanie sieci używanej przez iscsi od sieci służących do pozostałych zastosowao. Warto również zwrócid uwagę na adresy IPv6. Cel iscsi w wersji 3.2 jest w stanie pracowad tylko na takich adresach i przy całkowitym braku tradycyjnego IPv4. 4

5 Charakterystyczną cechą iscsi jest własne nazewnictwo i przestrzeo nazw niezależna od nazewnictwa i adresacji w sieci. Szczegółowo zostało to wyjaśnione we wspominanym we wstępie artykule "iscsi w systemach Windows". Ta odrębnośd przestrzeni nazw sprawia, że nie jest żadnym problemem umieszczenie na jednym hoście, na jednym adresie IP i na tym samym porcie wielu celów iscsi. Niektóre rozwiązania innych firm narzucają podejście "jedna usługa = jeden cel iscsi" jednak jest to uproszczenie ograniczające często administratora. Wystarczy wyobrazid sobie, że ten sam komputer realizujący usługę celów iscsi musi obsługiwad wiele inicjatorów zapewniając przy tym separację pomiędzy udostępnianymi dyskami. Chodzi o to, aby inicjator A mógł się połączyd ze swoim dyskiem przy użyciu swojego klucza szyfrującego, a inicjator B ze swoim, jednak tak, aby nie mógł sięgnąd do danych przeznaczonych dla inicjatora A. Najrozsądniejsze rozwiązanie opiera się na wielu celach iscsi pracujących na tym samym komputerze. W niektórych przypadkach można zastosowad obejście, opierające się na uruchomieniu wielu takich samych usług na różnych portach IP, jednak rozsądniejsze wydaje się obsłużenie obu inicjatorów przez tą samą usługę, kierującą ruch do poszczególnych dysków. W implementacji Microsoft, zastosowano podejście, w którym nie można zmieniad portów IP i wszystkie inicjatory łączą się z tą samą usługą, jednak na podstawie nazwy iqn są kierowane w odpowiednie miejsce czyli do właściwego celu iscsi. Podsumowując ten zagmatwany teoretyczny wstęp, stwierdzid można, że oprogramowanie iscsi w wykonaniu Microsoft, wymaga poza zainstalowaniem usługi również zdefiniowania co najmniej jednego celu. Maksymalna liczba celów działających na jednym komputerze wynosi 64 a do każdego z nich połączyd się może równocześnie do 16 inicjatorów. Aby zdefiniowad cel iscsi, należy z menu kontekstowego w gałęzi wybrad pozycję "Create iscsi Target". Cel taki charakteryzuje się kilkunastoma parametrami, wśród których warte zwrócenia uwagi są: Nazwa mająca na celu wyłącznie rozróżnienie celów w konsoli zarządzającej. Nazwa ta nie jest w żaden sposób publikowana i nie służy inicjatorom do nawiązywania połączeo. Opis ułatwiający orientowanie się w przypadku istnienia wielu nazw. Dozwolone inicjatory omówione poniżej. Pozostałe opcje celu iscsi nie pojawiają się w kreatorze i dotrzed można do nich dopiero po zakooczeniu tworzenia celu. Lista dozwolonych inicjatorów ma kluczowe znaczenie dla poprawnego działania celu iscsi, ponieważ tylko inicjator, który jest na liście zostanie "dopuszczony" do nawiązania połączenia. Inicjator, który nie został wskazany przez administratora nie będzie mógł się podłączyd do wskazanego celu. Jeżeli na serwerze istnieje jakikolwiek cel zawierający dany inicjator na swoich listach, to uda się nawiązad połączenie, jednak na liście celów pojawią się tylko te, które "znają" inicjator. Inicjator można wskazad na kilka sposobów: Podając pełną nazwę iqn inicjatora Podając nazwę FQDN. Nazwa ta musi byd rozwiązywalna przez revdns, żeby cel mógł sprawdzid jaki inicjator próbuje się z nim połączyd. Podając adres IP lub IPv6 inicjatora. Uwaga! Podanie adresu IPv6 oznacza, że konfigurując inicjator, musimy wskazad adres IPv6 celu. 5

6 Podając MAC Address inicjatora w postaci sześciu dwucyfrowych liczb szesnastkowych (na przykład 00-0C-2A-3F-DE-4B) W praktyce najprostsze wydaje się użycie iqn lub adresów IP, należy mied jednak świadomośd, że obie te wartości są prosto modyfikowalne w systemie inicjatora i z jednej strony istnieje ryzyko, że się kiedyś zmienią, a z drugiej że ktoś sobie skonfiguruje system tak, że dostanie się do zasobów, do których sięgad nie powinien. Chod listy uprawnionych inicjatorów pozwalają na zachowanie porządku, to jednak nie powinny byd traktowane jako poważny mechanizm zabezpieczający. Po utworzeniu celu iscsi, można edytowad wartości wprowadzone w kreatorze lub skonfigurowad inne parametry, takie jak: Nazwę iqn najważniejszy parametr iscsi nie pojawia się w kreatorze. iqn zmodyfikowad można dopiero po utworzeniu celu. Istniejące, zdefiniowane w konsoli zarządzającej, dyski VHD, które są przez cel iscsi publikowane dla inicjatorów. Parametry uwierzytelniania CHAP (oddzielnie z i do inicjatora). Jest to jedyne zabezpieczenie wbudowane w iscsi. Bardziej zaawansowaną ochronę zapewnia się przy użyciu IPSec. Parametry wydajnościowe, w przypadku których Microsoft odradza edycję (takie jak ilośd buforów czy maksymalna długośd segmentu danych) oraz przydatne czasem powiązanie obsługi konkretnego celu z konkretnym procesorem (Affinity). Ponadto, we właściwościach celu można zobaczyd, kiedy miało miejsce ostatnie udane połączenie. Cenną dla administratora funkcją jest również możliwośd wyłączenia celu bez konieczności jego usuwania. Cel taki jest nieaktywny i inicjatory nie mogą się z nim połączyd, jednak w każdej chwili można go uruchomid ponownie. Jak wspomniano powyżej, nazwa iqn celu nadawana jest automatycznie. Domyślnie ma ona postad "iqn com.microsoft:%s-%t-target", jednak można zmienid zarówno istniejące nazwy jak i szablon, na podstawie którego tworzone są nowe. Nowy szablon powinien zostad zapisany w rejestrze. W gałęzi "HKLM\SOFTWARE\Microsoft\iSCSI Target" należy dodad wartośd AutoIQNFormat typu string. W szablonie nazwy używad można pól %G dla unikalnego identyfikatora GUID, %S dla nazwy hosta oraz %T dla nazwy celu podanej w kreatorze przez użytkownika. Istnieją również pola %P oraz %V, są one jednak wykorzystywane przez producentów rozwiązao OEM. Niestety, nie można z interfejsu graficznego w prosty sposób odczytad, jakie inicjatory są w danym momencie przyłączone. W innych celach iscsi jest to możliwe i czasem upraszcza diagnostykę gdy dzieje się coś złego. Mimo, że w dowolnym momencie możliwe jest włączenie uwierzytelniania, najrozsądniej jest uruchomid połączenia iscsi bez ochrony i jeżeli wszystko zadziała włączyd CHAP. Znacząco uprości to lokalizowanie ewentualnych błędów. Zarządzanie dyskami Najważniejszym zastosowaniem celu iscsi jest udostępnianie dysków. Jak wspomniano powyżej, implementacja celu iscsi w wykonaniu Microsoft umożliwia wyłącznie udostępnianie statycznych (o stałym rozmiarze) dysków VHD. 6

7 Chod w warunkach laboratoryjnych i na wirtualnych maszynach dynamicznie dyski VHD bywają użyteczne, nie warto ich braku żałowad w zastosowaniach serwerowych. Narzut wydajnościowy wynikający z konieczności obsługi tablicy BAT oraz z nieuniknionej fragmentacji jest tak duży, że dyski dynamiczne nie są praktycznie użyteczne. Rysunek 3: Zarządzanie dyskami Konsola administracyjna celu iscsi umożliwia nie tylko tworzenie i usuwanie dysków, ale pozwala również na wykonanie kilku innych, dośd użytecznych operacji. W szczególności są to: Import gotowego dysku VHD. Jest to cenna opcja gdy dyski są już przygotowane. Dyski z maszyn wirtualnych dadzą się zaimportowad tylko wtedy, gdy są dyskami statycznymi. Rozszerzenie istniejącego dysku o dodatkową przestrzeo. Warto przy tym pamiętad, że znajdujący się na takim wirtualnym dysku system plików również wymaga rozszerzenia. Nie jest to wykonalne z poziomu zarządzania celem iscsi i należy to wykonad z systemu, który korzysta z danego dysku. Włączenie / wyłączenie dysku. Dysk taki nadal istnieje jako plik VHD, widoczny jest w konsoli zarządzającej, jednak nie jest udostępniany klientom. Podłączenie dysku do opisanego w poprzednim rozdziale celu iscsi. Aby podłączyd dysk, należy po prostu wskazad jeden lub więcej celów iscsi, które będą dysk udostępniad. Tą samą operację można wykonad od strony celu iscsi, wybierając, które dyski mają się w danym przypadku publikowad. Utworzenie snapshotu. Snapshot jest stanem dysku na daną chwilę i może umożliwid dostęp do historycznych danych bez przerywania normalnej pracy. Zamapowanie pliku VHD jako lokalnego dysku. Operacja ta jest o tyle istotna, że nie można użyd inicjatora iscsi do uzyskania dostępu do celów udostępnianych na tym samym komputerze. Równocześnie, jeden komputer z zainstalowanym oprogramowaniem Microsoft iscsi Software Target może obsługiwad do 512 dysków VHD, przy czym do jednego celu nie można podłączyd więcej niż 128 dysków na raz. Wynika to z faktu, że zdefiniowany w specyfikacji SCSI numer LUN (indywidualny dla każdego dysku w ramach jednego celu) ma tylko 7 bitów. 7

8 We właściwościach dysku (dostępnych po wybraniu "Properties") możliwe jest dodatkowo: Tworzenie i usuwanie snapshotów. Eksport snapshotów. Operacja ta w efekcie tworzy we wskazanym celu iscsi dysk, który odpowiada stanowi macierzystego dysku w przeszłości. Oczywiście, jak każda migawka, dysk taki dostępny jest jedynie w trybie tylko do odczytu. Zarządzanie miejscem na snapshoty. Dla każdego dysku wirtualnego, indywidualnie wyznaczyd można dysk, na którym przechowywane są snapshoty oraz określid limit miejsca na nie. Podany limit dotyczy sumy objętości wszystkich snapshotów na danym dysku. Najstarsze dane nie mieszczące się w limitach są automatycznie usuwane. Warto tu przypomnied, że cała funkcjonalnośd snapshotów opiera się w pełni na znanych, dobrze udokumentowanych mechanizmach VSS. Chod cel iscsi nie zabrania w żaden sposób równoczesnego korzystania z jednego dysku przez wiele komputerów (do 16 równocześnie), należy zachowad bardzo daleko idącą ostrożnośd. W przypadku, kiedy dyski nie są chronione przez mechanizmy klastra, próba równoczesnego dostępu z wielu komputerów może zakooczyd się uszkodzeniem danych. Nie jest to cecha samego w sobie celu iscsi, jednak jego zastosowanie może sprawid, że taki niezabezpieczony dostęp będzie łatwiejszy i dlatego warto przed nim przestrzec. Na koniec warto wspomnied o jednej bardzo miłej cesze: w przeciwieostwie do produktów wirtualizacyjnych (VirtualPC, Virtual Server i Hyper-V), tworzenie pliku VHD trwa ułamek sekundy niezależnie od jego rozmiaru. W innych produktach przygotowanie dysków potrafi zająd wiele godzin. Oczywiście takie szybkie tworzenie plików VHD jest potencjalnym zagrożeniem poufności (w ich wnętrzu znajduje się to, co było wcześniej na dysku) i dlatego wymaga uprawnieo administratora, a w szczególności systemowego prawa SE_MANAGE_VOLUME_NAME. Zarządzanie snapshotami Jedną z najciekawszych cech celu iscsi w implementacji Microsoft jest zarządzanie migawkami (snapshotami). Jak wspomniano powyżej, opierają się one na mądrze użytym mechanizmie VSS. W przypadku celu iscsi, możliwe są dośd interesujące zastosowania: Powrót stanu całego dysku do momentu "złapanego" w migawce Zamapowanie migawki (lokalnie oraz przez cel iscsi) jako dysku, bez zakłócenia pracy właściwego pliku VHD Powrót stanu dysku może byd wygodny w sytuacji, kiedy przeprowadza się jakąś testową operację na systemach. Przed operacją można zrobid snapshot i w zależności od rezultatu tej operacji skasowad snapshot lub powrócid do pierwotnego stanu. Funkcjonalności tej należy ostrożnie używad w środowisku produkcyjnym, ponieważ w wielu sytuacjach "cofnięcie się w czasie" może dad dośd nieoczekiwane i negatywne efekty, zwłaszcza w przypadku szeroko rozumianych baz danych. Zamapowanie migawki może mied dwa praktyczne zastosowania. Jednym z nich jest wgląd w dane historyczne, na przykład sprzed kilku dni. Czasem jest to bardzo potrzebne i funkcjonalnośd ta może okazad się w wielu przypadkach cenna. Drugim zastosowaniem są kopie zapasowe. Każdą migawkę można podłączyd jako dysk lokalny pracujący w trybie tylko do odczytu. Ponieważ jest to snapshot, to żaden plik nie jest 8

9 otwarty, nic się nie zmienia, nikt z danych nie korzysta. W takiej sytuacji nawet najprostsze mechanizmy kopii zapasowych (z xcopy włącznie) "poradzą sobie" z danymi i na pewno skopiują je we wskazane miejsce, niezależnie od tego, co w tym samym czasie dzieje się na właściwym dysku. Warto wiedzied, że istnieje ograniczenie, które sprawia, że równocześnie nie można zamapowad więcej niż 32 migawki na raz. Nie wydaje się to jednak bardzo kłopotliwe w praktyce. Jak wspomniano powyżej, zarządzanie przestrzenią dyskową na snapshoty, możliwe jest w gałęzi Devices. Warto wiedzied, że niezależnie od limitów przestrzeni dyskowej pojawia się limit ilości równocześnie istniejących snapshotów. Może ich byd na raz 512 a w niektórych przypadkach 448, ponieważ 64 migawki rezerwowane są przez udostępnione udziały. Pojedynczy dysk VHD może mied maksymalnie 128 snapshotów. Wszystkie snapshoty nie mieszczące się w podanych limitach są automatycznie usuwane, w kolejności od najstarszych do najnowszych. Ograniczenia te wynikają z architektury VSS, jednak wartości limitów są na tyle duże, że nie powinny stanowid problemu w praktyce. Tworzenie snapshotów jest jedną z niewielu funkcjonalności celu iscsi, które zrealizowad można przy pomocy wiersza poleceo. Jak wspomniano wcześniej, służy do tego polecenie wtcli.exe Pozwala to teoretycznie na automatyzację tworzenia snapshotów. "Teoretycznie" ponieważ w tym konkretnym przypadku samodzielne tworzenie zadao w mechanizmie Task Scheduler jest zbędne. Odpowiedni interfejs do takich działao dostępny jest w konsolce zarządzającej i najwygodniej właśnie w niej stworzyd automat wykonujący migawki co zadany czas. Wprawdzie kreator pozwala tylko na wykonywanie snapshotów raz dziennie, raz na tydzieo lub raz na miesiąc, jednak później można dośd swobodnie zmienid ten harmonogram. W razie potrzeby zawsze można sięgnąd do gałęzi "Task Scheduler Library" w programie Task Scheduler i dowolnie zmienid zasady wykonywania snapshotów. Poza prostym wykonywaniem snapshotów, w kreatorze tworzącym harmonogram zaznaczyd można, że ostatnia migawka ma byd dostępna jako dysk lokalny. Kopie zapasowe danych z wolumenów publikowanych przez iscsi stają się wtedy naprawdę proste. W konsoli zarządzającej celu iscsi możliwa jest również operacja eksportowania snapshotu. W praktyce oznacza to zamapowanie takiego snapshotu do jednego z dostępnych celów iscsi. Uzyskane dzięki temu dane historyczne nie pojawiają się lokalnie, tylko dostępne są z dowolnego uprawnionego inicjatora iscsi. W pewnych scenariuszach może okazad się to użyteczne, jednak w praktyce cenniejsza zwykle jest opcja lokalnego montowania migawki. Wysoka dostępność Protokół iscsi często kojarzony jest z klastrami. Faktycznie jest to najprostsza i najtaosza metoda zapewnienia współdzielonej pamięci masowej, dzięki której klaster jest w stanie dobrze pracowad. W efekcie, cele iscsi wykorzystuje się powszechnie w środowiskach testowych, laboratoryjnych i szkoleniowych. W środowiskach takich zazwyczaj nikt się nie zastanawia jednak nad wysoką dostępnością usługi realizującej funkcjonalnośd celu iscsi. Warto nad tym chwilę pomyśled. W przypadku awarii takiej usługi, skutki mogą byd bardzo poważne, ponieważ żaden z korzystających z niej inicjatorów iscsi nie ma dostępu do danych. Opisana wcześniej usługa systemowa WinTarget odpowiedzialna za cel iscsi jest usługą jak każda inna i można ją bez problemu uruchomid w klastrze. W tym celu należy utworzyd nową grupę zasobową w klastrze przed konfiguracją celu iscsi. Najrozsądniejsze wydaje się skonfigurowanie usługi jako zasobu klastrowego typu "Other Server". Można wtedy prosto nadad mu adres IP i całośd powinna działad bez problemu. Po uruchomieniu usługi w klastrze, przystąpid można do konfigurowania celów i dysków. 9

10 Podsumowanie Podsumowując niniejszy opis Microsoft iscsi Software Target, stwierdzid można, że jest to pełnowartościowe oprogramowanie, na którym można oprzed istotne elementy infrastruktury IT. Wprawdzie ma ono dośd znaczące ograniczenie polegające na tym, że obsługuje wyłącznie pliki VHD, jednak w praktyce nie powinno to byd poważną przeszkodą. Nawet, jeżeli uzna się, że wykorzystanie plików VHD zamiast udostępniania całych urządzeo jest niewygodne, to na pewno funkcjonalnośd związana ze snapshotami rekompensuje te niewygody. Oprogramowanie Microsoft iscsi Software Target dostępne jest wraz z Microsoft Windows Storage Server 2008 od kwietnia 2009 przez MSDN i TechNet i mimo, że na samodzielnie pobranych z Microsoft wersjach nie wolno budowad produkcyjnych rozwiązao, to na pewno warto im się bliżej przyjrzed. Autor Grzegorz Tworek (Konsultant ISCG, MVP) Inżynier systemowy, komputerowiec w drugim pokoleniu. Od wielu lat aktywnie promuje idee związane z bezpieczeostwem 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. 10