قائمة اختيار تصميم وبناء حلول متعددة المستأجرين على Azure

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

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

• فهم نوع الحل الذي تقوم بإنشائه، مثل الأعمال إلى الأعمال (B2B) أو من شركة إلى مستهلك (B2C) أو برامج مؤسستك، وكيف يختلف المستأجرون عن المستخدمين.
• حدد المستأجرين. فهم عدد المستأجرين الذين ستدعمهم في البداية وخطط النمو الخاصة بك.
• حدد نموذج التسعير الخاص بك وتأكد من أنه يتوافق مع استهلاك المستأجرين لموارد Azure.
• فهم ما إذا كنت بحاجة إلى فصل المستأجرين إلى مستويات مختلفة. قد يكون للطبقات أسعار وميزات ووعود أداء ومواقع جغرافية مختلفة وما إلى ذلك.
• بناء على متطلبات عملائك، حدد نماذج الإيجار المناسبة لأجزاء مختلفة من الحل الخاص بك.
• عندما تكون جاهزاً، قم ببيع حل B2B متعدد المستأجرين باستخدام Microsoft Commercial Marketplace.

اعتبارات الموثوقية

• راجع قائمة التحقق من موثوقية Azure Well-Architected، والتي تنطبق على جميع أحمال العمل.
• فهم مضادات التناثر للجار المزعجة. منع المستأجرين الفرديين من التأثير على توفر النظام للمستأجرين الآخرين.
• صمم الحل متعدد المستأجرين لمستوى النمو الذي تتوقعه. ولكن لا تفرط في الإفراط في النمو غير الواقعي.
• حدد أهداف مستوى الخدمة (SLOs) واتفاقيات مستوى الخدمة (SLAs) اختياريا للحل الخاص بك. يجب أن تستند اتفاقيات مستوى الخدمة واتفاقيات مستوى الخدمة إلى متطلبات المستأجرين.
• اختبر مقياس الحل الخاص بك. التأكد من أنه يعمل بشكل جيد تحت جميع مستويات الحمل، وأنه يتدرج بشكل صحيح مع زيادة عدد المستأجرين.
• تطبيق مبادئ هندسة الفوضى لاختبار موثوقية الحل الخاص بك.

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

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

اعتبارات تحسين التكلفة

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

اعتبارات التميز التشغيلي

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

اعتبارات كفاءة الأداء

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

المساهمون

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

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

• آرسن فلاديميرسكي | مهندس العملاء الرئيسي
• بوهدان شيرشيك | مهندس عملاء أول

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

• جون داونز | مهندس البرامج الرئيسي

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

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

• راجع الاعتبارات المعمارية للحلول متعددة المستأجرين.
• مراجعة النهج المعمارية للتعددية.
• اتبع إرشادات خاصة بالخدمة للتعددية.
• راجع الموارد للمهندسين المعماريين ومطوري الحلول متعددة المستأجرين.