ترحيل أحمال عمل Azure Kubernetes Service (AKS) وMySQL Flexible Server إلى دعم منطقة التوفر

  • مقالة

يصف هذا الدليل كيفية ترحيل Azure Kubernetes Service وأحمال عمل MySQL Flexible Server لإكمال دعم منطقة التوفر عبر جميع الخدمات التابعة. للحصول على قائمة كاملة بجميع تبعيات حمل العمل، راجع تبعيات خدمة حمل العمل.

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

يركز دليل الترحيل هذا بشكل أساسي على اعتبارات البنية الأساسية والتوافر لتشغيل البنية التالية على Azure:

Picture showing first part of workflow architecture

Picture showing second part of workflow architecture

تبعيات خدمة حمل العمل

لتوفير دعم كامل لحمل العمل لمناطق التوفر، يجب أن تدعم كل تبعية خدمة في حمل العمل مناطق التوفر.

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

تتكون بنية حمل عمل AKS وMySQL من تبعيات المكون التالية:

خدمة Azure Kubernetes ‏(AKS)

  • النطاق : تجمع عقدة النظام وتجمعات عقدة المستخدم هي مناطقية عند تحديد المناطق التي يتم نشر تجمعات العقدة فيها مسبقا أثناء وقت الإنشاء. نوصي بتحديد جميع المناطق الثلاث مسبقا للحصول على مرونة أفضل. يمكن إضافة المزيد من تجمعات عقد المستخدم التي تدعم مناطق التوفر إلى مجموعة AKS موجودة ومن خلال توفير قيمة للمعلمة zones .

  • المنطقة المكررة: يتم نسخ مكونات وحدة التحكم Kubernetes مثل etcd وخادم API و Scheduler و Controller Manager تلقائيا أو توزيعها عبر المناطق.

    إشعار

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

Azure Database for MySQL Flexible Server

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

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

Azure Standard Load Balancer أو Azure Application Gateway

Standard Load Balancer

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

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

  • النطاق: إذا كنت تقوم بتثبيت تجمعات العقد الخاصة بك إلى مناطق معينة مثل المنطقة 1 و2، يمكنك تحديد المنطقة 1 و2 مسبقا لعنون IP للواجهة الأمامية في موازن التحميل الموجود. قد يرجع سبب رغبتك في تثبيت تجمعات العقد إلى مناطق محددة إلى توفر سلسلة SKU مخصصة للجهاز الظاهري مثل M-series.

Azure Application Gateway

يتم دعم استخدام الوظيفة الإضافية وحدة تحكم الدخول لبوابة التطبيق مع مجموعة AKS الخاصة بك فقط على Application Gateway v2 SKUs (Standard و WAF). لفهم المزيد من الاعتبارات المتعلقة ب Azure Application Gateway، راجع تغيير حجم Application Gateway v2 وWAF v2.

النطاق: لاستخدام فوائد مناطق التوفر، نوصي بإنشاء مورد بوابة التطبيق في مناطق متعددة، مثل المنطقة 1 و2 و3. حدد جميع المناطق الثلاث للحصول على أفضل استراتيجية مرونة داخل المنطقة. ومع ذلك، لتتوافق مع تجمعات عقدة الواجهة الخلفية، يمكنك تثبيت تجمعات العقد الخاصة بك بمناطق معينة عن طريق تحديد المنطقة 1 و2 مسبقا أثناء إنشاء مورد App Gateway. قد يرجع سبب رغبتك في تثبيت تجمعات العقد إلى مناطق محددة إلى توفر سلسلة SKU مخصصة للجهاز الظاهري مثل M-series.

التخزين المتكرر للمنطقة (ZRS)

  • نوصي بتكوين نظام مجموعة AKS الخاص بك باستخدام أقراص ZRS المدارة لأنها موارد زائدة عن الحاجة للمنطقة. يمكن جدولة وحدات التخزين في جميع المناطق.

  • تعلم Kubernetes عن مناطق توفر Azure من الإصدار 1.12. يمكنك نشر كائن PersistentVolumeClaim يشير إلى قرص Azure المدار في مجموعة AKS متعددة المناطق. سيهتم Kubernetes بجدولة أي جراب يدعي PVC هذا في منطقة التوفر الصحيحة.

  • بالنسبة لقاعدة بيانات Azure ل SQL، نوصي باستضافة ملفات البيانات والسجلات في تخزين المنطقة المكرر (ZRS). يتم نسخ هذه الملفات إلى خادم الاستعداد عبر النسخ المتماثل على مستوى التخزين المتوفر مع ZRS.

جدار حماية Azure

النطاق: لاستخدام فوائد مناطق التوفر، نوصي بإنشاء مورد Azure Firewall في مناطق متعددة، مثل المنطقة 1 و2 و3. نوصي بتحديد جميع المناطق الثلاث للحصول على أفضل استراتيجية مرونة داخل المنطقة.

Azure Bastion

إقليمي: يتم نشر Azure Bastion داخل VNets أو شبكات ظاهرية مقترنة بمنطقة Azure. لمزيد من المعلومات، الأسئلة المتداولة حول se Bastion.

Azure Container Registry (ACR)

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

ذاكرة التخزين المؤقت في Azure لـ Redis

المنطقة المكررة: تدعم ذاكرة التخزين المؤقت Azure ل Redis تكوينات المنطقة المكررة في مستويات Premium وEnterprise. تضع ذاكرة التخزين المؤقت المكررة في المنطقة العقد الخاصة بها عبر مناطق توفر مختلفة في نفس المنطقة.

Microsoft Entra ID

Global: معرف Microsoft Entra هو خدمة عمومية ذات مستويات متعددة من التكرار الداخلي والاسترداد التلقائي. يتم نشر معرف Microsoft Entra في أكثر من 30 مركز بيانات حول العالم توفر مناطق التوفر حيث توجد. ويتزايد هذا العدد بسرعة مع نشر المزيد من المناطق.

Azure Key Vault

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

المنطقة المكررة: بالنسبة لمناطق Azure ذات مناطق التوفر وعدم وجود زوج من المناطق، يستخدم Key Vault التخزين المتكرر للمنطقة (ZRS) لنسخ محتويات خزنة المفاتيح ثلاث مرات داخل الموقع/المنطقة الواحدة.

اعتبارات حمل العمل

خدمة Azure Kubernetes ‏(AKS)

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

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

  • لأسباب تتعلق بالأداء مثل زمن الانتقال المنخفض، يمكن أن تكون الجرابات في نفس مركز البيانات داخل نفس منطقة التوفر. لتحديد موقع الجرابات في نفس مركز البيانات داخل نفس منطقة التوفر، يمكنك إنشاء تجمعات عقد المستخدم مع منطقة فريدة ومجموعة موضع التقارب. يمكنك إضافة مجموعة موضع التقارب (PPG) إلى مجموعة AKS موجودة عن طريق إنشاء تجمع عقدة عامل جديد وتحديد PPG. استخدم قيود انتشار طوبولوجيا الجراب للتحكم في كيفية انتشار الحجيرات في نظام مجموعة AKS عبر مناطق التوفر والعقد والمناطق.

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

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

    على سبيل المثال، قد تقرر استخدام Standard_M32ms ضمن M-series لعقد المستخدم لأن الخدمات المصغرة في التطبيق الخاص بك تتطلب إنتاجية عالية وزمن انتقال منخفض وأحجام الأجهزة الظاهرية المحسنة للذاكرة التي توفر أعدادا عالية من وحدات المعالجة المركزية الظاهرية وكميات كبيرة من الذاكرة. اعتمادا على منطقة التوزيع، عند تحديد حجم الجهاز الظاهري في مدخل Microsoft Azure، قد ترى أن حجم الجهاز الظاهري هذا مدعوم فقط في المنطقة 1 و2. يمكنك قبول تكوين المرونة هذا كمفاضلة مع الأداء العالي.

  • لا يمكنك تغيير حجم الجهاز الظاهري لتجمع عقدة بعد إنشائه. لمزيد من المعلومات حول قيود تجمع العقدة، راجع القيود.

Azure Database for MySQL Flexible Server

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

Picture showing zone selection for MySQL Flexible Servers

ذاكرة التخزين المؤقت في Azure لـ Redis

  • يوزع Azure Cache for Redis العقد في ذاكرة التخزين المؤقت المتكررة في المنطقة بطريقة الترتيب الدوري عبر مناطق التوفر التي حددتها.

  • لا يمكنك تحديث ذاكرة التخزين المؤقت Premium الموجودة لاستخدام تكرار المنطقة. لاستخدام تكرار المنطقة، يجب إعادة إنشاء ذاكرة التخزين المؤقت Azure ل Redis.

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

Picture showing three replicas for Azure Cache for Redis

اعتبارات الإصلاح بعد الكارثة

يتم استخدام مناطق التوفر للحصول على مرونة أفضل لتحقيق قابلية وصول عالية لحمل العمل الخاص بك داخل المنطقة الأساسية للتوزيع الخاص بك.

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

Picture showing secondary region deployment architecture

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

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

  • لديك خيار تكوين active-active، active-standby، active-passive لمجموعات AKS الخاصة بك.

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

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

  • عند بدء الاسترداد باستخدام ميزة الاستعادة الجغرافية في قاعدة بيانات Azure ل MySQL، يتم إنشاء خادم قاعدة بيانات جديد باستخدام بيانات النسخ الاحتياطي التي يتم نسخها نسخا متماثلا من منطقة أخرى.

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

تعلم المزيد عن:

خدمات Azure التي تدعم مناطق التوفر)