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.

-o((:: sprEad the l0ve ::))o-

Comments (3)

  1. gt

    Odpowiedz

    Scenariusz 2 pozwala zbudować klaster między wirtualkami. W scenariuszu 1 jest to niemożliwe.

  2. gt

    Odpowiedz

    Oczywiście! Powód taki sam jak na fizycznych maszynach: niezawodność usług. Print Server, DHCP i parę innych. Albo choćby mieszany cluster SQL między fizyczną maszyną (preferowaną) a wirtualką (na wszelki wypadek).

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Time limit is exhausted. Please reload CAPTCHA.