مشاركة عبر

تكوينات تخزين الجهاز الظاهري في Azure على SAP HANA

  • مقالة

يوفر Azure أنواع مختلفة من التخزين التي تناسب VMs Azure التي تقوم بتشغيل SAP HANA. أنواع تخزين Azure المعتمدة من SAP HANA التي يمكن اعتبارها في قائمة عمليات نشر SAP HANA مثل:

للتعرف على أنواع الأقراص هذه، راجع المقالة أنواع تخزين Azure لحمل عمل SAP وتحديد نوع القرص

يقدم Azure طريقتين للتوزيع لأقراص VHD على Azure Standard والتخزين المتميز v1/v2. نتوقع منك الاستفادة من قرص Azure المُدار لعمليات توزيع تخزين كتلة Azure.

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

هام

بغض النظر عن نوع تخزين Azure المختار، يجب دعم نظام الملفات المستخدم في هذا التخزين بواسطة SAP لنظام التشغيل ونظام إدارة قواعد البيانات (DBMS) المحددين. تسرد ملاحظة دعم SAP رقم #2972496 أنظمة الملفات المدعومة لأنظمة التشغيل وقواعد البيانات المختلفة، بما في ذلك SAP Hana. ينطبق هذا على جميع وحدات تخزين SAP Hana التي قد يصل إليها SAP Hana للقراءة والكتابة لأي مهمة. باستخدام NFS على Azure لـ SAP HANA تحديداً، يتم تطبيق قيود إضافية على إصدارات NFS كما هو مذكور لاحقاً في هذه المقالة

الحد الأدنى من شروط SAP HANA المعتمدة لأنواع التخزين المختلفة هي:

  • Azure premium storage v1 - /hana/log مطلوب ليتم دعمه من قبل Azure Write Accelerator. يمكن وضع وحدة تخزين /hana/data على التخزين المتميز v1 دون Azure Write Accelerator أو على قرص Ultra. لا يدعم تخزين Azure premium v2 أو Azure premium SSD v2 استخدام Azure Write Accelerator
  • قرص Azure Ultra على الأقل لوحدة التخزين /hana/log. يمكن وضع وحدة التخزين /hana/data إما على التخزين المتميز v1/v2 دون Azure Write Accelerator أو للحصول على أوقات إعادة تشغيل أسرع للقرص Ultra
  • وحدات تخزين NFS v4.1 أعلى ملفات Azure NetApp لـ hana/log/ وhana/data/. يمكن لوحدة تخزين /hana/shared استخدام بروتوكول NFS v3 أو NFS v4.1

استنادا إلى الخبرة المكتسبة مع العملاء، قمنا بتغيير الدعم للجمع بين أنواع التخزين المختلفة بين /hana/data و /hana/log. يتم دعم الجمع بين استخدام مخازن كتلة Azure المختلفة المعتمدة لمشاركات HANA وNFS استنادا إلى ملفات Azure NetApp. على سبيل المثال، من الممكن وضع /hana/data على التخزين المتميز v1 أو v2 ويمكن وضع /hana/log على تخزين قرص Ultra للحصول على زمن الانتقال المنخفض المطلوب. إذا كنت تستخدم وحدة تخزين تستند إلى ANF ل /hana/data، يمكن وضع وحدة تخزين /hana/log على أحد أنواع تخزين كتلة Azure المعتمدة من HANA أيضا. يتم دعم استخدام NFS أعلى ANF لأحد وحدات التخزين (مثل /hana/data) وتخزين Azure المتميز v1/v2 أو قرص Ultra لوحدة التخزين الأخرى (مثل /hana/log).

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

  • القراءة/الكتابة على /hana/log بسرعة 250 ميجابايت/ثانية بأحجام الإدخال/إخراج 1 ميجابايت
  • نشاط القراءة بما لا يقل عن 400 ميجابايت/ثانية لـ hana/data/ لأحجام الإدخال/إخراج 16 ميجابايت و64 ميجابايت
  • نشاط الكتابة بما لا يقل عن 250 ميجابايت/ثانية لـ /hana/data لأحجام الإدخال/إخراج 16 ميجابايت و64 ميجابايت

وبالنظر إلى أن انخفاض زمن التخزين أمر بالغ الأهمية لأنظمة DBMS، حتى مع احتفاظ DBMS، مثل SAP HANA، بالبيانات في الذاكرة. المسار الحرج في التخزين يكون عادة حول عمليات كتابة سجل المعاملات لأنظمة DBMS. ولكن أيضاً عمليات مثل كتابة savepoints أو تحميل البيانات في الذاكرة بعد استرداد تحطم يمكن أن تكون حاسمة. لذلك، من الإلزامي استخدام تخزين Azure المتميز v1/v2 أو قرص Ultra أو ANF لوحدات تخزين /hana/data و /hana/log .

يمكن إدراج بعض المبادئ التوجيهية في اختيار تكوين تخزين HANA مثل:

  • تحديد نوع التخزين استناداً إلى أنواع تخزين Azure لحمل عمل SAP وتحديد نوع القرص
  • يتم وضع إجمالي معدل نقل الإدخال/إخراج للجهاز الظاهري وحدود IOPS في الاعتبار عند تغيير الحجم أو اتخاذ قرار للجهاز الظاهري. تم توثيق إجمالي معدل نقل تخزين الجهاز الظاهري في المقالة أحجام الأجهزة الظاهرية المحسنة للذاكرة
  • عند اتخاذ قرار بشأن تكوين التخزين، حاول البقاء دون معدل النقل الإجمالي للجهاز الظاهري باستخدام تكوين وحدة تخزين /hana/data. نقاط حفظ كتابة SAP HANA، يمكن أن تكون HANA عدوانية في إصدار I/Os. من الممكن بسهولة دفع ما يصل إلى حدود معدل النقل لوحدة تخزين /hana/data عند كتابة نقطة حفظ. إذا كان القرص (الأقراص) الذي ينشئ وحدة تخزين /hana/data يحتوي على معدل نقل أعلى مما يسمح به الجهاز الظاهري، فقد تواجه مواقف يتداخل فيها معدل النقل المستخدم بواسطة كتابة نقطة الحفظ مع متطلبات معدل النقل الخاصة بكتابة سجل الإعادة. موقف يمكن أن يؤثر في معدل نقل التطبيق
  • إذا كنت تفكر في استخدام HANA System Replication، يجب أن يكون التخزين المستخدم ل /hana/data على كل نسخة متماثلة هو نفسه ويجب أن يكون نوع التخزين المستخدم ل /hana/log على كل نسخة متماثلة هو نفسه. على سبيل المثال، استخدام تخزين Azure premium v1 ل /hana/data مع جهاز ظاهري واحد وقرص Azure Ultra ل /hana/data في جهاز ظاهري آخر يقوم بتشغيل نسخة متماثلة من نفس تكوين النسخ المتماثل لنظام HANA، غير مدعوم

هام

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

المجموعات الشريطية مقابل تقسيم وحدة تخزين بيانات SAP Hana

باستخدام تخزين Azure premium v1، قد تحصل على أفضل نسبة سعر/أداء عند تخطيط وحدة تخزين /hana/data و/أو /hana/log عبر أقراص Azure متعددة. بدلاً من توزيع وحدات تخزين أقراص أكبر الذي توفر المزيد على IOPS أو معدل النقل المطلوبين. يمكن إنشاء وحدة تخزين واحدة عبر أقراص Azure متعددة مع مديري وحدة التخزين LVM وMDADM، والتي تعد جزءا من Linux. طريقة دمج الأقراص قديمة منذ عقود ومعروفة جيداً. على الرغم من فائدة وحدات التخزين الشريطية هذه للوصول إلى إمكانات IOPS أو معدل النقل الذي قد تحتاجه، إلا أنها تضيف تعقيدات حول إدارة وحدات التخزين الشريطية هذه. خاصة في الحالات التي تحتاج فيها وحدات التخزين إلى التمديد في السعة. على الأقل بالنسبة إلى /hana/data، قدمت SAP طريقة بديلة تحقق نفس هدف الدمج عبر أقراص Azure متعددة. نظرا لأن SAP HANA 2.0 SPS03، فإن خادم فهرس HANA قادر على دمج نشاط الإدخال/الإخراج الخاص به عبر ملفات بيانات HANA متعددة، والتي توجد على أقراص Azure مختلفة. الميزة هي أنك لست مضطراً إلى الاهتمام بإنشاء وحدة تخزين شريطية وإدارتها عبر أقراص Azure المختلفة. يتم وصف الوظيفة SAP Hana لتقسيم وحدة تخزين البيانات بالتفصيل في:

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

وضع جدولة إدخال/إخراج Linux

يحتوي Linux على العديد من أوضاع جدولة الإدخال/الإخراج المختلفة. التوصية الشائعة من خلال بائعي Linux وSAP هي إعادة تكوين وضع جدولة الإدخال/الإخراج لوحدات تخزين القرص من الوضع mq-deadline أو kyber إلى noop (non-multiqueue) أو none للوضع (multiqueue) إذا لم يتم ذلك بعد بواسطة ملف تعريفات SLES saptune. يشار إلى التفاصيل في:

على Red Hat، اترك الإعدادات كما تم تحديدها بواسطة ملفات التعريف المحددة لتطبيقات SAP المختلفة.

أحجام التخطيط عند استخدام مديري وحدات التخزين المنطقية

إذا كنت تستخدم LVM أو mdadm لإنشاء مجموعات شريطية عبر العديد من أقراص Azure المتميزة، فأنت بحاجة إلى تحديد أحجام الشريط. تختلف هذه الأحجام بين /hana/data و/hana/log. التوصية: كأحجام شريطية ينصح باستخدام:

  • 256 كيلوبايت لـ /hana/data
  • 64 كيلوبايت لـ /hana/log

إشعار

تم تغيير حجم الشريط لـ /hana/data من التوصيات السابقة التي تدعو إلى 64 كيلوبايت أو 128 كيلوبايت إلى 256 كيلوبايت استناداً إلى تجارب العملاء مع إصدارات Linux الأحدث. حجم 256 كيلو بايت يوفر أداء أفضل قليلاً. كما قمنا بتغيير التوصية الخاصة بأحجام الشريط لـ /hana/log من 32 كيلوبايت إلى 64 كيلوبايت من أجل الحصول على معدل نقل كافٍ بأحجام إدخال/إخراج أكبر.

إشعار

لا تحتاج إلى تكوين أي مستوى تكرار باستخدام وحدات تخزين RAID؛ نظرا لأن تخزين الكتلة من Azure يحتفظ بثلاث صور لـ VHD. إن استخدام مجموعة شريطية مع أقراص Azure المتميزة هو فقط لتكوين وحدات التخزين التي توفر عمليات IOPS كافية و/أو معدل نقل الإدخال/الإخراج.

تجميع أقراص Azure المتعددة أسفل مجموعة شريطية، تراكمي من جانب IOPS ومعدل نقل التخزين. لذلك، إذا وضعت مجموعة شريطية عبر أكثر من 3 x P30 أقراص تخزين Azure Premium v1، فيجب أن تمنحك ثلاث مرات IOPS وثلاث مرات معدل نقل التخزين لقرص Azure Premium Storage v1 P30 واحد.

هام

في حالة استخدام LVM أو mdadm كمدير وحدة تخزين لإنشاء مجموعات شريطية عبر عدة أقراص Azure premium، يجب ألا يتم وضع أنظمة ملفات /بيانات SAP HANA الثلاثة و/log و/shared في مجموعة وحدة تخزين افتراضية أو جذر. يوصى بشدة باتباع إرشادات موردي Linux التي عادة ما تكون لإنشاء مجموعات وحدة تخزين فردية ل /data و/log و/shared.

اعتبارات نظام الملفات المشتركة HANA

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

إذا كان نظام HANA في تكوين قابلية وصول عالية، فقد تتسبب الاستجابات البطيئة من نظام الملفات المشتركة، أي /hana/shared في مهلات موارد نظام المجموعة. قد تؤدي هذه المهلات إلى تجاوز الفشل غير الضروري، لأن عوامل موارد HANA قد تفترض بشكل غير صحيح أن قاعدة البيانات غير متوفرة.

ستبدو إرشادات SAP للأحجام الموصى بها /hana/shared كما يلي:

الحجم الحجم الموصى به
hana/shared/توسيع النطاق الحد الأدنى (1 تيرابايت، 1 × ذاكرة الوصول العشوائي)
hana/shared/ إجراء التوسع 1 × RAM من عقدة العامل
لكل أربع عقد عامل

راجع ملاحظات SAP التالية للحصول على مزيد من التفاصيل:
3288971 - الأسئلة المتداولة: SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager في SAP HANA System Replication Environments
1999930 - الأسئلة المتداولة: SAP HANA I/O Analysis

كأفضل ممارسة، الحجم /hana/shared لتجنب اختناقات الأداء. تذكر أن نظام الملفات /hana/shared بحجم جيد يساهم في استقرار وموثوقية نظام SAP HANA الخاص بك، خاصة في سيناريوهات قابلية الوصول العالية.

تكوينات Azure Premium Storage v1 ل HANA

للحصول على توصيات تكوين تخزين HANA مفصلة باستخدام تخزين Azure premium v1، اقرأ المستند تكوينات تخزين SSD المتميز للجهاز الظاهري SAP HANA Azure.

تكوينات Azure Premium SSD v2 ل HANA

للحصول على توصيات تكوين تخزين HANA مفصلة باستخدام تخزين Azure premium ssd v2، اقرأ المستند تكوينات تخزين SAP HANA Azure virtual machine Premium SSD v2.

تكوين تخزين قرص Azure Ultra لـ SAP Hana

للحصول على توصيات تكوين تخزين HANA مفصلة باستخدام Azure Ultra Disk، اقرأ المستند تكوينات تخزين القرص الفائق للجهاز الظاهري SAP HANA Azure.

وحدات التخزين NFS v4.1 على ملفات Azure NetApp

للحصول على تفاصيل حول ملفات Azure NetApp ل HANA، اقرأ المستند وحدات تخزين NFS v4.1 على Azure NetApp Files ل SAP HANA.

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

لمزيد من المعلومات، راجع: