Kontynuujemy nasze zanurzenie w fascynujący świat troubleshootingu poprzez logi. W umówiliśmy się na znaczenie podstawowych terminów i rzuciliśmy okiem na ogólną strukturę Veeam jako jednolitej aplikacji. Zadanie na tę sesję to zrozumieć, jak tworzone są pliki logów, jakie informacje są w nich wyświetlane i dlaczego wyglądają tak, jak wyglądają.
Co myślicie o tych "logach"? Według większości, logi jakiejkolwiek aplikacji powinny odgrywać rolę wszechmocnej istoty, która przez większość czasu przebywa gdzieś na zapleczu, ale w odpowiednim momencie pojawia się znikąd w błyszczących zbrojach i wszyscy zostają uratowani. To znaczy, że powinny zawierać wszystko, od najmniejszych błędów w każdym komponencie, po pojedyncze transakcje bazy. I żeby po błędzie od razu było napisane, jak to naprawić. A to wszystko powinno zmieścić się w kilku megabajtach, nie więcej. Przecież to tylko tekst! Nie mogą pliki tekstowe zajmować dziesiątek gigabajtów, gdzieś to słyszałem!
Tak więc, logi
W rzeczywistym świecie logi to zaledwie archiwum informacji diagnostycznych. A co tam przechowywać, skąd brać informacje do przechowywania i jak szczegółowe powinny być, decydują sami programiści. Niektórzy wybierają minimalizm, przechowując tylko zapisy poziomu WŁĄCZ/WYŁĄCZ, a inni starannie zbierają wszystko, co tylko mogą. Jest też pośrednia opcja z możliwością wyboru tzw. poziomu logowania, kiedy sam określasz, jak szczegółowe informacje chcesz przechować i jak wiele miejsca masz na dyskach =) VBR ma takich poziomów aż sześć, swoją drogą. I uwierzcie mi, nie chcecie widzieć, co się dzieje przy maksymalnym szczegółowym logowaniu przy wolnym miejscu na waszym dysku.
Dobrze. Mamy mniej więcej pomysł, co chcemy zachować, ale pojawia się uzasadnione pytanie: skąd czerpać te informacje? Część zdarzeń do logowania, oczywiście, generujemy sami naszymi wewnętrznymi procesami. Ale co robić, gdy dochodzi do interakcji z zewnętrznym środowiskiem? Aby nie wpaść w piekło z błędami i improwizowanymi rozwiązaniami, Veeam ma tendencję, by nie wynajdować już wynalezionych rozwiązań. Zawsze, gdy istnieje gotowe API, wbudowana funkcja systemowa, biblioteka itd., damy pierwszeństwo gotowym rozwiązaniom, zanim zaczniemy tworzyć nasze pomysłowe koncepcje. Choć takich również nie brakuje. Dlatego podczas analizy logów ważne jest, aby zrozumieć, że lwia część błędów pochodzi z komunikatów z zewnętrznych API, wywołań systemowych i innych bibliotek. W tym przypadku rola VBR ogranicza się do przesyłania tych błędów do plików logów w oryginalnej formie. A głównym zadaniem użytkownika jest nauczyć się rozumieć, które wiersze pochodzą od kogo, i za co ten „kto” odpowiada. Dlatego, jeśli kod błędu z loga VBR prowadzi cię na stronę MSDN, to jest to normalne i poprawne.
Jak wcześniej ustaliliśmy: Veeam to tak zwana aplikacja oparta na SQL. Oznacza to, że wszystkie ustawienia, wszystkie informacje i w ogóle wszystko, co potrzebne do normalnego działania — wszystko jest przechowywane w jego bazie. Stąd prosta zasada: to, czego nie ma w logach, najprawdopodobniej znajduje się w bazie. Ale to nie jest rozwiązanie bezbłędne: niektóre rzeczy nie znajdują się ani w lokalnych logach komponentów Veeam, ani w jego bazie. Dlatego trzeba nauczyć się analizować logi hosta, logi lokalnej maszyny i logi wszystkiego, co bierze udział w procesie tworzenia kopii zapasowej i przywracania. Czasem zdarza się, że potrzebne informacje nie są dostępne w ogóle nigdzie. Taka jest natura.
Kilka przykładów takich API
Ta lista nie ma na celu być całkowicie wyczerpująca, więc nie należy w niej szukać ostatniej prawdy. Jej celem jest jedynie pokazanie najczęściej używanych zewnętrznych API i technologii stosowanych w naszych produktach.
Zacznijmy od VMware.
Pierwszym na liście będzie vSphere API. Używane do uwierzytelniania, odczytywania hierarchii, tworzenia i usuwania migawki, żądania informacji o maszynach i wielu (naprawdę wielu) innych rzeczy. Funkcjonalność rozwiązania jest bardzo szeroka, więc wszystkim zainteresowanym mogę polecić VMware vSphere API Reference dla wersji i . Dla bardziej aktualnych wersji wystarczy wyszukać w internecie.
VIX API. Czarna magia hypervisora, dla której istnieje osobna . VMware API do pracy z plikami na hoście bez łączenia się z nimi przez sieć. Ostatnia deska ratunku, gdy trzeba umieścić plik w maszynie, do której nie ma lepszego kanału komunikacji. To rodzi ból i cierpienie, jeśli plik jest duży, a host obciążony. Tutaj działa zasada, że nawet 56,6 Kb/s to lepiej niż 0 Kb/s. W Hyper-V podobna rzecz nazywa się PowerShell Direct. Ale tak było tylko do pojawienia się
vSphere Web Services API Zaczynając od vSphere 6.0 (z grubsza, ponieważ ten API został po raz pierwszy zaprezentowany w wersji 5.5) jest używane do pracy z maszynami wirtualnymi i już praktycznie wszędzie zastąpiło VIX. W zasadzie to kolejny API do zarządzania vSphere. Osobom zainteresowanym mogę polecić zapoznanie się z podręcznikiem.
VDDK (Virtual Disk Development Kit). Biblioteka, o której częściowo mówiono w tej . Używana do odczytu wirtualnych dysków. Kiedyś była częścią VIX, jednak z czasem została przeniesiona do osobnego produktu. Jednak jako spadkobierca wykorzystuje te same kody błędów, co VIX. Ale z jakiegoś powodu w samym SDK nie ma opisów tych błędów. Dlatego doświadczenie pokazało, że błędy VDDK z innymi kodami to tylko translacja z binarnego na dziesiętny kod. Składa się z dwóch części – pierwsza połowa to niedokumentowane informacje o kontekście, a druga część to tradycyjne błędy VIX/VDDK. Na przykład, jeśli widzimy:
Błąd VDDK: 21036749815809. Nieznany błąd
To śmiało konwertujemy to na hex i otrzymujemy 132200000001. Nieinformacyjny początek 132200 po prostu odrzucamy, a reszta to nasz kod błędu (VDDK 1: Nieznany błąd). O najczęstszych błędach VDDK niedawno była osobna .
Teraz spójrzmy na Windows.
Tutaj wszystko, co potrzebne i ważne dla nas, można znaleźć w standardowym Podglądzie zdarzeń. Ale jest jedna pułapka: według starej tradycji Windows rejestruje nie pełny tekst błędu, a tylko jego numer. Na przykład, błąd 5 to „Odmowa dostępu”, a 1722 to „Serwer RPC jest niedostępny”, no i 10060 to „Przekroczenie limitu czasu połączenia”. Oczywiście, dobrze jest, jeśli pamiętasz te najbardziej znane, jednak co z wcześniej niewidzianymi?
Aby życie nie wydawało się zbyt różowe, błędy są także przechowywane w postaci szesnastkowej, z prefiksem 0x8007. Na przykład, 0x8007000e to tak naprawdę 14, Brak pamięci. Dlaczego i dla kogo to zrobiono - to tajemnica owiana mgłą. Pełną listę błędów można pobrać za darmo i bez SMS-ów z .
Przy okazji, czasami występują również inne prefiksy, a nie tylko 0x8007. W tak smutnej sytuacji dla zrozumienia HRESULT („uchwyt wyniku”) trzeba jeszcze głębiej wnikać w dla deweloperów. W normalnym życiu nie radziłbym Wam tego robić, ale jeśli nagle czujecie się przyparci do muru lub po prostu jesteście ciekawi, teraz wiecie, co robić.
Ale koledzy z Microsoftu nieco się nad nami zlitowali i przedstawili światu narzędzie . To mały kawałek konsolowego szczęścia, który potrafi tłumaczyć kody błędów na ludzki język bez użycia Google. Działa to mniej więcej tak.
C:UsersrootDesktop>err.exe 0x54f
# dla hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Wystąpił błąd wewnętrzny.
# jako HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# dla hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Wystąpił błąd wewnętrzny.
# 2 pasujące wpisy znalezione dla "0x54f"Pojawia się uzasadnione pytanie: dlaczego nie zapisujemy od razu w logach wyjaśnień, a zostawiamy te tajemnicze kody? Odpowiedź leży w aplikacjach zewnętrznych. Kiedy sam wywołujesz jakąś funkcję WinAPI, łatwo jest zrozumieć jej odpowiedź, ponieważ jest do tego nawet specjalne wywołanie WinAPI. Ale jak już wspomniano, do naszych logów trafia wszystko, co tylko przychodzi w odpowiedziach. A tu dla zrozumienia trzeba by było ciągle monitorować ten strumień świadomości, wyłapywać z niego fragmenty z błędami systemu Windows, rozkodowywać je i wstawiać z powrotem. Powiedzmy szczerze, to nie jest najbardziej fascynujące zajęcie.
Interfejs API zarządzania plikami systemu Windows jest w różnoraki sposób używany podczas pracy z plikami. Tworzenie plików, usuwanie, otwieranie do zapisu, praca z atrybutami i tak dalej.
Wspomniany wcześniej PowerShell Direct jest odpowiednikiem VIX API w świecie Hyper-V. Niestety, nie jest tak elastyczny: ma mnóstwo ograniczeń funkcjonalnych, nie działa z każdą wersją hosta i daleko nie z wszystkimi gośćmi.
RPC (Remote Procedure Call) Uważam, że nie ma takiej osoby, która pracując z systemem Windows, nie spotkałaby się z błędami związanymi z RPC. Wbrew powszechnemu przekonaniu nie jest to jeden protokół, ale każdy protokół klient-serwer spełniający określone wymagania. Jeśli w naszych logach pojawia się błąd RPC, w 90% przypadków będzie to błąd Microsoft RPC, który jest częścią DCOM (Distributed Component Object Model). W sieci można znaleźć mnóstwo dokumentacji na ten temat, jednak większość z niej jest dość przestarzała. Jeśli jednak masz silną chęć zgłębić ten temat, mogę polecić artykuły , i długą listę .
Główne przyczyny występowania błędów RPC w naszych logach to nieudane próby interakcji pomiędzy komponentami VBR (serwer > proxy, na przykład) i najczęściej związane są z problemami z łącznością.
Niekwestionowanym liderem wśród błędów jest błąd The RPC server is unavailable (1722). Mówiąc prosto, klient nie mógł nawiązać połączenia z serwerem. Dlaczego tak się dzieje – nie ma jednej odpowiedzi, ale zazwyczaj jest to problem z autoryzacją lub z dostępem sieciowym do portu 135. To ostatnie jest charakterystyczne dla infrastruktury z dynamicznym przydzielaniem portów. Na ten temat istnieje nawet . A Microsoft ma na temat poszukiwania przyczyn awarii.
Drugim najpopularniejszym błędem jest: There are no more endpoints available from the endpoint mapper (1753). Klient RPC lub serwer nie mogli przypisać sobie portu. Zwykle występuje, gdy serwer (w naszym przypadku maszyna wirtualna) został skonfigurowany na dynamiczne przydzielanie portów z wąskiego zakresu, który się wyczerpał. A jeśli spojrzeć od strony klienta (w naszym przypadku serwer VBR), oznacza to, że nasz VeeamVssAgent albo się nie uruchomił, albo nie został zarejestrowany jako interfejs RPC. Na ten temat również istnieje .
A żeby zakończyć naszą top-3 błędów RPC, przypomnijmy błąd RPC function call failed (1726). Pojawia się, jeśli połączenie zostało nawiązane, ale żądania RPC nie są realizowane. Na przykład, prosimy o informacje o statusie VSS (może akurat w tej chwili wykonywana jest kopia zapasowa, a my próbujemy się do niej dostać), a w odpowiedzi otrzymujemy ciszę i ignorowanie.
Windows Tape Backup API jest potrzebny do pracy z bibliotekami taśmowymi lub napędami. Jak wspomniałem na początku: pisanie własnych sterowników i późniejsze trudności z obsługą każdego urządzenia nie sprawia nam przyjemności. Dlatego Veeam nie ma żadnych własnych sterowników. Wszystko przez standardowe API, którego wsparcie realizują sami dostawcy sprzętu. Tak jest znacznie bardziej logiczne, prawda?
SMB/CIFS Wszyscy przyzwyczaili się pisać je obok siebie, chociaż niewiele osób pamięta, że CIFS (Common Internet File System) to po prostu prywatna wersja SMB (Server Message Block). Nie ma więc nic złego w uogólnieniu tych pojęć. Samba to już realizacja LinuxUnix, która ma swoje specyfiki, ale to dygresja. Ważne jest to, że gdy Veeam prosi o zapisanie czegoś przez ścieżkę UNC (serverdirectory), serwer używa hierarchii sterowników systemu plików, w tym mup i mrxsmb, do zapisu na udostępnionym zasobie. Odpowiednio, błędy będą generowane przez te sterowniki.
Nie da się obędzie bez Winsock API. Jeśli trzeba coś zrobić w sieci, VBR działa przez Windows Socket API, powszechnie znane jako Winsock. Jeśli więc widzimy w logach parę IP:Port, to właśnie to. W oficjalnej dokumentacji znajduje się całkiem niezła lista możliwych .
Wspomniany wcześniej WMI (Windows Management Instrumentation) — to wszechstronne API do zarządzania wszystkim w świecie Windows. Na przykład, przy pracy z Hyper-V prawie wszystkie zapytania do hosta odbywają się właśnie przez nie. W słowach, to rzecz całkowicie niezastąpiona i bardzo potężna w swoich możliwościach. W próbach pomocy w ustaleniu, gdzie i co się zepsuło, bardzo pomaga wbudowane narzędzie WBEMtest.exe.
A ostatni na liście, ale zupełnie nie mniej ważny — VSS (Volume Shadow Storage). Temat jest tak niewyczerpany i tajemniczy, jak wiele napisano na jego temat dokumentacji. Shadow Copy najłatwiej zrozumieć jako szczególny typ migawki, którym w zasadzie jest. Dzięki niemu w VMware można robić kopie zapasowe spójne aplikacyjnie, a w Hyper-V prawie wszystko. Planuję napisanie osobnego artykułu o VSS, ale na razie możesz spróbować przeczytać . Tylko ostrożnie, ponieważ próba zrozumienia VSS bez przygotowania może prowadzić do urazów głowy.
Na tym można by zakończyć. Uważam, że zrealizowałem zadanie wyjaśnienia najprostszych rzeczy, więc w następnym rozdziale już przyjrzymy się logom. Ale jeśli masz jakieś pytania, nie wahaj się ich zadawać w komentarzach.
Źródło: habr.com
