Azure Fundamentals · درس

إعادة الاستضافة باستخدام Azure Migrate (النقل كما هو)

نفّذ ترحيل الأجهزة الظاهرية بأسلوب النقل كما هو، بالاعتماد على النسخ المتماثل باستخدام Azure Migrate، واضبط التحويل الشبكي، وتحقق من سلامة التطبيق بعد الترحيل

إعادة الاستضافة باستخدام Azure Migrate (النقل كما هو) درس مجاني في Azure Fundamentals على CoddyKit. هذا هو الدرس 3 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Azure Fundamentals، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Azure Fundamentals 4 دروس في المجموع.

نظرة عامة على Lift and Shift

Rehost — ويُسمّى عادةً Lift and Shift — هو استراتيجية ترحيل تنقلون فيها جهازًا افتراضيًا من البيئة المحلية إلى Azure من دون إجراء تغييرات على نظام التشغيل أو الملفات الثنائية للتطبيق أو البيانات. تعمل أداة Migration and Modernisation في Azure Migrate (المعروفة سابقًا باسم Server Migration) على أتمتة هذه العملية من خلال نسخ بيانات الأقراص إلى Azure، ثم تحويل التشغيل مع الحد الأدنى من وقت التوقف. يُعد Lift and Shift مناسبًا للتطبيقات التي يصعب إعادة تصميمها أو التي تخضع لمواعيد نهائية ضيقة للترحيل.

المتطلبات الأساسية قبل الترحيل

قبل بدء النسخ المتماثل، يجب عليكم: إكمال الاكتشاف والتقييم حتى تتوفر لديكم توصيات وحدات SKU للأجهزة الافتراضية المستهدفة، وإنشاء موارد Azure المستهدفة (مجموعة الموارد، والشبكة الافتراضية، والشبكة الفرعية)، والتأكد من أن جهاز Azure Migrate يعمل بصورة سليمة. بالنسبة إلى مصادر VMware، يجب أن تتوفر للجهاز أذونات قراءة في vCenter، كما يجب أن يكون الجهاز الافتراضي الضيف قابلًا للوصول عبر الشبكة من الجهاز. نزّلوا برنامج Replication Provider وسجّلوه إذا كنتم ترحّلون من Hyper-V أو من خوادم فعلية.

# Verify appliance connectivity and status
az migrate replication-appliance list \
  --resource-group myRG \
  --project-name myMigrateProject

بدء النسخ المتماثل

ينسخ النسخ المتماثل جميع بيانات الأقراص من الجهاز الافتراضي المصدر إلى حساب تخزين ذاكرة مؤقتة تديره Azure، ثم يجهّز البيانات بشكل غير متزامن في Azure. في مدخل Azure Migrate، انتقلوا إلى Replicate، وحددوا الأجهزة الافتراضية المصدر، واربطوها بوحدة SKU الموصى بها للجهاز الافتراضي في Azure، ثم اختاروا الشبكة الافتراضية المستهدفة. يعتمد وقت النسخ المتماثل الأولي على حجم القرص وعرض النطاق الترددي — إذ يستغرق قرص بحجم 100 غيغابايت عبر اتصال بسرعة 100 ميغابت في الثانية نحو ساعتين تقريبًا للمزامنة الأولية.

# Start replication for a discovered server
az migrate server migration start-replication \
  --resource-group myRG \
  --project-name myMigrateProject \
  --machine-name 'web-server-01'

النسخ المتماثل للتغييرات والمزامنة

بعد نسخ صورة القرص الأولية، ينتقل Azure Migrate إلى النسخ المتماثل للتغييرات — حيث تُرسل كتل القرص التي تغيّرت فقط، مما يحافظ على مزامنة النسخة الموجودة في Azure مع المصدر المحلي في وقت شبه فعلي. يستمر الجهاز الافتراضي في العمل محليًا خلال هذه المرحلة. يمكنكم مراقبة صحة النسخ المتماثل، وتأخر RPO، ومعدلات نقل البيانات في المدخل. وعادةً ما يستقر تأخر النسخ المتماثل للتغييرات عند بضع دقائق فقط خلال 24 ساعة من اكتمال المزامنة الأولية.

# Check replication status
az migrate server migration list-replicating-server \
  --resource-group myRG \
  --project-name myMigrateProject \
  --query '[].{Name:machineName, State:migrationState, Health:migrationStateDescription}'

اختبار الترحيل

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

# Initiate a test migration
az migrate server migration test-migrate \
  --resource-group myRG \
  --project-name myMigrateProject \
  --machine-name 'web-server-01' \
  --test-network-id '/subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/test-vnet'

التخطيط لفترة التحويل

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

تنفيذ التحويل

في مدخل Azure Migrate، انقروا على Migrate للخادم المحدد. سيُطلب منكم تحديد ما إذا كنتم تريدون إيقاف تشغيل الجهاز الافتراضي المحلي قبل الترحيل (وهو أمر موصى به لتجنب فقدان البيانات). يطبّق Azure التغييرات النهائية، وينشئ الجهاز الافتراضي في Azure، ويضع علامة على اكتمال الترحيل. بعد ذلك، يجب عليكم تحديث سجلات DNS أو خوادم الواجهة الخلفية لموازن التحميل أو سلاسل اتصال التطبيق لتشير إلى عنوان IP الخاص الجديد أو FQDN في Azure، حتى يبدأ العملاء باستخدام الجهاز الافتراضي في Azure.

# Trigger the final cutover migration
az migrate server migration migrate \
  --resource-group myRG \
  --project-name myMigrateProject \
  --machine-name 'web-server-01' \
  --turn-off-source-server true

التحقق بعد الترحيل

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

# Install Azure Monitor agent on the migrated VM
az vm extension set \
  --resource-group myRG \
  --vm-name web-server-01-azure \
  --name AzureMonitorWindowsAgent \
  --publisher Microsoft.Azure.Monitor \
  --version 1.0

إيقاف تشغيل الموارد المحلية

بعد استقرار الجهاز الافتراضي المرحّل في Azure واعتماد أصحاب المصلحة للنتيجة، يمكنكم إيقاف تشغيل الجهاز الافتراضي المصدر المحلي. في Azure Migrate، حدّدوا Complete Migration لإغلاق النسخ المتماثل. لا يؤدي ذلك إلى إيقاف تشغيل الجهاز الافتراضي المحلي تلقائيًا — بل يجب عليكم إيقاف تشغيله واستعادة الأجهزة من خلال عملية إدارة أصول تقنية المعلومات المعتادة لديكم. يؤدي إيقاف التشغيل إلى خفض تكاليف البنية الأساسية المحلية، ويقرّبكم من نموذج تشغيلي سحابي بالكامل.

# Mark migration complete (stops billing for replication storage)
az migrate server migration complete-migration \
  --resource-group myRG \
  --project-name myMigrateProject \
  --machine-name 'web-server-01'

ترحيل عدة أجهزة افتراضية على نطاق واسع

بالنسبة إلى عمليات الترحيل الكبيرة التي تشمل مئات الأجهزة الافتراضية، يدعم Azure Migrate العمليات المجمعة عبر استيراد CSV. أعدّوا ملف CSV يسرد كل جهاز افتراضي مصدر، ووحدة SKU المستهدفة، ومجموعة الموارد المستهدفة، والشبكة الافتراضية، ثم حمّلوه لبدء النسخ المتماثل لجميع الأجهزة الافتراضية في الوقت نفسه. تتيح مجموعات الترحيل ترتيب النسخ المتماثل والتحويل، بحيث تهاجر طبقات التطبيقات التابعة (قاعدة البيانات، والتطبيق، والويب) بالترتيب الصحيح ضمن فترة الصيانة نفسها.

المشكلات الشائعة والنصائح

انتبهوا إلى مشكلات Lift and Shift الشائعة التالية: قد يمنع تشفير قرص التشغيل على الأجهزة الافتراضية التي تعمل بنظام Linux Azure من تشغيلها (استخدموا Azure Disk Encryption بعد الترحيل)؛ ويجب تحديث عناوين IP الثابتة المضمّنة في إعدادات التطبيقات إلى عناوين IP الخاصة أو أسماء DNS في Azure؛ وقد يلزم تكرار قواعد جدار الحماية المحلية التي تشير إلى عنوان IP الخاص بالخادم في NSG ضمن Azure؛ كما قد تؤدي إعدادات المنطقة الزمنية على الأجهزة الافتراضية التي تعمل بنظام Windows إلى تغييرات في سلوك التطبيق ضمن بيئة Azure التي تستخدم UTC.

تحقق سريع

اختبروا مدى فهمكم لمفاهيم Microsoft Azure Fundamentals (AZ-900) الواردة في هذا الدرس.

مراجعة الدرس

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

الأسئلة الشائعة

هل درس «إعادة الاستضافة باستخدام Azure Migrate (النقل كما هو)» مجاني؟

نعم — نص درس «إعادة الاستضافة باستخدام Azure Migrate (النقل كما هو)» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Azure Fundamentals، انتقل إلى CoddyKit PRO. تتضمن دورة Azure Fundamentals 4 دروس في المجموع.

ماذا ستتعلم في «إعادة الاستضافة باستخدام Azure Migrate (النقل كما هو)»؟

نفّذ ترحيل الأجهزة الظاهرية بأسلوب النقل كما هو، بالاعتماد على النسخ المتماثل باستخدام Azure Migrate، واضبط التحويل الشبكي، وتحقق من سلامة التطبيق بعد الترحيل تتمرن على Azure Fundamentals مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Azure Fundamentals؟

لا تُشترط خبرة سابقة. Azure Fundamentals على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 3 من أصل 4.

كم من الوقت يستغرق درس «إعادة الاستضافة باستخدام Azure Migrate (النقل كما هو)»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Azure Fundamentals هذا؟

نعم. كل درس في Azure Fundamentals يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

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

← العودة إلى Azure Fundamentals