إدارة نسبة استخدام الشبكة Azure مع استرداد موقع Azure
تتيح لك Azure Traffic Manager إمكانية التحكم في توزيع حركة نقل البيانات على مستوى نقاط النهاية في التطبيقات الخاصة بك. إن نقطة النهاية عبارة عن أي خدمة تعمل عبر الإنترنت وتتم استضافتها داخل Azure أو خارجها.
تستخدم إدارة نسبة استخدام الشبكة نظام أسماء المجالات (DNS) لتوجيه طلبات العملاء إلى نقطة النهاية الأكثر ملاءمة، استنادا إلى أسلوب توجيه حركة المرور وصحة نقاط النهاية. يوفر Traffic Manager مجموعة من طرق توجيه نسبة استخدام الشبكة وخيارات مراقبة نقطة النهاية؛ لتناسب احتياجات التطبيقات المختلفة، ونماذج تجاوز الفشل التلقائية. ويتصل العملاء بعدها مباشرة بنقطة النهاية المحددة. مدير استخدام الشبكة ليس وكيلا أو بوابة، ولا يرى حركة المرور التي تمر بين العميل والخدمة.
توضح هذه المقالة كيفية الجمع بين التوجيه الذكي ل Azure Traffic Monitor وإمكانات التعافي من الكوارث والترحيل القوية في Azure Site Recovery.
تجاوز الفشل الداخلي ل Azure
بالنسبة للسيناريو الأول، ضع في اعتبارك الشركة A التي لديها كل البنية التحتية للتطبيقات الخاصة بها تعمل في بيئتها الداخلية. لأسباب تتعلق باستمرارية العمل والامتثال، تقرر الشركة A استخدام استرداد موقع Azure لحماية تطبيقاتها.
تقوم الشركة A بتشغيل التطبيقات باستخدام نقاط النهاية العامة وتريد القدرة على إعادة توجيه حركة المرور بسلاسة إلى Azure في حدث الكوارث. أسلوب توجيه نسبة استخدام الشبكة الأولوية في إدارة حركة مرور Azure يسمح للشركة A لتنفيذ هذا النمط تجاوز الفشل بسهولة.
الإعداد كما يلي:
- تقوم الشركة A بإنشاء ملف تعريف مدير حركة المرور.
- باستخدام طريقة توجيه الأولوية ، تقوم الشركة A بإنشاء نقطتي نهاية - أساسي للمحليين وتجاوز الفشل ل Azure. يتم تعيين الأولوية الأولى للابتدائي ويتم تعيين تجاوز الفشل الأولوية 2.
- منذ استضافت نقطة النهاية الأساسية خارج أزور، يتم إنشاء نقطة النهاية كنقطة نهاية خارجية.
- مع استرداد موقع Azure، لا يوجد لدى موقع Azure أية أجهزة ظاهرية أو تطبيقات تعمل قبل تجاوز الفشل. لذلك، يتم إنشاء نقطة النهاية تجاوز الفشل أيضا كنقطة نهاية خارجية.
- بشكل افتراضي، يتم توجيه حركة مرور المستخدم إلى التطبيق المحلي لأن نقطة النهاية هذه لها الأولوية القصوى المقترنة به. لا يتم توجيه أي نسبة استخدام الشبكة إلى Azure إذا كانت نقطة النهاية الأساسية سليمة.
في حالة حدوث كارثة، يمكن للشركة A تشغيل تجاوز الفشل إلى Azure واسترداد تطبيقاتها على Azure. عندما يكتشف إدارة حركة مرور Azure أن نقطة النهاية الأساسية لم تعد سليمة، فإنه يستخدم نقطة النهاية تجاوز الفشل تلقائيا في استجابة DNS ويتصل المستخدمون بالتطبيق المسترد على Azure.
اعتمادا على متطلبات العمل، يمكن للشركة A اختيار تردد بحث أعلى أو أقل للتبديل بين أماكن العمل إلى Azure في حالة الكوارث، وضمان الحد الأدنى من وقت التوقف للمستخدمين.
عند احتواء الكارثة، يمكن أن تفشل الشركة A من Azure إلى بيئتها الداخلية(VMware أو Hyper-V)باستخدام استرداد موقع Azure. الآن، عندما يكتشف "إدارة المرور" أن نقطة النهاية الأساسية سليمة مرة أخرى، فإنه يستخدم نقطة النهاية الأساسية تلقائيا في استجابات DNS الخاصة به.
الترحيل الداخلي إلى Azure
بالإضافة إلى استرداد البيانات بعد الكوارث، يتيح استرداد موقع Azure أيضا عمليات الترحيل إلى Azure. باستخدام إمكانات تجاوز الفشل الاختبارية القوية في Azure Site Recovery، يمكن للعملاء تقييم أداء التطبيق على Azure دون التأثير على بيئتهم المحلية. وعندما يكون العملاء على استعداد للهجرة، يمكنهم اختيار ترحيل أعباء العمل بالكامل معا أو اختيار الترحيل والتدرج تدريجيا.
يمكن استخدام طريقة التوجيه المرجح الخاصة ب Azure نسبة استخدام الشبكة لتوجيه جزء من حركة المرور الواردة إلى Azure مع توجيه الأغلبية إلى البيئة المحلية. يمكن أن يساعد هذا الأسلوب في تقييم أداء المقياس حيث يمكنك متابعة زيادة الوزن المعين ل Azure أثناء ترحيل المزيد والمزيد من أعباء العمل إلى Azure.
على سبيل المثال، تختار الشركة B الترحيل على مراحل، مع نقل بعض بيئة التطبيق الخاصة بها مع الاحتفاظ بالباقي في الموقع. خلال المراحل الأولية عندما تكون معظم البيئة في الموقع، يتم تعيين وزن أكبر للبيئة الداخلية. يقوم مدير استخدام الشبكة بإرجاع نقطة نهاية استنادا إلى الأوزان المعينة إلى نقاط النهاية المتوفرة.
أثناء الترحيل، تكون نقطتا النهاية نشطتين ويتم توجيه معظم حركة المرور إلى البيئة المحلية. ومع استمرار الترحيل، يمكن تعيين وزن أكبر إلى نقطة النهاية على Azure، وأخيرا يمكن إلغاء تنشيط نقطة النهاية المحلية بعد الترحيل.
تجاوز الفشل Azure إلى Azure
على سبيل المثال، خذ بعين الاعتبار الشركة C التي لديها كافة البنية الأساسية للتطبيقات الخاصة به تشغيل Azure. لأسباب تتعلق باستمرارية العمل والامتثال، تقرر الشركة A استخدام استرداد موقع Azure لحماية تطبيقاتها.
تقوم الشركة C بتشغيل التطبيقات باستخدام نقاط النهاية العامة وتريد القدرة على إعادة توجيه حركة المرور بسلاسة إلى منطقة Azure مختلفة في حدث الكوارث. تسمح طريقة توجيه حركة المرور ذات الأولوية لشركة الشركة ج بتنفيذ نمط تجاوز الفشل هذا بسهولة.
الإعداد كما يلي:
- تقوم الشركة C بإنشاء ملف تعريف مدير استخدام الشبكة.
- باستخدام طريقة توجيه الأولوية ، تقوم الشركة C بإنشاء نقطتي نهاية - أساسي لمنطقة المصدر (Azure East Asia) وتجاوز الفشل لمنطقة الاسترداد (Azure South East Asia). يتم تعيين الأولوية الأولى للابتدائي ويتم تعيين تجاوز الفشل الأولوية 2.
- نظرا لأن نقطة النهاية الأساسية مستضافة في Azure، يمكن أن تكون نقطة النهاية كنقطة نهاية Azure .
- مع استرداد موقع Azure، لا يوجد لدى موقع Azure أية أجهزة ظاهرية أو تطبيقات تعمل قبل تجاوز الفشل. لذلك، يمكن إنشاء نقطة النهاية تجاوز الفشل كنقطة نهاية خارجية.
- بشكل افتراضي، يتم توجيه نسبة استخدام الشبكة للمستخدم إلى تطبيق المنطقة المصدر (شرق آسيا) حيث أن نقطة النهاية هذه لها الأولوية القصوى المقترنة به. لا يتم توجيه نسبة استخدام الشبكة إلى منطقة الاسترداد إذا كانت نقطة النهاية الأساسية سليمة.
في حالة حدوث كارثة، يمكن تشغيل الشركة C تجاوز الفشل واسترداد تطبيقاتها على منطقة أزور الاسترداد. عندما يكتشف إدارة نسبة استخدام الشبكة Azure أن نقطة النهاية الأساسية لم تعد سليمة، فإنه يستخدم نقطة النهاية تجاوز الفشل تلقائيا في استجابة DNS ويتصل المستخدمون بالتطبيق المسترد في منطقة أزور الاسترداد (جنوب شرق آسيا).
اعتمادا على متطلبات العمل ، يمكن للشركة C اختيار تردد فحص أعلى أو أقل للتبديل بين مناطق المصدر والاسترداد ، وضمان الحد الأدنى من وقت التوقف عن العمل للمستخدمين.
عند احتواء الكارثة، يمكن أن تفشل الشركة C من منطقة أزور الاسترداد إلى منطقة Azure المصدر باستخدام استرداد موقع Azure. الآن، عندما يكتشف "إدارة استخدام الشبكة" أن نقطة النهاية الأساسية سليمة مرة أخرى، فإنه يستخدم نقطة النهاية الأساسية تلقائيا في استجابات DNS الخاصة به.
حماية تطبيقات المؤسسات متعددة المناطق
غالبا ما تعمل الشركات العالمية على تحسين تجربة العملاء من خلال تصميم تطبيقاتها لتلبية الاحتياجات الإقليمية. يمكن أن يؤدي التعريب وتقليل الكمون إلى تقسيم البنية التحتية للتطبيقات عبر المناطق. كما تلتزم المؤسسات بقوانين البيانات الإقليمية في بعض المناطق وتختار عزل جزء من البنية التحتية لتطبيقها داخل الحدود الإقليمية.
دعونا ننظر في مثال حيث قامت الشركة D بتقسيم نقاط نهاية التطبيق الخاصة بها لخدمة ألمانيا وبقية العالم بشكل منفصل. تستخدم الشركة D طريقة التوجيه الجغرافي الخاصة ب Azure ادارة استخدام الشبكة لإعداد ذلك. يتم توجيه أي حركة مرور تنشأ من ألمانيا إلى نقطة النهاية 1 ويتم توجيه أي حركة مرور تنشأ خارج ألمانيا إلى نقطة النهاية 2.
المشكلة في هذا الإعداد هي أنه إذا توقفت Endpoint 1 عن العمل لأي سبب من الأسباب، فلا توجد إعادة توجيه لحركة المرور إلى Endpoint 2. يستمر توجيه حركة المرور القادمة من ألمانيا إلى نقطة النهاية 1 بغض النظر عن صحة نقطة النهاية ، مما يترك المستخدمين الألمان دون الوصول إلى تطبيق الشركة D. وبالمثل، إذا كان نقطة النهاية 2 يذهب حاليا، لا يوجد إعادة توجيه حركة المرور إلى نقطة النهاية 1.
لتجنب الوقوع في هذه المشكلة وضمان مرونة التطبيق، تستخدم الشركة D ملفات تعريف إدارة حركة المرور المتداخلة مع استرداد موقع Azure. في إعداد ملف تعريف متداخل، لا يتم توجيه حركة المرور إلى نقاط النهاية الفردية، ولكن بدلا من ذلك إلى ملفات تعريف إدارة حركة المرور الأخرى. إليك كيفية عمل هذا الإعداد:
- بدلا من استخدام التوجيه الجغرافي مع نقاط النهاية الفردية، تستخدم بة استخدام الشبكةالشركة D التوجيه الجغرافي مع ملفات تعريف إدارة نس.
- يستخدم كل ملف تعريف تابع لإدارة استخدام الشبكة توجيه الأولوية مع نقطة نهاية أساسية ونقطة نهاية استرداد، وبالتالي تداخل توجيه الأولوية داخل التوجيه الجغرافي.
- لتمكين مرونة التطبيق، يستخدم كل توزيع حمل العمل استرداد موقع Azure إلى تجاوز الفشل إلى منطقة استرداد تستند في حالة حدوث كارثة.
- عندما يتلقى إدارة حركة المرور الأصل استعلام DNS، يتم توجيهه إلى إدارة حركة المرور التابعة ذات الصلة التي تستجيب للاستعلام باستخدام نقطة نهاية متوفرة.
على سبيل المثال، إذا فشلت نقطة النهاية في ألمانيا الوسطى، يمكن استرداد التطبيق بسرعة إلى شمال شرق ألمانيا. تعالج نقطة النهاية الجديدة حركة المرور القادمة من ألمانيا بأقل وقت توقف للمستخدمين. وبالمثل، يمكن معالجة انقطاع نقطة النهاية في أوروبا الغربية عن طريق استرداد حمل العمل للتطبيق إلى شمال أوروبا، مع معالجة إدارة حركة مرور Azure عمليات إعادة توجيه DNS إلى نقطة النهاية المتوفرة.
يمكن توسيع الإعداد أعلاه لتضمين مجموعات المنطقة ونقطة النهاية المطلوبة. إدارة نسبة استخدام الشبكة يسمح حتى 10 مستويات من التشكيلات الجانبية المتداخلة ولا يسمح الحلقات داخل التكوين المتداخلة.
اعتبارات هدف وقت الاسترداد (RTO)
في معظم المؤسسات، تتم معالجة إضافة سجلات DNS أو تعديلها إما بواسطة فريق منفصل أو من قبل شخص خارج المؤسسة. وهذا يجعل مهمة تغيير سجلات DNS صعبة للغاية. يختلف الوقت المستغرق لتحديث سجلات DNS بواسطة فرق أو مؤسسات أخرى تدير البنية التحتية ل DNS من مؤسسة إلى أخرى، ويؤثر على RTO للتطبيق.
باستخدام إدارة نسبة استخدام الشبكة، يمكنك تحميل العمل المطلوب لتحديثات DNS. لا يلزم اتخاذ إجراء يدوي أو مكتوب في وقت تجاوز الفشل الفعلي. يساعد هذا النهج في التبديل السريع (وبالتالي خفض RTO) بالإضافة إلى تجنب أخطاء تغيير DNS المكلفة التي تستغرق وقتا طويلا في حدث الكوارث. مع ادارة نسبة استخدام الشبكة ، حتى خطوة التراجع عن الفشل تلقائية ، والتي يجب إدارتها بشكل منفصل.
يمكن تعيين الفاصل الزمني الصحيح من خلال الفحص الصحي الفاصل الأساسي أو السريع اسقاط إلى حد كبير RTO أثناء تجاوز الفشل والحد من التوقف للمستخدمين.
يمكنك بالإضافة إلى ذلك تحسين قيمة وقت DNS إلى Live (TTL) لملف تعريف إدارة حركة المرور. TTL هي القيمة التي سيتم تخزين إدخال DNS مؤقتا من قبل عميل. لسجل، DNS لن يتم الاستعلام مرتين ضمن نطاق TTL. كل سجل DNS له TTL مقترن به. يؤدي تقليل هذه القيمة إلى المزيد من استعلامات DNS إلى مدير استخدام الشبكة ولكن يمكن أن يقلل من RTO عن طريق اكتشاف الانقطاعات بشكل أسرع.
TTL التي يواجهها العميل أيضا لا يزيد إذا زاد عدد محللات DNS بين العميل وملقم DNS الموثوق بها. تقوم محللات DNS "بالعد التنازلي" ل TTL وتمرير قيمة TTL فقط التي تعكس الوقت المنقضي منذ تخزين السجل مؤقتا. يضمن هذا تحديث سجل DNS في العميل بعد TTL بغض النظر عن عدد محللات DNS في السلسلة.
الخطوات التالية
- تعرف على المزيد حول طرق توجيهإدارة استخدام الشبكة .
- تعرف على المزيد حول ملفات تعريف إدارة الزيارات المتداخلة.
- تعرف على المزيد حول مراقبة نقطة النهاية.
- تعرف على المزيد حول خطط الاسترداد التلقائية لتجاوز فشل التطبيق.