مشاركة عبر

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

  • مقالة

توفر ملفات Azure NetApp مشاركات NFS الأصلية التي يمكن استخدامها لوحدات hana/shared/، وhana/data/، وhana/log/ الخاصة بالتخزين. يتطلب استخدام مشاركات NFS المستندة إلى ANF لوحدات التخزين hana/data/ وhana/log/ استخدام بروتوكول V4.1 NFS. بروتوكول NFS v3 غير مدعوم لاستخدام وحدات التخزين hana/data/ وhana/log/ وحدات التخزين عند إسناد المشاركات إلى ANF.

هام

بروتوكول NFS v3 المنفذ على ملفات Azure NetApp لا يدعم الاستخدام في hana/data/ وhana/log/. يُعتبر استخدام NFS 4.1 إلزامي لوحدات التخزين hana/data/ وhana/log/ من وجهة نظر وظيفية. بينما بالنسبة لوحدة التخزين hana/shared/ يمكن استخدام بروتوكول NFS v3 أو NFS v4.1 من وجهة نظر وظيفية.

اعتبارات هامة

عند النظر في ملفات Azure NetApp لـ SAP Netweaver وSAP HANA، كن على علم بالاعتبارات المهمة التالية:

  • الحد الأدنى لمجمع السعة هو 4 تيرا بايت.

  • الحد الأدنى لحجم المجلد هو 100جيجابايت.

  • يجب أن تكون مشاركات NFS المستندة إلى ANF والأجهزة الظاهرية التي تقوم بتحميل هذه المشاركات في نفس شبكة Azure الظاهرية أو في الشبكات الظاهرية النظيرة في نفس المنطقة

  • يجب أن تحتوي الشبكة الظاهرية المحددة على شبكة فرعية، ذات وصول مفوض إلى ملفات Azure NetApp. بالنسبة لحمل عمل SAP، يوصى بشدة بتكوين نطاق /25 للشبكة الفرعية المفوضة إلى ANF.

  • من المهم أن تنشر الأجهزة الظاهرية تقاربا كافيا من تخزين Azure NetApp لتقليل زمن الانتقال، على سبيل المثال، الذي يطلبه SAP HANA لإعادة كتابة السجل.

    • وفي الوقت نفسه، تحتوي ملفات Azure NetApp على وظائف لنشر وحدات تخزين NFS في مناطق توفر Azure محددة. وهذا التقارب النطاقي سيكون كافيا في معظم الحالات لتحقيق زمن انتقال أقل من 1 مللي ثانية. الوظيفة في المعاينة العامة وموضحة في المقالة إدارة موضع وحدة تخزين منطقة التوفر لملفات Azure NetApp. لا تتطلب هذه الوظيفة أي عملية تفاعلية مع Microsoft لتحقيق التقارب بين VM ووحدات تخزين NFS التي تخصصها.
    • لتحقيق أقصى قدر من التقارب الأمثل، تتوفر وظائف مجموعات وحدة تخزين التطبيق. لا تبحث هذه الوظيفة عن التقارب الأمثل فقط، ولكن للحصول على الموضع الأمثل لوحدات تخزين NFS، لذلك، يتم التعامل مع بيانات HANA ووحدات تخزين سجل إعادة الإعادة بواسطة وحدات تحكم مختلفة. العيب هو أن هذا الأسلوب يحتاج إلى بعض العمليات التفاعلية مع Microsoft لتثبيت الأجهزة الظاهرية الخاصة بك.

  • تأكد من قياس زمن الوصول من خادم قاعدة البيانات إلى وحدة تخزين ANF وأقل من 1 ميلي ثانية

  • معدل النقل لوحدة تخزين Azure NetApp هي دالة الحصة النسبية لوحدة التخزين ومستوى الخدمة، كما هو موثق في مستوى الخدمة لملفات Azure NetApp. عند تغيير حجم وحدات التخزين HANA Azure NetApp تأكد من أن نتائج معدل النقل تفي بمتطلبات نظام HANA. بدلا من ذلك، فكر في استخدام مجمع سعة جودة الخدمة اليدوي حيث يمكن تكوين سعة الحجم والإنتاجية وقياسهما بشكل مستقل (SAP HANA الأمثلة المحددة في هذا المستند

  • حاول "دمج" وحدات التخزين لتحقيق أداء أكبر في حجم أكبر، على سبيل المثال، استخدم مجلداً واحداً لـ /sapmnt أو /usr/sap/trans،.... إذا كان ذلك ممكناً

  • توفر Azure NetApp Files نهج التصدير: يمكنك التحكم في العملاء المسموح لهم، ونوع الوصول (القراءة والكتابة، والقراءة فقط، وما إلى ذلك).

  • يجب أن يتطابق معرف المستخدم ل adm sidو معرف المجموعة sapsys على الأجهزة الظاهرية التكوين في ملفات Azure NetApp.

  • تنفيذ معلمات نظام التشغيل Linux المذكورة في ملاحظة SAP 3024346

هام

بالنسبة لأحمال عمل SAP HANA، يعد انخفاض زمن الانتقال أمراً بالغ الأهمية. اعمل مع ممثل Microsoft لديك للتأكد من نشر الأجهزة الافتراضية ووحدات تخزين Azure NetApp Files على مسافة قريبة.

هام

إذا كان هناك عدم تطابق بين معرف المستخدم لـ sid adm ومعرف المجموعة لـ sapsys بين الجهاز الظاهري وتكوين Azure NetApp، سيتم عرض أذونات الملفات الموجودة على وحدات تخزين Azure NetApp، المحملة على جهاز ظاهري كـ nobody. تأكد من تحديد معرف المستخدم الصحيح ل adm sidو معرف المجموعة لـsapsysعند الصعود إلى نظام جديد إلى ملفات Azure NetApp.

خيار تحميل NCONNECT

Nconnect هو خيار تحميل لوحدات تخزين NFS المستضافة على ANF الذي يسمح لعميل NFS بفتح جلسات متعددة مقابل وحدة تخزين NFS واحدة. يؤدي استخدام nconnect بقيمة أكبر من 1 أيضا إلى تشغيل عميل NFS لاستخدام أكثر من جلسة RPC واحدة على جانب العميل (في نظام التشغيل الضيف) للتعامل مع حركة المرور بين نظام التشغيل الضيف ووحدات تخزين NFS المثبتة. استخدام جلسات متعددة تتعامل مع نسبة استخدام الشبكة لوحدة تخزين NFS واحدة، ولكن أيضا استخدام جلسات RPC متعددة يمكن أن يعالج سيناريوهات الأداء ومعدل النقل مثل:

  • تركيب وحدات تخزين NFS متعددة مستضافة من ANF مع مستويات خدمة مختلفة في جهاز ظاهري واحد
  • الحد الأقصى لمعدل الكتابة لوحدة التخزين و جلسة عمل Linux واحدة بين 1.2 و 1.4 غيغابايت/ثانية. يمكن أن يؤدي وجود جلسات متعددة مقابل وحدة تخزين NFS واحدة مستضافة من ANF إلى زيادة معدل النقل

بالنسبة لإصدارات نظام التشغيل Linux التي تدعم nconnect كخيار تحميل وبعض اعتبارات التكوين المهمة ل nconnect، خاصة مع نقاط نهاية خادم NFS المختلفة، اقرأ المستند أفضل ممارسات خيارات تحميل Linux NFS لملفات Azure NetApp.

التحجيم لقاعدة بيانات HANA على ملفات Azure NetApp

الإنتاجية لوحدة تخزين Azure NetApp هي دالة لحجم وحدة التخزين ومستوى الخدمة، كما هو موثق في مستوى الخدمة لملفات Azure NetApp.

من المهم أن نفهم علاقة الأداء بالحجم وأن هناك حدودا مادية لنقطة نهاية التخزين للخدمة. سيتم إدخال كل نقطة نهاية تخزين ديناميكيا في الشبكة الفرعية المفوضة Azure NetApp Files عند إنشاء وحدة التخزين وتلقي عنوان IP. يمكن لوحدات تخزين ملفات Azure NetApp - اعتمادا على السعة المتوفرة ومنطق النشر - مشاركة نقطة نهاية التخزين

يوضح الجدول أدناه أنه قد يكون من المنطقي إنشاء وحدة تخزين "قياسية" كبيرة لتخزين النسخ الاحتياطية وأنه من غير المنطقي إنشاء وحدة تخزين "Ultra" أكبر من 12 تيرابايت لأنه سيتم تجاوز سعة النطاق الترددي الفعلي لواجهة منطقية واحدة.

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

الحجم معدل نقل Standard معدل نقل Premium سرعة نقل Ultra
1 تيرابايت 16 ميغا بايت/ثانية 64 ميجابايت/ثانية 128 ميجابايت/ثانية
2 تيرابايت 32 ميجابايت/ثانية 128 ميجابايت/ثانية 256 ميجابايت/ثانية
4 تيرابايت 64 ميجابايت/ثانية 256 ميجابايت/ثانية 512 ميجابايت/ثانية
10 تيرابايت 160 ميجابايت/ثانية 640 ميجابايت/ثانية 1280 ميجابايت/ثانية
15 تيرابايت 240 ميجابايت/ثانية 960 ميجابايت/ثانية 1,400 ميجابايت/ثانية1
20 تيرابايت 320 ميجابايت/ثانية 1280 ميجابايت/ثانية 1,400 ميجابايت/ثانية1
40 تيرابايت 640 ميجابايت/ثانية 1,400 ميجابايت/ثانية1 1,400 ميجابايت/ثانية1

1: الكتابة أو قراءة حدود الإنتاجية لجلسة واحدة (في حالة عدم استخدام خيار تحميل NFS nconnect)

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

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

نوع وحدة التخزين ونوع الإدخال/الإخراج الحد الأدنى لمؤشرات الأداء الرئيسية المطلوبة من قبل SAP مستوى الخدمة الخاص بـ Premium مستوى الخدمة الخاص بـ Ultra
كتابة وحدة تخزين السجل 250 ميجابايت/ثانية 4 تيرابايت 2 تيرابايت
كتابة وحدة تخزين البيانات 250 ميجابايت/ثانية 4 تيرابايت 2 تيرابايت
قراءة حجم البيانات 400 بايت/ثانية 6.3 تيرابايت 3.2 تيرابايت

نظراً لطلب مؤشرات الأداء الرئيسية الثلاثة، يجب أن يكون حجم /hana/data بحجم أكبر لتلبية متطلبات القراءة الدنيا. إذا كنت تستخدم تجمعات سعة QoS اليدوية، يمكن تعريف حجم وحدات التخزين ومعدل نقلها بشكل مستقل. نظرا لأن كل من السعة والإنتاجية مأخوذة من نفس مجموعة السعة، يجب أن يكون مستوى خدمة المجمع وحجمه كبيرين بما يكفي لتقديم الأداء الإجمالي (انظر المثال هنا)

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

هام

مستقلة عن القدرة التي تنشرها على وحدة تخزين NFS واحد، الإنتاجية، ومن المتوقع أن الهضبة في نطاق 1.2-1.4 غيغابايت / ثانية عرض النطاق الترددي المستخدمة من قبل المستهلك في جلسة عمل واحدة. يتعلق ذلك بالبنية الأساسية لعرض ANF وحدود جلسات Linux ذات الصلة حول NFS. تم إجراء أرقام الأداء ومعدل النقل كما هو موثق في المقالة نتائج اختبار الأداء القياسي لـ Azure NetApp Files مقابل وحدة تخزين NFS مشتركة مع عدة أجهزة ظاهرية للعميل وأدي ذلك إلى إجراء جلسات متعددة. يختلف هذا السيناريو عن السيناريو الذي نقيسه في SAP. حيث نقيس الإنتاجية من جهاز ظاهري واحد مقابل وحدة تخزين NFS. استضافت على ANF.

لتلبية متطلبات الحد الأدنى من معدل نقل SAP للبيانات والسجل، ووفقاً للمبادئ التوجيهية لـ /hana/shared، فإن الأحجام الموصى بها تبدو كما يلي:

الحجم الحجم
طبقة التخزين Premium		 الحجم
طبقة التخزين الفائق		 بروتوكول NFS المعتمد
/hana/log/ 4 تيرا بايت 2تيرا بايت v4.1
/hana/data 6.3 تيرا بايت 3.2 تيرا بايت v4.1
hana/shared/توسيع النطاق الحد الأدنى (1 تيرابايت، 1 × ذاكرة الوصول العشوائي) الحد الأدنى (1 تيرابايت، 1 × ذاكرة الوصول العشوائي) v3 أو v4.1
hana/shared/ إجراء التوسع 1 × RAM من عقدة العامل
لكل أربع عقد عامل		 1 × RAM من عقدة العامل
لكل أربع عقد عامل		 v3 أو v4.1
/hana/logbackups 3 × ذاكرة الوصول العشوائي 3 × ذاكرة الوصول العشوائي v3 أو v4.1
/hana/backup 2 × ذاكرة الوصول العشوائي 2 × ذاكرة الوصول العشوائي v3 أو v4.1

بالنسبة لجميع وحدات التخزين، يوصى بشدة بـ NFS v4.1.
راجع بعناية اعتبارات تغيير الحجم /hana/shared، حيث يساهم الحجم المناسب /hana/shared volume في استقرار النظام.

أحجام وحدات التخزين الاحتياطية هي تقديرات. يجب تحديد المتطلبات الدقيقة استناداً إلى حمل العمل وعمليات التشغيل. للنسخ الاحتياطية، يمكنك دمج وحدات تخزين عديدة لمثيلات SAP HANA مختلفة إلى وحدة تخزين واحدة (أو وحدتين) أكبر، والتي يمكن أن يكون مستوى خدمة أقل من ANF.

إشعار

تستهدف Azure NetApp Files، وتوصيات تغيير الحجم المذكورة في هذا المستند، الحد الأدنى من متطلبات SAP تجاه موفري البنية التحتية الخاصة بهم. في عمليات نشر العملاء الحقيقية وسيناريوهات حمل العمل، قد لا يكون ذلك كافيا. استخدم هذه التوصيات كنقطة بداية وتكيف، استناداً إلى متطلبات حمل العمل المحدد.

لذلك قد تفكر في نشر معدل نقل مماثل لوحدات تخزين ANF كما هو مذكور لتخزين القرص Ultra بالفعل. ضع في اعتبارك أيضاً الأحجام ذات الصلة بالأحجام المدرجة لوحدات التخزين الخاصة بالأجهزة الظاهرية لـ SKUs المختلفة كما هو الحال في جداول Ultra disk بالفعل.

تلميح

يمكنك إعادة حجم ملفات Azure NetApp بشكل حيوي، دون الحاجة إلى unmount وحدات التخزين، أو إيقاف الأجهزة الظاهرية أو إيقاف SAP HANA. وهذا يسمح بالمرونة لتلبية متطلبات الإنتاجية المتوقعة وغير المتوقعة على حد سواء.

يتم نشر وثائق حول كيفية نشر تكوين مقياس SAP HANA مع عقدة الاستعداد باستخدام وحدات تخزين NFS v4.1 المستندة إلى ANF في توسيع نطاق SAP HANA مع عقدة الاستعداد على أجهزة Azure الظاهرية باستخدام Azure NetApp Files على SUSE Linux Enterprise Server.

إعدادات Linux Kernel

لنشر SAP HANA بنجاح على ANF، يجب تنفيذ إعدادات نواة Linux وفقا لملاحظة SAP 3024346.

بالنسبة للأنظمة التي تستخدم قابلية الوصول العالية (HA) التي تستخدم منظم ضربات القلب وAzure Load Balancer، يجب تنفيذ الإعدادات التالية في ملف /etc/sysctl.d/91-NetApp-HANA.conf

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1

يجب أن تنفذ الأنظمة التي تعمل بدون جهاز تنظيم ضربات القلب وAzure Load Balancer هذه الإعدادات في /etc/sysctl.d/91-NetApp-HANA.conf

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1

النشر مع التقارب النطاقي

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

النشر من خلال مجموعة وحدات تخزين تطبيقات ملفات Azure NetApp SAP HANA (AVG)

لنشر وحدات تخزين ANF بالقرب من الجهاز الظاهري الخاص بك، تم تطوير وظيفة جديدة تسمى مجموعة وحدات تخزين تطبيقات ملفاتAzure NetApp SAP HANA (AVG). هناك سلسلة من المقالات التي توثق الوظيفة. الأفضل هو البدء بالمقالة فهم مجموعة وحدات تخزين تطبيقات ملفاتAzure NetApp SAP HANA. أثناء قراءة المقالات، يصبح من الواضح أن استخدام AVGs يتضمن استخدام مجموعات مواضع القرب Azure أيضا. يتم استخدام مجموعات مواضع القرب بواسطة الوظيفة الجديدة للربط مع وحدات التخزين التي يتم إنشاؤها. للتأكد من أنه على مدى عمر نظام HANA، لن يتم نقل الأجهزة الظاهرية بعيدا عن وحدات تخزين ANF، نوصي باستخدام مجموعة من Avset/ PPG لكل منطقة من المناطق التي تنشر فيها. وسيبدو ترتيب النشر كما يلي:

  • باستخدام النموذج الذي تحتاجه لطلب تثبيت AvSet الفارغ على حساب HW للتأكد من أن الأجهزة الظاهرية لن تتحرك
  • تعيين PPG إلى مجموعة التوفر وبدء تشغيل جهاز ظاهري معين لمجموعة التوفر هذه
  • استخدام مجموعة وحدات تخزين تطبيقات ملفات Azure NetApp للحصول على وظائف SAP HANA لنشر وحدات تخزين HANA الخاصة بك

سيبدو تكوين مجموعة موضع القرب لاستخدام AVGs بطريقة مثلى:

مجموعة وحدات تخزين تطبيقات ANF وبنية ppg

يوضح الرسم التخطيطي أنك ستستخدم مجموعة موضع قرب Azure لطبقة DBMS. لذلك، يمكن أن تعتاد مع AVGs. من الأفضل فقط تضمين الأجهزة الظاهرية التي تقوم بتشغيل مثيلات HANA في مجموعة موضع التقارب. تعد مجموعة موضع القرب ضرورية، حتى في حالة استخدام جهاز ظاهري واحد فقط مع مثيل HANA واحد، حتى يتمكن AVG من تحديد أقرب قرب من أجهزة ANF. وتخصيص وحدة تخزين NFS على ANF في أقرب وقت ممكن إلى الجهاز الظاهري (الأجهزة الظاهرية) التي تستخدم وحدات تخزين NFS.

ينشئ هذا الأسلوب أفضل النتائج من حيث صلته با لزمن انتقال منخفض. ليس فقط عن طريق الحصول على وحدات تخزين NFS والأجهزة الظاهرية بالقرب من بعضها البعض قدر الإمكان. ولكن يتم أخذ اعتبارات وضع البيانات وإعادة وحدات تخزين السجل عبر وحدات تحكم مختلفة على الواجهة الخلفية NetApp في الاعتبار أيضا. على الرغم من ذلك، فإن العيب هو أن يتم تثبيت توزيع الجهاز الظاهري الخاص بك إلى مركز بيانات واحد. مع ذلك كنت تفقد المرونة في تغيير أنواع الأجهزة الظاهرية والعائلات. ونتيجة لذلك، يجب تقييد هذا الأسلوب بالأنظمة التي تتطلب على الإطلاق زمن انتقال منخفض للتخزين. بالنسبة لجميع الأنظمة الأخرى، يجب محاولة التوزيع باستخدام توزيع نطاقي تقليدي للجهاز الظاهري و ANF. في معظم الحالات يكون هذا كافيا من حيث زمن الانتقال المنخفض. وهذا يضمن أيضا صيانة وإدارة سهلة للجهاز الظاهري و ANF.

التوافر

يتم تطبيق تحديثات وترقيات نظام ANF دون التأثير على بيئة العميل. اتفاقية مستوى الخدمة المحددة هي 99.99٪.

وحدات التخزين وعناوين IP وتجمعات السعة

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

وحدة تخزين السجل ووحدة تخزين النسخ الاحتياطي للسجل

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

وينطبق الشيء نفسه على وحدة التخزين التي تستخدم كتابة النسخ الاحتياطية الكاملة لقاعدة بيانات HANA إليها.
 

نسخة احتياطية

بالإضافة إلى دفق النسخ الاحتياطية وخدمة Azure Back التي تنسخ نسخة احتياطية من قواعد بيانات SAP HANA كما هو موضح في المقالة دليل النسخ الاحتياطي ل SAP HANA على أجهزة Azure الظاهرية، تفتح Azure NetApp Files إمكانية إجراء النسخ الاحتياطية للقطة المستندة إلى التخزين.

يدعم SAP HANA:

  • دعم النسخ الاحتياطي للقطة المستندة إلى التخزين لنظام حاوية واحدة مع SAP HANA 1.0 SPS7 والإصدارات الأحدث
  • دعم النسخ الاحتياطي للقطة المستندة إلى التخزين لبيئات HANA لحاويات قواعد البيانات المتعددة (MDC) مع مستأجر واحد مع SAP HANA 2.0 SPS1 والإصدارات الأحدث
  • دعم النسخ الاحتياطي للقطة المستندة إلى التخزين لبيئات HANA لحاويات قواعد البيانات المتعددة (MDC) مع العديد من المستأجرين مع SAP HANA 2.0 SPS4 والإصدارات الأحدث

يعد إنشاء نسخ احتياطية للقطات تستند إلى التخزين إجراء بسيطا من أربع خطوات،

  1. إنشاء لقطة قاعدة بيانات HANA (داخلية) - نشاط تحتاج أنت أو الأدوات إلى تنفيذه
  2. يكتب SAP HANA البيانات إلى ملفات البيانات لإنشاء حالة متناسقة على التخزين - تنفذ HANA هذه الخطوة نتيجة إنشاء لقطة HANA
  3. قم بإنشاء لقطة على وحدة تخزين / hana/data على وحدة التخزين - وهي خطوة تحتاج أنت أو الأدوات إلى تنفيذها. ليست هناك حاجة لإجراء لقطة على وحدة التخزين /hana/log
  4. حذف لقطة قاعدة بيانات HANA (الداخلية) واستئناف التشغيل العادي - وهي خطوة تحتاج أنت أو الأدوات إلى تنفيذها

تحذير

إن تفويت الخطوة الأخيرة أو الفشل في تنفيذ الخطوة الأخيرة له تأثير شديد على الطلب على ذاكرة SAP HANA ويمكن أن يؤدي إلى توقف SAP HANA

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';

نسخة احتياطية من لقطة ANF لـ SAP HANA

az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname

نسخة احتياطية من لقطة ANF لـ SAP HANA الجزء 2

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID 47110815 SUCCESSFUL SNAPSHOT-2020-08-18:11:00';

يمكن إدارة إجراء النسخ الاحتياطي للقطة هذه بطرق مختلفة، باستخدام أدوات مختلفة. أحد الأمثلة على ذلك هو البرنامج النصي Python "ntaphana_azure.py" المتاح على GitHub https://github.com/netapp/ntaphana هذا هو نموذج التعليمات البرمجية، المقدمة "كما هي" دون أي صيانة أو دعم.

تنبيه

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

الحلول المتاحة للنسخ الاحتياطي المتسق للتطبيقات القائمة على لقطات التخزين:

  • Microsoft What is Azure Application Consistent Snapshot tool is a command-line tool that enable data protection for third-party databases. يعالج جميع التنسيق المطلوب لوضع قواعد البيانات في حالة متسقة للتطبيق قبل أخذ لقطة تخزين. بعد أخذ لقطة التخزين، ترجع الأداة قواعد البيانات إلى حالة تشغيلية. يدعم AzAcSnap النسخ الاحتياطية المستندة إلى اللقطة لمثيل HANA الكبير وملفات Azure NetApp. لمزيد من التفاصيل، اقرأ المقالة ما هي أداة Azure Application Consistent Snapshot
  • بالنسبة لمستخدمي منتجات النسخ الاحتياطي Commvault، هناك خيار آخر هو Commvault IntelliSnap V.11.21 والإصدارات الأحدث. يوفر هذا الإصدار أو الإصدارات الأحدث من Commvault دعم لقطات ملفات Azure NetApp. توفر المقالة Commvault IntelliSnap 11.21 مزيداً من المعلومات.

قم بعمل نسخة احتياطية من اللقطة باستخدام تخزين Azure blob

يعد النسخ الاحتياطي إلى تخزين Azure blob طريقة فعالة من حيث التكلفة وسريعة لحفظ النسخ الاحتياطية للقطات تخزين قاعدة بيانات HANA المستندة إلى ANF. لحفظ اللقطات في وحدة تخزين Azure Blob، يفضل استخدام أداة AzCopy. قم بتنزيل أحدث إصدار من هذه الأداة وتثبيته، على سبيل المثال، في دليل bin حيث يتم تثبيت البرنامج النصي Python من GitHub. قم بتنزيل أحدث أداة AzCopy:

root # wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Saving to: ‘azcopy_v10.tar.gz’

الميزة الأكثر تقدما هي خيار SYNC. إذا كنت تستخدم الخيار SYNC، فإن azcopy يحافظ على مزامنة المصدر والدليل الوجهة. استخدام المعلمة --delete-destination مهم. بدون هذه المعلمة، لا يقوم azcopy بحذف الملفات في الموقع الوجهة وسيزداد استخدام المساحة على جانب الوجهة. قم بإنشاء حاوية حظر Blob في حساب تخزين Azure الخاص بك. ثم قم بإنشاء مفتاح SAS لحاوية blob ومزامنة مجلد اللقطة مع حاوية Azure Blob.

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

root # > azcopy sync '/hana/data/SID/mnt00001/.snapshot' 'https://azacsnaptmytestblob01.blob.core.windows.net/abc?sv=2021-02-02&ss=bfqt&srt=sco&sp=rwdlacup&se=2021-02-04T08:25:26Z&st=2021-02-04T00:25:26Z&spr=https&sig=abcdefghijklmnopqrstuvwxyz' --recursive=true --delete-destination=true

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

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