Συνεχίζουμε τη βύθισή μας στον συναρπαστικό κόσμο της εικασίας ... αντιμετώπισης προβλημάτων μέσω κορμών. ΣΕ συμφωνήσαμε για την έννοια των βασικών όρων και εξετάσαμε τη συνολική δομή του Veeam ως μια ενιαία εφαρμογή με ένα μάτι. Το καθήκον για αυτό είναι να καταλάβει πώς σχηματίζονται τα αρχεία καταγραφής, τι είδους πληροφορίες εμφανίζονται σε αυτά και γιατί φαίνονται όπως φαίνονται.
Τι πιστεύετε ότι είναι αυτά τα "κούτσουρα"; Σύμφωνα με τους περισσότερους, στα αρχεία καταγραφής οποιασδήποτε εφαρμογής θα πρέπει να ανατεθεί ο ρόλος ενός είδους παντοδύναμης οντότητας που τις περισσότερες φορές φυτρώνει κάπου στην πίσω αυλή, αλλά την κατάλληλη στιγμή εμφανίζεται από το πουθενά με λαμπερή πανοπλία και σώζει τους πάντες. Δηλαδή, θα πρέπει να περιέχουν τα πάντα, από τα παραμικρά σφάλματα σε κάθε στοιχείο έως μεμονωμένες συναλλαγές βάσης δεδομένων. Και έτσι που μετά το σφάλμα γράφτηκε αμέσως πώς αλλιώς να το διορθώσω. Και όλα αυτά πρέπει να χωρέσουν σε μερικά megabyte, όχι παραπάνω. Είναι απλώς κείμενο! Τα αρχεία κειμένου δεν μπορούν να πάρουν δεκάδες gigabyte, κάπου το άκουσα!
Τα κούτσουρα λοιπόν
Στον πραγματικό κόσμο, τα αρχεία καταγραφής είναι απλώς ένα αρχείο διαγνωστικών πληροφοριών. Και τι να αποθηκεύσετε εκεί, πού θα βρείτε πληροφορίες για αποθήκευση και πόσο λεπτομερείς θα πρέπει να είναι, εξαρτάται από τους ίδιους τους προγραμματιστές να αποφασίσουν. Κάποιος ακολουθεί το μονοπάτι του μινιμαλισμού κρατώντας αρχεία του επιπέδου ON / OFF και κάποιος επιμελώς τσουγκράνει ό,τι μπορεί να φτάσει. Παρόλο που υπάρχει και μια ενδιάμεση επιλογή με δυνατότητα επιλογής του λεγόμενου Logging Level, όταν εσείς ο ίδιος υποδεικνύετε πόσο λεπτομερείς πληροφορίες θέλετε να αποθηκεύσετε και πόσο επιπλέον χώρο στο δίσκο έχετε =) Το VBR έχει, παρεμπιπτόντως, έξι τέτοια επίπεδα. Και, πιστέψτε με, δεν θέλετε να δείτε τι συμβαίνει με την πιο λεπτομερή καταγραφή με ελεύθερο χώρο στο δίσκο σας.
Πρόστιμο. Καταλάβαμε κατά προσέγγιση τι θέλουμε να σώσουμε, αλλά τίθεται ένα εύλογο ερώτημα: από πού να αντλήσουμε αυτές τις πληροφορίες; Φυσικά, αποτελούμε μέρος των γεγονότων για την καταγραφή του εαυτού μας από τις εσωτερικές μας διαδικασίες. Τι να κάνουμε όμως όταν υπάρχει αλληλεπίδραση με το εξωτερικό περιβάλλον; Για να μην γλιστρήσει σε μια κόλαση με πατερίτσες και ποδήλατα, η Veeam τείνει να μην εφευρίσκει εφευρέσεις που έχουν ήδη εφευρεθεί. Όποτε υπάρχει έτοιμο API, ενσωματωμένη συνάρτηση, βιβλιοθήκη κ.λπ., θα προτιμάμε έτοιμες επιλογές πριν αρχίσουμε να περιφράσσουμε τα κατασκευάσματα μας. Αν και το τελευταίο είναι επίσης αρκετό. Επομένως, κατά την ανάλυση αρχείων καταγραφής, είναι σημαντικό να κατανοήσετε ότι η μερίδα του λέοντος των σφαλμάτων πέφτει σε μηνύματα από API τρίτων κατασκευαστών, κλήσεις συστήματος και άλλες βιβλιοθήκες. Σε αυτήν την περίπτωση, ο ρόλος του VBR έγκειται στην προώθηση αυτών των σφαλμάτων στα ως έχουν αρχεία καταγραφής. Και το κύριο καθήκον του χρήστη είναι να μάθει να κατανοεί ποια γραμμή είναι από ποιον και για ποιον είναι υπεύθυνος αυτός ο "ποιος". Επομένως, εάν ένας κωδικός σφάλματος από το αρχείο καταγραφής VBR σας μεταφέρει σε μια σελίδα MSDN, αυτό είναι εντάξει και σωστό.
Όπως συμφωνήσαμε νωρίτερα: Το Veeam είναι μια λεγόμενη εφαρμογή που βασίζεται σε SQL. Αυτό σημαίνει ότι όλες οι ρυθμίσεις, όλες οι πληροφορίες και γενικά όλα όσα είναι απαραίτητα μόνο για την κανονική λειτουργία - όλα αποθηκεύονται στη βάση δεδομένων του. Εξ ου και η απλή αλήθεια: ότι δεν υπάρχει στα αρχεία καταγραφής είναι πιθανότατα στη βάση δεδομένων. Αλλά ούτε αυτό είναι ασημένιο: ορισμένα πράγματα δεν βρίσκονται στα τοπικά αρχεία καταγραφής των στοιχείων Veeam, ούτε στη βάση δεδομένων του. Επομένως, πρέπει να μάθετε πώς να μελετάτε τα αρχεία καταγραφής του κεντρικού υπολογιστή, τα αρχεία καταγραφής του τοπικού μηχανήματος και τα αρχεία καταγραφής όλων των στοιχείων που εμπλέκονται στη διαδικασία δημιουργίας αντιγράφων ασφαλείας και επαναφοράς. Και επίσης συμβαίνει ότι οι απαραίτητες πληροφορίες δεν είναι διαθέσιμες πουθενά. Αυτός είναι ο τρόπος.
Μερικά παραδείγματα τέτοιων API
Αυτή η λίστα δεν έχει στόχο να είναι εξαιρετικά πλήρης, επομένως δεν χρειάζεται να αναζητήσετε την απόλυτη αλήθεια σε αυτήν. Σκοπός του είναι μόνο να εμφανίσει τα πιο κοινά API τρίτων και τεχνολογίες που χρησιμοποιούνται στα προϊόντα μας.
Ας αρχίσουμε VMware.
Πρώτος στη λίστα θα είναι vSphere API. Χρησιμοποιείται για έλεγχο ταυτότητας, ανάγνωση της ιεραρχίας, δημιουργία και διαγραφή στιγμιότυπων, αίτημα πληροφοριών σχετικά με μηχανήματα και πολλά (πάρα πολλά) άλλα. Η λειτουργικότητα της λύσης είναι πολύ ευρεία, επομένως μπορώ να προτείνω το VMware vSphere API Reference για την έκδοση и . Για πιο πρόσφατες εκδόσεις, όλα αναζητούνται στο google.
VIX API. Η μαύρη μαγεία του hypervisor, για την οποία υπάρχει ξεχωριστό . VMware API για εργασία με αρχεία στον κεντρικό υπολογιστή χωρίς σύνδεση σε αυτά μέσω δικτύου. Μια παραλλαγή της τελευταίας λύσης όταν πρέπει να βάλετε ένα αρχείο σε ένα μηχάνημα στο οποίο δεν υπάρχει καλύτερο κανάλι επικοινωνίας. Είναι πόνο και ταλαιπωρία εάν το αρχείο είναι μεγάλο και ο κεντρικός υπολογιστής είναι φορτωμένος. Αλλά εδώ λειτουργεί ο κανόνας ότι ακόμη και 56,6 Kb / s είναι καλύτερο από 0 Kb / s. Στο Hyper-V, αυτό το πράγμα ονομάζεται PowerShell Direct. Αλλά αυτό ήταν μόνο πριν
vSpehere Web Services API Ξεκινώντας από το vSphere 6.0 (περίπου, από τότε που αυτό το API εισήχθη για πρώτη φορά στην έκδοση 5.5) χρησιμοποιείται για εργασία με Guest μηχανήματα και έχει αντικαταστήσει το VIX σχεδόν παντού. Στην πραγματικότητα, αυτό είναι ένα άλλο API για τη διαχείριση του vSphere. Για όσους ενδιαφέρονται προτείνω να μελετήσουν εγχειρίδιο.
VDDK (Κιτ ανάπτυξης εικονικού δίσκου). Η βιβλιοθήκη, η οποία συζητήθηκε εν μέρει σε αυτό . Χρησιμοποιείται για την ανάγνωση εικονικών δίσκων. Μια φορά κι έναν καιρό ήταν μέρος του VIX, αλλά με τον καιρό μεταφέρθηκε σε ξεχωριστό προϊόν. Αλλά ως κληρονόμος, χρησιμοποιεί τους ίδιους κωδικούς σφάλματος με το VIX. Αλλά για κάποιο λόγο, δεν υπάρχει περιγραφή αυτών των σφαλμάτων στο ίδιο το SDK. Επομένως, ανακαλύφθηκε εμπειρικά ότι τα σφάλματα VDDK με άλλους κωδικούς είναι απλώς μια μετάφραση από τον δυαδικό σε δεκαδικό κώδικα. Αποτελείται από δύο μέρη - το πρώτο μισό είναι μη τεκμηριωμένες πληροφορίες σχετικά με το πλαίσιο και το δεύτερο μέρος είναι τα παραδοσιακά σφάλματα VIX / VDDK. Για παράδειγμα, αν δούμε:
VDDK error: 21036749815809.Unknown error
Στη συνέχεια, το μετατρέπουμε με τόλμη σε δεκαεξαδικό και λαμβάνουμε 132200000001. Απλώς απορρίπτουμε την μη πληροφοριακή αρχή του 132200 και το υπόλοιπο θα είναι ο κωδικός σφάλματος (VDDK 1: Άγνωστο σφάλμα). Σχετικά με τα πιο συχνά σφάλματα VDDK, μόλις πρόσφατα υπήρχε ένα ξεχωριστό .
Τώρα ας δούμε Windows.
Εδώ, όλα όσα είναι πιο απαραίτητα και σημαντικά για εμάς μπορούν να βρεθούν στο πρότυπο Προβολή συμβάντων. Αλλά υπάρχει ένα αλίευμα: σύμφωνα με μια μακρά παράδοση, τα Windows δεν καταγράφουν το πλήρες κείμενο του σφάλματος, αλλά μόνο τον αριθμό του. Για παράδειγμα, το σφάλμα 5 είναι "Δεν επιτρέπεται η πρόσβαση" και το 1722 είναι "Ο διακομιστής RPC δεν είναι διαθέσιμος" και το 10060 είναι "Η σύνδεση έληξε". Φυσικά, είναι υπέροχο αν θυμάστε τα πιο διάσημα, αλλά τι γίνεται με τα αόρατα μέχρι στιγμής;
Και για να μην φαίνεται καθόλου η ζωή σαν μέλι, τα σφάλματα αποθηκεύονται και σε δεκαεξαδική μορφή, με το πρόθεμα 0x8007. Για παράδειγμα, το 0x8007000e είναι στην πραγματικότητα 14, εκτός μνήμης. Το γιατί και για ποιον έγινε αυτό είναι ένα μυστήριο τυλιγμένο στο σκοτάδι. Ωστόσο, μπορείτε να κατεβάσετε μια πλήρη λίστα σφαλμάτων δωρεάν και χωρίς SMS από .
Παρεμπιπτόντως, μερικές φορές υπάρχουν και άλλα προθέματα, όχι μόνο 0x8007. Σε μια τόσο θλιβερή κατάσταση, για να κατανοήσετε το HRESULT («λαβή αποτελέσματος»), πρέπει να εμβαθύνετε για προγραμματιστές. Στη συνηθισμένη ζωή, δεν σας συμβουλεύω να το κάνετε αυτό, αλλά αν πιέσετε ξαφνικά στον τοίχο ή είστε απλώς περίεργοι, τώρα ξέρετε τι να κάνετε.
Αλλά οι σύντροφοι στη Microsoft μας λυπήθηκαν λίγο και έδειξαν στον κόσμο μια χρησιμότητα . Αυτό είναι ένα μικρό κομμάτι της ευτυχίας της κονσόλας που μπορεί να μεταφράσει τους κωδικούς σφαλμάτων σε ανθρώπινους χωρίς τη χρήση του Google. Δουλεύει κάπως έτσι.
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"Τίθεται ένα εύλογο ερώτημα: γιατί δεν γράφουμε αμέσως την αποκρυπτογράφηση στα αρχεία καταγραφής, αλλά αφήνουμε αυτούς τους μυστηριώδεις κώδικες; Η απάντηση βρίσκεται σε εφαρμογές τρίτων. Όταν τραβάτε μόνοι σας κάποια κλήση WinAPI, δεν είναι δύσκολο να αποκρυπτογραφήσετε την απόκρισή της, επειδή υπάρχει ακόμη και μια ειδική κλήση WinAPI για αυτό. Αλλά όπως ήδη αναφέρθηκε, όλα όσα έρχονται σε εμάς μόνο σε απαντήσεις μπαίνουν στα αρχεία καταγραφής μας. Και εδώ, για να το αποκρυπτογραφήσει κάποιος, θα έπρεπε να παρακολουθεί συνεχώς αυτό το ρεύμα συνείδησης, να βγάλει κομμάτια με σφάλματα των Windows από αυτό, να τα αποκρυπτογραφήσει και να τα επικολλήσει πίσω. Ας είμαστε ειλικρινείς, όχι η πιο συναρπαστική δραστηριότητα.
API διαχείρισης αρχείων των Windows χρησιμοποιείται με κάθε δυνατό τρόπο κατά την εργασία με αρχεία. Δημιουργία αρχείων, διαγραφή, άνοιγμα για εγγραφή, εργασία με χαρακτηριστικά, και ούτω καθεξής και ούτω καθεξής.
αναφέρθηκε παραπάνω PowerShell Direct ως ανάλογο του VIX API στον κόσμο του Hyper-V. Δυστυχώς, όχι τόσο ευέλικτο: πολλοί περιορισμοί στη λειτουργικότητα, δεν λειτουργεί με κάθε έκδοση του κεντρικού υπολογιστή και όχι με όλους τους επισκέπτες.
RPC (Κλήση απομακρυσμένης διαδικασίας) Δεν νομίζω ότι υπάρχει ένα άτομο που να έχει εργαστεί με τα Windows που να μην έχει δει σφάλματα που σχετίζονται με το RPC. Παρά τη δημοφιλή παρερμηνεία, δεν πρόκειται για ένα πρωτόκολλο, αλλά για οποιοδήποτε πρωτόκολλο πελάτη-διακομιστή που ικανοποιεί έναν αριθμό παραμέτρων. Ωστόσο, εάν υπάρχει σφάλμα RPC στα αρχεία καταγραφής μας, το 90% των περιπτώσεων θα είναι σφάλμα από το Microsoft RPC, το οποίο αποτελεί μέρος του DCOM (Distributed Component Object Model). Μπορείτε να βρείτε μια τεράστια ποσότητα τεκμηρίωσης για αυτό το θέμα στο διαδίκτυο, αλλά η μερίδα του λέοντος είναι αρκετά ξεπερασμένη. Αλλά αν υπάρχει έντονη επιθυμία να μελετήσετε το θέμα, τότε μπορώ να προτείνω άρθρα , και μακρύς κατάλογος .
Οι κύριες αιτίες των σφαλμάτων RPC στα αρχεία καταγραφής μας είναι αποτυχημένες προσπάθειες επικοινωνίας μεταξύ στοιχείων VBR (διακομιστής > διακομιστής μεσολάβησης, για παράδειγμα) και τις περισσότερες φορές λόγω προβλημάτων επικοινωνίας.
Η κορυφαία κορυφή μεταξύ όλων των κορυφαίων είναι το σφάλμα Ο διακομιστής RPC δεν είναι διαθέσιμος (1722). Με απλά λόγια, ο πελάτης δεν μπορούσε να δημιουργήσει σύνδεση με τον διακομιστή. Πώς και γιατί - δεν υπάρχει ενιαία απάντηση, αλλά συνήθως πρόκειται για πρόβλημα με τον έλεγχο ταυτότητας ή με την πρόσβαση δικτύου στη θύρα 135. Το τελευταίο είναι χαρακτηριστικό για υποδομές με δυναμική εκχώρηση θύρας. Σε αυτό το θέμα, υπάρχει ακόμη . Και η Microsoft έχει για να βρείτε την αιτία της αποτυχίας.
Δεύτερο πιο δημοφιλές σφάλμα: Δεν υπάρχουν πλέον διαθέσιμα τελικά σημεία από το mapper (1753). Ο πελάτης ή ο διακομιστής RPC απέτυχε να εκχωρήσει στον εαυτό του μια θύρα. Συνήθως συμβαίνει όταν ο διακομιστής (στην περίπτωσή μας, ο επισκέπτης) έχει ρυθμιστεί να εκχωρεί δυναμικά θύρες από ένα στενό εύρος που έχει τελειώσει. Και αν συνδεθείτε από την πλευρά του πελάτη (στην περίπτωσή μας, ο διακομιστής VBR), αυτό σημαίνει ότι το VeeamVssAgent είτε δεν ξεκίνησε είτε δεν είχε καταχωρηθεί ως διεπαφή RPC. Υπάρχει επίσης σε αυτό το θέμα .
Λοιπόν, για να ολοκληρώσουμε τα κορυφαία 3 σφάλματα RPC, ας θυμηθούμε ότι η κλήση συνάρτησης RPC απέτυχε (1726). Εμφανίζεται εάν η σύνδεση έχει δημιουργηθεί, αλλά τα αιτήματα RPC δεν υποβάλλονται σε επεξεργασία. Για παράδειγμα, ζητάμε πληροφορίες σχετικά με την κατάσταση του VSS (ξαφνικά αυτή τη στιγμή φτιάχνεται μια σκιώδης νάρκη εκεί και προσπαθούμε να σκαρφαλώσουμε), και ως απάντηση σε εμάς, σιωπή και αγνόηση.
Windows Tape Backup API απαιτείται για εργασία με βιβλιοθήκες κασετών ή μονάδες δίσκου. Όπως ανέφερα στην αρχή: δεν έχουμε ευχαρίστηση να γράφουμε τα δικά μας προγράμματα οδήγησης και μετά να υποφέρουμε με την υποστήριξη της κάθε συσκευής. Επομένως, το vim δεν έχει κανένα δικό του πρόγραμμα οδήγησης. Όλα μέσω ενός τυπικού API, η υποστήριξη του οποίου υλοποιείται από τους ίδιους τους προμηθευτές υλικού. Πολύ πιο λογικό, σωστά;
SMB / CIFS Από συνήθεια, όλοι τα γράφουν δίπλα-δίπλα, αν και δεν θυμούνται όλοι ότι το CIFS (Common Internet File System) είναι απλώς μια ιδιωτική έκδοση του SMB (Server Message Block). Επομένως, δεν υπάρχει τίποτα κακό με τη γενίκευση αυτών των εννοιών. Το Samba είναι ήδη μια υλοποίηση LinuxUnix και έχει τις δικές του ιδιαιτερότητες, αλλά παρεκκλίνω. Αυτό που είναι σημαντικό εδώ: όταν ο Veeam ζητά να γράψει κάτι στη διαδρομή UNC (κατάλογος διακομιστή), ο διακομιστής χρησιμοποιεί την ιεραρχία των προγραμμάτων οδήγησης συστήματος αρχείων, συμπεριλαμβανομένων των mup και mrxsmb, για να γράψει στη μπάλα. Κατά συνέπεια, αυτά τα προγράμματα οδήγησης θα δημιουργήσουν επίσης σφάλματα.
Δεν γίνεται χωρίς Winsock API. Εάν κάτι πρέπει να γίνει μέσω του δικτύου, το VBR λειτουργεί μέσω του Windows Socket API, ευρέως γνωστό ως Winsock. Έτσι, αν δούμε μια δέσμη IP:Port στο αρχείο καταγραφής, αυτό είναι. Η επίσημη τεκμηρίωση έχει μια καλή λίστα πιθανών .
αναφέρθηκε παραπάνω WMI (Windows Management Instrumentation) είναι ένα είδος παντοδύναμου API για τη διαχείριση των πάντων και όλων στον κόσμο των Windows. Για παράδειγμα, όταν εργάζεστε με το Hyper-V, σχεδόν όλα τα αιτήματα προς τον κεντρικό υπολογιστή περνούν από αυτό. Με μια λέξη, το πράγμα είναι απολύτως αναντικατάστατο και πολύ δυνατό στις δυνατότητές του. Σε μια προσπάθεια να σας βοηθήσει να μάθετε πού και τι είναι χαλασμένο, το ενσωματωμένο εργαλείο WBEMtest.exe βοηθάει πολύ.
Και τελευταίο στη λίστα, αλλά σε καμία περίπτωση λιγότερο σημαντικό - VSS (Volume Shadow Storage). Το θέμα είναι τόσο ανεξάντλητο και μυστηριώδες όσο πολλά έγγραφα έχουν γραφτεί πάνω του. Το Shadow Copy είναι πιο απλά κατανοητό ως ένας ειδικός τύπος στιγμιότυπου, που στην ουσία είναι. Χάρη σε αυτόν, μπορείτε να δημιουργήσετε αντίγραφα ασφαλείας με συνέπεια στην εφαρμογή στο VMware και σχεδόν τα πάντα στο Hyper-V. Έχω σχέδια να φτιάξω ένα ξεχωριστό άρθρο με λίγη πίεση στο VSS, αλλά προς το παρόν μπορείτε να δοκιμάσετε να διαβάσετε . Προσοχή μόνο γιατί. Η προσπάθεια κατανόησης του VSS με μια ματιά μπορεί να οδηγήσει σε εγκεφαλική βλάβη.
Σε αυτό, ίσως, μπορούμε να σταματήσουμε. Θεωρώ ότι το έργο της εξήγησης των πιο βασικών πραγμάτων έχει ολοκληρωθεί, επομένως στο επόμενο κεφάλαιο θα δούμε ήδη τα αρχεία καταγραφής. Αλλά αν έχετε οποιεσδήποτε ερωτήσεις, μη διστάσετε να τις ρωτήσετε στα σχόλια.
Πηγή: www.habr.com