الأسئلة المتداولة (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 تتكامل مع التطبيقات على مستوى 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)، عند إجراء عمليات البحث عن طرق التوجيه الجغرافي والأداء والشبكة الفرعية، يأخذ مدير نسبة استخدام الشبكة أيضاً في الاعتبار عنوان الشبكة الفرعية للعميل إذا يتم تضمينه في الاستعلام بواسطة المحلل الذي يقوم بالطلب نيابة عن المستخدم النهائي.
وعلى وجه التحديد، RFC 7871 - الشبكة الفرعية للعميل في استعلامات DNS التي توفر آلية ملحق لـ DNS (EDNS0) التي يمكنها تمرير عنوان الشبكة الفرعية للعميل من المحددات التي تدعمها.

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

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

  • يقلل 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 Manger.

أسلوب توجيه نسبة استخدام الشبكة الجغرافية لـ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 لإنشاء ملفات تعريف لنوع التوجيه الجغرافي أو تعيين مناطق جغرافية لنقاط النهاية. إذا تم استخدام إصدار أقدم من API لاسترداد ملفات التعريف من اشتراك Azure، فلن يتم إرجاع أي ملف تعريف لنوع التوجيه الجغرافي. بالإضافة إلى ذلك، عند استخدام إصدارات أقدم من واجهة برمجة التطبيقات، فإن أي ملف تعريف يتم إرجاعه يحتوي على نقاط نهاية مع تعيين منطقة جغرافية، لا يتم عرض تعيين المنطقة الجغرافية الخاص به.

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

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

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

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

تستخدم أجهزة المستخدم النهائي عادةً محلل DNS لإجراء بحث DNS نيابة عنها. إن IP الصادر لمثل هذه المحددات هو ما يراه Traffic Manager على أنه IP المصدر. بالإضافة إلى ذلك، تبحث طريقة توجيه الشبكة الفرعية أيضاً في معرفة ما إذا كانت هناك معلومات EDNS0 Extended Client Subnet (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 من كل التوصيفات عندما تعرضها من خلال مدخل Microsoft 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 التي أريد قياسها فقط؟

لا، في كل مرة يتم استدعاؤها، يقيس البرنامج النصي لقياسات المستخدم الحقيقي مجموعة من ست مناطق 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 بشكل منفصل عن جزء Real User Measurement، ورغم أنه من الجيد وجودهما في نفس موقع الويب، فلا داعي لذلك.

هل أحتاج إلى استضافة أي خدمة على مناطق 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 View هي إحدى ميزات Traffic Manager التي تساعدك على فهم المزيد عن المستخدمين وكيف تكون تجربتهم. هو يستخدم الاستعلامات التي يتلقاها Traffic Manager وجداول معلومات زمن الوصول للشبكة التي تحتفظ بها الخدمة لتزويدك بما يلي:

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

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

كيف يمكنني الاستفادة من استخدام Traffic View؟

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

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

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

هل تستخدم طريقة Traffic View معلومات الشبكة الفرعية لعميل EDNS؟

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

كم يوماً من البيانات يستخدم Traffic View؟

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

كيف تعالج طريقة عرض Traffic View نقاط النهاية الخارجية؟

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

هل أحتاج إلى تمكين Traffic View لكل ملف تعريف في اشتراكي؟

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

ملاحظة

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

كيف يمكنني إيقاف تشغيل Traffic View؟

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

كيف تعمل فوترة Traffic View؟

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

نقاط نهاية Traffic Manager

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

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

بالنسبة لأنواع نقاط النهاية الأخرى، من الممكن استخدام Traffic Manager مع نقاط نهاية من أكثر من اشتراك واحد. في Azure 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 مباشرة إلى إدارة المرور. وبدلاً من ذلك، يستخدم العميل خدمة DNS متكررة. يرسل عميل IPv6 فقط الطلبات إلى خدمة DNS العودية عبر IPv6. يجب أن تكون الخدمة المتكررة بعد ذلك قادرة على الاتصال بخوادم أسماء Traffic Manager باستخدام IPv4. يستجيب Traffic Manager باسم DNS أو عنوان IP لنقطة النهاية.

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

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

كيف يمكنني نقل نقاط نهاية 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 عمومي كموقع لها، متجاوزةً الوضع الافتراضي لمجموعة الموارد.

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

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

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

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

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

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

  • لم يتم التحقق من صحة الشهادات من جانب الخادم
  • لم يتم التحقق من صحة الشهادات من جانب الخادم 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 A / CNAME نقطة النهاية الهدف
A AAAA NODATA
AAAA AAAA / CNAME نقطة النهاية الهدف
AAAA A NODATA
CNAME CNAME نقطة النهاية الهدف
CNAME A / AAAA NODATA

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

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

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

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

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

عندما يتم إيقاف نقطة نهاية تطبيق ويب 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% من نقاط النهاية سليمة)، أو على كل مستوى نقطة نهاية. يتم عرض قياسات إدارة نسبة استخدام الشبكة من خلال مراقب Azure ويمكنك استخدام إمكانيات التنبيه الخاصة بها للحصول على إشعارات عند حدوث تغيير في الحالة الصحية لنقطة النهاية الخاصة بك. لمزيد من المعلومات، راجع تنبيهات وقياسات إدارة نسبة استخدام الشبكة.

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

كيف يمكنني تكوين التشكيلات الجانبية المتداخلة؟

يمكن تكوين ملفات تعريف Traffic Manager المتداخلة باستخدام كل من أوامر Azure Resource Manager، وAzure REST APIs، وAzure PowerShell cmdlets، وAzure CLI عبر الأنظمة الأساسية. يتم دعمها أيضاً عبر مدخل Microsoft 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'. لا توجد نقاط نهاية 'متصلة' أو 'متدهورة' نفس ما سبق.
غير نشط. تكون كافة نقاط نهاية ملف التعريف الفرعي إما معطلة أو متوقفة، أو لا يحتوي ملف التعريف هذا على نقاط نهاية. متوقف

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