Kami meneruskan rendaman kami ke dalam dunia meneka yang menarik ... menyelesaikan masalah dengan log. DALAM kami bersetuju dengan maksud istilah asas dan melihat struktur keseluruhan Veeam sebagai satu aplikasi dengan sebelah mata. Tugas untuk yang ini adalah untuk mengetahui bagaimana fail log dibentuk, jenis maklumat yang dipaparkan di dalamnya dan mengapa ia kelihatan seperti rupa.
Pada pendapat anda, apakah "log" ini? Menurut kebanyakan orang, log mana-mana aplikasi harus diberikan peranan sejenis entiti mahakuasa yang kebanyakan masa tumbuh-tumbuhan di suatu tempat di halaman belakang, tetapi pada masa yang tepat muncul entah dari mana dalam perisai bersinar dan menyelamatkan semua orang. Iaitu, ia harus mengandungi segala-galanya, dari sedikit kesilapan dalam setiap komponen kepada transaksi pangkalan data individu. Dan supaya selepas ralat itu segera ditulis bagaimana lagi untuk memperbaikinya. Dan semua ini sepatutnya muat dalam beberapa megabait, tidak lebih. Ia hanya teks! Fail teks tidak boleh mengambil berpuluh-puluh gigabait, saya mendengarnya di suatu tempat!
Jadi balak
Dalam dunia nyata, log hanyalah arkib maklumat diagnostik. Dan apa yang perlu disimpan di sana, di mana untuk mendapatkan maklumat untuk penyimpanan dan seberapa terperinci ia sepatutnya, terpulang kepada pembangun sendiri untuk membuat keputusan. Seseorang mengikut laluan minimalisme dengan menyimpan rekod tahap HIDUP/MATI, dan seseorang rajin mengumpul segala yang boleh dicapai. Walaupun terdapat juga pilihan perantaraan dengan keupayaan untuk memilih apa yang dipanggil Tahap Pembalakan, apabila anda sendiri menunjukkan betapa terperinci maklumat yang anda ingin simpan dan berapa banyak ruang cakera tambahan yang anda ada =) VBR mempunyai enam tahap sedemikian, dengan cara itu. Dan, percayalah, anda tidak mahu melihat apa yang berlaku dengan pengelogan paling terperinci dengan ruang kosong pada cakera anda.
baiklah. Kami secara kasarnya memahami apa yang ingin kami simpan, tetapi persoalan yang sah timbul: dari mana untuk mendapatkan maklumat ini? Sudah tentu, kita membentuk sebahagian daripada peristiwa untuk log diri kita oleh proses dalaman kita. Tetapi apa yang perlu dilakukan apabila terdapat interaksi dengan persekitaran luaran? Untuk tidak tergelincir ke dalam neraka jahanam tongkat dan basikal, Veeam cenderung untuk tidak mencipta ciptaan yang telah dicipta. Setiap kali terdapat API siap pakai, fungsi terbina dalam, perpustakaan, dll., kami akan memberi keutamaan kepada pilihan siap sedia sebelum mula memagar peralatan kami. Walaupun yang terakhir ini juga sudah memadai. Oleh itu, apabila menganalisis log, adalah penting untuk memahami bahawa bahagian terbesar ralat jatuh pada mesej daripada API pihak ketiga, panggilan sistem dan perpustakaan lain. Dalam kes ini, peranan VBR turun untuk memajukan ralat ini ke fail log sebagaimana adanya. Dan tugas utama pengguna adalah untuk belajar memahami baris mana dari siapa, dan apa "siapa" ini bertanggungjawab. Jadi jika kod ralat daripada log VBR membawa anda ke halaman MSDN, itu tidak mengapa dan betul.
Seperti yang kita bersetuju sebelum ini: Veeam ialah aplikasi berasaskan SQL yang dipanggil. Ini bermakna semua tetapan, semua maklumat dan secara umum semua yang hanya diperlukan untuk berfungsi normal - semuanya disimpan dalam pangkalan datanya. Oleh itu kebenaran mudah: apa yang tidak ada dalam log kemungkinan besar dalam pangkalan data. Tetapi ini bukan peluru perak sama ada: beberapa perkara tidak ada dalam log tempatan komponen Veeam, mahupun dalam pangkalan datanya. Oleh itu, anda perlu belajar bagaimana untuk mengkaji log hos, log mesin tempatan dan log semua yang terlibat dalam proses sandaran dan pemulihan. Dan ia juga berlaku bahawa maklumat yang diperlukan tidak tersedia di mana-mana sama sekali. Itulah caranya.
Beberapa contoh API tersebut
Senarai ini tidak bertujuan untuk menjadi sangat lengkap, jadi tidak perlu mencari kebenaran muktamad di dalamnya. Tujuannya hanya untuk menunjukkan API dan teknologi pihak ketiga yang paling biasa digunakan dalam produk kami.
Mari bermula dengan VMware.
Pertama dalam senarai akan menjadi vSphere API. Digunakan untuk pengesahan, membaca hierarki, mencipta dan memadam syot kilat, meminta maklumat tentang mesin dan banyak lagi (sangat banyak) lagi. Fungsi penyelesaian adalah sangat luas, jadi saya boleh mengesyorkan Rujukan API VMware vSphere untuk versi ΠΈ . Untuk lebih banyak versi semasa, semuanya hanya google.
API VIX. Sihir hitam hypervisor, yang mana terdapat yang berasingan . API VMware untuk bekerja dengan fail pada hos tanpa menyambungkannya melalui rangkaian. Satu varian pilihan terakhir apabila anda perlu meletakkan fail dalam mesin yang tidak mempunyai saluran komunikasi yang lebih baik. Ia adalah kesakitan dan penderitaan jika fail besar dan hos dimuatkan. Tetapi di sini peraturan berfungsi bahawa walaupun 56,6 Kb / s lebih baik daripada 0 Kb / s. Dalam Hyper-V, perkara ini dipanggil PowerShell Direct. Tetapi itu hanya sebelum ini
API Perkhidmatan Web vSpehere Bermula dari vSphere 6.0 (kira-kira, sejak API ini mula-mula diperkenalkan pada versi 5.5) ia digunakan untuk berfungsi dengan mesin tetamu dan telah menggantikan VIX hampir di mana-mana. Sebenarnya, ini adalah API lain untuk mengurus vSphere. Bagi yang berminat, saya sarankan untuk belajar manual.
VDDK (Kit Pembangunan Cakera Maya). Perpustakaan, yang sebahagiannya dibincangkan dalam ini . Digunakan untuk membaca cakera maya. Suatu ketika dahulu ia adalah sebahagian daripada VIX, tetapi lama kelamaan ia telah dipindahkan ke dalam produk yang berasingan. Tetapi sebagai pewaris, ia menggunakan kod ralat yang sama seperti VIX. Tetapi atas sebab tertentu, tiada perihalan tentang ralat ini dalam SDK itu sendiri. Oleh itu, didapati secara empirik bahawa ralat VDDK dengan kod lain hanyalah terjemahan daripada kod binari kepada perpuluhan. Ia terdiri daripada dua bahagian - separuh pertama ialah maklumat tidak berdokumen tentang konteks, dan bahagian kedua ialah ralat VIX / VDDK tradisional. Sebagai contoh, jika kita melihat:
VDDK error: 21036749815809.Unknown error
Kemudian kami dengan berani menukar ini kepada hex dan mendapatkan 132200000001. Kami hanya membuang permulaan yang tidak bermaklumat 132200, dan selebihnya akan menjadi kod ralat kami (VDDK 1: Ralat tidak diketahui). Mengenai ralat VDDK yang paling kerap, baru-baru ini terdapat ralat berasingan .
Sekarang mari kita lihat Windows.
Di sini, semua yang paling perlu dan penting bagi kami boleh didapati dalam piawaian Penonton Acara. Tetapi ada satu tangkapan: mengikut tradisi yang lama, Windows tidak mencatatkan teks penuh ralat, tetapi hanya nombornya. Contohnya, ralat 5 ialah "Akses ditolak", dan 1722 ialah "Pelayan RPC tidak tersedia", dan 10060 ialah "Sambungan tamat masa". Sudah tentu, sangat bagus jika anda mengingati yang paling terkenal, tetapi bagaimana dengan yang tidak kelihatan sehingga kini?
Dan supaya kehidupan tidak kelihatan seperti madu sama sekali, ralat juga disimpan dalam bentuk heksadesimal, dengan awalan 0x8007. Sebagai contoh, 0x8007000e sebenarnya ialah 14, Habis Ingatan. Mengapa dan untuk siapa ini dilakukan adalah misteri yang diselubungi kegelapan. Walau bagaimanapun, senarai lengkap ralat boleh dimuat turun secara percuma dan tanpa SMS daripada .
Ngomong-ngomong, kadangkala terdapat awalan lain, bukan hanya 0x8007. Dalam situasi yang menyedihkan, untuk memahami HRESULT ("kependalian keputusan"), anda perlu menyelidiki lebih mendalam lagi untuk pemaju. Dalam kehidupan biasa, saya tidak menasihati anda untuk melakukan ini, tetapi jika anda tiba-tiba menekan dinding atau hanya ingin tahu, kini anda tahu apa yang perlu dilakukan.
Tetapi rakan-rakan di Microsoft berasa kasihan sedikit dan menunjukkan kepada dunia satu utiliti . Ini adalah sebahagian kecil kegembiraan konsol yang boleh menterjemahkan kod ralat kepada manusia tanpa menggunakan Google. Ia berfungsi seperti ini.
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"Persoalan yang sah timbul: mengapa kita tidak segera menulis penyahsulitan pada log, tetapi meninggalkan kod misteri ini? Jawapannya ada dalam aplikasi pihak ketiga. Apabila anda menarik beberapa panggilan WinAPI sendiri, tidak sukar untuk menguraikan responsnya, kerana terdapat panggilan WinAPI khas untuk ini. Tetapi seperti yang telah disebutkan, semua yang hanya datang kepada kami sebagai balasan akan masuk ke dalam log kami. Dan di sini, untuk menyahsulitnya, seseorang perlu sentiasa memantau aliran kesedaran ini, mengeluarkan kepingan dengan ralat Windows daripadanya, menyahsulitnya dan menampalnya kembali. Sejujurnya, bukan aktiviti yang paling menarik.
API Pengurusan Fail Windows digunakan dalam setiap cara yang mungkin apabila bekerja dengan fail. Mencipta fail, memadam, membuka untuk menulis, bekerja dengan atribut, dan sebagainya dan sebagainya.
yang disebut di atas PowerShell Direct sebagai analog API VIX dalam dunia Hyper-V. Malangnya, tidak begitu fleksibel: banyak sekatan pada fungsi, ia tidak berfungsi dengan setiap versi hos dan bukan dengan semua tetamu.
RPC (Panggilan Prosedur Jauh) Saya rasa tidak ada seorang pun yang pernah bekerja dengan WIndows yang tidak melihat ralat berkaitan RPC. Walaupun terdapat tanggapan salah yang popular, ini bukan satu protokol, tetapi mana-mana protokol pelayan-pelanggan yang memenuhi beberapa parameter. Walau bagaimanapun, jika terdapat ralat RPC dalam log kami, 90% daripada masa itu ia akan menjadi ralat daripada Microsoft RPC, yang merupakan sebahagian daripada DCOM (Model Objek Komponen Teragih). Anda boleh menemui sejumlah besar dokumentasi mengenai topik ini di internet, tetapi bahagian terbesarnya sudah lapuk. Tetapi jika ada keinginan yang kuat untuk mengkaji topik itu, maka saya boleh mengesyorkan artikel , dan senarai panjang .
Punca utama ralat RPC dalam log kami adalah percubaan yang gagal untuk berkomunikasi antara komponen VBR (pelayan > proksi, contohnya) dan paling kerap disebabkan masalah komunikasi.
Bahagian atas teratas di antara semua bahagian atas ialah ralat Pelayan RPC tidak tersedia (1722). Secara ringkas, pelanggan tidak dapat mewujudkan sambungan dengan pelayan. Bagaimana dan mengapa - tiada jawapan tunggal, tetapi biasanya ia adalah masalah dengan pengesahan atau dengan akses rangkaian ke port 135. Yang terakhir adalah tipikal untuk infrastruktur dengan penugasan port dinamik. Mengenai topik ini, ada juga . Dan Microsoft telah untuk mencari punca kegagalan.
Ralat kedua paling popular: Tiada lagi titik akhir tersedia daripada pemeta titik akhir (1753). Klien atau pelayan RPC gagal memberikan port kepada dirinya sendiri. Biasanya berlaku apabila pelayan (dalam kes kami, mesin tetamu) telah dikonfigurasikan untuk memperuntukkan port secara dinamik daripada julat sempit yang telah tamat. Dan jika anda log masuk dari sisi klien (dalam kes kami, pelayan VBR), ini bermakna VeeamVssAgent kami sama ada tidak bermula atau tidak didaftarkan sebagai antara muka RPC. Terdapat juga mengenai topik ini .
Nah, untuk melengkapkan ralat 3 RPC Teratas, mari kita ingat panggilan fungsi RPC gagal (1726). Muncul jika sambungan telah diwujudkan, tetapi permintaan RPC tidak diproses. Sebagai contoh, kami meminta maklumat tentang status VSS (tiba-tiba sekarang lombong bayangan sedang dibuat di sana, dan kami cuba mendaki), dan sebagai tindak balas kepada kami, senyap dan abaikan.
API Sandaran Pita Windows diperlukan untuk bekerja dengan perpustakaan pita atau pemacu. Seperti yang saya nyatakan pada mulanya: kami tidak senang menulis pemandu kami sendiri dan kemudian menderita dengan sokongan setiap peranti. Oleh itu, vim tidak mempunyai pemacu sendiri. Semuanya melalui API standard, sokongan yang dilaksanakan oleh vendor perkakasan itu sendiri. Jadi lebih logik, bukan?
SMB / CIFS Di luar kebiasaan, semua orang menulisnya bersebelahan, walaupun tidak semua orang ingat bahawa CIFS (Common Internet File System) hanyalah versi peribadi SMB (Server Message Block). Jadi tidak ada salahnya untuk menggeneralisasikan konsep-konsep ini. Samba sudah pun menjadi pelaksanaan LinuxUnix, dan ia mempunyai keistimewaannya sendiri, tetapi saya menyimpang. Apa yang penting di sini: apabila Veeam meminta untuk menulis sesuatu ke laluan UNC (serverdirectory), pelayan menggunakan hierarki pemacu sistem fail, termasuk mup dan mrxsmb, untuk menulis kepada bola. Sehubungan itu, pemandu ini juga akan menjana ralat.
Tidak boleh melakukannya tanpa API Winsock. Jika sesuatu perlu dilakukan melalui rangkaian, VBR berfungsi melalui Windows Socket API, yang lebih dikenali sebagai Winsock. Jadi jika kita melihat sekumpulan IP:Port dalam log, ini dia. Dokumentasi rasmi mempunyai senarai yang baik kemungkinan .
yang disebut di atas WMI (Windows Management Instrumentation) ialah sejenis API yang maha kuasa untuk mengurus segala-galanya dan semua orang di dunia Windows. Sebagai contoh, apabila bekerja dengan Hyper-V, hampir semua permintaan kepada hos melaluinya. Dalam satu perkataan, perkara itu benar-benar tidak boleh ditukar ganti dan sangat berkuasa dalam keupayaannya. Dalam percubaan untuk membantu mengetahui di mana dan apa yang rosak, alat WBEMtest.exe terbina dalam banyak membantu.
Dan terakhir dalam senarai, tetapi sama sekali tidak penting - VSS (Storan Bayang Jilid). Topik ini tidak habis-habis dan misteri kerana banyak dokumentasi telah ditulis di atasnya. Shadow Copy paling mudah difahami sebagai jenis syot kilat khas, yang pada dasarnya adalah. Terima kasih kepadanya, anda boleh membuat sandaran aplikasi-konsisten dalam VMware, dan hampir semuanya dalam Hyper-V. Saya mempunyai rancangan untuk membuat artikel yang berasingan dengan sedikit penekanan pada VSS, tetapi buat masa ini anda boleh cuba membaca . Hanya berhati-hati, kerana. cuba memahami VSS dalam sekelip mata boleh menyebabkan kecederaan otak.
Mengenai ini, mungkin, kita boleh berhenti. Saya menganggap tugas menerangkan perkara yang paling asas telah selesai, jadi dalam bab seterusnya kita sudah akan melihat log. Tetapi jika anda mempunyai sebarang soalan, jangan ragu untuk bertanya kepada mereka dalam komen.
Sumber: www.habr.com