Wskazówki po instalacji System Center 2016 Data Protection Manager

  1. instalacja poniższych poprawek do Windows Server 2016:
    1. Cumulative Update for Windows 10 Version 1607 and Windows Server 2016: October 27, 2016
      http://www.catalog.update.microsoft.com/Search.aspx?q=KB3197954
    2. Aktualizacja systemu Windows Server 2016 dla komputerów z procesorami x64 (KB3199986)
      https://www.catalog.update.microsoft.com/Search.aspx?q=kb3199986
  2. Może oczywiste ale po instalacji roli Hyper-V oraz modułu Hyper-V PowerShell wykonaj restart serwera i wznów instalacje DPM ponownie.
  3. Instalacja nie będzie kontynuowana jeśli usługi SQL Server Reporting Services i SQL Server Agent nie będą uruchomione z poświadczeniami użytkownika domenowego lub konta systemu lokalnego.
  4. Jeśli SQL Server znajduję się na zdalnej maszynie trzeba zadbać aby zainstalować na niej System Center DPM Support Files (DPM Remote SQL Prep). Natomiast jeśli bazy będziemy mieć lokalnie instalator będzie wymagać SQL Server Management Tools.
  5. Już po instalacji DPM pobierz poprawkę która pozwala wykonywać kopie zapasowe używając Modern DPM Storage (Modern Backup Storage):
    1. Update Rollup 1 for System Center 2016 Data Protection Manager
      https://support.microsoft.com/en-us/kb/3190600
  6. Jak coś jeszcze mi się przypomni lub wyjdzie po instalacji dopiszę…

Dodatkowo o Modern Backup Storage:

Add Storage to DPM 2016

Introducing DPM 2016 Modern Backup Storage

Announcing SC 2016 DPM with Reduced TCO of Backup

 

Błędy w LSCopy i LSRestore

Po konfiguracji Log Shipping na serwerze pomocniczym w jobach LSCopy i LSRestore otrzymywałem tego typu błędy:

Na pomoc przyszedł mi wpis z innego bloga, a konkretnie http://ms-dba.blogspot.com/2010/06/copy-and-restore-job-errors-with-log.html

Rozwiązanie, rozwiązaniem a co spowodowało problem? Mianowicie użycie klona serwera z domyślną instancją SQL Server gdzie nazwa serwera została międzyczasie zmieniona. Niestety SQL Server nie zmienił sobie automatycznie nazwy instancji. W takim przypadku trzeba wykonać to ręcznie uruchamiając następującą procedurę:

Wykonanie procedury kończymy restartem SQL Server, rezultat natomiast możemy sprawdzić poleceniem:

Więcej na temat zmiany nazwy serwera znajdziemy tutaj: http://msdn.microsoft.com/en-us/library/ms143799.aspx

Po tych zmianach i ponownej konfiguracji Log Shipping zadania utworzyły się poprawnie bez potrzeby ręcznej zmiany parametru -Server dla aplikacji sqllogship w zadaniach.

NIC i Hyper-V Failover Cluster

Jakiś czas temu szukałem dobrych praktyk związanych z ilością i konfiguracją interfejsów sieciowych przy wdrażaniu Hyper-V Failover Cluster. Wyszukane informację przedstawiam w formie 3 tabel.

Minimalna potrzeba interfejsów sieciowych dla Hyper-V Failover Cluster:

Storage (iSCSI) Virtual Machine Managment Cluster Heartbeat / Cluster Shared Volumes Live Migration Razem
1 1 1 1 1 5

Ilość interfejsów dla zapewnienia wysokiej dostępności i wydajności:

Storage (iSCSI) Virtual Machine Zarządzanie Cluster Heartbeat Cluster Shared Volumes Live Migration Razem
min 2 min 2 1 1 1 1 8

Prawdę mówiąc do tej kwestii  mam wątpliwości, ale liczę, że ewentualnie poddacie moje wnioski weryfikacji, zachęcam do pisania w komentarzach.

Zalecane ustawienia interfejsów:

Ustawienia Management Heartbeat Cluster Shared Volumes Live Migration VM Storage (iSCSI)
Client for Microsoft Networks Y N Y Y N N
File and Printer Sharing Y N Y Y N N
Microsoft Virtual Network Switch Protocol N N N N Y N
Internet Protocol Version 6 O O O O N O
Internet Protocol Version 4 Y Y Y Y N Y
Link-Layer Topology Discovery Mapper I/O Driver Y N N Y N N
Link-Layer Topology Discovery Responder Y N N Y N N
Statyczna adresacja IP Y Y Y Y Y
Wyłącz system NetBIOS przez TCP/IP N Y Y Y N Y
Brama domyślna Y N N N N N
DNS Y N N N N N
Zarejestruj adresy tego połączenia w DNS Y N N N N N
Wykorzystanie MPIO Y
Wykorzystanie NIC Teaming Y Y Y Y Y N
W Failover Cluster Manager
Do not allow cluster network communication on this network.
N N N N Y Y

 

W Failover Cluster Manager
Allow cluster network communication on this network.
Y Y Y Y N N
W Failover Cluster Manager
Allow Clients Connect through this network.
N N N N N N

 

Zdarzenia WMI i Windows PowerShell

W WMI istnieje takie zagadnienie jak kwerendy zdarzeń WMI. Istnieją trzy rodzaje kwerend zdarzeń WMI:

  • zdarzenia wewnętrzne,
  • zewnętrzne zdarzenia
  • zdarzenia timera.

W skrócie postaram się przedstawić pierwszy z nich, czyli wewnętrzne zdarzenia które używane są do monitorowania zasobów reprezentowanych przez klasy w repozytorium CIM. Innym słowy, wewnętrzne zdarzenia występują w odpowiedzi na zmiany w standardowym modelu danych WMI. . WMI tworzy zdarzenia wewnętrzne dla obiektów przechowywanych w repozytorium WMI.

Najbardziej przydatne klasy wewnętrznych zdarzeń WMI:

__InstanceCreationEvent

Ta klasę używamy, gdy chcemy, aby otrzymać powiadomienie o tworzeniu instancji Na przykład, możemy użyć tej klasy gdy chcemy otrzymać powiadomienie za każdym razem o zdarzeniu utworzenia nowego procesu.

__InstanceDeletionEvent

Tą klasę używamy gdy chcemy otrzymać powiadomienie o usunięciu instancji. Analogicznie jak powyżej z tą różnicą że otrzymamy powiadomienie o każdym zakończonym procesie.

__InstanceModificationEvent

Ta klasa natomiast jest używana gdy chcemy monitorować zmiany na istniejącej instancji lub zasobie. Na przykład możemy użyć tej klasy gdy chcemy przekazać powiadomienie o zdarzeniu gdy wykorzystanie procesora wykracza poza próg określony przez zapytanie.

Ogólna składnia WQL dla wewnętrznych zdarzeń WMI:

W powyższej składni większość słów kluczowych jest znanych z SQL, oprócz słowa WITHIN które jest używane do określenia interwału sondowania dla zdarzeń. Można powiedzieć również że jest to  maksymalny odstęp w czasie jaki musi minąć zanim powiadomienie o zdarzeniu zostanie dostarczone.

Wartość określona jest jako liczba  w sekundach i jest liczbą zmienną przecinkową. Więc możemy określić wartości mniejszą niż jedna sekunda, trzeba pamiętać jednak że mniejszy niż jedna sekunda np. 0.2 może być przyczyną spowolnienia systemu z względu na intensywne wykorzystywanie zasobów przez zapytanie.

Rejestrując dwa zdarzenia możemy w prosty sposób monitorować podłączanie i odłączanie  urządzeń przenośnych, tworząc prosty dziennik zdarzeń w pliku tekstowym.

Na końcu warto wspomnieć o poleceniu Get-Job  którym możemy pobrać wszystkie zarejestrowane zdarzenia WMI, natomiast poleceniem Remove-Job możemy je usunąć.

Chwilę o DHCP Server

Wpis zacznę od idealnie pasującego powiedzenia ? ?Diabeł tkwi w szczegółach?. Tym szczegółem okazała się zatrzymana usługa DHCP Server, dla sieci potrafi być dokuczliwa tym bardziej, że niedostępność jest dość mocno zauważalna dla userów. Taką sytuację przerabiałem na dniach, pierwsze, co przychodzi do głowy to rzucenie okiem na eventvwr.msc gdzie ukazują się nam błędy tego typu:

Zdarzenia 1003 jak i 1008 są komunikatami dość nieprecyzyjnymi, natomiast wpis o identyfikatorze 1061 jednoznacznie wskazuje na przyczynę problemów z podniesieniem usługi. Faktycznie określona ścieżka była w danym momencie niedostępna i jedynym rozwiązaniem było zmiana ścieżki. W takiej sytuacji musimy wspomóc się rejestrem.

Dostęp do parametru, w którym możemy zmienić ścieżkę znajduje się:

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/DHCPServer/BackupDatabasePath

Po modyfikacji na „dostępną”  ścieżkę nasza usługa powinna bezproblemowo się uruchomić i u mnie tak było. Dodam, że poprzez rejestr mamy dostęp do parametrów naszego serwera DHCP, do których przystawka nie daje nam dostępu np. zmieniając parametr IntervalBackup jesteśmy wstanie zmienić interwał wykonywania kopii bazy danych naszego serwera DHCP.

Tak nie frasobliwy incydent jest idealnym pretekstem do zapoznania się z wysoką dostępnością usługi DHCP które daje nam Windows Server 2012. Do wyboru mamy 3 możliwości:

    • podział zakresów ? jest to metoda polegająca na podziale konkretnych zakresów pomiędzy dwa serwery DHCP, gdzie serwer główny zawiera 70% wszystkich adresów, a drugi 30%. Rozwiązanie to jest proponowane dla mniejszych środowisk, ponieważ w chwili, kiedy serwer główny jest niedostępny, a kolejni klienci próbują pobrać adresację, może okazać się, że dostępna pula adresów na drugim serwerze będzie niewystarczająca. Dodatkowy problem stanowi brak ciągłości w utrzymaniu adresacji,
    • DHCP over Failover Cluster ? funkcjonalność ta została wprowadzona we wcześniejszych wersjach systemu Windows Server. Aby z niej skorzystać, musimy posiadać środowisko domenowe, dwa serwery połączone w jeden klaster oraz udostępnioną przestrzeń dyskową, na której znajduje się konfiguracja DHCP. Metoda ta działa w trybie aktywno-pasywnym, gdzie jeden serwer oczekuje na awarię drugiego. Jeśli wymagane jest, aby węzły klastra były podzielone na dwie, rozdzielone geograficznie, lokalizacje (tzw. geocluster), można czasem natrafić na problemy konfiguracyjne. W takim wypadku należy zapewnić replikację udziału dyskowego pomiędzy lokalizacjami. Zaleca się także, aby serwery należały do tej samej podsieci ? przyśpiesza to proces przełączenia usługi na drugi węzeł po awarii pierwszego,
    • DHCP Failover ? funkcjonalność ta umożliwia zaimplementowanie wysokiej dostępności usługi DHCP w łatwiejszy i bardziej efektywny sposób, w porównaniu do wyżej wymienionych metod. Dzięki niej, klienci wysyłający zapytania do serwera mogą stale otrzymywać adresację i niezbędne do pracy opcje z tych samych zakresów, a przy tym ciągłość adresacji jest utrzymana. Do implementacji wymagane są dwa serwery wraz z oprogramowaniem Windows Server 2012 w wersji standard lub datacenter. Rozwiązanie to nie wymaga użycia kosztownych systemów dyskowych, czy też dodatkowego oprogramowania. Nie są również wymagane wydzielone podsieci dla komunikacji klastrowej. Całość możemy skonfigurować w dwóch trybach: Hot Standby, gdzie jeden serwer jest aktywny i komunikuje się z klientami, a drugi jest pasywny i oczekuje na awarię pierwszego. Drugi tryb Load Sharing  pozwala na równomierne obciążenie obu serwerów zapytaniami od klientów. Rozwiązanie DHCP Failover jest szczególnie ciekawe, jeśli chcemy umieścić dwie maszyny w odrębnych lokalizacjach. Dotychczas, najlepszym rozwiązaniem dla dużej firmy było uruchomienie skomplikowanej i kosztownej konfiguracji geoklastra, obecnie, praktycznie każdy administrator jest w stanie zapewnić obsługiwanej przez siebie firmie wysoką dostępność bez dodatkowych kosztów.

Cytat pozwoliłem zaczerpnąć z TechNet autora Witold Miszkiewicz, gdzie opisane jest konfiguracja  krok po kroku – http://technet.microsoft.com/pl-pl/library/jj906439.aspx

DHCP Failover jest optymalnym rozwiązaniem, tylko na tyle ile sprawdziłem jedynym mankamentem tego rozwiązania chyba, że się mylę  (w takiej sytuacji wyprowadzicie mnie z błędu) jest potrzeba ręcznego wymuszania replikacji zakresu, dzięki której replikują się rezerwacje. Rozwiązania są dwa, pamiętanie o wymuszaniu replikacji po dodaniu kolejnej rezerwacji bądź skorzystanie z polecenia PowerShell.

Inovke-DhcpServerv4FailoverReplication -Scope [nasz zakres] -Force

W połączeniu z harmonogramem rozwiązuje to problem.