Skip to Content

IT nieuczesane.
category

Category: tips’n’tricks

WMI vs CIM w praktyce

Windows_PowerShell_iconzakładam, że wszyscy wiedzą czym jest WMI i CIM – to jest abecadło dla każdego inżyniera systemowego. a [IMHO] podstawowa różnica w implementacji to możliwość tworzenia sesji CIM. czego dla WMI zrobić się nie dało. daje to niesamowite możliwości w przypadq hurtowych zapytań. podam trywialny przykład, gdzie zysk z zastosowania sesji nie jest wielki, ale osoby z wyobraźnią powinny poczuć moc, drzemiącą w takim zastosowaniu.

założeniem przykładu jest sztywna notacja nazewnicza dla hostów: ta sama nazwa ‚HOST’, zakończona inkrementowaną liczbą. ale równie dobrze można użyć ‚cat lista.txt | %‚ . niemniej chciałem przy okazji przemycić jeszcze jedną sztuczkę – w jaki sposób dopełniać liczby z dopełnieniem zerami.

cel: odpytanie 2o hostów o podstawowe informacje o BIOS – np. numer seryjny – oraz volumeny.

dla WMI

teraz zmierzmy czas dla wykonania tej sekwencji [ja robiłem dla siedmiu hostów]:

 

dla CIM

wydaje się być bardziej skomplikowane. odrobinę jest – trzeba najpierw założyć sesje, a następnie wykonać zapytanie wskazując na nie. sprawdźmy ekonomiczność zapytania [również dla 7 hostów]:

1331 vs 263  ms czyli 5cio krotnie szybciej [SIC!]. oczywiście można się przyczepić, że nie wliczyłem czasu utworzenia samej sesji ale…

wnioski

przy pojedynczym zapytaniu lub do niewielkiej ilości hostów – nie ma znaczenia czego użyjemy, bo czy co się wykona w 4oms czy w 1ooms jest dla człowieka pomijalne. jednak możliwość tworzenia sesji zwraca się przy seryjnych odpytaniach oraz jeśli do odpytania jest wiele hostów.

warto zauważyć, że przy dłuższej pracy zapis się upraszcza – ponieważ zamiast na iteracjach czy listingach, pracujemy na liście sesji.

eN.

 

 

Hyper-v replication – Critical

repairHyper-v Replica – problemy

Hv Replica jest dobrą ideą – jednak wykonanie szwanqje. wiele operacji, jakie jest wykonywane w ramach HvR jest zabójcze dla niego samego. do tego zachowanie jest bardzo nieprzejrzyste – do powodu błędów trzeba mocno dociekać, opisy są zwodnicze, braqje narzędzi do bezpośredniego debugowania. mówiąc w skrócie – mechanizm zaprojektowany jest jako samograj, a niestety jest na tyle niestabilny, że ciągle trzeba przy nim grzebać i jest to ciężka systemówka.

replikacja przerzuca pliki wektorów zmian [.hrl]. kiedy zostanie przerzucony plik, następuje… łączenie [merge] plików vhd. o ile w przypadq małej zmiany i małego pliq wszystko sobie działa dobrze, o tyle przewalenie kilq GB pliq do zmerdżowania z np. 1TB dyskiem, jest operacją zabijającą mechanizm – nie ma możliwości skończyć się ani w 5min [standardowy czas przerzucania zmian HvR] ani w 15min [max. jaki można ustawić] a zdarza się, że i godzina byłoby za mało, jeśli dyski są na prawdę duże. operacja jest wykonywana po stronie odbiorcy i jest to operacja bloqjąca – w czasie, kiedy jest wykonywana, z maszyną nie da się nic zrobić, a nadawca dostaje informację, że replikacji nie można wykonać.

dodatkowym problemem jest fakt, iż operacja łączenia dysków nie jest w żaden sposób pokazywana przez interfejs. błędy wyglądają następująco:

serwer wysyłający

log Hyper-V-VMMS/Admin, Event ID: 32552,

 

log Hyper-V-VMMS/Admin, Event ID: 32315,

 

serwer odbierający

log Hyper-V-VMMS/Admin, Event ID: 15268 [nie występuje zawsze]

log Hyper-V-VMMS/Storage, Event ID: 27000,

ponadto jest możliwość szybkiej weryfikacji przy pomocy PowerShell, weryfiqjąc status maszyny na serwerze odbierającym:

statusy wyraźnie pokazują – ‚InService’ oraz ‚ModifyingUpVirtualMachine’ – być może taki status jest również w innych scenariuszach, ale regularnie powtarzający się – może oznaczać tylko jedno. dyski się łączą.

dalsze konsekwencje

to za chwilę prowadzi to zmiany statusu repliki na ‚critical’ i ustawienia wymuszenia resynchronizacji w następnym cyklu [standardowo chyba raz dziennie o 18.oo – godzinę można sobie ustawić]. jeśli ręcznie wymusi się powtórną próbę replikacji po zakończeniu operacji ‚merge’, to wszystko powinno być ok i maszyna powinna się zacząć replikować. jeśli jednak zostawi się na automat, to do cyklu resync może minąć zbyt wiele czasu, a to będzie oznaczało faktyczny resync.

i tu dochodzimy do kolejnej maskrycznej operacji – resynchronizacja. jest to kolejna operacja bloqjąca, podczas trwania której sypią się backupy [lockowany jest VSS], a biorąc pod uwagą ile trwa czasu dla dużych dysqw, potrafi spowodować lawinowe błędy.

jak uniknąć części błędów

różnymi automatami – trzeba monitorować replikację i oskryptować całe rozwiązanie. można to zrobić w bardziej wyrafinowany sposób, można po prostu co jakiś czas wymuszać resync dla wszystkich maszyn.

jest też ciekawostka, która nigdzie nie jest opisana – w każdym razie nie trafiłem – podeślijcie linka, jeśli się mylę. póki co – wisienka na torcie, exclusive dla w-filesowiczów (;

kiedy poobserwuje się replikację, można zauważyć, że w pewnym momencie taski ‚zawisają’. jeśli z powodów opisanych powyżej wykonuje się kilka resynchronizacji, nagle okazuje się, że pozostałe maszyny co i rusz, również wchodzą w stan ‚critical’. ograniczeniem jest opcja definiująca ilość równoczesnych ‚storage migration’, ustawiana we właściwościach Hyper-V. standardowo są to dwie operacje. nawet jeśli maszyny rozłożone są na kilq węzłach klastra, może okazać się, że jakieś dwie długie synchronizacje lub resynchronizacje, będą blokować pozostałe maszyny. dla tego warto ten parametr zwiększyć. to znacząco obniża ilość problemów!

ponoć w Windows 1o Server, mechanizm replikacji ma być wymieniony – ale również nie mogę znaleźć artykułu potwierdzającego ten fakt /:

będę wdzięczny za linki (:

eN.

 

strach wyłączać – UEFI boot

repairdwa nowe serwery ProLiant DL360 Gen9… UEFI. po wyłączeniu serwerów nie wiedzieć czemu, rozwala rekord startowy. nie chce mi się opisywać hec jakie są z tymi złomami, ale przynajmniej ręczne rozwiązanie w przypadq wystąpienia problemu:

  1. jeśli jesteś szczęściarzem – płyta instalacyjna będzie widziała kontroler dysków. jednak w przypadq serwerów jest olbrzymie prawdopodobieństwo, że sterów do kontrolera RAID nie będzie. zatem pierwszy krok: przygotuj rozpakowane sterowniki dla kontrolera storage w wersji rozpakowanej – „.inf”.
  2. uruchom winPE – może być zwykła płyta instalacyjna Windows Server – uruchom konsolę [shift-F1o]
  3. sprawdź jakie są widoczne w systemie dyski. jeśli nie widać tego z systemem – załaduj sterowniki z pkt.1. dwie ciekawostki: instalacja z GUI nie powiedzie się [jeśli ktoś będzie próbował przez cześć recovery]. a druga to taka, że po załadowaniu z konsoli system krzyczy, że wymagany jest restart… ale powinno działać.
    • drvload <usb:>\<plik.inf>
  4. przypisz literę dla partycji EFI – łatwo ją rozpoznać, bo to mała partycja FAT32.
    • Diskpart
    • List vol [zapamiętaj oznaczenie dla OS]
    • Sel vol <EFI>
    • Assign letter=v:
    • Exit
  5. nadpisz sekwencję bootowania
    • cd /v v:\EFI\Microsoft\Boot
    • bootrec /fixboot
    • bcdboot <OS:>\windows /s v: /f ALL
  6. dla systemu z Hyper-v należy włączyć obsługę Hv. tu też ciekawostka – bez tej opcji usługi wstaną, ale przy próbie uruchomienia maszyny, będzie drzeć ryja. a wedle doq technetu to opcja służąca do debugowania. trochę zatem zaskaqjące to jest obligatoryjne a nie opcja /:

    hypervisorlaunchtype [ Off | Auto ]Controls the hypervisor launch options. If you are setting up a debugger to debug Hyper-V on a target computer, set this option to Auto on the target computer.

    • bcdedit /set {default} hypervisorlaunchtype Auto

po tej operacji system powinien prawidłowo się zbootować.

eN.

PS ISE – cudowny trick

windows-powershell-ise-iconostatnio odkryłem cudowny trick w PowerShell Integrated Scripting Environment:

przytrzymać shift+alt i teraz:

  • poruszając się strzałkami góra/dół oraz lewo/prawo można zaznaczyć blok
  • a teraz jeszcze lepszy: poruszając się strzałkami góra/dół rysuje się pionowa linia. i teraz kiedy zaczyna się pisać we wszystkich liniach pojawiają się znaki =^.^’=  tak samo można kasować.

przydatne w wielu scenariuszach – np. w hurtowym komentowaniu fragmentu kodu.

eN.

wymiana certyfikatu dla hyper-v replica

informacji o tym jak skonfigurować – od groma. ale jak wymienić certyfikat… no więc proszę:

po wymianie certyfikatu na serwerze źródłowym Hyper-v Replica trzeba jeszcze zmusić go do korzystania z niego. okazuje się, że używany cert jest właściwością replikowanej maszyny. oznacza to, że zmianę trzeba wprowadzić dla każdej VMki. można klikać – jak się ma dwie-trzy maszyny może i się da. ale jak się ma ich *dziesiąt to trochę mało fajne. szczęśliwie jest … PowerShell (: jakże by inaczej.

  • zaloguj się na którymś z Hv [np. enter-pssession]
  • skopiuj thumbprint certyfikatu

  •  potem można myszką skopiować ‚thumbprint’ tego, o który chodzi.
  • następnie trzeba wprowadzić zmianę dla maszyn. dla całego clustra sobie daruję, ale dla wszystkich VMek na pojedynczym hoście:

a potem można zrestartować usługę ‚vmms’ żeby odświeżyć replikację.

i już

 

 

VSS EventID 8194 na klastrze Hyper-v

po wstawieniu nowej macierzy EqualLogic i zaktualizowaniu HIT [Host Integration Tools] na węzłach, w eventlogu zaczęły się masowo pojawiać wpisy Event ID 8194 :

różne dziwne rozwiązania testowałem, przeszuqjąc Internet. większość sugestii dotyczyła dodania odpowiednich uprawnień na DCOM dla NT Authority\Network, odrejestrowanie hardwareowego requestora EQL, wyłączenie wykorzystania MPIO dla hardwareowych snapshotów i kilka innych pomysłów, większość artów wskazywała również na DPM…

finalnie trzeba było poskładać to do qpy, bo odpowiedź tkwiła w pomiędzy i kilka najważniejszych uwag, które mogą być przydatne przy takim debugowaniu:

  • to, co było najbardziej zwodnicze i spowodowało wydłużenie czasu debugowania, to założenie, że jak zrobię coś na jednym węźle i zadziała, to potem będę mógł wprowadzić na pozostałych węzłach. błąd logiczny w tym myśleniu polega na tym, że żądanie wysłane przez DPM do dowolnego węzła, generowało błędy na wszystkich. czyli nie widziałem poprawy po swoich zmianach, ponieważ błędy pojawiały się w wyniq akcji na innym węźle.
  • podstawą rozwiązania i zrozumienia całego problemu było znalezienie procesu, który wywołuje ten błąd. po sprawdzeniu szczegółów [details] dla tych wpisów w eventlogu, można znaleźć PID procesu, który go wywołuje. wskazało to na proces svhost, który zawierał kilka usług – m.in. usługę „Cryptographic Service”. trochę mnie to ździwiło, ale pozwoliło wyszukać właściwy wątek, w którym można przeczytać:

This problem appears only as part of a cluster ; This event is visible on nodes other than the one who initiated the call to VSS.

During a VSS call, the Cluster service sends requests to all nodes through the GUM (Global Update Manager). Because the „System Writer” is hosted by the encryption service (cryptographic service or cryptsvc) and that it is executed in a context „Network Service” instead of „System”, the return of COM calls a meeting Denied Access because different impersonnations on other cluster nodes

The problem will not be fixed as it has no functional involvement

dalej niestety jest info, że ten błąd nie wpływa na nic i nie będzie poprawiany. ciekawe, bo wpływa – bakcupy DPM nie bardzo chcą się robić…

  • ostatecznym rozwiązaniem było wykonanie *na wszystkich węzłach*:
    • zmuszenie DPM do korzystania z software providerów – tworzy się pusty klucz [nie wartość] na kliencie DPM [Software\Microsoft\Microsoft Data Protection Manager\Agent\UseSystemSoftwareProvider]
    • wyłączenie hardware providera EQL

eN.

Windows Updates z linii poleceń

jakoś ostatnio zauważam coraz więcej problemów z Windows Updates po stronie klienta – a to nic nie wyświetla, a to nie działa w ogóle ‚wejście’ do listy update’ów – jakby link był martwy… no i oczywiście dochodzą serwery bez GUI.

a przecież po zainstalowaniu wersji Core dostępna jest commandline’owa wersja instalacji poprawek. wystarczy więc zajrzeć gdzie to sobie leży … i:

warto zapamiętać: C:\Windows\System32\en-US\WUA_SearchDownloadInstall.vbs. w razie co, łatwo znaleźć:

nie wiem czemu to jest w vbs, tak samo jak nie rozumiem czemu serwery w2k12 bez GUI otwierają cmd, ale wewnątrz widać proste polecania, które można łatwo przepisać na jakiś ludzki język (:

eN.

Odzyskiwanie miejsca na DPM (nieoficjalne)

dpmniedawno na w-files pojawił się pierwszy wpis Ozz’a. dotyczył DPM. dziś premierę ma Tommy – temat również DPMowy (: zapraszam do lektury i komentarzy. dodam tylko, że opisywane metody nie są oficjalne i nie autor nie ręczy za ew. problemy.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.

 

Data Protection Manager zarządza dyskami w bardzo specyficzny sposób – kto nie zna DPM i otworzy diskmanagera, spadnie z krzesła. Dla każdego backupu tworzone są dwie partycje(dla repliki i recovery pointa), które potem są albo rozszerzane, albo spanowane. Widok przypomina trochę bardzo długi kod ISDN. Taka obsługa partycji oraz metoda oparta na bitmapie zmian, niesie ze sobą nieprzyjemne konsekwencje – w niektórych scenariuszach DPM zaczyna bardzo niewydajnie zarządzać przestrzenią. Są dwa podstawowe scenariusze, w których przestrzeń jest źle wykorzystywana, i różne metody naprawy.

Pierwszy scenariusz związany jest z przenoszeniem dużych plików baz danych – np. przeniesienie całego mailbox store na inny dysk. DPM może po takiej operacji wykonać kopię różnicową o wielkości dwukrotnie większej niż oryginał i dodatkowo zaalokować przestrzeń na kolejny. W przypadku o którym piszę, dla bazy 16oGB DPM zarezerwował 25oGB przestrzeni na pojedynczy recovery point. w tym scenariuszu jest tylko jedno skuteczne remedium– należy usunąć backup i utworzyć go od nowa. Należy oczywiście jakoś poradzić sobie z archiwami – w końcu nie zawsze można sobie pozwolić na takie ‘ot, wywalenie backupów’.

Jednak nawet podczas regularnej pracy operacyjnej DPM ma problemy z wydajnym zarządzaniem przestrzenią i wiele miejsca się marnuje – alokuje ilość przestrzeni daleko przekraczającą potrzeby. Można to zweryfikować otwierając zdefiniowany raport – Disk Utilization. Jesk kilka możliwości wygenerowania takiego raportu: per komputer, protection grupa oraz klient. Najbardziej obrazującym (i jednocześnie na pierwszy rzut oka najbardziej nieczytelnym) raportem jest per komputer:

dpm001

„Total Disk Capacity” to wielkość jaką mamy do dyspozycji na backupy. „Disk Allocated” oznacza jaka przestrzeń została zaalokowana na backupy. „Disk Used” określa ile nasze backupy naprawdę zajmują. Jak widać na załączonym obrazku, sumaryczna zaalokowana przestrzeń jest o kilka TB większa, niż ta potrzebna na same backupy (prawie 21TB zaalokowanej vs 13TB używanej).

Podstawowe pytanie, jakie przychodzi do głowy to jak tą przestrzeń uwolnić? Są dwie odpowiedzi.

Pierwsza to wykonać shrink w samym DPMie. Można to zrobić klikając na nasz backupowany serwer i z listy wybrać „Modify disk allocation”. Otworzy się okno, w którym możemy zwiększyć wielkości repliki i recovery pointa oraz zrobić shrink, ale TYLKO RECOVERY POINTA.

dpm002

Klikając na link „Shrink” uruchamia się zadanie wykonujące zmiejszenie wielkości wolumenu. Czasami da się zmniejszyć jego wielkość, a czasami nie. DPM zmniejsza wielkość automatycznie pozostawiając sobie „trochę” wolnej przestrzeni. W opisywanym przypadku udało się zmniejszyć wolumen o 30 GB.

dpm003

Super, nie? Sprawdźmy jeszcze czy da się ponownie zmniejszyć tą przestrzeń.

dpm004

Cóż, pozostało nam do przeklikania jeszcze 100 recovery pointów J (lub tyle ile mamy backupowanych serwerów). Biorac pod uwagę, że ta operacja zajmuje od kilku do kilkunastu minut mamy z głowy cały dzień o ile nie zna się powershella ale to już inna historia.

Ok to tę część mamy z głowy. Nie? A już wiem. Pewnie zastanawiacie się co z wielkością repliki? A co ma z nią być – z poziomu DPM nie da się zmniejszyć jej wielkości. I tu na tym jednym backupie tracimy 100 GB.

 

Co zatem zrobić z takimi 20 serwerami, które mają zaalokowane po +100GB per replika? Tu przychodzi nam z pomocą narzędzie zwane „Disk Manager” J. Otwórzmy go teraz i sprawdźmy ile mamy jeszcze wolnej przestrzeni na naszym wolumenie.

Zacznijmy jednak od „Recovery Point”. We wspomnianym narzędziu zrobię „shrinka”. Ze 188GB przestrzeni do zwolnienia jest 77 GB.

dpm005

Odzyskajmy jeszcze 30 GB.

Ok, to teraz czas na repliki. Nie da się zmniejszyć wilekości wolumenu repliki z poziomu DPM. Jedynym sposobem jest wykonanie tej operacji za pomocą „Disk Managera”. Prawy przycisk myszki na wolumenie i klikamy na shrink. Pamiętajmy o tym, aby nie zmniejszać przestrzeni o więcej, niż połowę za jednym razem. Co prawda nie jest to zabronione, ale z doświadczenia – gdy zmniejszamy za dużo, operacja się często nie udaje.

Jak skończymy, robimy „rescan” dysków w konsoli DPM (aby od razu wolne miejsce zostało dodane do niezaalokowanej przestrzeni).

Jest jeszcze kilka rzeczy, które mam nadzieję zostaną ulepszone takie jak shrinkowanie wielkosci repliki czy optymalizacja backupu na taśmy. Na chwilę obecną pozostaje nam czekać i mieć nadzieję, że te zmiany nastąpią.

Tommy.

 

jak sprawdzić przypisania wirtualnych kart sieciowych

klaster ma swoje wymagania co do sieci – potrzebuje kilku interfejsów do LM, HB, iSCSI, VLANy i tak dalej. jeśli tylu sieciówek nie ma, a zdarza się, że po prostu braqje portów na switchu (; i w kilq innych scenariuszach – czasem warto jest utworzyć wirtualne interfejsy. na stronach technetu można znaleźć ładną instrukcję więc nie będę kopiował. tutaj chciałem podać tylko mały trik. po założeniu owych wirtualnych interfejsów chciałoby się podejrzeć który jest dowiązany do którego wirtualnego switcha. trzeba przyznać, że konstrukcja wirtualnych switchy jest nieco zamota, a w połączeniu z VMM gdzie dochodzą jeszcze sieci logiczne staje się to na prawdę nieprzyjemne przy rozwiązywaniu problemów.

  • teoretycznie switche widać w hyper-v managerze… ale nie widać tak wirtualnych interfejsów.
  • interfejsy – czy to fizyczne czy wirtualne, widać w systemie – czy to z GUI ‚ncpa.cpl’ czy z powershell ‚get-netAdapter’. ale nawet wyświetlając wszystkie właściwości konkretnego interfejsu nie widać ich powiązań z VMSwitch
  • standardowo polecenie get-VMNetworkAdapter pokazuje powiązania z maszynami wirtualnymi……

..ale to już bardzo blisko rozwiązania. jest jeden magiczny przełącznik, który stanowi rozwiązanie:

po wykonaniu tej komendy pokazywane są nazwy switchy wirtualnych. teraz wystarczy sprawdzić który switch powiązany jest z która kartą fizyczną i voila:

idąc jeszcze krok dalej: nazwy kart z poziomu systemu znów są inne.. kolejna warstwa. więc jeszcze informacja jaka jest nazwa interfejsu z poziomu systemu:

eN.

Exchange online, powershell, kontakty i rezerwacja sal

to, co jest piękne w PS to fakt, że kiedy się go pozna, wszystko jedno do jakiego produktu się usiądzie – chwila moment i można szybko wyciągać statystyki, tworzyć obiekty, zestawienia i co kolwiek potrzeba. z jednego miejsca i bez różnych GUI.   <3 <3 ^^

przesiadka z Exchange onPremise na Exchange onLine jest bezbolesna – ot trochę mniej poleceń. wymagania? żadne. wystraczy po prostu zestawić sesję z serwerem i zaimportować sesję i stacja zmienia się w konsolę zarządzającą Exchange. po imporcie sesji dostępny jest moduł, którego nazwa jest generowana jakimś pseudolosowym algorytmem. dostępne polecenia można wylistować przy pomocy get-command:

do założenia kontaktu [bo przecież nie będę wyklikiwał z interfejsu, fuj] jest polecenie ‚new-mailContact’. okazuje się jednak, że ma ono bardzo ograniczoną listę parametrów, nie pozwalając ustalić takich szczegółów jak organizacja, stanowisko, telefon etc. i tu znów piękno PS – polecenie to nie tylko tworzy obiekt typu ‚mailContact’ ale również go zwraca. przypomnę, że PS zwraca obiekty przez referencję dzięki czemu wszystko można ‚pajpować’. ponieważ jest drugie polecenie – ‚set-contact’, które przyjmuje wszystkie wymagane parametry a jako wskazanie może użyć zarówno ID jak bezpośredniej referencji do obiektu ‚mailContact’, można utworzyć prostego jednolinijkowca, który zrobi co trzeba:

czyli gdyby chcieć ten prosty znaczek ‚|’ zapisać na polski byłoby to mniej-więcej – ‚a następnie przekarz go przez referencję do następnego polecenia’

i jeszcze „jedna rzecza” która się przydaje – rezerwowanie sal przez osoby z zewnątrz. standardowo takiej możliwości nie ma. w ex2k13 uzyskuje się to poprzez ‚calendar processing’:

to jeszcze nie wystarczy. jeszcze jedno wymaganie i jeden ‚trick’:

  • adres dokonujący rezerwacji musi istnieć jako kontakt na serwerze [poprzedni przykład]
  • a trick polega na tym, że nie zadziała dodanie w spotkaniu pokoju tak, jak to się zwyczajowo robi na homeserwerze. należy adres wpisać tak, jak zaprasza się zwykłą osobę.

eN.