مشاركة عبر

تكوينات البنية التحتية SAP HANA والعمليات على Azure

  • مقالة

يوفر هذا المستند إرشادات لتكوين البنية الأساسية لـ Azure وتشغيل أنظمة SAP Hana التي يتم توزيعها على الأجهزة الظاهرية الأصلية لـ Azure (VMs). يتضمن المستند أيضاً معلومات التكوين لتوسيع SAP Hana لوحدة SKU الخاصة بجهاز ظاهري M128s. ليس الهدف أن يحل هذا المستند محل وثائق SAP القياسية، والتي تتضمن المحتوى التالي:

المتطلبات الأساسية

لاستخدام هذا الدليل، تحتاج إلى معرفة أساسية بمكونات Azure التالية:

لمعرفة المزيد حول SAP NetWeaver ومكونات SAP الأخرى على Azure، راجع قسم SAP على Azure في وثائق Azure.

اعتبارات الإعداد الأساسية

تصف الأقسام التالية اعتبارات الإعداد الأساسية لتوزيع أنظمة SAP Hana على أجهزة Azure الظاهرية.

الاتصال بأجهزة Azure الظاهرية

كما هو موثق في دليل تخطيط الأجهزة الظاهرية في Azure، هناك ثلاث طرق أساسية للاتصال بالأجهزة الظاهرية لـ Azure هي:

  • الاتصال عبر الإنترنت ونقاط النهاية العامة على جهاز Jump الظاهري أو على الجهاز الظاهري الذي يشغّل SAP Hana.
  • الاتصال من خلال VPN أو Azure ExpressRoute.

الاتصال من موقع إلى موقع عبر VPN أو ExpressRoute ضروري لسيناريوهات الإنتاج. هذا النوع من الاتصال مطلوب أيضًا لسيناريوهات غير الإنتاج التي تغذي سيناريوهات الإنتاج حيث يتم استخدام برامج SAP. تعرض الصورة التالية مثالاً على الاتصالية عبر المواقع:

الاتصالية عبر المواقع

اختر أنواع أجهزة Azure الظاهرية

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

إشعار

بالنسبة للسيناريوهات غير المتعلقة بالإنتاج، استخدم أنواع الأجهزة الظاهرية المسردة في SAP note رقم 1928533. لاستخدام أجهزة Azure الظاهرية لسيناريوهات الإنتاج، تحقق من الأجهزة الظاهرية المعتمدة من SAP HANA في قائمة الأنظمة الأساسية لـ IaaS المعتمدة المنشورة.

وزِّع الأجهزة الظاهرية في Azure باستخدام:

  • مدخل Microsoft Azure.
  • الأوامر Azure PowerShell cmdlets.
  • واجهة سطر الأوامر Azure CLI.

يمكنك أيضاً توزيع نظام SAP Hana الأساسي المثبت بالكامل على خدمات أجهزة Azure الظاهرية من خلال النظام الأساسي السحابي SAP . يتم وصف عملية التثبيت في نشر SAP S/4HANA أو BW/4HANA على Azure.

هام

من أجل استخدام الأجهزة الظاهرية M208xx_v2، يجب أن تكون حذراً في اختيار صورة Linux خاصتك. لمزيد من المعلومات، راجع أحجام الأجهزة الظاهرية المُحسَّنة للذاكرة.

تكوين التخزين لـ SAP Hana

للحصول على تكوينات التخزين وأنواع التخزين التي سيتم استخدامها مع SAP Hana في Azure، اقرأ المستند تكوينات تخزين الجهاز الظاهري SAP HANA Azure

إعداد شبكة Azure الظاهرية

عندما يكون لديك اتصال من موقع إلى موقع في Azure عبر VPN أو ExpressRoute، يجب أن يكون لديك شبكة Azure ظاهرية واحدة على الأقل متصلة عبر بوابة ظاهرية إلى بوابة VPN أو دائرة ExpressRoute. في عمليات التوزيع البسيطة، يمكن توزيع البوابة الظاهرية في شبكة فرعية من شبكة Azure الظاهرية (VNet) التي تستضيف مثيلات SAP HANA أيضاً. لتثبيت SAP HANA، يمكنك إنشاء شبكتين فرعيتين إضافيتين داخل شبكة Azure الظاهرية. تستضيف شبكة فرعية واحدة الأجهزة الظاهرية لتشغيل مثيلات SAP Hana. تشغل الشبكة الفرعية الأخرى الأجهزة الظاهرية الخاصة بصندوق الانتقال أو الإدارة لاستضافة SAP HANA Studio أو برامج الإدارة الأخرى أو برنامج التطبيق خاصتك.

هام

بعيداً عن الوظائف، ولكن الأهم من أسباب الأداء، لا يتم دعم تكوين الأجهزة الظاهرية لشبكة Azure في مسار الاتصال بين تطبيق SAP وطبقة DBMS فيSAP NetWeaver أو Hybris أو نظام SAP القائم على S/4HANA. يجب أن يكون الاتصال بين طبقة تطبيق SAP وطبقة DBMS مساراً مباشراً. لا يتضمن القيد قواعد Azure ASG وNSG طالما أن قواعد ASG وNSG هذه تسمح بالاتصال المباشر. تُوجد سيناريوهات أخرى حيث لا يتم دعم الأجهزة الظاهرية للشبكة (NVAs) في مسارات الاتصال بين أجهزة Azure الظاهرية التي تمثل عُقد نظام المجموعة الخاص بالجهاز المنظم الذي يعمل بنظام التشغيل Linux وأجهزة SBD كما هو موضح في قابلية وصول عالية لـ SAP NetWeaver على أجهزة Azure الظاهرية على SUSE Linux Enterprise Server لتطبيقات SAP. أو في مسارات الاتصال بين أجهزة Azure الظاهرية أو إعداد Windows Server SOFS كما هو موضح في تجميع مثيل SAP ASCS/SCS على نظام مجموعة تجاوز فشل Windows باستخدام مشاركة ملف في Azure. يمكن أن تضاعف الأجهزة الظاهرية للشبكة (NVAs) في مسارات الاتصال بسهولة زمن انتقال الشبكة بين شريكي اتصال، ويمكن أن تقيد معدل النقل في المسارات الحرجة بين طبقة تطبيق SAP وطبقة DBMS. في بعض السيناريوهات التي تمت ملاحظتها مع العملاء، يمكن أن تتسبب الأجهزة الظاهرية للشبكة (NVAs) في فشل نُظم المجموعات الخاصة بالجهاز المنظم الذي يعمل بنظام التشغيل Linux في الحالات التي تحتاج فيها الاتصالات بين عقد نظام مجموعة الجهاز المنظم إلى الاتصال بجهاز SBD من خلال الجهاز الظاهري للشبكة (NVA).

هام

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

إذا قمت بنشر Jumpbox أو إدارة الأجهزة الظاهرية في شبكة فرعية منفصلة، يمكنك تعريف بطاقات واجهة شبكة ظاهرية متعددة (vNICs) للجهاز الظاهري HANA، مع تعيين كل vNIC إلى شبكة فرعية مختلفة. مع القدرة على الحصول على vNICs متعددة، يمكنك إعداد فصل نسبة استخدام الشبكة، إذا لزم الأمر. على سبيل المثال، يمكن توجيه حركة مرور العميل من خلال vNIC الأساسي ويتم توجيه حركة مرور المسؤول من خلال vNIC ثانية.
يمكنك أيضا تعيين عناوين IP خاصة ثابتة يتم نشرها لكل من بطاقات NIC الظاهرية.

إشعار

يجب عليك تعيين عناوين IP ثابتة من خلال وسائل Azure إلى بطاقات vNIC الفردية. يجب عدم تعيين عناوين IP ثابتة داخل نظام التشغيل الضيف إلى بطاقة واجهة الشبكة الظاهرية. تعتمد بعض خدمات Azure مثل Azure Backup Service على حقيقة أنه تم تعيين البطاقة vNIC الأساسية على الأقل إلى DHCP وليس إلى عناوين IP الثابتة. راجع أيضا المستند استكشاف أخطاء النسخ الاحتياطي للجهاز الظاهري Azure وإصلاحها. إذا كنت بحاجة إلى تعيين عناوين IP ثابتة متعددة إلى جهاز ظاهري، فأنت بحاجة إلى تعيين عناوين بطاقات vNIC متعددة إلى جهاز ظاهري.

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

توفر المقالات Azure Virtual Datacenter: A Network Perspective و Azure Virtual Datacenter وEnterprise Control Plane مزيداً من المعلومات عن نهج مركز البيانات الظاهري وتصميم شبكة Azure الظاهرية ذات الصلة.

إشعار

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

للحصول على نظرة عامة حول الأساليب المختلفة لتعيين عناوين IP، راجع أنواع عناوين IP وأساليب التخصيص في Azure.

بالنسبة للأجهزة الظاهرية التي تشغِّل SAP Hana، يجب أن تعمل مع عناوين IP الثابتة المعينة. السبب هو أن بعض سمات التكوين لـ HANA تشير إلى عناوين IP.

مجموعات أمان شبكة Azure تُستخدم لتوجيه نسبة استخدام الشبكة التي يتم توجيهها إلى مثيل SAP Hana أو مربع التنقل. ترتبط مجموعات أمان الشبكة (NSGs) ومجموعات أمان التطبيقات في نهاية المطاف بالشبكة الفرعية SAP Hana والشبكة الفرعية للإدارة.

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

مخطط توزيع تقريبي لـ SAP HANA بدون اتصال من موقع إلى موقع

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

خيارات مصدر الساعة في أجهزة Azure الظاهرية

يتطلب SAP HANA معلومات توقيت موثوقة ودقيقة لأداء الأداء الأمثل. تستخدم أجهزة Azure الظاهرية التي تعمل على Azure hypervisor صفحة Hyper-V TSC فقط كمصدر ساعة افتراضي. جعلت التطورات التكنولوجية في الأجهزة ونظام التشغيل المضيف ونظام التشغيل الضيف Linux نواة نظام التشغيل الضيف من الممكن توفير "TSC غير المتباين" كخيار مصدر للساعة على بعض وحدات SKU الخاصة ب Azure VM.

يتم دعم صفحة Hyper-V TSC (hyperv_clocksource_tsc_page) على جميع أجهزة Azure الظاهرية كمصدر للساعة. إذا كانت الأجهزة الأساسية وhypervisor و guest OS linux kernel تدعم Invariant TSC، tsc تقديمها كمصدر ساعة متوفر ومدعم في نظام التشغيل الضيف على أجهزة Azure الظاهرية.

تكوين البنية الأساسية لتوسيع Azure SAP Hana

لمعرفة أنواع أجهزة Azure الظاهرية المعتمدة إما لتوسيع نطاق OLAP أو توسيع نطاق S/4HANA، راجع دليل الأجهزة SAP Hana. تشير علامة الاختيار في العمود "تكوين أنظمة المجموعات" إلى دعم التوسع. يشير نوع التطبيق إلى ما إذا كان توسيع نطاق OLAP أو مقياس S/4HANA مدعوماً. للحصول على تفاصيل حول العقد المعتمدة في البنية الموسّعة، راجع الإدخال الخاص بـ SKU لجهاز ظاهري محدد ضمن دليل أجهزة SAP HANA.

الحد الأدنى من إصدارات نظام التشغيل لتوزيع تكوينات التوسع في أجهزة Azure الظاهرية، تحقق من تفاصيل الإدخالات في وحدة SKU الخاصة بالجهاز الظاهري المدرجة في دليل الأجهزة SAP Hana. للتكوين الموسّع لـ n-node OLAP، تعمل عقدة واحدة كعقدة رئيسية. تعمل العُقد الأخرى حتى حد الشهادة كعُقدة عاملة. لا تُحتسب العُقد الاحتياطية الإضافية ضمن العُقد المعتمدة

إشعار

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

بالنسبة إلى /hana/shared، نوصي باستخدام Azure NetApp Files أو Azure Files.

يبدو التصميم الأساسي النموذجي لعقدة واحدة في تكوين توسيع النطاق، مع /hana/shared نشره على Azure NetApp Files، كما يلي:

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

يبدو التكوين الأساسي لعقدة جهاز ظاهري لتوسيع SAP Hana كما يلي:

  • بالنسبة إلى /hana/shared، يمكنك استخدام خدمة NFS الأصلية المتوفرة من خلال Azure NetApp Files أو Azure Files.
  • جميع وحدات تخزين الأقراص الأخرى غير مشتركة عبر العقد المختلفة ولا تستند إلى NFS. يتم توفير تكوينات التثبيت والخطوات الخاصة بتوسيع نطاق عمليات تثبيت HANA باستخدام /hana/data و /hana/log غير المشتركة لاحقاً في هذا المستند. بالنسبة إلى وحدات التخزين المعتمدة من HANA التي يمكن استخدامها، راجع المقالة تكوينات وحدة تخزين الجهاز الظاهري SAP HANA Azure.

عند تحجيم وحدات التخزين أو الأقراص، تحتاج إلى التحقق من المستند متطلبات تخزين SAP HANA TDI، لمعرفة الحجم المطلوب اعتماداً على عدد العُقد العاملة. يصدر المستند صيغة تحتاج إلى تطبيقها للحصول على السعة المطلوبة لوحدة التخزين

معايير التصميم الأخرى التي يتم عرضها في رسومات تكوين العُقدة المفردة لتوسيع حجم جهاز ظاهري من SAP Hana هي شبكة ظاهرية، أو بالأحرى تكوين الشبكة الفرعية. توصي SAP بشدة بفصل العميل أو التطبيق الذي يواجه مشكلة من الاتصالات بين عُقد HANA. كما هو موضح في الرسومات، يتم تحقيق هذا الهدف من خلال وجود بطاقتي vNIC مختلفتين مرفقتين بالجهاز الظاهري. كلا بطاقتي vNIC في شبكات فرعية مختلفة ولها عناوين IP مختلفة. ثم يمكنك التحكم في تدفق نسبة استخدام الشبكة باستخدام قواعد التحويل باستخدام مجموعات أمان الشبكة أو المسارات التي يحددها المستخدم.

خاصة في Azure، لا تُوجد وسائل وأساليب لفرض جودة الخدمة والحصص على شبكات vNIC محددة. ونتيجة لذلك، لا يتيح فصل واجهة التطبيق/العميل والاتصال داخل العقدة أي فرصة لإعطاء الأولوية لدفق واحد لنسبة استخدام الشبكة على الآخر. وبدلاً من ذلك، يشكل الفصل مقياساً للأمن في حماية الاتصالات داخل العقدة لتكوينات التوسيع.

إشعار

توصي SAP بفصل نسبة استخدام الشبكة إلى جانب العميل/التطبيق وحركة المرور داخل العُقدة كما هو موضح في هذا المستند. لذلك يُوصى بوضع تصميم في مكانه كما هو موضح في الرسومات البيانية الأخيرة. استشِر أيضاً فريق الأمان والامتثال لديك لمعرفة المتطلبات التي تنحرف عن التوصية

من وجهة نظر الشبكات، سيبدو الحد الأدنى المطلوب لتصميم الشبكة كما يلي:

أساسيات توسيع عقدة واحدة

تثبيت توسيع حجم SAP HANA في Azure

عند تثبيت تكوين توسيع SAP، تحتاج إلى تنفيذ خطوات تقريبية من:

  • توزيع بنية أساسية لشبكة Azure ظاهرية جديدة أو تكييفها
  • توزيع الأجهزة الظاهرية الجديدة باستخدام Azure Managed Premium Storage ووحدات تخزين Ultra على القرص ووحدات تخزين NFS استناداً إلى ANF
    • ضبط توجيه الشبكة للتأكد من أنه، على سبيل المثال، لا يتم توجيه الاتصال داخل العقدة بين الأجهزة الظاهرية من خلال NVA.
  • تثبيت عُقدة SAP Hana الرئيسية.
  • تكييف معلمات التكوين لعُقدة SAP Hana الرئيسية
  • استمر في تثبيت عُقد SAP HANA العاملة

تثبيت SAP Hana في تكوين التوسيع

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

  • تثبيت عقدة SAP HANA الرئيسية وفقاً لوثائق SAP
  • عند استخدام Azure Premium Storage أو Ultra disk storage مع الأقراص غير المشتركة لـ /hana/data و/hana/log، يمكنك إضافة المعلّمة basepath_shared = no إلى ملف global.ini. تمكّن هذه المعلمة تشغيل SAP HANA في البنية الموسّعة دون وحدات تخزين /hana/data و/hana/log المشتركة بين العقد. يتم توثيق التفاصيل في SAP Note رقم 2080991. إذا كنت تستخدم وحدات تخزين NFS استناداً إلى ANF لـ /hana/data و/hana/log، فلن تحتاج إلى إجراء هذا التغيير
  • بعد التغيير النهائي في المعلمة global.ini، أعِد تشغيل مثيل SAP Hana
  • إضافة عُقد العوامل. لمزيد من المعلومات، راجع Add Hosts Using the Command-Line Interface. حدد الشبكة الداخلية لاتصال SAP HANA داخل العُقد أثناء التثبيت أو بعد ذلك باستخدام hdblcm المحلي على سبيل المثال. لمزيد من الوثائق التفصيلية، راجع SAP Note #2183363.

لإعداد نظام توسيع SAP HANA باستخدام عقدة في وضع الاستعداد، راجع إرشادات توزيع SUSE Linux أو إرشادات توزيع Red Hat.

SAP Hana Dynamic Tiering 2.0 لأجهزة Azure الظاهرية

بجانب شهادات SAP HANA على أجهزة Azure الظاهرية من السلسلة M، يتوفر الدعم لـ SAP HANA Dynamic Tiering 2.0 أيضاً على Microsoft Azure. لمزيد من المعلومات، راجع الارتباطات إلى وثائق DT 2.0. لا يوجد فرق بين تثبيت المنتج أو تشغيله. على سبيل المثال، يمكنك تثبيت SAP HANA Cockpit على جهاز Azure ظاهري. مع ذلك، هناك بعض المتطلبات الإلزامية، كما هو موضح في المقطع التالي، للدعم الرسمي على Azure. في جميع أنحاء المقالة، سيتم استخدام الاختصار "DT 2.0" بدلاً من الاسم الكامل Dynamic Tiering 2.0.

SAP HANA Dynamic Tiering 2.0 غير مدعوم من SAP BW أو S4HANA. حالات الاستخدام الرئيسية في الوقت الحالي هي تطبيقات HANA الأصلية.

نظرة عامة

تقدم الصورة أدناه نظرة عامة عن دعم DT 2.0 على Microsoft Azure. هناك مجموعة من المتطلبات الإلزامية والتي يجب اتباعها للامتثال للشهادة الرسمية:

  • يجب تثبيت DT 2.0 على جهاز ظاهري مخصص من Azure. قد لا يعمل على نفس الجهاز الظاهري بموضع تشغيل SAP HANA
  • يجب توزيع الأجهزة الظاهرية لدى SAP HANA وDT 2.0 داخل نفس Vnet Azure
  • يجب توزيع الأجهزة الظاهرية لدى SAP HANA وDT 2.0 مع تمكين الشبكات المسرعة لـ Azure
  • يجب أن يكون نوع التخزين للأجهزة الظاهرية لدى DT 2.0 "Azure Premium Storage"
  • يجب إرفاق أقراص Azure متعددة إلى الجهاز الظاهري DT 2.0
  • يلزم إنشاء غارة برمجية/ وحدة تخزين مخططة (إما عبر lvm أو mdadm) باستخدام الشريطية عبر أقراص Azure

سيتم شرح المزيد من التفاصيل في الأقسام التالية.

نظرة عامة على تصميم SAP HANA DT 2.0

جهاز Azure ظاهري مخصص لـ SAP HANA DT 2.0

على Azure IaaS، يتم دعم DT 2.0 فقط على جهاز ظاهري مخصص. لا يُسمح بتشغيل DT 2.0 على نفس جهاز Azure الظاهري حيث يتم تشغيل مثيل HANA. في البداية، يمكن استخدام نوعين من الأجهزة الظاهرية لتشغيل SAP Hana DT 2.0:

  • M64-32ms
  • E32sv3

لمزيد من المعلومات عن وصف نوع الجهاز الظاهري، راجع أحجام جهاز Azure الظاهري - الذاكرة

بالنظر إلى الفكرة الأساسية لـ DT 2.0، والتي تدور حول تفريغ البيانات "الدافئة" من أجل توفير التكاليف، فمن المنطقي استخدام أحجام الجهاز الظاهري المقابلة. مع ذلك، لا توجد قاعدة محددة فيما يتعلق بالتركيبات الممكنة. يعتمد ذلك على حمل عمل العميل المحدد.

التكوينات الموصى بها ستكون:

نوع جهاز ظاهري من SAP HANA نوع جهاز ظاهري من DT 2.0
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

يمكن الحصول على جميع مجموعات الأجهزة الظاهرية من الفئة M المعتمدة من SAP Hana مع أجهزة DT 2.0 الظاهرية المدعومة (M64-32ms وE32sv3).

شبكات Azure وSAP Hana DT 2.0

يتطلب تثبيت DT 2.0 على جهاز ظاهري مخصص معدل نقل للشبكة بين الجهاز الظاهري DT 2.0 والجهاز الظاهري SAP HANA بـ 10 جيجابايت الحد الأدنى. لذلك، من الإلزامي وضع جميع الأجهزة الظاهرية داخل شبكة Azure الظاهرية وتمكين الشبكات المُسرّعة من Azure.

راجع معلومات إضافية عن الشبكات المُسرّعة من Azure إنشاء جهاز Azure ظاهري باستخدام الشبكات المُسرّعة باستخدام Azure CLI

تخزين جهاز ظاهري لـ SAP Hana DT 2.0

وفقًا لإرشادات أفضل ممارسة DT 2.0 يجب أن يكون معدل نقل القرص بحد أدنى 50 ميغابايت\ثانية لكل ذاكرة أساسية لفعلية.

بالنظر إلى المواصفات الخاصة بنوعي أجهزة Azure الظاهرية، والمدعمين لـ DT 2.0، يبدو الحد الأقصى لمعدل نقل إدخال/إخراج القرص للجهاز الظاهري كما يلي:

  • E32sv3 : 768 ميجابايت/ثانية (غير مخزنة مؤقتاً)، ما يساوي النسبة 48 ميجابايت/ثانية لكل ذاكرة أساسية فعلية
  • M64-32ms: 1000 ميجابايت/ثانية (غير مخزنة مؤقتاً)؛ ما يساوي النسبة 62.5 ميجابايت/ثانية لكل ذاكرة أساسية فعلية

يلزم إرفاق أقراص Azure متعددة بجهاز DT 2.0 ظاهري وإنشاء صفيف متكرر للأقراص المستقلة (RAID) للبرامج (موزعة) على مستوى نظام التشغيل للوصول إلى أقصى معدل نقل للأقراص لكل جهاز ظاهري. لا يمكن لقرص Azure الواحد تحقيق معدل النقل اللازم للوصول إلى الحد الأقصى للجهاز الظاهري في هذا الصدد. يعد تخزين Azure Premium إلزامياً لتشغيل DT 2.0.

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

VM SKU تكوين القرص 1 تكوين القرص 2 تكوين القرص 3 تكوين القرص 4 تكوين القرص 5
M64-32ms 4 × P50 - >؛ 16 تيرابايت 4 × P40 -> ؛ 8 تيرابايت 5 × P30 -> ؛ 5 تيرابايت 7 × P20 -> ؛ 3.5 تيرابايت 8 × P15 - >؛ 2 تيرابايت
E32sv3 3 × P50 - >؛ 12 تيرابايت 3 × P40 - >؛ 6 تيرابايت 4 × P30 - >؛ 4تيرابايت 5 × P20 - >؛ 2.5 تيرابايت 6 × P15 - >؛ 1.5 تيرابايت

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

فيما يتعلق بحجم وحدة تخزين السجل، فإن نقطة البداية المُوصى بها هي استدلال بنسبة 15٪ من حجم البيانات. يمكن إنجاز إنشاء وحدة تخزين السجل باستخدام أنواع مختلفة من أقراص Azure استنادًا إلى متطلبات معدل النقل والتكلفة. بالنسبة لوحدة تخزين السجل، يلزم وجود معدل نقل إدخال/إخراج مرتفع.

في حالة استخدام جهاز ظاهري من النوع M64-32ms، يلزم تمكين مسرع الكتابة. يوفر Azure Write Accelerator زمن انتقال كتابة القرص الأمثل لسجل المعاملات (متوفر فقط للسلسلة M). هناك بعض العناصر التي يجب مراعاتها مثل الحد الأقصى لعدد الأقراص لكل نوع جهاز ظاهري. يمكن العثور على تفاصيل عن Write Accelerator في صفحة Azure Write Accelerator

فيما يلي بعض الأمثلة حول تغيير حجم السجل:

حجم وحدة تخزين البيانات ونوع القرص وحدة تخزين السجل ونوع القرص التكوين 1 وحدة تخزين السجل ونوع القرص التكوين 2
4 × P50 - >؛ 16 تيرابايت 5 × P20 - >؛ 2.5 تيرابايت 3 x P30 -> 3 تيرابايت
6 × P15 - >؛ 1.5 تيرابايت 4 x P6 -> 256 غيغابايت 1 x P15 -> 256 غيغابايت

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

عمليات توزيع SAP HANA على أجهزة Azure الظاهرية

تصف الأقسام التالية بعض العمليات المتعلقة بتوزيع أنظمة SAP Hana على أجهزة Azure الظاهرية.

إجراء عمليات النسخ الاحتياطي والاستعادة على أجهزة Azure الظاهرية

توضح المستندات التالية كيفية عمل نسخ احتياطي من توزيع SAP Hana واستعادتها:

ابدأ تشغيل الأجهزة الظاهرية التي تحتوي على SAP Hana وأعِد تشغيلها

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

استخدم SAProuter لدعم SAP عن بُعد

إذا كان لديك اتصال من موقع إلى موقع بين المواقع المحلية خاصتك وAzure، وكنت تشغُّل مكونات SAP، فمن المحتمل أن تشغِّل SAProuter بالفعل. في هذه الحالة، أكمِل العناصر التالية للدعم عن بُعد:

  • احتفظ بعنوان IP الخاص والثابت للجهاز الظاهري الذي يستضيف SAP HANA في تكوين SAProuter.
  • كوِّن مجموعة أمان الشبكة للشبكة الفرعية التي تستضيف جهاز ظاهري من HANA للسماح بنسبة استخدام الشبكة عبر منفذ TCP/IP 3299.

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

مخطط نشر تقريبي لـ SAP HANA دون اتصال من موقع إلى موقع وSAProuter

تأكد من تثبيت SAProuter في جهاز افتراضي منفصل وليس في الجهاز الافتراضي Jumpbox. يجب أن يكون للجهاز الظاهري المنفصل عنوان IP ثابت. لتوصيل SAProuter بـ SAProuter الذي يستضيفه SAP، اتصل بـ SAP للحصول على عنوان IP. (SAProuter الذي يستضيفه SAP هو نظير مثيل SAProuter الذي تقوم بتثبيته على الجهاز الظاهري) استخدم عنوان IP من SAP لتكوين مثيل SAProuter. في إعدادات التكوين، المنفذ الضروري الوحيد هو منفذ TCP 3299.

لمزيد من المعلومات حول كيفية إعداد اتصالات الدعم البعيد وصيانتها من خلال SAProuter، راجع وثائق SAP.

قابلية وصول عالية مع SAP HANA على أجهزة Azure الظاهرية الأصلية

إذا كنت تستخدم SUSE Linux Enterprise Server أو Red Hat، فيمكنك إنشاء نظام مجموعة الجهاز المنظم باستخدام أجهزة التسييج. يمكنك استخدام الأجهزة لإعداد تكوين SAP HANA الذي يستخدم النسخ المتماثل المتزامن مع النسخ المتماثل لنظام HANA وتجاوز الفشل التلقائي. لمزيد من المعلومات المُدرجة في قسم "الخطوات التالية".

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

تعرف على المقالات كما هي مدرجة