Skip to Content

IT nieuczesane.
category

Category: tips’n’tricks

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.

powershell–uruchomienie exe z parametrem

w całej ‘genialności’ projektanci PS zapomnieli o totalnie najprostszych rzeczach, które co-i-rusz wychodzą. bardzo chciałbym się pozbyć nawyq uruchamiania konsolki cmd ale do cholery… uruchomienie najprostszej instalki z parametrem bywa co najmniej uciążliwe.

w przeciwieństwie do starego ‘okienka DOS’ konsola PS próbuje interpretować cały ciąg jako instrukcję PS. i tak wpisanie:

costam param=1 –option 2 {otherParam:3}

w DOS spowoduje:

  • próbę odnalezienia polecenia ‘costam’
  • jeśli znaleziony – przekazanie całej reszty ciągu do obsłużenia przez ‘costam’

w PS natomiast sprawdzana jest składania całego polecenia. w win 8 jest powershell v3 gdzie pojawiło się specjalne oznaczenie:

--%

które mówi PS aby nie interpretować dalszej części linii. w starszych PS można albo łapać się prawą ręką za lewe ucho przekładając ją pod tyłkiem, albo po prostu odpalić cmd – np. ‘cmd /c polecenie’. dla chętnych do zabawy proszę najlepszy link jaki znalazłem: http://edgylogic.com/blog/powershell-and-external-commands-done-right/

a dodawanie wynalazków typu – – % może i działa i jest wyjściem, niemniej zaczyna przypominać wynalazki z cmd – gdzie zależnie od wykonania używało się coraz dziwaczniejszcyh figur i sztuczek. mam nadzieję, że nie doprowadzą do podobnego bałaganu…

eN.

jak usunąć nieistniejącą sieciówkę?

można grzebać się po rejestrach – i być może czasem jest to niezbędne:

ale można prościej i bez ryzyka. w starych windows wystarczyło uruchomić managera urządzeń i włączyć widok ukrytych urządzeń. w w7/w2k8 trzeba dodatkowo zastosować drobny trick:

  • uruchom cmd [jako admin]
  • ustaw zmienną środowiskową: set devmgr_show_nonpresent_devices=1
  • odpal managera urządzeń: devmgmt.msc
  • włącz widok ukrytych urządzeń: view-> show hiden devices

i teraz ślicznie widać usunięte siecióki – wystarczy usunąć i ładnie wywalą wszystko co trzeba z rejestru (:

eN

Hyper-V cluster i Cluster Shared Volumes

 

na ten temat znaleźć można wiele artykułów od stron technet po wpisy na blogu:

to tylko kilka przykładów [polecam zwłaszcza ten ostatni]. niemniej jest kilka pytań, na które nie umiałem znaleźć odpowiedzi. a więc podsumowując oraz co nieco dodając…

konfiguracja interfejsów sieciowych na Hyper-V Cluster

to największy problem i najbardziej zagmatwany. wykorzystanie interfejsów sieciowych jest co najmniej nieintuicyjne – zarówno dla klastra jak i samego Hyper-v. po pierwsze ile ich jest potrzebne:

  • potrzebne są oddzielne interfejsy dla:
    • iSCSI [jeśli używane do dostępu do macierzy]. oczywiście sugerowana redundancja.
    • heartbit + LiveMigration
    • Host Network – komunikacja z węzłem, HV, i inne takie
    • Virtual Switch – min. jedna ale oczywiście zależne od ilości maszyn

w niektórych artykułach jest wręcz przykazane, aby było jeszcze jedno połączenie – dedykowane dla Clustered Shared Volumes. jako niebezpieczeństwo łączenia funkcji heartbeat i LM jest możliwośc pełnego wysycenia podczas migracji i utraty heartbeatu – a co za tym idzie zfailowania całego klastra. nie wiem na czym dokładnie polega komunikacja CSV i jakie są jej wymagania – nie udało mi się tego odnaleźć w żadnym z artów.

jak widać, zakładając wykorzystanie iSCSI, minimalna sugerowana ilość to 4 interfejsy. 3 wykorzystane na samą infrastrukturę. teraz druga kwestia – jak toto skonfigurować?

  • iSCSI – interfejs powinien mieć wyłączone wszystkie dowiązania protokołów (bindings) poza niezbędnym, czyli TCP/IP – v4 lub v6 zależnie z której korzystamy. obecnie można przyjąć, że v4 – tak zapewne ma 99,9% środowisk.
    • numeracja sieci: prywatna, bez zdefiniowanego GW
    • w konfiguracja klastra ta sieć powinna być oznaczona jako ‘do not allow cluster network communication on this network’. nie chcemy przecież zaśmiecać iSCSI…
    • konfiguracja zazwyczaj oparta na VLANach – należy pamiętać o zapewnieniu maksymalnej redundancji
  • heartbeat + LiveMigration + CSV – do wymiany danych przy LM powinien być dedykowany interfejs. imho można zaryzykować i połączyć te role. UWAGA! sugerowane są dwa oddzielne interfejsy – jeden na CSV+HB drugi na LM. tylko zaczyna się ich robić strasznie mało dla maszyn…
    • numeracja sieci – prywatna [inna niż dla iSCSI], bez zdefiniowanego GW. połączenie najlepiej fizyczne – bezpośrednie. ew. może być VLAN [ale po co sobie utrudniać życie?]
    • ze względu na Cluster Shared Volumes muszą być włączone protokoły ‘Client for Microsoft Network’ oraz ‘File and Printer Sharing for Microsoft Networks’
    • no i oczywiście TCP/IP w odpowiedniej wersji
  • Host Network – czyli zwykły dostęp do serwera.
    • numeracja sieci: sieć lokalna, powinien być oczywiście GW i DNS. na podstawie tego czy GW jest zdefiniowany czy nie, algorytm LM dobiera sieć, którą będzie pchał dane. można to wymusić ręcznie, ale standard jest właśnie taki: na normalnym interfejsie jest GW, a na specjalnych go nie powinno być [ w większości to i tak połączenia punkt-punkt]. z tego też korzystają mechanizmy samej usługi clustra – w LABie trzeba było na siłę wpisywać GW bo głupek nie przyjmował takiego interfejsu q:
    • tu oczywiście można zostawić wszystkie wymagane protokoły wraz z QoS i LLT
  • Virtual Switch – czyli co najmniej jeden interfejs dla maszyn wirtualnych. raczej będzie ich sporo więcej. dla każdego takiego interfejsu zostanie utworzona karta wirtualna. przeważnie podczas konfiguracji VirtualSwitcha [czyli po prostu sieci] w Hyper-V, interfejs jest konfigurowany automatycznie.. ale nie zawsze. wynikowo jest tak: 
    • konfiguracja wymaga opisania obu interfejsów – fizycznego i wirtualnego:
      • fizyczny: można odbindować wszystkie protokoły. samego interfejsu nie można wyłączyć, bo wirtualny również przestanie działać. oczywiście trzeba zostawić ‘Microsoft Virtual Switch Protocol’.
      • wirtualny z HV: ponieważ fizyczny jest ‘przechwytywany’ i staje się switchem, wirtualny staje się jego odpowiednikiem – jest jako zwykła sieciówka, która może być wykorzystana do komunikacji. co z nią zrobić? można choćby wyłączyć – nie do końca znalazłem odpowiedź czy to czymś grozi ale na logikę.. nie powinno.

Cluster Shared Volume

czytając arty odnosi się wrażenie, że konfiguracja to kilka kliknięć. być może w labie – ale ja mam na drugie Murphy. owszem – wystarczy trochę poklikać i jest. jednak kilka ważnych informacji:

  • nie zapomnieć wywalić dedykowanych sieci – oznaczyć jako ‘do not allow cluster network communication on this network’  – np. iSCSI
  • trzeba sprawdzić której sieci używa cluster do komunikacji LiveMigration – jest to znów nieintuicyjne ponieważ sprawdza się we właściwościach zasobu a nie na poziomie samego clustra. dodatkowo jest dziwne – ponieważ zmiana tego ustawienia na pojedynczym zasobie jest globalna…
  • trzeba sprawdzić której siei używa cluster do komunikacji CSV – i tego już z GUI się nie zrobi.

inne takie…

  • bardzo nie chciałem serwerów HP – wsparcie tej firmy jest fatalne. i serwery są droższe. niestety zostałem pozbawiony wyboru i qpilismy HP. dodatkowo wybrałem architekturę AMD – więcej corów w mniejszej cenie daje większą elastyczność przy dystrybucji zasobów procesora na maszyny wirtualne.
  • niesamowite jest ile startują te HPki! trzeba czekać ok. 2min [SIC!] zanim w ogóle zacznie uruchamiać się BIOS. do tej porty wydawało mi się, że BIOS jest zawsze pierwsze – ale w tych serwerach jest coś, co się dzieje wcześniej. MASAKRA.
  • z AMD natomiast jest inny ból – Hyper-V nie chce działać, złośliwie mówiąc, że procesor nie wspiera wirtualizacji albo nie jest włączony DEP. okazuje się, że jest to spowodowane dodaniem do Opterownów z serii Buldozer technologii AVX. szczęśliwie jest na to poprawka: opis i download poprawki KB jest tutaj. pomimo, że technologia jest
    również w Intelach – poprawka jest tylko dla AMD. O_o
  • pozostaje kwestia konfiguracji jumboframes… na co najmniej oddzielny artykuł – to kolejna sprawa, która najczęściej podsumowywana jest ‘wystarczy włączyć’, a kiedy sprawę się ruszy okazuje się, że konfiguracja tego badziewia jest przytłaczająca i roi się wyjątków, wyjąteczków i wyjątusiów. wyjątusie są najgorsze q:
  • tak na prawdę to siedzę nad konfiguracją tego syfu 4 dzień i nadal mi nie działa – po uruchomieniu CSV w momencie, kiedy dwa serwery próbują coś pisać w tym samym czasie, całość przestaje działać. no i stąd mam za sobą kilkanaście artów na każdy temat. powinienem być mądrzejszy a czuję się głupszy. sprawę złożyłem we wsparciu Dell bp problem jest na pewno gdzieś na linii komunikacji z voluminem na macierzy… a więc na pewno będzie jeszcze krótkie podsumowanie dot. [za pewne jakiegoś głupiego] błędu jaki można zrobić podczas konfiguracji CSV..

eN.

system backupu na maszynie wirtualnej

scenariusz: chcemy zwirtualizaować serwer backupów.

problem: podstawowy problem to obsługa sterowników/urządzeń. oczywiście w przypadq backupu dyskowego nie ma problemów – mamy do dyspozycji kilka opcji. albo po prostu podłączenie dysq pass-through albo iSCSI. w przypadku napędu taśmowego nie jest tak łatwo. VMWare częściowo wspiera takie rozwiązania, pozwalając na bezpośrednie przekierowanie obsługi urządzenia do systemu guesta – nie mam w tej kwestii doświadczeń, poczytałem sobie tylko, że nie wszystko jest obsługiwane, ale szczegółów nie znam,

co w przypadku Hyper-V? jest bardziej uniwersalny sposób – iSCSI. tak, tak. nie służy tylko do dysków – przecież to pełna obsługa SCSI przez TCP/IP a więc czemu by nie opublikować urządzenia taśmowego po iSCSI?

zredefiniowany problem: jak znaleźć odpowiedni iSCSI Target? jest wiele darmowych produktów – choćby Microsoftowy – ale większość pozwala wyłącznie na tworzenie targetów do dysków wirtualnych. bardziej zaawansowane pozwalały na publikację plików ISO jako targety, fizycznych dysków etc. jednak ze znalezieniem takiego, który wspiera napędy taśmowe – był problem.

sięgnąłem po StarWinda – ponieważ to AFAIK najbardziej zaawansowany software iSCSI Target. nie myliłem się – w pełni obsługuje takie rozwiązanie. problem polega na tym, że pojedyncza licencja kosztuje ok. $1.ooo. to trochę dużo – zwłaszcza, że nie mam zamiaru wykorzystywać go do celu tworzenia wielkiego SANa, a tylko opublikować jedno urządzenie. q mojej uciesze na stronie z darmowymi produktami jest “Tape Redirector” – uproszczony iSCSI Target, stworzony właśnie w tym celu, i to za free!  

instalacja: aby zassać program trzeba mieć konto StarWind – weryfikacja danych jest na tyle niemiła, że nie przyjmuje nawet maila z publicznej skrzynki – musi to być konto korporacyjne. aplikacja instaluje się łatwo i przyjemnie i jest tak intuicyjna, że nie ma co się rozwodzić. jedyny problem – interfejs z jakiś powodów przekłamuje numer portu, dodając 1 – standardowy port tego targetu to 33268 a wszędzie pokazuje 33269.

image

po odpaleniu inicjatora po stronie systemu guesta i skonfigurowaniu połączenia, w urządzeniach pięknie pokazuje się odpowiednie urządzenie.

niespodzianką był komunikat podczas próby instalacji sterowników urządzenia na guescie, iż nie są wspierane w środowisq wirtualnym. szczęśliwie była również opcja ‘extract’ i po ręcznej instalacji samego sterownika, całość zahulała jak należy (: zresztą BE ma swoje własne sterowniki i niechętnie współpracuje z tymi dostarczanymi przez producenta – a więc najlepiej nie instalować!

na próbę zainstalowałem Backup Exec 2o12 w wersji trial. przetestowałem backup, inwentaryzację, restore – wydje się, że wszystko działa jak należy. można wirtualizować!

wydajność: to oczywiste, ale na wszelki wypadek – aby uzyskać odpowiednią wydajność rozwiązania należy odpowiednio skonfigurować środowisko wirtualne. karta sieciowa dla powinna być dedykowana dla rozwiązania. bez żadnej szczególnej konfiguracji miałem 93MBps.

eN.

robocopy na w2k8 (R2)

podczas kopiowania danych przez WAN [inicjalizacja DFS] trwało to 6dni. policzyłem ilość danych i przepustowość łącza i – było to co prawda nieco za długo, ale dało się wytłumaczyć.

okazuje się jednak, że robocopy podobną wydajność co via WAN osiąga w LAN. próbowałem coś poszukać i w zasadzie nie znalazłem jednoznacznej odpowiedzi – niektórzy piszą, że działa normalnie ale dużo osób potwierdza mój problem. tutaj można nawet poczytać o dość wnikliwej analizie… bez rezultatów.

znalazłem zastępstwo, napisane przez ludka z eMeSów Joshua Hoffmana – RichCopy. jest to w zasadzie to, co robocopy z dwoma podstawowymi różnicami – działa dobrze i ma GUI. GUI trochę okaleczone – coś się sypie z wyświetlaniem listy plików ale to jest najważniejsze:

image

to w peaku. średnio – 2oMBps – może bez szaleństwa, ale przynajmniej akceptowalnie.

eN.

Diabeł leży w szczegółach

konsola Hyper-v. sprawa prosta – używam jej od… 2k7 czy 2k8, kiedy wyszła beta [a nawet wcześniej, bo miałem dostęp do wewnętrznych wersji]. maszyny wirtualne zmieniły moje życie zawodowe (; sądziłem, że nie ma przede mną tajemnic.

był jeden drobny szczegół, który mnie strasznie irytował – po usunięciu maszyn, te jakoś niedetrministycznie znikały, albo nie. restartowałem usługę – nadal czasem zostawały wiszące w konsoli. restartowałem serwer – i dopiero udawało mi się ich pozbyć. przekonany to że to ewidentny bug… aż w końcu przyszło mi do głowy przesunąć pasek widoq, w którym na końcu znajduje się kolumna ‘status’. i tam po usunięciu maszyn pięknie pokazuje się ‘destroying (x%)’ … po dojściu do 1oo% maszyna znika tak, jak powinna.

powinienem swoją firmę nazwać ‘w gorącej wodzie company’

eN.

uptime

uptime systemu można sprawdzić narzędziem systemowym ‘net’:

net statistics server

eN.