Monthly Archives: May 2012

Windows 8 Release Preview, Windows Server 2012 Release Candidate, Microsoft Hyper-V Server 2012 Release Candidate już dostępne do pobrania

Windows 8 Release Preview, Windows Server 2012 Release Candidate, Microsoft Hyper-V Server 2012 Release Candidate  już dostępne do pobrania na MSDN.

U mnie już się lecą na dysk 🙂

I już 8 RP jest dostępna publicznie – http://windows.microsoft.com/en-US/windows-8/iso, strona trochę tylko się muli teraz.

Uprawniania do zdalnego zarządzania Hyper-V pomiędzy dwoma serwerami Windows Server 8 Beta w Workgroupie

Ściągamy hvremote.wsf – http://archive.msdn.microsoft.com/HVRemote

Wszystkie uruchomienia hvremote.wsf robimy na podniesionych uprawnieniach w cmd. Na obu serwach uruchamiamy takie komendy:

cscript hvremote.wsf /mode:client /anondcom:grant /mmc:enable /firewallhypervclient:enable
cscript hvremote.wsf /mode:server /firewallhypervmgmt:enable /firewallwmimgmt:enable

Jeżeli używamy konta Administrator na obu serwerach to wykonujemy polecenie na nich i restarcik(potrzeby tylko wtedy gdy pierwszy raz wykonujemy to polecenie).

cscript hvremote.wsf /add:Administrator

I działa 🙂

Hyper-V Replica. Część 2

W poprzednim poście opisałem jak uruchomić Hyper-V Replica w workgrupie. – Hyper-V Replica w workgroupie. Część 1
Teraz czas na resztę czynności, które możemy zrealizować.

Monitorowanie

Sprawdzenia stanu replikacji możemy wykonać poprzez kliknięcie prawym przyciskiem na maszynę w konsoli Hyper-V i w menu przechodząc do Replication -> View replication Health…

Po uruchomieniu dostaniemy okno z najważniejszym informacjami na temat replikacji.

W powershellu tą samą informację można uzyskać poleceniem:

Get-VMReplication -VMName "Replica Test" | Format-List *

Efekt polecenia:

Informacje w Event Logu znajdziemy w Applications and Services Logs\Microsoft\Windows\Hyper-V-VMMS\Admin

Test przełączenia

Aby sprawdzić testowo przełączenie w menu maszyny wirtualnej w sekcji Replication znajduję się opcja Test Failover. Opcja ta jest dostępna tylko na serwerze repliki.

Pozwala ona sprawdzić replikę bez przerywania procesu replikacji. Po kliknięciu ukaże się nam okno wyboru punktu przywrócenia. Jeśli przy konfiguracji replikacji wybraliśmy opcję, aby serwer trzymał więcej niż jeden punkt przywracania to będziemy mogli wybrać też punkt inny niż ostatni.

Po kliknięciu Test Failover zostanie utworzona maszyna wirtualna z dyskiem różnicowym podpiętym do replikowanego dysku. Wszystkie karty sieciowe znajdujące się w maszynie będą odłączone od sieci. Maszyna będzie miała nazwę „Nazwa Oryginalnej Maszyny – Test”. Taką maszynę można uruchomić i przetestować. Kiedy zakończymy testy należy ją usunąć klikając na replikę i wybierając z menu Replication -> Stop Test Failover. Maszyna zostanie usunięta.

W następnej części opiszę jak przeprowadzić planowane i nieplanowane przełączenie repliki pomiędzy serwerami oraz jak dokonać przełączenia zwrotnego wraz z synchronizacją.

Hyper-V Replica w workgroupie. Część 1

Nowe Hyper-V v3 przynosi świetną funkcję Hyper-V Replica, która pozwoli na replikację maszyn wirtualnych na inny serwer bez potrzeby posiadania mechanizmów replikacji na poziomie macierzy. Funkcjonalność ta pozwoli nawet małym firmą wdrożyć prawie bez kosztowo Disaster Recovery(zakładam, że w następcy darmowego Hyper-V Server 2008R2 będzie dostępna Hyper-V Replica, w wersji Hyper-V Server 8 “Beta” znajduję się ona).

W skrócie replikacja działa na zasadzie wysyłania, co 5 minut paczki ze zmianami, jakie dotknęły replikowany dysk od ostatniej replikacji(replikacja asynchroniczna). Ważną informacją jest to, że Hyper-V Replica nie posiada automatycznego mechanizmu failover, czyli przełączenia maszyny.

W tym poście opisze jak skonfigurować Hyper-V Replica pomiędzy dwoma serwerami Windows Server 8 Datacenter Beta będącymi w workgrupie. Do autoryzacji pomiędzy serwerami wykorzystamy certyfikaty self-signed.
W labie, na którym zostało to przetestowane były dwa serwery:

  • HV1 – serwer podstawowym, z którego maszyna wirtualna będzie replikowana
  • HV2 – serwer drugi, który będzie odbierał repliki z serwera podstawowego HV1

Krokiem pierwszym jest instalacja Hyper-V na obu serwerach. Najprościej jest to zrobić poleceniem w powershellu na uprawnianiach Administratora:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -restart

Następnym korkiem jest wyłączenie sprawdzania CRL. Certyfikaty self-signed nie wspierają CRL, a takowe są sprawdzane przy użyciu autoryzacji nimi. Na szczęście wyłączmy sprawdzanie CRL tylko dla usługi replikacji Hyper-V. Z linii poleceń na uprawnianiach administratora wykonujemy polecenie:

Reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Teraz możemy przejść do przygotowania małego PKI na bazie certyfikatów self-signed. Do wygenerowania certyfikatów posłuż narzędzie makecert.exe dostępne w SDK do Windows 7. Aby nie pobierać całego SDK możecie je ściągnąć stąd – link.
Na początek na serwerze HV1 generujemy certyfikat, który posłuży za root naszego CA poleceniem:

makecert -pe -n "CN=PrimaryTestRootCA" -ss root -sr LocalMachine -sky signature -r "PrimaryTestRootCA.cer"

Posiadając już główny certyfikat, możemy wygenerować certyfikaty dla naszych obu serwerów. Polecenie dla HV1 to:

makecert -pe -n "CN=HV1" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 PrimaryTestCert.cer

Dla HV2 to(również wykonujemy to polecenie na HV1):

makecert -pe -n "CN=HV2" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "PrimaryTestRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 PrimaryTestCert.cer

Jak widać nazwę serwera ustawiamy w parametrze –n “CN={FQDN}”, gdzie FQDN to nazwa naszego serwera.
Eksportujemy certyfikat dla serwera HV2 oraz publiczny certyfikat naszego CA z magazynu certyfikatów na serwerze HV1 i importujemy je na HV2 do magazynu personalnego oraz certyfikat CA do Trusted Root Certification Authority.
Teraz na serwerze HV2 przystępujemy do uruchomienia usługi replikacji. W tym celu wchodzimy w ustawienia Hyper-V i ustawiamy jak na rysunku poniżej i klikamy OK. Pamiętamy o wybraniu w Select Certificate… naszego certyfikatu CA stworzonego wcześniej. Dodatkowo możemy zmienić ścieżkę domyślną w której są przetrzymywane zreplikowane pliki maszyn wirtualnych w ostatniej sekcji ustawień.

W ten prosty sposób serwer jest gotowy do odbierania replik.

Na serwerze HV1 tworzymy maszynę testową i klikamy na nią prawym przyciskiem myszy wybierając opcję Enable Replication…

Podajemy nazwę serwera, na który ma być replikowana maszyna i klikamy Next.

Podajemy port i wybieramy typ autoryzacji i klikamy Next. W przypadku naszego scenariusza to Certificate-based. Wybieramy w Select Certificate… nasz certyfikat CA stworzony wcześniej.

Wybieramy dyski maszyny wirtualnej do replikacji i klikamy Next.

Wybieramy ile punktów odtworzenia ma być trzymana na serwerze repliki. Wybieramy opcję Only the latest recovery points to save i klikamy Next. Działanie drugiej opcji postaram się opisać w następnych postach.

Wybieramy typ początkowej replikacji i klikamy Next.

Sprawdzamy podsumowanie i klikamy Finish.

W polu status w konsoli Hyper-V widzimy status mówiący o rozpoczęciu początkowej replikacji.

W następnych postach poruszę mechanizm przełączania, typy początkowej replikacji, “historię odtwarzania/replikacji”, monitorowanie replikacji.

VMM2012, Perimeter host i Error (2910)

Wczoraj wieczorem host którego mam w DMZecie przestał odpowiadać w VMM. Błąd który wystąpił to Error (2910):

Error (2910)
 VMM does not have appropriate permissions to access the resource C:\Windows\system32\vmms.exe on the DMZ server.
Access is denied (0x80070005)Recommended Action
 Ensure that Virtual Machine Manager has the appropriate rights to perform this action.

Problem jest z kontem serwisowym VMM na hoście który jest w workgroupie. Konto wygasa domyślnie po 45 dniach.

Odznaczamy User must change password at next logon i zaznaczamy Password never expires.

KB Microsoftu: http://support.microsoft.com/kb/971825

Porównanie wydajności magazynów danych dla Hyper-V w Windows 8 Server Beta

Dziś na portalu wss.pl ukazał się mój artykuł “Porównanie wydajności magazynów danych dla Hyper-V w Windows 8 Server Beta” – link.
Artykuł opisuje wydajność dostępnych dysków wirtualny oraz Pass-Trough w Windows Server 8 Beta(Windows Server 2012) dla roli Hyper-V. Zapraszam również do mojego postu na temat wydajności dysków wirtualnych w Hyper-V Client – VHD vs VHDX.

Zapraszam do lektury :).

Instalacja i konfiguracja Microsoft Deployment Toolkit 2012

Na blogu itgeeks.pl ukazał się mój artykuł – INSTALACJA I KONFIGURACJA MICROSOFT DEPLOYMENT TOOLKIT 2012. Artykuł ten jest przewodnikiem po instalacji i konfiguracji MDT 2012. W artykule są przedstawione następujące zagadnienia:

  • Podstawowa instalacja i konfiguracja MDT
  • Import sterowników do MDT
  • Import systemów operacyjnych i przykładowa instalacja systemu operacyjnego za pomocą MDT
  • Tworzenie wzorcowego obrazu systemu operacyjnego
  • Podstawowa instalacja i konfiguracja WDS
  • Automatyczne dodawanie obrazów startowych z MDT do WDS
  • Dodanie automatycznej instalacji aplikacji podczas instalacji systemu na przykładzie aplikacji 7-zip

Polecam ten artykuł wszystkim, którzy nie posiadają systemu do deploymentu stacji, a chcą sobie uprościć i zautomatyzować prace w tym zakresie.
Zapraszam do przeczytania, dania lajka na dole strony oraz komentowania.

PS. Na cały tekst wyszło 105 screenów 🙂

Stan danych po migracji P2V online przez VMM

Na IT Campie vGruru w Warszawie w trakcie sesji wywiązała się dyskusja na temat, w jakim stanie zostaną przechwycone dane z dysku w trakcie migracji na żywo do maszyny wirtualnej za pomocą Virtual Machine Managera. Nie wchodząc w to dokładnie jak VMM dokonuje migracji P2V przedstawię stan danych po migracji do maszyny wirtualnej za pomocą VMM2012. Maszyna, która została zwirtualizowana to Windows Server 2008R2 SP1.

Przypadek 1

Na maszynie przed migracją został uruchomiany skrypt powershellowy:

While($true)
{
Get-Date | Out-File C:\konwersja.txt –Append
Start-Sleep 2
}

Skrypt ten, co 2 sekundy zapisuję aktualną datę do pliku konwersja.txt
Poniżej log VMM z procesu migracji. Na czerwono zaznaczone Rozpoczęcie kopiowania dysku oraz wyłączenie maszyny fizycznej.

Na maszynie wirtualnej w pliku ostatni wpis jest o godzenie 21:22:23.

Na maszynie, która była źródłem ostatni wpis jest o 21:34:26.

Kopiowanie rozpoczęło się o 21:22:16. Jak widać dane zapisane po tej godzinie nie zostały przeniesione na maszynę wirtualną.

Przypadek 2

Na maszynie przed migracją został uruchomiany skrypt powershellowy:

 $file = New-Object System.IO.StreamWriter("C:\\keep_konwersja.txt", $true)
While($true)
{
$file.WriteLine((Get-Date))
$file.Flush()
Start-Sleep 2
}

Skrypt ten, co 2 sekundy zapisuję aktualną datę do pliku keep_konwersja.txt. W przeciwieństwie do skryptu z przypadku pierwszego proces ten blokuję plik.
Log VMM:

Na maszynie wirtualnej w pliku ostatni wpis jest o godzenie 22:06:46.

Na maszynie, która była źródłem ostatni wpis jest o 22:18:34.

Dane są w takim stanie jak w przypadku pierwszym.

Dlaczego tak się dzieje?

Odwołując się do dokumentacji:

VMM creates a copy of local NTFS volumes and data of VSS-aware applications. VMM leverages the Volume Shadow Copy Service (VSS) to ensure that data is backed up consistently while the server continues to service user requests. VMM uses this read-only snapshot to create a VHD.
 

Czyli aby zapewnić poprawną konsystencję danych jest wykorzystywany mechanizm VSS, który tworzy snapshot w trybie read-only na początku procesu kopiowania. Przez to dane, które zostaną zmodyfikowane po starcie kopiowania nie będą już dostępne na maszynie wirtualnej.
Podsumowując należy pamiętać, aby usługi, aplikację, które zapisują coś na dysku przenoszonej maszyny były wyłączone, aby nie stracić danych. Osobiście polecam używania opcji migracji offline do maszyn wirtualnych.
Pozdrowienia dla obecnych na IT Campie :).

Warto przeczytać – SC2012 SP1, konsystencja backupów

Ciekawa notka na blog Windows Server Blog o System Center 2012 SP1 i Windows Server 2012 – http://blogs.technet.com/b/windowsserver/archive/2012/05/03/building-cloud-infrastructure-with-windows-server-2012-and-system-center-2012-sp1.aspx

Dwuczęściowy wpis na temat konsystencji backupów w środowiskach wirtualnych od Altaro: http://www.altaro.com/blog/vss-crash-consistent-vs-application-consistent-vss-backups-post-1-of-2/ http://www.altaro.com/blog/vss-crash-consistent-vs-application-consistent-vss-backups-post-2-of-2/

 

WordPress SEO fine-tune by Meta SEO Pack from Poradnik Webmastera
Skip to toolbar