كيفية تحديث Azure Cloud Service (إصدار كلاسيكي)
هام
تم الآن إهمال Cloud Services (كلاسيكي) للعملاء الجدد وسيتم استبعادها في 31 أغسطس 2024 لجميع العملاء. ينبغي أن تستخدم عمليات النشر الجديدة نموذج النشر الجديد القائم على Azure Resource Manager Azure Cloud Services (الدعم الموسع) .
يعد تحديث الخدمة السحابية، بما في ذلك كل من أدوارها ونظام التشغيل الضيف، عملية من ثلاث خطوات. أولاً، يجب تحميل الملفات الثنائية وملفات التكوين الخاصة بالخدمة السحابية الجديدة أو إصدار نظام التشغيل. بعد ذلك، يحتفظ Azure بموارد الحساب والشبكة للخدمة السحابية وفق متطلبات إصدار الخدمة السحابية الجديد. أخيراً، يقوم Azure بإجراء ترقية بالدور لتحديث المستأجر تحديثاً تزايدياً إلى الإصدار الجديد أو نظام التشغيل الضيف، مع الحفاظ على التوافر الخاص بك. تتناول هذه المقالة تفاصيل هذه الخطوة الأخيرة - الترقية بالدور.
قم بتحديث خدمة Azure
ينظم Azure مثيلات الدور الخاصة بك في مجموعات منطقية تسمى مجالات الترقية (UD). مجالات الترقية (UD) هي مجموعات منطقية من مثيلات الأدوار التي يتم تحديثها كمجموعة. يقوم Azure بتحديث خدمة سحابية واحدة UD في كل مرة، ما يسمح للطبعات في UDs الأخرى بمواصلة خدمة نسبة استخدام الشبكة.
العدد الافتراضي لمجالات الترقية هو 5. يمكنك تحديد عدد مختلف من نطاقات الترقية من خلال تضمين السمة upgradeDomainCount في ملف تعريف الخدمة (.csdef). لمزيد من المعلومات حول سمة upgradeDomainCount، راجع مخطط تعريف Azure Cloud Services (ملف csdef.).
عند إجراء تحديث موضعي لدور واحد أو أكثر في خدمتك، يقوم Azure بتحديث مجموعات مثيلات الأدوار وفقاً لمجال الترقية الذي تنتمي إليه. يقوم Azure بتحديث جميع المثيلات في مجال ترقية معين - إيقافها وتحديثها وإعادتها عبر الإنترنت - ثم ينتقل إلى المجال التالي. من خلال إيقاف المثيلات التي تعمل في مجال الترقية الحالي فقط، يتأكد Azure من حدوث التحديث بأقل تأثير ممكن على الخدمة قيد التشغيل. لمزيد من المعلومات، راجع كيفية استمرار التحديث لاحقاً في هذه المقالة.
ملاحظة
في حين أن المصطلحين تحديث وترقية لهما معنى مختلف قليلاً في سياق Azure، يمكن استخدامهما بالتبادل للعمليات وأوصاف الميزات في هذا المستند.
يجب أن تحدد خدمتك مثيلين على الأقل للدور ليتم تحديثه في مكانه دون توقف. إذا كانت الخدمة تتكون من مثيل واحد فقط لدور واحد، فلن تكون خدمتك متاحة حتى انتهاء التحديث الموضعي.
يغطي هذا الموضوع المعلومات التالية حول تحديثات Azure:
- تغييرات الخدمة المسموح بها أثناء التحديث
- كيف تستمر الترقية
- التراجع عن تحديث
- بدء عمليات تحويل متعددة في عملية توزيع جارية
- توزيع الأدوار عبر نطاقات الترقية
تغييرات الخدمة المسموح بها أثناء التحديث
يوضح الجدول التالي التغييرات المسموح بها على خدمة ما أثناء التحديث:
| التغييرات المسموح بها على الاستضافة والخدمات والأدوار | التحديث في المكان | منظم (مبادلة VIP) | حذف وإعادة التوزيع |
|---|---|---|---|
| إصدار نظام التشغيل | نعم | نعم | نعم |
| مستوى الثقة .NET | نعم | نعم | نعم |
| حجم الجهاز الافتراضي1 | نعم2 | نعم | نعم |
| إعدادات التخزين المحلية | زيادة2فقط | نعم | نعم |
| إضافة أو إزالة أدوار في الخدمة | نعم | نعم | نعم |
| عدد حالات دور معين | نعم | نعم | نعم |
| عدد أو نوع نقاط النهاية للخدمة | نعم2 | لا | نعم |
| أسماء وقيم إعدادات التكوين | نعم | نعم | نعم |
| قيم إعدادات التكوين (وليس الأسماء) | نعم | نعم | نعم |
| أضف شهادات جديدة | نعم | نعم | نعم |
| تغيير الشهادات الموجودة | نعم | نعم | نعم |
| توزيع كود جديد | نعم | نعم | نعم |
1 تغيير الحجم مقصور على مجموعة فرعية من الأحجام المتوفرة للخدمة السحابية.
2 يتطلب Azure SDK 1.5 أو إصدارات أحدث.
تحذير
سيؤدي تغيير حجم الجهاز الظاهري إلى تدمير البيانات المحلية.
العناصر التالية غير مدعومة أثناء التحديث:
- تغيير اسم الدور. قم بإزالة الدور ثم قم بإضافته بالاسم الجديد.
- تغيير عدد مجال الترقية.
- تقليص حجم الموارد المحلية.
إذا كنت تجري تحديثات أخرى لتعريف خدمتك، مثل تقليل حجم المورد المحلي، فيجب عليك إجراء تحديث مبادلة VIP بدلاً من ذلك. لمزيد من المعلومات، راجع توزيع المبادلة.
كيف تستمر الترقية
يمكنك تحديد ما إذا كنت تريد تحديث جميع الأدوار في خدمتك أو دور واحد في الخدمة. في كلتا الحالتين، يتم إيقاف جميع حالات كل دور تتم ترقيته وينتمي إلى مجال الترقية الأول وترقيتها وإعادتها عبر الإنترنت. بمخزون إعادة الاتصال بالإنترنت، يتم إيقاف الطبعات الموجودة في مجال الترقية الثاني وترقيتها وإعادة الاتصال بالإنترنت. يمكن أن تحتوي الخدمة السحابية على ترقية واحدة نشطة على الأكثر في كل مرة. يتم إجراء الترقية دائماً على أحدث إصدار من الخدمة السحابية.
يوضح الرسم التخطيطي التالي كيفية استمرار عملية الترقية إذا كنت تقوم بترقية جميع الأدوار في الخدمة:
يوضح الرسم التخطيطي التالي كيفية استمرار التحديث إذا كنت تقوم بترقية دور واحد فقط:
أثناء التحديث التلقائي، تقوم Azure Fabric Controller بشكل دوري بتقييم حالة الخدمة السحابية لتحديد متى يكون من الآمن المضي إلى مجال الترقية (UD) التالي. يتم إجراء هذا التقييم الصحي على أساس كل دور ولا يأخذ في الاعتبار سوى الحالات الموجودة في الإصدار الأخير (أي الحالات من مجالات الترقية (UD) التي تم عرضها بالفعل). يتحقق من أن الحد الأدنى لعدد مثيلات الدور، لكل دور، قد حقق حالة نهائية مُرضية.
مهلة بدء مثيل الدور
ستنتظر وحدة التحكم في النسيج لمدة 30 دقيقة حتى يصل كل مثيل دور إلى حالة البدء. إذا انقضت مدة المهلة، ستستمر وحدة التحكم في النسيج في السير إلى مثيل الدور التالي.
التأثير على دفع البيانات أثناء ترقيات Cloud Service
عند ترقية خدمة من مثيل واحد إلى مثيلات متعددة، سيتم إيقاف خدمتك أثناء إجراء الترقية بسبب الطريقة التي تقوم بها Azure بترقية الخدمات. تنطبق اتفاقية مستوى الخدمة التي تضمن توفر الخدمة فقط على الخدمات التي يتم نشرها مع أكثر من مثيل واحد. تصف القائمة التالية كيفية تأثر البيانات الموجودة على كل محرك أقراص بكل سيناريو لترقية خدمة Azure:
| السيناريو | سي درايف | د محرك | إي درايف |
|---|---|---|---|
| إعادة تشغيل الجهاز الظاهري | محفوظة | محفوظة | محفوظة |
| إعادة تشغيل البوابة | محفوظة | محفوظة | دمرت |
| بوابة reimage | محفوظة | دمرت | دمرت |
| ترقية في نفس المكان | محفوظة | محفوظة | دمرت |
| هجرة العقدة | دمرت | دمرت | دمرت |
لاحظ أنه في القائمة أعلاه، يمثل محرك الأقراص E: محرك جذر الدور، ويجب ألا يكون مشفراً. بدلاً من ذلك، استخدم متغير البيئة %RoleRoot% لتمثيل محرك الأقراص.
لتقليل وقت التعطل عند ترقية خدمة ذات مثيل واحد، قم بتوزيع خدمة جديدة متعددة المثيلات إلى الخادم المرحلي وقم بإجراء مبادلة VIP.
التراجع عن تحديث
يوفر Azure المرونة في إدارة الخدمات أثناء التحديث من خلال السماح لك ببدء عمليات إضافية على إحدى الخدمات، بعد قبول طلب التحديث الأولي بواسطة Azure Fabric Controller. لا يمكن إجراء التراجع إلا عندما يكون التحديث (تغيير التكوين) أو الترقية في حالة قيد التقدم أثناء التوزيع. يعتبر التحديث أو الترقية قيد التقدم طالما أن هناك مثيلاً واحداً على الأقل للخدمة لم يتم تحديثه بعد إلى الإصدار الجديد. لاختبار ما إذا كان التراجع عن الحالة السابقة مسموحاً به، تحقق من قيمة علامة RollbackAllowed، التي تم إرجاعها بواسطة عمليات Get Deployment وGet Cloud Service Properties، التي تم تعيينها على "true".
ملاحظة
من المنطقي فقط استدعاء Rollback على تحديث أو ترقية في المكان لأن ترقيات مبادلة VIP تتضمن استبدال مثيل واحد قيد التشغيل من خدمتك بأخرى.
التراجع عن تحديث قيد التقدم له التأثيرات التالية على التوزيع:
- لن يتم تحديث أو ترقية أي مثيلات دور لم يتم تحديثها أو ترقيتها إلى الإصدار الجديد، لأن هذه المثيلات تقوم بالفعل بتشغيل الإصدار المستهدف من الخدمة.
- تعود أي مثيلات دور تم تحديثها أو ترقيتها بالفعل إلى الإصدار الجديد من ملف حزمة الخدمة (*.cspkg) أو ملف تكوين الخدمة (*.cscfg) (أو كلا الملفين) إلى الإصدار ما قبل الترقية من هذه الملفات.
يتم توفير هذا وظيفياً من خلال الميزات التالية:
عملية التراجع عن التحديث أو الترقية، والتي يمكن استدعاؤها في تحديث التكوين (يتم تشغيله عن طريق استدعاء تغيير تكوين التوزيع) أو ترقية (يتم تشغيلها عن طريق استدعاء توزيع الترقية) طالما يوجد مثيل واحد على الأقل في الخدمة لم يتم تحديثه بعد إلى الإصدار الجديد.
العنصر Locked والعنصر RollbackAllowed، اللذان يتم إرجاعهما كجزء من نص الاستجابة لعمليات الحصول على التوزيع والحصول على خصائص الخدمة السحابية:
- يسمح لك العنصر المقفل باكتشاف متى يمكن استدعاء عملية التحول في عملية توزيع معينة.
- يسمح لك عنصر RollbackAllowed باكتشاف متى يمكن استدعاء عملية إعادة التحديث أو الترقية في عملية توزيع معينة.
من أجل إجراء التراجع، لا يتعين عليك التحقق من كل من العناصر Locked وRollbackAllowed. يكفي تأكيد تعيين RollbackAllowed على "صحيح". يتم إرجاع هذه العناصر فقط إذا تم استدعاء هذه الطرق باستخدام عنوان الطلب الذي تم تعيينه على "x-ms-version: 2011-10-01" أو إصدار لاحق. لمزيد من المعلومات حول تعيين رؤوس الإصدارات، راجع تعيين إصدارات إدارة الخدمة.
هناك بعض المواقف التي لا يتم فيها دعم التراجع عن التحديث أو الترقية، وهي كالتالي:
- تقليل الموارد المحلية - إذا أدى التحديث إلى زيادة الموارد المحلية لدور ما، فإن نظام Azure الأساسي لا يسمح بالتراجع.
- قيود الحصة النسبية - إذا كان التحديث عبارة عن عملية تصغير، فقد لا يكون لديك حصة احتساب كافية لإكمال عملية التراجع. يحتوي كل اشتراك Azure على حصة نسبية مقترنة به تحدد الحد الأقصى لعدد المراكز التي يمكن أن تستهلكها جميع الخدمات المستضافة التي تنتمي إلى هذا الاشتراك. إذا كان إجراء التراجع عن تحديث معين سيؤدي إلى زيادة اشتراكك في الحصة النسبية، فلن يتم تمكين هذا التراجع.
- حالة السباق - إذا اكتمل التحديث الأولي، فلن يكون التراجع ممكناً.
من الأمثلة على الوقت الذي قد يكون فيه التراجع عن تحديث مفيداً إذا كنت تستخدم عملية ترقية التوزيع في الوضع اليدوي للتحكم في معدل طرح ترقية موضعية رئيسية للخدمة المستضافة في Azure.
أثناء بدء الترقية، يمكنك استدعاء ترقية التوزيع في الوضع اليدوي وتبدأ في السير في مجالات الترقية. إذا لاحظت في وقت ما، أثناء مراقبة الترقية، أن بعض مثيلات الأدوار في نطاقات الترقية الأولى التي تفحصها أصبحت غير مستجيبة، فيمكنك استدعاء عملية التراجع عن التحديث أو الترقية في عملية التوزيع، والتي ستترك لم تمس الحالات التي لم تتم ترقيتها بعد ومثيلات التراجع التي تمت ترقيتها إلى حزمة الخدمة والتكوين السابقتين.
بدء عمليات تحويل متعددة في عملية توزيع جارية
في بعض الحالات، قد ترغب في بدء عمليات تحويل متعددة متزامنة في عملية توزيع جارية. على سبيل المثال، يمكنك إجراء تحديث للخدمة، وأثناء طرح هذا التحديث عبر خدمتك، فأنت تريد إجراء بعض التغيير، على سبيل المثال للتراجع عن التحديث أو تطبيق تحديث مختلف أو حتى حذف التوزيع. الحالة التي قد يكون فيها هذا ضرورياً هي إذا كانت ترقية الخدمة تحتوي على رمز عربات التي تجرها الدواب ما يؤدي إلى تعطل مثيل الدور الذي تمت ترقيته بشكل متكرر. في هذه الحالة، لن تتمكن Azure Fabric Controller من إحراز تقدم في تطبيق تلك الترقية لأن العدد غير الكافي من المثيلات في المجال الذي تمت ترقيته سليم. يشار إلى هذه الحالة باسم توزيع عالق. يمكنك إلغاء تثبيت التوزيع عن طريق التراجع عن التحديث أو تطبيق تحديث جديد فوق التحديث الفاشل.
بمخزون تلقي الطلب الأولي لتحديث الخدمة أو ترقيتها بواسطة Azure Fabric Controller، يمكنك بدء عمليات التحوير اللاحقة. أي، لا يتعين عليك الانتظار حتى تكتمل العملية الأولية قبل أن تتمكن من بدء عملية تحويل أخرى.
بدء عملية تحديث ثانية أثناء استمرار التحديث الأول سيؤدي إلى إجراء مماثل لعملية التراجع. إذا كان التحديث الثاني في الوضع التلقائي، فستتم ترقية مجال الترقية الأول على الفور، ما قد يؤدي إلى أن تكون مثيلات من نطاقات ترقية متعددة غير متصلة بالإنترنت في نفس الوقت.
عمليات التغيير كالتالي: تغيير تكوين التوزيعو ترقية التوزيعو تحديث حالة التوزيعو حذف التوزيعو التراجع عن التحديث أو الترقية.
العمليتان الحصول على التوزيع والحصول على خصائص الخدمة السحابية تعرضان علامة Locked التي يمكن فحصها لتحديد ما إذا كان يمكن استدعاء عملية التحول في عملية توزيع معينة.
من أجل استدعاء إصدار هذه الطرق التي تُرجع علامة Locked، يجب عليك تعيين عنوان الطلب على "x-ms-version: 2011-10-01" أو ما بعده. لمزيد من المعلومات حول تعيين رؤوس الإصدارات، راجع تعيين إصدارات إدارة الخدمة.
توزيع الأدوار عبر نطاقات الترقية
يوزع Azure مثيلات الدور بالتساوي عبر عدد معين من مجالات الترقية، والتي يمكن تكوينها كجزء من ملف تعريف الخدمة (csdef.). الحد الأقصى لعدد مجالات الترقية هو 20 مجالاً والافتراضي هو 5. لمزيد من المعلومات حول كيفية تعديل ملف تعريف الخدمة، راجع مخطط تعريف خدمة Azure (ملف csdef.).
على سبيل المثال، إذا كان دورك يحتوي على عشر مثيلات، فسيحتوي كل مجال ترقية افتراضياً على حالتين. إذا كان دورك يحتوي على 14 مثيلاً، فإن أربعة من نطاقات الترقية تحتوي على ثلاثة مثيلات، والمجال الخامس يحتوي على اثنين.
يتم تحديد مجالات الترقية بفهرس قائم على الصفر: مجال الترقية الأول له معرّف 0، ومجال الترقية الثاني له معرّف 1، وهكذا.
يوضح الرسم التخطيطي التالي كيف يتم توزيع الخدمة التي تحتوي على دورين عندما تحدد الخدمة مجالين للترقية. تقوم الخدمة بتشغيل ثمانية مثيلات لدور الويب وتسعة مثيلات لدور العامل.
ملاحظة
لاحظ أن Azure يتحكم في كيفية تخصيص المثيلات عبر مجالات الترقية. لا يمكن تحديد الحالات التي يتم تخصيصها لأي مجال.
الخطوات التالية
كيفية إدارة الخدمات السحابية
كيفية مراقبة الخدمات السحابية
كيفية تكوين الخدمات السحابية