SAP S/4HANA في Linux على Azure

يقدم هذا الدليل مجموعة من الممارسات المثبتة لتشغيل S/4HANA و Suite على HANA في بيئة توفر عالية تدعم التعافي من الكوارث (DR) على Azure. تطبق معلومات Fiori فقط على تطبيقات S/4HANA.

بناء الأنظمة

قم بتنزيل ملف Visio لهذه البنية.

يصف هذا الدليل نظام إنتاج شائع. يتم نشر هذه البنية مع أحجام الجهاز الظاهري (VM) التي يمكنك تغييرها لتلبية احتياجات مؤسستك. لتناسب احتياجات عملك، يمكنك تقليل هذا التكوين إلى جهاز ظاهري واحد.

في هذا الدليل، يتم تبسيط تخطيط الشبكة بشكل كبير لإظهار المبادئ المعمارية. لا يقصد به وصف شبكة مؤسسة كاملة.

تستخدم البنية المكونات التالية. بعض الخدمات المشتركة اختيارية.

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

تناظر الشبكة الظاهرية. تستخدم هذه البنية شبكات ظاهرية متعددة تتداخل معًا. يوفر هذا المخطط تجزئة الشبكة وعزلها للخدمات التي يتم نشرها على Azure. يربط التناظر الشبكات بشفافية من خلال شبكة Microsoft الأساسية ولا تتحمل عقوبة الأداء إذا تم تنفيذها داخل منطقة واحدة. يتم استخدام شبكات فرعية منفصلة لكل تطبيق من تطبيقات الطبقة (SAP NetWeaver) وقاعدة البيانات والخدمات المشتركة، مثل مربع الانتقال السريع وWindows Server Active Directory.

أجهزة ظاهرية. تستخدم هذه البنية الأجهزة الظاهرية التي تقوم بتشغيل Linux لطبقة التطبيق وطبقة قاعدة البيانات، مجمعة بالطريقة التالية:

• طبقة التطبيق. تتضمن هذه الطبقة المعمارية تجمع خادم الواجهة الأمامية Fiori، وتجمع SAP Web Dispatcher، وتجمع خادم التطبيق، ومجموعة SAP Central Services. للحصول على قابلية وصول عالية للخدمات المركزية على Azure التي تعمل في أجهزة Linux الظاهرية، يلزم توفر خدمة مشاركة ملف شبكة اتصال عالية التوفر، مثل مشاركات ملفات NFS في ملفات Azure أو ملفات Azure NetApp أو خوادم نظام ملفات الشبكة المجمعة (NFS) أو SIOS Protection Suite لنظام Linux. لإعداد مشاركة ملف متوفرة بشكل كبير لمجموعة Central Services على Red Hat Enterprise Linux (RHEL)، يمكنك تكوين GlusterFS على أجهزة Azure الظاهرية التي تقوم بتشغيل RHEL. على SUSE Linux Enterprise Server (SLES) 15 SP1 والإصدارات الأحدث أو SLES لتطبيقات SAP، يمكنك استخدام أقراص Azure المشتركة على مجموعة Pacemaker لتحقيق قابلية وصول عالية.

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

  • تكوين عقد الاستعداد HANA باستخدام Azure NetApp Files دون مكون تكوين أنظمة المجموعات Linux.
  • توسيع النطاق دون عقد الاستعداد باستخدام تخزين Azure المتميز. استخدم نظام مجموعات Linux لتجاوز الفشل.

• Azure Bastion. تتيح لك هذه الخدمة الاتصال بجهاز ظاهري باستخدام المستعرض ومدخل Azure، أو عبر عميل SSH أو RDP الأصلي المثبت بالفعل على الكمبيوتر المحلي. إذا تم استخدام RDP وSSH فقط للإدارة، فإن Azure Bastion هو حل رائع. إذا كنت تستخدم أدوات إدارة أخرى، مثل SQL Server Management Studio أو واجهة SAP الأمامية، فاستخدم مربع انتقال تقليدي ذاتي النشر.

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

موازنة التحمل. لتوزيع نسبة استخدام الشبكة على الأجهزة الظاهرية في الشبكة الفرعية لطبقة تطبيق SAP لقابلية الوصول العالية، نوصي باستخدام Azure Standard Load Balancer. لاحظ أن Standard Load Balancer يوفر طبقة من الأمان بشكل افتراضي. لا تحتوي الأجهزة الظاهرية الموجودة خلف موازن التحميل القياسي على اتصال بالإنترنت الصادر. لتمكين الإنترنت الصادر على الأجهزة الظاهرية، تحتاج إلى تحديث تكوين موازن التحميل القياسي. يمكنك أيضا استخدام Azure NAT Gateway للحصول على اتصال صادر. للحصول على قابلية وصول عالية للتطبيق المستند إلى ويب SAP، استخدم SAP Web Dispatcher المضمن، أو موازن تحميل آخر متوفر تجاريا. قم بالاستناد إلى التحديد الخاص بك على:

• نوع نسبة استخدام الشبكة، مثل HTTP أو SAP GUI.
• خدمات الشبكة التي تحتاجها، مثل إنهاء طبقة مآخذ التوصيل الآمنة (SSL).

يدعم Standard Load Balancer العديد من عناوين IP الظاهرية الأمامية. يعد هذا الدعم مثاليا لتطبيقات نظام المجموعة التي تتضمن هذه المكونات:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• خادم النسخ المتماثل المدرج (ERS)

يمكن لهذين المكونين مشاركة موازن تحميل لتبسيط الحل.

يدعم موازن التحميل القياسي أيضا أنظمة مجموعات SAP للمعرف متعدد الأنظمة (SID متعدد). بمعنى آخر، يمكن لأنظمة SAP متعددة على SLES أو RHEL مشاركة بنية أساسية عالية التوفر شائعة لتقليل التكاليف. نوصي بتقييم وفورات التكلفة وتجنب وضع عدد كبير جدا من الأنظمة في مجموعة واحدة. لا يدعم Azure أكثر من خمسة SIDs لكل نظام مجموعة.

بوابة التطبيق. Azure Application Gateway هو موازن تحميل حركة مرور الويب الذي يمكنك استخدامه لإدارة نسبة استخدام الشبكة إلى تطبيقات الويب الخاصة بك. تعمل موازنات التحميل التقليدية في طبقة النقل (طبقة OSI 4 - TCP وUDP). يقومون بتوجيه نسبة استخدام الشبكة استنادا إلى عنوان IP المصدر والمنفذ إلى عنوان IP الوجهة والمنفذ. يمكن لبوابة التطبيق اتخاذ قرارات التوجيه استنادا إلى سمات إضافية لطلب HTTP، مثل مسار URI أو عناوين المضيف. يعرف هذا النوع من التوجيه بموازنة تحميل طبقة تطبيق (طبقة OSI 7). تقدم S/4HANA خدمات تطبيقات الويب من خلال Fiori. يمكنك تحميل موازنة هذه الواجهة الأمامية Fiori، والتي تتكون من تطبيقات الويب، باستخدام بوابة التطبيق.

البوابة⁧. تقوم البوابة بتوصيل الشبكات المميزة وتوسيع شبكتك المحلية إلى شبكة Azure الظاهرية. Azure ExpressRoute هي خدمة Azure الموصى بها لإنشاء اتصالات خاصة لا تنتقل عبر الإنترنت العام، ولكن يمكنك أيضا استخدام اتصال من موقع إلى موقع . لتقليل زمن الانتقال، ExpressRoute Global Reach وExpressRoute FastPath هما خيارات الاتصال التي تمت مناقشتها لاحقا في هذه المقالة.

بوابة المناطق ذات التكرار المرتفع. يمكنك نشر بوابات ExpressRoute أو الشبكة الخاصة الظاهرية (VPN) عبر المناطق للحماية من فشل المنطقة. تستخدم هذه البنية بوابات الشبكة الظاهرية المكررة في المنطقة للمرونة بدلا من توزيع نطاقي يستند إلى نفس منطقة التوفر.

مجموعة وضع القرب. تضع هذه المجموعة المنطقية قيدا على الأجهزة الظاهرية التي يتم نشرها في مجموعة توفر أو مجموعة مقياس جهاز ظاهري. تفضل مجموعة موضع التقارب الموقع المشترك، مما يضع الأجهزة الظاهرية في نفس مركز البيانات لتقليل زمن انتقال التطبيق.

مجموعات أمان الشبكة. لتقييد نسبة استخدام الشبكة الواردة والصادرة وداخل الشبكة الفرعية في شبكة ظاهرية، يمكنك إنشاء مجموعات أمان الشبكة.

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

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

التوصيات

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

أجهزة ظاهرية

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

للحصول على تفاصيل حول دعم SAP أنواع أجهزة Azure الظاهرية ومقاييس معدل النقل (SAPS)، راجع 1928533 ملاحظة SAP. للوصول إلى ملاحظات SAP، تحتاج إلى حساب SAP Service Marketplace. للحصول على قائمة ب Azure VMs المعتمدة لقاعدة بيانات HANA، راجع دليل أجهزة SAP HANA المعتمد والمعتمد.

SAP Web Dispatcher

يتم استخدام مكون Web Dispatcher لموازنة تحميل حركة مرور SAP بين خوادم تطبيق SAP. لتحقيق قابلية وصول عالية ل SAP Web Dispatcher، ينفذ Azure Load Balancer إما مجموعة تجاوز الفشل أو إعداد Web Dispatcher المتوازي. بالنسبة للاتصالات التي تواجه الإنترنت، فإن الحل المستقل في الشبكة المحيطة هو البنية الموصى بها لتلبية المخاوف الأمنية. يعد Embedded Web Dispatcher على ASCS خيارًا خاصًا. إذا كنت تستخدم هذا الخيار، ففكر في تغيير الحجم المناسب بسبب حمل العمل الإضافي على ASCS.

خادم الواجهة الأمامية Fiori (FES)

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

للحصول على وصف لخيارات النشر الأساسية - إما مضمنة أو مركزية، اعتمادا على السيناريوهات - راجع خيارات نشر SAP Fiori وتوصيات مشهد النظام. للتبسيط والأداء، يتم ربط إصدارات البرامج بين مكونات تقنية Fiori وتطبيقات S/4 بإحكام. يؤدي هذا الإعداد إلى نشر مركز يناسب عدد قليل فقط من حالات الاستخدام الضيقة.

إذا كنت تستخدم توزيع مركز FES، فإن FES مكون إضافي إلى مكدس SAP NetWeaver ABAP الكلاسيكي. قم بإعداد قابلية وصول عالية بنفس الطريقة التي تحمي بها مكدس تطبيقات ABAP ثلاثي الطبقات الذي يحتوي على إمكانية مجمعة أو متعددة المضيفين: استخدم طبقة قاعدة بيانات خادم احتياطي، وطبقة ASCS متفاوت المسافات مع NFS عالي التوفر للتخزين المشترك، وخادمين تطبيقين على الأقل. يتم موازنة تحميل نسبة استخدام الشبكة عبر زوج من مثيلات Web Dispatcher التي يمكن تجميعها أو متوازية. بالنسبة لتطبيقات Fiori التي تواجه الإنترنت، نوصي بنشر مركز FES في الشبكة المحيطة. استخدم Azure Web Application Firewall على Application Gateway كمكون مهم لتحديد التهديدات. استخدم معرف Microsoft Entra مع SAML لمصادقة المستخدم وSSO ل SAP Fiori.

للحصول على بعض أمثلة التصميم الواردة/الصادرة التي تواجه الإنترنت، راجع اتصالات الإنترنت الواردة والصادرة ل SAP على Azure.

مزرعة خوادم التطبيقات

لإدارة مجموعات تسجيل الدخول لخوادم تطبيقات ABAP، من الشائع استخدام معاملة SMLG لتحميل مستخدمي تسجيل الدخول إلى الرصيد، واستخدام SM61 لمجموعات خوادم الدفعات، واستخدام RZ12 لمجموعات استدعاء الوظائف عن بعد (RFC)، وما إلى ذلك. تستخدم هذه المعاملات إمكانية موازنة التحميل الموجودة في خادم رسائل Central Services لتوزيع الجلسات أو أحمال العمل الواردة بين مجموعة خوادم تطبيقات SAP التي تتعامل مع SAP GUIs وحركة مرور RFC.

نظام مجموعة SAP Central Services.

يمكنك نشر Central Services على جهاز ظاهري واحد عندما تفي اتفاقية مستوى خدمة توفر الجهاز الظاهري (SLA) ل Azure بمتطلباتك. ومع ذلك، يصبح الجهاز الظاهري نقطة فشل واحدة محتملة (SPOF) لبيئة SAP. لنشر خدمات مركزية متوفرة بشكل كبير، استخدم إما NFS عبر Azure Files أو خدمة Azure NetApp Files و مجموعة Central Services.

خيار آخر هو استخدام أقراص Azure المشتركة لتحقيق قابلية وصول عالية. على SLES 15 SP1 والإصدارات الأحدث أو SLES لتطبيقات SAP، يمكنك إعداد نظام مجموعة Pacemaker باستخدام أقراص Azure المشتركة ل Linux.

بدلا من ذلك، يمكنك استخدام مشاركة ملف NFS للتخزين المشترك لنظام مجموعة Linux.

على توزيع Azure، تتصل خوادم التطبيقات بـ Central Services ذات قابلية الوصول العالية من خلال أسماء المضيف الظاهري لـ Central Services أو خدمات ERS. يتم تعيين أسماء المضيفين هذه إلى تكوين IP نظام مجموعة الواجهة لموازن التحميل. يدعم Load Balancer العديد من عناوين IP الأمامية، بحيث يمكن تكوين كل من Central Services وERS virtual IPs (VIPs) إلى موازن تحميل واحد.

يتوفر الآن دعم نظام مجموعة Linux لتثبيت ASCS متعدد SID على Azure بشكل عام. مشاركة مجموعة قابلية وصول عالية التوفر بين أنظمة SAP متعددة يبسط مشهد SAP.

الشبكات

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

Network interface cards ‏(NICs)

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

تدعم Azure NICs العديدَ من عناوين IP. يتوافق هذا الدعم مع الممارسة التي توصي بها SAP باستخدام أسماء المضيفين الظاهرية للتثبيتات، كما هو موضح في ملاحظة SAP 962955. للوصول إلى ملاحظات SAP، تحتاج إلى حساب SAP Service Marketplace.

الشبكات الفرعية ومجموعات أمان الشبكة

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

عند إقران مجموعة أمان شبكة بشبكة فرعية، تنطبق مجموعة أمان الشبكة على جميع الخوادم داخل الشبكة الفرعية وتوفر تحكما دقيقا في الخوادم. إعداد مجموعات أمان الشبكة باستخدام مدخل Microsoft Azure أو PowerShell أو Azure CLI.

ExpressRoute Global Reach

إذا كانت بيئة الشبكة تتضمن دائرتين أو أكثر من دوائر ExpressRoute، يمكن أن يساعدك ExpressRoute Global Reach في تقليل قفزات الشبكة وتقليل زمن الانتقال. هذه التقنية هي تناظر مسار بروتوكول بوابة الحدود (BGP) الذي تم إعداده بين دائرتين أو أكثر من دوائر ExpressRoute لوصل مجالي توجيه ExpressRoute. يقلل Global Reach من زمن الانتقال عندما تعبر نسبة استخدام الشبكة أكثر من دائرة ExpressRoute واحدة. وهو متاح حاليًا فقط للتناظر الخاص على دوائر ExpressRoute.

حاليا لا توجد قوائم التحكم في الوصول إلى الشبكة أو سمات أخرى يمكن تغييرها في Global Reach. لذلك يتم الإعلان عن جميع المسارات التي تعلمتها دائرة ExpressRoute معينة (من أماكن العمل وAzure) عبر الدائرة التي تتناظر مع دائرة ExpressRoute الأخرى. نوصي بإنشاء تصفية نسبة استخدام الشبكة محليًا لتقييد الوصول إلى الموارد.

ExpressRoute FastPath

ينفذ FastPath عمليات تبادل Microsoft Edge عند نقطة إدخال شبكة Azure. يقلل FastPath من قفزات الشبكة لمعظم حزم البيانات. ونتيجة لذلك، يقلل FastPath زمن انتقال الشبكة، ويحسن أداء التطبيق، وهو التكوين الافتراضي لاتصالات ExpressRoute الجديدة ب Azure.

بالنسبة لدوائر ExpressRoute الموجودة، اتصل بدعم Azure لتنشيط FastPath.

لا يدعم FastPath تناظر الشبكة الظاهرية. إذا تم إقران الشبكات الظاهرية الأخرى بإحدى الشبكات المتصلة ب ExpressRoute، إرسال نسبة استخدام الشبكة من شبكتك المحلية إلى الشبكات الظاهرية المحورية الأخرى إلى بوابة الشبكة الظاهرية. يتمثل الحل البديل في توصيل جميع الشبكات الظاهرية بدائرة ExpressRoute مباشرة.

موازنة التحمل

يعالج SAP Web Dispatcher موازنة تحميل حركة مرور HTTP(S) إلى مجموعة من خوادم تطبيقات SAP. يوفر موازن تحميل البرامج هذا خدمات طبقة التطبيق (يشار إليها باسم الطبقة 7 في نموذج شبكة ISO) القادرة على إنهاء SSL ووظائف إلغاء التحميل الأخرى.

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

بالنسبة لنسبة استخدام الشبكة من عملاء SAP GUI الذين يتصلون بخادم SAP عبر بروتوكول DIAG أو RFC، يوازن خادم رسالة Central Services التحميل من خلال مجموعات تسجيل دخول خادم تطبيق SAP. لا يلزم وجود موازن تحميل إضافي.

التخزين

يستخدم بعض العملاء التخزين القياسي لخوادم التطبيقات لديهم. نظرا لأن الأقراص المدارة القياسية غير مدعومة، كما هو مذكور في ملاحظة SAP 1928533، نوصي باستخدام أقراص Azure المدارة المتميزة أو ملفات Azure NetApp في جميع الحالات. يستثني التحديث الأخير لملاحظة SAP 2015553 استخدام تخزين HDD القياسي وتخزين SSD القياسي لبعض حالات الاستخدام المحددة.

نظرا لأن خوادم التطبيقات لا تستضيف أي بيانات عمل، يمكنك أيضا استخدام أقراص P4 وP6 المتميزة الأصغر للمساعدة في إدارة التكاليف. لفهم كيفية تأثير نوع التخزين على اتفاقية مستوى الخدمة لتوفر الجهاز الظاهري، راجع اتفاقية مستوى الخدمة للأجهزة الظاهرية. بالنسبة للسيناريوهات عالية التوفر، تتوفر ميزات القرص المشترك ل Azure على Azure Premium SSD وAzure Ultra Disk Storage. لمزيد من المعلومات، راجع أقراص Azure المدارة.

يمكنك استخدام أقراص Azure المشتركة مع Windows Server أو SLES 15 SP 1 والإصدارات الأحدث أو SLES ل SAP. عند استخدام قرص مشترك ل Azure في مجموعات Linux، يعمل القرص المشترك Azure كجهاز كتلة STONITH (SBD). يوفر تصويت الحصة في حالة تقسيم شبكة نظام المجموعة. لا يحتوي هذا القرص المشترك على نظام ملفات ولا يدعم عمليات الكتابة المتزامنة من أجهزة ظاهرية متعددة لعضو نظام المجموعة.

تحتوي Azure NetApp Files على وظائف مشاركة الملفات المضمنة ل NFS وSMB.

بالنسبة لسيناريوهات مشاركة NFS، توفر Azure NetApp Files التوفر لمشاركات NFS التي يمكن استخدامها لوحدات /hana/data/hana/sharedالتخزين و و/hana/log. للحصول على ضمان التوفر، راجع اتفاقية مستوى الخدمة لملفات Azure NetApp. إذا كنت تستخدم مشاركات NFS المستندة إلى ملفات Azure NetApp لوحدات /hana/data التخزين و /hana/log ، فستحتاج إلى استخدام بروتوكول NFS v4.1. بالنسبة إلى /hana/shared وحدة التخزين، يتم دعم بروتوكول NFS v3.

بالنسبة إلى مخزن بيانات النسخ الاحتياطي، نوصي باستخدام Azure cool وأرشفة مستويات الوصول. مستويات التخزين هذه هي طرق فعالة من حيث التكلفة لتخزين البيانات طويلة الأمد التي يتم الوصول إليها بشكل غير متكرر. يمكنك أيضا التفكير في استخدام المستوى القياسي ل Azure NetApp Files كهدف نسخ احتياطي أو خيار النسخ الاحتياطي لملفات Azure NetApp. بالنسبة إلى القرص المدار، تكون طبقة بيانات النسخ الاحتياطي الموصى بها هي طبقة الوصول إلى Azure cool أو archive.

يقلل Ultra Disk Storage وAzure NetApp Files ultra performance tier إلى حد كبير من زمن انتقال القرص ويفيد التطبيقات المهمة للأداء وخوادم قاعدة بيانات SAP.

تم تصميم Azure Premium SSD v2 لأحمال العمل المهمة للأداء مثل SAP. راجع نشر Premium SSD v2 للحصول على معلومات حول مزايا حل التخزين هذا وقيوده الحالية.

الاعتبارات الخاصة بالأداء

تتواصل خوادم تطبيقات SAP باستمرار مع خوادم قاعدة البيانات. بالنسبة للتطبيقات الهامة للأداء التي تعمل على أي نظام أساسي لقاعدة البيانات، بما في ذلك SAP HANA، قم بتمكين Write Accelerator لوحدة تخزين السجل إذا كنت تستخدم Premium SSD v1. يمكن أن يؤدي القيام بذلك إلى تحسين زمن انتقال كتابة السجل. لا يستخدم Premium SSD v2 Write Accelerator. يتوفر Write Accelerator للأجهزة الظاهرية من سلسلة M.

لتحسين الاتصالات بين الخوادم، استخدم الشبكات المسرعة. تدعم معظم أحجام مثيل الجهاز الظاهري للأغراض العامة والمحسنة للحساب والتي تحتوي على اثنين أو أكثر من وحدات المعالجة المركزية الظاهرية الشبكات المتسارعة. في المثيلات التي تدعم hyperthreading، تدعم مثيلات الجهاز الظاهري التي تحتوي على أربعة أو أكثر من وحدات المعالجة المركزية الظاهرية الشبكات المتسارعة.

للحصول على تفاصيل حول متطلبات أداء SAP HANA، راجع ملاحظة SAP 1943937 - أداة التحقق من تكوين الأجهزة. للوصول إلى ملاحظات SAP، تحتاج إلى حساب SAP Service Marketplace.

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

تم تصميم Azure Premium SSD v2 لأحمال العمل المهمة للأداء مثل SAP. راجع أنواع الأقراص المدارة من Azure للتعرف على فوائدها وقيودها وسيناريوهات الاستخدام المثلى.

يعد Ultra Disk Storage جيلا جديدا من التخزين الذي يلبي عمليات الإدخال والإخراج في الإخراج في الملفات المكثفة وطلبات النطاق الترددي للنقل للتطبيقات مثل SAP HANA. يمكنك تغيير أداء الأقراص الفائقة ديناميكيا وتكوين مقاييس بشكل مستقل مثل IOPS وMB/s دون إعادة تشغيل الجهاز الظاهري الخاص بك. عندما يتوفر Ultra Disk Storage، نوصي ب Ultra Disk Storage بدلا من Write Accelerator.

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

موضع جهاز ظاهري للشبكة (NVA) بين التطبيق وطبقات قاعدة البيانات لأي مكدس تطبيقات SAP غير مدعوم. يتطلب NVA قدرا كبيرا من الوقت لمعالجة حزم البيانات. ونتيجة لذلك، فإنه يبطئ أداء التطبيق بطريقة غير مقبولة.

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

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

اعتبارات قابلية التوسع

في طبقة تطبيق SAP، تقدم Azure مجموعة واسعة من أحجام الأجهزة الظاهرية لتوسيع نطاقها وتوسيع نطاقها. للحصول على قائمة شاملة، راجع "تطبيقات SAP على Azure: المنتجات المدعومة وأنواع أجهزة Azure الظاهرية" في SAP Note 1928533. للوصول إلى ملاحظات SAP، تحتاج إلى حساب SAP Service Marketplace. يتم اعتماد المزيد من أنواع الأجهزة الظاهرية باستمرار، بحيث يمكنك توسيع نطاقها أو خفضها في نفس توزيع السحابة.

على طبقة قاعدة البيانات، تقوم هذه البنية بتشغيل تطبيقات SAP HANA S/4 على أجهزة Azure الظاهرية التي يمكن أن تصل إلى 24 تيرابايت (TB) في مثيل واحد. إذا تجاوز حمل العمل الحد الأقصى لحجم الجهاز الظاهري، يمكنك استخدام تكوين متعدد العقد لما يصل إلى 96 تيغابايت (4 × 24) لتطبيقات معالجة المعاملات عبر الإنترنت (OLTP). لمزيد من المعلومات، راجع دليل أجهزة SAP HANA المعتمد والمعتمد.

اعتبارات التوفر

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

في التثبيت الموزع لتطبيق SAP هذا، يتم نسخ التثبيت الأساسي لتحقيق قابلية وصول عالية. لكل طبقة من التصميم، يتنوع تصميم قابلية الوصول العالية.

نهج التوزيع

على Azure، يمكن أن يكون توزيع حمل عمل SAP إقليميا أو نطاقيا، اعتمادا على متطلبات التوفر والمرونة لتطبيقات SAP. يوفر Azure خيارات نشر مختلفة، مثل مجموعات مقياس الجهاز الظاهري مع التنسيق المرن (FD=1) ومناطق التوفر ومجموعات التوفر، لتحسين توفر الموارد. للحصول على فهم شامل لخيارات النشر المتاحة وقابليتها للتطبيق عبر مناطق Azure المختلفة (بما في ذلك عبر المناطق أو داخل منطقة واحدة أو في منطقة بدون مناطق)، راجع بنية قابلية الوصول العالية وسيناريوهات SAP NetWeaver.

Web Dispatcher في مستوى خوادم التطبيق

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

الخدمات المركزية في مستوى خوادم التطبيق

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

يدعم NFS عبر Azure Files الآن مشاركات الملفات عالية التوفر لكل من SLES و RHEL. يعمل هذا الحل بشكل جيد لمشاركات الملفات عالية التوفر مثل مشاركات /sapmnt، /saptrans في عمليات تثبيت SAP.

تدعم Azure NetApp Files قابلية وصول عالية من ASCS على SLES. للحصول على معلومات مفصلة حول ASCS حول قابلية الوصول العالية ل RHEL، راجع SIOS Protection Suite for Linux.

يتوفر عامل Azure Fence المحسن لكل من SUSE وRed Hat ويوفر تجاوز فشل خدمة أسرع بكثير من الإصدار السابق من العامل.

خيار آخر هو استخدام أقراص Azure المشتركة لتحقيق قابلية وصول عالية. على SLES 15 SP 1 والإصدارات الأحدث أو SLES ل SAP، يمكنك إعداد نظام مجموعة Pacemaker باستخدام أقراص Azure المشتركة لتحقيق قابلية وصول عالية.

في Azure Standard Load Balancer، يمكنك تمكين منفذ التوفر العالي وتجنب الحاجة إلى تكوين قواعد موازنة التحميل للعديد من منافذ SAP. بشكل عام، إذا قمت بتمكين ميزة إرجاع الخادم المباشر (DSR) عند إعداد موازن تحميل، يمكن أن تتجاوز استجابات الخادم لاستعلامات العميل موازن التحميل. تعرف هذه الميزة أيضا باسم IP العائم. يمكن أن يكون موازن التحميل محليا أو على Azure. يمنع هذا الاتصال المباشر موازن التحميل من أن يصبح ازدحامًا في مسار نقل البيانات. بالنسبة لمجموعات ASCS وHANA DB، نوصي بتمكين طلب طلب البحث. إذا كانت الأجهزة الظاهرية في التجمع الخلفي تتطلب اتصالا صادرا عاما، يلزم إجراء المزيد من التكوين .

بالنسبة لنسبة استخدام الشبكة من عملاء SAP GUI الذين يتصلون بخادم SAP عبر بروتوكول DIAG أو RFC، يوازن خادم رسالة Central Services الحمل باستخدام مجموعات تسجيل دخول خادم تطبيق SAP. لا يلزم وجود موازن تحميل إضافي.

خوادم التطبيقات في مستوى خوادم التطبيق

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

مستوى ASCS

كما هو الحال مع طبقة خوادم التطبيق، فإن حل HANA عالي التوفر المنتشر عادة لنظام التشغيل Linux هو Pacemaker.

الطبقة المسؤولة عن البيانات

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

• لتجاوز الفشل اليدوي، انشر أكثر من مثيل HANA واحد واستخدم HSR.
• لتجاوز الفشل التلقائي، استخدم كل من ملحق HSR وLinux عالي التوفر (HAE) لتوزيع Linux الخاص بك. يوفر Linux HAE خدمات نظام المجموعة لموارد HANA، واكتشاف أحداث الفشل وتنسيق تجاوز فشل الخدمات غير الصحيحة إلى العقدة السليمة.

توزيع الأجهزة الظاهرية عبر مناطق التوفر

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

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

خذ هذه الاعتبارات في الاعتبار عندما تقرر نشر الموارد عبر مناطق التوفر:

• زمن الانتقال بين الأجهزة الظاهرية في منطقة واحدة
• زمن الانتقال بين الأجهزة الظاهرية عبر المناطق المختارة
• توفر نفس خدمات Azure (أنواع الأجهزة الظاهرية) في المناطق المختارة

مثال على التوزيع النشط/ غير الفعال

في هذا المثال للنشر، تشير الحالة النشطة/السلبية إلى حالة خدمة التطبيق داخل المناطق. في طبقة التطبيق، توجد جميع خوادم التطبيقات النشطة الأربعة لنظام SAP في المنطقة 1. تم إنشاء مجموعة أخرى من أربعة خوادم تطبيقات سلبية في المنطقة 2 ولكن يتم إيقاف تشغيلها. يتم تنشيطها فقط عند الحاجة إليها.

يتم تمديد المجموعات المكونة من عقدتين للخدمات المركزية وقاعدة البيانات عبر منطقتين. إذا فشلت المنطقة 1، يتم تشغيل الخدمات المركزية وخدمات قاعدة البيانات في المنطقة 2. يتم تنشيط خوادم التطبيقات السلبية في المنطقة 2. مع وجود جميع مكونات نظام SAP هذا في نفس المنطقة، يتم تقليل زمن انتقال الشبكة.

مثال على التوزيع النشط/ النشط

في النشر النشط/النشط، يتم إنشاء مجموعتين من خوادم التطبيقات عبر منطقتين. في كل منطقة، يكون خادما تطبيق في كل مجموعة غير نشطين أو متوقفين عن التشغيل. ونتيجة لذلك، هناك خوادم تطبيقات نشطة في كلتا المنطقتين في العمليات العادية.

خدمات ASCS وقاعدة البيانات تعملان في المنطقة 1. قد يكون لخوادم التطبيقات في المنطقة 2 زمن انتقال أطول للشبكة عند الاتصال بخدمات ASCS وقاعدة البيانات بسبب المسافة الفعلية بين المناطق.

إذا كانت المنطقة 1 غير متصلة، تفشل خدمات ASCS وقاعدة البيانات إلى المنطقة 2. يمكن إحضار خوادم التطبيقات الخاملة عبر الإنترنت لتوفير القدرة الكاملة لمعالجة التطبيقات.

اعتبارات الإصلاح بعد الكوارث

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

اعتبارات التكلفة

استخدم حاسبة تسعير Azure لتقدير التكاليف.

لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.

أجهزة ظاهرية

تستخدم هذه البنية الأجهزة الظاهرية التي تقوم بتشغيل Linux للإدارة وتطبيق SAP وطبقة قاعدة البيانات.

هناك العديد من خيارات الدفع للأجهزة الظاهرية بشكل عام:

• بالنسبة لأحمال العمل التي ليس لها وقت متوقع للاكتمال أو استهلاك الموارد، ضع في اعتبارك خيار الدفع أولا بأول.

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

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

  • سيناريوهات الحوسبة عالية الأداء أو مهام معالجة الدفعات أو تطبيقات العرض المرئي
  • بيئات الاختبار، بما في ذلك التكامل المستمر وأحمال عمل التسليم المستمر
  • تطبيقات عديمة الحالة على نطاق واسع

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

للحصول على نظرة عامة على التسعير، راجع أسعار الأجهزة الظاهرية ل Linux.

موازن التحميل

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

تتم محاسبتك فقط على عدد قواعد موازنة التحميل والقواعد الصادرة التي تم تكوينها. قواعد ترجمة عناوين الشبكة الواردة (NAT) مجانية. لا توجد رسوم بالساعة لموازن التحميل القياسي عند عدم تكوين أي قواعد.

ExpressRoute

في هذه البنية، ExpressRoute هي خدمة الشبكات المستخدمة لإنشاء اتصالات خاصة بين شبكة محلية وشبكات Azure الظاهرية.

جميع عمليات نقل البيانات الواردة مجانية. يتم حساب جميع عمليات نقل البيانات الصادرة وفقا إلى سعر محدد مسبقا. لمزيد من المعلومات، راجع تسعير Azure ExpressRoute.

اعتبارات الإدارة والعمليات

للمساعدة في الحفاظ على تشغيل النظام في الإنتاج، ضع في اعتبارك النقاط التالية.

Azure Center لحلول SAP

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

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

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

إدارة الهوية

استخدم نظام إدارة هوية مركزيًا للتحكم في الوصول إلى الموارد على جميع المستويات:

• توفير الوصول إلى موارد Azure من خلال التحكم في الوصول المستند إلى الدور من Azure.

• منح حق الوصول إلى أجهزة Azure الظاهرية من خلال البروتوكول الخفيف لتغيير بيانات الدليل (LDAP) أو معرف Microsoft Entra أو Kerberos أو نظام آخر.

• دعم الوصول داخل التطبيقات نفسها من خلال الخدمات التي توفرها SAP، أو استخدام OAuth 2.0 ومعرف Microsoft Entra.

مراقبة‬

لتحقيق أقصى قدر من توفر التطبيقات والخدمات وأدائها على Azure، استخدم Azure Monitor، وهو حل شامل لجمع بيانات تتبع الاستخدام وتحليلها والعمل عليها من البيئات السحابية والبيئات المحلية. يوضح Azure Monitor كيفية أداء التطبيقات ويحدد بشكل استباقي المشكلات التي تؤثر عليها والموارد التي تعتمد عليها. بالنسبة لتطبيقات SAP التي تعمل على SAP HANA وحلول قواعد البيانات الرئيسية الأخرى، راجع Azure Monitor لحلول SAP لمعرفة كيفية مساعدة Azure Monitor ل SAP في إدارة توفر خدمات SAP وأدائها.

اعتبارات الأمان

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

لتحسين أمان الشبكة، ضع في اعتبارك استخدام شبكة محيطة تستخدم NVA لإنشاء جدار حماية أمام الشبكة الفرعية ل Web Dispatcher وتجمعات خوادم Fiori الأمامية. تكلفة نقل البيانات هي سبب لوضع خوادم الواجهة الأمامية النشطة التي تشغل تطبيقات Fiori في نفس الشبكة الظاهرية مثل أنظمة S/4. البديل هو وضعها في الشبكة المحيطة وتوصيلها ب S/4 من خلال تناظر شبكة ظاهرية.

بالنسبة إلى أمان البنية الأساسية، يتم تشفير البيانات في أثناء نقلها وثباتها. يحتوي قسم "اعتبارات الأمان" من SAP NetWeaver على Azure Virtual Machines–Planning and Implementation Guide على معلومات حول أمان الشبكة ينطبق على S/4HANA. يحدد هذا الدليل أيضا منافذ الشبكة لفتحها على جدران الحماية للسماح بالاتصال بالتطبيق.

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

بالنسبة لتشفير البيانات الثابتة ل SAP HANA، نوصي باستخدام تقنية التشفير الأصلية ل SAP HANA.

المُجتمعات

يمكن للمجتمعات الإجابة عن الأسئلة ومساعدتك في إعداد عملية توزيع ناجحة. راجع هذه الموارد:

• تشغيل تطبيقات SAP على مدونة Microsoft Platform
• Azure Community Support
• مجتمع SAP
• تجاوز مكدس الذاكرةِ المؤقتة SAP

المساهمون

تحتفظ Microsoft بهذه المقالة. تمت كتابته في الأصل من قبل المساهم التالي.

الكاتب الرئيسي:

• Ben Trinh | المهندس المعماري الرئيسي

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

لمزيد من المعلومات وعلى سبيل المثال لأحمال عمل SAP التي تستخدم بعض التقنيات نفسها مثل هذه البنية، راجع هذه المقالات:

• نشر SAP S/4HANA أو BW/4HANA على Azure
• تخطيط وتنفيذ Azure Virtual Machines لـ SAP NetWeaver
• استخدام Azure لاستضافة وتشغيل سيناريوهات أحمال أعمال SAP

الموارد ذات الصلة

• تشغيل أحمال عمل إنتاج SAP باستخدام قاعدة بيانات Oracle على Azure