نشر نظام إدارة قواعد البيانات للأجهزة الظاهرية لـ IBM Db2 Azure لـ SAP workload

باستخدام Microsoft Azure، يمكنك ترحيل تطبيق SAP الحالي الذي يعمل على IBM Db2 لنظام التشغيل Linux وUNIX وWindows (LUW) إلى أجهزة Azure الظاهرية. باستخدام SAP على IBM Db2 لـ LUW، لا يزال بإمكان المسؤولين والمطورين استخدام نفس أدوات التطوير والإدارة، المتوفرة محليا. تتوفر معلومات عامة حول تشغيل SAP Business Suite على IBM Db2 لـ LUW عبر شبكة SAP Community Network (SCN) في SAP on IBM Db2 for Linux, UNIX, and Windows.

لمزيد من المعلومات والتحديثات حول SAP على Db2 لـ LUW على Azure، راجع ملاحظة SAP رقم 2233094.

هناك مقالات مختلفة لحمل عمل SAP على Azure. نوصي بالبدء مع Get started with SAP on Azure VMs ثم القراءة عن المجالات الأخرى ذات الاهتمام.

ترتبط ملاحظات SAP التالية بـ SAP على Azure فيما يتعلق بالمجال الذي يغطيه هذا المستند:

رقم الملاحظة ‏‫المسمى الوظيفي
1928533 تطبيقات SAP على Azure: المنتجات المدعومة وأنواع أجهزة Azure الظاهرية
2015553 SAP على Microsoft Azure: دعم المتطلبات الأساسية
1999351 استكشاف أخطاء مراقبة Azure المحسنة لـ SAP وإصلاحها
2178632 مقاييس المراقبة الرئيسية لـ SAP على Microsoft Azure
1409604 المحاكاة الافتراضية على Windows: المراقبة المحسنة
2191498 SAP على Linux مع Azure: مراقبة محسنة
2233094 DB6: تطبيقات SAP على Azure باستخدام IBM DB2 لنظام التشغيل Linux وUNIX وWindows - معلومات إضافية
2243692 Linux على Microsoft Azure (IaaS) VM: مشكلات ترخيص SAP
1984787 خادم المؤسسة 12 لـSUSE LINUX: ملاحظات التثبيت
2002167 Red Hat Enterprise Linux 7.x: التثبيت والترقية
1597355 توصية مساحة المبادلة لنظام التشغيل Linux

كقراءة مسبقة لهذا المستند، راجع اعتبارات نشر Azure Virtual Machines DBMS لحمل عمل SAP. راجع الأدلة الأخرى في حمل عمل SAP على Azure.

دعم إصدارات IBM Db2 لـ Linux وUNIX وWindows

يتم دعم SAP على IBM Db2 لـ LUW على خدمات جهاز Microsoft Azure الظاهري اعتبارًا من الإصدار 10.5 من Db2.

للحصول على معلومات حول منتجات SAP المدعومة وأنواع Azure VM (الأجهزة الظاهرية)، راجع 1928533 ملاحظة SAP.

إرشادات تطوين IBM Db2 لنظام التشغيل Linux وUNIX وWindows لعمليات تثبيت SAP في أجهزة Azure الظاهرية

تكوين التخزين

للحصول على نظرة عامة على أنواع تخزين Azure لحمل عمل SAP، راجع المقالة أنواع تخزين Azure لحمل عمل SAP يجب تخزين جميع ملفات قاعدة البيانات على الأقراص المحملة من تخزين كتلة Azure (Windows: NTFS أو Linux: xfs أو مدعوم اعتبارا من Db2 11.1 أو ext3).

وحدات التخزين المشتركة عن بعد مثل خدمات Azure في السيناريوهات المسردة غير مدعومة لملفات قاعدة بيانات Db2:

  • خدمة ملفات Microsoft Azure لجميع أنظمة التشغيل الضيف.

  • Azure NetApp Files لـ Db2 قيد التشغيل في نظام التشغيل المضيف Windows.

يتم دعم وحدات التخزين المشتركة عن بعد مثل خدمات Azure في السيناريوهات المدرجة لملفات قاعدة بيانات Db2:

  • يتم دعم استضافة بيانات وملفات سجل Db2 المستندة إلى نظام التشغيل Linux المضيف على مشاركات NFS المستضافة على ملفات Azure NetApp!

إذا كنت تستخدم أقراصا تستند إلى تخزين Azure Page BLOB أو الأقراص المدارة، فإن العبارات التي تم إجراؤها في اعتبارات نشر Azure Virtual Machines DBMS لحمل عمل SAP تنطبق على عمليات النشر باستخدام Db2 DBMS (نظام إدارة قاعدة البيانات) أيضا.

كما هو موضح سابقا في الجزء العام من المستند، توجد حصص نسبية على معدل نقل IOPS (عمليات الإدخال/الإخراج في الثانية) لأقراص Azure. تعتمد الحصص الدقيقة على نوع الجهاز الظاهري المستخدم. يمكن العثور على قائمة بأنواع الأجهزة الظاهرية مع حصصها النسبية هنا (Linux) وهنا (Windows).

طالما أن الحصة النسبية الحالية IOPS لكل قرص كافية، فمن الممكن تخزين جميع ملفات قاعدة البيانات على قرص واحد مثبت. في حين يجب عليك دائما فصل ملفات البيانات وملفات سجل المعاملات على أقراص/ VHDs مختلفة.

للاطلاع على اعتبارات الأداء، راجع أيضا الفصل "سلامة البيانات واعتبارات الأداء لأدلة قواعد البيانات" في أدلة تثبيت SAP.

بدلا من ذلك، يمكنك استخدام تجمعات تخزين Windows، والتي تتوفر فقط في Windows Server 2012 والإصدارات الأحدث كما هو موضح اعتبارات نشر Azure Virtual Machines DBMS لحمل عمل SAP. على Linux، يمكنك استخدام LVM أو mdadm لإنشاء جهاز منطقي كبير واحد عبر أقراص متعددة.

بالنسبة إلى Azure M-Series VM، يمكنك تقليل حسب عوامل زمن الانتقال للكتابة في سجلات المعاملات، مقارنة بأداء تخزين Azure Premium، عند استخدام Azure Write Accelerator. لذلك، يجب نشر Azure Write Accelerator لواحد أو أكثر من VHDs التي تشكل وحدة التخزين لسجلات معاملات Db2. يمكن قراءة التفاصيل في المستند مسرع الكتابة.

أصدر IBM Db2 LUW 11.5 دعمًا لقطاع بحجم 4 كيلوبايت. على الرغم من أنك تحتاج إلى تمكين استخدام قطاع بحجم 4 كيلوبايت مع 11.5 بواسطة إعداد تكوينات db2set DB2_4K_DEVICE_SUPPORT=ON كما هو موثق في:

بالنسبة لإصدارات Db2 الأقدم، يجب استخدام حجم قطاع 512 بايت. أقراص Premium SSD أصلية 4 كيلوبايت تحاكي 512 بايت. يستخدم قرص Ultra قطاع بحجم 4 كيلوبايت بشكل افتراضي. يمكنك تمكين حجم قطاع 512 بايت أثناء إنشاء قرص Ultra. تتوفر التفاصيل باستخدام أقراص Azure ultra. حجم قطاع 512 بايت هذا هو شرط أساسي لإصدارات IBM Db2 LUW الأقل من 11.5.

في Windows باستخدام تجمعات التخزين لمسارات تخزين Db2 ل log_dir، sapdata والدلائل saptmp ، يجب تحديد حجم قطاع القرص الفعلي من 512 بايت. عند استخدام تجمعات تخزين Windows، يجب عليك إنشاء تجمعات التخزين يدويًا عبر واجهة سطر الأوامر باستخدام المعلمة -LogicalSectorSizeDefault. لمزيد من المعلومات، راجع New-StoragePool.

توصية بشأن الجهاز الظاهري وبنية القرص لنشر IBM Db2

يتم دعم IBM Db2 لتطبيقات SAP NetWeaver على أي نوع من أنواع الأجهزة الظاهرية المدرجة في ملاحظة دعم SAP 1928533. مجموعات الأجهزة الظاهرية الموصى بها لتشغيل قاعدة بيانات IBM Db2 هي Esd_v4/Eas_v4/Es_v3 وسلسلة M/M_v2 لقواعد البيانات الكبيرة متعددة التيرابايت. يمكن تحسين أداء كتابة قرص سجل معاملات IBM Db2 من خلال تمكين مسرع الكتابة من السلسلة M.

فيما يلي تكوين أساسي لمختلف الأحجام واستخدامات عمليات توزيع SAP على Db2 من الصغيرة إلى x-large.

هام

أنواع الجهاز الظاهري المذكورة أدناه هي أمثلة تفي بوحدة المعالجة المركزية الظاهرية والذاكرة لكل فئة من الفئات. يعتمد تكوين التخزين على تخزين Azure premium v1. Premium SSD v2 وقرص Azure Ultra مدعوم بالكامل مع IBM Db2 أيضا ويمكن استخدامه في عمليات النشر. استخدم قيم السعة ومعدل نقل الاندفاع واندفاع IOPS لتحديد قرص Ultra أو تكوين Premium SSD v2. يمكنك الحد من عمليات الإدخال والإخراج لـ /db2//<SID>log_dir عند حوالي 5000 عملية إدخال وإخراج. ضبط معدل النقل وIOOPS إلى حمل العمل المحدد إذا كانت توصيات الأساس هذه لا تفي بالمتطلبات

نظام SAP الصغير جدًا: حجم قاعدة البيانات 50 - 200 جيجابايت: مثال مدير الحلول

حجم الجهاز الظاهري / أمثلة نقطة تركيب Db2 قرص Azure Premium عدد الأقراص عمليات الإدخال / الإخراج في الثانية (IOPS) الإنتاجية
[ميجابايت/الثانية]
الحجم [جيجابايت] اندفاع IOPS الإنتاجية المتلاحقة
[جيجابايت]
حجم الشريط التخزين المؤقت
وحدة المعالجة المركزية الظاهرية: 4 /db2 P6 1 240 50 64 3,500 170
ذاكرة الوصول العشوائي: ~32 جيبي بايت /db2/<SID>/sapdata P10 2 1,000 200 256 7,000 340 256
كيلوبايت
ReadOnly
E4(d)s_v5 /db2/<SID>/saptmp P6 1 240 50 128 3,500 170
E4(d)as_v5 /db2/<SID>/log_dir P6 2 480 100 128 7,000 340 64
كيلوبايت
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3,500 170

نظام SAP الصغير: حجم قاعدة البيانات 200 - 750 جيجابايت: Business Suite الصغيرة

حجم الجهاز الظاهري / أمثلة نقطة تركيب Db2 قرص Azure Premium عدد الأقراص عمليات الإدخال / الإخراج في الثانية (IOPS) الإنتاجية
[ميجابايت/الثانية]
الحجم [جيجابايت] اندفاع IOPS الإنتاجية المتلاحقة
[جيجابايت]
حجم الشريط التخزين المؤقت
vCPU: 16 /db2 P6 1 240 50 64 3,500 170
ذاكرة الوصول العشوائي: ~128 جيبي بايت /db2/<SID>/sapdata P15 4 4400 500 1.024 14000 680 256 كيلوبايت ReadOnly
E16(d)s_v5 /db2/<SID>/saptmp P6 2 480 100 128 7,000 340 128 كيلوبايت
E16(d)as_v5 /db2/<SID>/log_dir P15 2 2,200 250 512 7,000 340 64
كيلوبايت
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3,500 170

نظام SAP المتوسط: حجم قاعدة البيانات 500 - 1000 جيجابايت: Business Suite الصغيرة

حجم الجهاز الظاهري / أمثلة نقطة تركيب Db2 قرص Azure Premium عدد الأقراص عمليات الإدخال / الإخراج في الثانية (IOPS) الإنتاجية
[ميجابايت/الثانية]
الحجم [جيجابايت] اندفاع IOPS الإنتاجية المتلاحقة
[جيجابايت]
حجم الشريط التخزين المؤقت
وحدة المعالجة المركزية الظاهرية: 32 /db2 P6 1 240 50 64 3,500 170
ذاكرة الوصول العشوائي: ~256 جيبي بايت /db2/<SID>/sapdata P30 2 10,000 400 2.048 10,000 400 256 كيلوبايت ReadOnly
E32(d)s_v5 /db2/<SID>/saptmp P10 2 1,000 200 256 7,000 340 128 كيلوبايت
E32(d)as_v5 /db2/<SID>/log_dir P20 2 4,600 300 1.024 7,000 340 64
كيلوبايت
M32ls /db2/<SID>/offline_log_dir P15 1 1,100 125 256 3,500 170

نظام SAP الكبير: حجم قاعدة البيانات 750 - 2000 جيجابايت: Business Suite

حجم الجهاز الظاهري / أمثلة نقطة تركيب Db2 قرص Azure Premium عدد الأقراص عمليات الإدخال / الإخراج في الثانية (IOPS) الإنتاجية
[ميجابايت/الثانية]
الحجم [جيجابايت] اندفاع IOPS الإنتاجية المتلاحقة
[جيجابايت]
حجم الشريط التخزين المؤقت
vCPU: 64 /db2 P6 1 240 50 64 3,500 170
ذاكرة الوصول العشوائي: ~512 جيبي بايت /db2/<SID>/sapdata P30 4 20,000 800 4.096 20,000 800 256 كيلوبايت ReadOnly
E64(d)s_v5 /db2/<SID>/saptmp P15 2 2,200 250 512 7,000 340 128 كيلوبايت
E64(d)as_v5 /db2/<SID>/log_dir P20 4 9200 600 2.048 14000 680 64
كيلوبايت
M64ls /db2/<SID>/offline_log_dir P20 1 2,300 150 512 3,500 170

نظام SAP الكبير متعدد التيرابايت: حجم قاعدة البيانات 2 تيرابايت +: نظام Global Business Suite

خاصة بالنسبة لمثل هذه الأنظمة الأكبر، من المهم تقييم البنية الأساسية التي يعمل عليها النظام حاليا وبيانات استهلاك الموارد لتلك الأنظمة للعثور على أفضل تطابق للبنية الأساسية للحوسبة والتخزين وتكوين Azure.

اسم / حجم الجهاز الظاهري نقطة تركيب Db2 قرص Azure Premium عدد الأقراص عمليات الإدخال / الإخراج في الثانية (IOPS) الإنتاجية
[ميجابايت/الثانية]
الحجم [جيجابايت] اندفاع IOPS الإنتاجية المتلاحقة
[جيجابايت]
حجم الشريط التخزين المؤقت
وحدة المعالجة المركزية الظاهرية: =>128 /db2 P10 1 500 100 128 3,500 170
ذاكرة الوصول العشوائي: =>2,048 جيبي بايت /db2/<SID>/sapdata P40 4 30,000 1.000 8.192 30,000 1.000 256 كيلوبايت ReadOnly
M128s_v2 /db2/<SID>/saptmp P20 2 4,600 300 1.024 7,000 340 128 كيلوبايت
M176s_2_v3 /db2/<SID>/log_dir P30 4 20,000 800 4.096 20,000 800 64
كيلوبايت
كتابة
مسرع الحل
M176s_3_v3،
M176s_4_v3
/db2/<SID>/offline_log_dir P30 1 5,000 200 1.024 5,000 200

استخدام ملفات Azure NetApp

يتم دعم استخدام وحدات تخزين NFS v4.1 استنادًا إلى ملفات Azure NetApp (ANF) مع IBM Db2، المستضاف في نظام التشغيل المضيف Suse أو Red Hat Linux. يجب عليك إنشاء أربعة مجلدات مختلفة على الأقل تسرد مثل:

  • وحدة التخزين المشتركة لـ saptmp1 وsapmnt وusr_sap و<sid>_home و db2<sid> _home وdb2_software
  • وحدة تخزين بيانات واحدة لـ sapdata1 إلى sapdatan
  • وحدة تخزين سجل واحدة لدليل سجل الإعادة
  • وحدة تخزين واحدة لمحفوظات السجل والنسخ الاحتياطية

قد يكون الحجم الخامس المحتمل هو وحدة تخزين ANF التي تستخدمها لمزيد من النسخ الاحتياطية طويلة الأجل التي تستخدمها لالتقاط اللقطات وتخزينها في مخزن Azure Blob.

قد يبدو التكوين كما هو موضح هنا:

مثال على تكوين Db2 باستخدام ANF

يجب اختيار مستوى الأداء وحجم وحدات التخزين المستضافة من ANF بناء على متطلبات الأداء. ومع ذلك، نوصي بأخذ مستوى أداء Ultra للبيانات ووحدة تخزين السجل. لا يتم دعم خلط تخزين الكتلة وأنواع التخزين المشتركة للبيانات وحجم السجل.

اعتبارًا من خيارات التثبيت، قد يبدو تثبيت وحدات التخزين هذه (تحتاج إلى استبدال <SID> و <sid> بـSID لنظام SAP الخاص بك):

vi /etc/idmapd.conf   
 # Example
 [General]
 Domain = defaultv4iddomain.com
 [Mapping]
 Nobody-User = nobody
 Nobody-Group = nobody

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2shared /mnt 
mkdir -p /db2/Software /db2/AN1/saptmp /usr/sap/<SID> /sapmnt/<SID> /home/<sid>adm /db2/db2<sid> /db2/<SID>/db2_software
mkdir -p /mnt/Software /mnt/saptmp  /mnt/usr_sap /mnt/sapmnt /mnt/<sid>_home /mnt/db2_software /mnt/db2<sid>
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2data /mnt
mkdir -p /db2/AN1/sapdata/sapdata1 /db2/AN1/sapdata/sapdata2 /db2/AN1/sapdata/sapdata3 /db2/AN1/sapdata/sapdata4
mkdir -p /mnt/sapdata1 /mnt/sapdata2 /mnt/sapdata3 /mnt/sapdata4
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2log /mnt 
mkdir /db2/AN1/log_dir
mkdir /mnt/log_dir
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2backup /mnt
mkdir /db2/AN1/backup
mkdir /mnt/backup
mkdir /db2/AN1/offline_log_dir /db2/AN1/db2dump
mkdir /mnt/offline_log_dir /mnt/db2dump
umount /mnt

إشعار

مطلوب خيار التثبيت الثابت والمزامنة

Backup/Restore

يتم دعم وظيفة النسخ الاحتياطي/الاستعادة لـ IBM Db2 لـ LUW بنفس الطريقة كما هو الحال في أنظمة تشغيل خادم Windows القياسية وHyper-V.

تأكد من وجود إستراتيجية نسخ احتياطي صالحة لقاعدة البيانات.

وكما هو الحال في عمليات نشر المعادن العارية، يعتمد أداء النسخ الاحتياطي/الاستعادة على عدد وحدات التخزين التي يمكن قراءتها بالتوازي وإنتاجية هذه المجلدات. بالإضافة إلى ذلك، قد يلعب استهلاك وحدة المعالجة المركزية المستخدمة بواسطة ضغط النسخ الاحتياطي دورًا مهمًا على الأجهزة الظاهرية مع ما يصل إلى ثمانية مؤشرات ترابط لوحدة المعالجة المركزية. لذلك، يمكن للمرء أن يفترض:

  • كلما قل عدد الأقراص المستخدمة لتخزين أجهزة قاعدة البيانات، قلت الإنتاجية الإجمالية في القراءة
  • كلما قل عدد مؤشرات ترابط وحدة المعالجة المركزية في الجهاز الظاهري، زاد تأثير ضغط النسخ الاحتياطي
  • كلما قل عدد الأهداف (الدلائل الشريطية والأقراص) لكتابة النسخة الاحتياطية إليها، انخفض معدل الإنتاجية

لزيادة عدد الأهداف للكتابة إليها، يمكن استخدام/دمج خيارين اعتمادًا على احتياجاتك:

  • تخطيط وحدة التخزين المستهدفة للنسخ الاحتياطي عبر أقراص متعددة لتحسين إنتاجية عمليات الإدخال والإخراج على وحدة التخزين المخططة هذه
  • استخدام أكثر من دليل هدف واحد لكتابة النسخة الاحتياطية إليه

إشعار

لا يدعم Db2 على Windows تقنية Windows VSS. ونتيجة لذلك، لا يمكن الاستفادة من النسخ الاحتياطي المتسق للجهاز الظاهري للتطبيق لخدمة النسخ الاحتياطي لـ Azure Backup Service للأجهزة الظاهرية التي يتم نشر Db2 DBMS فيها.

قابلية الوصول العالية والتعافي من الكوارث

جهاز تنظيم ضربات القلب Linux

هام

بالنسبة إلى الإصدار 11.5.6 الخاص بـ Db2 والإصدارات الأحدث، نوصي بشدة بالحل المتكامل باستخدام Pacemaker من شركة IBM.

خادم نظام المجموعة Windows

نظام مجموعة تجاوز الفشل ل Windows Server (WSFC) المعروف أيضا باسم Microsoft Cluster Server (MSCS) غير مدعوم.

يتم دعم Db2 للتعافي من الكوارث عالي التوافر (HADR). إذا كانت الأجهزة الظاهرية لتكوين قابلية الوصول العالية تحتوي على تحليل اسم العمل، فإن الإعداد في Azure لا يختلف عن أي إعداد يتم محليا. لا يوصى بالاعتماد على دقة IP فقط.

لا تستخدم النسخ المتماثل الجغرافي لحسابات التخزين التي تخزن أقراص قاعدة البيانات. لمزيد من المعلومات، راجع المستند اعتبارات لنشر DBMS أجهزة Azure الظاهرية لحمل عمل SAP.

تسريع الشبكات

بالنسبة إلى عمليات نشر Db2 على Windows، نوصي بشدة باستخدام وظيفة Azure للشبكات المسرعة كما هو موضح في المستند Azure Accelerated Networking. ضع في اعتبارك أيضا التوصيات المقدمة في اعتبارات نشر DBMS أجهزة Azure الظاهرية لحمل عمل SAP.

تفاصيل عمليات نشر Linux

طالما أن الحصة النسبية الحالية IOPS لكل قرص كافية، فمن الممكن تخزين جميع ملفات قاعدة البيانات على قرص واحد. بينما يجب عليك دائما فصل ملفات البيانات وملفات سجل المعاملات على أقراص مختلفة.

إذا لم يكن معدل نقل IOPS أو I/O ل Azure VHD واحد كافيا، يمكنك استخدام LVM (إدارة وحدة التخزين المنطقية) أو MDADM كما هو موضح في المستند اعتبارات نشر Azure Virtual Machines DBMS لحمل عمل SAP لإنشاء جهاز منطقي كبير واحد عبر أقراص متعددة. بالنسبة للأقراص التي تحتوي على مسارات تخزين Db2 للدلائل sapdata و saptmp ، يجب تحديد حجم قطاع القرص الفعلي 512 كيلوبايت.

أخرى

تنطبق جميع المجالات العامة الأخرى مثل مجموعات توفر Azure أو مراقبة SAP على عمليات نشر الأجهزة الظاهرية باستخدام قاعدة بيانات IBM أيضا. هذه المجالات العامة التي نصفها في اعتبارات توزيع Azure Virtual Machines DBMS لحمل عمل SAP.

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

قراءة المقال: