Kontynuujemy zanurzenie się w fascynującym świecie zgadywania… rozwiązywania problemów za pomocą dzienników. W zgodziliśmy się co do znaczenia podstawowych terminów i jednym okiem przyjrzeliśmy się ogólnej strukturze Veeam jako pojedynczej aplikacji. Zadaniem tego jest ustalenie, w jaki sposób tworzone są pliki dziennika, jakie informacje są w nich wyświetlane i dlaczego wyglądają tak, jak wyglądają.
Jak myślisz, co to są te „logi”? Według większości logom dowolnej aplikacji należy przypisać rolę swego rodzaju wszechmocnego bytu, który przez większość czasu wegetuje gdzieś na podwórku, ale w odpowiednim momencie pojawia się znikąd w lśniącej zbroi i ratuje wszystkich. Oznacza to, że powinny zawierać wszystko, od najmniejszych błędów w każdym komponencie po poszczególne transakcje bazy danych. I tak, że po błędzie od razu napisano, jak inaczej to naprawić. A wszystko to powinno zmieścić się w kilku megabajtach, nie więcej. To tylko tekst! Pliki tekstowe nie mogą zajmować dziesiątek gigabajtów, gdzieś to słyszałem!
Więc logi
W prawdziwym świecie logi to po prostu archiwum informacji diagnostycznych. A co tam przechowywać, skąd wziąć informacje do przechowywania i jak szczegółowe powinny być, decydują sami programiści. Ktoś podąża ścieżką minimalizmu, prowadząc zapisy poziomu ON/OFF, a ktoś pilnie grabi wszystko, co się da. Chociaż jest też opcja pośrednia z możliwością wyboru tzw. Logging Level, kiedy sam wskażesz, jak szczegółowe informacje chcesz przechowywać i ile masz dodatkowego miejsca na dysku =) Swoją drogą VBR ma sześć takich poziomów. I uwierz mi, nie chcesz zobaczyć, co się stanie z najbardziej szczegółowym logowaniem z wolnym miejscem na dysku.
Cienki. Z grubsza rozumieliśmy, co chcemy zapisać, ale pojawia się uzasadnione pytanie: skąd wziąć te informacje? Oczywiście uczestniczymy w zdarzeniach związanych z logowaniem się przez nasze wewnętrzne procesy. Ale co zrobić, gdy dochodzi do interakcji ze środowiskiem zewnętrznym? Aby nie wpaść w piekło pełne kul i rowerów, firma Veeam raczej nie wymyśla wynalazków, które już zostały wynalezione. Zawsze, gdy istnieje gotowe API, wbudowana funkcja, biblioteka itp., będziemy preferować gotowe opcje przed przystąpieniem do ogrodzenia naszych urządzeń. Chociaż to drugie też wystarczy. Dlatego podczas analizowania dzienników ważne jest, aby zrozumieć, że lwia część błędów przypada na komunikaty z interfejsów API innych firm, wywołania systemowe i inne biblioteki. W tym przypadku rola VBR sprowadza się do przekazania tych błędów do plików dziennika „tak jak jest”. A głównym zadaniem użytkownika jest nauczenie się rozumienia, która linia jest od kogo i za co ten „kto” jest odpowiedzialny. Więc jeśli kod błędu z dziennika VBR prowadzi do strony MSDN, to jest w porządku i poprawne.
Jak ustaliliśmy wcześniej: Veeam to tzw. aplikacja oparta na SQL. Oznacza to, że wszystkie ustawienia, wszystkie informacje i ogólnie wszystko, co jest potrzebne tylko do normalnego funkcjonowania - wszystko jest przechowywane w jego bazie danych. Stąd prosta prawda: to, czego nie ma w logach, najprawdopodobniej jest w bazie danych. Ale to też nie jest złoty środek: niektórych rzeczy nie ma w lokalnych dziennikach komponentów Veeam ani w jego bazie danych. Dlatego musisz nauczyć się, jak badać dzienniki hosta, dzienniki komputera lokalnego i dzienniki wszystkiego, co jest zaangażowane w proces tworzenia kopii zapasowych i przywracania. Zdarza się też, że potrzebne informacje nie są nigdzie dostępne. Oto jest sposób.
Niektóre przykłady takich interfejsów API
Ta lista nie ma na celu być wyjątkowo kompletna, więc nie ma potrzeby szukać w niej ostatecznej prawdy. Jego celem jest jedynie pokazanie najpopularniejszych interfejsów API i technologii innych firm używanych w naszych produktach.
Zacznijmy od VMware.
Pierwszy na liście będzie API vSphere. Używany do uwierzytelniania, odczytywania hierarchii, tworzenia i usuwania migawek, żądania informacji o maszynach i wielu (bardzo) innych. Funkcjonalność rozwiązania jest bardzo szeroka, dlatego do wersji mogę polecić VMware vSphere API Reference и . W przypadku bardziej aktualnych wersji wszystko jest po prostu wyszukiwane w Google.
API VIX. Czarna magia hypervisora, dla której istnieje osobna . VMware API do pracy z plikami na hoście bez łączenia się z nimi przez sieć. Wariant ostateczności, gdy trzeba umieścić plik w maszynie, do której nie ma lepszego kanału komunikacji. To ból i cierpienie, jeśli plik jest duży, a host jest załadowany. Ale tutaj sprawdza się zasada, że nawet 56,6 Kb/s jest lepsze niż 0 Kb/s. W Hyper-V to coś nazywa się PowerShell Direct. Ale to było tylko wcześniej
Interfejs API usług internetowych vSpehere Począwszy od vSphere 6.0 (w przybliżeniu od momentu wprowadzenia tego API w wersji 5.5) jest używany do pracy z maszynami-gościami i prawie wszędzie wyparł VIX. W rzeczywistości jest to kolejny interfejs API do zarządzania vSphere. Zainteresowanym polecam naukę podręcznik.
WDDK (zestaw deweloperski dysku wirtualnego). Biblioteka, która została częściowo omówiona w tym . Służy do odczytu dysków wirtualnych. Kiedyś był częścią VIX, ale z czasem został przeniesiony do osobnego produktu. Ale jako spadkobierca używa tych samych kodów błędów co VIX. Ale z jakiegoś powodu w samym SDK nie ma opisu tych błędów. Dlatego empirycznie stwierdzono, że błędy VDDK z innymi kodami są tylko translacją z kodu binarnego na dziesiętny. Składa się z dwóch części – pierwsza połowa to nieudokumentowane informacje o kontekście, a druga część to tradycyjne błędy VIX/VDDK. Na przykład, jeśli widzimy:
VDDK error: 21036749815809.Unknown error
Następnie odważnie konwertujemy to na szesnastkowy i otrzymujemy 132200000001. Po prostu odrzucamy nieinformacyjny początek 132200, a reszta będzie naszym kodem błędu (VDDK 1: Nieznany błąd). O najczęstszych błędach VDDK niedawno pojawił się osobny artykuł .
Teraz spójrzmy na Okna.
Tutaj wszystko, co jest dla nas najbardziej potrzebne i ważne, znajduje się w standardzie Event Viewer. Ale jest jeden haczyk: zgodnie z długą tradycją Windows nie rejestruje pełnego tekstu błędu, a jedynie jego numer. Na przykład błąd 5 to „Odmowa dostępu”, a 1722 to „Serwer RPC jest niedostępny”, a 10060 to „Przekroczono limit czasu połączenia”. Oczywiście świetnie, jeśli pamiętasz te najsłynniejsze, ale co z tymi, których do tej pory nie widziano?
Aby życie wcale nie wyglądało jak miód, błędy są również przechowywane w postaci szesnastkowej, z prefiksem 0x8007. Na przykład 0x8007000e to w rzeczywistości 14, brak pamięci. Dlaczego i dla kogo to zrobiono, jest tajemnicą owianą ciemnością. Jednak pełną listę błędów można pobrać bezpłatnie i bez SMS-ów z .
Nawiasem mówiąc, czasami istnieją inne prefiksy, nie tylko 0x8007. W tak smutnej sytuacji, aby zrozumieć HRESULT („uchwyt wyniku”), trzeba jeszcze bardziej zagłębić się w dla programistów. W zwykłym życiu nie radzę ci tego robić, ale jeśli nagle przycisnąłeś się do ściany lub jesteś po prostu ciekawy, teraz wiesz, co robić.
Ale towarzysze z Microsoftu trochę się nad nami zlitowali i pokazali światu użyteczność . To mały kawałek szczęścia konsoli, który może tłumaczyć kody błędów na ludzi bez korzystania z Google. To działa tak.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Powstaje uzasadnione pytanie: dlaczego nie zapisujemy od razu deszyfrowania w dziennikach, ale zostawiamy te tajemnicze kody? Odpowiedź znajduje się w aplikacjach innych firm. Gdy sam wywołasz jakieś wywołanie WinAPI, nietrudno jest rozszyfrować jego odpowiedź, ponieważ jest nawet do tego specjalne wywołanie WinAPI. Ale jak już wspomniano, wszystko, co przychodzi do nas tylko w odpowiedziach, trafia do naszych logów. I tutaj, aby go odszyfrować, trzeba by stale monitorować ten strumień świadomości, wyciągać z niego fragmenty z błędami Windowsa, odszyfrowywać je i wklejać z powrotem. Bądźmy szczerzy, nie jest to najbardziej ekscytująca czynność.
Interfejs API zarządzania plikami systemu Windows używany w każdy możliwy sposób podczas pracy z plikami. Tworzenie plików, usuwanie, otwieranie do zapisu, praca z atrybutami i tak dalej i tak dalej.
wspomniano powyżej Bezpośrednie PowerShell jako analog VIX API w świecie Hyper-V. Niestety mało elastyczny: dużo ograniczeń w funkcjonalności, nie działa z każdą wersją hosta i nie ze wszystkimi gośćmi.
RPC (Zdalne wywołanie procedury) Chyba nie ma osoby, która pracowała z systemem Windows, która nie widziałaby błędów związanych z RPC. Pomimo powszechnego błędnego przekonania, nie jest to pojedynczy protokół, ale dowolny protokół klient-serwer, który spełnia szereg parametrów. Jeśli jednak w naszych dziennikach pojawi się błąd RPC, w 90% przypadków będzie to błąd Microsoft RPC, który jest częścią modelu DCOM (Distributed Component Object Model). W sieci można znaleźć ogromną ilość dokumentacji na ten temat, ale lwia jej część jest dość przestarzała. Ale jeśli istnieje silna chęć przestudiowania tematu, mogę polecić artykuły , i długa lista .
Głównymi przyczynami błędów RPC w naszych dziennikach są nieudane próby komunikacji między komponentami VBR (na przykład serwer > proxy) i najczęściej problemy z komunikacją.
Na szczycie wśród wszystkich wierzchołków znajduje się błąd Serwer RPC jest niedostępny (1722). Mówiąc najprościej, klient nie mógł nawiązać połączenia z serwerem. Jak i dlaczego - nie ma jednej odpowiedzi, ale zazwyczaj jest to problem z uwierzytelnieniem lub dostępem sieciowym do portu 135. To drugie jest typowe dla infrastruktur z dynamicznym przydzielaniem portów. W tym temacie jest nawet . A Microsoft ma znaleźć przyczynę niepowodzenia.
Drugi najpopularniejszy błąd: nie ma więcej dostępnych punktów końcowych z programu mapowania punktów końcowych (1753). Klient lub serwer RPC nie mógł przypisać sobie portu. Zwykle występuje, gdy serwer (w naszym przypadku komputer gościa) został skonfigurowany do dynamicznego przydzielania portów z wąskiego zakresu, który się skończył. A jeśli logujesz się od strony klienta (w naszym przypadku serwera VBR), oznacza to, że nasz VeeamVssAgent albo się nie uruchomił, albo nie został zarejestrowany jako interfejs RPC. Jest też w tym temacie .
Cóż, aby uzupełnić 3 najczęstsze błędy RPC, pamiętajmy, że wywołanie funkcji RPC nie powiodło się (1726). Pojawia się, jeśli połączenie zostało ustanowione, ale żądania RPC nie są przetwarzane. Na przykład żądamy informacji o statusie VSS (nagle w tej chwili powstaje tam mina cienia, a my próbujemy się wspinać), aw odpowiedzi milczymy i ignorujemy.
Interfejs API kopii zapasowych na taśmach systemu Windows potrzebne do pracy z bibliotekami taśm lub napędami. Jak wspomniałem na początku: nie mamy przyjemności pisać własnych sterowników, a potem cierpieć z pomocą każdego urządzenia. Dlatego vim nie ma żadnych własnych sterowników. Wszystko za pośrednictwem standardowego interfejsu API, którego wsparcie jest realizowane przez samych dostawców sprzętu. O wiele bardziej logiczne, prawda?
SMB / CIFS Z przyzwyczajenia wszyscy zapisują je obok siebie, choć nie wszyscy pamiętają, że CIFS (Common Internet File System) to tylko prywatna wersja SMB (Server Message Block). Nie ma więc nic złego w uogólnianiu tych pojęć. Samba jest już implementacją LinuxUnix i ma swoje osobliwości, ale zrobię dygresję. Co jest tutaj ważne: gdy Veeam prosi o wpisanie czegoś do ścieżki UNC (serverdirectory), serwer używa hierarchii sterowników systemu plików, w tym mup i mrxsmb, aby zapisać do piłki. W związku z tym te sterowniki będą również generować błędy.
Nie da się bez API Winsock'a. Jeśli trzeba coś zrobić przez sieć, VBR działa poprzez Windows Socket API, popularnie znany jako Winsock. Więc jeśli widzimy kilka adresów IP:Port w dzienniku, to jest to. Oficjalna dokumentacja zawiera dobrą listę możliwych .
wspomniano powyżej WMI (Windows Management Instrumentation) to rodzaj wszechmocnego interfejsu API do zarządzania wszystkim i wszystkimi w świecie Windows. Na przykład podczas pracy z Hyper-V prawie wszystkie żądania do hosta przechodzą przez niego. Jednym słowem rzecz absolutnie niezastąpiona i bardzo potężna w swoich możliwościach. Aby dowiedzieć się, gdzie i co jest zepsute, wbudowane narzędzie WBEMtest.exe bardzo pomaga.
I ostatnie na liście, ale bynajmniej nie najmniej ważne - VSS (Przechowywanie woluminów w tle). Temat jest tak niewyczerpany i tajemniczy, jak wiele dokumentacji na jego temat napisano. Kopia w tle jest najprościej rozumiana jako specjalny rodzaj migawki, którą w istocie jest. Dzięki niemu możesz tworzyć spójne aplikacyjnie kopie zapasowe w VMware i prawie wszystko w Hyper-V. Mam w planach zrobić osobny artykuł z pewnym wyciskiem na temat VSS, ale na razie możesz spróbować poczytać . Tylko uważaj, bo. próba zrozumienia VSS w mgnieniu oka może doprowadzić do uszkodzenia mózgu.
Na tym być może się zatrzymamy. Zadanie wyjaśnienia najbardziej podstawowych rzeczy uważam za wykonane, więc w następnym rozdziale przyjrzymy się już logom. Ale jeśli masz jakieś pytania, możesz je zadać w komentarzach.
Źródło: www.habr.com