Συνεχίζουμε την βουτιά μας στον συναρπαστικό κόσμο της μαντείας... την αντιμετώπιση προβλημάτων μέσω αρχείων καταγραφής. Συμφωνήσαμε σχετικά με την έννοια των βασικών όρων και ρίξαμε μια γρήγορη ματιά στη συνολική δομή του Veeam ως ενιαίας εφαρμογής. Στόχος μας είναι να κατανοήσουμε πώς σχηματίζονται τα αρχεία καταγραφής, ποιες πληροφορίες εμφανίζονται σε αυτά και γιατί έχουν αυτή την εμφάνιση.
Τι νομίζετε ότι είναι αυτά τα "αρχεία καταγραφής"; Οι περισσότεροι άνθρωποι πιστεύουν ότι τα αρχεία καταγραφής οποιασδήποτε εφαρμογής θα πρέπει να έχουν τον ρόλο κάποιου είδους παντοδύναμης οντότητας που περνάει τον περισσότερο χρόνο της μαραζώνοντας κάπου στην πίσω αυλή, αλλά την κατάλληλη στιγμή εμφανίζεται από το πουθενά με λαμπερή πανοπλία και σώζει τους πάντες. Δηλαδή, θα πρέπει να περιέχουν τα πάντα, από τα μικρότερα σφάλματα σε κάθε στοιχείο μέχρι τις μεμονωμένες συναλλαγές βάσης δεδομένων. Και έτσι ώστε μετά από ένα σφάλμα, να υποδεικνύει αμέσως πώς αλλιώς να το διορθώσετε. Και όλα αυτά θα πρέπει να χωράνε σε μερικά megabyte, όχι περισσότερα. Είναι απλώς κείμενο! Τα αρχεία κειμένου δεν μπορούν να καταλάβουν δεκάδες gigabyte, το άκουσα κάπου!
Λοιπόν, αρχεία καταγραφής
Στον πραγματικό κόσμο, τα αρχεία καταγραφής είναι απλώς ένα αρχείο διαγνωστικών πληροφοριών. Και τι να αποθηκεύσετε εκεί, πού να βρείτε τις πληροφορίες για αποθήκευση και πόσο λεπτομερείς θα πρέπει να είναι, εξαρτάται από τους ίδιους τους προγραμματιστές να αποφασίσουν. Κάποιοι ακολουθούν τον δρόμο του μινιμαλισμού αποθηκεύοντας αρχεία σε επίπεδο ON/OFF, και κάποιοι συλλέγουν επιμελώς ό,τι μπορούν να βρουν. Αν και υπάρχει και μια ενδιάμεση επιλογή με τη δυνατότητα επιλογής του λεγόμενου Επιπέδου Καταγραφής, όταν εσείς οι ίδιοι καθορίζετε πόσο λεπτομερείς είναι οι πληροφορίες που θέλετε να αποθηκεύσετε και πόσο επιπλέον χώρο έχετε στους δίσκους σας =) Το VBR έχει έως και έξι τέτοια επίπεδα, παρεμπιπτόντως. Και πιστέψτε με, δεν θέλετε να δείτε τι συμβαίνει με τον ελεύθερο χώρο στον δίσκο σας με την πιο λεπτομερή καταγραφή.
Εντάξει. Έχουμε μια γενική ιδέα για το τι θέλουμε να αποθηκεύσουμε, αλλά τίθεται ένα εύλογο ερώτημα: από πού να λάβουμε αυτές τις πληροφορίες; Φυσικά, δημιουργούμε μόνοι μας ορισμένα από τα συμβάντα για την καταγραφή χρησιμοποιώντας τις εσωτερικές μας διαδικασίες. Αλλά τι να κάνουμε όταν υπάρχει αλληλεπίδραση με το εξωτερικό περιβάλλον; Για να μην γλιστρήσουμε σε μια σκοτεινή κόλαση από πατερίτσες και ποδήλατα, το Veeam τείνει να μην επανεφευρίσκει ήδη εφευρέσεις. Όποτε υπάρχει ένα έτοιμο API, μια ενσωματωμένη λειτουργία συστήματος, μια βιβλιοθήκη κ.λπ., θα δώσουμε προτίμηση σε έτοιμες επιλογές πριν ξεκινήσουμε να δημιουργούμε τις δικές μας έξυπνες λύσεις. Αν και υπάρχουν και πολλές από τις τελευταίες. Επομένως, κατά την ανάλυση των αρχείων καταγραφής, είναι σημαντικό να κατανοήσουμε ότι το μερίδιο του λέοντος των σφαλμάτων είναι μηνύματα από API τρίτων, κλήσεις συστήματος και άλλες βιβλιοθήκες. Σε αυτήν την περίπτωση, ο ρόλος του VBR καταλήγει στην προώθηση αυτών των σφαλμάτων στα αρχεία καταγραφής ως έχουν. Και το κύριο καθήκον του χρήστη είναι να μάθει να καταλαβαίνει ποια γραμμή είναι από ποιον και για τι είναι υπεύθυνο αυτό το "ποιος". Επομένως, εάν ο κωδικός σφάλματος από το αρχείο καταγραφής VBR σας μεταφέρει στη σελίδα MSDN, αυτό είναι φυσιολογικό και σωστό.
Όπως συμφωνήσαμε νωρίτερα: Το Veeam είναι μια εφαρμογή που βασίζεται σε SQL. Αυτό σημαίνει ότι όλες οι ρυθμίσεις, όλες οι πληροφορίες και όλα όσα είναι απαραίτητα για την κανονική λειτουργία αποθηκεύονται στη βάση δεδομένων του. Εξ ου και η απλή αλήθεια: ό,τι δεν υπάρχει στα αρχεία καταγραφής πιθανότατα βρίσκεται στη βάση δεδομένων. Αλλά αυτό δεν είναι πανάκεια: κάποια πράγματα δεν υπάρχουν στα τοπικά αρχεία καταγραφής των στοιχείων του Veeam, ούτε στη βάση δεδομένων του. Επομένως, πρέπει να μάθετε να μελετάτε τα αρχεία καταγραφής του κεντρικού υπολογιστή, τα αρχεία καταγραφής του τοπικού μηχανήματος και τα αρχεία καταγραφής όλων όσων εμπλέκονται στη διαδικασία δημιουργίας αντιγράφων ασφαλείας και επαναφοράς. Και συμβαίνει επίσης οι απαραίτητες πληροφορίες να μην βρίσκονται πουθενά. Αυτός είναι ο τρόπος.
Μερικά παραδείγματα τέτοιων API
Αυτή η λίστα δεν έχει σκοπό να είναι εξαντλητική, επομένως μην αναζητάτε την απόλυτη αλήθεια σε αυτήν. Σκοπός της είναι μόνο να δείξει τα πιο συνηθισμένα API και τεχνολογίες τρίτων που χρησιμοποιούνται στα προϊόντα μας.
Ας αρχίσουμε VMware.
Το πρώτο στη λίστα θα είναι API vSphereΧρησιμοποιείται για έλεγχο ταυτότητας, ανάγνωση της ιεραρχίας, δημιουργία και διαγραφή στιγμιότυπων, αίτημα πληροφοριών σχετικά με μηχανήματα και πολλά (πάρα πολλά) άλλα πράγματα. Η λειτουργικότητα της λύσης είναι πολύ ευρεία, επομένως μπορώ να προτείνω το VMware vSphere API Reference για την έκδοση σε όλους όσους το θέλουν. и Για πιο ενημερωμένες εκδόσεις, μπορείτε απλώς να αναζητήσετε τα πάντα στο Google.
API VIXΜαύρη μαγεία του υπερεπόπτη, για την οποία υπάρχει ξεχωριστός . VMware API για εργασία με αρχεία στον κεντρικό υπολογιστή χωρίς σύνδεση σε αυτά μέσω δικτύου. Μια έσχατη λύση όταν χρειάζεται να τοποθετήσετε ένα αρχείο σε έναν υπολογιστή με τον οποίο δεν υπάρχει καλύτερο κανάλι επικοινωνίας. Είναι δύσκολο και ταλαιπωρία αν το αρχείο είναι μεγάλο και ο κεντρικός υπολογιστής φορτωμένος. Αλλά ο κανόνας εδώ είναι ότι ακόμη και τα 56,6 Kbps είναι καλύτερα από 0 Kbps. Στο Hyper-V, κάτι παρόμοιο ονομάζεται PowerShell Direct. Αλλά αυτό ήταν μόνο πριν από την έλευση του
API Υπηρεσιών Ιστού vSpehere Ξεκινώντας με το vSphere 6.0 (περίπου, από τότε που αυτό το API εισήχθη για πρώτη φορά στην έκδοση 5.5) χρησιμοποιείται για να λειτουργεί με υπολογιστές-επισκέπτες και έχει ήδη αντικαταστήσει το 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, Out of Memory. Το γιατί και για ποιον έγινε αυτό είναι ένα μυστήριο τυλιγμένο στο σκοτάδι. Ωστόσο, η πλήρης λίστα των σφαλμάτων μπορεί να ληφθεί δωρεάν και χωρίς 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 από αυτήν, να τα αποκρυπτογραφούμε και να τα εισάγουμε ξανά. Ας είμαστε ειλικρινείς, δεν είναι η πιο συναρπαστική δραστηριότητα.
Windows API διαχείρισης αρχείων χρησιμοποιείται με κάθε δυνατό τρόπο κατά την εργασία με αρχεία. Δημιουργία αρχείων, διαγραφή, άνοιγμα για εγγραφή, εργασία με χαρακτηριστικά, κ.λπ., κ.λπ.
Τα προαναφερθέντα PowerShell Direct ως ανάλογο του VIX API στον κόσμο του Hyper-V. Δυστυχώς, δεν είναι τόσο ευέλικτο: πολλοί περιορισμοί στη λειτουργικότητα, δεν λειτουργεί με κάθε έκδοση του κεντρικού υπολογιστή και όχι με όλους τους φιλοξενούμενους.
RPC (Κλήση Απομακρυσμένης Διαδικασίας) Νομίζω ότι δεν υπάρχει ούτε ένα άτομο που έχει εργαστεί με Windows και δεν έχει δει σφάλματα σχετικά με το RPC. Παρά την κοινή παρανόηση, αυτό δεν είναι κάποιο μεμονωμένο πρωτόκολλο, αλλά οποιοδήποτε πρωτόκολλο πελάτη-διακομιστή που ικανοποιεί μια σειρά από παραμέτρους. Ωστόσο, εάν υπάρχει σφάλμα RPC στα αρχεία καταγραφής μας, στο 90% των περιπτώσεων θα είναι σφάλμα από το Microsoft RPC, το οποίο αποτελεί μέρος του DCOM (Distributed Component Object Model). Μπορείτε να βρείτε μια τεράστια ποσότητα τεκμηρίωσης σχετικά με αυτό το θέμα στο Διαδίκτυο, αλλά το μεγαλύτερο μέρος της είναι αρκετά ξεπερασμένο. Αλλά αν έχετε έντονη επιθυμία να μελετήσετε το θέμα, μπορώ να σας προτείνω τα άρθρα. , και μια πολύ μεγάλη λίστα .
Οι κύριοι λόγοι για τα σφάλματα RPC στα αρχεία καταγραφής μας είναι οι αποτυχημένες προσπάθειες αλληλεπίδρασης μεταξύ των στοιχείων VBR (για παράδειγμα, διακομιστής > διακομιστής μεσολάβησης) και, τις περισσότερες φορές, οφείλονται σε προβλήματα επικοινωνίας.
Η κορυφαία από όλες τις κορυφές είναι το σφάλμα Ο διακομιστής RPC δεν είναι διαθέσιμος (1722). Με απλά λόγια, ο υπολογιστής-πελάτης δεν μπόρεσε να δημιουργήσει μια σύνδεση με τον διακομιστή. Δεν υπάρχει μία μόνο απάντηση για το πώς και γιατί, αλλά αυτό είναι συνήθως ένα πρόβλημα με τον έλεγχο ταυτότητας ή με την πρόσβαση δικτύου στη θύρα 135. Το τελευταίο είναι τυπικό για υποδομές με δυναμική ανάθεση θύρας. Υπάρχει ακόμη και ένα Και η Microsoft έχει - για να βρείτε τις αιτίες της δυσλειτουργίας.
Το δεύτερο πιο συνηθισμένο σφάλμα: Δεν υπάρχουν άλλα διαθέσιμα τελικά σημεία από τον αντιστοιχιστή τελικών σημείων (1753). Ο υπολογιστής-πελάτης ή ο διακομιστής RPC δεν μπόρεσαν να αντιστοιχίσουν μια θύρα στον εαυτό τους. Συνήθως συμβαίνει όταν ο διακομιστής (στην περίπτωσή μας, ο φιλοξενούμενος υπολογιστής) είχε ρυθμιστεί να εκχωρεί δυναμικά θύρες από ένα στενό εύρος, το οποίο έχει λήξει. Και αν πάτε από την πλευρά του υπολογιστή-πελάτη (στην περίπτωσή μας, ο διακομιστής VBR), αυτό σημαίνει ότι το VeeamVssAgent μας είτε δεν ξεκίνησε είτε δεν καταχωρήθηκε ως διεπαφή RPC. Σε αυτό το θέμα, υπάρχει επίσης .
Λοιπόν, για να συμπληρώσουμε τα 3 κορυφαία σφάλματα RPC, ας θυμηθούμε ότι η κλήση της συνάρτησης RPC απέτυχε (1726). Εμφανίζεται ότι η σύνδεση έχει δημιουργηθεί, αλλά τα αιτήματα RPC δεν υποβάλλονται σε επεξεργασία. Για παράδειγμα, ζητάμε πληροφορίες σχετικά με την κατάσταση του VSS (τι γίνεται αν δημιουργείται ένα σκιώδες αντίγραφο εκεί αυτή τη στιγμή και προσπαθούμε να εισέλθουμε σε αυτό) και σε απάντηση λαμβάνουμε σιωπή και αγνόηση.
Windows API δημιουργίας αντιγράφων ασφαλείας ταινίας χρειαζόταν να λειτουργεί με βιβλιοθήκες ταινιών ή μονάδες δίσκου. Όπως ανέφερα στην αρχή: το να γράφουμε τους δικούς μας οδηγούς και στη συνέχεια να πρέπει να υποφέρουμε με την υποστήριξη κάθε συσκευής δεν είναι διασκεδαστικό για εμάς. Γι' αυτό το Vim δεν έχει κανέναν δικό του οδηγό. Όλα γίνονται μέσω του τυπικού API, το οποίο υποστηρίζεται από τους ίδιους τους προμηθευτές υλικού. Είναι πολύ πιο λογικό, έτσι δεν είναι;
SMB / CIFS Όλοι τα γράφουν από συνήθεια, αν και δεν θυμούνται όλοι ότι το CIFS (Common Internet File System) είναι απλώς μια ιδιόκτητη έκδοση του SMB (Server Message Block). Δεν υπάρχει λοιπόν τίποτα κακό στη γενίκευση αυτών των εννοιών. Το Samba, από την άλλη πλευρά, είναι LinuxΕίναι μια υλοποίηση Unix και έχει τις δικές της ιδιαιτερότητες, αλλά παρεκκλίνω από το θέμα. Αυτό που είναι σημαντικό εδώ είναι ότι όταν το Veeam ζητά να γράψει κάτι σε μια διαδρομή UNC (κατάλογο διακομιστή), ο διακομιστής χρησιμοποιεί μια ιεραρχία προγραμμάτων οδήγησης συστήματος αρχείων, συμπεριλαμβανομένων των mup και mrxsmb, για να γράψει στον κοινόχρηστο δίσκο. Κατά συνέπεια, αυτά τα προγράμματα οδήγησης θα δημιουργήσουν επίσης σφάλματα.
Δεν υπάρχει τρόπος να το κάνεις χωρίς αυτό API WinsockΑν χρειάζεται να γίνει κάτι μέσω δικτύου, το 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
