مشاركة عبر

ترحيل مثيل نظام مجموعة تجاوز الفشل ل SQL Server Always On إلى Azure VMware Solution

  • مقالة

في هذه المقالة، ستتعلم كيفية ترحيل مثيل نظام مجموعة تجاوز الفشل ل SQL Server إلى Azure VMware Solution. حاليا لا تدعم خدمة Azure VMware Solution الوضع المرتبط المختلط VMware لتوصيل خادم vCenter محلي مع خادم يعمل في Azure VMware Solution. بسبب هذا القيد، تتطلب هذه العملية استخدام VMware HCX للترحيل. لمزيد من المعلومات حول تكوين HCX، راجع تثبيت VMware HCX وتنشيطه في Azure VMware Solution.

لا يدعم VMware HCX ترحيل الأجهزة الظاهرية مع وحدات تحكم SCSI في وضع المشاركة الفعلية المرفقة بجهاز ظاهري. ومع ذلك، يمكنك التغلب على هذا القيد عن طريق تنفيذ الخطوات الموضحة في هذا الإجراء واستخدام VMware HCX Cold Migration لنقل الأجهزة الظاهرية المختلفة التي تشكل نظام المجموعة.

يوضح الرسم التخطيطي بنية تجاوز فشل SQL Server ل Azure VMware Solution.

إشعار

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

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

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

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

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

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

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

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

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

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

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

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

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

يتطلب نظام مجموعة تجاوز الفشل ل Windows Server آلية الحصة للحفاظ على نظام المجموعة.

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

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

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

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

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

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

ترحيل مجموعة تجاوز الفشل

لأغراض التوضيح، في هذا المستند نستخدم نظام مجموعة من عقدتين مع Windows Server 2019 Datacenter وSQL Server 2019 Enterprise. يتم أيضا دعم Windows Server 2022 وSQL Server 2022 مع هذا الإجراء.

  1. من إيقاف تشغيل عميل vSphere، العقدة الثانية من نظام المجموعة.

  2. الوصول إلى العقدة الأولى من نظام المجموعة وفتح Failover Cluster Manager.

    • تحقق من أن العقدة الثانية في حالة عدم الاتصال وأن جميع الخدمات والتخزين المجمعين تحت سيطرة العقدة الأولى. يوضح الرسم التخطيطي التحقق من تخزين نظام مجموعة Windows Server Failover Cluster Manager.

    • إيقاف تشغيل نظام المجموعة.

      يوضح الرسم التخطيطي نظام مجموعة إيقاف التشغيل باستخدام Windows Server Failover Cluster Manager.

    • تحقق من إيقاف جميع خدمات نظام المجموعة بنجاح دون أخطاء.

  3. إيقاف تشغيل العقدة الأولى من نظام المجموعة.

  4. من عميل vSphere، قم بتحرير إعدادات العقدة الثانية من نظام المجموعة.

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

  5. تحرير إعدادات الجهاز الظاهري للعقدة الأولى. تعيين SCSI Bus Sharing من Physical إلى None في وحدات تحكم SCSI.

  6. من vSphere Client، انتقل إلى منطقة المكون الإضافي HCX. ضمن الخدمات، حدد ترحيل>الترحيل.

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

  7. كرر نفس العملية للعقدة الأولى.

  8. الوصول إلى عميل Azure VMware Solution vSphere وتحرير إعدادات العقدة الأولى والعودة إلى ناقل SCSI الفعلي الذي يشارك وحدة تحكم SCSI أو وحدات التحكم التي تدير الأقراص المشتركة.

  9. تحرير إعدادات العقدة 2 في vSphere Client.

    • قم بتعيين مشاركة ناقل SCSI مرة أخرى إلى الفعلي في وحدة تحكم SCSI التي تدير التخزين المشترك.
    • أضف الأقراص المشتركة لنظام المجموعة إلى العقدة كمساحة تخزين إضافية. قم بتعيينها إلى وحدة تحكم SCSI الثانية.
    • تأكد من أن جميع تكوينات التخزين هي نفسها التي تم تسجيلها قبل الترحيل.

  10. تشغيل الجهاز الظاهري للعقدة الأولى.

  11. الوصول إلى العقدة الأولى VM مع وحدة تحكم VMware البعيدة.

    • تحقق من تكوين شبكة الجهاز الظاهري وتأكد من أنه يمكنه الوصول إلى الموارد المحلية وموارد Azure.

    • افتح Failover Cluster Manager وتحقق من خدمات نظام المجموعة.

      يظهر الرسم التخطيطي ملخص نظام المجموعة في Failover Cluster Manager.

  12. الطاقة على الجهاز الظاهري للعقدة الثانية.

  13. الوصول إلى الجهاز الظاهري للعقدة الثانية من وحدة تحكم VMware البعيدة.

    • تحقق من أن Windows Server يمكنه الوصول إلى التخزين.
    • في Failover Cluster Manager ، راجع أن العقدة الثانية تظهر على أنها حالة عبر الإنترنت . يوضح الرسم التخطيطي حالة عقدة نظام المجموعة في Failover Cluster Manager.

  14. باستخدام SQL Server Management Studio، اتصل باسم شبكة موارد نظام مجموعة SQL Server. تأكد من أن جميع قواعد البيانات متصلة بالإنترنت ويمكن الوصول إليها.

يوضح الرسم التخطيطي التحقق من اتصال SQL Server Management Studio بقاعدة بيانات مثيل نظام المجموعة التي تم ترحيلها.

تحقق من الاتصال ب SQL Server من الأنظمة والتطبيقات الأخرى في البنية الأساسية الخاصة بك. تحقق من أن جميع التطبيقات التي تستخدم قاعدة البيانات أو قواعد البيانات لا تزال قادرة على الوصول إليها.

مزيد من المعلومات