مشاركة عبر

تخطيط وتنفيذ توزيع SAP على Azure

  • مقالة

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

يقدم Azure نظاما أساسيا شاملا لتشغيل تطبيقات SAP الخاصة بك. تتحد عروض البنية الأساسية كخدمة (IaaS) والنظام الأساسي كخدمة (PaaS) في Azure لمنحك الخيارات المثلى للنشر الناجح لمشهد مؤسسة SAP بأكمله.

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

التعريفات

خلال هذه المقالة، نستخدم المصطلحات التالية:

  • مكون SAP: تطبيق SAP فردي مثل SAP S/4HANA أو SAP ECC أو SAP BW أو SAP Solution Manager. يمكن أن يستند مكون SAP إلى تقنيات برمجة تطبيقات الأعمال المتقدمة (ABAP) أو Java، أو يمكن أن يكون تطبيقا لا يستند إلى SAP NetWeaver، مثل SAP BusinessObjects.
  • بيئة SAP: مكونات SAP متعددة مجمعة منطقيا لأداء وظيفة عمل، مثل التطوير أو ضمان الجودة أو التدريب أو التعافي من الكوارث أو الإنتاج.
  • مشهد SAP: المجموعة الكاملة من أصول SAP في مشهد تكنولوجيا المعلومات في المؤسسة. يتضمن المشهد SAP جميع بيئات الإنتاج وغير المنتجة.
  • نظام SAP: مزيج من طبقة نظام إدارة قاعدة البيانات (DBMS) وطبقة التطبيق. مثالان هما نظام تطوير SAP ERP ونظام اختبار SAP BW. في توزيع Azure، لا يمكن توزيع هاتين الطبقتين بين الموقع المحلي وAzure. يجب نشر نظام SAP محليا أو نشره في Azure. ومع ذلك، يمكنك تشغيل أنظمة مختلفة داخل مشهد SAP إما في Azure أو محليا.

الموارد

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

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

هام

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

تشكل ملاحظات SAP التالية قاعدة إرشادات Azure لتوزيع SAP:

رقم الملاحظة ‏‫المسمى الوظيفي
1928533 تطبيقات SAP على Azure: المنتجات المدعومة والحجم
2015553 SAP على Azure: متطلبات الدعم الأساسية
2039619 تطبيقات SAP على Azure باستخدام قاعدة بيانات Oracle
2233094 DB6: تطبيقات SAP على Azure باستخدام IBM Db2 ل Linux وUNIX وWindows
1999351 استكشاف أخطاء مراقبة Azure المحسنة لـ SAP وإصلاحها
1409604 المحاكاة الافتراضية على Windows: المراقبة المحسنة
2191498 SAP على Linux مع Azure: مراقبة محسنة
2731110 دعم الأجهزة الظاهرية للشبكة (NVA) ل SAP على Azure

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

السيناريوهات

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

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

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

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

لجمع البيانات لتخطيط النشر إلى Azure، من المهم:

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

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

الخطوات الأولى لتخطيط توزيع

الخطوة الأولى في تخطيط النشر ليست البحث عن الأجهزة الظاهرية المتوفرة لتشغيل تطبيقات SAP.

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

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

خطة للامتثال

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

الخطة المتعلقة بالأمن

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

تنظيم موارد Azure

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

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

لمساعدتك على اتخاذ القرارات الصحيحة، يتم وصف العديد من تفاصيل بنية المؤسسة في Azure Cloud Adoption Framework.

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

الخطوات التالية هي التخطيط للموضع الجغرافي وبنية الشبكة التي تقوم بنشرها في Azure.

المناطق الجغرافية والمناطق في Azure

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

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

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

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

المناطق المُقترنة في Azure

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

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

أنواع التخزين التي تدعم النسخ المتماثل لبيانات المنطقة المقترنة هي أنواع تخزين غير مناسبة لمكونات SAP وعبء عمل DBMS. تقتصر إمكانية استخدام النسخ المتماثل لتخزين Azure على Azure Blob Storage (لأغراض النسخ الاحتياطي) ومشاركات الملفات ووحدات التخزين وسيناريوهات التخزين الأخرى ذات زمن الانتقال العالي.

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

مجموعات التوافر

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

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

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

مجالات الخطأ

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

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

مجال التحديث

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

رسم تخطيطي يصور مجالات التحديث ومجالات الفشل.

مجموعات التوفر

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

لمعرفة المزيد حول مجموعات توفر Azure وكيفية ارتباط مجموعات التوفر بمجالات الخطأ، راجع مجموعات توفر Azure.

هام

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

يمكنك الجمع بين مجموعات التوفر ومناطق التوفر إذا كنت تستخدم مجموعات موضع التقارب.

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

على سبيل المثال، يمكنك إنشاء مجموعة توفر، ونشر الجهاز الظاهري الأول في مجموعة التوفر. الجهاز الظاهري الأول الذي تضيفه إلى مجموعة التوفر هو في عائلة Edsv5 VM. عند محاولة نشر جهاز ظاهري ثان، جهاز ظاهري موجود في عائلة M، يفشل هذا النشر. والسبب هو أن الأجهزة الظاهرية لعائلة Edsv5 لا تعمل على نفس الجهاز المضيف مثل الأجهزة الظاهرية في عائلة M.

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

مجموعات مقياس الجهاز الظاهري مع تزامن مرن

توفر مجموعات مقياس الجهاز الظاهري ذات التنسيق المرن تجميعا منطقيا للأجهزة الظاهرية المدارة بواسطة النظام الأساسي. لديك خيار لإنشاء مجموعة مقياس داخل المنطقة أو توسيعها عبر مناطق التوفر. عند الإنشاء، سيتم توزيع مجموعة المقياس المرنة داخل منطقة مع platformFaultDomainCount>1 (FD>1)، سيتم توزيع الأجهزة الظاهرية المنشورة في مجموعة المقياس عبر عدد محدد من مجالات الخطأ في نفس المنطقة. من ناحية أخرى، سيؤدي إنشاء مجموعة التحجيم المرنة عبر مناطق التوفر باستخدام platformFaultDomainCount=1 (FD=1) إلى توزيع الأجهزة الظاهرية عبر منطقة محددة وستوزع مجموعة المقياس أيضا الأجهزة الظاهرية عبر مجالات خطأ مختلفة داخل المنطقة على أساس أفضل جهد.

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

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

تلميح

لا توجد حاليا طريقة مباشرة لترحيل حمل عمل SAP المنشور في مجموعات التوفر أو مناطق التوفر إلى نطاق مرن باستخدام FD=1. لإجراء التبديل، تحتاج إلى إعادة إنشاء الجهاز الظاهري والقرص مع قيود المنطقة من الموارد الموجودة في مكانها. يتضمن مشروع مفتوح المصدر وظائف PowerShell التي يمكنك استخدامها كعينة لتغيير جهاز ظاهري تم نشره في مجموعة التوفر أو منطقة التوفر إلى مجموعة مقياس مرنة مع FD=1. يوضح لك منشور مدونة كيفية تعديل نظام SAP HA أو غير HA الذي تم نشره في مجموعة التوفر أو منطقة التوفر إلى مجموعة مقياس مرنة مع FD=1.

مجموعات تعيين موضع التقارب

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

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

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

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

شبكة Azure

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

  • الوصول إلى خدمات Azure والوصول إلى منافذ معينة في الأجهزة الظاهرية التي تستخدمها التطبيقات.
  • الوصول المباشر إلى الأجهزة الظاهرية عبر Secure Shell (SSH) أو سطح المكتب البعيد ل Windows (RDP) للإدارة والإدارة.
  • الاتصال الداخلي وتحليل الاسم بين الأجهزة الظاهرية وخدمات Azure.
  • الاتصال المحلي بين شبكة محلية وشبكات Azure.
  • الاتصال بين الخدمات التي يتم نشرها في مناطق Azure المختلفة.

للحصول على معلومات مفصلة حول الشبكات، راجع شبكة Azure الظاهرية.

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

الشبكات الظاهرية في Azure.

الشبكة الظاهرية هي كتلة إنشاء أساسية لشبكتك الخاصة في Azure. يمكنك تحديد نطاق عناوين الشبكة وفصل النطاق إلى شبكات فرعية للشبكة. يمكن أن تكون الشبكة الفرعية للشبكة متاحة ل SAP VM لاستخدامها أو يمكن تخصيصها لخدمة أو غرض معين. تتطلب بعض خدمات Azure، مثل Azure Virtual Network وAzure Application Gateway، شبكة فرعية مخصصة.

تعمل الشبكة الظاهرية ك حدود شبكة. جزء من التصميم المطلوب عند التخطيط للتوزيع الخاص بك هو تعريف الشبكة الظاهرية والشبكات الفرعية ونطاقات عناوين الشبكة الخاصة. لا يمكنك تغيير تعيين الشبكة الظاهرية لموارد مثل بطاقات واجهة الشبكة (NICs) للأجهزة الظاهرية بعد توزيع الأجهزة الظاهرية. قد يتطلب إجراء تغيير على شبكة ظاهرية أو نطاق عناوين شبكة فرعية نقل كافة الموارد المنشورة إلى شبكة فرعية مختلفة.

يجب أن يعالج تصميم الشبكة العديد من المتطلبات لتوزيع SAP:

  • لا يتم وضع أي أجهزة ظاهرية للشبكة، مثل جدار حماية، في مسار الاتصال بين تطبيق SAP وطبقة DBMS لمنتجات SAP عبر نواة SAP، مثل S/4HANA أو SAP NetWeaver.
  • يتم فرض قيود توجيه الشبكة بواسطة مجموعات أمان الشبكة (NSGs) على مستوى الشبكة الفرعية. تجميع عناوين IP للأجهزة الظاهرية في مجموعات أمان التطبيقات (ASGs) التي يتم الاحتفاظ بها في قواعد NSG، وتوفير مجموعات الدور والطبقة ومعرف الأمان المشترك للأذونات.
  • تعمل الأجهزة الظاهرية لتطبيق SAP وقاعدة البيانات في نفس الشبكة الظاهرية، داخل نفس الشبكات الفرعية أو الشبكات الفرعية المختلفة لشبكة ظاهرية واحدة. استخدم شبكات فرعية مختلفة للأجهزة الظاهرية للتطبيق وقاعدة البيانات. بدلا من ذلك، استخدم التطبيق المخصص وDBMS ASGs لتجميع القواعد التي تنطبق على كل نوع من أنواع حمل العمل داخل نفس الشبكة الفرعية.
  • يتم تمكين الشبكات المسرعة على جميع بطاقات الشبكة لجميع الأجهزة الظاهرية لأحمال عمل SAP حيثما أمكن تقنيا.
  • تأكد من الوصول الآمن للتبعية على الخدمات المركزية، بما في ذلك تحليل الاسم (DNS)، وإدارة الهوية (مجالات Windows Server Active Directory/ معرف Microsoft Entra)، والوصول الإداري.
  • توفير الوصول إلى نقاط النهاية العامة وبها، حسب الحاجة. تتضمن الأمثلة إدارة Azure لعمليات ClusterLabs Pacemaker في قابلية وصول عالية أو لخدمات Azure مثل Azure Backup.
  • استخدم بطاقات NIC متعددة فقط إذا كانت ضرورية لإنشاء شبكات فرعية معينة لها مساراتها وقواعد NSG الخاصة بها.

للحصول على أمثلة حول بنية الشبكة لتوزيع SAP، راجع المقالات التالية:

اعتبارات الشبكة الظاهرية

بعض تكوينات الشبكات الظاهرية لها اعتبارات محددة يجب أن تكون على علم بها.

  • تكوين الأجهزة الظاهرية للشبكة في مسار الاتصال بين طبقة تطبيق SAP وطبقة DBMS لمكونات SAP باستخدام نواة SAP، مثل S/4HANA أو SAP NetWeaver، غير مدعوم.

    يمكن للأجهزة الظاهرية للشبكة في مسارات الاتصال مضاعفة زمن انتقال الشبكة بسهولة بين شريكين في الاتصال. كما يمكنهم تقييد الإنتاجية في المسارات الحرجة بين طبقة تطبيق SAP وطبقة DBMS. في بعض السيناريوهات، يمكن أن تتسبب الأجهزة الظاهرية للشبكة في فشل مجموعات Pacemaker Linux.

    يجب أن يكون مسار الاتصال بين طبقة تطبيق SAP وطبقة DBMS مسارا مباشرا. لا يتضمن التقييد قواعد ASG وNSG إذا كانت قواعد ASG وNSG تسمح مسار اتصال مباشر.

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

  • فصل طبقة تطبيق SAP وطبقة DBMS في شبكات Azure الظاهرية المختلفة غير مدعوم. نوصي بفصل طبقة تطبيق SAP وطبقة DBMS باستخدام الشبكات الفرعية داخل نفس شبكة Azure الظاهرية بدلا من استخدام شبكات Azure الظاهرية المختلفة.

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

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

تحليل الاسم وخدمات المجال

غالبا ما يكون حل اسم المضيف إلى عنوان IP من خلال DNS عنصرا حاسما لشبكة SAP. لديك العديد من الخيارات لتكوين الاسم ودقة IP في Azure.

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

كما هو الحال مع خدمات DNS، قد يكون هناك متطلبات ل Windows Server Active Directory يمكن الوصول إليها بواسطة SAP VMs أو الخدمات.

تعيين عنوان IP

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

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

لمزيد من المعلومات، راجع إنشاء جهاز ظاهري يحتوي على عنوان IP خاص ثابت.

إشعار

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

عناوين IP الثانوية لظاهرية اسم مضيف SAP

يمكن أن يكون لكل NIC الخاص ب Azure VM عناوين IP متعددة معينة إليه. يمكن استخدام IP ثانوي لاسم مضيف ظاهري SAP، والذي يتم تعيينه إلى سجل DNS A أو سجل DNS PTR. يجب تعيين عنوان IP ثانوي إلى تكوين IP الخاص ب Azure NIC. يجب أيضا تكوين IP ثانوي داخل نظام التشغيل بشكل ثابت لأن عناوين IP الثانوية غالبا ما لا يتم تعيينها من خلال DHCP. يجب أن يكون كل IP ثانوي من نفس الشبكة الفرعية التي ترتبط بها NIC. يمكن إضافة IP ثانوي وإزالته من Azure NIC دون إيقاف الجهاز الظاهري أو إلغاء تخصيصه. لإضافة عنوان IP الأساسي ل NIC أو إزالته، يجب إلغاء تخصيص الجهاز الظاهري.

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

موازن تحميل Azure مع الأجهزة الظاهرية التي تشغل SAP

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

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

تلميح

يجب عدم استخدام موازن التحميل الأساسي مع أي بنية SAP في Azure. تمت جدولة موازن التحميل الأساسي ليتم إيقافه.

vNICs متعددة لكل جهاز ظاهري

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

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

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

تحذير

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

شبكات مسرعة

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

الاتصال المحلي

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

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

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

الاتصال بالإنترنت الصادر والوارد

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

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

مسارات الاتصال مع الإنترنت هي محور تصميم أفضل الممارسات.

أجهزة Azure الظاهرية لأحمال عمل SAP

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

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

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

للحصول على هذه المعلومات لعائلة FM معينة ونوعها، راجع أحجام الأجهزة الظاهرية في Azure.

نماذج التسعير لأجهزة Azure الظاهرية

بالنسبة لنموذج تسعير الجهاز الظاهري، يمكنك اختيار الخيار الذي تفضل استخدامه:

  • نموذج تسعير الدفع أولا بأول
  • خطة محجوزة أو توفير لمدة سنة واحدة
  • خطة محجوزة أو توفير لمدة ثلاث سنوات
  • نموذج تسعير موضعي

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

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

لمزيد من المعلومات حول التسعير الفوري، راجع أجهزة Azure Spot الظاهرية.

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

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

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

نظام التشغيل للأجهزة الظاهرية

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

للحصول على تفاصيل ومعلومات حول الخيارات المتوفرة:

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

الأجهزة الظاهرية من الجيل 1 والجيل 2

في Azure، يمكنك نشر جهاز ظاهري إما كجيل 1 أو من الجيل 2. يسرد دعم الأجهزة الظاهرية من الجيل 2 في Azure عائلات أجهزة Azure الظاهرية التي يمكنك نشرها كجيل 2. تسرد المقالة أيضا الاختلافات الوظيفية بين الأجهزة الظاهرية من الجيل 1 والجيل 2 في Azure.

عند نشر جهاز ظاهري، تحدد صورة نظام التشغيل التي تختارها ما إذا كان الجهاز الظاهري سيكون من الجيل 1 أو جهاز ظاهري من الجيل 2. تتوفر أحدث إصدارات جميع صور نظام التشغيل ل SAP المتوفرة في Azure (Red Hat Enterprise Linux وSuSE Enterprise Linux وWindows أو Oracle Enterprise Linux) في كل من الجيل 1 والجيل 2. من المهم تحديد صورة بعناية استنادا إلى وصف الصورة لنشر الجيل الصحيح من الجهاز الظاهري. وبالمثل، يمكنك إنشاء صور نظام تشغيل مخصصة كالجيل 1 أو الجيل 2، وتؤثر على جيل الجهاز الظاهري عند نشر الجهاز الظاهري.

إشعار

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

يمكنك تحديد ما إذا كان الجهاز الظاهري هو الجيل 1 أو الجيل 2 فقط استنادا إلى صورة نظام التشغيل المحددة. لا يمكنك تغيير جهاز ظاهري موجود من جيل إلى جيل آخر.

لا يمكن تغيير جهاز ظاهري منشور من الجيل 1 إلى الجيل 2 في Azure. لتغيير جيل الجهاز الظاهري، يجب نشر جهاز ظاهري جديد هو الجيل الذي تريده وإعادة تثبيت برنامجك على الجيل الجديد من الجهاز الظاهري. يؤثر هذا التغيير على صورة VHD الأساسية للجهاز الظاهري فقط وليس له أي تأثير على أقراص البيانات أو مشاركات نظام ملفات الشبكة المرفقة (NFS) أو Server Message Block (SMB). يمكن إرفاق أقراص البيانات أو مشاركات NFS أو مشاركات SMB التي تم تعيينها في الأصل إلى جهاز ظاهري من الجيل 1 بجهاز ظاهري من الجيل الثاني.

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

حدود الأداء لأجهزة Azure الظاهرية

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

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

إشعار

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

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

عند التخطيط للأجهزة الظاهرية واختيارها لاستخدامها في توزيع SAP، ضع في اعتبارك هذه العوامل:

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

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

  • قارن متطلبات SAPS لخادم DBMS مع SAPS التي يمكن أن توفرها أنواع الأجهزة الظاهرية المختلفة من Azure. يتم توثيق المعلومات حول SAPS من أنواع أجهزة Azure الظاهرية المختلفة في SAP Note 1928533. يجب أن يكون التركيز على DBMS VM أولا لأن طبقة قاعدة البيانات هي الطبقة في نظام SAP NetWeaver الذي لا يتوسع في معظم عمليات التوزيع. في المقابل، يمكن توسيع طبقة تطبيق SAP. تصف إرشادات DBMS الفردية تكوينات التخزين الموصى بها.

  • تلخيص النتائج الخاصة بك من أجل:

    • عدد أجهزة Azure الظاهرية التي تتوقع استخدامها.
    • عائلة الجهاز الظاهري الفردية ووحدات SKU للجهاز الظاهري لكل طبقة SAP: DBMS و(A) SCS وخادم التطبيق.
    • مقاييس معدل نقل الإدخال/إخراج أو متطلبات سعة التخزين المحسوبة.

خدمة HANA Large Instances

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

إشعار

خدمة HANA Large Instances في وضع الغروب ولا تقبل عملاء جدد. لا يزال من الممكن توفير وحدات لعملاء HANA Large Instances الحاليين.

تخزين SAP على Azure

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

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

القرص المؤقت على الأجهزة الظاهرية

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

يجب عدم تخزين أي تطبيق أو بيانات نظام تشغيل غير قابلة للاستهلاك على قرص مؤقت. في بيئات Windows، عادة ما يتم الوصول إلى محرك الأقراص المؤقت كمحرك أقراص D. في أنظمة Linux، غالبا ما تكون نقطة التحميل جهاز /dev/sdb أو /mnt أو /mnt/resource.

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

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

مشاركات الشبكة ووحدات التخزين ل SAP

تتطلب أنظمة SAP عادة مشاركة ملف شبكة واحدة أو أكثر. عادة ما تكون مشاركات الملفات أحد الخيارات التالية:

  • دليل نقل SAP (/usr/sap/trans أو TRANSDIR).
  • وحدات تخزين SAP أو وحدات التخزين sapmnt أو saploc المشتركة لنشر خوادم تطبيقات متعددة.
  • وحدات تخزين بنية عالية التوفر ل SAP (A) SCS أو SAP ERS أو قاعدة بيانات (/hana/shared).
  • واجهات الملفات التي تقوم بتشغيل تطبيقات الجهات الخارجية لاستيراد الملفات وتصديرها.

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

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

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

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

إشعار

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

الأمان لمناظر SAP الأفقية

لحماية حمل عمل SAP على Azure، تحتاج إلى تخطيط جوانب متعددة من الأمان:

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

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

تأمين الشبكات الظاهرية باستخدام مجموعات الأمان

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

لا تقيد مجموعات أمان الشبكة الأداء بالقواعد التي تحددها لمجموعة أمان الشبكة. لمراقبة تدفق حركة المرور، يمكنك اختياريا تنشيط تسجيل تدفق NSG مع السجلات التي تم تقييمها بواسطة إدارة أحداث المعلومات (SIEM) أو نظام الكشف عن التسلل (IDS) الذي تختاره لمراقبة نشاط الشبكة المشبوه والعمل عليه.

تلميح

تنشيط مجموعات أمان الشبكة فقط على مستوى الشبكة الفرعية. على الرغم من أنه يمكن تنشيط مجموعات أمان الشبكة على مستوى الشبكة الفرعية ومستوى NIC، فإن التنشيط على كليهما غالبا ما يكون عائقا في استكشاف الأخطاء وإصلاحها عند تحليل قيود حركة مرور الشبكة. استخدم NSGs على مستوى NIC فقط في حالات استثنائية وعند الحاجة.

نقاط النهاية الخاصة للخدمات

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

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

لمعرفة خدمات Azure التي توفر خيار استخدام نقطة نهاية خاصة، راجع الخدمات المتوفرة ل Private Link. بالنسبة إلى NFS أو SMB مع Azure Files، نوصي دائما باستخدام نقاط النهاية الخاصة لأحمال عمل SAP. للتعرف على الرسوم التي يتم تكبدها باستخدام الخدمة، راجع تسعير نقطة النهاية الخاصة. قد تتضمن بعض خدمات Azure اختياريا التكلفة مع الخدمة. يتم تضمين هذه المعلومات في معلومات التسعير الخاصة بالخدمة.

التشفير

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

التشفير لموارد البنية الأساسية

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

  • تشفير من جانب التخزين (SSE) PMK (SSE-PMK)
  • المفتاح المدار بواسطة عميل SSE (SSE-CMK)
  • التشفير المزدوج الثابت
  • التشفير المستند إلى المضيف

لمزيد من المعلومات، بما في ذلك وصف تشفير قرص Azure، راجع مقارنة خيارات تشفير Azure.

إشعار

حاليا، لا تستخدم التشفير المستند إلى المضيف على جهاز ظاهري موجود في عائلة M-series VM عند التشغيل مع Linux بسبب قيود الأداء المحتملة. لا يتأثر استخدام تشفير SSE-CMK للأقراص المدارة بهذا القيد.

بالنسبة إلى عمليات توزيع SAP على أنظمة Linux، لا تستخدم تشفير قرص Azure. ينطوي تشفير قرص Azure على تشغيل التشفير داخل SAP VMs باستخدام CMKs من Azure Key Vault. بالنسبة إلى Linux، لا يدعم تشفير قرص Azure صور نظام التشغيل المستخدمة لأحمال عمل SAP. يمكن استخدام تشفير قرص Azure على أنظمة Windows مع أحمال عمل SAP، ولكن لا تجمع بين تشفير قرص Azure والتشفير الأصلي لقاعدة البيانات. نوصي باستخدام التشفير الأصلي لقاعدة البيانات بدلا من تشفير قرص Azure. لمزيد من المعلومات، راجع القسم التالي.

على غرار تشفير القرص المدار، يتوفر تشفير ملفات Azure الثابتة (SMB وNFS) مع PMKs أو CMKs.

بالنسبة لمشاركات شبكة SMB، راجع ملفات Azure وتبعيات نظام التشغيل بعناية مع إصدارات SMB لأن التكوين يؤثر على دعم التشفير أثناء النقل.

هام

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

التشفير لمكونات SAP

يمكن فصل التشفير على مستوى SAP إلى طبقتين:

  • تشفير DBMS
  • تشفير النقل

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

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

اتصل ب SAP أو مورد DBMS للحصول على دعم حول كيفية تمكين تشفير البرامج أو استخدامه أو استكشاف الأخطاء وإصلاحها.

هام

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

يمكن تطبيق تشفير النقل أو الاتصال على اتصالات SQL Server بين محركات SAP وDBMS. وبالمثل، يمكنك تشفير الاتصالات من طبقة عرض SAP التقديمي (اتصال شبكة SAPGui الآمن أو SNC) أو اتصال HTTPS بواجهة ويب أمامية. راجع وثائق مورد التطبيقات لتمكين التشفير وإدارته أثناء النقل.

مراقبة التهديدات والتنبيه

لنشر حلول مراقبة التهديدات والتنبيه واستخدامها، ابدأ باستخدام بنية مؤسستك. توفر خدمات Azure حماية من التهديدات وعرض أمان يمكنك دمجه في خطة توزيع SAP الشاملة. يعالج Microsoft Defender for Cloud متطلبات الحماية من التهديدات. عادة ما يكون Defender for Cloud جزءا من نموذج حوكمة شامل لنشر Azure بأكمله، وليس فقط لمكونات SAP.

لمزيد من المعلومات حول إدارة أحداث معلومات الأمان (SIEM) وحلول الاستجابة التلقائية لتنسيق الأمان (SOAR)، راجع حلول Microsoft Sentinel لتكامل SAP.

برامج الأمان داخل SAP VMs

تصف 2808515 ملاحظة SAP لنظامي التشغيل Linux وSAP Note 106267 لنظام التشغيل Windows المتطلبات وأفضل الممارسات عند استخدام الماسحات الضوئية للفيروسات أو برامج الأمان على خوادم SAP. نوصي باتباع توصيات SAP عند نشر مكونات SAP في Azure.

التوافر العالي

يحتوي توفر SAP العالي في Azure على مكونين:

  • قابلية وصول عالية للبنية الأساسية ل Azure: قابلية وصول عالية لحساب Azure (VMs) والشبكة وخدمات التخزين، وكيف يمكنها زيادة توفر تطبيق SAP.

  • قابلية وصول عالية لتطبيق SAP: كيف يمكن دمجه مع قابلية الوصول العالية للبنية الأساسية ل Azure باستخدام شفاء الخدمة. مثال يستخدم قابلية وصول عالية في مكونات برامج SAP:

    • مثيل SAP (A) SCS وSAP ERS
    • خادم قاعدة البيانات

لمزيد من المعلومات حول قابلية الوصول العالية ل SAP في Azure، راجع المقالات التالية:

Pacemaker على Linux وWindows Server تجاوز الفشل للمجموعات هي أطر العمل الوحيدة عالية التوفر لأحمال عمل SAP التي تدعمها Microsoft مباشرة على Azure. أي إطار عمل آخر عالي التوفر غير مدعوم من قبل Microsoft وسيحتاج إلى التصميم وتفاصيل التنفيذ ودعم العمليات من المورد. لمزيد من المعلومات، راجع السيناريوهات المدعومة ل SAP في Azure.

التعافي من الكوارث

غالبا ما تكون تطبيقات SAP من بين العمليات الأكثر أهمية للأعمال في المؤسسة. واستنادا إلى أهميتها والوقت اللازم للتشغيل مرة أخرى بعد انقطاع غير متوقع، ينبغي التخطيط بعناية لسيناريوهات استمرارية الأعمال والتعافي من الكوارث.

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

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

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

يقدم Azure Backup حلول PaaS للنسخ الاحتياطي:

  • تكوين الجهاز الظاهري ونظام التشغيل وطبقة تطبيق SAP (تغيير حجم البيانات على الأقراص المدارة) من خلال Azure Backup للجهاز الظاهري. راجع مصفوفة الدعم للتحقق من أن البنية الخاصة بك يمكنها استخدام هذا الحل.
  • بيانات قاعدة بيانات SQL Server وSAP HANA والنسخ الاحتياطي للسجل. يتضمن دعم تقنيات النسخ المتماثل لقاعدة البيانات، مثل النسخ المتماثل لنظام HANA أو SQL Always On، ودعم عبر المناطق للمناطق المقترنة.
  • النسخ الاحتياطي لمشاركة الملفات من خلال ملفات Azure. تحقق من دعم NFS أو SMB وتفاصيل التكوين الأخرى.

بدلا من ذلك، إذا قمت بنشر Azure NetApp Files، تتوفر خيارات النسخ الاحتياطي على مستوى وحدة التخزين، بما في ذلك تكامل SAP HANA وOracle DBMS مع نسخة احتياطية مجدولة.

توفر حلول Azure Backup خيار حذف مبدئي لمنع الحذف الضار أو العرضي ومنع فقدان البيانات. يتوفر الحذف المبدئي أيضا لمشاركات الملفات التي تقوم بنشرها باستخدام Azure Files.

تتوفر خيارات النسخ الاحتياطي لحل تقوم بإنشائه وإدارته بنفسك، أو إذا كنت تستخدم برامج تابعة لجهة خارجية. يتمثل أحد الخيارات في استخدام الخدمات مع Azure Storage، بما في ذلك باستخدام التخزين غير القابل للتغيير لبيانات الكائن الثنائي كبير الحجم. هذا الخيار المدار ذاتيا حاليا مطلوب كخيار نسخ احتياطي ل DBMS لبعض قواعد البيانات مثل SAP ASE أو IBM Db2.

استخدم التوصيات الواردة في أفضل ممارسات Azure لحماية هجمات برامج الفدية الضارة والتحقق من صحتها.

تلميح

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

النسخ الاحتياطي عبر المناطق

بالنسبة لأي متطلبات نسخ احتياطي عبر المناطق، حدد هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO) الذي يقدمه الحل وما إذا كان يطابق تصميم BCDR واحتياجاته.

ترحيل SAP إلى Azure

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

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

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

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

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

  • توسيع نطاق البنية الأساسية. أثناء ترحيل SAP، يمكن أن يساعدك الحصول على المزيد من سعة البنية الأساسية في النشر بسرعة أكبر. يجب أن يفكر فريق المشروع في زيادة حجم الجهاز الظاهري لتوفير المزيد من وحدة المعالجة المركزية والذاكرة. يجب على الفريق أيضا النظر في توسيع نطاق التخزين الكلي للجهاز الظاهري ومعدل نقل الشبكة. وبالمثل، على مستوى الجهاز الظاهري، ضع في اعتبارك عناصر التخزين مثل الأقراص الفردية لزيادة معدل النقل مع الاندفاع عند الطلب طبقات الأداء ل Premium SSD v1. قم بزيادة قيم IOPS ومعدل النقل إذا كنت تستخدم Premium SSD v2 أعلى القيم المكونة. تكبير مشاركات ملفات NFS وSMB لزيادة حدود الأداء. ضع في اعتبارك أنه لا يمكن تقليل حجم إدارة أقراص Azure، ويمكن أن يكون لهذا الانخفاض في الحجم، مستويات الأداء، ومؤشرات الأداء الرئيسية لمعدل النقل أوقات تهدئة مختلفة.

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

    يمكن أن يؤدي استخدام ExpressRoute أو VPN إلى اختناقات:

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

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

تلميح

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

الدعم والعمليات ل SAP

من المهم مراعاة بعض المجالات الأخرى قبل وأثناء توزيع SAP في Azure.

ملحق Azure VM ل SAP

يشير ملحق مراقبة Azure والمراقبة المحسنة وملحق Azure ل SAP إلى ملحق الجهاز الظاهري الذي تحتاج إلى نشره لتوفير بعض البيانات الأساسية حول البنية الأساسية ل Azure إلى عامل مضيف SAP. قد تشير ملاحظات SAP إلى الملحق باسم Monitoring Extension أو Enhanced monitoring. في Azure، يسمى Azure Extension ل SAP. لأغراض الدعم، يجب تثبيت الملحق على جميع أجهزة Azure الظاهرية التي تقوم بتشغيل حمل عمل SAP. لمعرفة المزيد، راجع ملحق Azure VM ل SAP.

SAProuter لدعم SAP

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

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