دعمت Cloudwrxs تنفيذ SAP S/4HANA 2022 على AWS وتشغيله الفعلي لشركة تابعة تعمل في قطاع الأدوية، إلى جانب Solution Manager وWeb Dispatcher. شمل البرنامج نشر نظام جديد، وتفعيل SAP Best Practices، وترحيل البيانات القديمة من ECC، ودعم النقل وإدارة Basis، وتصميم النسخ الاحتياطي والاستعادة، وتخطيط استمرارية الأعمال لبيئة الإنتاج.
تم تنفيذ البرنامج كتنفيذ جديد لنظام S/4HANA مع مسار عمل قوي لإدارة Basis والبنية التحتية بالتوازي مع نشر التطبيق. دعم المشهد المستهدف شركة في قطاع الأدوية، وشمل SAP S/4HANA 2022 وSolution Manager وWeb Dispatcher.
تضمن التنفيذ ترحيل عدة سنوات من بيانات النظام القديم من ECC إلى نظام S/4HANA الجديد لدعم العمليات التجارية في قطاع الأدوية. وجاءت مراحل التنفيذ كما يلي:
قبل نشر أي نظام SAP، كان يجب حسم عدد من قرارات الأساس: منطقة AWS الأقرب إلى المستخدمين ومراكز البيانات، ومتطلبات إقامة البيانات والامتثال، ودعم خدمات AWS المطلوبة وعائلات مثيلات EC2، والحاجة إلى نشر متعدد مناطق التوافر للتوافر العالي، ونموذج النشر المناسب، والتأثير التجاري لتسعير خدمات AWS.
حددت هذه الخيارات مسار التنفيذ الكامل. وبعد اتضاحها، استطاع المشروع الانتقال من قرارات التصميم إلى التخطيط الفعلي للنشر والاتصال.
عند نشر نظام SAP S/4HANA على AWS، تتوفر الخيارات نفسها تقريباً كما في البيئات المحلية.
توفر SAP Best Practices مكتبة محتوى مهيأة مسبقاً لعمليات أعمال كاملة من البداية إلى النهاية، مبنية على خبرة SAP العالمية الواسعة في التنفيذ. تساعد هذه الحزم على تسريع التهيئة والنشر، وضمان اتساق العمليات، وتقليل جهود التخصيص في مشاريع SAP.
عملت بيئة التطوير على SAP S/4HANA 2022 مع خادم التطبيق الأساسي وASCS والخدمات المركزية على SUSE Linux Enterprise Server 15 SP5، بينما عملت قاعدة بيانات HANA على مضيف قاعدة بيانات مخصص ومنفصل. كما تم نشر Solution Manager 7.2 مع مضيف قاعدة بيانات خاص به. كان هذا نشراً موزعاً تم فيه فصل طبقتي قاعدة البيانات والتطبيق بشكل مقصود.
بعد أعمال التثبيت وما بعد التثبيت، تم إنشاء عدة عملاء لتلبية احتياجات تجارية ووظيفية محددة. ثم تم تفعيل SAP Best Practices لألمانيا والسعودية والإمارات، مع تغيير عملة المجموعة من USD الافتراضية إلى KWD بما يلائم نموذج تشغيل العميل.
Client 100 – التخصيص والتطوير
هذا عميل فريد، وهو عميل المنشأ لجميع النقلات الوظيفية عبر المشهد. وهو العميل الوحيد في المشهد الذي لا يمكن إعادة إنشائه بنسخة عميل؛ فلا يمكن تحديثه، بل يمكن استعادته فقط. يستخدمه مبرمجو ABAP لإنشاء كود ABAP جديد.
Client 200 – اختبار الوحدة
هذا هو أول عميل يتم فيه الاختبار الرسمي. يستخدم لاختبار المعاملات الفردية والتهيئة، أي أصغر وحدة في معاملة أو عملية أعمال. يعمل الجميع في عميل اختبار الوحدة، ويتم تنفيذ جميع المعاملات فيه، بما في ذلك كود ABAP، ومجموعات أنشطة الأمان، وتحميل البيانات، والتهيئة، والبيانات الرئيسية، والمهام الدورية.
Client 300 – عميل Sandbox
عميل Sandbox هو بيئة منفصلة ومعزولة للاختبار والتجربة على التهيئات والتخصيصات من دون التأثير في أنظمة التطوير أو الإنتاج الرئيسية.
بعد اختيار نموذج النشر، تم إنشاء الاتصال بين البيئة المحلية وAWS عبر Site-to-Site VPN. وضعت بنية التطوير SAP S/4HANA وSolution Manager وHANA داخل شبكة فرعية خاصة، مع خادم قفز في شبكة فرعية عامة لتوفير وصول مضبوط إلى المشهد.
استخدم Solution Manager لإدارة طلبات التغيير، ومراقبة النظام، وتنبيهات EWA، ودعم ADS لأنظمة التطوير والجودة في S/4HANA. وقد حافظ ذلك على حوكمة المشروع أثناء انتقال التنفيذ عبر مراحل البناء والاختبار.
احتفظ نظام الجودة بالبنية العامة نفسها المستخدمة في التطوير، لكن تم استخدام مثيل قاعدة بيانات أكبر لأن اختبارات SIT وUAT احتاجت إلى بيانات أكثر. كما تم توفير خادم تطبيق إضافي حتى يمكن توزيع الحمل بين PAS وAAS.
أتاح ذلك لبيئة الجودة أن تتصرف بشكل أقرب إلى بيئة ما قبل الإنتاج الواقعية، مع الحفاظ على نمط بناء مألوف لفرق التسليم.
بقيت بنية نظام الجودة مشابهة تقريباً، مع بعض الاختلافات المهمة:
Client 100 – اختبار تكامل النظام (SIT)
يركز هذا العميل على الاختبار الشامل لنظام كامل يتكون من عدة مكونات أو عناصر فرعية.
Client 200 – اختبار قبول المستخدم (UAT)
يعرف أيضاً باسم اختبار التطبيق أو اختبار المستخدم النهائي، وهو مرحلة يتم فيها اختبار البرنامج في العالم الحقيقي بواسطة الجمهور المقصود.
قبل مناقشة SAP HANA System Replication وضوابط التوافر العالي، وضع المشروع أولاً نسخ قاعدة البيانات الاحتياطي. تم استخدام AWS Backint لنسخ قاعدة بيانات HANA احتياطياً إلى حاوية S3، مع جدولة نسخ يومية من خلال SAP HANA Cockpit.
وفر Backint الواجهة بين SAP HANA وتخزين النسخ الاحتياطي الخارجي، بينما تولى AWS Backint Agent نقل ملفات النسخ الاحتياطي والكتالوج إلى Amazon S3 أو AWS Backup. دعم ذلك النسخ الكامل والتزايدي والتفاضلي، إلى جانب حماية السجلات والكتالوجات.
Client 100 – الإنتاج
عميل العميل الحي، ويستخدم لتسجيل معاملات الأعمال الخاصة بالعميل.
يوضح مخطط البنية بيئة الإنتاج حيث تتم استضافة SAP S/4HANA وقاعدة بيانات HANA داخل شبكة فرعية خاصة. ويتم نشر Web Dispatcher في الشبكة الفرعية العامة DMZ لتسهيل الوصول الآمن إلى تطبيق Fiori من الإنترنت. وتتم كل الاتصالات بين AWS ومركز بيانات العميل عبر Site-to-Site VPN.
يعد التوافر العالي في بيئة إنتاج SAP S/4HANA ضرورياً لضمان استمرار العمليات التجارية، وتقليل التوقف، واستمرار الوصول إلى التطبيقات والبيانات المؤسسية الحرجة. وقبل مناقشة استمرارية الأعمال، كان يجب تناول موضوع مهم آخر، وهو النسخ الاحتياطي لقاعدة بيانات SAP HANA. فهذا أحد أهم الضوابط التي يجب أن تكون جاهزة قبل بدء توافر قاعدة بيانات SAP HANA العالي.
قبل تمكين SAP HANA System Replication، يجب التأكد من إعداد النسخ الاحتياطي. في هذه الحالة، استخدمنا AWS Backint لنسخ قاعدة بيانات HANA احتياطياً إلى حاوية S3، وجدولنا نسخاً احتياطية يومية باستخدام SAP HANA Cockpit.
يوضح المخطط أعلاه أن النسخ الاحتياطي اليومي يتم تشغيله من SAP HANA Cockpit. ويتم تكوين النسخ باستخدام AWS Backint، ثم يخزن Amazon Backint Agent ملفات النسخ الاحتياطي في حاوية Amazon S3 بناءً على المعلومات الموجودة في ملف تهيئة Amazon Backint Agent for SAP HANA.
ومن هنا ننتقل إلى الموضوع الأهم: استمرارية الأعمال. فـ SAP تطبيق حرج للأعمال، إذ يوفر منصة موحدة لإدارة العمليات، وتبسيط التشغيل، وتحسين الكفاءة العامة. وهو نظام ERP رائد يساعد المؤسسات على دمج البيانات والعمليات عبر الإدارات المختلفة، بما يتيح قرارات أفضل ورؤى لحظية.
تم تصميم النشر متعدد مناطق التوافر ليكون ملائماً لأحمال العمل الحرجة. وتم تكرار كل الخدمات التي يمكن أن تتحول إلى نقاط فشل منفردة عبر أكثر من منطقة توافر لتوفير تحمل الأعطال وتعظيم وقت التشغيل. يشرح القسم التالي كيفية تهيئة SAP S/4HANA على AWS باستخدام SUSE Linux Enterprise Server، مع خطوات إعداد Pacemaker cluster لـ ABAP SAP Central Services وEnqueue Replication Server عبر مثيلات EC2 في منطقتي توافر داخل منطقة AWS نفسها.
تشمل نقاط الفشل المنفردة في SAP عادةً الخدمات المركزية SAP Central Services مثل SCS/ASCS، وخادم Enqueue، وقاعدة البيانات، وخادم التطبيق الأساسي PAS عند وجوده منفرداً. يدير ASCS جدول القفل، ومعالجة الرسائل، والبوابة الخاصة بطبقة ABAP، ولذلك يجب حمايته بواسطة HA cluster مع عقدة تجاوز فشل وEnqueue Replication Server. ويجب تكرار جدول القفل باستخدام ERS حتى يمكن تنفيذ الفشل التلقائي عبر Pacemaker أو cluster من دون فقد الاتساق.
أما قاعدة البيانات فهي مستودع البيانات المركزي، وأي فشل فيها يوقف عمليات SAP. لذلك يجب استخدام HANA System Replication. وإذا كان هناك PAS واحد فقط، فقد يؤثر فشله في تسجيل الدخول، ولذلك يجب إضافة AAS إضافية خلف موزع حمل.
تعتمد الاستراتيجية على زوج من عقد cluster موزعة في شبكات فرعية معزولة داخل مناطق توافر منفصلة، ضمن VPC ومنطقة AWS واحدة. يتم توزيع PAS وAAS عبر مناطق توافر أو خوادم فعلية مختلفة، ويتم تكوينها خلف موزع حمل أو SAP Web Dispatcher لتوزيع الحمل ودعم تجاوز الفشل.
يستخدم Enqueue Replication Server لتكرار بيانات جدول القفل من ASCS، بما يضمن تجاوز الفشل من دون فقد بيانات عند فشل العقدة الأساسية. كما يلزم توفر صلاحيات عرض أو تعديل جداول التوجيه المرتبطة بالشبكات الفرعية المحددة.
توضح الصورة أعلاه مخططاً عالي المستوى لكيفية تخفيف نقطة الفشل المنفردة عند مستوى ASCS/ERS. يعد ASCS نقطة فشل منفردة؛ فإذا فشل، تتوقف اتصالات SAP وآلية القفل. يتم تثبيت مكوني SAP ASCS وERS على عقدتين مختلفتين في منطقتي توافر مختلفتين. يعمل ERS على العقدة B ويكرر جدول القفل باستمرار. وإذا فشل ASCS، ينتقل تلقائياً إلى العقدة التي يعمل عليها ERS، مما يحافظ على اتساق جدول القفل عند بدء ASCS.
يوضح المخطط منخفض المستوى عمق التهيئة، بما في ذلك الموارد وCorosync وPacemaker. يتم تكوين موارد cluster متعددة لتحقيق استمرارية الأعمال.
أنشأنا عنوان IP افتراضياً وموارد sapstartsrv وSAP instance لـ ASCS، ثم جمعناها معاً. وفي حالة حدوث تجاوز فشل، تنتقل المجموعة التي تحتوي على موارد cluster إلى العقدة التي يعمل عليها ERS معاً. وبالطريقة نفسها، تم أيضاً تكوين موارد cluster الخاصة بـ ERS وجمعها في مجموعة مختلفة.
في المشهد الرقمي سريع التطور اليوم، أصبحت أمان البيانات وتوافرها وموثوقيتها أكثر أهمية من أي وقت مضى. تعتمد المؤسسات بشكل متزايد على منصات إدارة بيانات قوية مثل SAP HANA لضمان التشغيل السلس، وتمكين القرارات المبنية على المعلومات، والحفاظ على ميزة تنافسية. وبفضل بنية الذاكرة الداخلية عالية الأداء، يلعب SAP HANA دوراً محورياً في استراتيجيات البيانات الحديثة.
يمتاز SAP HANA بسرعته وقابليته للتوسع، ومن أهم نقاط قوته قدرات System Replication التي تدعم التوافر العالي والتعافي من الكوارث وتوزيع البيانات بكفاءة، بما يقلل الانقطاع أثناء الصيانة المخططة أو الأعطال غير المتوقعة.
يعد SAP HANA System Replication ميزة حرجة لضمان التوافر العالي واستمرارية الأعمال. فهو يتيح تكرار البيانات في الزمن الحقيقي من نظام HANA أساسي إلى نظام ثانوي أو أكثر، مما يقلل التوقف أثناء الصيانة أو الفشل. وعند مناقشة استمرارية الأعمال، يظهر مفهوما RTO وRPO بشكل طبيعي، وهما عنصران أساسيان في التخطيط للتعافي من الكوارث واستمرارية أنظمة البيانات.
Recovery Point Objective (RPO)
يحدد RPO الحد الأقصى المسموح به لفقد البيانات الذي يمكن للمؤسسة تحمله عند حدوث انقطاع أو فشل في النظام. وببساطة: ما مقدار البيانات التي يمكن قبول فقدانها؟
Recovery Time Objective (RTO)
يشير RTO إلى الحد الأقصى المقبول لمدة التوقف التي يمكن للمؤسسة تحملها قبل استعادة الأنظمة والخدمات بعد الانقطاع. وببساطة: ما السرعة المطلوبة لإعادة النظام إلى العمل؟
بينما يركز RPO على فقد البيانات المقبول، يتناول RTO وقت الاستعادة المقبول. وتتطلب إدارة الاثنين بشكل فعال نهجاً مشتركاً يشمل طرق التكرار، واستراتيجيات النسخ الاحتياطي، والتحقق من الأنظمة، وآليات تجاوز الفشل الآلية، بما يضمن الاتساق والتوافر العالي والاستعادة السريعة عند حدوث الانقطاعات.
SAP HANA replication آلية قوية لتكرار البيانات من نظام HANA أساسي إلى نظام ثانوي أو أكثر. يضمن هذا التكرار في الزمن الحقيقي أو شبه الحقيقي أن يعكس النظام الثانوي ذاكرة وبيانات النظام الأساسي، مما يتيح التحويل السريع عند الحاجة.
SAP HANA System Replication ميزة توافر عال تقدمها SAP لتعزيز مرونة بيئات SAP HANA. فهي تساعد في تقليل التوقف الناتج عن الصيانة المخططة أو أعطال العتاد أو سيناريوهات الكوارث. في هذا الإعداد، يكون مثيل SAP HANA الثانوي مرآة للنظام الأساسي، مع الحفاظ على عدد مطابق من المضيفين النشطين. وتقوم كل خدمة على العقدة الأساسية بالمزامنة المستمرة مع الخدمة المقابلة على العقدة الثانوية في وضع تكرار لحظي لنسخ البيانات والسجلات وحفظها، وغالباً مع تحميلها مسبقاً في الذاكرة لتسريع تجاوز الفشل.
في النهاية، يساعد SAP HANA replication المؤسسات على البقاء مرنة وعالية التوافر وجاهزة لمتطلبات العالم الرقمي المتغير.
من الجوانب المهمة التي يجب مناقشتها في هذا المستند النسخ الاحتياطي لقاعدة البيانات، لأنه أحد الشروط التي يجب تلبيتها قبل بدء HANA System Replication. وبما أننا نحتاج إلى تكرار السجلات من العقدة الأساسية إلى العقدة الثانوية، يجب نسخها احتياطياً قبل تكرارها. لذلك، ومن أجل تخزين السجلات، يجب إعداد نسخ احتياطي قادر على حفظ التغييرات المستمرة في قاعدة البيانات.
يقوم نهج SUSE بأتمتة عملية takeover في بيئات SAP HANA System Replication. ورغم أن تكرار البيانات إلى مثيل SAP HANA ثانوي يضمن توافر البيانات، فإنه لا يضمن استمرارية النظام وحده. ولتعزيز التوافر العالي، نحتاج إلى حل cluster يدير عملية تجاوز الفشل ويضمن استمرار وصول العملاء عبر نقل عنوان الخدمة.
تم تصميم نشر SAP HANA على AWS لتوفير التوافر العالي وتحمل الأعطال على مستوى البنية التحتية. ومع ذلك، لا تزال الأعطال على مستوى قاعدة بيانات SAP HANA تحتاج إلى إدارة. عند حدوث مشكلة في العتاد أو البرامج، يمكن بدء failover يدوي باستخدام SAP HANA Cockpit أو SAP HANA Studio أو أداة hdbnsutil. وقد تؤدي هذه الإجراءات اليدوية إلى انقطاعات مؤقتة في الأعمال.
يتيح إعداد التوافر العالي لـ SAP HANA باستخدام System Replication تجاوز فشل آلياً بين المثيلين الأساسي والثانوي. يتم تكوين المثيلين داخل Pacemaker cluster يعمل على مستوى نظام التشغيل ويتكامل مع SAP HANA عبر hooks متخصصة. يراقب هذا الحل النظام باستمرار ويبدأ failover تلقائياً عند الحاجة، وغالباً ما تتحقق الاستعادة خلال دقائق أو أسرع.
يستخدم Pacemaker cluster عنوان IP افتراضياً لتوجيه الحركة إلى مثيل SAP HANA master النشط. أثناء failover، يتم نقل هذا العنوان إلى المثيل الاحتياطي الذي تتم ترقيته ليصبح الأساسي الجديد. وعلى AWS، يستخدم عنوان Overlay IP ليشير دائماً إلى عقدة SAP HANA النشطة، سواء كانت العقدة الأساسية الأصلية أو النظام الثانوي.
تنظم AWS بنيتها في Regions وAvailability Zones. ويساعد النشر عبر أكثر من Availability Zone داخل Region واحدة على تحسين تحمل الأعطال وتقليل تأثير الأعطال المحلية. في مشروعنا، قمنا بتكوين نظام ثانوي Active/Passive وفق سيناريو Performance Optimized. يقيّد System Replication الوصول للقراءة وتنفيذ SQL على النظام الثانوي حتى يحدث takeover وينتقل الدور النشط من الأساسي إلى الثانوي. يعمل الثانوي كـ hot standby باستخدام وضع log replay. وإذا فشل نظام SAP HANA الأساسي، يبدأ cluster عملية takeover، مستفيداً من البيانات المحملة مسبقاً لتسريع الاستعادة مقارنة بإعادة تشغيل محلية كاملة.
عند استخدام SLES for SAP من AWS Marketplace، تكون حزم SUSE HAE مضمنة مسبقاً. يجب التأكد من تشغيل أحدث الإصدارات وتحديثها عبر zypper عند الحاجة. كما يجب التأكد من تثبيت الحزم التالية: corosync وcrmsh وfence-agents وha-cluster-bootstrap وpacemaker وpatterns-ha-ha_sles وresource-agents وcluster-glue.
قبل متابعة تكوين cluster، يجب أن تكون خدمة Pacemaker متوقفة. ينبغي التحقق من حالتها وإيقافها إذا كانت نشطة.
إذا أردنا رؤية حالة HANA System Replication من مستوى نظام التشغيل، يجب تشغيل سكربت Python باسم systemReplicationStatus.py باستخدام مستخدم sidadm.
1. تهيئة Corosync
يجب أن تكون خدمة Pacemaker cluster غير نشطة أثناء تكوين cluster. تحقق من حالتها وأوقف الخدمة إذا لزم الأمر باستخدام systemctl status pacemaker.
2. إنشاء مفاتيح التشفير
بعد الإنشاء، يوجد ملف authkey في /etc/corosync/. يجب نسخه إلى الموقع نفسه على العقدة الثانية مع الحفاظ على الأذونات والملكية كما هي.
عادةً ما يتم تشغيل ذلك قبل إضافة مورد HANA إلى cluster أو أثناء الإعداد الأولي. وعندما يتم ضبط معامل stonith-action على “off”، تقوم الوكلاء ببدء إيقاف المثيل أثناء سيناريوهات تجاوز الفشل.
الوضع الأولي
يتصل SAP NetWeaver بـ SAP HANA عبر DBSL، وغالباً ما يستخدم اسم مضيف افتراضياً أو عنوان IP افتراضي للوصول إلى مضيف قاعدة البيانات ومثيلها. وتترجم DNS عادةً أسماء المضيفين الافتراضية إلى عناوين IP افتراضية يمكن نقلها بين منافذ الشبكة. يكون SAP HANA System Replication عاملاً ويكون النظام الثانوي في حالة متزامنة أو غير متزامنة مع مثيل HANA الأساسي. يحاول System Replication دائماً الوصول إلى الحالة المتزامنة، وفي إعداد SYNC ينتظر الأساسي تأكيد الثانوي لعمليات COMMIT.
وقوع الحادث وتنفيذ takeover
يراقب مدير cluster الحالة التشغيلية للإعداد ويتخذ إجراء عند حدوث فشل. وفي هذه الحالة يعزل المضيف المتأثر، وينقل عناوين IP الافتراضية بعيداً، وقد يرسل أمر STONITH لمنع أي استخدام إضافي للمضيف الأساسي. كما يبدأ مدير cluster عملية takeover، وينتظر وصول الثانوي إلى حالة التشغيل الكاملة، ثم ينقل عنوان IP الافتراضي إلى منفذ شبكة المضيف الثانوي. وبانتقال عنوان IP الافتراضي، يصبح هناك نظام عامل خلف الواجهة نفسها، ويمكن إعادة توصيل جلسات SAP NetWeaver وعمليات العمل بمثيل قاعدة البيانات الثانوي.
المتابعة وإعادة تهيئة SAP HANA System Replication بالاتجاه العكسي
تصبح كل المعاملات المؤكدة والتغييرات المرتبطة بها متاحة على نظام takeover. وتتم إعادة المزامنة بين الأساسي والثانوي الجديدين تلقائياً، وقد تستغرق بعض الوقت. يختار SAP HANA تلقائياً الطريقة المثلى لتنفيذ ذلك، مثل delta transfer. ولا يمكن بدء takeover عكسي إلى الوضع الأصلي إلا بعد اكتمال هذه المزامنة.
اتصال العملاء
يتضمن اتصال العملاء بـ SAP HANA عبر VIP على AWS عادةً تكوين حلول HA تستخدم عنوان IP عائماً لسيناريوهات failover. يضمن ذلك استمرار الوصول إلى قاعدة بيانات SAP HANA إذا أصبح المثيل الأساسي غير متاح. يتم تكوين عنوان IP افتراضي أو Overlay IP داخل HA cluster، ولا يكون مرتبطاً بشكل دائم بمثيل محدد، بل ينتقل بين العقدة النشطة والاحتياطية. يتصل العملاء مثل تطبيقات SAP وSAP HANA Studio والتطبيقات المخصصة بقاعدة البيانات باستخدام هذا العنوان. وأثناء failover، ينقل cluster عنوان IP إلى مثيل HANA النشط الجديد، مما يسمح للعملاء بإعادة الاتصال من دون إعادة تهيئة يدوية لأن هدف الاتصال يبقى ثابتاً.
لا يقتصر نجاح تنفيذ SAP S/4HANA على AWS على تثبيت التطبيق وترحيل البيانات. يجب أن يكون المشهد الأوسع جاهزاً للاستخدام التجاري الفعلي: اتصال آمن، وضبط واضح للنقل، ومراقبة، ونسخ احتياطي، واستعادة، وتوافر عال، ونموذج استمرارية مختبر قبل go-live.
في هذا التنفيذ، دعم بناء S/4HANA الجديد بنية AWS منظمة عبر التطوير والجودة والإنتاج. وتم تفعيل SAP Best Practices، وترحيل بيانات ECC القديمة باستخدام Migration Cockpit، وتصميم بيئة الإنتاج مع مراعاة التوافر الحرج للأعمال.
أهم درس هو أن Basis والبنية التحتية وتخطيط الاستمرارية لا يمكن أن تأتي خلف مسار العمل الوظيفي، بل يجب أن تتحرك معه. عندما تصمم أساسات المنصة مبكراً، وتختبر جيداً، وتوائم مع نموذج تشغيل الأعمال، يصبح go-live انتقالاً مضبوطاً بدلاً من حدث تقني عالي المخاطر.
يوضح تنفيذ SAP S/4HANA أن التخطيط لـ SAP على AWS يحتاج إلى أكثر من بناء البنية التحتية. قبل الانتقال إلى التصميم التفصيلي أو تخطيط التحويل، يجب التحقق من نطاق البيئة وتحجيم HANA والتكامل والأمن والنسخ الاحتياطي والتوافر العالي والتشغيل والتحقق من الأعمال.
أنشأت Cloudwrxs مورداً مكملاً: قائمة جاهزية هجرة SAP إلى AWS للفرق التي تستعد لبرامج مشابهة.
يجب إثبات أحجام HANA، بنية الشبكة، الاتصال بالموقع، النسخ الاحتياطي، HSR، التوافر العالي، أمن الوصول، المراقبة، وخطة الانتقال قبل اعتبار بيئة S/4HANA جاهزة للإنتاج.
يوفر HSR التوافر واستمرارية الخدمة، لكنه لا يحل محل النسخ الاحتياطي القابل للاستعادة. يجب إعداد Backint، S3 أو AWS Backup، الكتالوجات، واختبارات الاستعادة قبل الاعتماد على التوافر العالي.
تنفيذ SAP على AWS يربط Basis، التطبيق، البيانات، النقل، الاتصال، الأمن، التعافي، التوافر العالي، واختبارات الأعمال. النجاح يعتمد على جاهزية التشغيل والانتقال، وليس فقط تثبيت الخوادم.
يمكن لـ Cloudwrxs مساعدتك في تسليم SAP Basis، وتصميم المناظر التقنية، والنسخ الاحتياطي والاستعادة، وبنية التوافر العالي، ودعم الانتقال المنضبط إلى التشغيل على AWS.
