استكشاف مشاكل الحالة المتدهورة وإصلاحها في Azure Traffic Manager
توضح هذه المقالة كيفية استكشاف مشاكل وإصلاحها في ملف تعريف Azure Traffic Manager الذي يظهر حالة متدهورة. كخطوة أولى في استكشاف الأخطاء وإصلاحها في الحالة المتدهورة في Azure Traffic Manager هي تمكين تسجيل الدخول. وجه تمكين سجلات الموارد للحصول على مزيد من المعلومات. لهذا السيناريو، خذ بعين الاعتبار تكوين ملف تعريف Traffic Manager مشيراً إلى بعض الخدمات المستضافة على cloudapp.net. إذا كانت صحة Traffic Manager تعرض حالة متدهورة فقد تكون حالة نقطة نهاية واحدة أو أكثر متدهورة:
إذا كانت صحة Traffic Manger تعرض حالة غير نشطة فقد يتم تعطيلنقطتي النهاية:
فهم تحقيقات Traffic Manager
- يعتبر Traffic Manager نقطة نهاية أن يكون عبر إنترنت فقط عندما يتلقى التحقيق استجابة HTTP 200 مرة أخرى من مسار التحقيق. إذا أرجع التطبيق أي رمز استجابة HTTP أخر، يجب إضافة رمز الاستجابة إلى نطاقات رمز الحالة المتوقعة من ملف تعريف Traffic Manager.
- يتم التعامل مع استجابة إعادة التوجيه 30x كفشل إلا إذا قمت حددت هذا كرمز استجابة صالح في نطاقات رمز الحالة المتوقعة لملف تعريف Traffic Manager. لا يحقق Traffic Manager في هدف إعادة التوجيه.
- بالنسبة إلى تحقيقات HTTPs، يتم تجاهل لأخطاء الشهادات.
- المحتوى الفعلي لمسار التحقيق لا يهم، طالما يتم إرجاع 200. بحث عنوان موقع ويب لبعض المحتوى الثابت مثل "/favicon.ico" هو أسلوب شائع. قد لا يرجع المحتوى الديناميكي مثل صفحات ASP دائماً 200 حتى عندما يكون التطبيق سليم.
- أفضل الممارسات هي تعيين مسار التحقيق لشيء لديه ما يكفي من المنطق لتحديد أن الموقع هو أعلى أو لأسفل. في المثال السابق، عن طريق تعيين المسار إلى "/favicon.ico"، يتم اختبار فقط أن w3wp.exe يستجيب. قد لا يشير هذا التحقيق إلى أن تطبيق الويب الخاص بك صحي. سيكون الخيار الأفضل هو تعيين مسار إلى شيء مثل "/Probe.aspx" الذي لديه منطق لتحديد صحة الموقع. على سبيل المثال، يمكنك استخدام عدادات الأداء لاستخدام وحدة المعالجة أو قياس عدد الطلبات الفاشلة. أو يمكنك محاولة الوصول إلى موارد قاعدة البيانات أو حالة جلسة العمل للتأكد من عمل تطبيق الويب.
- إذا تدهورت كل نقاط النهاية في ملف التعريف، ثم عامل Traffic Manager كل نقاط النهاية كصحية ويوجه نسبة استخدام الشبكة إلى كل نقاط النهاية. يضمن هذا السلوك أن المشاكل مع آلية التحقيق لا يؤدي إلى انقطاع كامل للخدمة.
استكشاف الأخطاء وإصلاحها
لاستكشاف مشاكل فشل التحقيق وإصلاحها، تحتاج إلى أداة تعرض إرجاع رمز حالة HTTP من عنوان موقع الويب الخاص بالتحقيق. يوجد العديد من الأدوات المتاحة التي تظهر لك استجابة HTTP الخام.
يمكنك أيضاً استخدام علامة تبويب الشبكة من أدوات تصحيح الأخطاء F12 في متصفح Internet Explorer لعرض استجابات HTTP.
بالنسبة لهذا المثال، نريد أن نرى الرد من عنوان URL الخاص بالتحقيق: http://watestsdp2008r2.cloudapp.net:80/Probe. يوضح مثال PowerShell التالي المشكلة.
Invoke-WebRequest 'http://watestsdp2008r2.cloudapp.net/Probe' -MaximumRedirection 0 -ErrorAction SilentlyContinue | Select-Object StatusCode,StatusDescription
مثال على الإخراج:
StatusCode StatusDescription
---------- -----------------
301 Moved Permanently
لاحظ أننا تلقينا استجابة إعادة التوجيه. كما ذكرنا سابقاً، يعتبر أي رمز حالة بخلاف 200 فاشلاً. يغير Traffic Manager حالة نقطة النهاية إلى غير متصل. لحل المشكلة، تحقق من تكوين موقع الويب للتأكد من أنه يمكن إرجاع "رمز الحالة" الصحيح من مسار التحقيق. إعادة تكوين تحقيق Traffic Manager لنقطة المسار سيظهر استجابة 200.
إذا كانت التحقيق يستخدم بروتوكول HTTPS، فقد تحتاج لإلغاء تفعيل فحص الشهادة لتجنب أخطاء SSL/TLS أثناء الاختبار. تلغي حالات PowerShell التالية تفعيل التحقق من صحة الشهادة لجلسة PowerShell الحالية:
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
الخطوات التالية
نبذة حول طرق توجيه نسبة استخدام الشبكة لـ Traffic Manger
العمليات على Traffic Manager (مرجع واجهة برمجة تطبيقات REST)