الأسئلة المتداولة (FAQ) حول Traffic Manager

  • مقالة

أساسيات Traffic Manager

ما عنوان IP الذي يستخدمه Traffic Manager؟

كما هو موضح في كيفية عمل Traffic Manager، يعمل Traffic Manager على مستوى نظام أسماء المجالات (DNS). فهو يرسل استجابات DNS إلى العملاء المباشرين إلى نقطة نهاية الخدمة المناسبة. ثم يتصل العملاء بنقطة نهاية الخدمة مباشرة، وليس من خلال Traffic Manager.

لذلك، لا يوفر Traffic Manager نقطة نهاية أو عنوان IP للعملاء للاتصال به. إذا كنت تريد عنوان IP ثابتا للخدمة الخاصة بك، يجب تكوينه في الخدمة، وليس في Traffic Manager.

ما أنواع نسبة استخدام الشبكة التي يمكن توجيهها باستخدام Traffic Manager؟

كما هو موضح في كيفية عمل Traffic Manager، يمكن أن تكون نقطة نهاية Traffic Manager هي أي خدمة تواجه الإنترنت ومستضافة داخل أو خارج Azure. ومن ثَمَّ، يمكن لـTraffic Manager توجيه نسبة استخدام الشبكة التي تنشأ من الإنترنت العامّ إلى مجموعة من نقاط النهاية التي تواجه الإنترنت أيضاً. إذا كانت لديك نقاط نهاية داخل شبكة خاصة (على سبيل المثال، إصدار داخلي من Azure Load Balancer) أو كان لديك مستخدمون يقومون بطلبات DNS من مثل هذه الشبكات الداخلية، فلا يمكنك استخدام Traffic Manager لتوجيه نسبة استخدام الشبكة هذه.

هل يدعم Traffic Manager الجلسات "الثابتة"؟

كما هو موضح في كيفية عمل Traffic Manager، يعمل Traffic Manager على مستوى DNS. يستخدم استجابات DNS لتوجيه العملاء إلى نقطة نهاية الخدمة المناسبة. يتصل العملاء بنقطة نهاية الخدمة مباشرة، وليس من خلال Traffic Manager. لذلك، لا يرى Traffic Manager نسبة استخدام الشبكة HTTP بين العميل والخادم.

وبالإضافة إلى ذلك، ينتمي عنوان IP المصدر لاستعلام DNS الذي تم تلقِّيه بواسطة Traffic Manager إلى خدمة DNS المتكررة، وليس إلى العميل. لذلك، لا توجد طريقة ل Traffic Manager لتعقب العملاء الفرديين ولا يمكنه تنفيذ جلسات العمل "الملصقة". هذا القيد شائع لجميع أنظمة إدارة حركة المرور المستندة إلى DNS وليس خاصا ب Traffic Manager.

لماذا أشاهد خطأ HTTP عند استخدام Traffic Manager؟

كما هو موضح في كيفية عمل Traffic Manager، يعمل Traffic Manager على مستوى DNS. يستخدم استجابات DNS لتوجيه العملاء إلى نقطة نهاية الخدمة المناسبة. ثم يتصل العملاء بنقطة نهاية الخدمة مباشرة، وليس من خلال Traffic Manager. لا يرى Traffic Manager نسبة استخدام الشبكة HTTP بين العميل والخادم. لذلك، يجب أن يكون أي خطأ HTTP تراه صادراً من التطبيق الخاص بك. لكي يتصل العميل بالتطبيق، تكون كافة خطوات تحليل DNS مكتملة. يتضمن ذلك أي تفاعل لدى Traffic Manager على تدفق حركة مرور التطبيق.

ولذلك ينبغي أن تركز التحقيقات الإضافية على الطلب.

يعتبر رأس مضيف HTTP الذي تم إرساله من مستعرض العميل أكثر مصادر المشاكل شيوعاً. تأكد من تكوين التطبيق لقبول عنوان المضيف الصحيح لاسم المجال الذي تستخدمه. لنقاط النهاية التي تستخدم خدمة Azure App، راجع تكوين اسم مجال مخصص لتطبيق ويب في خدمة Azure App باستخدام Traffic Manager.

كيف يمكنني حل مشكلة 500 (خطأ داخلي في الخادم) عند استخدام Traffic Manager؟

إذا تلقى العميل أو التطبيق خطأ HTTP 500 أثناء استخدام Traffic Manager، يمكن أن يكون سبب ذلك استعلام DNS قديم. لحل المشكلة، قم بإلغاء تحديد ذاكرة التخزين المؤقت DNS والسماح للعميل بإصدار استعلام DNS جديد.

عندما تكون نقطة نهاية الخدمة غير مستجيبة، لا تتم إعادة تعيين العملاء والتطبيقات التي تستخدم نقطة النهاية هذه حتى يتم تحديث ذاكرة التخزين المؤقت DNS. يتم تحديد مدة ذاكرة التخزين المؤقت بواسطة مدة البقاء (TTL) لسجل DNS. لمزيد من المعلومات، راجع Traffic Manager وذاكرة التخزين المؤقت DNS.

راجع أيضا الأسئلة المتداولة التالية ذات الصلة في هذه المقالة:

ما تأثير استخدام Traffic Manager؟

كما هو موضح في كيفية عمل Traffic Manager، يعمل Traffic Manager على مستوى DNS. نظرا لأن العملاء يتصلون بنقاط نهاية الخدمة الخاصة بك مباشرة، فلا يوجد أي تأثير على الأداء يتم تكبده عند استخدام Traffic Manager بمجرد إنشاء الاتصال.

بما أن Traffic Manager تتكامل مع التطبيقات على مستوى DNS، فإنها تتطلب إدراج بحث DNS إضافي في سلسلة تحليل DNS. إن تأثير Traffic Manager في وقت حل DNS ضئيل جدّاً. يستخدم Traffic Manager شبكة عمومية من خوادم الأسماء، ويستخدم أي مجموعة من الشبكات لضمان توجيه استعلامات DNS دائماً إلى أقرب خادم أسماء متوفر. وبالإضافة إلى ذلك، يعني التخزين المؤقت لاستجابات DNS أن زمن الوصول الإضافي لـ DNS الذي يتم تكبده باستخدام Traffic Manager لا ينطبق إلا على جزء صغير من الجلسات.

يوجه أسلوب الأداء حركة المرور إلى أقرب نقطة نهاية متوفرة. والنتيجة الصافية هي أن تأثير الأداء الكلي المقترن بهذه الطريقة يجب أن يكون ضئيلاً. يجب التعويض عن أي زيادة في زمن وصول DNS بزمن وصول أقل للشبكة إلى نقطة النهاية.

ما بروتوكولات التطبيق التي يمكنني استخدامها مع Traffic Manager؟

كما هو موضح في كيفية عمل Traffic Manager، يعمل Traffic Manager على مستوى DNS. بمجرد اكتمال البحث عن DNS، يتصل العملاء بنقطة نهاية التطبيق مباشرة، وليس من خلال Traffic Manager. لذلك، يمكن الاتصال باستخدام أي بروتوكول تطبيق. في حالة تحديد TCP كبروتوكول مراقبة، يمكن إجراء مراقبة صحة نقطة نهاية Traffic Manager بدون استخدام أي بروتوكولات تطبيق. إذا اخترت التحقق من الصحة باستخدام بروتوكول تطبيق، يجب أن تكون نقطة النهاية قادرة على الاستجابة لطلبات HTTP أو HTTPS GET.

هل يمكنني استخدام Traffic Manager باسم مجال "مجرد"؟

نعم. لمعرفة كيفية إنشاء سجل اسم مستعار لمعرف اسم المجال الخاص بك للإشارة إلى ملف تعريف Azure Traffic Manager، راجع تكوين سجل اسم مستعار لدعم أسماء المجالات العليا مع إدارة المرور.

هل يأخذ Traffic Manager في الاعتبار عنوان الشبكة الفرعية للعميل عند التعامل مع استعلامات DNS؟

نعم. بالإضافة إلى عنوان IP المصدر لاستعلام DNS (عادة ما يكون عنوان IP الخاص بمحلل DNS)، يأخذ Traffic Manager أيضا في الاعتبار عنوان الشبكة الفرعية للعميل إذا تم تضمينه في استعلام DNS الذي يتم إرساله بواسطة محلل DNS الذي يقوم بإجراء الطلب نيابة عن المستخدم النهائي. تستخدم عناوين IP هذه لتحسين أساليب توجيه الشبكة الجغرافية والأداء والشبكة الفرعية. على وجه التحديد، RFC 7871 – توفر الشبكة الفرعية للعميل في استعلامات DNS آلية ملحق ل DNS (EDNS0) يمكن أن تمر على عنوان الشبكة الفرعية للعميل من أدوات الحل التي تدعمها.

ما هو DNS TTL وكيف يؤثر على المستخدمين لدي؟

عندما يقع استعلام DNS على "Traffic Manager"، فإنه يقوم بتعيين قيمة في الاستجابة التي تسمى time-to-live (TTL). تشير هذه القيمة، التي يتم تعيين الوحدة الخاصة بها في ثوانٍ، إلى محددات DNS في المرحلة النهائية حول المدة التي يتم خلالها تخزين هذه الاستجابة مؤقتاً. في حين أن محللي DNS غير مضمونين لتخزين هذه النتيجة مؤقتا، فإن التخزين المؤقت يمكنهم من الاستجابة لأي استعلامات لاحقة خارج ذاكرة التخزين المؤقت بدلا من الانتقال إلى خوادم DNS ل Traffic Manager. ويؤثر ذلك في الردود على النحو التالي:

  • يقلل TTL الأعلى من عدد الاستعلامات التي تقع على خوادم DNS لـTraffic Manager، والتي يمكن أن تقلل التكلفة على العميل؛ نظراً لأن عدد الاستعلامات التي يتم تقديمها هو استخدام قابل للفوترة.
  • يمكن لـ TTL الأعلى تقليل الوقت المستغرق لإجراء بحث DNS.
  • تعني مدة البقاء (TTL) الأعلى أيضا أن بياناتك لا تعكس أحدث المعلومات الصحية التي حصل عليها Traffic Manager من خلال وكلاء الفحص.

إلى أي مدى يمكنني ضبط TTL (مدة البقاء) لاستجابات Traffic Manager؟

يمكنك تعيين DNS TTL، على مستوى ملف التعريف، بحيث يكون منخفضاً لمدة 0 ثوانٍ وعالياً بمقدار 2،147،483،647 ثانية (الحد الأقصى من التوافق مع النطاق مع RFC-1035). تعني TTL من 0 أن محللات DNS المتلقية للمعلومات لا تقوم بتخزين استجابات الاستعلام مؤقتا ومن المتوقع أن تصل جميع الاستعلامات إلى خوادم DNS الخاصة ب Traffic Manager للتحليل.

كيف يمكنني فهم حجم الاستعلامات الواردة إلى ملف التعريف الخاص بي؟

أحد المقاييس التي يوفرها Traffic Manager هو عدد الاستعلامات التي تم الرد عليها من قِبَل ملف تعريف. يمكنك الحصول على هذه المعلومات على مستوى تجميع ملف التعريف أو يمكنك تقسيمها أكثر لرؤية حجم الاستعلامات حيث تم إرجاع نقاط نهاية معينة. وبالإضافة إلى ذلك، يمكنك إعداد تنبيهات لإخطارك إذا تجاوز حجم استجابة الاستعلام الشروط التي قمت بتعيينها. للمزيد من التفاصيل، مقاييس Traffic Managerوالتنبيهات.

عندما أقوم بحذف ملف تعريف Traffic Manager، ما مقدار الوقت قبل أن يكون اسم ملف التعريف متاحاً لإعادة الاستخدام؟

عند حذف ملف تعريف Traffic Manager، يتم حجز اسم المجال المقترن لفترة من الوقت. يمكن لملفات تعريف Traffic Manager الأخرى في نفس المستأجر إعادة استخدام الاسم على الفور. ومع ذلك، لا يمكن لمستأجر Azure مختلف استخدام نفس اسم ملف التعريف حتى تنتهي صلاحية الحجز. تمكنك هذه الميزة من الحفاظ على السلطة على مساحات الأسماء التي تقوم بنشرها، مما يلغي المخاوف من أن الاسم قد يتم أخذه من قبل مستأجر آخر.

على سبيل المثال، إذا كان اسم ملف تعريف Traffic Manager هو label1، فسيتم حجز label1.trafficmanager.net للمستأجر الخاص بك حتى إذا قمت بحذف ملف التعريف. يتم أيضا حجز مساحات الأسماء التابعة، مثل xyz.label1 أو 123.abc.label1 . عند انتهاء صلاحية الحجز، يتم توفير الاسم للمستأجرين الآخرين. الاسم المقترن بملف تعريف معطل محجوز إلى أجل غير مسمى. للحصول على أسئلة حول مدة حجز الاسم، اتصل بممثل حسابك.

أسلوب توجيه حركة مرور البيانات الجغرافية لـTraffic Manager

ما هي بعض حالات الاستخدام التي يكون فيها التوجيه الجغرافي مفيداً؟

يمكن استخدام نوع التوجيه الجغرافي في أي سيناريو يحتاج فيه عميل Azure إلى تمييز مستخدميه استناداً إلى مناطق جغرافية. على سبيل المثال، باستخدام أسلوب توجيه حركة مرور البيانات الجغرافية، يمكنك منح المستخدمين من مناطق معينة تجربة مستخدم مختلفة عن تلك التي توفرها مناطق أخرى. ثمة مثال آخر هو الامتثال للولايات المحلية المتعلقة بالسيادة على البيانات التي تقتضي ألا يخدم المستعملون من منطقة معينة إلا نقاط نهاية في تلك المنطقة.

كيف أقرر ما إذا كان يجب أن أستخدم أسلوب توجيه الأداء أو أسلوب التوجيه الجغرافي؟

يكمن الفرق الرئيسي بين هاتَين الطريقتَين من طرق التوجيه الشائعة في أن هدفك الأساسي في أسلوب توجيه الأداء هو إرسال حركة مرور البيانات إلى نقطة النهاية التي يمكنها توفير أقل زمن انتقال إلى المتصل، بينما يتمثل الهدف الأساسي في التوجيه الجغرافي في فرض سياج جيوغرافي على المتصلين بحيث يمكنك توجيههم عمداً إلى نقطة نهاية محددة. يحدث التداخل نظراً لوجود علاقة بين التقارب الجغرافي وزمن وصول أقل، رغم أن هذا ليس صحيحاً دائماً. قد تكون هناك نقطة نهاية في منطقة جغرافية مختلفة يمكنها توفير تجربة زمن انتقال أفضل للمتصل وفي هذه الحالة يرسل توجيه الأداء المستخدم إلى نقطة النهاية هذه ولكن التوجيه الجغرافي يرسله دائما إلى نقطة النهاية التي قمت بتعيينها لمنطقته الجغرافية. لتوضيح ذلك، خذ المثال التالي بعين الاعتبار -يمكنك مع التوجيه الجغرافي، القيام بتعيينات غير شائعة مثل إرسال جميع حركة المرور من آسيا إلى نقاط النهاية في الولايات المتحدة وجميع حركة المرور في الولايات المتحدة إلى نقاط النهاية في آسيا. في هذه الحالة، يقوم التوجيه الجغرافي عمدا بما قمت بتكوينه بالضبط للقيام به، ولا يعد تحسين الأداء أحد الاعتبارات.

إشعار

قد تكون هناك سيناريوهات قد تحتاج فيها إلى كل من الأداء وإمكانات التوجيه الجغرافي؛ لأن ملفات التعريف المتداخلة للسيناريوهات هذه قد تكون اختياراً رائعاً. على سبيل المثال، يمكنك إعداد ملف تعريف أصل مع توجيه جغرافي حيث ترسل كل حركة مرور من أمريكا الشمالية إلى ملف تعريف متداخل له نقاط نهاية في الولايات المتحدة، وتستخدم توجيه الأداء لإرسال حركة مرور البيانات هذه إلى أفضل نقطة نهاية ضمن تلك المجموعة.

ما هي المناطق التي يدعمها Traffic Manager للتوجيه الجغرافي؟

يمكن العثور على التسلسل الهيكلي للبلد/للمنطقة الذي يستخدمه Traffic Manager هنا. أثناء تحديث هذه الصفحة بأي تغييرات، يمكنك أيضاً استرداد نفس المعلومات برمجياً باستخدام Azure Traffic Manager REST API.

كيف يحدد Traffic Manager من أين يقوم المستخدم بالاستعلام؟

يبحث Traffic Manager في IP المصدر للاستعلام (من المرجح أن يكون هذا هو محلل DNS المحلي الذي يقوم بالاستعلام نيابةً عن المستخدم) ويستخدم IP داخليّاً لتعيين المنطقة لتحديد الموقع. يتم تحديث هذه الخريطة بشكل مستمر لاحتساب التغييرات في الإنترنت.

هل من المؤكد أن Traffic Manager يمكنه أن يحدد بشكل صحيح الموقع الجغرافي الدقيق للمستخدم في كل حالة؟

لا، لا يمكن أن يضمن Traffic Manager أن المنطقة الجغرافية التي نستنتجها من عنوان IP المصدر لاستعلام DNS تتوافق دائما مع موقع المستخدم للأسباب التالية:

  • أولاً، كما هو موضح في الأسئلة المتداولة السابقة، عنوان IP المصدر الذي نراه هو لمحلل DNS يقوم بالبحث نيابة عن المستخدم. على الرغم من أن الموقع الجغرافي للمحلل DNS هو وكيل جيد للموقع الجغرافي للمستخدم، إلا أنه قد يختلف أيضاً تبعاً لبصمة خدمة محلل DNS وخدمة محلل DNS المحددة التي اختار العميل استخدامها. على سبيل المثال، يمكن للعميل الموجود في ماليزيا أن يحدد في إعدادات جهازه استخدام خدمة محلل DNS التي قد يتم انتقاء خادم DNS الموجود في سنغافورة للتعامل مع حلول الاستعلام لهذا المستخدم/الجهاز. في هذه الحالة، يمكن لـ Traffic Manager رؤية عنوان IP الخاص بالمحلل الذي يتوافق مع موقع سنغافورة فقط. راجع أيضاً الأسئلة المتداولة السابقة حول دعم عنوان الشبكة الفرعية للعميل في هذه الصفحة.

  • ثانياً، يستخدم "Traffic Manager" خريطة داخلية للقيام بعنوان IP لترجمة المنطقة الجغرافية. بينما يتم التحقق من صحة هذه الخريطة وتحديثها بشكل مستمر لزيادة دقتها وحساب الطبيعة المتطورة للإنترنت، لا يزال هناك احتمال ألا تكون معلوماتنا تمثيلا دقيقا للموقع الجغرافي لجميع عناوين IP.

هل يجب أن تكون نقطة النهاية موجودة فعليًا في نفس المنطقة التي تم تكوينها بها للتوجيه الجغرافي؟

لا، موقع نقطة النهاية لا يفرض أي قيود على المناطق التي يمكن تعيينها إليها. على سبيل المثال، من الممكن أن تحتوي نقطة نهاية في منطقة Azure المركزية الأمريكية على كافة المستخدمين من الهند الموجهين إليها.

هل يمكنني تعيين مناطق جغرافية لنقاط نهاية في ملف تعريف لم يتم تكوينه للقيام بالتوجيه الجغرافي؟

نعم، إذا لم يكن أسلوب التوجيه لملف التعريف جغرافيا، يمكنك استخدام Azure Traffic Manager REST API لتعيين مناطق جغرافية لنقاط النهاية في ملف التعريف هذا. بالنسبة إلى ملفات تعريف نوع التوجيه غير الجغرافي، يتم تجاهل هذا التكوين. في حالة تغيير ملف التعريف هذا إلى نوع التوجيه الجغرافي في وقت لاحق، يمكن لـ Traffic Manager استخدام هذه التعيينات.

لماذا أتلقى خطأ عند محاولة تغيير أسلوب التوجيه لملف تعريف موجود إلى Geographic؟

يجب تعيين منطقة واحدة على الأقل في كل نقاط النهاية الموجودة ضمن ملف تعريف ذي توجيه جغرافي. لتحويل ملف تعريف موجود إلى نوع توجيه جغرافي، يجب أولاً إقران مناطق جغرافية بجميع نقاط النهاية باستخدام REST API الخاص بـ Azure Traffic Manager قبل تغيير نوع التوجيه إلى جغرافي. في حالة استخدام المدخل، قم أولاً بحذف نقاط النهاية، وقم بتغيير طريقة توجيه ملف التعريف إلى جغرافي، ثم قم بإضافة نقاط النهاية مع تعيين المنطقة الجغرافية.

يمكن تعيين منطقة إلى نقطة نهاية واحدة فقط داخل ملف تعريف إذا كانت تستخدم أسلوب التوجيه الجغرافي. إذا لم تكن نقطة النهاية هذه من النوع المتداخل مع ملف تعريف تابع مرفق بها، إذا كانت نقطة النهاية هذه غير سليمة، فسيستمر Traffic Manager في إرسال نسبة استخدام الشبكة إليها لأن بديل عدم إرسال أي حركة مرور ليس أفضل. لا يفشل Traffic Manager في الوصول إلى نقطة نهاية أخرى، حتى عندما تكون المنطقة المعينة "أصلية" للمنطقة المعينة لنقطة النهاية التي أصبحت غير سليمة (على سبيل المثال، إذا كانت نقطة النهاية التي تحتوي على منطقة إسبانيا غير سليمة، فلن نفشل إلى نقطة نهاية أخرى تم تعيين المنطقة أوروبا إليها). ويتم ذلك لضمان احترامTraffic Manager للحدود الجغرافية التي يقوم العميل بإعدادها في ملفه الشخصي. للحصول على فائدة تجاوز الفشل إلى نقطة نهاية أخرى عندما تصبح نقطة النهاية غير سليمة، يوصى بتعيين مناطق جغرافية إلى ملفات تعريف متداخلة مع نقاط نهاية متعددة داخلها بدلا من نقاط النهاية الفردية. بهذه الطريقة، إذا فشلت نقطة نهاية في ملف تعريف الطفل المدمج، يمكن أن تفشل نسبة استخدام الشبكة إلى نقطة نهاية أخرى داخل نفس ملف التعريف الفرعي المدمج.

هل هناك أي قيود على إصدار API الذي يدعم نوع التوجيه هذا؟

نعم، فقط إصدار API 2017-03-01 وأحدث يدعم نوع التوجيه الجغرافي. لا يمكن استخدام أي إصدارات قديمة من واجهة برمجة التطبيقات لإنشاء ملفات تعريف لنوع التوجيه الجغرافي أو تعيين مناطق جغرافية لنقاط النهاية. إذا تم استخدام إصدار API أقدم لاسترداد ملفات التعريف من اشتراك Azure، فلن يتم إرجاع أي ملف تعريف من نوع التوجيه الجغرافي. بالإضافة إلى ذلك، عند استخدام إصدارات واجهة برمجة التطبيقات القديمة، لا يتم عرض تعيين المنطقة الجغرافية لأي ملف تعريف تم إرجاعه يحتوي على نقاط نهاية مع تعيين منطقة جغرافية.

أسلوب توجيه حركة مرور الشبكة الفرعية لـTraffic Manager

ما هي بعض حالات الاستخدام التي يكون توجيه الشبكة الفرعية مفيداً فيها؟

يسمح لك توجيه الشبكة الفرعية بتمييز التجربة التي تقدمها لمجموعات محددة من المستخدمين الذين تم تحديدهم من قِبَل IP المصدر لطلبات DNS الخاصة بعنوان IP. مثال على ذلك هو عرض محتوى مختلف إذا كان المستخدمون يتصلون بموقع ويب من مقر شركتك الرئيسي. وهناك طريقة أخرى تتمثل في تقييد المستخدمين من مزودي خدمة إنترنت معينين للوصول إلى نقاط النهاية التي تدعم اتصالات IPv4 فقط إذا كان لدى مزودي خدمة الإنترنت أداء دون المستوى عند استخدام IPv6. هناك سبب آخر لاستخدام أسلوب توجيه الشبكة الفرعية مقترن بتوصيفات أخرى في مجموعة ملفات تعريف متداخلة. على سبيل المثال، إذا كنت تريد استخدام أسلوب توجيه جغرافي للسياج الجغرافي للمستخدمين، ولكن بالنسبة إلى موفر خدمة محدد (ISP)، يمكنك استخدام أسلوب توجيه مختلف، كما يمكنك الحصول على ملف تعريف باستخدام أسلوب توجيه الشبكة الفرعية كملف تعريف أصلي وتجاوز ISP لاستخدام ملف تعريف فرعي معين والحصول على ملف التعريف الجغرافي القياسي لأي شخص آخر.

كيف يعرف Traffic Manager عنوان IP للمستخدم النهائي؟

تستخدم أجهزة المستخدم النهائي عادةً محلل DNS لإجراء بحث DNS نيابة عنها. إن IP الصادر لمثل هذه المحددات هو ما يراه Traffic Manager على أنه IP المصدر. بالإضافة إلى ذلك، يبحث أسلوب توجيه الشبكة الفرعية أيضا لمعرفة ما إذا كانت هناك معلومات الشبكة الفرعية للعميل الموسع EDNS0 (ECS) التي تم تمريرها مع الطلب. إذا كانت معلومات ECS موجودة، فهذا هو العنوان المستخدم لتحديد التوجيه. في حالة عدم وجود معلومات ECS، يتم استخدام IP المصدر للاستعلام لأغراض التوجيه.

كيف يمكنني تحديد عناوين IP عند استخدام توجيه الشبكة الفرعية؟

يمكن تحديد عناوين IP التي سيتم إقرانها بنقطة نهاية بطريقتَين. أولاً، يمكنك استخدام التدوين العشري الرباعي المنقط بعناوين بداية ونهاية لتحديد النطاق (على سبيل المثال، 1.2.3.4-5.6.7.8 أو 3.4.5.6-3.4.5.6). ثانياً، يمكنك استخدام شفرة CIDR لتحديد النطاق (على سبيل المثال، 1.2.3.0/24). يمكنك تحديد نطاقات متعددة، ويمكنك استخدام كِلَا النوعَين من الرسائل في مجموعة نطاقات. تنطبق بعض القيود.

  • لا يمكنك تراكب نطاقات العناوين نظرا لأنه يجب تعيين كل عنوان IP إلى نقطة نهاية واحدة فقط
  • لا يمكن أن يكون عنوان البدء أكثر من عنوان النهاية
  • بالنسبة إلى رمز CIDR، يجب أن يكون عنوان IP قبل '/' هو عنوان الشبكة لهذا النطاق (على سبيل المثال، 1.2.3.0/24 صالح ولكن 1.2.3.4.4/24 غير صحيح)

كيف يمكنني تحديد نقطة نهاية احتياطية عند استخدام توجيه الشبكة الفرعية؟

في ملف تعريف مع توجيه الشبكة الفرعية، إذا كان لديك نقطة نهاية مع عدم تعيين شبكات فرعية إليها، يتم توجيه أي طلب لا يتطابق مع نقاط النهاية الأخرى إلى هنا. يوصى بشدة بأن يكون لديك نقطة نهاية احتياطية في ملف التعريف الخاص بك نظرا لأن Traffic Manager يقوم بإرجاع استجابة NXDOMAIN إذا جاء طلب ولم يتم تعيينه إلى أي نقاط نهاية أو إذا تم تعيينه إلى نقطة نهاية ولكن نقطة النهاية هذه غير سليمة.

ماذا يحدث إذا تم تعطيل نقطة نهاية في ملف تعريف نوع توجيه الشبكة الفرعية؟

في ملف تعريف مع توجيه الشبكة الفرعية، إذا كان لديك نقطة نهاية مع تعطيلها، فإن Traffic Manager يتصرف كما لو كانت نقطة النهاية هذه وتعيينات الشبكة الفرعية غير موجودة. إذا تم تلقي استعلام مطابق لتعيين عنوان IP الخاص به وتم تعطيل نقطة النهاية، ترجع Traffic Manager نقطة نهاية احتياطية (واحدة بدون تعيينات) أو إذا لم تكن نقطة النهاية هذه موجودة، فترجع استجابة NXDOMAIN.

أسلوب توجيه حركة مرور MultiValue لـTraffic Manager

ما هي بعض حالات الاستخدام حيث يكون فيها التوجيه MultiValue مفيداً؟

يقوم توجيه MultiValue بإرجاع نقاط نهاية سليمة متعددة في استجابة استعلام واحد. الميزة الرئيسية لهذا هي أنه إذا كانت نقطة النهاية غير سليمة، يكون لدى العميل مزيد من الخيارات لإعادة المحاولة دون إجراء استدعاء DNS آخر (الذي قد يعيد نفس القيمة من ذاكرة التخزين المؤقت للتحميل). ينطبق هذا على التطبيقات الحساسة للإتاحة والتي تريد تقليل وقت التوقف عن العمل. هناك استخدام آخر لأسلوب توجيه MultiValue وهو إذا كانت نقطة النهاية "مزدوجة الوجهة" لكل من عنوانَي IPv4 وIPv6، وتريد منح المتصل كِلَا الخيارَين للاختيار منهما عند تهيئة اتصال بنقطة النهاية.

كم عدد نقاط النهاية التي يتم إرجاعها عند استخدام التوجيه MultiValue؟

يمكنك تحديد الحد الأقصى لعدد نقاط النهاية التي سيتم إرجاعها ولا ترجع MultiValue أكثر من العديد من نقاط النهاية السليمة عند تلقي استعلام. الحد الأقصى للقيمة الممكنة لهذا التكوين هو 10.

هل سأحصل على نفس مجموعة نقاط النهاية عند استخدام توجيه MultiValue؟

لا يمكننا ضمان إرجاع نفس مجموعة نقاط النهاية في كل استعلام. يتأثر هذا أيضاً بحقيقة أن بعض نقاط النهاية قد تصبح غير صحية وفي هذه المرحلة لن يتم تضمينها في الاستجابة

قياسات المستخدم الحقيقي

ما هي فوائد استخدام Real User Measurements؟

عند استخدام أسلوب توجيه الأداء، يلتقط Traffic Manager أفضل منطقة Azure للمستخدم النهائي للاتصال بها عن طريق فحص الشبكة الفرعية لعميل IP المصدر وEDNS (في حالة تمرير الدخول) والتحقق منها مقابل معلومات زمن الوصول للشبكة التي تحتفظ بها الخدمة. تعمل قياسات المستخدم الحقيقي على تحسين ذلك لقاعدة المستخدمين النهائيين من خلال جعل خبرتهم تساهم في جدول زمن الانتقال هذا بالإضافة إلى ضمان أن يمتد هذا الجدول بشكل كافٍ إلى شبكات المستخدم النهائي من حيث يتصل المستخدمون بـ Azure. يؤدي هذا إلى زيادة الدقة في توجيه المستخدم النهائي الخاص بك.

هل يمكنني استخدام قياسات المستخدم الحقيقي مع مناطق غير مناطق Azure؟

يقيس Real User Measurements زمن الوصول إلى مناطق Azure وتقريره فقط. إذا كنت تستخدم التوجيه المستند إلى الأداء مع نقاط النهاية المستضافة في مناطق غير Azure، فلا يزال بإمكانك الاستفادة من هذه الميزة من خلال زيادة معلومات زمن الانتقال حول منطقة Azure التمثيلية التي حددتها لإقرانها بنقطة النهاية هذه.

ما هي طريقة التوجيه التي تستفيد من Real User Measurements؟

لا تنطبق المعلومات الإضافية التي يتم الحصول عليها من خلال Real User Measurements إلا على التوصيفات التي تستخدم أسلوب توجيه الأداء. يتاح رابط Real User Measurements من كل التوصيفات عندما تعرضها من خلال مدخل Azure.

هل أحتاج إلى تمكين Real User Measurements لكل ملف شخصي على حدة؟

لا، تحتاج فقط إلى تمكينه مرة واحدة لكل اشتراك، وتتوفر جميع معلومات زمن الوصول المقيسة والمفاد بها لكافة ملفات التعريف.

كيف يمكنني إيقاف تشغيل Real User Measurements للاشتراك الخاص بي؟

يمكنك إيقاف تحصيل الرسوم المرتبطة بقياسات المستخدم الحقيقي عندما تتوقف عن جمع وإرسال قياسات زمن الوصول من تطبيق العميل الخاص بك. على سبيل المثال، عند قياس JavaScript مدمج في صفحات الويب، يمكنك إيقاف استخدام هذه الميزة بإزالة JavaScript أو بإيقافه عند تقديم الصفحة.

يمكنك أيضاً إيقاف Real User Measurements عن طريق حذف المفتاح الخاص بك. بمجرد حذف المفتاح، يتم تجاهل أي قياسات يتم إرسالها إلى Traffic Manager مع هذا المفتاح.

هل يمكنني استخدام Real User Measurements مع تطبيقات العميل بخلاف صفحات الويب؟

نعم، تم تصميم قياسات المستخدم الحقيقي لاستيعاب البيانات التي تم جمعها من خلال أنواع مختلفة من عملاء المستخدم النهائي. يتم تحديث هذه الأسئلة المتداولة مع دعم أنواع جديدة من تطبيقات العميل.

كم عدد القياسات التي يتم إجراؤها في كل مرة يتم فيها تقديم صفحة الويب الممكنة لـReal User Measurements؟

عند استخدام قياسات المستخدم الحقيقي مع توفير القياس JavaScript، فإن كل تجسيد للصفحة ينتج ستة قياسات يتم اتخاذها. ثم يتم الإبلاغ عنها مرة أخرى إلى خدمة Traffic Manager. يتم تحصيل رسوم منك مقابل هذه الميزة استنادا إلى عدد القياسات التي تم الإبلاغ عنها إلى خدمة Traffic Manager. على سبيل المثال، إذا انتقل المستخدم بعيدا عن صفحة الويب الخاصة بك أثناء أخذ القياسات ولكن قبل الإبلاغ عنها، لا يتم النظر في هذه القياسات لأغراض الفوترة.

هل هناك تأخير قبل تشغيل البرنامج النصي Real User Measurements في صفحة ويب الخاصة بي؟

لا، لا يوجد تأخير مبرمج قبل استدعاء البرنامج النصي.

هل يمكنني استخدام Real User Measurements مع مناطق Azure التي أريد قياسها فقط؟

لا، في كل مرة يتم استدعاؤها، يقيس البرنامج النصي Real User Measurements مجموعة من ست مناطق Azure كما تحددها الخدمة. تقوم هذه المجموعة بالتغيير بين الاستدعاءات المختلفة، وعند حدوث عدد كبير من هذه الاستدعاءات، تمتد تغطية القياس عبر مناطق Azure المختلفة.

هل يمكنني تحديد عدد القياسات التي أُجريت على رقم محدد؟

يتم تضمين القياس JavaScript داخل صفحة الويب الخاصة بك وأنت في تحكم كامل في وقت البدء والتوقف عن استخدامه. ما دامت خدمة إدارة المرور تتلقى طلباً لقائمة مناطق Azure المراد قياسها، يتم إرجاع مجموعة من المناطق.

هل يمكنني رؤية القياسات التي تم أخذها من قِبَل تطبيق العميل كجزء من Real User Measurements؟

نظرا لأن منطق القياس يتم تشغيله من تطبيق العميل الخاص بك، فأنت تتحكم بشكل كامل في ما يحدث بما في ذلك رؤية قياسات زمن الانتقال. لا يبلغ Traffic Manager عن طريقة عرض مجمعة للقياسات المستلمة تحت المفتاح المرتبط باشتراكك.

هل يمكنني تعديل برنامج القياس الذي يقدمه Traffic Manager؟

في حين أنك تتحكم في ما هو مضمن في صفحة الويب الخاصة بك، فإننا لا نشجعك بشدة على إجراء أي تغييرات على برنامج القياس النصي للتأكد من أنه يقيس زمن الانتقال ويبلغ عنه بشكل صحيح.

هل سيكون من الممكن للآخرين رؤية المفتاح الذي أستخدمه مع Real User Measurements؟

عند تضمين البرنامج النصي للقياس في صفحة ويب، من الممكن للآخرين رؤية البرنامج النصي ومفتاح قياسات المستخدم الحقيقي (RUM). ولكن من المهم معرفة أن هذا المفتاح يختلف عن معرف الاشتراك الخاص بك ويتم إنشاؤه بواسطة Traffic Manager لاستخدامه لهذا الغرض فقط. إن معرفة مفتاح RUM الخاص بك لن يؤثر على أمان حسابك في Azure.

هل يمكن للآخرين إساءة استخدام مفتاح RUM الخاص بي؟

في حين أنه من الممكن للآخرين استخدام مفتاحك لإرسال معلومات خاطئة إلى Azure، فإن بعض القياسات الخاطئة لن تغير التوجيه نظرا لأنه يؤخذ في الاعتبار مع جميع القياسات الأخرى التي نتلقاها. إذا كنت بحاجة إلى تغيير مفاتيحك، يمكنك إعادة إنشاء المفتاح عند النقطة التي يتم فيها تجاهل المفتاح القديم.

هل أحتاج إلى وضع JavaScript للقياس في كل صفحات الويب الخاصة بي؟

تقدمReal User Measurements قيمة أكبر مع زيادة عدد القياسات. بعد أن قلت ذلك، إنه قرارك فيما إذا كنت بحاجة إلى وضعه في جميع صفحات الويب الخاصة بك أو عدد قليل محدد. تتمثل توصيتنا في البدء بوضعها في أكثر صفحاتك زيارةً، حيث يتوقع من المستخدم البقاء على تلك الصفحة لمدة خمس ثوانٍ أو أكثر.

هل يمكن التعرف على معلومات حول المستخدمين النهائيين من خلال Traffic Manager إذا قمت باستخدام قياسات المستخدم الحقيقي؟

عند استخدام القياس المتوفر JavaScript، يكون ل Traffic Manager رؤية في عنوان IP للعميل للمستخدم النهائي وعنوان IP المصدر لمحلل DNS المحلي الذي يستخدمونه. يستخدم Traffic Manager عنوان IP الخاص بالعميل فقط بعد اقتطاعه بحيث لا تتمكن من تحديد المستخدم النهائي المحدد الذي أرسل القياسات.

هل تحتاج صفحة الويب التي تقيسReal User Measurement إلى استخدام Traffic Manager للتوجيه؟

لا، لا تحتاج إلى استخدام Traffic Manager. يعمل جانب التوجيه من Traffic Manager بشكل منفصل عن جزء قياس المستخدم الحقيقي وعلى الرغم من أنه من الجيد أن يكون كليهما في نفس خاصية الويب، إلا أنه لا يلزم أن يكون كذلك.

هل أحتاج إلى استضافة أي خدمة على مناطق Azure لاستخدامها مع Real User Measurements؟

لا، لا تحتاج إلى استضافة أي مكون من جانب الخادم على Azure من أجل Real User Measurements للعمل. تتم استضافة وإدارة الصورة ذات البيكسل الواحد والتي تم تنزيلها بواسطة JavaScript للقياس والخدمة التي تقوم بتشغيلها في مناطق Azure مختلفة بواسطة Azure.

هل سيزيد استخدام عرض النطاق الترددي Azure عند استخدامReal User Measurements؟

كما هو مذكور في الإجابة السابقة، فإن مكونات خادم Real User Measurements الخاصة بالمستخدم الحقيقي مملوكة وتتم إدارتها بواسطة Azure. وهذا يعني أن استخدام النطاق الترددي ل Azure لن يزيد لأنك تستخدم قياسات المستخدم الحقيقي. لا يتضمن هذا أي استخدام للنطاق الترددي خارج رسوم Azure. نعمل على تقليل عرض النطاق الترددي المستخدم من خلال تنزيل صورة ذات وحدة بكسل واحدة فقط لقياس زمن الوصول إلى منطقة Azure.

عرض استخدام الشبكة

ماذا تفعل ميزة "عرض نسبة استخدام الشبكة"؟

Traffic View هي إحدى ميزات Traffic Manager التي تساعدك على فهم المزيد عن المستخدمين وكيف تكون تجربتهم. هو يستخدم الاستعلامات التي يتلقاها Traffic Manager وجداول معلومات زمن الوصول للشبكة التي تحتفظ بها الخدمة لتزويدك بما يلي:

  • المناطق التي يقيم فيها المستخدمون والتي تتصل بنقاط النهاية الخاصة بك في Azure.
  • حجم المستخدمين الذين يتصلون من هذه المناطق.
  • مناطق Azure التي يتم توجيهها إليها.
  • توجيه تجربة زمن انتقال المستخدمين إلى مناطق Azure هذه.

هذه المعلومات متاحة لك للاستهلاك من خلال تغشية الخريطة الجغرافية وعروض جدولية في البوابة، بالإضافة إلى توفرها كبيانات أولية لتنزيلها.

كيف يمكنني الاستفادة من استخدام "عرض نسبة استخدام الشبكة"؟

يمنحك Traffic View طريقة العرض الإجمالية لحركة مرور البيانات التي تتلقاها ملفات تعريف Traffic Manager. على وجه الخصوص، يمكن استخدامه لفهم مصدر ترابط قاعدة المستخدمين لديك، والأهم أيضاً معرفة متوسط تجربة زمن الوصول. يمكنك بعد ذلك استخدام هذه المعلومات للعثور على المناطق التي تحتاج إلى التركيز فيها، على سبيل المثال، عن طريق توسيع مساحة Azure إلى منطقة يمكن أن تخدم هؤلاء المستخدمين بزمن وصول أقل. هناك فكرة أخرى يمكنك استنتاجها من استخدام عرض نسبة استخدام الشبكة وهي رؤية أنماط نسبة استخدام الشبكة إلى مناطق مختلفة، والتي بدورها يمكن أن تساعدك في اتخاذ قرارات بشأن زيادة أو تقليل الاختراعات في تلك المناطق.

كيف يختلف "عرض نسبة استخدام الشبكة" عن مقاييس Traffic Manager المتوفرة من خلال شاشة Azure؟

يمكن استخدام Azure Monitor لفهم حركة مرور البيانات التي تم تلقيها من ملف التعريف ونقاط النهاية الخاصة به على مستوى إجمالي. كما أنه يمكِّنك من تتبع حالة صحة نقاط النهاية عن طريق الكشف عن نتائج الفحص الصحي. عندما تحتاج إلى تجاوز هذه الخطوات وتفهم تجربة المستخدم النهائي في الاتصال بـ Azure على مستوى إقليمي، يمكن استخدام Traffic View لتحقيق ذلك.

هل تستخدم "عرض نسبة استخدام الشبكة" معلومات الشبكة الفرعية لعميل EDNS؟

تضع استعلامات DNS التي يخدمها Azure Traffic Manager معلومات ECS في عين الاعتبار لزيادة دقة التوجيه. ولكن عند إنشاء مجموعة البيانات التي تظهر من أين يتصل المستخدمون، يستخدم Traffic View فقط عنوان IP للمحلل DNS.

كم يوماً تستخدم ميزة "عرض نسبة استخدام الشبكة" البيانات؟

يُنشئ عرض نسبة استخدام الشبكة مخرجاته من خلال معالجة البيانات من الأيام السبعة السابقة لليوم السابق عندما تشاهدها أنت. هذه نافذة متحركة ويتم استخدام أحدث البيانات في كل مرة تزور فيها.

كيف يعالج "عرض نسبة استخدام الشبكة" نقاط النهاية الخارجية؟

عند استخدام نقاط النهاية الخارجية المستضافة خارج مناطق Azure في ملف تعريف إدارة المرور، يمكنك اختيار تعيينها إلى منطقة Azure، وهي وكيل لخصائص وقت الاستجابة (هذا ضروري في الواقع إذا كنت تستخدم أسلوب توجيه الأداء). إذا كان لديه تعيين منطقة Azure هذا، يتم استخدام مقاييس زمن الانتقال الخاصة بمنطقة Azure عند إنشاء إخراج عرض نسبة استخدام الشبكة. إذا لم يتم تحديد منطقة Azure، تكون معلومات زمن الانتقال فارغة في البيانات الخاصة بنقاط النهاية الخارجية هذه.

هل أحتاج إلى تمكين "عرض نسبة استخدام الشبكة" لكل ملف تعريف في اشتراكي؟

خلال فترة المعاينة، تم تمكين Traffic View على مستوى الاشتراك. كجزء من التحسينات التي أجريناها قبل التوفر العام، يمكنك الآن تمكين Traffic View على مستوى ملف التعريف؛ ما يتيح لك إمكانية تمكين هذه الميزة بمزيد من التفصيل. بشكل افتراضي، يتم تعطيل Traffic View لملف تعريف.

إشعار

إذا قمتَ بتمكين Traffic View على مستوى الاشتراك أثناء وقت المعاينة، فستحتاج الآن إلى إعادة تمكينه لكل ملف تعريف ضمن هذا الاشتراك.

كيف يمكنني إيقاف تشغيل "عرض نسبة استخدام الشبكة"؟

يمكنك إيقاف تشغيل Traffic View لأي ملف تعريف باستخدام البوابة الإلكترونية أو واجهة برمجة تطبيقات REST.

كيف تعمل فوترة "عرض نسبة استخدام الشبكة"؟

يستند تسعير Traffic View إلى عدد نقاط البيانات المستخدمة لإنشاء الإخراج. حاليّاً، نوع البيانات الوحيد المعتمد هو الاستعلامات التي يتلقاها ملف التعريف. بالإضافة إلى ذلك، تتم محاسبتك فقط على المعالجة التي تم إجراؤها عند تمكين عرض نسبة استخدام الشبكة. وهذا يعني أنه في حالة تمكين Traffic View لفترة زمنية ما في شهر وإيقاف تشغيلها خلال أوقات أخرى، لن يتم سوى معالجة نقاط البيانات أثناء تمكين ميزة حساب الفاتورة.

نقاط نهاية Traffic Manager

هل يمكنني استخدام "Traffic Manager" مع نقاط النهاية من اشتراكات متعددة؟

لا يمكن استخدام نقاط النهاية من اشتراكات متعددة مع Azure Web Apps. يتطلب Azure Web Apps استخدام أي اسم مجال مخصص مستخدم مع Web Apps فقط في اشتراك واحد. لا يمكن استخدام Web Apps من اشتراكات متعددة بنفس اسم المجال.

بالنسبة إلى أنواع نقاط النهاية الأخرى، من الممكن استخدام Traffic Manager مع نقاط النهاية من أكثر من اشتراك واحد. في Resource Manager، يمكن إضافة نقاط النهاية من أي اشتراك إلى Traffic Manager، طالما أن الشخص الذي يقوم بتكوين ملف تعريف Traffic Manager لديه حق الوصول للقراءة إلى نقطة النهاية. يمكن منح هذه الأذونات باستخدام التحكم في الوصول المستند إلى الدور Azure (دور Azure RBAC). يمكن إضافة نقاط النهاية من الاشتراكات الأخرى باستخدام Azure PowerShell أو Azure CLI.

هل يمكنني استخدام Traffic Manager مع فتحات "عملية التقسيم المرحلي" لخدمة السحابة؟

نعم. يمكن تكوين فتحات "التدريج" لخدمة السحابة في Traffic Manager كنقاط نهاية خارجية. لا يزال يتم فرض رسوم على الفحوصات الصحية بمعدل نقاط نهاية Azure.

هل يدعم Traffic Manager نقاط نهاية IPv6؟

لا يوفر Traffic Manager حاليا خوادم أسماء قابلة للعنوان IPv6. ومع ذلك، لا يزال يمكن استخدام Traffic Manager من قبل عملاء IPv6 المتصلين بنقاط نهاية IPv6 إذا كان خادم DNS المتداخل للعميل يدعم IPv4. لا يقوم العميل بإجراء طلب DNS مباشرة إلى Traffic Manager. وبدلاً من ذلك، يستخدم العميل خدمة DNS متكررة. يرسل عميل IPv6 فقط الطلبات إلى خدمة DNS العودية عبر IPv6. يجب أن تكون الخدمة المتكررة عندئذ قادرة على الاتصال بخوادم أسماء Traffic Manager باستخدام IPv4. يستجيب Traffic Manager باسم DNS أو عنوان IP لنقطة النهاية.

هل يمكنني استخدام Traffic Manager مع أكثر من تطبيق ويب واحد في المنطقة نفسها؟

في العادة، يتم استخدام Traffic Manager لتوجيه حركة مرور البيانات إلى التطبيقات المنتشرة في مناطق مختلفة. ومع ذلك، يمكن استخدامه أيضاً عندما يكون للتطبيق أكثر من عملية نشر في نفس المنطقة. لا تسمح نقاط نهاية Traffic Manager Azure بإضافة أكثر من نقطة نهاية Web App واحدة من نفس منطقة Azure إلى نفس ملف تعريف Traffic Manager.

كيف يمكنني نقل نقاط نهاية Azure لملف تعريف Traffic Manager إلى مجموعة موارد أو اشتراك مختلف؟

يتم تعقب نقاط نهاية Azure المقترنة بملف تعريف Traffic Manager باستخدام معرفات الموارد الخاصة بها. عندما يتم نقل مورد Azure الذي يتم استخدامه كنقطة نهاية (على سبيل المثال، IP العام أو Classic Cloud Service أو WebApp أو ملف تعريف إدارة مرور آخر مستخدم بطريقة متداخلة) إلى مجموعة موارد أو اشتراك مختلف، يتغير معرّف المورد الخاص به. في هذا السيناريو، حاليّاً، يجب تحديث ملف تعريفTraffic Manager عن طريق الحذف أولاً ثم إضافة نقاط النهاية إلى ملف التعريف.

لمزيد من المعلومات، راجع لنقل نقطة نهاية.

إضافة نقاط نهاية لمدير المرور

هل Traffic Manager قادر على الصمود في مواجهة حالات الفشل في منطقة Azure؟

يعد Traffic Manager أحد المكونات الرئيسية لتسليم التطبيقات عالية التوفر في Azure. لتوفير قابلية توفر عالية، يجب أن يتوفر لدى Traffic Manager مستوى توفر عالٍ بشكل استثنائي وأن يكون قادراً على مواجهة الأعطال في المنطقة.

من خلال التصميم، تتميز مكونات Traffic Manager بالمرونة اللازمة لمواجهة أي فشل تام لأي منطقة من مناطق Azure. تنطبق هذه المرونة على كافة مكونات Traffic Manager: خوادم أسماء DNS وAPI، وطبقة التخزين، وخدمة مراقبة نقطة النهاية.

في حالة تعطل منطقة Azure بالكامل وهو أمر مستبعد، من المتوقع أن يستمر Traffic Manager في أداء مهامه بشكل طبيعي. يمكن للتطبيقات التي تم نشرها في العديد من مناطق Azure الاعتماد على Traffic Manager لتوجيه حركة المرور إلى مثيل متوفر من التطبيق الخاص بها.

كيف يؤثر اختيار موقع مجموعة الموارد في Traffic Manager؟

Traffic Manager هو خدمة عالمية واحدة. إنه ليس إقليميا. لا يُحدِث اختيار موقع مجموعة الموارد أي فرق في ملفات تعريف Traffic Manager التي تم نشرها في مجموعة الموارد هذه.

يتطلب Azure Resource Manager أن تقوم كافة مجموعات الموارد بتحديد موقع، والذي يحدد الموقع الافتراضي للموارد التي تم نشرها في مجموعة الموارد هذه. عند إنشاء ملف تعريف Traffic Manager، يتم إنشاؤه في مجموعة موارد. تستخدم كافة ملفات تعريف لـ Traffic Manager عمومي كموقع لها، متجاوزةً الوضع الافتراضي لمجموعة الموارد.

كيف يمكنني تحديد السلامة الحالية لكل نقطة نهاية؟

يتم عرض حالة المراقبة الحالية لكل نقطة نهاية، بالإضافة إلى ملف التعريف العامّ، في مدخل Azure. تتوفر هذه المعلومات أيضاً من خلال مراقبة حركة المرور REST API وPowerShell cmdlets وAzure CLI.

يمكنك أيضاً استخدام Azure Monitor لتعقب سلامة نقاط النهاية الخاصة بك ورؤية تمثيل مرئي لها. لمزيد من المعلومات حول استخدام Azure Monitor، راجع وثائق مراقبة Azure.

هل يمكنني مراقبة نقاط نهاية HTTPS؟

نعم. يدعم Traffic Manager التحقق عبر HTTPS. تكوين HTTPS كالبروتوكول في تكوين المراقبة.

لا يمكن لمدير حركة المرور توفير أي تحقق من صحة الشهادة، بما في ذلك:

  • لا يتم التحقق من صحة الشهادات من جانب الخادم
  • لم يتم التحقق من صحة الشهادات من جانب خادم SNI
  • شهادات العميل غير مدعومة

هل يمكنني استخدام عنوان IP أو اسم DNS عند إضافة نقطة نهاية؟

يدعم Traffic Manager إضافة نقاط نهاية باستخدام ثلاث طرق لإحالتها - كاسم DNS، وعنوان IPv4، وعنوان IPv6. إذا تمت إضافة نقطة النهاية كعنوان IPv4 أو IPv6، فإن استجابة الاستعلام من نوع السجل A أو AAAA، على التوالي. إذا تمت إضافة نقطة النهاية كاسم DNS، فإن استجابة الاستعلام من نوع السجل CNAME. لا يسمح بإضافة نقاط نهاية كعنوان IPv4 أو IPv6 إلا إذا كانت نقطة النهاية من النوع External. يتم اعتماد كافة أساليب التوجيه وإعدادات المراقبة بواسطة أنواع معالجة نقطة النهاية الثلاثة.

ما أنواع عناوين IP التي يمكنني استخدامها عند إضافة نقطة نهاية؟

يسمح لك Traffic Manager باستخدام عناوين IPv4 أو IPv6 لتحديد نقاط النهاية. هناك بعض القيود المذكورة أدناه:

  • لا يسمح بالعناوين التي تتوافق مع مساحات عناوين IP الخاصة المحجوزة. تتضمن هذه العناوين تلك التي تم استدعاؤها في RFC 1918 وRFC 6890، وRFC 5737 وRFC 3068، وRFC 2544، وRFC 5771
  • يجب ألا يحتوي العنوان على أي أرقام منافذ (يمكنك تحديد المنافذ التي سيتم استخدامها في إعدادات تكوين ملف التعريف)
  • لا يمكن أن يكون لدى نقطتَي النهاية في نفس الملف الشخصي نفس عنوان IP الهدف

هل يمكنني استخدام أنواع عناوين نقاط نهاية مختلفة ضمن ملف تعريف واحد؟

لا، لا يسمح لك Traffic Manager بخلط أنواع عناوين نقاط النهاية داخل ملف تعريف، باستثناء حالة ملف تعريف بنوع توجيه MultiValue حيث يمكنك مزج أنواع عناوين IPv4 وIPv6

ماذا يحدث عندما يختلف نوع سجل الاستعلام الوارد عن نوع السجل المقترن بنوع عناوين نقاط النهاية؟

عندما يتم تلقي استعلام مقابل ملف تعريف، تجد Traffic Manager أولاً نقطة النهاية التي تحتاج إلى الإرجاع وفقاً لأسلوب التوجيه المحدد وحالة صحة نقاط النهاية. ثم يبحث عن نوع السجل المطلوب في الاستعلام الوارد ونوع السجل المقترن بنقطة النهاية قبل إرجاع استجابة تستند إلى الجدول أدناه.

بالنسبة إلى التشكيلات الجانبية التي لها أي أسلوب توجيه بخلاف MultiValue:

طلب الاستعلام الوارد نوع نقطة النهاية الاستجابة المقدمة
ANY A / AAAA / CNAME نقطة النهاية الهدف
ش A / CNAME نقطة النهاية الهدف
ش AAAA NODATA
AAAA AAAA / CNAME نقطة النهاية الهدف
AAAA ش NODATA
CNAME CNAME نقطة النهاية الهدف
CNAME A / AAAA NODATA

بالنسبة إلى ملفات التعريف ذات أسلوب التوجيه التي تم تعيينها إلى MultiValue:

طلب الاستعلام الوارد نوع نقطة النهاية الاستجابة المقدمة
ANY مزيج من A وAAAA نقاط النهاية الهدف
ش مزيج من A وAAAA نقاط النهاية الهدف فقط من النوع A
AAAA مزيج من A وAAAA نقاط النهاية الهدف فقط من نوع AAAA
CNAME مزيج من A وAAAA NODATA

هل يمكنني استخدام ملف تعريف يحتوي على نقاط نهاية IPv4/IPv6 في ملف تخصيص متداخل؟

نعم يمكنك، باستثناء أن ملف تعريف من النوع MultiValue لا يمكن أن يكون ملف تعريف أصل في مجموعة ملفات تعريف متداخلة.

لقد أوقفت نقطة نهاية تطبيق ويب في ملف تعريف Traffic Manager لديّ، لكنني لا أتلقى أي نسبة استخدام الشبكة حتى بعد إعادة تشغيلها. كيف يمكنني إصلاح هذا؟

عندما يتم إيقاف نقطة نهاية تطبيق ويب Azure توقف Traffic Manager عن التحقق من صحتها، ثم تقوم بإعادة تشغيل عمليات التحقق من الصحة فقط بعد أن تكتشف أن نقطة النهاية قد تمت إعادة تشغيلها. لمنع هذا التأخير، قم بتعطيل نقطة النهاية هذه ثم إعادة تمكينها في ملف تعريف Traffic Manager بعد إعادة تشغيل نقطة النهاية.

هل يمكنني استخدام Traffic Manager حتى إذا كان تطبيقي لا يدعم HTTP أو HTTPS؟

نعم. يمكنك تحديد TCP كبروتوكول مراقبة، ويمكن لـTraffic Manager بدء اتصال TCP وانتظار استجابة من نقطة النهاية. إذا ردت نقطة النهاية على طلب الاتصال باستجابة لإنشاء الاتصال، ضمن فترة المهلة، فسيتم وضع علامة سليمة على نقطة النهاية هذه.

ما هي الاستجابات المحددة المطلوبة من نقطة النهاية عند استخدام مراقبة TCP؟

عند استخدام مراقبة TCP، يقوم Traffic Manager بتشغيل مصافحة TCP ثلاثية الاتجاهات من خلال إرسال طلب SYN إلى نقطة النهاية عند المنفذ المحدد. ثم ينتظر استجابة SYN-ACK من نقطة النهاية لفترة زمنية (محددة في إعدادات المهلة).

  • إذا تم تلقي استجابة SYN-ACK خلال فترة المهلة المحددة في إعدادات المراقبة، فإن نقطة النهاية هذه تعد سليمة. FIN أو FIN-ACK هو الاستجابة المتوقَّعة من Traffic Manager عندما يقوم بإنهاء مأخذ التوصيل بشكل منتظم.
  • إذا تم تلقي استجابة SYN-ACK بعد المهلة المحددة، يستجيب Traffic Manager مع RST لإعادة تعيين الاتصال.

ما مدى سرعة نقل "Traffic Manager" للمستخدمين بعيداً عن نقطة نهاية غير سليمة؟

يوفر Traffic Manager إعدادات متعددة يمكن أن تساعدك على التحكم في سلوك تجاوز الفشل لملف تعريف Traffic Manager كما يلي:

  • يمكنك تحديد أن Traffic Manager تحقق في نقاط النهاية بشكل أكثر تكراراً عن طريق تعيين "الفاصل الزمني للاختبار" في 10 ثوانٍ. ويضمن ذلك أن أي نقطة نهاية غير سليمة يمكن اكتشافها في أقرب وقت ممكن.
  • يمكنك تحديد مدة الانتظار قبل انتهاء مهلة طلب الفحص الصحي (الحد الأدنى لقيمة المهلة هو 5 ثوانٍ).
  • يمكنك تحديد عدد مرات الفشل التي يمكن أن تحدث قبل وضع علامة غير سليمة على نقطة النهاية. يمكن أن تكون هذه القيمة منخفضة بمقدار 0، وفي هذه الحالة تكون نقطة النهاية غير سليمة بمجرد فشلها في أول تحقق عن السلامة. غير أن استخدام القيمة الدنيا 0 بالنسبة إلى عدد حالات الفشل المسموح بها يمكن أن يؤدي إلى إزالة نقاط نهاية للتناوب بسبب أي مسائل عابرة قد تحدث وقت التحقيق.
  • يمكنك تحديد عمر الحزمة (TTL) لاستجابة DNS لتكون منخفضة بمقدار 0. يعني القيام بذلك أنه لا يمكن لمحللات DNS تخزين الاستجابة مؤقتا ويحصل كل استعلام جديد على استجابة تتضمن أحدث المعلومات الصحية التي لدى Traffic Manager.

باستخدام هذه الإعدادات، يمكن لـ Traffic Manager توفير عمليات تجاوز الفشل في أقل من 10 ثوانٍ بعد أن تصبح نقطة النهاية غير سليمة ويتم إجراء استعلام DNS مقابل ملف التعريف المطابق.

كيف يمكنني تحديد إعدادات مراقبة مختلفة لنقاط نهاية مختلفة في ملف تعريف؟

إعدادات مراقبة Traffic Manager على مستوى ملف التعريف. إذا كنت بحاجة إلى استخدام إعداد مراقبة مختلف لنقطة نهاية واحدة فقط، يمكن القيام بذلك من خلال جعل نقطة النهاية هذه ملف تعريف متداخل والتي تختلف إعدادات المراقبة الخاصة به عن ملف التعريف الأصلي.

كيف يمكن تعيين رؤوس HTTP إلى عمليات التحقق من صحة Traffic Manager إلى نقاط النهاية الخاصة بي؟

يسمح لك Traffic Manager بتحديد الرؤوس المخصصة في عمليات التحقق من صحة HTTP(S) التي تهيئها إلى نقاط النهاية الخاصة بك. إذا كنت تريد تحديد رأس مخصص، يمكنك عمل ذلك على مستوى ملف التخصيص (يمكن تطبيقه على كل نقاط النهاية) أو تعيينه على مستوى نقطة النهاية. إذا تم تعريف رأس في كلا المستويين، فإن العنوان المحدد على مستوى نقطة النهاية يتجاوز مستوى ملف التعريف 1. إحدى حالات الاستخدام الشائعة لهذا هو تحديد عناوين المضيف بحيث يمكن توجيه طلبات Traffic Manager بشكل صحيح إلى نقطة نهاية مستضافة في بيئة متعددة المستأجرين. تتمثل حالة استخدام أخرى لهذا في تحديد طلبات Traffic Manager من سجلات طلبات HTTP(S) لنقطة نهاية ما

ما هو رأس المضيف الذي تستخدمه فحوصات السلامة في نقطة النهاية؟

في حالة عدم توفير إعداد رأس مضيف مخصص، يكون رأس المضيف المستخدم من قِبَل Traffic Manager هو اسم DNS لهدف نقطة النهاية المكون في ملف التعريف، إذا كان ذلك متوفراً.

ما هي عناوين IP التي تنشأ منها فحوص السلامة؟

راجع هذه المقالة لمعرفة كيفية استرداد قوائم عناوين IP التي يمكن إنشاء عمليات التحقق من سلامة Traffic Manager منها. يمكنك استخدام REST API، أو Azure CLI، أو Azure PowerShell لاسترداد أحدث قائمة. راجع عناوين IP المدرجة للتأكد من السماح بالاتصالات الواردة من عناوين IP هذه عند نقاط النهاية للتحقق من حالة سلامتها.

مثال باستخدام Azure PowerShell:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

إشعار

قد تتغير عناوين IP العامة دون إشعار. تأكد من استرداد أحدث المعلومات باستخدام واجهة برمجة تطبيقات اكتشاف علامة الخدمة أو ملف JSON القابل للتنزيل.

كم عدد فحوصات السلامة لنقطة النهاية التي يمكنني توقعها من Traffic Manager؟

يعتمد عدد فحوصات السلامة لـ "Traffic Manager" في الوصول إلى نقطة النهاية الخاصة بك على ما يلي:

  • القيمة التي قمت بتعيينها لفترة المراقبة (الفترة الأصغر تعني المزيد من طلبات الهبوط على نقطة النهاية في أي فترة زمنية محددة).
  • عدد المواقع التي تنشأ منها تحققات السلامة (عناوين IP التي يمكنك توقع هذه التحققات منها مدرجة في الأسئلة الشائعة السابقة).

كيف يمكن أن يتم إخطاري إذا تعطلت إحدى نقاط النهاية؟

أحد المقاييس التي يقدمها Traffic Manager هو حالة السلامة لنقاط النهاية في ملف تعريف. يمكنك أن ترى هذا على أنه تجميع لكل نقاط النهاية داخل ملف تخصيص (على سبيل المثال، 75٪ من نقاط النهاية سليمة)، أو على كل مستوى نقطة نهاية. يتم عرض مقاييس Traffic Manager من خلال Azure Monitor ويمكنك استخدام قدرات التنبيه الخاصة به للحصول على إعلامات عند حدوث تغيير في الحالة الصحية لنقطة النهاية. لمزيد من المعلومات، راجع تنبيهات وقياسات إدارة نسبة استخدام الشبكة.

ملفات تعريف متداخلة لـ Traffic Manager

كيف يمكنني تكوين ملفات التعريف المتداخلة؟

يمكن تكوين ملفات تعريف Traffic Manager المتداخلة باستخدام كل من أوامر Azure Resource Manager، وAzure REST APIs، وAzure PowerShell cmdlets، وAzure CLI عبر الأنظمة الأساسية. كما أنها مدعومة عبر مدخل Azure الجديد.

كم عدد طبقات التداخل التي يدعمها Traffic Manger؟

يمكنك تداخل ملفات تعريف يصل عمقها إلى 10 مستويات. "التكرارات الحلقية" غير مسموح بها.

هل يمكنني مزج أنواع نقاط النهاية الأخرى مع ملفات تعريف تابعة متداخلة، في نفس ملف تعريف Traffic Manager؟

نعم. لا توجد قيود على كيفية دمج نقاط النهاية من أنواع مختلفة داخل ملف تعريف.

كيف ينطبق نموذج الفوترة على ملفات التعريف المتداخلة؟

لا يوجد تأثير سلبي على التسعير لاستخدام ملفات التعريف المتداخلة.

تتضمن فوترة Traffic Manager مكونَين: عمليات التحقق من سلامة نقطة النهاية، والملايين من استعلامات DNS

  • عمليات التحقق من صحة نقطة النهاية: لا توجد رسوم على ملف تعريف تابع عند تكوينه كنقطة نهاية في ملف تعريف أصل. تتم عادة فوترة رصد نقاط النهاية في الملف الفرعي.
  • استعلامات DNS: يتم حساب كل استعلام مرة واحدة فقط. يتم حساب استعلام مقابل ملف تعريف أصل يرجع نقطة نهاية من ملف تعريف تابع مقابل ملف التعريف الأصلي فقط.

للحصول على التفاصيل الكاملة، راجع صفحة التسعيرTraffic Manager.

هل هناك تأثير "الأداء" لملفات التعريف المتداخلة؟

لا، لا يوجد تأثير على الأداء يتم تكبده عند استخدام ملفات التعريف المتداخلة.

تعبر خوادم أسماء Traffic Manager التسلسل الهيكلي لملف التعريف داخليّاً عند معالجة كل استعلام DNS. يمكن أن يتلقى استعلام DNS إلى ملف تعريف أصل استجابة DNS مع نقطة نهاية من ملف تعريف تابع. يتم استخدام سجل CNAME واحد سواء كنت تستخدم ملف تعريف واحد أو ملفات تعريف متداخلة. ليست هناك حاجة لإنشاء سجل CNAME لكل ملف تعريف في التسلسل الهرمي.

كيف يحسب "Traffic Manager" سلامة نقطة نهاية متداخلة في ملف تعريف أصل؟

لا يقوم الملف الشخصي الأصل بإجراء فحوصات سلامة على الفرعي مباشرة. وبدلاً من ذلك، يتم استخدام سلامة نقاط نهاية ملف التعريف الفرعي لحساب السلامة العامة لملف التعريف الفرعي. يتم نشر هذه المعلومات في التسلسل الهرمي لملف التعريف المتداخل لتحديد صحة نقطة النهاية المتداخلة. يستخدم ملف التعريف الأصلي هذه الصحة المجمعة لتحديد ما إذا كان يمكن توجيه حركة المرور إلى ملف التعريف الفرعي.

يوضح الجدول التالي سلوك عمليات التحقق من سلامة Traffic Manager لنقطة نهاية متداخلة.

حالة مراقب ملف تعريف فرعي حالة مراقب نقطة النهاية الأصل ملاحظات
مُعطل. تم تعطيل التشكيل الجانبي لملف التعريف الفرعي. متوقفة حالة نقطة النهاية الأصل متوقفة، وليست معطلة. الحالة معطل محجوزة للإشارة إلى أنك قمت بتعطيل نقطة النهاية في ملف التعريف الأصل.
متدهورة. توجد نقطة نهاية ملف تعريف تابع واحدة على الأقل في حالة متدهورة. عبر الإنترنت: عدد نقاط النهاية عبر الإنترنت في ملف التعريف التابع هو على الأقل قيمة MinChildEndpoints.
نقطة نهاية الفحص: عدد نقاط نهاية CheckingEndpoint في ملف التعريف التابع هو على الأقل قيمة MinChildEndpoints.
المتدهورة: خلاف ذلك.		 يتم توجيه حركة مرور البيانات إلى نقطة نهاية CheckingEndpoint للحالة. إذا تم تعيين MinChildEndpoints إلى مستوى أعلى من اللازم، فإن نقطة النهاية تكون دائماً متدهورة.
متصل. نقطة نهاية ملف تعريف تابع واحدة على الأقل هي حالة متصل بالإنترنت Online. لا توجد نقطة نهاية في الحالة متدهورة Degraded. انظر أعلاه.
CheckingEndpoints. نقطة نهاية ملف تعريف تابع واحدة على الأقل هي 'CheckingEndpoint'. لا توجد نقاط نهاية 'متصلة' أو 'متدهورة' مثل أعلاه.
غير نشط. تكون كافة نقاط نهاية ملف التعريف الفرعي إما معطلة أو متوقفة، أو لا يحتوي ملف التعريف هذا على نقاط نهاية. متوقفة

هام

عند إدارة ملفات التعريف التابعة ضمن ملف تعريف أصل في Azure Traffic Manager، يمكن أن تحدث مشكلة إذا قمت بتعطيل ملفي تعريف تابعين وتمكينهما في نفس الوقت. إذا حدثت هذه الإجراءات في نفس الوقت، فقد تكون هناك فترة قصيرة عند تعطيل نقطتي النهاية، مما يؤدي إلى إدخال ملف التعريف الأصل في حالة اختراق.

لتجنب هذه المشكلة، يجب توخي الحذر عند إجراء تغييرات متزامنة على ملفات التعريف التابعة. ضع في اعتبارك التقسيم المرحلي لهذه الإجراءات قليلا لمنع الاضطرابات غير المقصودة في تكوين إدارة نسبة استخدام الشبكة.

لماذا لا يمكنني إضافة نقاط نهاية الدعم الموسع لخدمات Azure Cloud إلى ملف تعريف Traffic Manager الخاص بي؟

لإضافة نقاط نهاية Azure Cloud Extended إلى ملف تعريف Traffic Manager، يجب أن يكون لدى مجموعة الموارد توافق مع واجهة برمجة تطبيقات Azure Service Management (ASM). يجب أن تلتزم ملفات التعريف الموجودة في مجموعة الموارد القديمة بمعايير واجهة برمجة تطبيقات ASM، والتي تحظر تضمين نقاط نهاية عنوان IP العام أو نقاط النهاية من اشتراك مختلف عن اشتراك ملف التعريف. لحل هذه المشكلة، ضع في اعتبارك نقل ملف تعريف Traffic Manager والموارد المقترنة إلى مجموعة موارد جديدة متوافقة مع واجهة برمجة تطبيقات ASM.

الخطوات التالية: