Skip to Content

IT nieuczesane.
archive

> Monthly Archives: Sierpień 2012

disk2vhd na wersji core

przy uruchomieniu disk2vhd na w2k8 R2 od razu pojawia się ‘missing vssapi.dll’. kwestią jest wersja x64 a standardowo próbuje dostępu do 32bit biblioteki. proste rozwiązanie:

set path=c:windowssyswow64;%path%

a potem już disk2vhd śmiga jak trzeba.

ps. próbowałem stworzyć ‘livecd’ z disk2vhd – tak, aby można było zfałhadekować offlineowy serwer. niestety na żadnym WinPE – nawet w DaRTS – nie jest uruchamiany podsystem obsługi vhd ): póki co nie mam pojęcia czy da się [i jak] stworzyć WinPE z obsługą VHD.

eN.

Tymczasem na rynku urządzeń mobilnych

mobile

Zmiany w grupach mailowych

przy zmianach w grupach mailowych na Exchange robi się niezłe zamieszanie. podstawowe powody to:

  • klienty outlook przechowują sobie ‘często używane’ adresy w plikach NK2
  • opcja automatycznego dokańczania Exchange korzysta z adresów X5oo

przykładowy scenariusz

  • porządki w grupach. aby usunąć duplikujące się grupy security i distribution chcemy przepisać adresy mailowe do grup security.

w takim przypadku trzeba usunąć stare grupy dystrybucyjne [usunięcie grupy security to szaleństwo], przerobić grupy security na uniwersalne [komentarz za chwilę] i przypisać im stary email. potem wykonać ‘update address book’. i teraz zaczyna się masakra. po pierwsze outlooki *teoretycznie* powinny odświeżyć książkę adresową w ciągu 24h – moja obserwacja tego nie potwierdza. ale dużo gorsza sprawa jest z ‘auto-complete’, który usilnie będzie próbował wysyłać maile na nieistniejący adres X5oo.

jedną z opcji byłoby dodanie skryptu logowania, który usuwa pliki NK2… ale nie jestem przekonany do takiej operacji. drugą, bardziej przeźroczystą opcją, jest po prostu dodanie starego adresu X5oo do nowej grupy. link do artu, który to w pełni opisuje jest tutaj.

grupy uniwersalne

wymuszenie korzystania z grup uniwersalnych jest imho głupie. rozumiem, że “czasy się zmieniają i nic nie jest takie jak przedtem” ale:

  • z każdym kolejnym wydaniem Server znikała jakakolwiek techniczna konieczność tworzenia poddomen. ostatnią były polityki haseł, które zostały zniesione w 2k8 R2 z fine-grained passwords. pozostają kwestie raczej polityczne.
  • rozbija to standardowy model grup AGDLP. wszelkie modyfikacje – choćby jak w przedstawionym scenariuszu, wiążą się z dużo większymi zmianami niż początkowo planowane. w złożonych strukturach, przy sporym zagnieżdżeniu, okazuje się, że sporo trzeba dodatkowo przemyśleć
  • jeśli korzystamy z grup globalnych mail-enabled, po przerobieniu na uniwersalne, zwiększa się ruch replikacyjny na GC.

oczywiście nadal można korzystać z globalnych, ale nie jest to wpierane [głównie przez interfejs] co jest dość upierdliwe. dziwna decyzja /:

eN.

Migration attempt failed

problemy z live migration są ohydne do debugowania. poza krótkim opisem ‘migration attempt failed’ i enigmatycznym wpisie w eventvwr, który w najlepszym przypadq podpowie ‘error on source/destionation’ nie wiadomo nic więcej. pozostaje zbadanie całej konfiguracji krok-po-kroq. BUEEE.

najczęstszą przyczyną są błędy w nazewnictwie – np. sieci wirtualnych. literówki, brak jakiejś spacji etc. dość łatwo to przetestować po prostu podłączając do innej sieci i sprawdzić czy działa.

doczytałem o problemie z przesyceniem łącza dla LiveMigration – dlatego MS zaleca aż dwa dedykowane połączenia bezpośrednie między węzłami – oddzielne na LM i oddzielne na CSV i Hearbeat.

trafiłem na bardziej wredny problem ale trywialny w rozwiązaniu:
wszystko hula jak trzeba, maszyny używane od jakiegoś czasu, więc żadne literówki nie wchodzą w grę. na wszelki wypadek porobiłem testy migracji – maszyny, które mają pojedyncze dyski migrują się bez problemu… kłopot z migracją był tylko z maszynami, które miały podłączone dodatkowe dyski na drugim CSV. już chciałem się wściekać, że “to głupie LM nie obsługuje dwóch CSV”… ale zauważyłem, że w interfejsie brakuje informacji o powiązaniu z drugim CSV:

image

a rozwiązanie jest tak proste:

  • po każdej zmianie wykonanej z poziomu Hyper-V Manager – bez względu czy dotyczy dysków, sieciówek czy czegokolwiek – należy odświeżyć konfigurację na klastrze.

 

w widoq maszyny wirtualnej RMB –> more actions –> refresh virtual machine configuration.

image

**UPDATE

i jeszcze jeden LoL http://blogs.msdn.com/b/robertvi/archive/2011/06/07/problems-with-live-migration.aspx

eN.

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.