مشاركة عبر

ترحيل SQL Server Always On Availability Group إلى Azure VMware Solution

  • مقالة

في هذه المقالة، ستتعلم كيفية ترحيل مجموعة قابلية وصول عالية التوفر Always On SQL Server إلى Azure VMware Solution. بالنسبة إلى VMware HCX، يمكنك اتباع إجراء ترحيل VMware vMotion.

رسم تخطيطي يوضح بنية Always On SQL Server ل Azure VMware Solution.

تم اختبار Microsoft SQL Server (2019 و2022) مع إصدار مركز البيانات Windows Server (2019 و2022) مع الأجهزة الظاهرية المنشورة في البيئة المحلية. يتم تكوين Windows Server وSQL Server باتباع أفضل الممارسات والتوصيات من Microsoft وVMware. كانت البنية الأساسية للمصدر المحلي VMware vSphere 7.0 Update 3 وVMware vSAN تعمل على خوادم Dell PowerEdge وأجهزة Intel Optane P4800X SSD NVMe.

المتطلبات الأساسية

فيما يلي المتطلبات الأساسية لترحيل مثيل SQL Server إلى Azure VMware Solution.

  • مراجعة وتسجيل تكوين التخزين والشبكة لكل عقدة في نظام المجموعة.
  • الاحتفاظ بالنسخ الاحتياطية لجميع قواعد بيانات SQL Server.
  • النسخ الاحتياطي للجهاز الظاهري أو الأجهزة الظاهرية التي تستضيف SQL Server.
  • إزالة الجهاز الظاهري من أي مجموعات وقواعد VMware vSphere Distributed Resource Scheduler (DRS).
  • يجب تكوين VMware HCX بين مركز البيانات المحلي والسحابة الخاصة ل Azure VMware Solution التي تشغل أحمال العمل التي تم ترحيلها. لمزيد من المعلومات حول كيفية تكوين HCX، راجع وثائق Azure VMware Solution.
  • تأكد من توسيع جميع مقاطع الشبكة المستخدمة من قبل SQL Server وأحمال العمل التي تستخدمها إلى سحابة Azure VMware Solution الخاصة بك. للتحقق من هذه الخطوة، راجع تكوين ملحق شبكة VMware HCX.

يمكن استخدام إما VMware HCX عبر VPN أو اتصال ExpressRoute كتكوين شبكة للترحيل.

مع VMware HCX عبر VPN، بسبب النطاق الترددي المحدود، عادة ما يكون مناسبا لأحمال العمل التي يمكن أن تحافظ على فترات أطول من وقت التعطل (مثل البيئات غير المنتجة).

بالنسبة لأي من المثيلات التالية، يوصى باتصال ExpressRoute للترحيل:

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

وتناقش اعتبارات أخرى في وقت التعطل في القسم التالي.

اعتبارات وقت التعطل

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

يشير الجدول التالي إلى وقت التعطل المقدر لترحيل كل مخطط SQL Server.

السيناريو وقت التعطل المتوقع ملاحظات
مثيل SQL Server المستقل منخفض يتم الترحيل باستخدام VMware vMotion، تتوفر قاعدة البيانات أثناء وقت الترحيل، ولكن لا يوصى بتثبيت أي بيانات مهمة أثناء ذلك.
مجموعة قابلية وصول عالية التوفر Always On ل SQL Server منخفض ستكون النسخة المتماثلة الأساسية متاحة دائما أثناء ترحيل النسخة المتماثلة الثانوية الأولى وستصبح النسخة المتماثلة الثانوية هي النسخة الأساسية بعد تجاوز الفشل الأولي إلى Azure.
SQL Server دائما على مثيل نظام مجموعة تجاوز الفشل درجة عالية يتم إيقاف تشغيل جميع عقد نظام المجموعة وترحيلها باستخدام VMware HCX Cold Migration. تعتمد مدة التوقف عن العمل على حجم قاعدة البيانات وسرعة الشبكة الخاصة إلى سحابة Azure.

اعتبارات حصة نظام مجموعة تجاوز الفشل ل Windows Server

تعتمد مجموعات قابلية الوصول عالية التوفر ل Microsoft SQL Server Always On على نظام مجموعة تجاوز الفشل ل Windows Server، والذي يتطلب آلية التصويت على الحصة للحفاظ على اتساق نظام المجموعة.

مطلوب عدد فردي من عناصر التصويت، والذي يتحقق من خلال عدد فردي من العقد في نظام المجموعة أو باستخدام مراقب. يمكن تكوين المراقب بثلاث طرق مختلفة:

  • مراقب القرص
  • مراقب مشاركة الملف
  • مراقب سحابي

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

إذا كان نظام المجموعة يستخدم مراقب مشاركة ملف يعمل محليا، فإن نوع المراقب لنظام المجموعة الذي تم ترحيله يعتمد على سيناريو Azure VMware Solution، فهناك العديد من الخيارات التي يجب مراعاتها.

  • ملحق مركز البيانات: الاحتفاظ بمشاهد مشاركة الملف محليا. يتم توزيع أحمال العمل الخاصة بك عبر مركز البيانات وAzure. لذلك يجب أن يكون الاتصال بين مركز البيانات الخاص بك وAzure متاحا دائما. على أي حال، خذ بعين الاعتبار قيود النطاق الترددي والتخطيط وفقا لذلك.
  • إنهاء مركز البيانات: لهذا السيناريو، هناك خياران. في كلا الخيارين، يمكنك الاحتفاظ بمشاهد مشاركة الملف محليا أثناء الترحيل في حالة الحاجة إلى التراجع أثناء العملية.
    • نشر شاهد مشاركة ملف جديد في سحابة Azure VMware Solution الخاصة بك.
    • نشر مراقب سحابة يعمل في Azure Blob Storage في نفس المنطقة مثل السحابة الخاصة Azure VMware Solution.
  • التعافي من الكوارث واستمرارية الأعمال: بالنسبة لسيناريو التعافي من الكوارث، فإن الخيار الأفضل والأكثر موثوقية هو إنشاء مراقب سحابي يعمل في Azure Storage.
  • تحديث التطبيق: بالنسبة لحالة الاستخدام هذه، فإن الخيار الأفضل هو نشر Cloud Witness.

للحصول على تفاصيل حول تكوين الحصة وإدارتها، راجع وثائق تجاوز الفشل للمجموعات. للحصول على معلومات حول نشر مراقب السحابة في Azure Blob Storage، راجع إدارة حصة نظام المجموعة لمجموعة تجاوز الفشل.

ترحيل SQL Server Always On Availability Group

  1. قم بالوصول إلى مجموعة قابلية وصول عالية التوفر AlwaysOn باستخدام SQL Server Management Studio باستخدام بيانات اعتماد الإدارة.

    • حدد النسخة المتماثلة الأساسية وافتح Availability GroupProperties. رسم تخطيطي يوضح خصائص مجموعة قابلية وصول عالية التوفر AlwaysOn.
    • قم بتغيير وضع التوفر إلى تثبيت غير متزامن فقط للنسخة المتماثلة المراد ترحيلها.
    • تغيير وضع تجاوز الفشل إلى يدوي لكل عضو في مجموعة التوفر.

  2. الوصول إلى خادم vCenter المحلي والمتابعة إلى منطقة HCX.

  3. ضمن الخدمات، حدد ترحيل>الترحيل.

    • حدد جهازا ظاهريا واحدا يقوم بتشغيل النسخة المتماثلة الثانوية لقاعدة البيانات التي سيتم ترحيلها.
    • قم بتعيين نظام مجموعة vSphere في السحابة الخاصة البعيدة، والتي تستضيف الآن الجهاز الظاهري ل SQL Server أو الأجهزة الظاهرية التي تم ترحيلها كحاوية حساب.
    • حدد مخزن بيانات vSAN كمخزن بعيد.
    • حدد مجلدا. ليس إلزاميا، ولكن يوصى بفصل أحمال العمل المختلفة في سحابة Azure VMware Solution الخاصة بك.
    • احتفظ بنفس التنسيق مثل المصدر.
    • حدد vMotion كملف تعريف الترحيل.
    • في خيارات موسعة، حدد ترحيل السمات المخصصة.
    • تحقق من أن مقاطع الشبكة المحلية تحتوي على المقطع البعيد الصحيح الممتد في Azure.
    • حدد Validate وتأكد من اكتمال جميع الفحوصات بحالة المرور. يرتبط الخطأ الأكثر شيوعا بتكوين التخزين. تحقق مرة أخرى من عدم وجود وحدات تحكم SCSI ظاهرية لديها إعداد المشاركة الفعلية.
    • حدد Go لبدء الترحيل.

  4. بمجرد اكتمال الترحيل، قم بالوصول إلى النسخة المتماثلة التي تم ترحيلها وتحقق من الاتصال مع بقية الأعضاء في مجموعة التوفر.

  5. في SQL Server Management Studio، افتح Availability Group Dashboard وتحقق من ظهور النسخة المتماثلة على أنها Online. رسم تخطيطي يوضح لوحة معلومات مجموعة قابلية وصول عالية التوفر AlwaysOn.

    • من المتوقع حالة فقدان البيانات في عمود "جاهزية تجاوز الفشل" نظرا لأن النسخة المتماثلة غير متزامنة مع الأساسي أثناء الترحيل.

  6. قم بتحرير خصائص مجموعةالتوفر مرة أخرى وتعيين وضع التوفر مرة أخرى إلى الالتزام المتزامن.

    • تبدأ النسخة المتماثلة الثانوية في مزامنة جميع التغييرات التي تم إجراؤها على النسخة المتماثلة الأساسية أثناء الترحيل. انتظر حتى يظهر في حالة المزامنة.

  7. من لوحة معلومات مجموعة التوفر، في SSMS، حدد بدء معالج تجاوز الفشل.

  8. حدد النسخة المتماثلة التي تم ترحيلها وحدد التالي.

    رسم تخطيطي يوضح تحديد النسخة المتماثلة الأساسية الجديدة ل Always On.

  9. الاتصال إلى النسخة المتماثلة في الشاشة التالية باستخدام بيانات اعتماد مسؤول DB. رسم تخطيطي يوضح اتصال بيانات اعتماد مسؤول النسخة المتماثلة الأساسية الجديدة.

  10. راجع التغييرات وحدد إنهاء لبدء عملية تجاوز الفشل.

    رسم تخطيطي يوضح مراجعة عملية مجموعة قابلية وصول عالية التوفر AlwaysOn.

  11. راقب تقدم تجاوز الفشل في الشاشة التالية، وحدد إغلاق عند انتهاء العملية. رسم تخطيطي يوضح انتهاء مجموعة SQL Server Always On بنجاح.

  12. قم بتحديث طريقة عرض مستكشف العناصر في SQL Server Management Studio (SSMS)، وتحقق من أن المثيل الذي تم ترحيله هو الآن النسخة المتماثلة الأساسية.

  13. كرر الخطوات من 1 إلى 6 لبقية النسخ المتماثلة لمجموعة التوفر.

    إشعار

    ترحيل نسخة متماثلة واحدة في كل مرة والتحقق من مزامنة جميع التغييرات مرة أخرى إلى النسخة المتماثلة بعد كل عملية ترحيل. لا تقم بترحيل كافة النسخ المتماثلة في نفس الوقت باستخدام HCX Bulk Migration.

  14. بعد اكتمال ترحيل جميع النسخ المتماثلة، قم بالوصول إلى مجموعة قابلية وصول عالية التوفر AlwaysOn باستخدام SQL Server Management Studio.

    • افتح لوحة المعلومات وتحقق من عدم وجود فقدان للبيانات في أي من النسخ المتماثلة وأن جميعها في حالة متزامنة . رسم تخطيطي يوضح توفر لوحة معلومات المجموعة مع نسخة متماثلة أساسية جديدة وجميع النسخ المتماثلة الثانوية التي تم ترحيلها في حالة متزامنة.

    • قم بتحرير خصائص مجموعة التوفر وتعيين وضع تجاوز الفشل إلى تلقائي في جميع النسخ المتماثلة.

      رسم تخطيطي يوضح إعدادا لتجاوز الفشل مرة أخرى إلى تلقائي لجميع النسخ المتماثلة.

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