بغض النظر عن البنية والمكونات التي تستخدمها لتنفيذها، تحتاج إلى نشر مكونات الحل وتكوينها. في بيئة متعددة المستأجرين، من المهم مراعاة كيفية نشر موارد Azure خاصتك، خاصة عند نشر موارد مخصصة لكل مستأجر، أو عند إعادة تكوين الموارد استناداً إلى عدد المستأجرين في نظامك. في هذه الصفحة، نقدم لمهندسي الحلول إرشادات حول نشر الحلول متعددة المستأجرين، ونوضح بعض الأساليب التي يجب مراعاتها عند التخطيط لاستراتيجية النشر خاصتك.
الاعتبارات والمتطلبات الرئيسية
من المهم أن يكون لديك فكرة واضحة عن متطلباتك، قبل أن تخطط لاستراتيجية النشر خاصتك. وتشمل الاعتبارات المحددة ما يلي:
- الحجم المتوقع: هل تتوقع دعم عدد صغير من المستأجرين (مثل خمسة أو أقل)، أم أنك ستنمو إلى عدد كبير من المستأجرين?
- الإعداد الآلي أو المدعوم: عندما يكون المستأجر جاهزاً للالتحاق، هل سيتمكن من إكمال العملية بنفسه باتباع إجراء آلي? أو هل يبدأ المستأجرون الجدد في تقديم طلب، وتقوم بإعدادهم يدوياً بعد استلام الطلب? هل هناك خطوات موافقة يدوية مطلوبة من فريقك، مثل منع إساءة استخدام خدمتك?
- وقت التوفير: عندما يكون المستأجر جاهزاً للانضمام، ما مدى السرعة التي يجب أن تكتمل بها عملية الإعداد? إذا لم يكن لديك إجابة واضحة، ففكر فيما إذا كان يجب قياسها بالثواني أو الدقائق أو الساعات أو الأيام.
- Azure Marketplace: هل تخطط لاستخدام Azure Marketplace لبدء النشر? إذا قمت بذلك، فهناك متطلبات تحتاج إلى تلبيتها لإضافة مستأجرين جدد.
يجب عليك أيضاً مراعاة خطوات الإعداد والتوفير و التنفيذ التلقائي ومسؤولية إدارة الموارد.
خطوات الإعداد والتزويد
ضع في اعتبارك كل ما تحتاج إلى القيام به عند إعداد مستأجر، وقم بتوثيق هذه القائمة وسير العمل، حتى إذا تم تنفيذه يدوياً. يتضمن سير عمل الإعداد عادةً ما يلي:
- قبول الاتفاقيات التجارية.
- جمع المعلومات التي تحتاجها لتكوين النظام خاصتك للمستأجر الجديد.
- خطوات الموافقة اليدوية، على سبيل المثال، لمنع الاحتيال أو إساءة استخدام خدمتك.
- توفير الموارد في Azure.
- إنشاء أسماء النطاقات أو تكوينها.
- قم بتنفيذ مهام التكوين بعد التوزيع، مثل إنشاء حساب المستخدم الأول للمستأجر وإرسال بيانات الاعتماد الخاصة به بأمان إلى المستأجر.
- تغييرات التكوين اليدوي، مثل تغييرات سجل DNS.
قم بتوثيق سير العمل المطلوب لتأهيل مستأجر جديد بوضوح.
بالإضافة إلى ذلك، ضع في اعتبارك موارد Azure المحددة التي تحتاج إلى توفيرها لمستأجر. حتى إذا لم توفر موارد مخصصة لكل مستأجر، ففكر فيما إذا كنت تحتاج أحيانا إلى نشر الموارد عند إعداد مستأجر جديد. قد يحدث هذا عندما يطلب المستأجر تخزين بياناته في منطقة معينة، أو عندما تقترب من حدود ختم أو مكون في الحل خاصتك وتحتاج إلى إنشاء مثيل آخر للدفعة التالية من المستأجرين.
ضع في اعتبارك ما إذا كانت عملية الإعداد من المرجح أن تكون مدمرة للمستأجرين الآخرين، خاصةً لأولئك الذين يشاركون نفس البنية التحتية. على سبيل المثال، إذا كنت بحاجة إلى تعديل قواعد البيانات المشتركة، فهل يمكن أن تتسبب هذه العملية في تأثير على الأداء قد يلاحظه المستأجرون الآخرون? فكر فيما إذا كان يمكنك تجنب هذه الآثار، أو تخفيفها من خلال إجراء عملية الإعداد خارج ساعات العمل العادية.
Automation
ينصح دائماً بعمليات النشر التلقائية للحلول المستضافة على السحابة. عند العمل مع حلول متعددة المستأجرين، يصبح التنفيذ التلقائي للنشر أكثر أهمية للأسباب التالية:
- نطاق: تصبح عمليات النشر اليدوي معقدة بشكل متزايد وتستغرق وقتا طويلا، مع زيادة عدد المستأجرين. من الأسهل توسيع نطاق نهج النشر التلقائي مع زيادة عدد المستأجرين.
- قابل للتكرار: في بيئة متعددة المستأجرين، استخدم عملية متسقة لعمليات النشر عبر جميع المستأجرين. تقدم العمليات اليدوية فرصة الخطأ أو الخطوات التي يتم تنفيذها لبعض المستأجرين دون غيرهم. تترك هذه العمليات اليدوية بيئتك في حالة غير متناسقة، ما يجعل من الصعب على فريقك إدارة الحل.
- تأثير الانقطاعات: عمليات النشر اليدوية أكثر خطورة بكثير وعرضة للانقطاع من عمليات النشر الآلية. في بيئة متعددة المستأجرين، يمكن أن يكون تأثير انقطاع التيار الكهربائي على مستوى النظام (بسبب خطأ في النشر) مرتفعاً، نظراً لأن كل مستأجر قد يتأثر.
عند النشر في بيئة متعددة المستأجرين، يجب عليك استخدام مسارات النشر واستخدام البنية الأساسية كتقنيات التعليمات البرمجية (IaC)، مثل Bicep أو قوالب JSON ARM أو Terraform أو Azure SDKs.
إذا كنت تخطط لتقديم الحل خاصتك من خلال Azure Marketplace، فيجب عليك توفير عملية إعداد تلقائية بالكامل للمستأجرين الجدد. يتم وصف هذه العملية في وثائق واجهات برمجة تطبيقات تنفيذ SaaS.
الحد الأقصى لسعة الموارد
عند نشر موارد المستأجر برمجياً على الموارد المشتركة، ضع في اعتبارك حد السعة لكل مورد. عند الاقتراب من هذا الحد، قد تحتاج إلى إنشاء مثيل آخر من المورد لدعم المزيد من التوسع. ضع في اعتبارك حدود كل مورد تقوم بنشره، والشروط التي ستدفعك إلى نشر مثيل آخر.
على سبيل المثال، افترض أن الحل خاصتك يتضمن خادم منطقي Azure SQL، وأن الحل خاصتك يوفر قاعدة بيانات مخصصة على هذا الخادم لكل مستأجر. يحتوي خادم منطقي واحد على حدود، والتي تتضمن الحد الأقصى لعدد قواعد البيانات التي يدعمها الخادم المنطقي. ومع اقترابك من هذه الحدود، قد تحتاج إلى توفير خوادم جديدة حتى تتمكن من الاستمرار في إعداد المستأجرين. ضع في اعتبارك ما إذا كنت تقوم بتنفيذ هذه العملية تلقائياً أو مراقبة النمو يدوياً.
مسؤولية إدارة الموارد
في بعض الحلول متعددة المستأجرين، يمكنك نشر موارد Azure مخصصة لكل مستأجر، مثل قاعدة بيانات لكل مستأجر. أو يمكنك تحديد عدد محدد من المستأجرين لاستضافتهم على مثيل واحد من مورد، وبالتالي فإن عدد المستأجرين لديك يملي مجموعة الموارد التي تقوم بنشرها في Azure. في الحلول الأخرى، يمكنك نشر مجموعة واحدة من الموارد المشتركة، ثم إعادة تكوين الموارد عند إعداد مستأجرين جدد.
يتطلب منك كل نموذج من هذه النماذج نشر الموارد وإدارتها بطرق مختلفة، ويجب أن تفكر في كيفية نشر وإدارة دورة حياة الموارد التي تقوم بتوفيرها. وهناك نهجان شائعان هما كما يلي:
- لمعاملة المستأجرين على أنهم تكوين الموارد التي تقوم بنشرها، واستخدم مسارات النشر لنشر هذه الموارد وتكوينها.
- لمعاملة المستأجرين كبيانات، ولديهم توفير وحدة تحكم وتكوين البنية الأساسية للمستأجرين.
ويرد أدناه مزيد من المناقشة لهذه النهج.
الاختبار
خطط لاختبار الحل خاصتك بدقة أثناء وبعد كل عملية نشر. يمكنك استخدام الاختبار التلقائي للتحقق من السلوك الوظيفي وغير الوظيفي للحل الخاص بك. تأكد من اختبار نموذج عزل المستأجر خاصتك، وفكر في استخدام أدوات مثل Azure Chaos Studio لتقديم أخطاء تحاكي حالات انقطاع التيار الكهربائي في العالم الحقيقي عمداً والتحقق من أن الحل خاصتك يعمل حتى عندما يكون أحد المكونات غير متوفر أو معطل.
النهج والأنماط التي ينبغي مراعاتها
ترتبط العديد من أنماط التصميم من مركز Azure Architecture Center والمجتمع الأوسع بنشر وتكوين الحلول متعددة المستأجرين.
نمط طوابع النشر
يتضمن نمط طوابع النشر نشر بنية تحتية مخصصة لمستأجر أو مجموعة من المستأجرين. قد يحتوي طابع واحد على مستأجرين متعددين، أو قد يكون مخصصاً لمستأجر واحد. يمكنك اختيار نشر طابع واحد، أو يمكنك تنسيق النشر عبر طوابع متعددة. إذا قمت بنشر طوابع مخصصة لكل مستأجر، فيمكنك أيضاً التفكير في نشر طوابع كاملة برمجياً.
حلقات النشر
حلقات النشر تمكنك من طرح التحديثات لمجموعات مختلفة من البنية التحتية في أوقات مختلفة. يتم استخدام هذا الأسلوب بشكل شائع مع نمط طوابع النشر، ويمكن تعيين مجموعات من الطوابع إلى حلقات مميزة استنادا إلى تفضيلات المستأجر وأنواع حمل العمل والاعتبارات الأخرى. لمزيد من المعلومات، راجع حلقات النشر.
علامات الميزة
تمكنك علامات الميزات من عرض ميزات أو إصدارات جديدة من الحل تدريجيا لمستأجرين مختلفين، بينما تحتفظ بقاعدة تعليمات برمجية واحدة. فكر في استخدام تكوين تطبيق Azure لإدارة علامات الميزات خاصتك. لمزيد من المعلومات، راجع علامات الميزات.
في بعض الأحيان تحتاج إلى تمكين ميزات محددة بشكل انتقائي لبعض العملاء. على سبيل المثال، قد يكون لديك مستويات مختلفة التسعير تسمح بالوصول إلى إمكانات معينة. لا تكون علامات الميزات عادة الخيار الصحيح لهذه السيناريوهات. بدلاً من ذلك، فكر في إنشاء عملية لتتبع وإنفاذ استحقاقات الترخيص التي يمتلكها كل عميل.
أنماط مضادة لتجنب
عند نشر الحلول متعددة المستأجرين وتكوينها، من المهم تجنب المواقف التي تمنع قدرتك على التوسع. ويشمل ذلك ما يلي:
- النشر والاختبار اليدويين. كما هو موضح أعلاه، تضيف عمليات النشر اليدوية مخاطر وتبطئ قدرتك على النشر. ضع في اعتبارك استخدام البنية الأساسية لبرنامج ربط العمليات التجارية لعمليات النشر التلقائية، أو إنشاء الموارد برمجيا من التعليمات البرمجية للحل الخاص بك، أو مزيج من كليهما.
- التخصيصات المتخصصة للمستأجرين. تجنب نشر ميزات أو تكوين ينطبق فقط على مستأجر واحد. يضيف هذا النهج تعقيداً إلى عمليات النشر والاختبار. بدلاً من ذلك، استخدم نفس أنواع الموارد وقاعدة التعليمات البرمجية لكل مستأجر، واستخدم استراتيجيات مثل علامات المعالم للتغييرات المؤقتة أو للميزات التي يتم طرحها تدريجيا، أو استخدم مستويات تسعير مختلفة مع استحقاقات الترخيص لتمكين الميزات بشكل انتقائي للمستأجرين الذين يحتاجون إليها. استخدم عملية نشر متسقة ومنفذة تلقائياً، حتى بالنسبة للمستأجرين الذين لديهم موارد معزولة أو مخصصة.
قوائم المستأجرين كتكوين أو بيانات
يمكنك مراعاة النهجين التاليين عند نشر الموارد في حل متعدد المستأجرين:
- استخدم مسار نشر تلقائي لنشر كل مورد. عند إضافة مستأجرين جدد، أعد تكوين المسار خاصتك لتوفير الموارد لكل مستأجر.
- استخدم مسار نشر تلقائي لنشر الموارد المشتركة التي لا تعتمد على عدد المستأجرين. بالنسبة للموارد التي يتم نشرها لكل مستأجر، قم بإنشائها داخل التطبيق خاصتك.
عند النظر في النهجين، يجب التمييز بين التعامل مع قائمة المستأجرين خاصتك على أنها تكوين أو كبيانات. هذا التمييز مهم أيضا عندما تفكر في كيفية إنشاء وحدة تحكم لنظامك.
قائمة المستأجرين كتكوين
عند التعامل مع قائمة المستأجرين الخاصة بك على أنها تكوين، فإنك توزع جميع مواردك من مسار توزيع مركزي. عند إعداد مستأجرين جدد، يمكنك إعادة تكوين مسار أو معلماته. عادة ما تتم إعادة التكوين من خلال التغييرات اليدوية، كما هو موضح في الرسم البياني التالي.
قد تكون عملية إعداد مستأجر جديد مشابهة لما يلي:
- تحديث قائمة المستأجرين. يحدث هذا عادةً يدوياً عن طريق تكوين المسار نفسه، أو عن طريق تعديل ملف معلمات مضمن في تكوين المسار.
- قم بتحفيز المسار لتشغيله.
- يقوم المسار بإعادة نشر مجموعتك الكاملة من موارد Azure، بما في ذلك أي موارد جديدة خاصة بالمستأجر.
يميل هذا النهج إلى العمل بشكل جيد مع أعداد صغيرة من المستأجرين، وللمباني المعمارية التي يتم فيها مشاركة جميع الموارد. إنه نهج بسيط لأنه يمكن نشر جميع موارد Azure وتكوينها باستخدام عملية واحدة.
ومع ذلك، عندما تقترب من عدد أكبر من المستأجرين، على سبيل المثال من 5 إلى 10 أو أكثر، يصبح من الصعب إعادة المسار أثناء إضافة مستأجرين. غالباً ما يزداد الوقت المستغرق لتشغيل مسار النشر بشكل كبير أيضاً. لا يدعم هذا النهج أيضاً إنشاء مستأجر الخدمة الذاتية بسهولة، ويمكن أن تكون المهلة الزمنية قبل إعداد المستأجر أطول لأنك تحتاج إلى تشغيل المسار خاصتك.
قائمة المستأجرين كبيانات
عند التعامل مع قائمة المستأجرين كبيانات، فإنك لا تزال تنشر المكونات المشتركة باستخدام مسار. ومع ذلك، بالنسبة للموارد وإعدادات التكوين التي يلزم نشرها لكل مستأجر، يمكنك حتما نشر الموارد أو تكوينها. على سبيل المثال، يمكن لوحدة التحكم الخاصة بك استخدام Azure SDKs لإنشاء مورد معين أو لبدء نشر قالب معلمات.
قد تكون عملية إعداد مستأجر جديد مشابهة لما يلي، وستحدث بشكل غير متزامن:
- طلب إلحاق مستأجر، مثل عن طريق بدء طلب واجهة برمجة التطبيقات إلى مستوى التحكم في النظام الخاص بك.
- يتلقى مكون سير العمل طلب الإنشاء وينسق الخطوات المتبقية.
- يبدأ سير العمل نشر الموارد الخاصة بالمستأجر إلى Azure. يمكن تحقيق ذلك باستخدام نموذج برمجة إلزامي، مثل استخدام Azure SDKs، أو عن طريق تشغيل نشر قالب Bicep أو Terraform بشكل إلزامي.
- عند اكتمال التوزيع، يحفظ سير العمل تفاصيل المستأجر الجديد في كتالوج المستأجر المركزي. قد تتضمن البيانات المخزنة لكل مستأجر معرف المستأجر ومعرفات الموارد لكافة الموارد الخاصة بالمستأجر التي أنشأها سير العمل.
من خلال القيام بذلك، يمكنك توفير الموارد للمستأجرين الجدد دون إعادة نشر الحل بأكمله. من المرجح أن يكون الوقت المستغرق في توفير موارد جديدة لكل مستأجر أقصر، لأن هذه الموارد فقط هي التي تحتاج إلى نشرها.
ومع ذلك، غالبا ما يكون هذا النهج أكثر استهلاكاً للوقت للبناء، ويجب تبرير الجهد الذي تنفقه بعدد المستأجرين أو الأطر الزمنية للتوفير التي تحتاج إلى الوفاء بها.
لمزيد من المعلومات حول هذا النهج، راجع اعتبارات مستويات التحكم متعددة المستأجرين.
ملاحظة
غالباً ما تستغرق عمليات توزيع وتكوين Azure وقتاً لإكمالها. تأكد من استخدام عملية مناسبة لبدء ومراقبة هذه العمليات طويلة الأمد. على سبيل المثال، قد تفكر في اتباع نمط الطلب والرد غير المتزامن. استخدم التقنيات المصممة لدعم العمليات طويلة الأمد، مثل Azure Logic Apps و الوظائف المتينة.
مثال
تدير Contoso حلاً متعدد المستأجرين لعملائها. حالياً، لديهم ستة مستأجرين، ويتوقعون النمو إلى 300 مستأجر في غضون الأشهر الـ 18 المقبلة. يتبع Contoso تطبيق Multitenant مع قواعد بيانات مخصصة لكل مستأجر نهج. لقد قاموا بنشر مجموعة واحدة من موارد App Service وخادم Azure SQL المنطقي الذي تتم مشاركته بين جميع المستأجرين لديهم، وقاموا بنشر قاعدة بيانات Azure SQL مخصصة لكل مستأجر، كما هو موضح في الرسم التخطيطي التالي.
يستخدم Contoso Bicep لنشر موارد Azure الخاصة بهم.
الخيار 1 - استخدام مسارات النشر لكل شيء
قد تفكر Contoso في نشر جميع مواردها باستخدام مسار نشر. يقوم المسار خاصتهم بنشر ملف Bicep يتضمن كافة موارد Azure الخاصة بهم، بما في ذلك قواعد بيانات Azure SQL لكل مستأجر. يعرف ملف معلمة قائمة المستأجرين، ويستخدم ملف Bicep حلقة الموارد لنشر قاعدة بيانات لكل من المستأجرين المدرجين، كما هو موضح في الرسم التخطيطي التالي.
إذا اتبعت Contoso هذا النموذج، فستحتاج إلى تحديث ملف المعلمة الخاص بها كجزء من إعداد مستأجر جديد. ثم يحتاجون إلى إعادة تشغيل المسار الخاص بهم. كما أنها تحتاج إلى تتبع ما إذا كانت قريبة من أي حدود يدوياً، مثل ما إذا كانت تنمو بمعدل مرتفع بشكل غير متوقع وتقترب من الحد الأقصى لعدد قواعد البيانات المدعومة على خادم منطقي Azure SQL واحد.
الخيار 2 - استخدام مزيج من مسارات النشر وإنشاء الموارد الضرورية
بدلاً من ذلك، قد تفكر Contoso في فصل المسؤولية عن عمليات نشر Azure.
يستخدم Contoso ملف Bicep يحدد الموارد المشتركة التي يجب نشرها. تدعم الموارد المشتركة جميع المستأجرين وتتضمن قاعدة بيانات خريطة المستأجر، كما هو موضح في الرسم البياني التالي.
ثم يقوم فريق Contoso بإنشاء وحدة تحكم تتضمن مستأجرا يقوم بإلحاق واجهة برمجة التطبيقات. عندما يكمل فريق المبيعات عملية البيع إلى عميل جديد، يقوم Microsoft Dynamics بتشغيل واجهة برمجة التطبيقات لبدء عملية الإعداد. يوفر Contoso أيضاً واجهة ويب ذاتية الخدمة للعملاء لاستخدامها، وهذا يؤدي إلى تشغيل واجهة برمجة التطبيقات أيضاً.
تبدأ واجهة برمجة التطبيقات بشكل غير متزامن سير عمل يقوم بإعداد المستأجرين الجدد. يبدأ سير العمل نشر قاعدة بيانات Azure SQL جديدة، والتي يمكن القيام بها بواسطة أحد الأساليب التالية:
- استخدم Azure SDK لبدء نشر ملف Bicep ثان يعرف قاعدة بيانات Azure SQL.
- استخدم Azure SDK لإنشاء قاعدة بيانات Azure SQL بشكل إلزامي، باستخدام مكتبة الإدارة.
بعد نشر قاعدة البيانات، يضيف سير العمل المستأجر إلى قاعدة بيانات قائمة المستأجرين، كما هو موضح في الرسم التخطيطي التالي.
يتم بدء تحديثات مخطط قاعدة البيانات المستمرة حسب طبقة التطبيق الخاصة بهم.
المساهمون
هذه المقالة تحتفظ بها Microsoft. تمت كتابتها في الأصل من قِبل المساهمين التاليين.
الكاتب الرئيسي:
- جون داونز | مهندس العملاء الرئيسي، FastTrack ل Azure
مساهمون آخرون:
- بوهدان شيرشيك | مهندس عملاء أول، FastTrack لـAzure
- Arsen Vladimirskiy | مهندس العملاء الرئيسي، FastTrack for Azure
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
- راجع اعتبارات تحديث حل متعدد المستأجرين.
- النظر في النهج المعمارية للتخزين والبيانات.
- ضع في اعتبارك كيفية استخدام Azure Resource Manager في حل متعدد المستأجرين.