تكوين خيارات الترحيل السحابي لأحمال عمل SAP

مكتمل

توضح هذه الوحدة المتطلبات الأساسية ومزايا الترحيل إلى Microsoft Azure في خطوة واحدة عبر خيار ترحيل البيانات (DMO) المدعم بنظام نقل مقارنة بالخيار ذي الخطوتين الرفع والنقل "lift and shift" ثم خيار ترحيل البيانات (DMO).

فيما يلي خطوات عمل خيار ترحيل البيانات (DMO) مع خيار نقل النظام إلى Microsoft Azure:

  • ضمان توفر الاتصال بـ Azure عبر Express Route (يوصى الاتصال به فله سرعة اتصال عالية) أو الشبكة الظاهرية الخاصة (VPN) في Azure

  • توفير البنية الأساسية الهدف في Azure والتي تتضمن ملقمات قاعدة بيانات SAP NetWeaver وSAP HANA. إذ يمكن نشر البنية الأساسية لـ Azure بسرعة باستخدام قوالب إدارة موارد Azure (ARM) المعرفة مسبقًا.

  • يتم بدء تشغيل أداة SUM على ملقم تطبيق المصدر الداخلي لـ SAP.

  • تُنفذ أنشطة وقت التشغيل من ملقم تطبيق SAP الداخلي ويُنشأ مستودع الظل.

  • كجزء من مرحلة التعطل، يتم إنشاء ملفات التصدير على النظام المصدر ثم تُنقل هذه الملفات إلى Azure عبر Express Route أو VPN.

  • يمكن أن تحدث عمليات نقل الملفات في وضع نقل البيانات التسلسلي “Sequential Data Transfer” أو نقل البيانات المتوازي “Parallel Data Transfer”

وضع نقل البيانات التسلسلي "Sequential Data Transfer":

  • في وضع "Sequential Data Transfer"، تُصدّر جميع الجداول إلى نظام الملفات الخاص بالملقم الداخلي

  • بمجرد الانتهاء من التصدير، يُنقل دليل SUM الكامل إلى ملقم التطبيق الهدف في Azure

  • تُعاد مزامنة دليل SUM في أثناء مرحلة "HOSTCHANGE" من خيار ترحيل البيانات (DMO)

  • تبدأ أداة SUM في التشغيل على ملقم تطبيق الهدف في Azure ومن ثم تبدأ عملية الاستيراد

  • يتم اكتمال مرحلة ما بعد المعالجة

وضع نقل البيانات المتوازي "Parallel Data Transfer":

  • في وضع "Parallel Data Transfer"، تُنقل البيانات على الفور إلى الهدف في Azure بعد إتمام عملية التصدير لكل ملف عبر البرمجة النصية dmotocloud.sh

  • يمكن استخدام هذا الوضع لتقليل الوقت المستغرق في تعطيل عملية الترحيل.

يجب مراعاة ما يلي في عملية الترحيل ذات الخطوتين:

  • تأكد من توفر إمكانية الاتصال بـ Azure عبر Express Route (المستحسن) أو VPN.

  • توفير البنية الأساسية للهدف على Azure والتي تشمل النظام المستنسخ وملقمات قاعدة بيانات SAP NetWeaver وSAP HANA للهدف. إذ يمكن نشر البنية الأساسية لـ Azure باستخدام قوالب إدارة موارد Azure (ARM) المعرفة مسبقًا.

  • يمكن بناء النظام المستنسخ باستخدام نسخة نظام متجانسة (النسخ الاحتياطي/الاستعادة) أو عن طريق أدوات النسخ المتماثل DBMS (على سبيل المثال، Oracle Data Guard، أو SQL Always-On).

  • يجب بدء التحقق من صحة الأعمال والتقنيات (باستخدام اختبار وظيفي واختبار الدمج واختبار القبول لضمان نجاح نقل البيانات).

  • بعد التحقق من صحة الأعمال والتقنيات، يمكن اتباع عملية خيار ترحيل البيانات (DMO) التقليدية لترحيل قاعدة بيانات SAP HANA وترقيتها.

  • يمكن الاستفادة من خيار ترحيل البيانات (DMO) باستخدام طريقة أنابيب الذاكرة (أي أن عملية التصدير/الاستيراد تحدث داخل نفس ملقم التطبيق وشريحة الذاكرة في عمليات الترحيل المتسارعة).

  • بعد ترحيل البيانات إلى SAP HANA، يجب البدء مرة أخرى في التحقق من الأعمال والتقنيات.

  • في هذا النهج، يشترط توفير دورتين لوقت التعطل ودورتين اختباريتين.

خيارات تحسين خيار ترحيل البيانات (DMO)

تؤثر عوامل عديدة على وقت التعطل المقترن بترحيل قاعدة بيانات SAP وتشمل (من بين أمور أخرى) ما يلي:

النطاق التغييرات البرمجية، وتحويل Unicode، وتغيير موقع مركز البيانات
أداء النظام المصدر وحدة المعالجة المركزية، وI/O، والذاكرة، وأداء DBMS، وإصدار SAP NetWeaver
حجم قاعدة بيانات النظام المصدر حجم قاعدة البيانات، وأكبر الجداول، وحالة تحسين الأداء
أداء نظام الهدف وحدة المعالجة المركزية، وI/O، والذاكرة، وأداء DBMS، وإصدار SAP NetWeaver
الشبكة سرعة الشبكة، والنطاق الترددي، وزمن الانتقال
مجموعة الأدوات أداة SWPM، وأداة SUM، وخيار ترحيل البيانات (DMO) من SUM، وإصدار مجموعة الأدوات
نهج الترحيل وقت التعطل القياسي مقابل الحد الأدنى لوقت التعطل
زيادة الأنشطة / انخفاض الأنشطة إدارة واجهة الأنشطة، إدارة الوظيفة الدفعية
التحقق من صحة مرحلة ما قبل الترحيل ومرحلة ما بعده اختبارات الوظائف والتكامل والقبول.

بشكلٍ عام، يمكن ملاحظة إمكانية تحسين الأداء في المجالات الثلاثة التالية:

  • تصدير

  • نقل الملفات

  • استيراد

البنية الأساسية/الأجهزة

تتكون عملية التحكم في انخفاض مستوى البنية الأساسية/الأجهزة مما يلي:

  • داخلي
  • نشر ملقم ترحيل مخصص (PAS / AAS) مزوّد بقدرة حوسبة واسعة النطاق لتنفيذ عمل أداة SUM

  • نشر محرك الأقراص ذي الحالة الصلبة (SSD) على قاعدة بيانات المصدر وملقمات الترحيل.

  • (PAS/AAS)

  • Microsoft Azure
  • يُوصى بـ ⁧⁩Express Route connectivity ⁧⁩ بدرجة عالية مع الحد الأقصى للنطاق الترددي المتاح (متوفر حاليًا حتى 10 جيجابت في الثانية)

  • الاستفادة من البرمجة النصية dmotocloud.sh (RSYNC) لنقل الملفات من أحد المصادر الداخلية إلى هدف Azure لخيار نقل النظام الخاص بخيارات ترحيل البيانات (DMO) باستخدام وضع النقل المتوازي "Parallel Transfer".

  • ⁩أخذ نسخة مطابقة لموقع التخزين⁧⁩ للنسخ الاحتياطي ذي الوقت الفعال خلال فترة الانقطاع.

الاعتبارات الرئيسية لتحسين وقت التعطل الخاص بخيار ترحيل البيانات (DMO)

  • تحسين قاعدة البيانات المصدر (إعادة بناء الفهرس، إحصائيات قاعدة البيانات، معلمات قاعدة البيانات، ونظام ملفات قاعدة البيانات). ويرد في الجدول التالي مراجع مفيدة.
‏‏قاعدة البيانات ‏‏المرجع
Oracle SAP Note 936441 - Oracle settings for R3load based system copy
DB2 http://www.redbooks.ibm.com/abstracts/sg247774.html
SQL Server https://docs.microsoft.com/archive/blogs/saponsqlserver/sap-osdb-migration-to-sql-server-faq-v6-2-april-2017
  • استخدم أحدث إصدار من أداة الترحيل (على سبيل المثال، R3* وkernel).

  • استخدام محددات الشبكة (على سبيل المثال، إعدادات MTU، وإعادة ضبط العدادات).

  • المحددات ذات الصلة بـ OS (على سبيل المثال، عمق Q).

  • معلمات قاعدة بيانات SAP HANA (المتعلقة بحفظ النقاط، ووضع التسجيل، والمهلات).

  • معلمات خيار ترحيل البيانات (DMO) (على سبيل المثال، ملفات المدة، وتقسيمات الجدول اليدوية، وترتيب تسلسل الجدول اليدوي، والتحميل السريع لمخزن BLOB).

وضع معايير لخيار ترحيل البيانات (DMO):

  • تُستخدم المعايير لتسجيل مراحل التصدير والاستيراد لإحدى المجموعات الفرعية من البيانات. ويمكن تكوينها ليتم تشغيله على جداول معينة.

تكرار عمليات تشغيل متعددة من مرحلة التعطل:

  • يمكن تشغيل مرحلة التنفيذ عدة مرات عن طريق إعادة عمل نشاط تقسيم الجدول (ومن ثمَّ تحسين تقسيم الجدول الذي سيقلل من وقت التعطل الخاص بخيار ترحيل البيانات (DMO)).

خيار ترحيل البيانات (DMO) المحسن حسب وقت التعطل

خيار ترحيل البيانات (DMO) حسب وقت التعطل يمثل أحد خيارات الترحيل الذي تُرحل فيه الجداول الكبيرة كجزء من مرحلة وقت التشغيل. وستسجل المشغلات التغييرات التي يمكن إعادتها مرة أخرى كجزء من عملية التعطل.

يرد في الجدول الوارد أدناه مقارنة بين خيار ترحيل البيانات (DMO) التقليدي وخيار ترحيل البيانات (DMO) المحسن حسب وقت التعطل.

خيار DMO التقليدي خيار DMO المحسن حسب وقت التعطل
يمكن لأي مورد تنفيذ خيار ترحيل البيانات (DMO) يتعين على أحد موظفي SAP تنفيذ المشروع، فهو مشروع قائم على خدمات SAP فقط
يتم نسخ جميع الجداول نسخًا متماثلاً كجزء من وقت التعطل يتم نسخ الجداول الكبيرة نسخًا متماثلاً كجزء من وقت التشغيل باستخدام SLT
مدة تعطل أطول مدة تعطل قليلة
جميع السيناريوهات مدعمة

يمكن دمج سيناريو "DMO without Software Update" مع سيناريو "downtime-optimized DMO"

لا يدعم سيناريو "DMO with System Move" السيناريو "downtime-optimized DMO"

لا يشترط إضافة DMIS في جيل stack.xml يُضاف DMIS في محسن الصيانة (MOPZ) يدويًا لإنشاء ملف تكوين المكدس (stack.xml)
لا توجد قيود

المنتجات المدعمة:

  • SAP ECC 6.0 وإصدارات SAP الأعلى
  • CRM 7.0 والإصدارات الأعلى
لا توجد قيود

القيود المفروضة على الجداول التي لا يمكن نسخها نسخًا متماثلاً في وقت التشغيل:

  • جداول الأساس التي تحتوي على مكونات عميقة (على سبيل المثال، STRG)
  • جداول الوعاء
  • جداول تبادل التطبيقات (تُنقل وقت التشغيل بأية طريقة)
  • الجداول المراد تحويلها
  • الجداول المتروكة بدون مفتاح أساسي
  • الجداول التي تبدأ بـ /BI في اسمها
  • الجداول الواردة من نظام إدارة النقل (Transport Management System, TMS) بدءًا من E07*

تقنية Near-Zero Downtime (NZDT)

تتبع تقنية NZDT منهجية تقوم على الاستنساخ وتتابع عملية استنساخ نظام الإنتاج، بينما ينفذ خيار ترحيل البيانات (DMO) هذا الاستنساخ. تُسجل أنشطة المعاملات بدءًا من نظام الإنتاج وحتى إعادتها إلى نظام الاستنساخ. لمعرفة مزيد من التفاصيل، راجع ملاحظة SAP رقم #693168 - خدمة وقت التعطل المخفض (MDS).