منذ أكثر من 10 سنوات ، أعلنت Microsoft عن توفر النظام الأساسي Azure لجمهور عريض من المستخدمين. خلال هذا الوقت ، أرادت العديد من الشركات الاستفادة من البنية التحتية السحابية لحل مشاكل تكنولوجيا المعلومات الحالية. اتصل بنا بعضهم للحصول على المشورة بشأن نشر الأنظمة في السحابة. ولكن مر الوقت والآن تدرس الشركة إمكانية وضع أنظمة كثيفة الاستخدام للموارد مثل SAP HANA في السحب. نحن ، بدورنا ، قمنا بالفعل بتنفيذ العديد من المشاريع المماثلة ونحن على استعداد لمشاركة تلك الملاحظات التي يمكن أن تضمن نشرًا أكثر نجاحًا لنظام SAP في سحابة MS Azure. لن تكون بعض الملاحظات اكتشافًا ، لكننا أردنا إظهار إمكانية تطبيق بعض الأساليب في النظام الأساسي السحابي. نريد مشاركة الدروس الرئيسية المستفادة معك.
رقم 1: تحسين بنية تكنولوجيا المعلومات باستمرار باستخدام السحابة
كجزء من ترحيل النظام الإنتاجي ، واجهنا مشكلة الاستهلاك المرتفع للموارد في عمليات الاختبار والتطوير ، مما جعلنا في النهاية نفكر في سبب حاجتنا إلى الكثير من الموارد لبيئة الاختبار والتطوير وكيفية تحسين استهلاك موارد البنية التحتية بواسطة نظام إنتاجي.
يعتمد النهج الموصى به لبناء نظام SAP على تقييم القدرات المطلوبة باستخدام حاسبة SAP Quick Sizer. حتى الآن ، تعتمد منهجيات SAP على مناهج قياسية لا تأخذ في الاعتبار خصائص تقنيات السحابة. تلقينا المتطلبات من العميل ، وأدخلنا البيانات الأولية في مقدرات SAP وتلقينا تكوينًا أوليًا للمناظر الطبيعية. في حالة البنية التحتية التقليدية ، كان من الممكن التوقف عند هذا الحد والانتقال إلى شراء المعدات ، ولكن في حالتنا كان من الممكن الاستفادة من السحابة. في السحابة ، يمكن زيادة الموارد في أي وقت ، وبالتالي فقد تخلينا عن احتياطي الموارد الفائض المتضمن في المقدر والآلات المنشورة ذات الأداء المنخفض. سمح لنا هذا بتقليل التكاليف ،ومع زيادة الحمل ، يمكننا دائمًا زيادة أداء أجهزة SAP الافتراضية في دقائق.
توفر Microsoft دعم SAP على الأجهزة الظاهرية من السلسلة M فقط. ويبدو أن استخدام موارد الاختبار المشابهة لبيئة الإنتاج من حيث مستوى الدعم في مرحلة التطوير الأولية لا لزوم له بالنسبة لنا.
في الوقت نفسه ، تتمتع ماكينات الفئة E بخصائص مماثلة لسلسلة M ، لكن تكلفتها أقل بكثير. نتيجة لذلك ، استبدلنا آلات الاختبار بالسلسلة E. الجانب السلبي لهذا الاستبدال هو نقل المسؤولية عن تشغيل النظام في بيئات الاختبار من المزود إلى المُدمج. هذا يفرض الحاجة إلى أن يكون للمتكامل خبرة في SAP.
# 2: كيفية التوفير في استهلاك الموارد
يتيح لك MS Azure التوفير بشكل كبير عند حجز الموارد بدفع مسبق متزامن لمدة عام أو 3 أعوام.
غالبًا ، في المرحلة الأولية ، لا يستطيع العميل تقدير تاريخ إطلاق نظام إنتاجي بدقة ، نظرًا لأن تطويره واختباره غالبًا ما يرتبط بالعديد من المتغيرات الموجودة في جانب الشركة أو مطوري المقاول.
على سبيل المثال ، في وقت إطلاق أحد المشاريع ، خططنا للنشر المتزامن لجميع البيئات بناءً على الخطط الحالية للعميل. كما هو الحال غالبًا ، تطلب التطوير تنسيقًا أطول مع الشركة ، مما أخر الإطلاق الإنتاجي لعدة أشهر.
في هذا المثال ، عند حجز الموارد بدفع مسبق ، قد يخسر العميل قدرًا كبيرًا من الأموال. بالطبع ، من الضروري الاحتفاظ بالموارد ، ولكن من الأفضل القيام بذلك في مراحل لاحقة من المشروع ، عندما يستقر الجزء الأكبر من النظام الإنتاجي ، وأصبح التطور متوقعًا من حيث استهلاك الموارد. في كثير من الأحيان ، عندما تحتفظ بموارد الحوسبة لمدة 3 سنوات ، يمكنك الحصول على حوالي 70٪ مدخرات مقارنة بطريقة الدفع حسب الاستخدام.
# 3: كيفية اختيار منطقة Azure
لدى Azure مجموعة واسعة من مناطق استضافة الموارد. أحد المعايير الرئيسية لاختيار منطقة هو بُعد بنيتك التحتية عن المستخدمين النهائيين ، مما يؤثر على استجابة النظام وعمل عمليات الدمج والمستخدمين النهائيين.
المعيار الثاني ، الذي لا يقل أهمية هو قائمة الخدمات في منطقة معينة.
تتوفر بعض الخدمات حسب المنطقة. في كثير من الأحيان ، يتم تقديم الخدمات كمعاينة قبل الإصدار الرسمي. تكون بعض المناطق أسرع في إدخال تقنيات جديدة وتجربة خدمة أو أخرى ظهرت. لا توفر جميع المناطق القدرة على استخدام النطاق الكامل لسلسلة الأجهزة الافتراضية.
في ممارستنا ، غالبًا ما تُظهر مقارنة سرعة الوصول ميزة منطقة أوروبا الغربية. هذا ملحوظ بشكل خاص للشركات التي تقع خوادمها وعملائها في الجزء الأوروبي من روسيا. في كل حالة ، وخاصة إذا كانت مراكز البيانات والعملاء موجودون في الشرق الأقصى ، فمن المنطقي التحقق من التأخيرات من مركز البيانات (أو من المنطقة الجغرافية التي يوجد بها عملاؤك) لتحديد أفضل منطقة في Azure.
تسمح لك الخدمات مثل Azure Latency Test باختبار وقت الاستجابة بشكل استباقي لكل منطقة من مناطق Azure الخاصة بك من شبكة مركز البيانات الخاصة بك. مثال على نتائج قياس زمن الوصول باستخدام الخدمة المذكورة عند الاختبار من مكتبنا في موسكو:
رقم 4: كيفية تطبيق الأساليب الأرضية على عمليات التثبيت السحابية
في كل عملية ترحيل ، نسأل أنفسنا السؤال عن كيفية استخدام الحلول التقليدية المثبتة بواسطة البنية التحتية الكلاسيكية في السحابة. على وجه الخصوص ، عند إعداد حل ، نعتمد على توصيات البائع لتطوير حل صحيح تقنيًا. مشاريع SAP HANA ليست استثناءً ، كما أنها تمر عبر منظور التوصيات وأفضل الممارسات.
في أحد المشاريع ، عند تنفيذ المرحلة الأولى من الحل ، تم نشر خادم Jump المستند إلى Windows. لتحسين تكاليف مرحلة التطوير الأولية ، تم نشر خادم NFS على نفس الخادم لاحتياجات البيئات غير المنتجة ، والتي غطت الاحتياجات الحالية للمطورين وسمح بتوفير كبير في الموارد.
مع مرور الوقت ، نمت البيئات ومتطلبات الموارد ، وتعامل خادم NFS مع جميع المهام. تدريجيًا ، في إطار المشروع ، اقتربنا من استنفاد موارد الجهاز الافتراضي الأولي. يمكن زيادة موارد الأجهزة الافتراضية في MS Azure في دقائق ، ولكن في نفس الوقت زادت متطلبات التسامح مع أخطاء الخادم ، مما جعلنا نفكر في إعادة تكوين أكبر.
من أجل التنفيذ ، تم استخدام خادم Linux وخدمة DRBD ووظيفة مجموعة التوفر ، والتي أغلقت مشكلة نسخ البيانات بين عقد مجموعة NFS وزيادة التوافر في حالة فشل إحدى عقدتي المجموعة.
بالمناسبة: بعد شهرين من تنفيذ حل الكتلة ، تمت إضافة خدمة ملفات NetApp إلى Azure ، والتي تتيح لك الاستفادة من مصفوفات NetApp ، ولكن يتم الدفع مقابلها من خلال نموذج Pay-As-You-Go.
# 5: كيفية أتمتة جدول VM
عند استخدام أي بنية أساسية سحابية ، من المنطقي دائمًا تحليل الآليات الإضافية التي يمكن استخدامها لزيادة توفير التكاليف إلى أقصى حد.
في حالتنا ، يتم اختبار الأنظمة خلال ساعات العمل. في حين أن تعطل خادم البنية التحتية التقليدية يُترجم بشكل أساسي إلى زيادة فواتير الطاقة ، في السحابة ، تستهلك الخوادم غير المفيدة التمويل لاستئجار السعة. قمنا بتقييم الرسوم البيانية للتحميل على خوادم الاختبار والتطوير ولاحظنا أن الغالبية العظمى من المطورين والمختبرين يستخدمون النظام في أيام الأسبوع من 8-00 إلى 20-00.
في الحالات التي يكون فيها جدول التحميل على أنظمة غير منتجة متوقعًا ودوريًا ، نحاول استخدام البرامج النصية لأتمتة تشغيل / إيقاف تشغيل الجهاز الظاهري. يحتوي Azure على العديد من الأدوات: إيقاف التشغيل التلقائي وحسابات الأتمتة و Cloud Shell. لم تكن جميعها مناسبة لنا. تم استبعاد الإغلاق التلقائي لأنه لا يمكنه إلا إيقاف تشغيل الجهاز الظاهري. لم تشارك Cloud Shell أيضًا ، نظرًا لأنها تتطلب إعداد نصوص برمجية إضافية ، وتطوير المخططات ووضعها في مكان آمن لتخزين كل هذا مع التكرار ، مما قلل المدخرات إلى الحد الأدنى.
في حالتنا ، يتم استخدام آلية أكثر مرونة. تقدم حسابات الأتمتة حلاً جاهزًا وعمليًا في شكل كتيبات التشغيل ، مما يسمح لك بتشغيل وإيقاف تشغيل الأجهزة الافتراضية وفقًا لجدول زمني.
لقد أعددنا الرسوم البيانية للموارد المعنية ، وحملنا كتيبات التشغيل ، وشكلنا روابط بين الرسوم البيانية والموارد.
نتيجة لذلك ، قمنا بتقليل التكلفة الإجمالية للملكية. في البداية ، لم يتم التخطيط لهذه الأدوات للتنفيذ ، ولكن تم تنفيذها بالفعل في مرحلة التشغيل الأولي.
يتم تغيير الجدول في بضع دقائق. أولاً ، يتم تكوين جدول جديد ، ثم يتم ربط الجدول الذي تم إنشاؤه بالمورد المطلوب. إذا لزم الأمر وكان هناك عدد كبير من التغييرات ، فمن الممكن استخدام Cloud Shell لأتمتة هذه العملية.
# 6: مراقبة استهلاك الموارد
بينما بالنسبة لمراكز البيانات التقليدية ، فإن المراقبة الصحية واستهلاك الموارد ، للأسف ، عادةً ما يتلاشى في الخلفية ، ثم في Azure من غير المرغوب فيه السماح بذلك. تؤثر المعلومات المتعلقة بتاريخ استهلاك الموارد بشكل مباشر على إمكانيات تحسين التكلفة. وفي حالة الحجز المبكر للموارد ، يمكن أن يكون بمثابة إشارة للتحسينات المعمارية.
# 7: شبكة أمان في حالة القوة القاهرة
تحذر العديد من الشركات من وضع أنظمة تكنولوجيا المعلومات الخاصة بها على موارد السحابة بسبب الخوف من العوائق التي كانت تستهدفها الجهات التنظيمية في السابق. مثل أي مخاطر أخرى ، يمكن أيضًا أخذ ذلك في الاعتبار عند تصميم النظام. في المشاريع ، نقوم ، كقاعدة عامة ، بتنفيذ تفريغ أسبوعي لنسخ النظام الاحتياطية من السحابة إلى مركز بيانات العميل. يتيح لك هذا التأكد من إمكانية استعادة النظام في أي حال. بالإضافة إلى ذلك ، نستخدم إستراتيجية تثبيت متعددة الأوساط السحابية ، والتي ستسمح في حالة تقييد الوصول بعدم تركها دون الوصول إلى الموارد. في هذا السيناريو ، يتم استخدام موفري السحابة البديلة كمواقع DR للسحابة الرئيسية ، مما يسمح باستعادة النظام في حالة حدوث عوائق ضخمة.
رقم 7 + معالجة البيانات الشخصية
خلال عملنا ، قمنا بتشكيل نهج لكيفية تخزين البيانات الشخصية ومعالجتها في أنظمة تتضمن موارد سحابية أجنبية. لاحظ أنه ينبغي تنفيذ هذا النهج مع مراعاة متطلبات المنظمين. هذا الموضوع واسع إلى حد ما ، وسنحاول تغطيته في المقالات التالية إذا لاحظنا الاهتمام المقابل بالتعليقات.
النتيجة
في هذه المقالة ، راجعنا العديد من الدروس العملية حول استضافة SAP في سحابة MS Azure. من الواضح أن الموضوع واسع للغاية وتمكنا من التطرق فقط إلى جزء من التحسينات الممكنة عند الترحيل إلى السحابة.
ما الفروق الدقيقة التي واجهتها؟ سنكون ممتنين إذا قمت بمشاركة تجربتك في التعليقات.