التعمق التقني في الترحيل المدعوم من النظام الأساسي من الإصدار الكلاسيكي إلى Azure Resource Manager
ينطبق على: ✔️ أجهزة ظاهرية بنظام التشغيل Linux ✔️ أجهزة ظاهرية بنظام التشغيل Windows
هام
اليوم، يستخدم حوالي 90٪ من أجهزة IaaS الظاهرية Azure Resource Manager. اعتبارا من 28 فبراير 2020، تم إهمال الأجهزة الظاهرية الكلاسيكية وسيتم إيقافها بالكامل في 6 سبتمبر 2023. تعرف على المزيد حول هذا الإهمال وكيفية تأثيره عليك.
دعونا نلقي نظرة متعمقة على الترحيل من نموذج النشر الكلاسيكي Azure إلى نموذج نشر Azure Resource Manager. نحن ننظر إلى الموارد على مستوى الموارد والميزات لمساعدتك على فهم كيفية قيام النظام الأساسي ل Azure بترحيل الموارد بين نموذجي النشر. لمزيد من المعلومات، يرجى قراءة مقالة إعلان الخدمة: ترحيل موارد IaaS المدعومة من النظام الأساسي من Resource Manager الكلاسيكي إلى Azure.
ترحيل موارد IaaS من نموذج النشر الكلاسيكي إلى Azure Resource Manager
أولا، من المهم فهم الفرق بين عمليات مستوى البيانات وعمليات مستوى الإدارة على موارد البنية التحتية كخدمة (IaaS).
- يصف مستوى الإدارة/التحكم المكالمات التي تأتي إلى مستوى الإدارة/التحكم أو واجهة برمجة التطبيقات لتعديل الموارد. على سبيل المثال، عمليات مثل إنشاء جهاز ظاهري وإعادة تشغيل جهاز ظاهري وتحديث شبكة ظاهرية بشبكة فرعية جديدة تدير الموارد قيد التشغيل. فهي لا تؤثر بشكل مباشر على الاتصال بالأجهزة الظاهرية.
- يصف مستوى البيانات (التطبيق) وقت تشغيل التطبيق نفسه، ويتضمن التفاعل مع المثيلات التي لا تمر عبر واجهة برمجة تطبيقات Azure. على سبيل المثال، الوصول إلى موقع الويب الخاص بك، أو سحب البيانات من مثيل SQL Server قيد التشغيل أو خادم MongoDB، هي تفاعلات مستوى البيانات أو التطبيق. تتضمن الأمثلة الأخرى نسخ نقطة من حساب تخزين والوصول إلى عنوان IP عام لاستخدام بروتوكول سطح المكتب البعيد (RDP) أو Secure Shell (SSH) إلى الجهاز الظاهري. تحافظ هذه العمليات على تشغيل التطبيق عبر الحوسبة والشبكات والتخزين.
مستوى البيانات هو نفسه بين نموذج النشر الكلاسيكي ومكدسات Resource Manager. الفرق هو أنه أثناء عملية الترحيل، تترجم Microsoft تمثيل الموارد من نموذج النشر الكلاسيكي إلى النموذج الموجود في مكدس Resource Manager. ونتيجة لذلك، تحتاج إلى استخدام أدوات جديدة واجهات برمجة التطبيقات و SDKs لإدارة الموارد الخاصة بك في مكدس إدارة الموارد.
إشعار
في بعض سيناريوهات الترحيل، يقوم النظام الأساسي Azure بإيقاف الأجهزة الظاهرية وتحديد مواقعها وإعادة تشغيلها. يؤدي هذا إلى توقف قصير عن العمل على مستوى البيانات.
تجربة الترحيل
قبل بدء الترحيل:
- تأكد من أن الموارد التي تريد ترحيلها لا تستخدم أي ميزات أو تكوينات غير مدعومة. عادة ما يكتشف النظام الأساسي هذه المشكلات ويولد خطأ.
- إذا كان لديك أجهزة ظاهرية غير موجودة في شبكة ظاهرية، إيقافها وإلغاء تخصيصها كجزء من عملية الإعداد. إذا كنت لا تريد أن تفقد عنوان IP العام، ففكر في حجز عنوان IP قبل تشغيل عملية الإعداد. إذا كانت الأجهزة الظاهرية في شبكة ظاهرية، فلن يتم إيقافها و إلغاء تخصيصها.
- خطط للترحيل خلال ساعات العمل غير الرسمية لاستيعاب أي حالات فشل غير متوقعة قد تحدث أثناء الترحيل.
- قم بتنزيل التكوين الحالي للأجهزة الظاهرية باستخدام PowerShell أو أوامر واجهة سطر الأوامر (CLI) أو واجهات برمجة تطبيقات REST لتسهيل التحقق من الصحة بعد اكتمال خطوة الإعداد.
- قم بتحديث البرامج النصية للأتمتة والتشغيل لمعالجة نموذج نشر إدارة الموارد، قبل بدء الترحيل. يمكنك اختياريا إجراء عمليات GET عندما تكون الموارد في الحالة المعدة.
- تقييم نهج التحكم في الوصول المستندة إلى دور Azure (Azure RBAC) التي تم تكوينها على موارد IaaS في نموذج النشر الكلاسيكي، والتخطيط لها بعد اكتمال الترحيل.
سير عمل الترحيل هو كما يلي:
إشعار
العمليات الموضحة في الأقسام التالية كلها غير فعالة. إذا واجهتك مشكلة أخرى غير ميزة غير مدعومة أو خطأ في التكوين، فأعد محاولة إعداد العملية أو إجهاضها أو تنفيذها. يحاول Azure الإجراء مرة أخرى.
التحقق
عملية التحقق من الصحة هي الخطوة الأولى في عملية الترحيل. الهدف من هذه الخطوة هو تحليل حالة الموارد التي تريد ترحيلها في نموذج النشر الكلاسيكي. تقوم العملية بتقييم ما إذا كانت الموارد قادرة على الترحيل (نجاح أو فشل).
حدد الشبكة الظاهرية أو خدمة سحابية (إذا لم تكن في شبكة ظاهرية) التي تريد التحقق من صحتها للترحيل. إذا لم يكن المورد قادرا على الترحيل، يسرد Azure أسباب ذلك.
الشيكات التي لم تتم في عملية التحقق من الصحة
تقوم عملية التحقق من الصحة بتحليل حالة الموارد في نموذج النشر الكلاسيكي فقط. يمكنه التحقق من جميع حالات الفشل والسيناريوهات غير المدعومة بسبب التكوينات المختلفة في نموذج النشر الكلاسيكي. لا يمكن التحقق من جميع المشكلات التي قد تفرضها مكدس إدارة موارد Azure على الموارد أثناء الترحيل. يتم التحقق من هذه المشكلات فقط عندما تخضع الموارد للتحويل في الخطوة التالية من الترحيل (عملية الإعداد). يسرد الجدول التالي كافة المشكلات التي لم يتم تحديدها في عملية التحقق من الصحة:
عمليات التحقق من الشبكات غير الموجودة في عملية التحقق من الصحة |
---|
شبكة افتراضية تحتوي على بوابات ER و VPN. |
اتصال بوابة شبكة ظاهرية في حالة قطع الاتصال. |
يتم ترحيل جميع دوائر التقارير الإلكترونية مسبقا إلى مكدس إدارة موارد Azure. |
إدارة موارد Azure عمليات التحقق من الحصص النسبية لموارد الشبكات. على سبيل المثال: IP العام الثابت وعناوين IP العامة الديناميكية وموازن الأحمال ومجموعات أمان الشبكة وجداول المسارات وواجهات الشبكة. |
جميع قواعد موازن التحميل صالحة عبر النشر والشبكة الظاهرية. |
عناوين IP الخاصة المتضاربة بين الأجهزة الظاهرية التي تم إلغاء تخصيصها في نفس الشبكة الظاهرية. |
تجهيز
عملية الإعداد هي الخطوة الثانية في عملية الترحيل. الهدف من هذه الخطوة هو محاكاة تحويل موارد IaaS من طراز النشر الكلاسيكي إلى موارد إدارة الموارد. علاوة على ذلك، تقدم عملية التحضير هذا جنبا إلى جنب لتتمكن من تصوره.
إشعار
لا يتم تعديل الموارد الخاصة بك في نموذج النشر الكلاسيكي خلال هذه الخطوة. إنها خطوة آمنة للتشغيل إذا كنت تحاول الترحيل.
حدد الشبكة الظاهرية أو الخدمة السحابية (إذا لم تكن شبكة ظاهرية) التي تريد إعدادها للترحيل.
- إذا لم يكن المورد قادرا على الترحيل، يقوم Azure بإيقاف عملية الترحيل ويسرد سبب فشل عملية الإعداد.
- إذا كان المورد قادرا على الترحيل، يقوم Azure بتأمين عمليات مستوى الإدارة للموارد قيد الترحيل. على سبيل المثال، لا يمكنك إضافة قرص بيانات إلى جهاز ظاهري ضمن الترحيل.
Azure ثم يبدأ ترحيل بيانات التعريف من طراز النشر الكلاسيكي إلى إدارة الموارد للموارد الترحيل.
بعد اكتمال عملية التحضير، لديك خيار تصور الموارد في كل من طراز النشر الكلاسيكي وإدارة الموارد. لكل خدمة سحابية في نموذج النشر الكلاسيكي، يقوم النظام الأساسي Azure بإنشاء اسم مجموعة موارد يحتوي على النمط cloud-service-name>-Migrated
.
إشعار
لا يمكن تحديد اسم مجموعة موارد تم إنشاؤها للموارد التي تم ترحيلها (أي "-Migrated"). بعد اكتمال الترحيل، ومع ذلك، يمكنك استخدام ميزة نقل إدارة موارد Azure لنقل الموارد إلى أي مجموعة موارد تريدها. لمزيد من المعلومات، راجع نقل الموارد إلى مجموعة موارد جديدة أو اشتراك جديد.
تعرض لقطتا الشاشة التاليتان النتيجة بعد عملية إعداد ناجحة. يعرض الأول مجموعة موارد تحتوي على الخدمة السحابية الأصلية. يعرض الثاني مجموعة الموارد "-ترحيل" الجديدة التي تحتوي على موارد إدارة موارد Azure المكافئة.
فيما يلي نظرة من وراء الكواليس على مواردك بعد الانتهاء من مرحلة الإعداد. لاحظ أن المورد في مستوى البيانات هو نفسه. وهو ممثل في كل من مستوى الإدارة (طراز النشر الكلاسيكي) و مستوى التحكم (إدارة الموارد).
إشعار
يتم إيقاف الأجهزة الظاهرية غير الموجودة في شبكة ظاهرية في نموذج النشر الكلاسيكي وإلغاء تخصيصها في مرحلة الترحيل هذه.
تحقق (يدوي أو مكتوب)
في خطوة الاختيار، يتوفر لديك خيار استخدام التكوين الذي قمت بتنزيله مسبقا للتحقق من صحة الترحيل. بدلا من ذلك، يمكنك تسجيل الدخول إلى البوابة الإلكترونية، والتحقق الفوري من الخصائص والموارد للتحقق من أن ترحيل بيانات التعريف يبدو جيدا.
إذا كنت تقوم بترحيل شبكة ظاهرية، فلن تتم إعادة تشغيل معظم تكوين الأجهزة الظاهرية. بالنسبة للتطبيقات الموجودة على هذه الأجهزة الظاهرية، يمكنك التحقق من أن التطبيق لا يزال قيد التشغيل.
يمكنك اختبار البرامج النصية للمراقبة والتشغيل لمعرفة ما إذا كانت الأجهزة الظاهرية تعمل كما هو متوقع، وما إذا كانت البرامج النصية المحدثة تعمل بشكل صحيح. يتم دعم عمليات GET فقط عندما تكون الموارد في حالة الاستعداد.
لا توجد نافذة زمنية محددة تحتاج قبلها إلى تنفيذ الترحيل. يمكنك أن تأخذ الكثير من الوقت كما تريد في هذه الحالة. ومع ذلك، يتم تأمين مستوى الإدارة لهذه الموارد حتى تقوم إما بالإجهاض أو الالتزام.
إذا رأيت أي مشكلات، فيمكنك دائما إجهاض الترحيل والعودة إلى نموذج النشر الكلاسيكي. بعد العودة، يفتح Azure عمليات مستوى الإدارة على الموارد، بحيث يمكنك استئناف العمليات العادية على تلك الأجهزة الظاهرية في نموذج النشر الكلاسيكي.
يجهض
هذه خطوة اختيارية إذا كنت تريد إعادة التغييرات إلى نموذج النشر الكلاسيكي وإيقاف الترحيل. حذف هذه العملية بيانات التعريف إدارة الموارد (التي تم إنشاؤها في خطوة تحضير) للموارد الخاصة بك.
إشعار
لا يمكن إجراء هذه العملية بعد تشغيل عملية الالتزام.
تثبيت
بعد الانتهاء من التحقق من الصحة، يمكنك تنفيذ الترحيل. الموارد لا تظهر بعد الآن في طراز النشر الكلاسيكية، وتتوفر فقط في طراز توزيع إدارة الموارد. لا يمكن إدارة الموارد التي تم ترحيلها إلا في البوابة الإلكترونية الجديدة.
إشعار
هذه عملية غير ظاهرة إذا فشلت، أعد محاولة العملية. إذا استمر الفشل، فبادر بإنشاء تذكرة دعم أو إنشاء منتدى على Microsoft Q&A
مخطط انسيابي للترحيل
في ما يلي مخطط انسيابي يوضح كيفية متابعة الترحيل:
ترجمة طراز النشر الكلاسيكي إلى موارد إدارة الموارد
يمكنك العثور على طراز النشر الكلاسيكي وتمثيلات إدارة الموارد للموارد في الجدول التالي. الميزات والموارد الأخرى غير مدعومة حاليا.
التمثيل الكلاسيكي | تمثيل إدارة الموارد | ملاحظات |
---|---|---|
اسم الخدمة السحابية (اسم الخدمة المستضافة) | اسم نظام أسماء المجالات (DNS) | أثناء الترحيل، يتم إنشاء مجموعة موارد جديدة لكل خدمة سحابية باستخدام نمط التسمية <cloudservicename>-migrated . تحتوي مجموعة الموارد هذه على جميع مواردك. يصبح اسم الخدمة السحابية اسم DNS مقترنا بعنوان IP العام. |
الجهاز الظاهري | الجهاز الظاهري | يتم ترحيل الخصائص الخاصة ب VM دون تغيير. لا يتم تخزين بعض معلومات osProfile، مثل اسم الكمبيوتر، في نموذج النشر الكلاسيكي، وتظل فارغة بعد الترحيل. |
موارد القرص المرفقة بالجهاز الظاهري | الأقراص الضمنية المرفقة بالجهاز الظاهري | لا يتم تصميم الأقراص كموارد المستوى الأعلى في طراز توزيع إدارة الموارد. يتم ترحيلها كأقراص ضمنية تحت الجهاز الظاهري. يتم حاليا دعم الأقراص المرفقة بجهاز ظاهري فقط. يمكن الآن استخدام حسابات التخزين إدارة الموارد في طراز النشر الكلاسيكية، والذي يسمح الأقراص ليتم ترحيلها بسهولة دون أي تحديثات. |
امتدادات الجهاز الظاهري | امتدادات الجهاز الظاهري | يتم ترحيل كافة ملحقات الموارد، باستثناء ملحقات XML، من نموذج النشر الكلاسيكي. |
شهادات الجهاز الظاهري | الشهادات في Azure Key Vault | إذا كانت الخدمة السحابية تحتوي على شهادات خدمة، فإن الترحيل ينشئ مخزن مفاتيح Azure جديدا لكل خدمة سحابية، وينقل الشهادات إلى مخزن المفاتيح. يتم تحديث الأجهزة الظاهرية للإشارة إلى الشهادات من قبو المفاتيح. لا تحذف قبو المفاتيح. هذا يمكن أن يسبب الجهاز الظاهري للذهاب إلى حالة فاشلة. |
تكوين WinRM | تكوين WinRM ضمن ملف تعريف النظام التشغيلي | Windows يتم نقل تكوين "الإدارة عن بعد" دون تغيير، كجزء من الترحيل. |
مكان الإقامة المتاح | مورد مجموعة التوفر | مواصفات مجموعة التوفر هي خاصية على الجهاز الظاهري في نموذج النشر الكلاسيكي. تصبح مجموعات التوفر موردا عالي المستوى كجزء من الترحيل. التكوينات التالية غير مدعومة: مجموعات توفر متعددة لكل خدمة سحابية، أو مجموعة توفر واحدة أو أكثر إلى جانب الأجهزة الظاهرية التي ليست في أي توفر تم تعيينها في خدمة سحابية. |
تكوين الشبكة على جهاز ظاهري | واجهة الشبكة الأساسية | يتم تمثيل تكوين الشبكة على جهاز ظاهري كمورد واجهة الشبكة الأساسي بعد الترحيل. بالنسبة للأجهزة الظاهرية غير الموجودة في شبكة ظاهرية، يتغير عنوان IP الداخلي أثناء الترحيل. |
واجهات شبكة متعددة على جهاز ظاهري | واجهات الشبكة | إذا كان الجهاز الظاهري يحتوي على واجهات شبكة متعددة مرتبطة به، تصبح كل واجهة شبكة موردا من المستوى الأعلى كجزء من الترحيل، إلى جانب جميع الخصائص. |
مجموعة نقاط نهاية متوازنة الحمل | موازن التحميل | في نموذج النشر الكلاسيكي، قام النظام الأساسي بتعيين موازن تحميل ضمني لكل خدمة سحابية. أثناء الترحيل، يتم إنشاء مورد جديد لموازن الأحمال، وتصبح مجموعة نقاط نهاية موازنة التحميل قواعد موازن التحميل. |
قواعد ترجمة عناوين الشبكة الواردة | قواعد ترجمة عناوين الشبكة الواردة | يتم تحويل نقاط نهاية الإدخال المحددة على الجهاز الظاهري إلى قواعد ترجمة عنوان الشبكة الواردة ضمن موازن التحميل أثناء الترحيل. |
عنوان VIP | عنوان IP العام باسم DNS | يصبح عنوان IP الظاهري عنوان IP عاما، ويرتبط بموازن التحميل. لا يمكن ترحيل عنوان IP افتراضي إلا إذا كانت هناك نقطة نهاية إدخال معينة له. للاحتفاظ بعنوان IP، يمكنك تحويله إلى عنوان IP محجوز قبل الترحيل. سيكون هناك وقت توقف لمدة 60 ثانية تقريبا أثناء هذا التغيير. |
الشبكة الظاهرية | الشبكة الظاهرية | يتم ترحيل الشبكة الظاهرية، بجميع خصائصها، إلى نموذج نشر إدارة الموارد. يتم إنشاء مجموعة موارد جديدة بالاسم -migrated . |
IPs محجوزة | عنوان IP عام مع طريقة تخصيص ثابتة | يتم ترحيل عناوين IP المحجوزة المرتبطة بموازن التحميل، إلى جانب ترحيل الخدمة السحابية أو الجهاز الظاهري. يمكن ترحيل عناوين IP المحجوزة غير المرتبطة باستخدام Move-AzureReservedIP. |
عنوان IP العام لكل VM | عنوان IP عام مع طريقة تخصيص ديناميكية | يتم تحويل عنوان IP العام المقترن بالجهاز الظاهري كمورد عنوان IP عام، مع تعيين طريقة التخصيص إلى ديناميكية. |
NSG | NSG | يتم استنساخ مجموعات أمان الشبكة المقترنة بجهاز ظاهري أو شبكة فرعية كجزء من الترحيل إلى نموذج نشر إدارة الموارد. لا تتم إزالة NSG في نموذج النشر الكلاسيكي أثناء الترحيل. ومع ذلك، يتم حظر عمليات مستوى الإدارة لمجموعة موردي المواد النووية عندما يكون الترحيل قيد التقدم. يمكن ترحيل NSGs غير المرتبطة باستخدام Move-AzureNetworkSecurityGroup. |
خوادم DNS | خوادم DNS | يتم ترحيل خوادم DNS المقترنة بشبكة ظاهرية أو الجهاز الظاهري كجزء من ترحيل الموارد المقابل، إلى جانب جميع الخصائص. |
UDRs | UDRs | يتم استنساخ التوجيهات المعرفة من قبل المستخدم المقترنة بشبكة فرعية كجزء من الترحيل إلى نموذج توزيع إدارة الموارد. لا تتم إزالة UDR في نموذج النشر الكلاسيكي أثناء الترحيل. يتم حظر عمليات مستوى الإدارة ل UDR عندما يكون الترحيل قيد التقدم. يمكن ترحيل UDRs غير المقترنة باستخدام Move-AzureRouteTable. |
خاصية إعادة توجيه IP على تكوين شبكة الجهاز الظاهري | خاصية إعادة توجيه IP على NIC | يتم تحويل خاصية إعادة توجيه IP على جهاز ظاهري إلى خاصية على واجهة الشبكة أثناء الترحيل. |
موازن التحميل مع عناوين IP متعددة | موازن التحميل مع موارد IP عامة متعددة | يتم تحويل كل عنوان IP عام مقترن بموازن التحميل إلى مورد IP عام، ويرتبط بموازن التحميل بعد الترحيل. |
أسماء DNS الداخلية على الجهاز الظاهري | أسماء DNS الداخلية على NIC | أثناء الترحيل، يتم ترحيل لواحق DNS الداخلية للأجهزة الظاهرية إلى خاصية للقراءة فقط تسمى "InternalDomainNameSuffix" على NIC. تظل اللاحقة دون تغيير بعد الترحيل، ويجب أن تستمر دقة VM في العمل كما كانت في السابق. |
بوابة الشبكة الظاهرية | بوابة الشبكة الظاهرية | يتم ترحيل خصائص بوابة الشبكة الظاهرية دون تغيير. لا يتغير VIP المرتبط بالبوابة أيضا. |
موقع الشبكة المحلية | بوابة الشبكة المحلية | يتم ترحيل خصائص موقع الشبكة المحلية دون تغيير إلى مورد جديد يسمى بوابة شبكة محلية. يمثل هذا بادئات العناوين المحلية وعنوان IP للبوابة البعيدة. |
مراجع الاتصالات | الاتصال | يتم تمثيل مراجع الاتصال بين البوابة وموقع الشبكة المحلية في تكوين الشبكة بواسطة مورد جديد يسمى الاتصال. يتم نسخ كافة خصائص مرجع الاتصال في ملفات تكوين الشبكة دون تغيير إلى مورد الاتصال. يتم تحقيق الاتصال بين الشبكات الافتراضية في نموذج النشر الكلاسيكي عن طريق إنشاء نفقين IPsec إلى مواقع الشبكة المحلية التي تمثل الشبكات الافتراضية. يتم تحويل هذا إلى نوع اتصال شبكة الاتصال الظاهري إلى شبكة ظاهرية في طراز إدارة الموارد دون الحاجة إلى عبارات شبكة الاتصال المحلية. |
التغييرات التي تطرأ على التشغيل التلقائي والأدوات بعد الترحيل
كجزء من ترحيل الموارد الخاصة بك من طراز النشر الكلاسيكي إلى طراز توزيع إدارة الموارد، يجب تحديث التشغيل التلقائي أو الأدوات الموجودة للتأكد من استمرار العمل بعد الترحيل.
الخطوات التالية
- نظرة عامة على الترحيل المدعوم من النظام الأساسي لموارد IaaS من الكلاسيكية إلى Azure Resource Manager
- التخطيط لترحيل موارد IaaS من الكلاسيكية إلى Azure Resource Manager
- استخدام PowerShell لترحيل موارد IaaS من الإصدار الكلاسيكي إلى Azure Resource Manager
- استخدام CLI لترحيل موارد IaaS من الكلاسيكية إلى Azure Resource Manager
- بوابة VPN الكلاسيكية لترحيل إدارة الموارد
- ترحيل دوائر ExpressRoute والشبكات الظاهرية المقترنة من الطراز الكلاسيكي إلى نموذج توزيع إدارة الموارد
- أدوات المجتمع للمساعدة في ترحيل موارد IaaS من الكلاسيكية إلى Azure Resource Manager
- مراجعة أخطاء الترحيل الأكثر شيوعا
- راجع الأسئلة الأكثر شيوعاً حول ترحيل موارد خدمة تأجير البنية التحتية من النموذج الكلاسيكي إلى نموذج Azure Resource Manager