نقل Azure VMs إلى منطقة أخرى خاصة بـ Azure
تقدم هذه المقالة نظرة عامة على الأسباب والخطوات المتضمنة في نقل Azure VMs إلى منطقة أخرى خاصة بـ Azure باستخدام Azure Site Recovery .
الأسباب المؤدية إلى نقل Azure VMs
يمكن نقل VMs للأسباب التالية:
- نُشر بالفعل في منطقة واحدة، وأُضيف دعم لمنطقة جديدة أقرب إلى المستخدمين النهائيين لتطبيقك أو خدمتك. في هذا السيناريو، قد تكون هنا رغبة في نقل VMs الخاص بك كما هو الحال في المنطقة الجديدة لتقليل زمن الوصول. استخدام نفس الأسلوب عند الرغبة في دمج الاشتراكات أو إذا كانت هناك قواعد تحكّم أو تنظيم تتطلب الانتقال.
- عند نشر VM باعتباره VM ذا مثيل مفرد أو بصفته جزءاً من مجموعة إتاحة. عند الرغبة في زيادة توفّر اتفاقيات مستوى الخدمة، يمكن نقل أجهزة VM إلى منطقة توفّر الخدمات.
نقل VMs مع Resource Mover
يمكن الآن نقل VMs إلى منطقة أخرى باستخدام Azure Resource Mover . يوجد Resource Mover في المعاينة العامة ويتيح:
- مركز واحد لنقل الموارد عبر المناطق.
- تقليل وقت الحركة وتعقيدها. كل ما نحتاج إليه موجود في مكان واحد.
- تجربة بسيطة ومتسقة لنقل أنواع مختلفة من موارد Azure.
- طريقة بسيطة لتحديد التبعيات عبر الموارد المراد نقلها. يساعد هذا على نقل الموارد ذات الصلة مع بعضها، بحيث يعمل كل شيء كما هو متوقع في المنطقة المستهدفة بعد النقل.
- التنظيف التلقائي للموارد في منطقة المصدر، إذا كنت ترغب في حذفها بعد النقل.
- الاختبار. يمكن تجربة حركة ثم تجاهلها عند عدم الرغبة في القيام بحركة كاملة.
نقل VMs باستخدام Site Recovery
يتضمن نقل VMs باستخدام Site Recovery الخطوات التالية:
- تحقق من المتطلبات الأساسية.
- تحضير VMs المصدر.
- تجهيز المنطقة المستهدفة.
- نسخ البيانات إلى المنطقة المستهدفة. استخدام تقنية النسخ المتماثل لـ Azure Site Recovery لنسخ البيانات من VM المصدر إلى المنطقة المستهدفة.
- اختبار التكوين. بعد اكتمال النسخ المتماثل، اختبار التكوين بإجراء اختبار تجاوز فشل على شبكة غير إنتاجية.
- تنفيذ النقل.
- تجاهل الموارد في منطقة المصدر.
إشعار
توفير تفاصيل حول هذه الخطوات في الأقسام التالية.
هام
يدعم Azure Site Recovery حالياً نقل VMs من منطقة إلى أخرى ولكنه لا يدعم الانتقال داخل إطار منطقة ما.
بنيات نموذجية لنشر متعدد الطبقات
يصف هذا القسم بنيات النشر الأكثر شيوعاً لتطبيق متعدد الطبقات في Azure. المثال عبارة عن تطبيق ثلاثي الطبقات بعنوان IP عام. تحتوي كل طبقة من الطبقات (الويب والتطبيق وقاعدة البيانات) على VMs لكل منهما، وهما متصلان بواسطة موزع أحمال Azure بالطبقات الأخرى. تحتوي طبقة قاعدة البيانات على نسخ متماثلة لـ SQL Server Always On بين VMs من أجل التوفّر العالي.
VMs أحادية المثيل التي نُشرت عبر طبقات مختلفة : يُعد كل VM في طبقة ما VM أحادي المثيل ومتصلاً من خلال موزع الأحمال بالطبقات الأخرى. هذا التكوين هو الأبسط للتنفيذ.
VMs in each tier deployed across availability sets: يكون كل VM في الطبقة في مجموعة إتاحة. Availability sets التأكد من أن VMs التي تُنشر على Azure موزعة عبر عدة عقد أجهزة معزولة في مجموعة. يضمن هذا أنه في حالة حدوث عطل في الأجهزة أو البرامج داخل Azure، ستتأثر مجموعة فرعية فقط من VMs، وسيظل الحل العام متاحاً وعاملاً.
VMs in each tier deployed across Availability Zones: يكون كل VM في الطبقة مكوناً عبر Availability Zones. تعد منطقة التوفّر في منطقة Azure مزيجًا من مجال خاطئ ومجال تحديث. على سبيل المثال، إذا أنشأت ثلاثة أجهزة ظاهرية أو أكثر عبر ثلاث مناطق في منطقة Azure، سيتم توزيع الأجهزة الظاهرية الخاصة بك بشكل فعال عبر ثلاثة مجالات خطأ وثلاثة مجالات تحديث. يتعرف النظام الأساسي Azure على هذا التوزيع عبر مجالات التحديث للتأكد من عدم تحديث الأجهزة الظاهرية في مناطق مختلفة في نفس الوقت.
انقل VMs كما هي إلى منطقة مستهدفة
استناداً إلى architectures المذكورة سابقاً، هذا ما ستبدو عليه عمليات النشر بعد إجراء النقل كما هو الحال في المنطقة المستهدفة.
- Single-instance VMs deployed across various tiers
- VMs in each tier deployed across availability sets
- VMs in each tier deployed across Availability Zones
نقل VMs لزيادة التوفر
Single-instance VMs deployed across various tiers
VMs in each tier deployed across availability sets: يمكن تكوين VMs في مجموعة توفر معينة في مناطق توفّر منفصلة عند القيام بتمكين النسخ المتماثل لجهاز VM الخاص بك باستخدام Azure Site Recovery. تكتمل اتفاقية مستوى الخدمة الخاصة بالتوفّر بنسبة 99.99٪ بعد إتمام عملية النقل.
