Microsoft Server 2008

Microsoft iSCSI Software Target Udostępnij na: Facebook

Autor: Grzegorz Tworek

Opublikowano: 17 lipca 2009

 Windows Storage Server 2008   Windows Storage Server 2008
 Instalacja   Instalacja
Uruchomienie  Uruchomienie
Możliwości  Możliwości
Zarządzanie celami  Zarządzanie celami
Zarządzanie dyskami  Zarządzanie dyskami
Zarządzanie snapshotami  Zarządzanie snapshotami
Wysoka dostępność  Wysoka dostępność
Podsumowanie  Podsumowanie
 

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ęć i typowych dla iSCSI zjawisk. Powtarzanie całego wstępu teoretycznego w niniejszym artykule nie ma sensu, dlatego najlepiej go czytać tak, jak gdyby był rozwinięciem i aktualizacją rozdziału "Cele iSCSI".

Pobierz
Pobierz artykuł w pliku:

Windows Storage Server 2008

Od pewnego czasu, wśród produktów serwerowych Microsoft, dawała się zauważyć 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 opierać na nim infrastrukturę.

Sytuacja ta zmieniła się na początku 2009 roku, kiedy powstała wersja beta Windows Storage Server 2008. 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 pobrać Windows Storage Server 2008. Ważne jest jednak, aby pamiętać, że licencja pozwala na użycie tej wersji oprogramowania jedynie do celów testowych i edukacyjnych. Budowanie produkcyjnych rozwiązań 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.

 Do początku strony Do początku strony

Instalacja

Aby zainstalować programowy cel (target) iSCSI, należy pobrać 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?

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 instalować można tylko na wersjach Workgroup, Standard i Enterprise. Oczywiście postać 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 zautomatyzować 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ąć udostępniać dane przez iSCSI.

 Do początku strony Do początku strony

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ętać o firewallu, ponieważ działający cel iSCSI wcale nie oznacza, że inicjator może się z nim połączyć.

Konsola zarządzająca programowym celem iSCSI ma typową dla systemów Windows postać 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 poleceń (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ąć i przyjąć, że jedyną metodą zarządzania jest korzystanie z konsoli graficznej.

Konsola iSCSI Target

Rysunek 1: Konsola iSCSI Target

Jak łatwo zauważyć, w konsoli dostępne są trzy grupy obiektów, które można konfigurować: iSCSI Targets, Devices oraz Snapshots. Zostaną one kolejno omówione w dalszej części artykułu.

 Do początku strony Do początku strony

Możliwości

Ponieważ w świecie IT można spotkać 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ść, to również można ją prosto opisać w kilku punktach:

  • Udostępniać 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ść lokalnego montowania dysków oraz snapshotów

Porównując możliwości z wieloma innymi produktami dostępnymi na rynku, można dojść do wniosku, że funkcjonalność 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 mieć do braku możliwości udostępniania całego urządzenia (na przykład całego wolumenu dyskowego), jednak mając świadomość, że Microsoft iSCSI Software Target 3.2 pracuje tylko z plikami VHD, dość prosto można podejść 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 odbywać 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 zastanawiać się nad celowością takiego ograniczenia, jednak możliwość 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 zdarzeń.

Konsola iSCSI Target

Rysunek 2: Wpisy w dzienniku zdarzeń generowane przez cel iSCSI

Jak widać, nie dość, że podany jest dokładny powód błędu, to jeszcze opis zawiera poradę sugerującą, co w takiej sytuacji zrobić. Ogólnie wydaje się, że generowane przez cel iSCSI wpisy w dzienniku zdarzeń są użyteczne i naprawdę warto do nich zaglądać.

 Do początku strony Do początku strony

Zarządzanie celami

Domyślnie, cel iSCSI udostępnia dyski na wszystkich interfejsach, na wszystkich adresach sieciowych IPv4 oraz IPv6 na porcie 3260.

Specyfikacja mówi, że cel iSCSI nie powinien pracować na więcej niż czterech interfejsach sieciowych równocześnie, ale wydaje się, że w praktyce nie jest to kłopotliwe ograniczenie. Warto pamiętać, że w systemie Windows działa firewall, który może uniemożliwić połączenie z celem. Warto sprawdzić jego konfigurację i dodać stosowne reguły dotyczące portu 3260.

Jeżeli z jakiegoś powodu, niektóre adresy sieciowe mają być wyłączone z nasłuchiwania, można nimi zarządzać 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 zastosowań. Warto również zwrócić uwagę na adresy IPv6. Cel iSCSI w wersji 3.2 jest w stanie pracować tylko na takich adresach i przy całkowitym braku tradycyjnego IPv4.

Charakterystyczną cechą iSCSI jest własne nazewnictwo i przestrzeń 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ść 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 wyobrazić sobie, że ten sam komputer realizujący usługę celów iSCSI musi obsługiwać wiele inicjatorów zapewniając przy tym separację pomiędzy udostępnianymi dyskami.

Chodzi o to, aby inicjator A mógł się połączyć ze swoim dyskiem przy użyciu swojego klucza szyfrującego, a inicjator B – ze swoim, jednak tak, aby nie mógł sięgnąć 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 zastosować 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 zmieniać 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, stwierdzić 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łączyć się może równocześnie do 16 inicjatorów.

Aby zdefiniować cel iSCSI, należy z menu kontekstowego w gałęzi wybrać 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łączeń.
  • 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 dotrzeć można do nich dopiero po zakończeniu 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łączyć do wskazanego celu. Jeżeli na serwerze istnieje jakikolwiek cel zawierający dany inicjator na swoich listach, to uda się nawiązać połączenie, jednak na liście celów pojawią się tylko te, które "znają" inicjator. Inicjator można wskazać na kilka sposobów:

  • Podając pełną nazwę iQN inicjatora
  • Podając nazwę FQDN. Nazwa ta musi być rozwiązywalna przez revDNS, żeby cel mógł sprawdzić jaki inicjator próbuje się z nim połączyć.
  • Podając adres IP lub IPv6 inicjatora. Uwaga! Podanie adresu IPv6 oznacza, że konfigurując inicjator, musimy wskazać adres IPv6 celu.
  • 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 mieć jednak świadomość, ż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ęgać nie powinien. Choć listy uprawnionych inicjatorów pozwalają na zachowanie porządku, to jednak nie powinny być traktowane jako poważny mechanizm zabezpieczający.

Po utworzeniu celu iSCSI, można edytować wartości wprowadzone w kreatorze lub skonfigurować inne parametry, takie jak:

  • Nazwę iQN – najważniejszy parametr iSCSI nie pojawia się w kreatorze. iQN zmodyfikować 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ść buforów czy maksymalna długość segmentu danych) oraz przydatne czasem powiązanie obsługi konkretnego celu z konkretnym procesorem (Affinity).

Ponadto, we właściwościach celu można zobaczyć, kiedy miało miejsce ostatnie udane połączenie. Cenną dla administratora funkcją jest również możliwość wyłączenia celu bez konieczności jego usuwania. Cel taki jest nieaktywny i inicjatory nie mogą się z nim połączyć, jednak w każdej chwili można go uruchomić ponownie.

Jak wspomniano powyżej, nazwa iQN celu nadawana jest automatycznie. Domyślnie ma ona postać "iqn.1991-05.com.microsoft:%S-%T-target", jednak można zmienić zarówno istniejące nazwy jak i szablon, na podstawie którego tworzone są nowe. Nowy szablon powinien zostać zapisany w rejestrze. W gałęzi "HKLM\SOFTWARE\Microsoft\iSCSI Target" należy dodać wartość AutoIQNFormat typu string. W szablonie nazwy używać 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ązań OEM.

Niestety, nie można z interfejsu graficznego w prosty sposób odczytać, 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 uruchomić połączenia iSCSI bez ochrony i jeżeli wszystko zadziała – włączyć CHAP. Znacząco uprości to lokalizowanie ewentualnych błędów.

 Do początku strony Do początku strony

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.

Choć w warunkach laboratoryjnych i na wirtualnych maszynach dynamicznie dyski VHD bywają użyteczne, nie warto ich braku żałować 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.

Zarządzanie dyskami

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ść 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ę zaimportować tylko wtedy, gdy są dyskami statycznymi.
  • Rozszerzenie istniejącego dysku o dodatkową przestrzeń. Warto przy tym pamiętać, ż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 wykonać 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łączyć dysk, należy po prostu wskazać jeden lub więcej celów iSCSI, które będą dysk udostępniać. Tą samą operację można wykonać od strony celu iSCSI, wybierając, które dyski mają się w danym przypadku publikować.
  • Utworzenie snapshotu. Snapshot jest stanem dysku na daną chwilę i może umożliwić 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żyć 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ługiwać do 512 dysków VHD, przy czym do jednego celu nie można podłączyć 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.

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 wyznaczyć można dysk, na którym przechowywane są snapshoty oraz określić 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 przypomnieć, że cała funkcjonalność snapshotów opiera się w pełni na znanych, dobrze udokumentowanych mechanizmach VSS.

Choć 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 zachować bardzo daleko idącą ostrożność. W przypadku, kiedy dyski nie są chronione przez mechanizmy klastra, próba równoczesnego dostępu z wielu komputerów może zakończyć się uszkodzeniem danych. Nie jest to cecha samego w sobie celu iSCSI, jednak jego zastosowanie może sprawić, że taki niezabezpieczony dostęp będzie łatwiejszy i dlatego warto przed nim przestrzec.

Na koniec warto wspomnieć o jednej bardzo miłej cesze: w przeciwieństwie 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ąć 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 uprawnień administratora, a w szczególności systemowego prawa SE_MANAGE_VOLUME_NAME.

 Do początku strony Do początku strony

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ść 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 być wygodny w sytuacji, kiedy przeprowadza się jakąś testową operację na systemach. Przed operacją można zrobić snapshot i w zależności od rezultatu tej operacji – skasować snapshot lub powrócić do pierwotnego stanu. Funkcjonalności tej należy ostrożnie używać w środowisku produkcyjnym, ponieważ w wielu sytuacjach "cofnięcie się w czasie" może dać dość nieoczekiwane i negatywne efekty, zwłaszcza w przypadku szeroko rozumianych baz danych.

Zamapowanie migawki może mieć 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ść ta może okazać się w wielu przypadkach cenna. Drugim zastosowaniem są kopie zapasowe. Każdą migawkę można podłączyć jako dysk lokalny pracujący w trybie tylko do odczytu. Ponieważ jest to snapshot, to żaden plik nie jest 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 wiedzieć, że istnieje ograniczenie, które sprawia, że równocześnie nie można zamapować 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 wiedzieć, że niezależnie od limitów przestrzeni dyskowej pojawia się limit ilości równocześnie istniejących snapshotów. Może ich być na raz 512 a w niektórych przypadkach 448, ponieważ 64 migawki rezerwowane są przez udostępnione udziały. Pojedynczy dysk VHD może mieć 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 stanowić problemu w praktyce.

Tworzenie snapshotów jest jedną z niewielu funkcjonalności celu iSCSI, które zrealizować można przy pomocy wiersza poleceń. 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 zadań w mechanizmie Task Scheduler jest zbędne. Odpowiedni interfejs do takich działań dostępny jest w konsolce zarządzającej i najwygodniej właśnie w niej stworzyć automat wykonujący migawki co zadany czas. Wprawdzie kreator pozwala tylko na wykonywanie snapshotów raz dziennie, raz na tydzień lub raz na miesiąc, jednak później można dość swobodnie zmienić ten harmonogram. W razie potrzeby zawsze można sięgnąć do gałęzi "Task Scheduler Library" w programie Task Scheduler i dowolnie zmienić zasady wykonywania snapshotów. Poza prostym wykonywaniem snapshotów, w kreatorze tworzącym harmonogram zaznaczyć można, że ostatnia migawka ma być 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 okazać się to użyteczne, jednak w praktyce cenniejsza zwykle jest opcja lokalnego montowania migawki.

 Do początku strony Do początku strony

Wysoka dostępność

Protokół iSCSI często kojarzony jest z klastrami. Faktycznie jest to najprostsza i najtańsza metoda zapewnienia współdzielonej pamięci masowej, dzięki której klaster jest w stanie dobrze pracować. 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ść celu iSCSI. Warto nad tym chwilę pomyśleć. W przypadku awarii takiej usługi, skutki mogą być 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 uruchomić w klastrze. W tym celu należy utworzyć 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 nadać mu adres IP i całość powinna działać bez problemu. Po uruchomieniu usługi w klastrze, przystąpić można do konfigurowania celów i dysków.

 Do początku strony Do początku strony

Podsumowanie

Podsumowując niniejszy opis Microsoft iSCSI Software Target, stwierdzić można, że jest to pełnowartościowe oprogramowanie, na którym można oprzeć istotne elementy infrastruktury IT. Wprawdzie ma ono dość znaczące ograniczenie polegające na tym, że obsługuje wyłącznie pliki VHD, jednak w praktyce nie powinno to być poważną przeszkodą. Nawet, jeżeli uzna się, że wykorzystanie plików VHD zamiast udostępniania całych urządzeń jest niewygodne, to na pewno funkcjonalność 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 budować produkcyjnych rozwiązań, to na pewno warto im się bliżej przyjrzeć.


Grzegorz Tworek 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 Do początku strony

Microsoft Server 2008