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.

Krótko o WMI Command-Line.

Windows Management Instrumentation Command-Line inaczej WMIC  zapewnia prosty konsolowy interfejs dla  Windows Management Instrumentation czyli po prostu WMI. Polecenie dostępne od Windows XP oprócz edycji Home i systemów z rodziny Windows Server 2003. Mimo małej popularności, WMIC jest narzędziem które daje nam sporo możliwości:

  • przeglądanie instancji klas WMI, używając aliasów które sprawiają obsługę WMI bardziej intuicyjną,
  • pracę z lokalnym, zdalnym lub wieloma komputerami za pomocą pojedynczej konsoli,
  • dostosowanie aliasów i formatów wejściowych w zależności do potrzeb,
  • tworzenie i wykonywanie skryptów opartych o WMIC.

Standardowo po wpisaniu /? otrzymamy treść pomocy. Warto zapoznać się z dostępnymi przełącznikami oraz aliasami. (1).

Praktycznym i przydatnym zastosowaniem polecenia może być zdalna deinstalacja oprogramowania która na przykład wcześniej nie została rozdystrybuowana poprzez polisy GPO. W tym celu możemy korzystać z przełączników /NODE oraz /USER przy połączeniu z zdalnym hostem (2),  bądź uruchomić konsole cmd z odpowiednimi poświadczeniami (3) i pomijać autoryzacje przy poleceniach.

Poleceniem >/NODE:10.100.100.220 PRODUCT GET NAME wyświetlimy zainstalowane oprogramowanie na stacji roboczej. Niestety lista ta nie będzie pełna, uwzględnia ona tylko oprogramowanie wykorzystujące narzędzie MsiExec, które zapewnia metody instalowania i modyfikowania programów oraz wykonywania operacji dotyczących Instalatora Windows z wiersza polecenia.

Używając klauzuli WHERE możemy „wybrać” aplikację, której chcemy się pozbyć, całe polecenie będzie wyglądać w ten sposób: >/NODE:10.100.100.220 PRODUCT WHERE=”7-Zip 9.20″ CALL UNINSTALL  Zostaniemy jeszcze poproszeni o potwierdzenie naszej decyzji (4).

Gdybyśmy chcieli jednocześnie zarządzać kilkoma hostami możemy zastosować polecenie >/FAILFAST:ON /NODE:10.100.100.220,10.100.100.221, 10.100.100.222 PRODUCT WHERE NAME=”7-ZIP 9.20″ CALL UNINSTALL /NOINTERACTIVE Zrzut, co prawda prezentuje zatrzymanie procesu na zdalnych hostach (5), ale zasada stosowania jest identyczna, przełącznik w poleceniu /NOINTERACTIVE zwalnia nas z obowiązku każdorazowego potwierdzania.

WMIC to na prawdę przydatne narzędzie i myślę że może niekiedy być alternatywą dla PowerShell.

Więcej informacji o WMIC: