مشاركة عبر

نشر IBM Maximo Application Suite على Azure

Azure Files
Azure Load Balancer
Azure Red Hat OpenShift
Azure Virtual Machines
Azure Virtual Network

IBM Maximo Application Suite (MAS) 8.يعمل x على OpenShift، ومن المفيد التعرف على OpenShift والأنماط المقترحة للتثبيت على Azure. لمزيد من المعلومات، راجع التحضير للتضمين على Azure. توضح هذه البنية مجموعة OpenShift. لا يدخل في التفاصيل حول كيفية تثبيت MAS. لمعرفة المزيد حول عملية التثبيت، راجع تثبيت Maximo Application Suite من OperatorHub.

بناء الأنظمة

رسم تخطيطي للبنية يوضح المكونات والخدمات التي تدعم نشر IBM Maximo Application Suite على Azure.

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

يمكن نشر حمل العمل داخليا أو خارجيا، اعتمادا على متطلباتك.

‏‏سير العمل‬

من منظور البنية الأساسية، توفر هذه البنية ما يلي:

  • نظام أساسي لاستضافة الحاويات لنشر أحمال العمل المتوفرة بشكل كبير عبر مناطق التوفر
  • نشر خصخصة للعقد العاملة وعقد التحكم المدمجة مع التخزين
  • ملفات Azure المتميزة والملفات القياسية للتخزين (OpenShift Data Foundation غير مطلوبة)
  • SQL Server على أجهزة Azure الظاهرية أو مستودع IBM Db2 المستند إلى الحاوية
  • Azure DNS لإدارة DNS ل OpenShift وحاوياته
  • معرف Microsoft Entra لتسجيل الدخول الأحادي (SSO) في MAS

المكونات

  • أجهزة Azure الظاهرية لاستضافة النظام الأساسي OpenShift وتشغيل حاويات Maximo. الأجهزة الظاهرية هي عرض خدمة تأجير البُنية التحتية (IaaS). يمكنك استخدام الأجهزة الظاهرية لتوزيع موارد الحوسبة القابلة للتطوير عند الطلب.

  • Red Hat Enterprise Linux CoreOS لتوفير صورة جهاز ظاهري مخصصة ل OpenShift.

  • موازنات تحميل Azure لتوفير الاتصال في نظام المجموعة. يعد Azure Load Balancerعبارة عن خدمة موازنة أحمال من الطبقة 4 عالية الأداء وذات زمن انتقال منخفض للغاية (واردة وصادرة) لجميع بروتوكولات UDP وTCP. تم تصميمه لمعالجة ملايين الطلبات في الثانية مع ضمان قابلية الوصول عالية التوفر للحل. Azure Load Balancer تكون متكررة، ممّا يضمن توفّراً بدرجة كبيرة عبر Availability Zones.

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

  • ملفات Azure لاستضافة البيانات ذات الحالة لقواعد البيانات والأنظمة داخل نظام المجموعة. توفر Azure Files مشاركات ملفات مدارة بالكامل في السحابة التي يمكن الوصول إليها عبر بروتوكولات SMB ونظام ملفات الشبكة (NFS).

  • Azure DNS لإدارة دقة DNS للحاويات داخل الحل وخارجه. يدعم Azure DNS جميع سجلات DNS الشائعة ويوفر قابلية وصول عالية.

  • Azure Bastion (اختياري) وشبكة فرعية للوصول المحسن إلى الأمان إلى أي من العقد العاملة أو أجهزة JumpBox الاختيارية. Azure Bastion هي خدمة مدارة بالكامل توفر وصولا سلسا ومحسنا للأمان RDP وSSH إلى الأجهزة الظاهرية دون أي تعرض من خلال عناوين IP العامة.

  • SQL Server على أجهزة Azure الظاهرية (اختياري) لتوفير خدمات البيانات إلى MAS. يمكن أن تكون قاعدة البيانات أيضا أخرى، مثل Oracle Exadata أو IBM Db2 Warehouse. قاعدة بيانات Azure SQL ومثيل Azure SQL المدار غير مدعومين الآن.

  • Twilio Send Grid (اختياري) لإرسال رسائل البريد الإلكتروني من MAS إلى المستهلكين.

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

البدائل

عادة ما تكون الخدمات التالية غير ضرورية، ولكنها بدائل فعالة:

  • Azure NetApp Files كبديل ل Azure Files. تدعم Azure NetApp Files أي نوع من أحمال العمل مع توفر عال وأداء عال.
  • Oracle Database على Azure إذا كنت تفضل ذلك على SQL Server أو Db2 Warehouse.
  • OpenShift Data Foundation إذا كنت تريد استخدام Db2 Warehouse على OpenShift Data Foundation.

تفاصيل السيناريو

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

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

هذه التطبيقات و MAS 8.يتم اختبار x للاستخدام على Azure. اشتركت Microsoft وفريق IBM Maximo لضمان تكوين هذا الحل للتشغيل على النحو الأمثل على Azure. توفر هذه المقالة تصميما لتشغيل MAS 8.x على Azure للعملاء الذين لديهم دعم من IBM وشريك للتثبيت. اتصل بفريق IBM الخاص بك للحصول على أسئلة خاصة بالمنتج. يقدم Azure Marketplace تثبيتا بديلا ل MAS يدعم إحضار الترخيص الخاص بك. لمزيد من المعلومات، راجع IBM Maximo Application Suite (إحضار الترخيص الخاص بك (BYOL)) .

حالات الاستخدام المحتملة

تستخدم العديد من الصناعات والقطاعات الحلول في MAS، مثل:

  • الطاقة والمرافق
  • النفط والغاز
  • التصنيع
  • السفر والسيارات والنقل
  • القطاع العام

اعثر على مزيد من المعلومات حول حالات استخدام MAS على موقع IBM على الويب في IBM Maximo Application Suite.

التوصيات

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

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

نحن نعمل عن كثب مع IBM والشركاء الآخرين لضمان أن التوجيه والهندسة المعمارية ودليل التشغيل السريع يمنحك أفضل تجربة على Azure. وهي تتبع أفضل الممارسات كما هو موضح في Microsoft Azure Well-Architected Framework. اتصل بفريق حساب IBM للحصول على الدعم خارج هذه الوثائق.

قبل المتابعة في النشر، تحتاج إلى الإجابة على الأسئلة التالية حول التصميم:

  • ما هي تطبيقات MAS التي تحتاج إليها؟
  • ما هي التبعيات التي تحتوي عليها تطبيقاتك؟
  • ما هو إصدار OpenShift المطلوب؟
  • ما هي طريقة تثبيت OpenShift التي يجب استخدامها؟
  • ما هي قواعد البيانات المطلوبة؟
  • ما هو عدد وأحجام الأجهزة الظاهرية التي تحتاج إليها؟
  • هل سيتصل المستخدمون من الشبكات الخارجية؟

مجموعة تطبيقات Maximo

قامت Microsoft باختبار إصدارات MAS 8.5 والإصدارات الأحدث على Azure. توصيتنا هي استخدام أحدث إصدار من MAS، وهو الإصدار 8.7.

راجع تطبيقات MAS التي تحتاجها لسيناريو عملك الكامل، ثم راجع متطلبات كل تطبيق من التطبيقات. لمزيد من المعلومات، راجع متطلبات نظام IBM Maximo Application Suite. قد يحتاج كل تطبيق من التطبيقات إلى قواعد بيانات منفصلة. لقد قمنا باختبار ودعم قواعد البيانات التالية على Azure:

قد تختار أيضا تشغيل Oracle Exadata على جهاز ظاهري أو على Oracle Cloud Infrastructure باستخدام التوصيل البيني، ولكن هذا ليس تكوينا تم اختباره. لمزيد من المعلومات حول التوصيل البيني، راجع ربط Oracle Cloud ب Microsoft Azure. حاليا، لا يتم دعم قاعدة بيانات Azure SQL ومثيل Azure SQL المدار وAzure Cosmos DB.

إشعار

في بعض الحالات، لا يمكنك إعادة استخدام قاعدة بيانات لتطبيقات MAS متعددة بسبب إعدادات قاعدة البيانات المتعارضة. على سبيل المثال، لا يمكنك استخدام نفس IBM Db2 Warehouse for Health and Manage مع Monitor. ومع ذلك، يمكنك خلط منتجات قاعدة بيانات مختلفة، مثل استخدام SQL Server لتطبيق واحد وIBM Db2 Warehouse لتطبيق آخر.

لمزيد من المعلومات حول متطلبات قاعدة البيانات لتطبيق Health، راجع تكوين قاعدة البيانات ل Maximo Health.

تعتمد MAS وبعض تطبيقاتها على MongoDB وKafka. حدد كيفية نشر هذه الحلول بناء على اعتبارات الأداء والعمليات. الإعدادات الافتراضية هي نشر MongoDB Community Edition وStrimzi Kafka داخل المجموعات. تستخدم بعض المتطلبات الأساسية ل MAS، على سبيل المثال BAS، قواعد البيانات التي لا يمكن خارجيتها ولكنها تتطلب تخزينا مستمرا لتوفيرها إلى نظام مجموعة OpenShift.

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

بالنسبة للخدمات التي تحتفظ بالحالة، استخدم عروض النظام الأساسي الخارجي ل Azure كخدمة (PaaS) عندما يكون ذلك ممكنا. يؤدي القيام بذلك إلى تحسين إمكانية الدعم أثناء الانقطاع.

قد تتطلب بعض الخدمات أدوات وخدمات IBM أخرى، مثل IBM Watson التعلم الآلي وIBM App Connect. يمكنك نشر جميع الأدوات والخدمات على نفس مجموعة OpenShift.

OpenShift

إشعار

تدعم IBM Maximo Application Suite Azure Red Hat OpenShift، شريطة محاذاة الإصدارات الأساسية من OpenShift وCloud Pak for Data (CP4D).

قبل تثبيت OpenShift، تحتاج إلى تحديد الطريقة التي ستستخدمها:

  • Installer Provisioned Infrastructure (IPI) . يستخدم هذا الأسلوب المثبت لنشر وتكوين بيئة OpenShift على Azure. IPI هو الأسلوب الأكثر شيوعا للتوزيع على Azure، ويجب عليك استخدام IPI ما لم تكن متطلبات الأمان صارمة للغاية للقيام بذلك.

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

نوصي باستخدام IPI كلما أمكن ذلك، لأنه يقلل بشكل كبير من مقدار العمل المطلوب لإكمال تثبيت OpenShift.

إشعار

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

عند تثبيت OpenShift، يجب حل الاعتبارات التالية:

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

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

  • تجاوز الفشل. ضع في اعتبارك نشر OpenShift في منطقتين واستخدام Red Hat Advanced Cluster Management. إذا كان الحل الخاص بك يحتوي على نقاط نهاية عامة، يمكنك وضع Azure Traffic Manager بينها وبين الإنترنت لإعادة توجيه نسبة استخدام الشبكة إلى نظام المجموعة المناسب عندما يكون هناك انقطاع في المنطقة. في مثل هذه الحالة، يجب عليك أيضا ترحيل حالات التطبيقات ووحدات التخزين الثابتة.

عمليات التثبيت المكيفة الهواء

في بعض الحالات، مثل الامتثال التنظيمي، قد تحتاج إلى تثبيت AIR-gapped من MAS على Azure. يعني حدة الهواء أنه لا يوجد وصول إلى الإنترنت الوارد أو الصادر. بدون اتصال بالإنترنت، لا يمكن للتثبيت استرداد تبعيات التثبيت في وقت التشغيل لتثبيت MAS أو OpenShift.

إشعار

تتطلب عمليات النشر المكيفة الهواء UPI للتثبيت. ومع ذلك، لم يتم اختبارها بالكامل.

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

لمزيد من المعلومات حول عمليات التثبيت المكشوفة الهواء، راجع وثائق OpenShift التالية:

بعد تثبيت OpenShift، راجع وثائق MAS للحصول على إرشادات مماثلة.

تغيير حجم بيئتك

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

يتطلب Maximo Visual Inspection عقد GPU لتنفيذ التعلم الآلي الخاص بها. يستخدم الحل CUDA ويدعم فقط NVIDIA GPUs. الأنواع الموصى بها من الأجهزة الظاهرية هي NCv3 و NCasT4_v3. إذا كنت بحاجة إلى التدريب باستخدام YOLOv3، فستحتاج إلى وحدات معالجة الرسومات المستندة إلى Ampere. استخدم NVadsA10 v5 أو NC A100 v4 لمهام التدريب الأكبر.

بالنسبة لأجهزة GPU، نوصي بالبدء بأصغر عقدة والتوسع مع زيادة متطلباتك.

تحذير

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

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

  • عقد التحكم. جهاز ظاهري واحد على الأقل لكل منطقة توفر داخل المنطقة المحددة. أوصينا بعدد وحدات المعالجة المركزية الظاهرية (vCPU) الذي لا يقل عن 4. يستخدم مرجعنا 3x Standard_D8s_v4 العقد.

  • عقد العامل. جهازين كحد أدنى لكل منطقة توفر داخل المنطقة المحددة. نوصي بعدد وحدات المعالجة المركزية الظاهرية من 8 على الأقل. يستخدم مرجعنا 6x Standard_D8s_v4 العقد.

تتطلب ذاكرة MAS الأساسية 13 وحدة معالجة مركزية ظاهرية لتثبيت قاعدة قياسية الحجم. يختلف تغيير الحجم للعقد العاملة استنادا إلى تطبيقات MAS التي ينشرها التكوين الخاص بك والحمل على البيئة الخاصة بك. على سبيل المثال، تتطلب إدارة ل 10 مستخدمين 2 vCPUs أخرى. نوصي بمراجعة متطلبات نظام IBM Maximo Application Suite للحصول على تقدير جيد للتحجيم.

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

إذا كنت بحاجة إلى مربع انتقال سريع لاستخدام واجهة سطر الأوامر OpenShift (oc) أو لتثبيت MAS، فقم بنشر جهاز ظاهري يقوم بتشغيل الإصدار 8.4 من Red Hat Enterprise Linux.

الشبكة

باستخدام OpenShift، نستخدم موفر واجهة شبكة الحاوية الافتراضية (CNI) للشبكات المعرفة بالبرامج (SDN) الخاصة ب OpenShift. لمزيد من المعلومات حول OpenShift CNI الافتراضي، راجع عامل تشغيل شبكة نظام المجموعة في OpenShift Container Platform. يجب تغيير حجم شبكتك لعدد عقد التحكم OpenShift والعقد العاملة التي تحتاجها، وكذلك لأي متطلبات أخرى، مثل قواعد البيانات وحسابات التخزين.

لتثبيت إنتاج MAS القياسي، نوصي بشبكة ظاهرية بمساحة العنوان التي توفرها بادئة التوجيه بين المجالات (CIDR) بدون فئة من /24. تحتوي الشبكة الظاهرية على ثلاث أو أربع شبكات فرعية (ل Azure Bastion). بالنسبة ل OpenShift، تحتوي الشبكة الفرعية للعقد العاملة على بادئة CIDR من /25، وعقد التحكم لها بادئة /27. يجب أن تحتوي الشبكة الفرعية لنقاط النهاية وخادم قاعدة بيانات خارجي اختياري على بادئة /27. إذا كنت تقوم بنشر Azure Bastion، وهو أمر اختياري، فأنت بحاجة إلى شبكة فرعية تسمى AzureBastionSubnet ببادئة /26. لمزيد من المعلومات حول متطلبات Azure Bastion، راجع البنية.

إذا كنت قصيرا في عناوين IP، يمكنك تنفيذ تكوين عالي التوفر مع بادئة الحد الأدنى من /27 للشبكة الفرعية لعقد التحكم و/27 للشبكة الفرعية للعقد العاملة.

إذا كنت ترغب في استخدام CNI مختلف، فحجم شبكاتك وفقا لذلك. تنشر MAS مع بعض التطبيقات القياسية أكثر من 800 جراب، والتي من المحتمل أن تتطلب بادئة CIDR من /21 أو أكبر.

تفاصيل قاعدة البيانات

تستخدم المكونات المختلفة ل MAS MongoDB كمخزن بيانات تعريف. التوجيه الافتراضي هو نشر MongoDB Community Edition داخل نظام المجموعة. إذا قمت بنشره باستخدام هذا الأسلوب، فتأكد من وجود إجراء مناسب لإجراء النسخ الاحتياطي واستعادة قاعدة البيانات. ضع في اعتبارك استخدام MongoDB Atlas على Azure، لأنه يوفر مخزنا خارجيا ونسخا احتياطيا وتغيير الحجم والمزيد. لا يدعم Azure حاليا استخدام واجهات برمجة تطبيقات MongoDB مع Azure Cosmos DB.

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

يأتي MAS مزودا بالعديد من قواعد البيانات داخل pods الخاصة به، وتحتفظ قواعد البيانات هذه بحالاتها على نظام الملفات المقدم ل MAS. نوصي باستخدام آلية تخزين زائدة عن الحاجة (ZRS) للاحتفاظ بالولايات خارج مجموعاتك لتكون قادرة على استيعاب حالات فشل المنطقة. النمط الموصى به هو استخدام Azure File Storage مع التكوينات التالية:

  • قياسي. يوفر مشاركات Server Message Block (SMB) لمعدل نقل أقل وأحمال عمل ReadWriteOnce (RWO). يعد Standard مناسبا بشكل كبير لأجزاء من التطبيق التي لا تكتب إلى التخزين في كثير من الأحيان وتتطلب وحدة تخزين ثابتة واحدة (على سبيل المثال، تخزين من مستوى واحد من IBM).

  • Premium. يوفر مشاركات نظام ملفات الشبكة (NFS) لمعدل نقل أعلى وأحمال عمل ReadWriteMany (RWX). يتم استخدام وحدات التخزين مثل هذه في جميع أنحاء نظام المجموعة لأحمال عمل RWX، مثل مستودع Db2 في Cloud Pak للبيانات أو Postgres في الإدارة.

تأكد من تعطيل نهج فرض النقل الآمن على Azure Blob Storage أو إعفاء الحسابات من هذه النهج. يتطلب Azure Premium Files مع NFS تعطيل النقل الآمن. تأكد من استخدام نقطة نهاية خاصة لضمان الاتصال الخاص بمشاركاتك.

بشكل افتراضي، يتم نشر Db2 Warehouse أعلى OpenShift Data Foundation (المعروف سابقا باسم OpenShift Container Storage). لأسباب تتعلق بالتكلفة والأداء والتحجيم والموثوقية، نوصي باستخدام Azure Premium Files مع NFS بدلا من OpenShift Data Foundation.

لا تستخدم Azure Blob Storage مع برامج تشغيل CSI، لأنه لا يدعم الارتباطات الثابتة المطلوبة. لا يمكن تشغيل بعض القرون دون ارتباطات ثابتة.

الاعتبارات

تطبق هذه الاعتبارات ركائز إطار العمل جيد التصميم في Azure، وهي مجموعة من المبادئ التوجيهية التي يمكنك استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الأمان

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

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

يقدم Azure MAS باستخدام نماذج البنية الأساسية كخدمة (IaaS) وPaaS. Microsoft تبني حماية الأمان في الخدمة على المستويات التالية:

  • مركز البيانات الفعلي
  • الشبكة الفعلية
  • المضيف الفعلي
  • برنامج مراقبة الأجهزة الافتراضية

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

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

  • السماح بوصول SSH إلى عقد OpenShift لاستكشاف الأخطاء وإصلاحها
  • حظر الوصول إلى جميع الأجزاء الأخرى من نظام المجموعة
  • التحكم في المواقع التي يمكنها الوصول إلى MAS والمجموعة OpenShift

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

التشفير من جانب الخادم (SSE) لـ Azure Disk Storage يحمي بياناتك. كما يساعدك على الوفاء بالتزامات الأمان والتوافق التنظيمية. يقوم SSE بتشفير البيانات الثابتة عند استمرارها في السحابة، وذلك باستخدام الأقراص المُدارة من Azure. هذا السلوك ينطبق بشكل افتراضي على كل من نظام التشغيل وأقراص البيانات. يستخدم OpenShift SSE بشكل افتراضي.

المصادقة

يدعم MAS حاليا تسجيل الدخول الأحادي (SSO) باستخدام لغة ترميز تأكيد الأمان (SAML) في معرف Microsoft Entra. يتطلب أسلوب المصادقة هذا تطبيق مؤسسة داخل معرف Microsoft Entra وأذونات لتعديل التطبيق. لمزيد من المعلومات، راجع تكامل Microsoft Entra SSO مع Maximo Application Suite.

قبل إعداد المصادقة المستندة إلى SAML، نوصي بالانتقال من خلال تكوين IBM وتكوين Azure. للحصول على معلومات حول SAML مع MAS، راجع SAML في وثائق MAS. للحصول على معلومات حول SAML مع Azure، راجع التشغيل السريع: تمكين تسجيل الدخول الأحادي لتطبيق مؤسسة.

يجب عليك أيضا تكوين التخويل المفتوح (OAuth) ل OpenShift. لمزيد من المعلومات، راجع نظرة عامة على المصادقة والتخويل في وثائق OpenShift.

حماية البنية الأساسية لديك

التحكم في الوصول إلى موارد Azure التي تقوم بتوزيعها. كل اشتراك Azure له علاقة ثقة مع مستأجر Microsoft Entra. استخدم التحكم في الوصول المستند إلى دور Azure (RBAC) لمنح المستخدمين داخل مؤسستك الأذونات الصحيحة لموارد Azure. امنح حق الوصول عن طريق تعيين أدوار Azure للمستخدمين أو المجموعات في نطاق معين. يمكن أن يكون النطاق اشتراكاً أو مجموعة موارد أو مورداً واحداً. تأكد من تدقيق جميع التغييرات على البنية الأساسية. لمزيد من المعلومات حول التدقيق، راجع سجل نشاط Azure Monitor.

تحسين التكلفة

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

يتكون التوزيع القياسي ل MAS من المكونات التالية:

  • 3 أجهزة ظاهرية للتحكم
  • 6 أجهزة ظاهرية عاملة
  • 3 أجهزة ظاهرية عاملة لمستودع Db2
    • يمكنك استبدال SQL Server على أجهزة Azure الظاهرية في بعض التكوينات، بدلا من استخدام Db2 Warehouse.
  • 2 حسابات Azure Storage
  • 2 مناطق DNS
  • 2 موازنات التحميل
  • Azure Bastion
  • 1 جهاز ظاهري للفحص البصري
    • هذا غير مطلوب إلا إذا كنت تخطط لتشغيل الفحص المرئي داخل MAS.

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

الموثوقيه

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

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

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

نشر هذا السيناريو

قبل البدء، نوصي بمراجعة متطلبات نظام IBM Maximo Application Suite. تأكد من توفر الموارد التالية قبل بدء النشر:

  • الوصول إلى اشتراك Azure باستخدام إذن القارئ
  • تسجيل التطبيق أو اسم الخدمة الأساسي الذي لديه أذونات المساهم ومسؤول وصول المستخدم للاشتراك
  • المجال أو المجال الفرعي المفوض إلى منطقة Azure DNS
  • سحب البيانات السرية من Red Hat لنشر OpenShift
  • مفتاح استحقاق MAS
  • ملف ترخيص MAS (تم إنشاؤه بعد تثبيت MAS)
  • تحجيم نظام المجموعة الموصى به من IBM
  • شبكة ظاهرية موجودة أو شبكة ظاهرية جديدة تم إنشاؤها بواسطة IPI، اعتمادا على متطلباتك
  • متطلبات قابلية الوصول العالية والتعافي من الكوارث للنشر المحدد
  • ملف التكوين، install-config.yaml، للمثبت

للحصول على دليل خطوة بخطوة لتثبيت OpenShift و MAS على Azure، بما في ذلك كيفية معالجة المتطلبات الأساسية، راجع دليل التشغيل السريع على GitHub.

إشعار

دليل التشغيل السريع: يتضمن Maximo Application Suite على Azure مثالا لملف install-config.yaml في /src/ocp/.

اعتبارات النشر

من الأفضل نشر أحمال العمل باستخدام البنية الأساسية كتعليق برمجي (IaC) بدلا من نشر أحمال العمل يدويا، لأن النشر اليدوي يمكن أن يؤدي إلى تكوين خاطئ. يمكن أن تكون أحمال العمل المستندة إلى الحاوية حساسة للتكوين الخاطئ، ما يمكن أن يقلل من الإنتاجية.

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

تقدم IBM خدمات متخصصة لمساعدتك في التثبيت. اتصل بفريق IBM للحصول على الدعم.

المساهمون

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

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

المساهم الآخر:

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

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

للحصول على تعليمات حول البدء، راجع الموارد التالية:

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