Share via

الموثوقية في Azure Communications Gateway

  • مقالة

تضمن Azure Communications Gateway موثوقية خدمتك باستخدام آليات تكرار Azure وسلوك إعادة المحاولة الخاصة ب SIP. يجب أن تفي شبكتك بمتطلبات محددة لضمان توفر الخدمة.

نموذج التكرار لبوابة اتصالات Azure

تتكون عمليات نشر Production Azure Communications Gateway (تسمى أيضا عمليات التوزيع القياسية) من ثلاث مناطق منفصلة: منطقة إدارة ومنطقتين للخدمة. تتكون عمليات نشر المختبر من منطقة إدارة واحدة ومنطقة خدمة واحدة.

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

رسم تخطيطي لمنطقتين للخدمة، ومنطقة إدارة وموقعين لعامل التشغيل.

مناطق الخدمة

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

تتضمن عمليات نشر Production Azure Communications Gateway منطقتين للخدمة يتم توزيعهما في وضع نشط-نشط (كما هو مطلوب من قبل توصيل المشغل وTeams الهاتف Mobile). يتم توفير تجاوز الفشل السريع بين مناطق الخدمة على مستوى البنية الأساسية/IP وعلى مستوى التطبيق (SIP/RTP/HTTP).

تحتوي مناطق الخدمة أيضا على البنية الأساسية لواجهة برمجة تطبيقات تزويد Azure Communications Gateway.

تلميح

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

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

عمليات توزيع المعمل لها منطقة خدمة واحدة.

متطلبات توجيه المكالمات

توفر Azure Communications Gateway نموذج تكرار "ناجح" : يتم إنهاء المكالمات التي يعالجها النظراء الفاشلون، ولكن يتم توجيه المكالمات الجديدة إلى نظراء سليمين. يعكس هذا النموذج نموذج التكرار الذي يوفره Microsoft Teams.

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

رسم تخطيطي لاثنين من مواقع المشغل ومنطقتين للخدمة. تتصل منطقتا الخدمة بكلا الموقعين، مع التوجيهات الأساسية والثانوية.

يجب أن تتصل عمليات نشر المختبر بموقع واحد في شبكتك.

توفر كل منطقة خدمة Azure Communications Gateway سجل SRV. يحتوي هذا السجل على جميع أقران SIP الذين يقدمون وظائف SBC (لتوجيه المكالمات إلى خدمات الاتصالات) داخل المنطقة. يمكن أن يشير سجل SRV هذا إلى أي عنوان IP في نطاق IP /28 الذي يوفره لك فريق الإلحاق.

إذا كانت Azure Communications Gateway تتضمن نقطة تحكم الجوال (MCP)، فإن كل منطقة خدمة توفر سجل SRV إضافيا ل MCP. يحتوي كل سجل MCP لكل منطقة على MCP داخل المنطقة على أولوية قصوى وMCP في المنطقة الأخرى بأولوية أقل.

يجب على كل موقع في شبكتك:

  • إرسال نسبة استخدام الشبكة إلى منطقة خدمة Azure Communications Gateway المحلية بشكل افتراضي.
  • حدد موقع نظراء Azure Communications Gateway داخل منطقة باستخدام DNS SRV، كما هو موضح في RFC 3263.
    • قم بإجراء بحث DNS SRV على اسم المجال لاتصال منطقة الخدمة بشبكتك، باستخدام _sip._tls.<regional-FQDN-from-portal>. استبدل <regional-FQDN-from-portal> ب FQDNs لكل منطقة من حقول Hostname في صفحة Overview للمورد الخاص بك في مدخل Microsoft Azure. على سبيل المثال، إذا كان التوزيع يستخدم commsgw.azure.com أسماء المجالات، فابحث _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com عن المنطقة الأولى.
    • إذا كان بحث SRV يرجع أهدافا متعددة، فاستخدم وزن وأولوية كل هدف لتحديد هدف واحد.
  • إرسال مكالمات جديدة إلى نظراء Azure Communications Gateway المتوفرين.
  • كن قادرا على تلقي نسبة استخدام الشبكة من أي عنوان IP في كل نطاق من نطاقات IP المقترنة ببوابة اتصالات Azure.

عندما توجه شبكتك المكالمات إلى أقران SIP لبوابة الاتصالات Azure لدالة SBC، يجب أن:

  • استخدم خيارات SIP (أو مجموعة من الخيارات وحركة مرور SIP) لمراقبة توفر نظراء SIP لبوابة اتصالات Azure.
  • أعد محاولة INVITEs التي تلقت 408 استجابات أو 503 استجابة أو 504 استجابات أو لم تتلق استجابات، عن طريق إعادة توجيهها إلى نظراء آخرين متاحين في الموقع المحلي. البحث عن منطقة الخدمة الأخرى (المحددة بواسطة سجل SRV الخاص بالمنطقة الأخرى) فقط إذا فشل جميع النظراء في منطقة الخدمة المحلية.
  • لا تقم أبدا بإعادة محاولة المكالمات التي تتلقى استجابات الخطأ بخلاف 408 و503 و504.

إذا كان توزيع Azure Communications Gateway يتضمن نقطة تحكم متنقلة متكاملة (MCP)، فيجب أن تفعل شبكتك كما يلي ل MCP:

  • اكتشف متى يكون MCP في منطقة غير متوفر، وضع علامة على أهداف سجل SRV لتلك المنطقة على أنها غير متوفرة، ثم أعد المحاولة بشكل دوري لتحديد متى تتوفر المنطقة مرة أخرى. لا يستجيب MCP لخيارات SIP.
  • التعامل مع استجابات 5xx من MCP وفقا لنهج مؤسستك. على سبيل المثال، يمكنك إعادة محاولة الطلب، أو يمكنك السماح بمتابعة الاستدعاء دون المرور عبر Azure Communications Gateway وإلى نظام هاتف Microsoft.

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

مناطق الإدارة

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

دعم منطقة القابلية للوصول

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

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

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

تجربة تعطل المنطقة لمناطق الخدمة

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

تجربة تعطل المنطقة لمنطقة الإدارة

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

التعافي من الكوارث: الرجوع إلى مناطق أخرى

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

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

يصف هذا القسم سلوك Azure Communications Gateway أثناء انقطاع التيار الكهربائي على مستوى المنطقة.

التعافي من الكوارث: تجاوز الفشل عبر المناطق لمناطق الخدمة

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

توفر الدالة SBC في Azure Communications Gateway استطلاع OPTIONS للسماح لشبكتك بتحديد توفر النظير. بالنسبة إلى MCP، يجب أن تكون شبكتك قادرة على الكشف عن وقت عدم توفر MCP، وإعادة المحاولة بشكل دوري لتحديد وقت توفر MCP مرة أخرى. لا يستجيب MCP لخيارات SIP.

تزويد عملاء API بالاتصال ب Azure Communications Gateway باستخدام اسم المجال الأساسي للتوزيع الخاص بك. يحتوي سجل DNS لهذا المجال على مدة البقاء (TTL) تبلغ 60 ثانية. عند فشل منطقة ما، يقوم Azure بتحديث سجل DNS للإشارة إلى منطقة أخرى، بحيث يتلقى العملاء الذين يقومون بالبحث عن DNS جديد تفاصيل المنطقة الجديدة. نوصي بالتأكد من أن العملاء يمكنهم إجراء بحث DNS جديد وإعادة محاولة طلب بعد 60 ثانية من انتهاء المهلة أو استجابة 5xx.

تلميح

لا تقدم عمليات توزيع المختبر تجاوز الفشل عبر المناطق (لأن لديها منطقة خدمة واحدة فقط).

التعافي من الكوارث: تجاوز الفشل عبر المناطق لمناطق الإدارة

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

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

اختيار مناطق الإدارة والخدمات

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

ضع في اعتبارك النقاط التالية عند اختيار مواقع منطقة الخدمة:

  • حدد من قائمة مناطق Azure المتوفرة. يمكنك مشاهدة مناطق Azure التي يمكن تحديدها كمناطق خدمة في صفحة المنتجات حسب المنطقة .
  • اختر المناطق القريبة من أماكن عملك ومواقع التناظر بين شبكتك وMicrosoft لتقليل زمن انتقال المكالمات.
  • تفضل الأزواج الإقليمية لتقليل وقت الاسترداد في حالة حدوث انقطاع متعدد المناطق.

اختر منطقة إدارة من القائمة التالية:

  • شرق الولايات المتحدة
  • غرب وسط الولايات المتحدة
  • أوروبا الغربية
  • جنوب المملكة المتحدة
  • وسط الهند
  • وسط كندا
  • شرق أستراليا

يمكن تجميع مناطق الإدارة مع مناطق الخدمة. نوصي باختيار منطقة الإدارة الأقرب إلى مناطق الخدمة.

إشعار

إذا كنت تقوم بتمكين Azure Operator Call Protection Preview، فقد لا تكون منطقة الخدمة التي تحددها هي منطقة Azure حيث يتم نشر موارد الدعم. راجع منتجات Azure حسب المنطقة للحصول على قائمة مناطق خدمة Azure Operator Call Protection المدعومة حاليا وتحدث إلى فريق الإلحاق إذا كانت لديك أي أسئلة حول المنطقة المحددة.

اتفاقيات مستوى الخدمة

يتم تنفيذ تصميم الموثوقية الموضح في هذا المستند بواسطة Microsoft وهو غير قابل للتكوين. لمزيد من المعلومات حول اتفاقيات مستوى خدمة Azure Communications Gateway (SLAs)، راجع اتفاقية مستوى الخدمة لبوابة اتصالات Azure.

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