مشاركة عبر

التخطيط لإجراء الترحيل لموارد IaaS من النموذج الكلاسيكي إلى نموذج Azure Resource Manager

  • مقالة

ينطبق على: ✔️ أجهزة ظاهرية بنظام التشغيل Linux ✔️ أجهزة ظاهرية بنظام التشغيل Windows

هام

اليوم، يستخدم حوالي 90٪ من أجهزة IaaS الظاهرية Azure Resource Manager. اعتبارا من 28 فبراير 2020، تم إهمال الأجهزة الظاهرية الكلاسيكية وسيتم إيقافها بالكامل في 6 سبتمبر 2023. تعرف على المزيد حول هذا الإهمال وكيفية تأثيره عليك.

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

إشعار

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

هناك أربع مراحل عامة لرحلة الترحيل:

مراحل الترحيل

الخطة

الاعتبارات التقنية والمقايضات

بناءً على حجم متطلباتك التقنية والمناطق الجغرافية والممارسات التشغيلية، قد تحتاج إلى وضع ما يلي في الاعتبار:

  1. لماذا Azure Resource Manager مطلوب لمؤسستك؟ ما هي الأسباب التجارية للترحيل؟
  2. ما هي الأسباب التقنية بالنسبة إلىAzure Resource Manager؟ ماذا (إن وجدت) خدمات Azure الأخرى التي ترغب في استخدامها؟
  3. ما التطبيق (أو مجموعات الأجهزة الافتراضية) المضمنة في الترحيل؟
  4. ما هي السيناريوهات المدعومة مع واجهة برمجة تطبيقات الترحيل؟ راجع الميزات والتكوينات غير المدعومة.
  5. هل ستدعم فرقك التشغيلية الآن التطبيقات/الأجهزة الظاهرية في كل من النماذج الكلاسيكية وAzure Resource Manager؟
  6. كيف يقوم Azure Resource Manager (إن وجد) بتغيير عمليات نشر الأجهزة الظاهرية وإدارتها ومراقبتها وإعداد التقارير عنها؟ هل تحتاج البرامج النصية للنشر إلى التحديث؟
  7. ما هي خطة الاتصالات لتنبيه المساهمين (المستخدمين النهائيين ومالكي التطبيقات ومالكي البنية التحتية)؟
  8. اعتماداً على تعقيد البيئة، هل يجب أن تكون هناك فترة صيانة لا يتوفر فيها التطبيق للمستخدمين النهائيين ومالكي التطبيقات؟ إذا كان الأمر كذلك، فإلى متى؟
  9. ما هي خطة التدريب لضمان معرفة حملة الأسهم وإتقانهم لـ Azure Resource Manager؟
  10. ما هي خطة إدارة البرنامج أو إدارة المشاريع للترحيل؟
  11. ما هي الجداول الزمنية لترحيل Azure Resource Manager وخرائط طريق التكنولوجيا الأخرى ذات الصلة؟ هل تم محاذاتها على النحو الأمثل؟

أنماط النجاح

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

الأخطاء التي يجب تجنبها

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

الاختبارات المعملية

النسخ المتماثل لبيئتك وإجراء ترحيل تجريبي

إشعار

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

يعد إجراء اختبار معملي للسيناريو الدقيق (الحوسبة والشبكات والتخزين) أفضل طريقة لضمان الترحيل السلس. سيساعد ذلك على ضمان:

  • وجود مختبر منفصل تماماً أو بيئة غير تشغيلية للاختبار. نوصي بإنشاء مختبر منفصل تماماً يمكن ترحيله بشكل متكرر ويمكن تعديله بشكل مدمر. البرامج النصية لجمع/تحميل باستخدام بيانات تعريف المجال من الاشتراكات الحقيقية مدرجة أدناه.

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

    يمكن تحقيق ذلك باستخدام أداة AsmMetadataParser. اقرأ المزيد عن هذه الأداة هنا

أنماط النجاح

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

  • قم بإجراء عملية التحقق من الصحة/التحضير/إيقاف التشغيل التجريبي - ربما تكون هذه هي الخطوة الأكثر أهمية لضمان نجاح الترحيل من النموذج الكلاسيكي إلى Azure Resource Manager. تحتوي واجهة برمجة تطبيقات الترحيل على ثلاث خطوات رئيسية: التحقق من الصحة والإعداد والالتزام. سيقرأ التحقق من الصحة حالة بيئتك الكلاسيكية ويعرض نتيجة لجميع المشكلات. ومع ذلك، نظرا لوجود بعض المشكلات في مكدس Azure Resource Manager، لن يلتقط Validate كل شيء. الخطوة التالية في عملية الترحيل، سيساعد الاستعداد في الكشف عن هذه المشكلات. سيقوم الإعداد بنقل بيانات التعريف من Classic إلى Azure Resource Manager، ولكنه لن يلتزم بالنقل، ولن يزيل أي شيء أو يغيره على الجانب الكلاسيكي. يتضمن التشغيل الجاف إعداد الترحيل، ثم إجهاض (عدم الالتزام) إعداد عمليات الترحيل. الهدف من التحقق من صحة / الإعداد / إيقاف التشغيل التجريبي يتجلى في رؤية جميع بيانات التعريف في مكدس Azure Resource Manager، وفحصها (برمجياً أو في المدخل)، والتحقق من ترحيل كل شيء بشكل صحيح، والعمل على حل المشكلات الفنية. سيعطيك أيضاً إحساساً بمدة الترحيل حتى تتمكن من التخطيط لوقت التعطل وفقاً لذلك. لا يتسبب التحقق/التحضير/الإيقاف في أي وقت تعطل للمستخدم؛ لذلك، فإنه غير متقطع لاستخدام التطبيق.

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

  • دوائر Express Route وشبكة ظاهرية خاصة (VPN). لا يمكن حاليا ترحيل Express Route Gateways ذات ارتباطات التخويل دون وقت تعطل. للحل البديل، راجع ترحيل دوائر ExpressRoute والشبكات الظاهرية المقترنة من الوضع الكلاسيكي إلى نموذج توزيع Resource Manager.

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

    • في حالة فقدان الاتصال بخادم DNS أثناء الترحيل، يجب أولاً إزالة جميع ملحقات الأجهزة الظاهرية باستثناء BGInfo v1.* من كل جهاز ظاهري قبل إعداد الترحيل، ثم إعادة إضافتها مرة أخرى إلى الجهاز الظاهري بعد ترحيل Resource Manager Azure. هذا فقط للأجهزة الظاهرية قيد التشغيل. إذا تم إيقاف إلغاء تخصيص الأجهزة الظاهرية، فلن تحتاج ملحقات الجهاز الظاهري إلى إزالتها. ملاحظة: ستقوم العديد من الملحقات مثل تشخيص Azure ومراقبة Defender for Cloud بإعادة تثبيت نفسها بعد الترحيل، لذا فإن إزالتها ليست مشكلة.

    • بالإضافة إلى ذلك، تأكد من أن مجموعات أمان الشبكة لا تقيد الوصول إلى الإنترنت الصادر. يمكن أن يحدث هذا مع بعض تكوينات مجموعات أمان الشبكة. يلزم الوصول إلى الإنترنت الصادر (و DNS) لترحيل ملحقات الأجهزة الظاهرية إلى Azure Resource Manager.

    • هناك إصداران من ملحق BGInfo: v1 و v2. إذا تم إنشاء الجهاز الظاهري باستخدام مدخل Azure أو PowerShell، فمن المحتمل أن يحتوي الجهاز الظاهري على ملحق v1 عليه. لا يلزم إزالة هذا الملحق وسيتم تخطيه (لم يتم ترحيله) بواسطة واجهة برمجة تطبيقات الترحيل. ومع ذلك، إذا تم إنشاء الجهاز الظاهري الكلاسيكي باستخدام مدخل Azure الجديد، فمن المحتمل أن يحتوي على إصدار v2 المستند إلى JSON من BGInfo، والذي يمكن ترحيله إلى Azure Resource Manager شريطة أن يعمل الوكيل ولديه وصول إلى الإنترنت الصادر (وDNS).

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

    • خيار المعالجة 2. إذا كانت ملحقات الجهاز الظاهري كبيرة جداً من الحاجز، فهناك خيار آخر هو إيقاف التشغيل / إلغاء تخصيص جميع الأجهزة الظاهرية قبل الترحيل. قم بترحيل الأجهزة الظاهرية التي تم إلغاء تخصيصها، ثم أعد تشغيلها على الجانب Resource Manager Azure. الفائدة هنا هي أن ملحقات الأجهزة الظاهرية سيتم ترحيلها. الجانب السلبي هو أن جميع عناوين IP العامة التي تواجه عناوين IP الظاهرية ستُفقد (قد يكون هذا غير قابل للبدء)، ومن الواضح أن الأجهزة الظاهرية سيتم إيقاف تشغيلها مما يسبب تأثيراً أكبر بكثير على التطبيقات العاملة.

      إشعار

      إذا تم تكوين نهج Microsoft Defender for Cloud مقابل الأجهزة الظاهرية قيد التشغيل التي يتم ترحيلها، فيجب إيقاف نهج الأمان قبل إزالة الملحقات، وإلا ستتم إعادة تثبيت ملحق مراقبة الأمان تلقائياً على الجهاز الظاهري بعد إزالته.

  • مجموعات التوفر - لكي يتم ترحيل شبكة ظاهرية (vNet) إلى Azure Resource Manager، يجب أن تكون الأجهزة الظاهرية المضمنة في النشر الكلاسيكي (أي الخدمة السحابية) في مجموعة توفر واحدة، أو يجب ألا تكون الأجهزة الظاهرية جميعها في أي مجموعة توافر. وجود أكثر من مجموعة توفر واحدة في الخدمة السحابية غير متوافق مع Azure Resource Manager وسيوقف الترحيل. بالإضافة إلى ذلك، لا يمكن أن يكون هناك بعض الأجهزة الظاهرية في مجموعة توفر، وبعض الأجهزة الظاهرية ليست في مجموعة توفر. لحل هذه المشكلة، ستحتاج إلى معالجة الخدمة السحابية أو إعادة ترتيبها. خطط وفقاً لذلك لأن هذا قد يستغرق وقتاً طويلا.

  • عمليات نشر دور الويب/العامل - لا يمكن ترحيل الخدمات السحابية التي تحتوي على أدوار الويب والعاملين إلى Azure Resource Manager. يجب أولاً إزالة أدوار العامل/الويب من الشبكة الظاهرية قبل بدء الترحيل. الحل النموذجي هو مجرد نقل مثيلات دور العامل/الويب إلى شبكة افتراضية كلاسيكية منفصلة مرتبطة أيضاً بدائرة ExpressRoute، أو ترحيل التعليمات البرمجية إلى خدمات تطبيقات النظام الأساسي كخدمة (PaaS) الأحدث (هذه المناقشة خارج نطاق هذا المستند). في حالة إعادة النشر السابقة، قم بإنشاء شبكة افتراضية كلاسيكية جديدة، ونقل/إعادة نشر أدوار العامل/الويب إلى تلك الشبكة الظاهرية الجديدة، ثم احذف عمليات النشر من الشبكة الظاهرية التي يتم نقلها. لا توجد تغييرات في التعليمات البرمجية المطلوبة. يمكن استخدام إمكانية Virtual Network Peering الجديدة لربط الشبكة الافتراضية الكلاسيكية التي تحتوي على أدوار العامل/الويب والشبكات الافتراضية الأخرى في نفس منطقة Azure مثل الشبكة الافتراضية التي يتم ترحيلها (بعد اكتمال ترحيل الشبكة الافتراضية حيث لا يمكن ترحيل الشبكات الافتراضية النظيرة)، وبالتالي توفير نفس القدرات دون فقدان الأداء ودون عقوبات على زمن الانتقال/النطاق الترددي. نظراً لإضافة Virtual Network Peering، يمكن الآن ترحيل عمليات نشر دور العامل/الويب بسهولة وعدم حظر الترحيل إلى Azure Resource Manager.

  • Azure Resource Manager Quotas - تحتوي مناطق Azure على حصص/حدود منفصلة لكل من Resource Manager الكلاسيكي وAzure. على الرغم من أنه في سيناريو الترحيل لا يتم استهلاك أجهزة جديدة (نقوم بتبديل الأجهزة الظاهرية الحالية من الوضع الكلاسيكي إلى Azure Resource Manager)، إلا أنه لا تزال هناك حاجة إلى وجود حصص Azure Resource Manager بسعة كافية قبل بدء الترحيل. العناصر المدرجة أدناه هي الحدود الرئيسية التي رأينا أنها تسبب مشاكل. افتح تذكرة دعم الحصص لرفع الحدود.

    إشعار

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

    • واجهات الشبكة

    • موازنة التحميل

    • عناوين IP عامة

    • عناوين IP العامة الثابتة

    • الذاكرات الأساسية

    • مجموعات أمان الشبكة

    • ⁧⁩جداول التوجيه⁧⁩

      يمكنك التحقق من الحصص النسبية الحالية لـ Resource Manager Azure باستخدام الأوامر التالية لأحدث إصدار من Azure CLI.

      الحوسبة (الذاكرات الأساسية، مجموعات التوفر)

      az vm list-usage -l <azure-region> -o jsonc

      الشبكة (الشبكات الظاهرية، عناوين IP العامة الثابتة، عناوين IP العامة، مجموعات أمان الشبكة، واجهات الشبكة، موازنات التحميل، جداول التوجيه)

      az network list-usages -l <azure-region> -o jsonc

      التخزين (حساب التخزين)

      az storage account show-usage

  • حدود Azure Resource Manager - إذا كانت لديك بيئة كافية (مثال: >400 جهاز ظاهري في شبكة ظاهرية)، فقد تصل إلى حدود تقييد واجهة برمجة التطبيقات الافتراضية لعمليات الكتابة (تبلغ حالياً 1200 عملية كتابة/الساعة) في Azure Resource Manager. قبل بدء الترحيل، يجب عليك رفع تذكرة دعم لزيادة هذا الحد لاشتراكك.

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

  • حالة الجهاز الظاهري RoleStateUnknown - إذا توقف الترحيل بسبب رسالة خطأ غير معروفة لحالة الدور، فافحص الجهاز الظاهري باستخدام المدخل وتأكد من تشغيله. عادة ما يختفي هذا الخطأ من تلقاء نفسه (لا يلزم معالجته) بعد بضع دقائق وغالباً ما يكون نوعاً عابراً غالباً ما يظهر أثناء بدء تشغيل الجهاز الظاهري أو إيقاف تشغيله، أو إعادة تشغيله. الممارسة الموصى بها: أعد محاولة الترحيل مرة أخرى بعد بضع دقائق.

  • مجموعة النسيج غير موجودة - في بعض الحالات، لا يمكن ترحيل أجهزة ظاهرية معينة لأسباب غريبة مختلفة. إحدى هذه الحالات المعروفة هي إذا تم إنشاء الجهاز الظاهري مؤخرا (خلال الأسبوع الماضي أو نحو ذلك) وحدث أن نزل نظام مجموعة Azure غير مجهزة بعد لأحمال عمل Azure Resource Manager. ستحصل على خطأ يقول إن مجموعة النسيج غير موجودة ولا يمكن ترحيل الجهاز الظاهري. عادةً ما يؤدي الانتظار لبضعة أيام إلى حل هذه المشكلة المحددة حيث سيتم تمكين Azure Resource Manager في المجموعة قريباً. ومع ذلك، فإن أحد الحلول الفورية هو إلى الجهاز الظاهري، ثم تابع stop-deallocate عملية الترحيل، وابدأ تشغيل الجهاز الظاهري احتياطياً في Azure Resource Manager بعد الترحيل.

الأخطاء التي يجب تجنبها

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

الترحيل

الاعتبارات التقنية والمقايضات

أنت الآن جاهز لأنك عملت من خلال المشكلات المعروفة مع بيئتك.

بالنسبة لعمليات الترحيل الحقيقية، يجب اعتبار ما يلي:

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

أنماط النجاح

يجب النظر في الإرشادات الفنية الواردة في قسم الاختبارات المعملية أعلاه وتخفيفها قبل الترحيل الحقيقي. مع الاختبار المناسب، فإن الترحيل هو في الواقع ليس حدثاً. بالنسبة لبيئات التشغيل قد يكون من المفيد الحصول على دعم إضافي، مثل شريك Microsoft موثوق به أو خدمات Microsoft Premier.

الأخطاء التي يجب تجنبها

قد يؤدي عدم الاختبار الكامل إلى حدوث مشكلات وتأخير في الترحيل.

ما وراء الترحيل

الاعتبارات التقنية والمقايضات

الآن بعد أن أصبحت في Azure Resource Manager، قم بتكبير النظام الأساسي. اقرأ نظرة عامة على Azure Resource Manager لمعرفة المزيد عن المزايا الإضافية.

نقاط يجب مراعاتها:

  • تجميع الترحيل مع أنشطة أخرى. يختار معظم العملاء نافذة صيانة التطبيقات. إذا كان الأمر كذلك، فقد ترغب في استخدام وقت التوقف هذا لتمكين إمكانات Azure Resource Manager الأخرى مثل التشفير والترحيل إلى الأقراص المدارة.
  • إعادة النظر في الأسباب التقنية والتجارية ل Azure Resource Manager؛ تمكين الخدمات الإضافية المتوفرة فقط على Azure Resource Manager الذي ينطبق على البيئة الخاصة بك.
  • قم بتحديث بيئتك باستخدام خدمات PaaS.

أنماط النجاح

كن هادفاً بشأن الخدمات التي تريد الآن تمكينها في Azure Resource Manager. يجد العديد من العملاء ما يلي مقنعاً لبيئات Azure الخاصة بهم:

الأخطاء التي يجب تجنبها

تذكر لماذا بدأت رحلة الترحيل من الوضع الكلاسيكي إلى Azure Resource Manager هذه. ما هي الأسباب التجارية الأصلية؟ هل حققت هدف العمل؟

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