تنفيذ ترحيل قاعدة بيانات كبيرة جدًا إلى سحابة Azure لتقليل أحمال عمل SAP

مكتمل

تتضمن أنظمة SAP التي تم نقلها إلى سحابة Azure أنظمة مثيل عالمي واحد"single global instance" متعددة الجنسيات أكبر عدة مرات من الأنظمة المنشورة عندما تم اعتماد منصة Azure في البداية لتقليل أحمال عمل SAP.

من الشائع الآن، نقل قواعد البيانات الضخمة (VLDB) إلى سحابة Azure. تتطلب أحجام قاعدة البيانات التي تزيد عن 20 تيرابايت تقنيات وإجراءات إضافية لإتمام عملية الترحيل من الموقع إلى سحابة Azure في وقت تعطل مقبول وبمخاطر أقل.

رغم أن هذا الدرس لا يشمل عملية الترحيل إلى HANA (DMO) قيد التشغيل على Azure، فثمة العديد من نفس المفاهيم يُقبل تطبيقها على عمليات ترحيل HANA.

نظرة عامة رفيعة المستوى

ينبغي أن تستهلك عملية ترحيل VLDB المحسنة تمامًا حوالي 2 تيرابايت في الساعة بمعدل نقل البيانات المرحلة أو أكثر. ويمكن إتمام مكون نقل البيانات في عملية ترحيل تبلغ 20 تيرابايت في حوالي 10 ساعات. ويلي ذلك تنفيذ خطوات مرحلة ما بعد المعالجة وتطبيق خطوات التحقق من صحتها. بشكلٍ عام، ومن خلال توفير الوقت الكافي للتحضير والاختبار، يمكن نقل أي نظام خاص بالعملاء مهما كان حجمه إلى سحابة Azure.

تتطلب عمليات ترحيل VLDB Migrations مهارة كبيرة، واهتمامًا بالتفاصيل وإجراء التحاليل. على سبيل المثال، يجب قياس صافي أثر تقسيم الجدول وتحليله. إذ إن تقسيم أحد الجداول الكبيرة إلى أكثر من 50 صادرة متوازية قد يقلل الوقت المستغرق في تصدير جدول ما. ومع ذلك، قد ينتج عن انقسامات الجداول بكثرة زيادة مدة وقت الاستيراد. لذلك، يجب حساب صافي أثر تقسيم الجدول واختباره. وسيكون أحد الخبراء المرخصين بشهادة OS/DB في عمليات الترحيل على دراية بالمفاهيم والأدوات المتخصصة بذلك.

يتناول هذا القسم عملية ترحيل OS/DB غير المتجانسة إلى سحابة Azure المزوّدة بملقم SQL Server بصفته قاعدة بيانات الهدف باستخدام أدوات مثل R3load وأداة مراقبة الترحيل (MIGMON). الخطوات التي تُنفذ هنا غير مخصصة لنسخ النظام المتجانسة، وهي نسخة يبقى فيها نظام إدارة قواعد البيانات (DBMS) وتصميم المعالج (Endian Order) على نفس عمله. وبشكلٍ عام، يجب أن تتمتع نسخ النظام المتجانسة بوقت تعطل قليل بغض النظر عن حجم DBMS لأنه يمكن استخدام النسخ المتواصل للسجل في مزامنة نسخةٍ من قاعدة البيانات في Azure.

فيما يلي ملخص مخطط ترحيل VLDB OS/DB ونقلها إلى سحابة Azure، ويشمل النقاط الأساسية التالية:

  1. المصدر الحالي OS/DB غالبًا يكون AIX، وHPUX، وSolaris. أو Linux وDB2 أو Oracle

  2. نظام تشغيل الهدف يكون إما Windows أو 12.3 Suse أو Red Hat 7.x أو Oracle Linux 7.x

  3. قاعدة بيانات الهدف عادة ما تكون إما SQL Server أو Oracle 12.2

  4. ينخفض أداء مؤشر ترابط IBM pSeries وSolaris SPARC hardware وHP Superdome انخفاضًا حادًا عن ملقمات سلع Intel الحديثة منخفضة التكلفة، لذلك، يعمل R3load على ملقمات Intel منفصلة

  5. يتطلب نظام VMWare ضبطًا وتكوينًا خاصًا لتحقيق مستوى أداء شبكي جيد ومستقر يمكن التنبؤ به. في العادة، تستخدم الملقمات الفعلية كملقم R3load وليس VMs

  6. عادةً ما يُستخدم أربعة ملقمات تصدير R3load، رغم عدم وجود حد لعدد ملقمات التصدير. التكوين النموذجي يكون كما يلي:

    • ملقم تصدير #1 - مخصص لأكبر جداول من 1-4 (اعتمادًا على كيفية انحراف عملية توزيع البيانات على قاعدة البيانات المصدر)

    • ملقم تصدير #2 - مخصص للجداول المدعمة بتقسيمات الجدول

    • ملقم تصدير #3 - مخصص للجداول المدعمة بتقسيمات الجدول

    • ملقم تصدير #4 - جميع الجداول المتبقية

  7. تُنقل النسخة الاحتياطية لملفات التصدير من القرص الداخلي في ملقم R3load القائم على Intel إلى سحابة Azure باستخدام أداة AzCopy عبر الإنترنت العام (يكون عادةً أسرع من خلال أداة ExpressRoute على الرغم من عدم توفرها في جميع الحالات)

  8. يتحكم ملف الإشارة (Signal File, SGN) في عملية الاستيراد وتسلسلها، وهو ملف يتم إنشاؤه تلقائيًا عند اكتمال جميع حزم التصدير ويسمح بتصدير/استيراد شبه متوازي

  9. يتشابه تصميم عملية استيراد البيانات إلى SQL Server أو Oracle مع عملية للتصدير في الاستفادة من أربعة ملقمات استيراد. وهذه الملقمات يجب أن تكون ملقمات R3load مخصصة ومنفصلة مدعمة بشبكات مسرّعة. ومن المستحسن عدم استخدام ملقمات تطبيق SAP لهذه المهمة

  10. عادة ما تستخدم قواعد بيانات VLDB ملقمات E64v3 أو m64 أو m128 VMs مع خدمة التخزين المتميز. ويمكن وضع تسجيل العملية على قرص SSD الداخلي لتسريع عمليات كتابة سجل العملية وإزالة عمليات IOPS الخاصة بسجل العمليات والنطاق الترددي لـ IO من الحصة النسبية لـ VM. بعد عملية الترحيل، يجب وضع سجل العمليات على القرص الثابت.

فيما يلي مخطط لتدفق مركز بيانات داخلي إلى مركز بيانات Azure.

تدفق مركز بيانات داخلي إلى مركز بيانات Azure.