Skip to Content

IT nieuczesane.
category

Category: tips’n’tricks

inplace upgrage DPM 2010 -> 2012 SP1

przy próbie podniesienia wersji DPM 2o1o do 2o12 SP1 dostaję informację, iż nie jest wspierana i należy postawić DPM2o12 SP1 obok. taką migrację da się jednak zrobić, z krokiem pośrednim, którym jest DPM 2o12 bez SP1:

DPM2o1o -> DPM2o12 -> DPM2o12 SP1

czemu tak? ze względu na ograniczenia w ilości sprzętu, żeby nie przenosić potem konfiguracji i zachować całą historię backupów.

in-place upgrade nie jest specjalnie skomplikowany ale interfejs jest na tyle niejasny, że można się obawiać, co się tak na prawdę robi i jak to się zakończy. że się w ogóle da i żeby się nie bać przeczytałem sobie tutaj, jednak to koniec wartości tego wpisu. zabrakło kilq ważnych informacji.

  • za artykułem zrobiłem upgrade wszystkich komponentów DPM i agentów [w arcie mowa o starych poprawkach więc lepiej wyszukać najnowszych]. i tu się pojawia pierwszy problem – jeśli backup dotyczy również stacji mobilnych, to pewnie nie będzie ich aqrat w okolicy ergo nie zostaną podniesione wersje.
  • art sugeruje zrobienie backupu z SQL managera… ja bym raczej polecił /DPM/bin/DMPbackup.exe -db
  • instalator cały czas sugeruje, że to będzie nowa instalacja – w pewnym sensie będzie, ale należy nie zwracać na to uwagi – konfiguracja będzie przeniesiona. najdziwniejszy jest moment, w którym należy wybrać bazę danych [w moim przypadq baza była na tym samym kompie]. należy wybrać ‚use dedicated instance’.
  • kolejnym dziwnym krokiem jest hasło dla kont DPMowych – podać stare hasło czy jakieś nowe? odpowiedź: nie ma to znaczenia. zostanie zmienione.
  • każda faza upgrade’u wymaga restartu. co więcej – pomimo opcji ‚czek apdejts’ przy instalacji, nie warto tego od razu robić, ponieważ nawet po znalezieniu poprawek dla DPM ich instalacja nie powiedzie się. trzeba zrestartować, wyszukać, zainstalować, zrestartować, dalej wykonywać upgrade.
  • po instalacji DPM 2012 pozostaje działająca baza 2o1o oraz stary SQL. kiedy już się upewni, że wszystko działa – można je usunąć. o dziwo instalator nawet nie ustawia starej bazy w tryb ręczny, więc standardowo działać będą obie.
  • nie znalazłem czegoś takiego jak „SP1 dla DPM 2o12”. instalacja SP1 sprowadza się de facto do zrobienie in-place upgrade z DPM2o12 -> DPM2o12 SP1 /:
  • największym problemem przy każdym przejściu jest upgrade agentów na końcówkach. DPM sam z siebie nie ma możliwości automatycznej instalacji wersji. po prostu nie będzie robił backupów. jeśli chodzi o serwery – jest to dość proste, ponieważ z panelu ‚management’ można po prostu zaznaczyć wszystkie serwery i zrobić ‚update’. jeśli chodzi o laptopy – pozostaje przygotowanie paczki SCCM. serwery poza domeną – instalacja skryptowa.

sporo drobiazgów, a stresik jest.

eN.

ograniczenia Storage Spaces

artykuły dotyczące funkcjonalności są zazwyczaj mieszaniną zachwytu oraz wizji jak to teraz będzie cudownie. można się z nich dowiedzieć że coś jest i mniej-więcej o co cho, niemniej pod względem wartości – są tylko wstępem do rzeczy całej. dla tego najbardziej lubię arty krytykanckie [ale nie hejterskie!], ponieważ to w nich odnajduje się ostrzeżenia, ograniczenia, potencjalne problemy czy nieobsługiwane scenariusze. nawiązując zatem do trendu kilka rzeczy, na które należy zwrócić uwagę przy korzystaniu z SS.

limity i inne takie

  • SS pozwala na założenie volumenu logicznego o wartości przekraczającej dostępną wielkość fizyczną. [nie testowałem, ale ponoć] jest w bug w SS, w wyniq którego przy osiąganiu górnych limitów zużycie CPU peakuje a dostęp się zawiesza. generalnie uważam, że tworzenie dysq logicznego większego niż fizyczna przestrzeń w produkcji, to strzał w kolano. zawsze można potem łatwo zrobić ‚extend’ więc po co tak ryzykować? bo przecież…
  • …kiedy przestrzeń kończy się na dyskach fizycznych, volumen SS jest wyłączany.
  • po wybraniu trybu działania volumenu [single/mirror/parity] – ustawienia nie da się zmienić. w sumie to normalne dla każdego RAIDu… inne zasady dotyczące odzyskiwania/przenoszenia danych na fizycznych dyskach również obowiązują – nie da się wyjąć pojedynczego dysq i z niego coś odczytać. cały system działa na poziomie ‚block level’ i dane są rozdystrybuowane na wszystkie dyski.
  • jeśli wybierze się tryb ‚mirror’, a wielkości dysqw nie są takie same, to traci się całą pozostałą przestrzeń. mirror wymaga równych kawałków, a więc jeśli mamy pool z 3 dysqw – 5,1o i 2o GB, to fizycznie będzie to RAID na 3x5GB [no… trochę kłamię – szczegóły w FAQ]. dla użytkownika de facto będzie jeszcze mniej, bo odpadają parzystości. jedną z najistotniejszych rzeczy, o których należy pamiętać w pracy z SS jest właśnie fakt, że pod spodem działają normalne algorytmy wyliczania parzystości znane z RAID. w związq z tym ustalając maxymalną wielkość volumenu logicznego należy pamiętać o tym, że fizycznie to nie jest prosta suma dostępnych dysków fizycznych. IMHO to spory ból, że nie ma dostępnego jakiegoś kalqlatora podczas tworzenia volumenu [jest w w8 a nie ma w w12 /: ], który pokazuje max fizycznej dostępnej wielkości… szczerze powiedziawszy to nie wiem jak to w ogóle sprawdzić na serwerze O_o
  • minimalną wielkością dysq obsługiwaną przez SS jest 4GB
  • cluster nie obsługuje SS fizycznych RAIDów – pool musi być utworzony z fizycznie podłączonych dysków SAS, wyłącznie z fixed provisioning i tryb parzystości mirror lub simple [nie obsługuje parity]
  • braqje sensownego systemu notyfikacji…

kilka fajnych zmian pojawia się w wersji R2 – zwłaszcza Automatic Tiering. niemniej powyższe ograniczenia zostają.

ot taka ciekawostka na koniec – próba skopiowania pliq na volumen, który fizycznie już nie ma miejsca:

 

#REFS

eN.

the trust relationship between this workstation and the primary domain failed

dość standardowy komunikat – zwłaszcza na maszynach wirtualnych. snapshotowanie czy po prostu długo uśpione maszyny – w takich przypadkach hasła często desynchronizują się z a AD. do tej pory wykorzystywanym rozwiązaniem było wyrzucenie i dodanie maszyny z powrotem do domeny. ciekawostka, która mnie zawsze intrygowała to opcja ‚reset password’ na obiekcie komputera w ADUaC. opcja, która teoretycznie powinna wymusić synchronizację hasła. jakoś nigdy mi to nie zadziałało, choć są tacy, którzy twierdzą, że to się zdarza O_o?

tymczasem w powershell v3.o pojawiało się polecenie pozwalające na synchronizację hasła: Reset-ComputerMachinePassword.

zgodnie z zasadą ‚człowiek uczy się całe życie’ okazuje się, że taka funkcjonalność była dostępna od dawna… z poleceniem ‚netdom resetpwd‚ /:

temat trafił na mnie przypadkiem więc póki co nie testowałem żadnej z powyższych – dwa najważniejsze pytania to czy obie działają i czy konieczny jest restart? do sprawdzenia.

a to KB powinno zostać zmodyfikowane: KB162797

eN.

VMConnect

niedawno pisałem o tym, co można zrobić z hosta maszynie wirtualnej. przy okazji dalszych poszukiwań poczytałem sobie o VMConnect.exe – czyli jak w zasadzie działa zdalny pulpit to VM? najciekawsze jest,  że jest to zdalny pulpit – ale przecież można się połączyć zanim w ogóle wystartuje system. po zainstalowaniu RSAT dla Hv vmconnect znajduje się w „C:\Program Files\Hyper-V” i można pobawić się z linii poleceń. wymagane są dwa paramtry: nazwa hosta oraz maszyny wirtualnej, przy czym nazwa VM może być w postaci nazwy lub VMID. kilka ciekawostek o VMConnect i PS można przeczytać tutaj.

pozostaje jeszcze jedna ciekawostka – na Hyper-v Server nie ma GUI i nie ma VMConnect. ciekawszym scenariuszem jest zarządzanie z Linuxa… okazuje się, że na codeplexie jest alternatywa – FreeRDP.

eN.

 

Najlepszy skrót w Windows 8

Właśnie walczę drugi dzień z interfejsem W8 i naciskając po kolei wszystkie kombinacje Windows+… trafiłem na Windows+X
Może i lamerski wpis, ale mi ułatwił życie… może innym się przyda. Poniżej wynik tej kombinacji:

zarządzanie VM z hosta Hv

środowiskiem zarządza się z jakichś narzędzi infrastrukturalnych typu System Center – to oczywiście najlepszy sposób ale w pewnych warunkach mało przydatny lub niemożliwy. zarządzanie w tej warstwie jest niemal niemożliwe/totalnie skomplikowane w środowisq hostowanym – wiele domen nie powiązanych ze sobą, maszyny w podsieciach porozdzielanych VLANami, inne przestrzenie nazewnicze i tak dalej… efekt jest taki, że nawet jeśli dla narzędzi uwierzytelnienie w wielu domenach nie jest problemem, pozostaje bardzo skomplikowany schemat sieci i bezpieczeństwa – często niezależny od administratora i zarządzany przez klienta.

fajnie byłoby móc to wszystko ogarnąć z jednego, centralnego punktu – klastra Hyper-V, gdzie te wszystkie hosty sobie działają. skoro mam je w jednym miejscu logicznym się wydaje, aby z niego wykonywać pewne operacje maintenancowe czy administracyjne [oczywiście jeśli taka jest umowa z klientem]. na każdym guescie powinny być Integration Services, Hv komuniqje się z IS i … co możemy dzięki temu zrobić?

nic. w każdym razie bardzo niewiele. powód jest prosty – z założenia całość musi być bezpieczna a Hv ma być warstwą izolującą. nie bez powodu w Hv w konsoli zdalnej nie ma możliwości mountowania dysków czy nawet schowka. Hv ma pozostać możliwie najcieńszą i najbezpieczniejszą warstwą.

co zatem jednak można oraz jak sobie z takim środowiskiem poradzić?

root\virtualization

popatrzmy co nam daje WMI z poziomu hosta. skoro można coś zrobić z poziomu SCVMM to znaczy, że da się z konsoli w postaci skryptu. obszerna lista klas pozwala na pełną konfigurację i odpytanie maszyny – oczywiście od strony ‚wirtualnego hardwareu’ – czyli nadal nie to, co mnie w tej chwili interesuje, ponieważ chciałbym dostać się do OSa. i tutaj z ciekawszych klas można znaleźć:

  • MSVM_ComputerSystem – podstawowa klasa, pozwalająca dowiedzieć się czegoś o samym OS. informacje nie są jednak dostępne bezpośrednio z tego obiektu – trzeba informacje ‚wymienić’ między hostem a guestem, a robi się przy pomocy klasy…
  • Msvm_KvpExchangeComponent – to podstawowy komponent służący do wymiany informacji między hostem i guestem. dzięki kombinacji tych dwóch klas można m.in. sprawdzić: FQDN systemu, skonfigurowane adresy IP, wersję systemu i SP itp. to podstawowa klasa pozwalająca na dalszą automatyzację – nazwa maszyny wirtualnej jest zupełnie nie przydatna poza kontextem samego SCVMM/HvM. aby połączyć się czymś do VM trzeba będzie to zrobić ‚oficjalnie’ czyli via sieć. a do tego potrzebny jest IP, który można uzyskać właśnie z tej klasy.
  • kilka innych klas ‚Integration Services’ pozwalających na interakcję z wewnętrznym OSem – shutdown, timesync i VSS. szczególną uwagę zwraca – Msvm_GuestFileService i Msvm_CopyFileToGuestJob – dostępne od wersji Windows 8.1. zdaje się, że wraz z R2 będzie można w końcu normalnie kopiować pliki q: pojawia się też inne klasy sugerujące, iż ilość operacji jakie będzie można wykonać z hosta będzie się rozszerzać.

praktyka

jednym z przydatniejszych skryptów jaki często wykorzystuje jest Get-VMDetails wykorzystujący powyżej opisane klasy. importuję go jako funkcję dzięki temu na stacji zarządzającej jest zawsze dostępny:

funkcja wypluwa obiekt dzięki czemu łatwo jest potem dalej odpytywać o poszczególne atrybuty. przykładowe użycie:

środowisko

ostatecznie daje to tylko podstawowe informacje pozwalające na dalsze podłączanie się do maszyn. z samym system z tego poziomu nie zrobi się wiele więcej. nic zatem nie zastąpi odpowiednio przygotowanego środowiska tak, aby z centralnego punktu można było do maszyn się podłączyć.

można by poudostępniać sieci guest-VLAN dla hosta aby z jego poziomu dostawać się VMek. ale uważam, że to nie jest najlepszy sposób… izolację lepiej pozostawić. zależnie od polityki być może da się utworzyć stację, która będzie miała dostęp do wszystkich VLANów będące punktem styq. takim punktem mogą być  np.:

  • stacje monitorujące. np. nagios, open manage czy inne wynalazki. zależnie od polityki być może da się utworzyć stację, która będzie miała dostęp do wszystkich VLANów
  • system AV
  • system backupów
  • system dystrybucji poprawek

ponieważ klienci mogą nie wyrazić takiej zgody lub środowiska muszą być odizolowane w 1oo% z jakiś względów – pozostaje utworzenie kilq stacji w różnych sieciach, nawet jeśli wszystkie VM są na pojedynczym klastrze. fajnie byłoby mieć możliwość instalacji ‚superagenta’ – który pozwoliłby na pełny dostęp do VM z hosta po uwierzytelnieniu – IMHO jeśli ktoś ma uprawnienia/zalecenia do maintenancu maszyny, security nie powinno cierpieć szczególnie pozwalając na dodatkową metodę dostępu…

refs

suma wszystkich pestek

odwieczny problem – archiva maili. nieużywane, ale nie wolno tknąć, broń Cię Panie Wielki Kalqlatorze! bo może ktoś-kiedyś-coś-jakoś i co wtedy??

no więc serwery są zawalone pestkami. oczywiście nikt nie kontroluje co gdzie jest zbackupowane – leży więc po kilka kopii w różnych miejscach. ogrom. jak policzyć ile to zajmuje, żeby pokazać klientowi skalę problemu w cyferkach?

polecam w pierwszej kolejności sięgnąć po raporty FSRM. narzędzie jest od dawna w systemie i warto sobie o nim czasem przypomnieć. raporty/statystyki – trzeba to pamiętać – są łatwe w generowaniu, trochę trudniejsze w interpretacji.

jako przykład proponuję takie statsy:

  • „file by filegroup” i w opcjach zaawansowanych ‚Email Files’
  • oraz „least used” co by pokazać, że są to równocześnie nieużywane pliki.

nie daje to 1oo% aqracji ale na pewno są ‚na szybko’ i ‚wyglądają’ czyli dwie ważne rzeczy aby raport pokazać np. managementowi [czy adminom].

bardziej geekowe/administracyjne podejście to oczywiście powershell. najpierw łanlajner żeby zliczyć wielkość wszystkich plików typu XXX:

bardziej rozbudowane statsy pokazujące ilość plików, sumaryczną wielkość oraz ile z nich nie było używane przez ostatni rok:

Filter or Include?

i na koniec jeszcze ciekawostka. filtrować listę plików [i nie tylko] można na trzy sposoby: filter, include i late-filtering. bardziej po polsq: można zdefiniować filtr bezpośredni, można zdefiniować co ma zawierać lista [wbrew pozorom to co innego niż filtrowanie] i można zrobić listę a potem ją filtrować – której metody używać?

mi się nie chciało tego mierzyć q: ale komuś się chciało: http://tfl09.blogspot.com/2012/02/get-childitem-and-theinclude-and-filter.html . wynik: najszybszy jest filtr i to dość znacząco.

eN.

 

 

Hyper-v replication v1.o?

znaczenie wersji produktów/ficzerów w Microsoft:

  • v1.o – marketing czyli ‘mamy taki produkt, jesteśmy na rynq!’. w rzeczywistości nie zdatny do użytq – po prostu ładnie wygląda na reklamie i informuje, że eMeS wyraża zainteresowanie tym fragmentem rynku
  • v2.o – początek, czyli – ‘mamy taki a taki produkt, potrafi to i to, nie potrafi jeszcze tego i tego, ale SOHO/SMB ma już pewne funkcjonalności za free’. w rzeczywistości – hmmm.. faktycznie działa.
  • v3.o – wdrażamy w ENT. w rzeczywistości – można wdrażać w ENT, bo faktycznie już jest skalowalny i większość funkcji nie dość że jest, to działa dobrze.

w w12 jest PowerShell v3.o oraz Hyper-v v3.o – oba naprawdę fajne i dojrzałe. a do Hv dodano nową, świetną funkcjonalność – Hv Replication… i jest ona ewidentnie w v1.o.. no może v2.o. o samej konfiguracji już trochę pisałem. czas na opis samej funkcjonalności.

co można o niej powiedzieć – jest. pomysł zaiste przedni – na miarę VMWare SRM. do tego stopnia fajnie pomyślane, że pozwala na wykorzystanie w scenariuszu hostingowym, gdzie stacje nie są w tej samej domenie. zacnie. skoro backup na hostingu – to znaczy łącze jakieś-takie. w sensie, że nie LAN 1GB. i teraz dochodzimy do clue, czyli to, co w całej świetności zostało spartaczone do stopnia nieużywalności. a są to dwa podstawowe ‘mankamenty’ + jeszcze trochę:

  • miejsce docelowe replikacji ustawiane jest per cały cluster a nie per replikowana maszyna wirtualna.
  • replikacja wykonywana jest co 5 min. i nie inaczej.

konsekwencje:

– jeśli chce się zrobić replikę całego clustra Hv, to wszystkie maszyny pchane są na pojedynczy storage. nawet jeśli maszyny-źródła są rozlokowane na wielu CSV dla zwiększenia wydajności, to docelowo będą przechowywane na pojedynczym. czyli jeśli strzeli podstawowa serwerownia, to zapasowa i tak może nie unieść takiego obciążenia. w efekcie można stosować albo dla bardzo małych środowisk – jedna, dwie maszyny, albo dla bardzo bogatych – gdzie jest się w stanie dostarczyć infrastrukturę [macierz, switche, NIC etc] potrafiącą unieść ‘takie’ obciążenie na jedym CSV. ‘takie’ – testowaliśmy to myśląc o redundancji dla klienta, gdzie na źródlanym klastrze stoi ok. 4o produkcyjnych maszyn. jedynym ratunkiem jest dodatnie do naszego DRP kroku pod tytułem ‘storage migration’ – czyli w trakcie uruchamiania maszyn w naszej lokalizacji offsite, równolegle migrujemy je na inne/docelowe CSV. odpalenie 4o wirtualek na jednym CSV po prostu się nie uda.

– no i najgorsze z najgorszych – czyli te nieszczęsne 5 min. ktoś, kto to zaharcodował musiał być po ciężkiej nocy – nie wnikając czy chodzi o pracę, czy zabawę, ale na pewno miał zaćmienie. replikowane są oczywiście delty – super. Mierzyliśmy je i nawet przy produkcyjnej maszynie nie są to *standardowo* duże zmiany – ot, 2-4MB. nawet dla 4o maszyn, przy 1oMbps łączu – 5min [teoretycznie i przy pełnej przepustowości] powinno wystarczyć. ale często, zbyt często, na maszynach produkcyjnych pojawiają się zmiany dużo większe – transakcje sql przy operacjach maintenancowych, operacje na serwerze plików, gdzie wrzuca się duże wielości czy tymczasowe pliki zrzucane przez aplikacje. nieszczęsny DPM potrafi na chwilę wrzucić 5GB plik. nie ma niestety możliwości utworzenia wykluczenia dla katalogu czy typu pliq – co w jakiś sposób by zminimalizowało problem w związq z czym trochę matematyki:

  • załóżmy, że aplikacja utworzyła tempa 5GB. w sumie to bez większej różnicy czy jest to temp czy nie, ale ten scenariusz jest bardziej absurdalny i pokazuje nonsens w jaki się wpada, bo plik za chwilę znika. 5GB=4o96oMb. przy teoretycznym 1oo% dostępności, dajmy na to na 5oMb łączu, taki plik repliqje się 4o96o/5o/6o=13,65 minuty. tylko ta jedna zmiana i na naprawdę fajnym łączu i przy 1oo% dostępności – czyli warunki bardzo optymistyczne [czyt. mało realne]. dla 1oMb łącza ta liczba to już ponad 1h.
    co się dzieje w tym czasie? oczywiście uruchamiają się kolejne wyliczenia delty, ponieważ w ciągu tego czasu minęło kilka/wiele 5minutówek. w praktyce może się okazać, że za nim zreplikujemy naszą pierwszą zmianę (5GB) to przestanie ona być aktualna, ponieważ za chwile nadpisze ją kolejna zmiana. czyli w praktyce hv wysyła coś, co za chwilę zostanie nadpisane kolejną zmianą. zamiast się połapać i od razu wysłać ostatnią wersję naszych zmian. mały schemat:

image

jakieś tam obejście to zpauzowanie replikacji i uruchomienie z opcją resynchronizacji [koniecznie run as admin, inaczej krzyczy, że takiej maszyny nie ma]

  • Suspend-VMReplication –vmname <VNAME>
  • Resume-VMReplication –vmname <VNAME> -resynchronize

dzięki opcji resynchronize hv idzie po rozum do głowy i porównuje stan maszyny replikowanej na chwilę obecną z maszyną kopią, ergo tworzy nową deltę jedynie z ostatnimi zmianami. oszczędza nam to replikowanie ‘stanów pośrednich’. niestety resynchronizacja trochę zajmuje, dodatkowo została pisana z myślą o vhd/vhdx nie większych niż 500 GB. jeśli mamy takie trochę większe (np. dysk z danymi baz ponad 1TB), wtedy resynchronizacja zachowuje się mało wydajnie.

pojawia się wiele dodatkowych wątpliwości – bo trzeba nieźle się wstrzelić z czasem tegoż suspendu. w praktyce, wymagane jest małe dochodzenie, w jakich godzinach dochodzi do tworzenia ogromnych delt. osobiście pomogłem sobie małym skryptem, odpalanym ze schedulera co 5 minut

  • $time = "{0:yyyy-MM-dd_HH.mm.ss}" -f (get-date)
  • measure-vmreplication <VNAME> >> c:temp$time.txt

w prosty sposób mamy fajny obraz jak nasze delty rosną na przestrzeni czasu.

a rozwiązanie mogłoby być bardzo trywialne: zamiast nie-wiedzieć-skąd-wymuszone-5-min, wystarczyłoby, aby każda synchronizacja była wzbudzana – ot choćby przez scheduler. dzięki temu można byłoby w pełni kontrolować całą replikację, robić ją np. 2 razy dziennie, omijać okienka maintenancowe i backupowe i tak dalej…

z rzeczy na plus, które faktycznie działają i są miłym zaskoczeniem:

  • kompresja – pogłoski mówiły o superwydajnym rosyjskim algorytmie, ale nie wiadomo jak to jest w praktyce. wiadomo natomiast, że faktycznie działa. zależnie od pomyślności wiatrów skacze od 5o% do 7o%. przy wstępnych wyliczeniach można założyć, że mamy prędkość replikacji równą 1,5 przepustowości naszego łącza.
  • robienie pierwszej repliki na dysk USB – by zacząć replikację, musimy najpierw skopiować całą wirtualną maszynę do lokacji off-site. można to robić po WANie, ale można też tą pierwszą kopię zrobić na nośnik i przesłać go do serwerowni. kiedy nasza ‘initial replica’ zrobi się na dysk USB, po drugiej stronie powstaje replikowana maszyna z pustymi dyskami i snapshotem. Hv replikuje już zmiany do snapshota, mimo, że cała maszyna nie została jeszcze wgrana. replikacja działa, a kiedy kurier zawita do nas z nośnikiem, możemy w dowolnym momencie zaimportować sobie naszą pierwszą replikę.
  • wersjonowanie – czasami może się okazać,
    że replikujemy zmiany z już uszkodzonej wirtualnej maszyny. nasza replika jest odwzorowaniem oryginału 1:1, więc jeśli uszkodzi się OS w oryginalnej maszynie, to samo spotka naszą replikę. wersjonowanie umożliwia trzymanie kilku snapshotów replikowanej maszyny. gdyby okazało się, że coś nie hula, możemy cofnąć się o te kilka/kilkanaście godzin.

na chwilę obecną Hv replica jest i się uśmiecha, ale jest to jeszcze bardzo nieśmiały uśmiech. niemniej działa i przy świadomości ‘charakterystyki’ tego działania, można śmiało wdrożyć to dla klienta, który nie ma wyśrubowanych wymagań. w praktyce eMeS oferuje nam trzy opcje na stworzenia sobie taniego DRP:

  • Hv Replica
  • połączenie Hv Replica i Data Protection Manager Chain Backup – maszyny, których nie da się replikować Hv Replicą, replikujemy DPMem, który podobnie wylicza delty, ale w bardziej zarządzalny sposób.
  • DPM Chain Backp – wszystko replikowane za pomocą DPMa

każde podejście ma swoje zady i walety ale o tym… może kiedyś…

eN & Damian Skrzypiec

powershell – kiedy będzie standardem?

globalnie – nie prędko. z jednej strony możliwości PS się zwiększają z każdą wersją systemu, z drugiej strony – pozostają bez zmian dla wersji starych. potworny dualizm – jest wiele zapowiedzi, że będzie wycofane wsparcie konfiguracji TCP/IP z netsh, wmic – z drugiej strony po uruchomieniu w12 w wersji core nadal jesteśmy witani CMD – co jest zresztą dla mnie zupełnie niezrozumiałe /: . taki oto scenariusz, na który często trafiam:

trzeba coś zautomatyzować/zmienić u klienta. wersje serwerów – od W2k3R2 po w12. jakie mamy środowisko do tego?:

  • na w2k3R2 powershella nie ma w ogóle
  • na w2k8 jest, ale dla tej wersji była bardzo ograniczona liczna cmdletów
  • na w2k8R2 cmdletów jest więcej ale nadal są ograczniczone
  • na w12 jest ich na prawdę dużo, ale część operacji i tak trzeba wykonywać via stare commandlineowe toole.

i tak wybór jest pomiędzy:

  • zainstalować na wszystkich maszynach powershell. zadanie nietrywialne bo nie wszędzie jest v3, trzeba spełnic szereg wymagań, być może dograć jakieś moduły. sporo zachodu ale jeśli jest się adminem sieci to można się pobawić. jednak dla konsultanta – osoby z zewnątrz – jest to nieopłacalne.
  • być uniwersalnym – korzystać z VBS + CMD

finalnie – jeśli ma być uniwersalnie to trzeba sięgnąć do VBSa, co jest bolesne. po wygodzie i mozliwościach, jakie daje PS, grzebanie się w basicu jest ciężkim doznaniem.

niezrozumiałe dla mnie pozostaje:

  • czemu default shell w core to cmd
  • czemu PS nie jest poprawką obligatoryjną/sugerowaną dodatkową – w końcu to podstawowe środowisko zarządzania! na stronie opisującej WMF 3.o jest informacja iż nie jest kompatybilny z <tu całkiem spora lista>. niewątpliwie odpowiada to bezpośrednio na pytanie ‘czemu nie jest poprawką obligatoryjną’ ale rodzi pytanie – skąd te niekompatybilności?
  • czemu nie ma oficjalnych update’ów modułów do PS?

w efekcie, pomimo ostrego parcia w kierunq PS nie można mu zaufać – skrypty napisane na jeden system mogą nie działać na innym. brak jest spójności i jednego, porządnego środowiska.

Powershell basics mini-FAQ

  • jak sprawdzić wersję powershell:

$host.version

  • czy da się zupgradeować powershell do wersji 3 na wszystkich systemach?

po pierwsze to nie tylko PowerShell ale ‘Windows Management Framework’. na cały framework składa się kilka komponentów, wykorzystywanych na końcu łańcucha przez PS: BITS, WinRM i kilka innych komponentów, +oczywiście .NET framework. na staszych systemach trzeba więc zupdateować i pozostałe komponenty.

dla w2k8, w2k8R2 i w7 da się – można zaciągnąć z download center
dla wersji 2k3/XP SP3 jest tylko v2 i nowszej nie będzie

  • jak sprawdzić dostępne moduły

get-module –listAvailable

użytkownika: userdocumentswindowspowershellmodulesmymodule
systemowe: windowssystem32windowspowershellV1.0modulesmymodule

  • skąd wziąć moduły?

sporo jest na codeplexie. jedno z fajniejszych repozytoriów jest na technetowym wiki.

eN.

export/import maszyn wirtualnych hyper-v

takie proste… ale jak ja do czegoś siadam od razu staje się jakieś takie trudne… należę do grupy opisanej przez paradoks Wittgensteina na temat reguł ograniczonych. należę do tych, dla których najbardziej oczywiste rozwiązania wcale nie są najbardziej oczywiste…

jaki jest problem: nie ma SCVMM i trzeba sobie radzić narzedziami systemowymi. do wyboru mamy: Powershell [yeah!] i hyper-v manager. okazuje się, że export/import z HVmgmt działa zupełnie inaczej niż ten z PS. nie da się wexportować maszyny z GUI a zaimportować z PS – w każdym razie nie w prost. różnice:

GUI PS
EXPORT z GUI export-vm
generuje plik ‘config.xml’ znajdujący się w root katalogu exportu generuje plik <GUID>.xml znajdujący sie w katalogu Virtual Machines
plik xml zawiera tylko kilka podstawowych informacji. plik ma <1Kb plik xml zawiera pełny opis ma 33KB+
IMPORT z GUI import-vm
opcja ‘copy’ zostawia pliki w tym samym miejscu i generuje nowy ID opcja ‘-copy’ kopiuje pliki. standardowo zawsze zachowywany jest oryginalny GUID. aby wygenerować nowy trzeba dodać ‘-generateNewID’.
  nie da się użyć tych samych plików i zostawić GUID. operacja –register –generateNewId generuje błąd. nowy ID wymaga użycia opcji -copy
ładnie zakłda nowy katalog o nazwie maszyny wrzuca pliki do root katalogu maszyn wirtualnych

to tak w skrócie. ciekawostek jest jeszcze kilka – np. jak już się zaimportuje maszynę i przypadkiem zapomni się zmienić GUID to pupa. nie ma [bezpośredniej] mozliwości zmiany GUID – trzeba wywalić i zaimportować jeszcze raz. być może są jakies hardcore’owe możliwości z grzebaniem się w xml’kach ale to na pewno nie jest coś co zrobienia na szybko.

eMeSy chyba próbują zmusić ludzi do korzystania z SCVMM – nawet strona na technecie czy help dla poleceń systemowych hyper-v praktycznie nie istnieje. są parametry ale nie ma opisów jak je stosować i co robią ):

eN.