إن جمال ورعب أخطاء VDDK هو أنه ، من ناحية ، من الواضح تمامًا مكان كسرها ، ومن ناحية أخرى ، من غير المفهوم تمامًا سبب وكيفية إصلاحها الآن. يبدو الأمر وكأن وظيفة استدعاء RPC فشلت في عالم Windows.
على الرغم من أن كل شيء ليس سيئًا للغاية ، بالطبع. بعض الأخطاء لها أسباب وعلاجات محددة للغاية. والبعض - قائمة معروفة منذ فترة طويلة من الأسباب والخيارات الأكثر شيوعًا لتصحيحها.
وبطبيعة الحال ، فإن الدعم الفني لـ Veeam لدينا يجمع هذه المعرفة ، واليوم سوف نلقي نظرة على مشاركاتهم. لذلك ، إنه لمن دواعي سروري البالغ أن أقدم لكم أهم أخطاء VDDK الأكثر شيوعًا وطرق التخلص منها.
أخطاء VDDK. ما هو وكيف يتم الحصول عليها؟
كما قد تتخيل من الاسم ، فهذه بعض المشاكل على مستوى VDDK Api (Virtual Disk Development Kit) - أفضل طريقة للتفاعل مع البنية التحتية vSphere. لا يهم إذا كان مضيف ESXi منفصل أو vCenter مترامي الأطراف ، ولكن إذا احتجنا إلى كتابة أو قراءة شيء ما من بنيتنا التحتية ، فإن أفضل طريقة للقيام بذلك هي VDDK المجاني.
للتبسيط قدر الإمكان ، يبدو هذا التفاعل كما يلي: يريد خادم Veeam ، على سبيل المثال ، قراءة شيء ما من المضيف (أو الكتابة) وإرسال طلب إليه. يتم إنشاء مكالمة قراءة تشير إلى أي قرص ، والمقدار الذي تريد قراءته ، ومن أي إزاحة وإلى أي مخزن مؤقت في الذاكرة. أو اكتب ، بالمثل ، من المخزن المؤقت المحدد. انه سهل.
لكن هذا في عالم مثالي.
في الحياة الواقعية ، تحدث أخطاء في بعض الأحيان على طول طريق هذه الخوارزمية البسيطة ، بسبب استحالة إكمال الطلب. وبدلاً من الاستجابة المتوقعة ، يأتي إلينا رقم خطأ يتم تسجيله بعناية في السجلات.
اليوم سنتحدث عن أكثر هذه الأخطاء شيوعًا.
إخلاء مهم!
لست متأكدا - لا تفعل! لا تضغط ولا تلمس أي شيء على الإطلاق! يعد الاتصال أو الكتابة إلى دعم Veeam دائمًا أفضل من تجربة منتجك. لحسن الحظ ، دعمنا يتحدث الروسية وتقني للغاية.
عند أدنى شك ، اتصل واسأل: "لدي مثل هذه المشكلة ، لقد وجدت هذا الحل على الشبكة ، هل سيساعدني في حلها؟" - عادي وصحيح. ما هو غير طبيعي وغير صحيح هو عدم التأكد من أفعالك للقيام بالكثير من الأشياء ، ثم اطلب استعادة كل شيء من الأنقاض في خمس دقائق ، حتى لا يضيع شيء.
نعم ، بالطبع ، سنساعد في هذه الحالة ، لكن أفضل معركة هي تلك التي لم تكن موجودة. لذلك ، حاول دائمًا تقييم أفعالك بشكل نقدي ، وكل وقت التشغيل الكبير.
خطأ VDDK 1: خطأ غير معروف
في الواقع ، لدينا مقال HF كامل حول هذا الخطأ . وكما هو مذكور ، يحدث هذا الخطأ غالبًا إذا كان لديك عدد كبير جدًا من عدادات الأداء المثبتة - وقم بتنزيل تصحيح من برنامج VMware الذي سيصلح كل شيء من أجلك.
من ناحية أخرى ، لا يوجد شيء للتعليق عليه. ها هي المشكلة ، وإليك وصفًا (حتى لو لم يكن واضحًا جدًا) ، والأهم من ذلك ، هذا رابط إلى الدواء. ومع ذلك ، ليس كل شيء بهذه البساطة. وفقًا لملاحظاتنا ، يمكن أن يحدث هذا الخطأ ليس فقط بسبب مشكلة مملة في العدادات ، ولكن أيضًا بسبب:
- VMDK . , , . — — . , . , , .
- datastore. . , .
- HBA . , . . ?
- , : ESXi vCenter.
حسنًا ، حسنًا ، لقد استوعبت الأمر ، كما تقول. ثم ماذا؟ كيف نفهم أن الوقت قد حان للركض بشكل عاجل للحصول على أقراص جديدة - أو هل يكفي وضع رقعة وزفير؟
وسأجيب عليك - احتفظ بمجموعة من الاختبارات البسيطة التي ستساعدك على اتخاذ القرار الصحيح إذا حدث شيء ما.
- نقوم بتشغيل Storage vMotion أو ببساطة استنساخ جهاز مشبوه إلى مخزن بيانات آخر ، ثم نحاول بدء نسخة احتياطية. إذا فشل الاستنساخ ، فهناك بالتأكيد مشكلة في مكان ما في نظام القرص الفرعي. وضع البارانويا إلى الحد الأقصى - وتحقق من كل شيء من الأقراص إلى وحدات التحكم.
إذا تم استنساخه وحفظه بنجاح ، فهذا يعني أن VMDK قد تعرض للتلف ، لأنه أثناء الاستنساخ يقوم VMware بإعادة إنشاء محتوياته ، والآن لا توجد أخطاء بالتأكيد هناك.
- , . , . « — » .
- , , , — VMware.
- , . , .
VDDK error 2: Value: 0x0000000000000002
يسير دائمًا جنبًا إلى جنب مع خطأ VDDK 1. وفقًا لإحصاءاتنا ، يرتبط ظهور الخطأ عادةً بإصدارات معينة من حزمة vCenter / ESXi ، لذا فإن أفضل نصيحة هنا هي الترقية إلى الإصدار 6.7 على الأقل. وأفضل 7.0.
إذا لم يساعد ذلك ، فانتقل إلى الخطة ب.
يظهر الخطأ نفسه عند نفاد ذاكرة مضيف ESXi المخصصة لمخزن قراءة NFC. بشكل افتراضي ، يعمل Veeam في وضع قراءة NBD / NFC غير المتزامن ، والذي قد يتطلب في الظروف العادية توسيع هذا المخزن المؤقت. لكن هذا لا يحدث دائمًا. لذلك ، لتعطيل هذا الوضع ، يوجد مفتاح خاص:
Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1بعد إنشائه ، تحتاج إلى إعادة تشغيل Veeam Backup Service والاستعداد للأداء الذي تراجع بنسبة 10٪ تقريبًا.
خيار آخر هو تسجيل الدخول من الجانب المضيف وإعادة وكلاء الإدارة:
/etc/init.d/hostd restart
/etc/init.d/vpxa restartيتم وصف الإجراء بالتفصيل في KB من VMware ، لذلك لن نعيد كتابته.
ومجموعة قياسية من الخيارات التي لن تكون غير ضرورية لفرزها أثناء عملية التشخيص:
- ترحيل الأجهزة التي بها أخطاء إلى مضيف آخر.
- جرب وضع نقل آخر - HotAdd باستخدام وكيل افتراضي أو DirectSAN.
خطأ VDDK 3: إحدى المعلمات غير صالحة
خطأ يحدث دائمًا تقريبًا عند استخدام وضع الجهاز الظاهري (المعروف أيضًا باسم وضع HotAdd).
لا يوجد شيء خاص لأقوله هنا ، سأقدم فقط روابط إلى قاعدة المعارف الخاصة بنا ، حيث يتم وصف العديد من الخيارات ، وحتى إذا أتيت على الفور للدعم ، فسيُطلب منك القيام بكل شيء مكتوب هناك.
KB1218 - وصف عام للمشاكل المحتملة وطرق التخلص منها.
KB1332 - إذا كان خادم Veeam يعمل كوكيل لوضع HotAdd
خطأ VDDK 13: ليس لديك حقوق الوصول إلى هذا الملف
وفي هذه الحالة ، لدينا KB2008 . نعم ، هناك العديد من الخيارات للتخلص من هذه المشكلة ، ولكن مثل هذا الخطأ. يكاد يكون من المستحيل أن تقول بشكل لا لبس فيه ما حدث بالضبط في حالتك ، لذلك عليك أن تأخذ وتكرر القائمة بأكملها.
ما أود أن أقوله بالإضافة إلى ذلك. كن حذرًا جدًا مع قسم استكشاف الأخطاء وإصلاحها الإضافية. نعم ، هناك كتابات ، ربما تكون واضحة جدًا لأشياء كثيرة. لكن حتى مثل هذه الابتذال يراوغ معظم المهنيين المحترفين. غالبًا ما تكون هناك حالات ، بعد أسبوع ، في محاولة لحل كل شيء بأنفسهم ، يأتون للدعم فقط ليكتشفوا أنهم لم يقرؤوا قائمة المتطلبات الفنية بعناية ، أو شيء من هذا القبيل. ومن العار والشفقة على الوقت الذي يقضيه.
ونصيحتان لكل الأوقات:
- Veeam proxy , UUID . - , . , , .
- ( — ), , VDDK .
VDDK error 18000: Cannot connect to the host
في معظم الحالات ، يكمن الخطأ في هذا الخطأ في وجود خطأ في VDDK نفسه. على وجه التحديد ، يقع اللوم على مكتبة gvmomi.dll. ويظهر نفسه فقط تحت حمولة ثقيلة. على سبيل المثال ، عندما يتم نسخ العديد من الأجهزة احتياطيًا بشكل متوازٍ ، تصبح إحدى الوظائف 0 وقد تنهار المكتبة. ثم يسقط كل شيء آخر.
هذه هي القصة المحزنة.
لكن أسوأ شيء في هذه القصة هو أنه من المستحيل إعادة إنتاج ظروف الخطأ بدقة. هذا هو ما يسميه المختبرين الحشرات العائمة. لذلك ، من المستحيل تحديد عدد الآلات الموازية التي تسببت في الانهيار.
ومع ذلك ، وفقا لملاحظات الإصدار الرسميتم إصلاح هذا الخطأ بالكامل. لذا فإن المخرج الصحيح هو تحديث مضيفك. ولكن إذا كان من المستحيل القيام بذلك لسبب ما ، فإن الطريقة الوحيدة التي يمكننا المساعدة بها هي أن ننصحك بتقليل عدد الأجهزة التي تتم معالجتها في وقت واحد.
لا توجد طريقة أخرى.
خطأ VDDK 14008: تعذر الاتصال بالخادم المحدد
لذا ، إذا حلت بك هذه المشكلة ، فإن أول شيء عليك فعله هو التحقق من الشبكة. على الأرجح ، الاتصال بين vCenter و Veeam proxy معطل. نرى ما إذا كانت جميع المنافذ مفتوحة ويمكن الوصول إليها ، إذا تم حل جميع أسماء DNS بشكل صحيح لعناوين IP المتوقعة. علاوة على ذلك ، تحتاج إلى التحقق من الوكيل المحدد المتضمن في الوظيفة الفاشلة ، وليس الوكيل الذي يقف بجانبه (هناك حالات).
95٪ من الحالات التي بها هذا الخطأ مغلقة بالعلامة "مشكلة مع DNS / المنافذ في البنية التحتية للعميل".
لذلك ، مرة أخرى ، أحثك على التحقق بعناية شديدة من الإشارة إلى خادم DNS الصحيح في كل مكان ، وما إذا كانت هناك منافذ مغلقة وفيها يتم حل أسماء FQDN IP.
في الإصدارات الأقدم من VDDK ، كان هناك خطأ مشابه عند استخدام منفذ غير افتراضي للعمل مع vCenter ، والذي يمثل 5 ٪ المتبقية ، ولكن الآن قام VMware بإخفاء KB مع وصفه ، مما يعني على الأرجح أن KB لم تعد ذات صلة. ولكن يمكنك البحث عنه في أرشيفات الإنترنت على 2108658 (فشل النسخ الاحتياطي عند تحديد منفذ غير افتراضي لخادم VMware vCenter).
خطأ VDDK 14009: رفض الخادم الاتصال
والخطأ الأخير في قمة اليوم هو رفض الخادم الاتصال. كل شيء مبتذل تمامًا هنا: هناك شيء ما يمنع الاتصال بين المضيف والوكيل. في معظم الحالات ، يقع اللوم على جدار الحماية. لكن - النقطة الدقيقة - ليس بسبب الموانئ المغلقة ، ولكن بسبب التأخيرات المقدمة. لذا ، أولاً وقبل كل شيء ، نتحقق من انفتاح المنفذ 443 ، ثم ننظر إلى المهلات.
إذا لم يقدم كلا الخيارين أي شيء ، فانتقل إلى الدعم. سيتعين علينا التحقق من المضيف نفسه. ربما هو ببساطة مشغول للغاية وليس لديه الوقت للرد في الوقت المناسب ، وربما شيء آخر.
وأخيرًا ، بعض الروابط المفيدة:
- بوابة الدعم الفني الحائز على جائزة لدينا.
- قاعدة معارف دعم Veeam