ترقيات صورة نظام التشغيل التلقائية لمجموعة مقياس الجهاز الظاهري Azure
إشعار
تنطبق العديد من الخطوات المدرجة في هذا المستند على مجموعات مقياس الجهاز الظاهري باستخدام وضع التنسيق الموحد. نوصي باستخدام التنسيق المرن لأحمال العمل الجديدة. لمزيد من المعلومات، راجع أوضاع التنسيق لمجموعات مقياس الجهاز الظاهري في Azure.
يساعد تمكين الترقيات التلقائية لصورة نظام التشغيل على مجموعة المقياس على تسهيل إدارة التحديث عن طريق ترقية قرص نظام التشغيل بأمان وتلقائيا لجميع المثيلات في مجموعة المقياس.
الترقية التلقائية لنظام التشغيل لها الخصائص التالية:
- بمجرد تكوينها، يتم تطبيق أحدث صورة لنظام التشغيل التي ينشرها ناشرو الصور تلقائيًا على مجموعة المقياس دون تدخل من المستخدم.
- ترقية دفعات المثيلات بطريقة متدرجة في كل مرة ينشر فيها الناشر صورة جديدة.
- يتكامل مع فحوصات صحة التطبيق وملحق Application Health.
- يعمل مع جميع أحجام الأجهزة الظاهرية، ولكل من Windows وصور Linux بما في ذلك الصور المخصصة من خلال Azure Compute Gallery.
- يمكنك إلغاء الاشتراك في الترقيات التلقائية في أي وقت (يمكن بدء ترقيات نظام التشغيل يدويًا أيضًا).
- يتم استبدال قرص نظام التشغيل من الأجهزة الظاهرية مع قرص نظام التشغيل الجديد الذي تم إنشاؤه مع أحدث إصدار الصورة. يتم تشغيل الملحقات المكونة والبرامج النصية المخصصة للبيانات، بينما يتم الاحتفاظ بأقراص البيانات الدائمة.
- يتم دعم تسلسل الملحق.
- يمكن تمكينه على مجموعة مقياس بأي حجم.
إشعار
قبل تمكين الترقيات التلقائية لصورة نظام التشغيل، تحقق من قسم المتطلبات في هذه الوثائق.
كيف تعمل الترقية التلقائية لصورة نظام التشغيل؟
تعمل الترقية عن طريق استبدال قرص نظام التشغيل لجهاز ظاهري بقرص جديد تم إنشاؤه باستخدام إصدار الصورة. يتم تشغيل أي ملحقات مكوّنة ونصوص بيانات مخصصة على قرص نظام التشغيل، بينما يتم الاحتفاظ بأقراص البيانات. لتقليل وقت تعطل التطبيق، تتم الترقيات على دفعات، مع عدم وجود أكثر من 20٪ من ترقية مجموعة المقياس في أي وقت.
يجب دمج فحص صحة تطبيق Azure Load Balancer أو ملحق Application Health لتتبع صحة التطبيق بعد الترقية. يسمح هذا للنظام الأساسي بالتحقق من صحة الجهاز الظاهري لضمان تطبيق التحديثات بطريقة آمنة. نوصي بتضمين رسالة كشف أخطاء الاتصال للتطبيق للتحقق من صحة نجاح الترقية.
تحديثات التوفر أولاً
يضمن نموذج التوفر الأول لتحديثات النظام الأساسي المنسقة الموضحة أدناه احترام تكوينات التوفر في Azure عبر مستويات التوفر المتعددة.
عبر المناطق:
- سيتم نقل التحديث عبر Azure بشكلٍ عام بطريقة مرحلية لمنع فشل النشر على مستوى Azure.
- قد تحتوي "المرحلة" على منطقة واحدة أو أكثر، ولا ينتقل التحديث عبر المراحل إلا إذا تم تحديث الأجهزة الظاهرية المؤهلة في المرحلة السابقة بنجاح.
- لا يتم تحديث المناطق المقترنة جغرافياً في وقت واحد ولا يمكن أن تكون في نفس المرحلة الإقليمية.
- يتم قياس نجاح التحديث من خلال تتبع تحديث النشر السليم للجهاز الظاهري.
داخل المنطقة:
- لا يتم تحديث الأجهزة الظاهرية في مناطق توافر الخدمات المختلفة بالتزامن مع نفس التحديث.
ضمن "مجموعة":
- لا يتم تحديث جميع الأجهزة الظاهرية في مجموعة قياس مشتركة بشكلٍ متزامن.
- يتم تجميع الأجهزة الظاهرية في مجموعة مقياس الجهاز الظاهري الشائعة على دفعات وتحديثها ضمن تحديث حدود المجال كما هو موضح أدناه.
يتم اتباع عملية التحديثات المنسقة للنظام الأساسي لطرح ترقيات صور النظام الأساسي لنظام التشغيل المدعوم كل شهر. بالنسبة للصور المخصصة من خلال Azure Compute Gallery، لا يتم بدء ترقية الصورة إلا لمنطقة Azure معينة عند نشر الصورة الجديدة ونسخها إلى منطقة مجموعة المقياس هذه.
ترقية الأجهزة الظاهرية في مجموعة قياس
تصبح منطقة مجموعة القياس مؤهلة للحصول على ترقيات الصور إما من خلال عملية التوفر أولا لصور النظام الأساسي أو تكرار إصدارات الصور المخصصة الجديدة لمعرض الصور المشاركة. يتم بعد ذلك تطبيق ترقية الصورة على مجموعة قياس فردي بطريقة مجمعة على النحو التالي:
- قبل البدء في عملية الترقية، سيضمن المنسق أن ما لا يزيد عن 20٪ من المثيلات في مجموعة المقياس بأكملها غير سليمة (لأي سبب).
- يحدد منسق الترقية مجموعة مثيلات الأجهزة الظاهرية للترقية، مع وجود أي حزمة واحدة بحد أقصى 20٪ من إجمالي عدد المثيلات، مع مراعاة الحد الأدنى لحجم الحزمة لجهاز ظاهري واحد. لا يوجد حد أدنى لمتطلبات حجم مجموعة القياس وستضم مجموعات القياس التي تحتوي على 5 مثيلات أو أقل على جهاز ظاهري واحد لكل حزمة ترقية (الحد الأدنى لحجم الحزمة).
- يتم استبدال قرص نظام التشغيل لكل جهاز ظاهري في دفعة الترقية المحددة بقرص نظام تشغيل جديد تم إنشاؤه من الصورة. يتم تطبيق جميع الملحقات والتكوينات المحددة في نموذج مجموعة القياس على المثيل الذي تمت ترقيته.
- بالنسبة لمجموعات القياس التي تحتوي على فحصوات سلامة التطبيق التي تم تكوينها أو ملحق حماية التطبيق، تنتظر الترقية ما يصل إلى 5 دقائق حتى يصبح المثيل سليماً، قبل الانتقال إلى ترقية الحزمة التالية. إذا لم يستعد أحد المثيلات سلامته في 5 دقائق بعد الترقية، فسيتم افتراضياً استعادة قرص نظام التشغيل السابق للمثيل.
- يتتبع منسق الترقية أيضاً النسبة المئوية للمثيلات التي تصبح غير سليمة قبل الترقية. ستتوقف الترقية إذا أصبح أكثر من 20٪ من المثيلات التي تمت ترقيتها غير سليمة أثناء عملية الترقية.
- تستمر العملية المذكورة أعلاه حتى تتم ترقية جميع المثيلات في مجموعة المقياس.
يتحقق منسق ترقية نظام تشغيل مجموعة القياس من سلامة مجموعة القياس الإجمالية قبل ترقية كل حزمة. أثناء ترقية دُفعة، قد تكون هناك أنشطة صيانة متزامنة أخرى مخططة أو غير مخطط لها يمكن أن تؤثر على سلامة مثيلات مجموعة القياس. في مثل هذه الحالات، إذا أصبح أكثر من 20٪ من مثيلات مجموعة المقاييس غير سليمة، فستتوقف ترقية مجموعة المقياس في نهاية الحزمة الحالية.
لتعديل الإعدادات الافتراضية المقترنة بالترقيات المتداولة، راجع نهج الترقية المتداول ل Azure.
إشعار
لا تؤدي الترقية التلقائية لنظام التشغيل إلى ترقية الصورة المرجعية Sku على مجموعة القياس. لتغيير Sku (مثل Ubuntu 18.04-LTS إلى 20.04-LTS)، يجب تحديث نموذج مجموعة التحجيم مباشرة مع الصورة المطلوبة Sku. لا يمكن تغيير ناشر الصور والعرض لمجموعة قياس موجودة.
ترقية صورة نظام التشغيل مقابل إعادة الرسم
كل من ترقية صور نظام التشغيل وإعادة التعيين هما أسلوبان يستخدمان لتحديث الأجهزة الظاهرية ضمن مجموعة مقياس، ولكنهما يخدمان أغراضا مختلفة ولهما تأثيرات مميزة.
تتضمن ترقية صورة نظام التشغيل تحديث صورة نظام التشغيل الأساسية المستخدمة لإنشاء مثيلات جديدة في مجموعة مقياس. عند إجراء ترقية صورة نظام التشغيل، سيقوم Azure بإنشاء مثيلات جهاز ظاهري جديدة مع صورة نظام التشغيل المحدثة واستبدال مثيلات الجهاز الظاهري القديمة تدريجيا في مجموعة المقياس بأخرى جديدة. عادة ما يتم تنفيذ هذه العملية على مراحل لضمان توفر عال. ترقيات صور نظام التشغيل هي طريقة غير معطلة لتطبيق التحديثات أو التغييرات على نظام التشغيل الأساسي للأجهزة الظاهرية في مجموعة مقياس. لا تتأثر مثيلات الجهاز الظاهري الموجودة حتى يتم استبدالها بالمثيلات الجديدة.
إعادة تعيين مثيل جهاز ظاهري في مجموعة مقياس هو إجراء أكثر فورية وتخريبية. عند اختيار إعادة تعيين مثيل جهاز ظاهري، سيقوم Azure بإيقاف مثيل الجهاز الظاهري المحدد، وتنفيذ عملية إعادة الرسم، ثم إعادة تشغيل الجهاز الظاهري باستخدام نفس صورة نظام التشغيل. يؤدي هذا إلى إعادة تثبيت نظام التشغيل بشكل فعال على مثيل الجهاز الظاهري المحدد هذا. عادة ما يتم استخدام إعادة التعيين عندما تحتاج إلى استكشاف أخطاء مثيل جهاز ظاهري معين أو إعادة تعيينه بسبب مشكلات في هذا المثيل.
الاختلافات الرئيسية:
- ترقية صورة نظام التشغيل هي عملية تدريجية وغير معطلة تقوم بتحديث صورة نظام التشغيل لمجموعة مقياس الجهاز الظاهري بأكملها بمرور الوقت، ما يضمن الحد الأدنى من التأثير على تشغيل أحمال العمل.
- إعادة التصميم هو إجراء أكثر فورية وتخريبية يؤثر فقط على مثيل الجهاز الظاهري المحدد، وإيقافه مؤقتا وإعادة تثبيت نظام التشغيل.
متى تستخدم كل أسلوب:
- استخدم ترقية صورة نظام التشغيل عندما تريد تحديث صورة نظام التشغيل لمجموعة المقياس بأكملها مع الحفاظ على قابلية الوصول العالية.
- استخدم Reimage عندما تحتاج إلى استكشاف أخطاء مثيل جهاز ظاهري معين أو إعادة تعيينه ضمن مجموعة مقياس الجهاز الظاهري.
من الضروري التخطيط بعناية واختيار الطريقة المناسبة استنادا إلى متطلباتك المحددة لتقليل أي تعطيل للتطبيقات والخدمات التي تعمل في مجموعة مقياس الجهاز الظاهري.
صور نظام التشغيل المدعومة
يتم دعم بعض صور النظام الأساسي لنظام التشغيل حالياً. الصور المخصصة مدعومة إذا كانت مجموعة القياس تستخدم صوراً مخصصة من خلال Azure Compute Gallery.
يتم حالياً دعم وحدات SKU للنظام الأساسي التالية (ويتم إضافة المزيد بشكل دوري):
الناشر | عرض نظام التشغيل | Sku |
---|---|---|
Canonical | UbuntuServer | 18.04-LTS |
Canonical | UbuntuServer | 18_04-LTS-Gen2 |
Canonical | 0001-com-ubuntu-server-focal | 20_04-LTS |
Canonical | 0001-com-ubuntu-server-focal | 20_04-LTS-Gen2 |
Canonical | 0001-com-ubuntu-server-jammy | 22_04-LTS |
Canonical | 0001-com-ubuntu-server-jammy | 22_04-LTS-Gen2 |
MicrosoftCblMariner | Cbl-Mariner | cbl-mariner-1 |
MicrosoftCblMariner | Cbl-Mariner | 1-Gen2 |
MicrosoftCblMariner | Cbl-Mariner | cbl-mariner-2 |
MicrosoftCblMariner | Cbl-Mariner | cbl-mariner-2-Gen2 |
MicrosoftSqlServer | Sql2017-ws2019 | مؤسسة |
MicrosoftWindowsServer | WindowsServer | 2012-R2-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-gensecond |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-gs |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-with-Containers |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-with-containers-gs |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-Core |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-Core-with-Containers |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-gensecond |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-gs |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-with-Containers |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-with-Containers-gs |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-smalldisk-g2 |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-core |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-core-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-g2 |
MicrosoftWindowsServer | WindowsServer | Datacenter-core-20h2-with-containers-smalldisk-gs |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-azure-edition |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-azure-edition-smalldisk |
ميرانتيس | Windows_with_Mirantis_Container_Runtime_2019 | win_2019_mcr_23_0 |
ميرانتيس | Windows_with_Mirantis_Container_Runtime_2019 | win_2019_mcr_23_0_gen2 |
متطلبات تكوين الترقية التلقائية لصورة نظام التشغيل
- يجب تعيين خاصية الإصدار للصورة إلى الأحدث.
- يجب استخدام فحوصات صحة التطبيق أو ملحق صحة التطبيق لمجموعات تغيير حجم غير Service Fabric. للحصول على متطلبات Service Fabric، راجع متطلبات Service Fabric.
- استخدم إصدار واجهة برمجة تطبيقات الحوسبة 2018-10-01 أو أعلى.
- تأكد من توفر الموارد الخارجية المحددة في نموذج مجموعة القياس وتحديثها. تتضمن الأمثلة SAS URI لتمهيد الحمولة في خصائص ملحق الجهاز الظاهري، والحمولة في حساب التخزين، والإشارة إلى الأسرار في النموذج، وغير ذلك.
- بالنسبة لمجموعات المقياس التي تستخدم أجهزة Windows الظاهرية، بدءا من إصدار Compute API 2019-03-01، يجب تعيين الخاصية virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates إلى false في تعريف نموذج مجموعة المقياس. تعمل الخاصية enableAutomaticUpdates على تمكين التصحيح في الجهاز الظاهري حيث يطبق "Windows Update" تصحيحات نظام التشغيل دون استبدال قرص نظام التشغيل. مع تمكين ترقيات صورة نظام التشغيل التلقائية على مجموعة المقياس، والتي يمكن إجراؤها عن طريق تعيين automaticOSUpgradePolicy.enableAutomaticOSUpgrade إلى true، لا يلزم إجراء عملية تصحيح إضافية من خلال Windows Update.
إشعار
بعد استبدال قرص نظام التشغيل من خلال إعادة التعيين أو الترقية، قد يتم إعادة تعيين أحرف محرك الأقراص لأقراص البيانات المرفقة. للاحتفاظ بنفس أحرف محرك الأقراص للأقراص المرفقة، يقترح استخدام برنامج نصي مخصص للتمهيد.
متطلبات Service Fabric
إذا كنت تستخدم Service Fabric، فتأكد من استيفاء الشروط التالية:
- مستوى القدرة على الصمود الخاص بـ Service Fabric هو فضي أو ذهبي. إذا كانت متانة Service Fabric برونزية، فإن أنواع العقد عديمة الحالة فقط هي التي تدعم الترقيات التلقائية لصورة نظام التشغيل).
- يجب أن يحتوي ملحق Service Fabric في تعريف نموذج مجموعة المقاييس على TypeHandlerVersion 1.1 أو أعلى.
- يجب أن يكون مستوى القدرة على الصمود هو نفسه في مجموعة Service Fabric وملحق Service Fabric على تعريف نموذج مجموعة التوسعة.
- لا يلزم إجراء فحص سلامة إضافي أو استخدام ملحق سلامة التطبيق للحصول على متانة فضية أو ذهبية. تتطلب المتانة البرونزية مع أنواع العقد عديمة الحالة فحص سلامة إضافي فقط.
- يجب تعيين الخاصية virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates على false في تعريف نموذج مجموعة المقياس. تعمل الخاصية enableAutomaticUpdates على تمكين التصحيح في الجهاز الظاهري باستخدام "Windows Update" وهي غير مدعومة في مجموعات قياس Service Fabric. يجب استخدام الخاصية automaticOSUpgradePolicy.enableAutomaticOSUpgrade بدلا من ذلك.
تأكد من عدم تطابق إعدادات المتانة في مجموعة Service Fabric وملحق Service Fabric، حيث سيؤدي عدم التطابق إلى حدوث أخطاء في الترقية. يمكن تعديل مستويات المتانة وفقاً للإرشادات الموضحة في هذه الصفحة.
الترقية التلقائية لصورة نظام التشغيل للصور المخصصة
يتم دعم الترقية التلقائية لصور نظام التشغيل للصور المخصصة التي يتم نشرها من خلال Azure Compute Gallery. الصور المخصصة الأخرى غير مدعومة للترقيات التلقائية لصور نظام التشغيل.
متطلبات إضافية للصور المخصصة
- إن عملية الإعداد والتكوين للترقية التلقائية لصورة نظام التشغيل هي نفسها لجميع مجموعات القياس كما هو مفصل في قسم التكوين بهذه الصفحة.
- ستتم ترقية مثيلات مجموعات المقياس التي تم تكوينها للترقيات التلقائية لصورة نظام التشغيل إلى إصدار صورة Azure Compute Gallery عند نشر إصدار جديد من الصورة ونسخها نسخا متماثلا إلى منطقة مجموعة التحجيم هذه. إذا لم يتم نسخ الصورة الجديدة إلى المنطقة التي يتم فيها نشر المقياس، فلن تتم ترقية مثيلات مجموعة المقياس إلى الإصدار. يسمح لك النسخ الإقليمي للصور بالتحكم في طرح الصورة الجديدة لمجموعات القياس الخاصة بك.
- يجب عدم استبعاد إصدار الصورة الجديد من إصدار صورة المعرض هذه. لا يتم طرح إصدارات الصور المستبعدة من إصدار صورة المعرض إلى مجموعة المقياس من خلال الترقية التلقائية لصورة نظام التشغيل.
إشعار
قد يستغرق الأمر ما يصل إلى 3 ساعات لمجموعة التحجيم لتشغيل إطلاق ترقية الصورة الأولى بعد تكوين مجموعة التحجيم أولا لترقيات نظام التشغيل التلقائي بسبب عوامل معينة مثل صيانة Windows أو قيود أخرى. قد لا يحصل العملاء على أحدث صورة على ترقية حتى تتوفر صورة جديدة.
تكوين الترقية التلقائية لصورة نظام التشغيل
لتكوين الترقية التلقائية لصورة نظام التشغيل، تأكد من تعيين الخاصية automaticOSUpgradePolicy.enableAutomaticOSUpgrade إلى true في تعريف طراز مجموعة القياس.
إشعار
يعد وضع سياسة الترقية وسياسة الترقية التلقائية لنظام التشغيل إعدادات منفصلة وتتحكم في جوانب مختلفة من مجموعة القياس. عند وجود تغييرات في قالب مجموعة القياس، ستحدد سياسة الترقية mode
ما يحدث للمثيلات الموجودة في مجموعة القياس. ومع ذلك، فإن سياسة الترقية التلقائية لنظام التشغيل enableAutomaticOSUpgrade
خاصة بصورة نظام التشغيل وتتعقب التغييرات التي أجراها ناشر الصورة وتحدد ما يحدث عند وجود تحديث للصورة.
إشعار
إذا enableAutomaticOSUpgrade
تم تعيين إلى صحيح، enableAutomaticUpdates
يتم تعيين تلقائيا إلى خطأ ولا يمكن تعيينه إلى صحيح.
واجهة برمجة تطبيقات REST
يوضح المثال التالي كيفية تعيين ترقيات نظام التشغيل التلقائية على طراز مجموعة القياس:
PUT or PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet?api-version=2021-03-01`
{
"properties": {
"upgradePolicy": {
"automaticOSUpgradePolicy": {
"enableAutomaticOSUpgrade": true
}
}
}
}
Azure PowerShell
استخدم New-AzVmss cmdlet لتكوين ترقيات صورة نظام التشغيل التلقائية لمجموعة المقياس أثناء التوفير. يقوم المثال التالي بتكوين الترقيات التلقائية لمجموعة القياس المسماة myScaleSet في مجموعة الموارد المسماة myResourceGroup:
New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
استخدم Update-AzVmss cmdlet لتكوين ترقيات صورة نظام التشغيل التلقائي لمجموعة المقياس الموجودة. يقوم المثال التالي بتكوين الترقيات التلقائية لمجموعة القياس المسماة myScaleSet في مجموعة الموارد المسماة myResourceGroup:
Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
Azure CLI 2.0
استخدم az vmss create لتكوين ترقيات صورة نظام التشغيل التلقائية لمجموعة المقياس أثناء التوفير. استخدم Azure CLI 2.0.47 أو أعلى. يقوم المثال التالي بتكوين الترقيات التلقائية لمجموعة القياس المسماة myScaleSet في مجموعة الموارد المسماة myResourceGroup:
az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
استخدم تحديث az vmss لتكوين ترقيات صورة نظام التشغيل التلقائية لمجموعة المقياس الموجودة. استخدم Azure CLI 2.0.47 أو أعلى. يقوم المثال التالي بتكوين الترقيات التلقائية لمجموعة القياس المسماة myScaleSet في مجموعة الموارد المسماة myResourceGroup:
az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
إشعار
بعد تكوين الترقيات التلقائية لصور نظام التشغيل لمجموعة القياس الخاصة بك، يجب عليك أيضاً إحضار مجموعة قياس الأجهزة الظاهرية إلى أحدث نموذج مجموعة قياس إذا كانت مجموعة القياس الخاصة بك تستخدم "دليل" سياسة الترقية.
قوالب ARM
يصف المثال التالي كيفية تعيين ترقيات نظام التشغيل التلقائية على نموذج مجموعة مقياس عبر قوالب Azure Resource Manager (قوالب ARM):
"properties": {
"upgradePolicy": {
"mode": "Automatic",
"RollingUpgradePolicy": {
"BatchInstancePercent": 20,
"MaxUnhealthyInstancePercent": 25,
"MaxUnhealthyUpgradedInstancePercent": 25,
"PauseTimeBetweenBatches": "PT0S"
},
"automaticOSUpgradePolicy": {
"enableAutomaticOSUpgrade": true,
"useRollingUpgradePolicy": true,
"disableAutomaticRollback": false
}
},
},
"imagePublisher": {
"type": "string",
"defaultValue": "MicrosoftWindowsServer"
},
"imageOffer": {
"type": "string",
"defaultValue": "WindowsServer"
},
"imageSku": {
"type": "string",
"defaultValue": "2022-datacenter"
},
"imageOSVersion": {
"type": "string",
"defaultValue": "latest"
}
Bicep
يصف المثال التالي كيفية تعيين ترقيات نظام التشغيل التلقائية على نموذج مجموعة مقياس عبر Bicep:
properties: {
overprovision: overProvision
upgradePolicy: {
mode: 'Automatic'
automaticOSUpgradePolicy: {
enableAutomaticOSUpgrade: true
}
}
}
استخدام ملحق صحة التطبيق
أثناء ترقية نظام التشغيل، تتم ترقية مثيلات الأجهزة الظاهرية في مجموعة القياس حزمة واحدة في كل مرة. يجب أن تستمر الترقية فقط إذا كان تطبيق العميل سليماً في مثيلات الجهاز الظاهري التي تمت ترقيتها. نوصي بأن يوفر التطبيق إشارات صحية لمحرك ترقية نظام التشغيل المحدد المقياس. بشكلٍ افتراضي، أثناء ترقيات نظام التشغيل، يأخذ النظام الأساسي في الاعتبار حالة طاقة الجهاز الظاهري وحالة توفير الملحقات لتحديد ما إذا كان مثيل الجهاز الظاهري سليماً بعد الترقية. أثناء ترقية نظام التشغيل لمثيل الجهاز الظاهري، يتم استبدال قرص نظام التشغيل على مثيل الجهاز الظاهري بقرص جديد استناداً إلى أحدث إصدار من الصور. بعد اكتمال ترقية نظام التشغيل، يتم تشغيل الملحقات التي تم تكوينها على هذه الأجهزة الظاهرية. يعتبر التطبيق سليماً فقط عندما يتم توفير جميع الإضافات على المثيل بنجاح.
يمكن تكوين مجموعة القياس اختيارياً باستخدام فحوصات سلامة التطبيق لتزويد النظام الأساسي بمعلومات دقيقة عن الحالة المستمرة للتطبيق. إن فحوصات سلامة التطبيق عبارة عن فحوصات مخصصة لموازنة الحمل تُستخدم كإشارة سلامة. يمكن للتطبيق الذي يعمل على مجموعة قياس مثيل الجهاز الظاهري الاستجابة لطلبات HTTP أو TCP الخارجية التي تشير إلى ما إذا كان سليماً أم لا. لمزيدٍ من المعلومات حول كيفية عمل فحوصات موازن الحمل المخصصة، راجع فهم فحوصات موازن الأحمال. لا يتم دعم فحوصات سلامة التطبيق لمجموعات قياس Service Fabric. تتطلب مجموعات القياس غير المتعلقة بـ Service Fabric إما فحوصات سلامة تطبيق موازن التحميل أو ملحق سلامة التطبيق.
إذا تم تكوين مجموعة القياس لاستخدام مجموعات مواضع متعددة، فيجب استخدام الفحوصات التي تستخدم موازن تحميل قياسي.
إشعار
يمكن استخدام مصدر واحد فقط لمراقبة الصحة لمجموعة مقياس الجهاز الظاهري، إما ملحق صحة التطبيق أو فحص الصحة. إذا كان لديك كلا الخيارين ممكنين، فستحتاج إلى إزالة خيار قبل استخدام خدمات التنسيق مثل إصلاحات المثيل أو ترقيات نظام التشغيل التلقائية.
تكوين فحوصات موازن تحميل مخصص كفحص سلامة التطبيق على مجموعة قياس
كممارسة مثلى، قم بإنشاء فحص موازن الحمل بشكلٍ صريح لسلامة مجموعة القياس. يمكن استخدام نفس نقطة النهاية لفحص HTTP أو فحص TCP الحالي، ولكن قد يتطلب فحص السلامة سلوكاً مختلفاً عن فحص موازن التحميل التقليدي. على سبيل المثال، قد يعود فحص موازن التحميل التقليدي بشكلٍ غير سليم إذا كان الحمل على المثيل مرتفعاً جداً، ولكن هذا لن يكون مناسباً لتحديد سلامة المثيل أثناء الترقية التلقائية لنظام التشغيل. قم بتكوين الفحص ليكون بمعدل فحص مرتفع أقل من دقيقتين.
يمكن الرجوع إلى فحص موازن الأحمال في ملف تعريف الشبكة لمجموعة القياس ويمكن ربطه إما بموازن تحميل داخلي أو عام على النحو التالي:
"networkProfile": {
"healthProbe" : {
"id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
},
"networkInterfaceConfigurations":
...
}
إشعار
عند استخدام ترقيات نظام التشغيل التلقائية مع Service Fabric، يتم طرح صورة نظام التشغيل الجديدة تحديث المجال بواسطة تحديث المجال للحفاظ على التوافر العالي للخدمات التي تعمل في Service Fabric. لاستخدام ترقيات نظام التشغيل التلقائية في Service Fabric، يجب تكوين نوع عقدة الكتلة لاستخدام طبقة المتانة الفضية أو أعلى. بالنسبة لمستوى المتانة البرونزية، يتم دعم الترقية التلقائية لصورة نظام التشغيل فقط لأنواع العقد عديمة الحالة. لمزيدٍ من المعلومات حول خصائص المتانة لمجموعات Service Fabric، يُرجى الاطلاع على هذه الوثائق.
استخدام ملحق سلامة التطبيق
يتم نشر ملحق Application Health داخل مثيل مجموعة مقياس الجهاز الظاهري وتقارير عن صحة الجهاز الظاهري من داخل مثيل مجموعة المقياس. يمكنك تكوين الملحق لفحص نقطة نهاية تطبيق وتحديث حالة التطبيق على هذا المثيل. يتم فحص حالة المثيل هذه بواسطة Azure لتحديد ما إذا كان المثيل مؤهلاً لعمليات الترقية أم لا.
نظراً لأن صحة تقارير الملحق من داخل جهاز ظاهري، يمكن استخدام الملحق في المواقف التي لا يمكن فيها استخدام فحوصات خارجية مثل فحصوات سلامة التطبيق (التي تستخدم فحوصات موازن تحميل Azure المخصصة).
ثمة طرق عدة لنشر ملحق سلامة التطبيق على مجموعات القياس الخاصة بك كما هو مفصل في الأمثلة في هذه المقالة.
إشعار
يمكن استخدام مصدر واحد فقط لمراقبة الصحة لمجموعة مقياس الجهاز الظاهري، إما ملحق صحة التطبيق أو فحص الصحة. إذا كان لديك كلا الخيارين ممكنين، فستحتاج إلى إزالة خيار قبل استخدام خدمات التنسيق مثل إصلاحات المثيل أو ترقيات نظام التشغيل التلقائية.
الحصول على سجل الترقيات التلقائية لصور نظام التشغيل
يمكنك التحقق من سجل أحدث ترقية لنظام التشغيل تم إجراؤها على مجموعة القياس الخاصة بك باستخدام Azure PowerShell أو Azure CLI 2.0 أو واجهات برمجة تطبيقات REST. يمكنك الحصول على سجل لآخر خمس محاولات لترقية نظام التشغيل خلال الشهرين الماضيين.
تحديث أوراق الاعتماد باستمرار
إذا كانت مجموعة القياس الخاصة بك تستخدم أي بيانات اعتماد للوصول إلى الموارد الخارجية، مثل ملحق الجهاز الظهري الذي تم تكوينه لاستخدام رمز SAS لحساب التخزين، فتأكد من تحديث بيانات الاعتماد. إذا انتهت صلاحية أي بيانات اعتماد، بما في ذلك الشهادات والرموز المميزة، فستفشل الترقية وسيتم ترك الحزمة الأولى من الأجهزة الظاهرية في حالة فشل.
تتمثل الخطوات الموصى بها لاسترداد الأجهزة الظاهرية وإعادة تمكين الترقية التلقائية لنظام التشغيل إذا كان هناك فشل في مصادقة الموارد فيما يلي:
- إعادة إنشاء الرمز المميز (أو أي بيانات اعتماد أخرى) تم تمريره إلى الملحق (الملحقات).
- تأكد من تحديث أي بيانات اعتماد مستخدمة من داخل الجهاز الظاهري للتحدث إلى الكيانات الخارجية.
- تحديث الملحق (الملحقات) في نموذج مجموعة القياس باستخدام أي رموز مميزة جديدة.
- نشر مجموعة القياس المحدثة، والتي ستقوم بتحديث جميع مثيلات الجهاز الظاهري بما في ذلك المثيلات الفاشلة.
واجهة برمجة تطبيقات REST
يستخدم المثال التالي REST API للتحقق من حالة مجموعة القياس المسماة myScaleSet في مجموعة الموارد المسماة myResourceGroup:
GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`
يقوم استدعاء GET بإرجاع خصائص مشابهة لإخراج المثال التالي:
{
"value": [
{
"properties": {
"runningStatus": {
"code": "RollingForward",
"startTime": "2018-07-24T17:46:06.1248429+00:00",
"completedTime": "2018-04-21T12:29:25.0511245+00:00"
},
"progress": {
"successfulInstanceCount": 16,
"failedInstanceCount": 0,
"inProgressInstanceCount": 4,
"pendingInstanceCount": 0
},
"startedBy": "Platform",
"targetImageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2016-Datacenter",
"version": "2016.127.20180613"
},
"rollbackInfo": {
"successfullyRolledbackInstanceCount": 0,
"failedRolledbackInstanceCount": 0
}
},
"type": "Microsoft.Compute/virtualMachineScaleSets/rollingUpgrades",
"location": "westeurope"
}
]
}
Azure PowerShell
استخدم الأمر Get-AzVmss cmdlet للتحقق من سجل ترقية نظام التشغيل لمجموعة القياس الخاصة بك. يوضح المثال التالي بالتفصيل كيفية مراجعة حالة ترقية نظام التشغيل لمجموعة قياس باسم myScaleSet في مجموعة الموارد المسماة myResourceGroup:
Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory
Azure CLI 2.0
استخدم get-os-Upgrade-history-az vmss للتحقق من سجل ترقية نظام التشغيل لمجموعة القياس الخاصة بك. استخدم Azure CLI 2.0.47 أو أعلى. يوضح المثال التالي بالتفصيل كيفية مراجعة حالة ترقية نظام التشغيل لمجموعة قياس باسم myScaleSet في مجموعة الموارد المسماة myResourceGroup:
az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet
كيفية الحصول على أحدث إصدار من صورة نظام التشغيل الأساسي؟
يمكنك الحصول على إصدارات الصور المتاحة لوحدات SKU المدعومة للترقية التلقائية لنظام التشغيل باستخدام الأمثلة التالية:
واجهة برمجة تطبيقات REST
GET on `/subscriptions/subscription_id/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions?api-version=2021-03-01`
Azure PowerShell
Get-AzVmImage -Location "westus" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"
Azure CLI 2.0
az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all
تشغيل ترقيات صورة نظام التشغيل يدوياً
مع تمكين الترقية التلقائية لصورة نظام التشغيل في مجموعة القياس الخاصة بك، لن تحتاج إلى تشغيل تحديثات الصور يدوياً على مجموعة القياس الخاصة بك. سيقوم منسق ترقية نظام التشغيل تلقائياً بتطبيق أحدث إصدار متاح للصور على مثيلات مجموعة المقاييس الخاصة بك دون أي تدخل يدوي.
بالنسبة للحالات المحددة التي لا تريد فيها الانتظار حتى يقوم المنسق بتطبيق أحدث صورة، يمكنك تشغيل ترقية صورة نظام التشغيل يدوياً باستخدام الأمثلة أدناه.
إشعار
لا يوفر المشغل اليدوي لترقيات صورة نظام التشغيل إمكانيات التراجع التلقائي. إذا لم يستعد مثيل سلامته بعد عملية ترقية، فلا يمكن استعادة قرص نظام التشغيل السابق الخاص به.
واجهة برمجة تطبيقات REST
استخدم استدعاء بدء ترقية نظام التشغيل API لبدء ترقية متجددة لنقل جميع مثيلات مجموعة مقياس الجهاز الظاهري إلى أحدث إصدار متاح من نظام التشغيل للصور. لن تتأثر المثيلات التي تعمل بالفعل بأحدث إصدار متاح من نظام التشغيل. يوضح المثال التالي كيف يمكنك بدء ترقية متجددة لنظام التشغيل على مجموعة مقاييس تسمى myScaleSet في مجموعة الموارد المسماة myResourceGroup:
POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`
Azure PowerShell
استخدم الأمر Start-AzVmssRollingOSUpgrade cmdlet للتحقق من سجل ترقية نظام التشغيل لمجموعة القياس الخاصة بك. يوضح المثال التالي كيف يمكنك بدء ترقية متجددة لنظام التشغيل على مجموعة مقاييس تسمى myScaleSet في مجموعة الموارد المسماة myResourceGroup:
Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"
Azure CLI 2.0
استخدم بدء الترقية المتداول من az vmss للتحقق من سجل ترقية نظام التشغيل لمجموعة القياس الخاصة بك. استخدم Azure CLI 2.0.47 أو أعلى. يوضح المثال التالي كيف يمكنك بدء ترقية متجددة لنظام التشغيل على مجموعة مقاييس تسمى myScaleSet في مجموعة الموارد المسماة myResourceGroup:
az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"
الاستفادة من سجلات النشاط لإعلامات الترقية ونتائج التحليلات
سجل النشاط هو سجل اشتراك يوفر نظرة ثاقبة على الأحداث على مستوى الاشتراك التي حدثت في Azure. العملاء قادرون على:
- راجع الأحداث المتعلقة بالعمليات التي تم إجراؤها على مواردها في مدخل Microsoft Azure
- إنشاء مجموعات إجراءات لضبط أساليب الإعلام مثل البريد الإلكتروني أو الرسائل القصيرة أو الإخطارات على الويب أو ITSM
- إعداد تنبيهات مناسبة باستخدام معايير مختلفة باستخدام المدخل أو قالب مورد ARM أو PowerShell أو CLI لإرسالها إلى مجموعات الإجراءات
سيتلقى العملاء ثلاثة أنواع من الإعلامات المتعلقة بعملية الترقية التلقائية لنظام التشغيل:
- إرسال طلب ترقية لمورد معين
- نتيجة طلب الإرسال مع أي تفاصيل خطأ
- نتيجة إكمال الترقية مع أي تفاصيل خطأ
إعداد مجموعات الإجراءات لتنبيهات سجل النشاط
مجموعة الإجراءات هي مجموعة من تفضيلات الإعلامات التي يحددها مالك اشتراك Azure. تستخدم تنبيهات Azure Monitor و Service Health مجموعات الإجراءات لإعلام المستخدمين بأنه تم تشغيل تنبيه.
يمكن إنشاء مجموعات الإجراءات وإدارتها باستخدام:
- ARM Resource Manager
- بوابة
- PowerShell:
- المبادره القطريه
يمكن للعملاء إعداد ما يلي باستخدام مجموعات الإجراءات:
- رسائل SMS و/أو إعلامات البريد الإلكتروني
- الإخطارات على الويب - يمكن للعملاء إرفاق خطافات الويب بسجلات التشغيل التلقائي الخاصة بهم وتكوين مجموعات الإجراءات الخاصة بهم لتشغيل دفاتر التشغيل. يمكنك بدء تشغيل دفتر تشغيل من إخطار على الويب
- اتصالات ITSM
التحقيق في أخطاء الترقية التلقائية وحلها
يمكن للنظام الأساسي إرجاع أخطاء على الأجهزة الظاهرية أثناء تنفيذ الترقية التلقائية للصورة باستخدام نهج Rolling Upgrade. تحتوي طريقة عرض Get Instance لجهاز ظاهري على رسالة الخطأ التفصيلية للتحقيق في خطأ وحله. يمكن أن توفر الترقيات المتداولة - الحصول على الأحدث مزيدا من التفاصيل حول تكوين الترقية المتجددة وحالتها. توفر محفوظات ترقية نظام التشغيل Get OS تفاصيل حول عملية ترقية الصورة الأخيرة على مجموعة المقياس. فيما يلي أهم الأخطاء التي يمكن أن تؤدي إلى ترقيات متجددة.
RollingUpgradeInProgressWithFailedUpgradedVMs
- يتم تشغيل الخطأ لفشل الجهاز الظاهري.
- تذكر رسالة الخطأ التفصيلية ما إذا كان سيتم متابعة/إيقاف الإطلاق مؤقتا استنادا إلى الحد الذي تم تكوينه.
MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade
- يتم تشغيل الخطأ عندما تتجاوز النسبة المئوية للأجهزة الظاهرية التي تمت ترقيتها الحد الأقصى المسموح به للأجهزة الظاهرية غير السليمة.
- تجمع رسالة الخطأ التفصيلية الخطأ الأكثر شيوعا الذي يساهم في الأجهزة الظاهرية غير السليمة. راجع MaxUnhealthyUpgradedInstancePercent.
MaxUnhealthyInstancePercentExceededInRollingUpgrade
- يتم تشغيل الخطأ عندما تتجاوز النسبة المئوية للأجهزة الظاهرية غير السليمة الحد الأقصى المسموح به للأجهزة الظاهرية غير السليمة أثناء الترقية.
- تعرض رسالة الخطأ التفصيلية النسبة المئوية الحالية غير السليمة والنسبة المئوية المسموح بها للجهاز الظاهري غير السليم التي تم تكوينها. راجع maxUnhealthyInstancePercent.
MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade
- يتم تشغيل الخطأ عندما تتجاوز النسبة المئوية للأجهزة الظاهرية غير السليمة الحد الأقصى المسموح به للأجهزة الظاهرية غير السليمة قبل إجراء الترقية.
- تعرض رسالة الخطأ التفصيلية النسبة المئوية الحالية غير السليمة والنسبة المئوية المسموح بها للجهاز الظاهري غير السليم التي تم تكوينها. راجع maxUnhealthyInstancePercent.
InternalExecutionError
- يتم تشغيل الخطأ عند حدوث غير معالج أو غير منسق أو غير متوقع أثناء التنفيذ.
- تعرض رسالة الخطأ التفصيلية سبب الخطأ.
RollingUpgradeTimeoutError
- يتم تشغيل الخطأ عند انتهاء مهلة عملية الترقية المتداولة.
- تعرض رسالة الخطأ التفصيلية مدة انتهاء مهلة النظام بعد محاولة التحديث.