Kesalahan VDDK dengan wajah manusia



Keindahan dan kengerian kesalahan VDDK adalah, di satu sisi, sangat jelas di mana kerusakannya, dan di sisi lain, sama sekali tidak dapat dipahami mengapa dan bagaimana memperbaikinya sekarang. Ini seperti fungsi panggilan RPC gagal di dunia Windows.



Meski tidak semuanya begitu buruk, tentu saja. Beberapa kesalahan memiliki penyebab dan penanganan yang sangat spesifik. Dan beberapa - daftar panjang penyebab paling umum dan pilihan untuk memperbaikinya.



Dukungan Teknis Veeam kami, tentu saja, mengumpulkan pengetahuan tersebut, dan hari ini kami akan melihat entri mereka. Oleh karena itu, dengan senang hati saya mempersembahkan kepada Anda kesalahan VDDK paling umum dan metode untuk menghilangkannya.

 

Kesalahan VDDK. Apa itu dan bagaimana mendapatkannya?



 Seperti yang bisa Anda tebak dari namanya, ini adalah beberapa jenis masalah pada level VDDK Api (Virtual Disk Development Kit) - cara terbaik untuk berinteraksi dengan infrastruktur vSphere. Tidak masalah apakah itu host ESXi yang terpisah atau vCenter yang luas, tetapi jika kita perlu menulis atau membaca sesuatu dari infrastruktur kita, cara terbaik untuk ini adalah VDDK gratis.



Untuk menyederhanakan sebanyak mungkin, interaksi ini terlihat seperti ini: server Veeam ingin, misalnya, membaca sesuatu dari host (atau menulis) dan mengirimkannya permintaan. Panggilan baca dibuat menunjukkan dari disk mana, seberapa banyak Anda ingin membaca, dari mana offset dan ke buffer mana dalam memori. Atau tulis, dengan cara yang sama, dari buffer yang ditentukan. Itu mudah.



Tapi ini di dunia yang sempurna. 



Dalam kehidupan nyata, terkadang kesalahan terjadi di sepanjang jalan algoritme sederhana ini, yang karenanya tidak mungkin untuk menyelesaikan permintaan. Dan alih-alih respons yang diharapkan, sebuah nomor kesalahan datang kepada kami, yang dicatat dengan cermat di log.



 Hari ini kita akan berbicara tentang kesalahan yang paling umum terjadi.

 

Penafian penting!

 

Tidak yakin - jangan! Jangan tekan dan jangan sentuh apapun! Menelepon atau menulis ke dukungan Veeam selalu lebih baik daripada bereksperimen dengan produk Anda. Untungnya, dukungan kami berbahasa Rusia dan sangat teknis.



Dengan sedikit keraguan, telepon dan tanyakan: "Saya punya masalah seperti itu, saya menemukan solusi ini di jaringan, apakah ini akan membantu saya menyelesaikannya?" - normal dan benar. Apa yang tidak normal dan tidak benar adalah tidak yakin dengan tindakan Anda untuk melakukan banyak hal, dan kemudian meminta untuk memulihkan semuanya dari reruntuhan dalam lima menit, dan agar tidak ada yang hilang.



Ya, kami, tentu saja, akan membantu dalam kasus ini, tetapi pertempuran terbaik adalah pertempuran yang tidak ada. Oleh karena itu, selalu mencoba untuk mengevaluasi tindakan Anda secara kritis, dan semua waktu kerja yang besar.

 

VDDK error 1: Error tidak diketahui



Faktanya, kami memiliki seluruh artikel HF tentang kesalahan ini . Dan, seperti yang dikatakan, paling sering kesalahan ini terjadi jika Anda menginstal terlalu banyak penghitung kinerja - dan mengunduh tambalan dari VMware yang akan memperbaiki semuanya untuk Anda.



Di satu sisi, bahkan tidak ada yang perlu dikomentari. Ini masalahnya, berikut adalah uraiannya (meskipun tidak terlalu jelas), dan yang terpenting, berikut tautan ke obatnya. Namun, tidak semuanya sesederhana itu. Menurut pengamatan kami, kesalahan ini dapat terjadi tidak hanya karena masalah yang membosankan dengan penghitung, tetapi juga karena:



  1. VMDK . , , . โ€” โ€” . , . , , .

  2. datastore. . , .

  3. HBA . , . . ? 

  4. , : ESXi vCenter.



 Well, well, saya berhasil melakukannya, katamu. Lalu apa? Bagaimana memahami bahwa sudah waktunya untuk segera mencari disk baru - atau apakah cukup untuk memasang tambalan dan membuang napas?



Dan saya akan menjawab Anda - simpan serangkaian tes sederhana yang akan membantu Anda membuat keputusan yang tepat jika terjadi sesuatu.



  • Kami meluncurkan Storage vMotion atau cukup mengkloning mesin yang mencurigakan ke datastore lain, lalu mencoba memulai pencadangan. Jika kloning gagal, pasti ada masalah di suatu tempat di subsistem disk. Mode paranoia secara maksimal - dan periksa semuanya mulai dari drive hingga pengontrol.



    Jika berhasil dikloning dan dicadangkan, itu berarti VMDK rusak, karena selama kloning VMware membuat ulang kontennya, dan sekarang sudah pasti tidak ada kesalahan.   

  • , . , . ยซ โ€” ยป .

  • , , , โ€” VMware.

  • , . , . 



VDDK error 2: Value: 0x0000000000000002 



Hampir selalu sejalan dengan kesalahan VDDK 1. Menurut statistik kami, munculnya kesalahan biasanya dikaitkan dengan versi tertentu dari bundel vCenter / ESXi, jadi saran terbaik di sini adalah meningkatkan ke setidaknya versi 6.7. Dan lebih baik dan 7.0.



Jika tidak membantu, lanjutkan ke rencana B. 



Kesalahan itu sendiri muncul saat host ESXi kehabisan memori yang dialokasikan untuk buffer pembacaan NFC. Secara default, Veeam beroperasi dalam mode baca NBD / NFC asynchronous, yang dalam kondisi normal mungkin memerlukan perluasan buffer ini. Tapi ini tidak selalu terjadi. Oleh karena itu, untuk menonaktifkan mode ini, ada kunci khusus:



Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1


Setelah membuatnya, Anda perlu memulai ulang Layanan Pencadangan Veeam dan bersiap untuk kinerja yang telah merosot sekitar 10%.



Opsi lainnya adalah masuk dari sisi host dan memulai ulang agen manajemen:



/etc/init.d/hostd restart
/etc/init.d/vpxa restart


Prosedurnya dijelaskan secara detail di KB dari VMware , jadi kami tidak akan menulis ulang.



Dan serangkaian opsi standar yang tidak akan berlebihan untuk dipilah selama proses diagnostik:



  • Migrasikan mesin yang mengalami kesalahan ke host lain.
  • Coba mode Transport lain - HotAdd dengan proxy virtual atau DirectSAN.


VDDK error 3: Salah satu parameter tidak valid



 Kesalahan yang hampir selalu terjadi saat menggunakan mode Peralatan Virtual (alias mode HotAdd).



Tidak ada yang istimewa untuk diceritakan di sini, saya hanya akan memberikan tautan ke dua KB kami, di mana banyak opsi dijelaskan, dan bahkan jika Anda segera datang untuk mendukung, Anda akan diminta untuk melakukan semua yang tertulis di sana.



KB1218 - Gambaran umum tentang kemungkinan masalah dan metode penghapusannya.



KB1332 - Jika server Veeam Anda bertindak sebagai proxy untuk mode HotAdd

 

VDDK error 13: Anda tidak memiliki hak akses ke file ini



Dan untuk kasus ini kami memiliki KB2008 . Ya, ada banyak opsi untuk menghilangkan masalah ini, tetapi kesalahan seperti itu. Hampir tidak mungkin untuk mengatakan dengan tegas apa yang sebenarnya terjadi dalam kasus Anda, jadi Anda perlu mengambil dan mengulang seluruh daftar. 



Apa yang ingin saya sampaikan sebagai tambahan. Berhati-hatilah dengan bagian Pemecahan Masalah Tambahan. Ya, ada yang tertulis, mungkin terlalu jelas untuk banyak hal. Tetapi bahkan kata-kata hampa seperti itu luput dari perhatian para profesional paling profesional. Seringkali ada kasus ketika, setelah seminggu, mencoba menyelesaikan semuanya sendiri, mereka datang untuk mendukung hanya untuk mengetahui bahwa mereka belum membaca daftar persyaratan teknis dengan cermat, atau sesuatu seperti itu. Dan sayang sekali untuk waktu yang dihabiskan.



Dan dua tip untuk sepanjang masa:



  • Veeam proxy , UUID . - , . , , . 
  • ( โ€” ), , VDDK .
 

 VDDK error 18000: Cannot connect to the host 



Dalam kebanyakan kasus, kesalahan ini terletak pada bug di VDDK itu sendiri. Secara khusus, perpustakaan gvmomi.dll yang harus disalahkan. Dan dia hanya menunjukkan dirinya di bawah beban berat. Misalnya, ketika banyak mesin dicadangkan secara paralel, salah satu fungsi menjadi 0, dan pustaka mungkin runtuh. Dan kemudian yang lainnya jatuh.



Begitulah kisah sedihnya. 



Tetapi hal terburuk dalam cerita ini adalah tidak mungkin untuk mereproduksi kondisi bug secara akurat. Inilah yang disebut penguji sebagai bug mengambang. Oleh karena itu, tidak mungkin untuk mengatakan dengan tepat berapa banyak mesin paralel yang menyebabkan crash.



Namun, menurut catatan rilis resmibug ini telah diperbaiki sepenuhnya. Jadi, jalan keluar yang tepat adalah memperbarui host Anda. Tetapi jika karena alasan tertentu tidak mungkin melakukan ini, satu-satunya cara kami dapat membantu adalah menyarankan untuk mengurangi jumlah mesin yang diproses secara bersamaan.



Tidak ada jalan lain.



 

Kesalahan VDDK 14008: Server yang ditentukan tidak dapat dihubungi



 Jadi, jika masalah ini menimpa Anda, maka hal pertama yang harus dilakukan adalah memeriksa jaringan. Kemungkinan besar, komunikasi antara vCenter dan proxy Veeam terputus. Periksa apakah semua port terbuka dan dapat diakses, jika semua nama DNS diselesaikan dengan benar ke alamat IP yang diharapkan. Selain itu, Anda perlu memeriksa proxy tertentu yang terlibat dalam pekerjaan yang gagal, dan bukan yang berdiri di sebelahnya (ada beberapa kasus).

95% kasus dengan kesalahan ini ditutup dengan tanda "Masalah dengan DNS / port di infrastruktur klien".



Oleh karena itu, sekali lagi saya mendorong Anda untuk memeriksa dengan sangat hati-hati jika server DNS yang benar ditunjukkan di mana-mana, jika ada port yang tertutup dan di mana IP nama FQDN diselesaikan.



 Di versi VDDK yang lebih lama, ada kesalahan serupa saat menggunakan port non-default untuk bekerja dengan vCenter, yang menyumbang 5% sisanya, tetapi sekarang VMware telah menyembunyikan KB dengan deskripsinya, yang mungkin berarti KB tidak lagi relevan. Tetapi Anda dapat mencarinya di arsip Internet di 2108658 (Pencadangan gagal saat port non-default ditentukan untuk VMware vCenter Server).

 

Kesalahan VDDK 14009: Server menolak koneksi



 Dan kesalahan terakhir di bagian atas hari ini adalah Server menolak koneksi. Semuanya benar-benar basi di sini: sesuatu mencegah koneksi antara host dan proxy. Dalam banyak kasus, firewall adalah penyebabnya. Tapi - poin halus - bukan karena port tertutup, tetapi karena penundaan yang diperkenalkan. Jadi, pertama-tama, kami memeriksa keterbukaan port 443, dan kemudian kami melihat batas waktu.

Jika kedua opsi tidak memberikan apa-apa, pergi ke dukungan. Kami harus memeriksa tuan rumah itu sendiri. Mungkin dia terlalu sibuk dan tidak punya waktu untuk merespon tepat waktu, dan mungkin hal lain.

 

Dan terakhir, beberapa tautan berguna:






All Articles