iSCSI na guest’cie. optymalizacja

można wyobrazić sobie dwa modele podłączenia dysku  iSCSI z danymi do maszyny wirtualnej:

• oba dyski dostępne są jako vhd na hosta i z tego poziomu podpięte do guesta
• dysk systemowy jest widoczny dla hosta a dysk z danymi jest dostępny via iSCSI i mountowany z poziomu guesta

jaka jest różnica?

różnica będzie polegać na kilku elementach: optymalizacji wykorzystania sieci, gdzie wchodzi przepustowość, i MPIO oraz wykorzystania pewnych mechanizmów – np. snpshotów, a to wiąże się z backupami. różni się również przenaszalność/elastyczność.

Scenariusz 1 – oba dyski jako vhd

niewątpliwie jest bardziej standardowym scenariuszem. dysk systemowy i dysk z danymi są w postaci VHD widoczne na poziomie hosta. zazwyczaj takie dyski będą albo lokalnie na serwerze albo na macierzy. bardziej interesujący jest przypadek z macierzą:

• jasna sprawa, że w takiej konfiguracji cała optymalizacja będzie realizowana z poziomu hosta. tutaj musi być odpowiednio skonfigurowane np. MPIO
• najważniejszą kwestią jest przepustowość sieci. jeśli maszyn wirtualnych jest wiele – a tak zazwyczaj jest, to (zakładając, że to konfiguracja Hyper-V z Cluster Shared Volume) wykorzystywane jest pojedyncze połączenie dla wszystkich maszyn. można zatem próbować kombinować z różnymi mechanizmami agregacji – czy to teaming kart sieciowych czy LACP. gdzieś na stronach MS można znaleźć, że Microsoft iSCSI nie obsługuje MPIO dla kart w teamingu, ale nie potwierdzam tego w praktyce i znalazłem podobne opinie na innych blogach.
• druga kwestia to mechanizmu snapshotów – macierz ma zazwyczaj swoje mechanizmy a Windows ma swoje [VSS dla systemu oraz snapshoty dla Hyper-v]. i tu zaczyna się trochę kombinowania – który mechanizm da najlepsze wyniki i jak to skonfigurować. aplikacje backupujące będą odwoływać się do VSS Hyper-V. jeśli tylko producent dostarcza odpowiednie sterowniki, można jednym snapshotem z poziomu macierzy zrobić wszystkie maszyny – warto zwrócić się do producenta maszyny o informacje czy jest to wspierane i jak to skonfigurować, ponieważ zysk może być duży.
• jest to rozwiązanie bardzo przenaszalne – ponieważ pliki vhd łatwo skopiować, podmountować itp, itd. w związku z czym łatwo zarządza się całym dyskiem jako pojedynczym plikiem.

Scenariusz 2 – dysk z danymi jako iSCSI

w pewnych sytuacjach może jednak być potrzeba innej optymalizacji. dysk z danymi może być jako volumen na macierzy udostępniany via iSCSI. jak wygląda optymalizacja i potencjalny zysk:

• daje to dużą dynamikę w alokacji przepustowości sieci, ponieważ można dedykować konkretny interfejs sieciowy dla konkretnego guesta (albo kilq) mapując go z poziomu Hyper-V i wykorzystać do połączenia iSCSI
• inaczej też wyglądają wtedy możliwości snapshotowania – host oczywiście nie dostanie się do takiego dysku a więc mechaznimy backupu muszą być optymalizowanie na poziomie guesta lub macierzy. nie da się w takim wypadku skorzystać ze sterowników macierzy dla Hyper-V.
• przenaszalność jest ograniczona – co prawda volumen można za pomocą iSCSI połączyć na dowolnym hoście, ale wszelkie mechanizmy dostępowe/zarządzania przenoszą się na macierz.
• olbrzymim zyskiem jest możliwość bardzo łatwej i bardzo szybkiej zmiany wielkości partycji danych – w przypadku vhd taka operacja zajmie wiele godzi, w tym scenariuszu – kilka sekund.

które lepsze?

w większości przypadków – scenariusz 1. daje to zoptymalizowane wykorzystanie sieci oraz potencjalnie – wsparcie mechanizmów snapshotowania z poziomu hosta przez macierz. jednak jeśli przyrost danych jest nie do przewidzenia lub konieczne jest dedykowane łącze zapewniające 1oo% przepustowości sieci – w takim wypadku scenariusz 2 staje się bardzo zachęcający.

eN.