مشاركة عبر

اعتبارات مورد البرامج المستقل (ISV) لمناطق هبوط Azure

  • مقالة

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

تلميح

قد يكون من المفيد التفكير في مناطق هبوط Azure على أنها تشبه خطط المدينة. بنى أحمال العمل المنتشرة في منطقة الهبوط تشبه خطط المباني في المدينة.

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

بصفتك بائع برامج مستقل (ISV) يقوم بإنشاء الحل وتشغيله على Azure، يجب عليك الرجوع إلى الموارد التالية أثناء إنشاء بيئة Azure الخاصة بك:

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

  • يمكنك إنشاء برامج ينشرها العملاء في اشتراكاتهم الخاصة.
  • لديك مستوى التحكم الخاص بك وتستخدم البرامج النصية التلقائية أو البرامج لتوزيع موارد Azure وتكوينها لحلول SaaS الخاصة بك.
  • أنت ISV صغير أو بدء تشغيل وتريد البدء بأقل تكلفة ممكنة، وقد لا ترغب في استخدام خدمات مثل Azure Firewall وAzure DDoS Protection في البداية.
  • أنت SaaS ISV كبير وتخطط لتقسيم تطبيق SaaS الخاص بك عبر اشتراكات متعددة للمقياس. تريد أيضا تجميع الاشتراكات بحيث تتوافق مع بيئات التطوير والاختبار والتقسيم المرحلي والإنتاج.
  • يفصل نموذج التشغيل الخاص بمؤسستك أدوار فريق تكنولوجيا المعلومات في شركتك وفرق منتجات SaaS. قد يدير فريق تكنولوجيا المعلومات في مؤسستك موارد مثل Microsoft Office 365 وMicrosoft Teams، وقد يكون فريق منتج SaaS مسؤولا عن إنشاء منتج SaaS وتشغيله (بما في ذلك النظام الأساسي المركزي ومكونات الهوية).

ملاحظة

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

نماذج توزيع ISV

غالبا ما تتناسب حلول ISV مع أحد نماذج التوزيع الثلاثة: SaaS النقي أو الموزع من قبل العميل أو SaaS ثنائي التوزيع. يصف هذا القسم الاعتبارات المختلفة لكل نموذج لمناطق هبوط Azure.

Pure SaaS

في نموذج SaaS النقي، يتم نشر برنامجك بالكامل فقط في اشتراكات Azure الخاصة بك. يستهلك العملاء النهائيون برنامجك دون توزيعه في اشتراكات Azure الخاصة بهم. في الرسم التخطيطي التالي، يستخدم المستخدمون تطبيق SaaS خالص يوفره ISV:

رسم تخطيطي يوضح نموذج توزيع SaaS خالص. يستخدم المستخدم مباشرة التطبيق المنشور في اشتراك Azure الخاص ب I S V.

تتضمن أمثلة برامج SaaS النقية البريد الإلكتروني كخدمة، وKafka-as-a-service، وcloud-data-warehouse-as-a-service، والعديد من قوائم SaaS في Azure Marketplace.

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

يجب أن تأخذ ISVs التي تبني حلول SaaS النقية في الاعتبار الأسئلة التالية:

  • هل يجب أن تكون جميع موارد Azure التي تشكل حل SaaS الخاص بنا في اشتراك Azure واحد، أو مقسمة عبر اشتراكات Azure متعددة؟
  • هل يجب علينا استضافة كل عميل في اشتراك Azure المخصص الخاص به، أم يمكننا إنشاء موارد ضمن اشتراك واحد أو عدد قليل من الاشتراكات المشتركة؟
  • كيف يمكننا تطبيق نمط طابع النشر (وحدة المقياس) على جميع مستويات الحل لدينا؟
  • كيف يمكننا استخدام تنظيم موارد Azure في حلول متعددة المستأجرين لمنعنا من مواجهة تحديات النطاق وحدود اشتراك Azure؟

تم نشر العميل

في النموذج الذي نشره العميل، يشتري عملاؤك النهائيون البرامج منك ثم ينشرونها في اشتراكات Azure الخاصة بهم. قد يبدأون التوزيع من Azure Marketplace، أو يقومون بذلك يدويا باتباع الإرشادات واستخدام البرامج النصية التي تقدمها.

في الرسم التخطيطي التالي، يوفر ISV حزمة برامج أو منتج كتالوج Azure Marketplace، وينشر المستخدمون هذا المورد في اشتراكات Azure الخاصة بهم جنبا إلى جنب مع أحمال العمل الأخرى الخاصة بهم:

رسم تخطيطي يوضح نموذج توزيع تم نشره من قبل العميل. ينشر العميل الموارد التي يوفرها ISV في اشتراك Azure الخاص به، ويستخدم المستخدمون هذه الموارد.

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

تتضمن أمثلة منتجات ISV التي ينشرها العميل العديد من صور الجهاز الظاهري (مثل الأجهزة الظاهرية للشبكة والتخزين) وتطبيقات Azure في Azure Marketplace.

بالنسبة لبعض الحلول التي ينشرها العميل، قد توفر المؤسسة إدارة الحل المنشور داخل اشتراكات Azure للعميل النهائي وتحديثاته باستخدام Azure Lighthouse أو تطبيقات Azure المدارة. يمكن لجميع ISVs و Solution Integrators (SIs) وموفري الخدمات المدارة (MSPs) استخدام هذه الاستراتيجية عندما تلبي احتياجاتهم الخاصة.

تعتبر حلول ISV التي ينشرها العميل حمل عمل تطبيق قياسي من منظور مناطق هبوط Azure. ضع في اعتبارك إرشادات مناطق هبوط Azure أثناء تصميم منتجك للعمل مع مبادئ تصميم مناطق هبوط Azure التي يعتمدها عملاؤك في Azure.

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

يجب أن تأخذ ISVs التي تبني حلولا موزعة من قبل العملاء في الاعتبار الأسئلة التالية:

  • هل يجب على العميل نشر حلنا في اشتراكه المخصص الخاص أو في اشتراك موجود يحتوي على أحمال عمل ذات صلة؟
  • كيف يجب على العملاء إنشاء اتصال بالشبكة بين أحمال العمل الحالية (داخل وخارج Azure) وحلنا؟
  • هل يدعم الحل آليات المصادقة من Azure Active Directory (Azure AD) أو يتطلب بروتوكولات أخرى مثل LDAP أو Kerberos؟
  • كيف يمكننا تقليل انتهاكات نهج Azure أو إزالتها، مثل تلك التي تسببها التعارضات بين قوالب الحل ونهج Azure للعميل؟

تتضمن نهج Azure للعميل التي يمكن أن تتسبب في انتهاكات نهج Azure أمثلة مثل "يجب أن تحتوي جميع الشبكات الفرعية على مجموعة أمان شبكة" و"لا يمكن إرفاق عناوين IP عامة بواجهات الشبكة في منطقة هبوط Corp". ضع في اعتبارك إمكانية هذه النهج المسببة للتعارض أثناء التخطيط للتوزيع.

خدمة تأجير البرامج (SaaS) للتوزيع المزدوج

تتفاعل بعض حلول SaaS مع الموارد التي يتم نشرها في اشتراكات Azure للعملاء أو تستخدمها. يسمى نموذج التوزيع هذا أحيانا SaaS أو SaaS المختلط للتوزيع المزدوج. في الرسم التخطيطي التالي، يوفر ISV حل SaaS مستضافا يتفاعل مع الموارد المنشورة في اشتراك Azure للعميل النهائي:

رسم تخطيطي يوضح نموذج توزيع SaaS للتوزيع المزدوج.

مثال حقيقي على SaaS للتوزيع المزدوج هو Microsoft Power BI، وهي خدمة SaaS يمكنها اختياريا استخدام بوابة بيانات محلية ل Power BI تم نشرها على جهاز ظاهري في اشتراك Azure للعميل.

تتضمن الأمثلة الأخرى لسيناريوهات SaaS للتوزيع المزدوج ما يلي:

  • تنشئ مؤسستك Virtual Desktop Manager، وهو منتج يوفر واجهة وحدة تحكم SaaS للتحكم في موارد Azure Virtual Desktop في اشتراك Azure لكل عميل.
  • توفر مؤسستك وحدة تحكم SaaS لتحليلات البيانات، وتقوم بإنشاء وحذف الأجهزة الظاهرية لعقدة الحساب ديناميكيا في اشتراك Azure لكل عميل.

ك ISV للتوزيع المزدوج، يجب عليك الرجوع إلى منطقة Azure المنتقل إليها للحصول على إرشادات في منطقتين: هيكلة بيئة Azure الخاصة بك لاستضافة خدمة SaaS الخاصة بك، وضمان التفاعل المناسب بين عمليات التوزيع الخاصة بك في اشتراكات Azure للعملاء ومناطق هبوط عملائك.

يجب أن تأخذ ISVs التي تنشئ حلول SaaS ذات التوزيع المزدوج في الاعتبار الأسئلة التالية:

  • هل راجعنا جميع الاعتبارات لبناء كل من حلول SaaS النقية والحلول التي ينشرها العملاء؟
  • ما مكونات الحل الذي يجب استضافته في اشتراكات Azure، وما هي المكونات التي يجب توزيعها من قبل العملاء؟
  • كيف يمكننا ضمان التزويد الآمن والتفاعلات مع الموارد المنشورة في اشتراكات Azure لعملائنا؟

مبادئ وتنفيذات تصميم منطقة Azure المنتقل إليها

توصي مبادئ تصميم المنطقة المنتقل إليها في Azure بالتوافق مع إمكانات النظام الأساسي الأصلي ل Azure مثل Log Analytics وAzure Monitor وAzure Firewall. توفر إرشادات المنطقة المنتقل إليها أيضا خيارات تنفيذ منطقة هبوط Azure محددة.

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

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

مستأجرو Azure AD

يتم جذر كل منطقة هبوط Azure والتسلسل الهرمي لمجموعة الإدارة الخاصة بها في مستأجر Azure Active Directory (Azure AD) واحد. وهذا يعني أن القرار الأول الذي تحتاج إلى اتخاذه هو Azure AD المستأجر لاستخدامه كمصدر للهويات لإدارة موارد Azure. تتضمن الهويات في Azure AD المستخدمين والمجموعات وكيانات الخدمة.

تلميح

لا يؤثر المستأجر Azure AD الذي تحدده للمنطقة المنتقل إليها على المصادقة على مستوى التطبيق. لا يزال بإمكانك استخدام موفري الهوية الآخرين مثل Azure AD B2C بغض النظر عن المستأجر الذي تختاره.

توصي إرشادات مناطق هبوط Azure والمستأجرين Azure AD بشدة باستخدام مستأجر Azure AD واحد، وهذا هو النهج الصحيح لمعظم المواقف. ومع ذلك، ك SaaS ISV، قد يكون لديك سبب لاستخدام مستأجرين.

بالنسبة لبعض SaaS ISVs، يدير فريق واحد موارد الشركة ويدير فريق منفصل حل SaaS. يمكن أن يكون هذا الفصل لأسباب تشغيلية أو للامتثال للمتطلبات التنظيمية. ربما لا يسمح لفريق تكنولوجيا المعلومات في شركتك بإدارة أي اشتراكات وموارد متعلقة ب SaaS، لذلك لا يمكن أن يكونوا مسؤولين عن المستأجر Azure AD. إذا كان هذا السيناريو ينطبق عليك، ففكر في استخدام مستأجرين منفصلين Azure AD: مستأجر واحد لموارد تكنولوجيا المعلومات للشركات مثل Office 365، ومستأجر واحد لموارد Azure التي تشكل حل SaaS الخاص بك.

يجب أن يكون لكل مستأجر Azure AD اسم المجال الخاص به. إذا كانت مؤسستك تستخدم مستأجرين اثنين، فقد تختار اسما مثل contoso.com لمستأجر Azure AD شركتك ولمستأجر contoso-saas-ops.com Azure AD SaaS، كما هو موضح في الرسم التخطيطي التالي.

رسم تخطيطي يوضح Azure AD خيارات المستأجر ل ISVs مع مستأجر شركة واحد أو الفصل بين مستأجري الشركات وSaaS Ops.

تحذير

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

تجنب استخدام مستأجرين Azure AD منفصلين لبيئات ما قبل الإنتاج والإنتاج. بدلا من إنشاء مستأجرين مثل contoso-saas-ops-preprod.com و contoso-saas-ops-prod.com مع اشتراكات Azure منفصلة ضمن كل منهما، يجب عليك إنشاء مستأجر Azure AD واحد. يمكنك استخدام مجموعات الإدارة وAzure RBAC للتحكم في الوصول إلى الاشتراكات والموارد ضمن هذا المستأجر الفردي.

لمزيد من المعلومات حول استخدام مستأجرين متعددين Azure AD، راجع مناطق هبوط Azure ومستأجري Azure Active Directory المتعددينوتأمين بيئات Azure باستخدام المستند التقني ل Azure Active Directory.

مجموعات الإدارة

توصي البنية المفاهيمية لمنطقة Azure المنتقل إليها باستخدام التسلسل الهرمي لمجموعة إدارة معينة. ومع ذلك، يمكن أن يكون لم ISVs متطلبات مختلفة عن المؤسسات الأخرى. يصف هذا القسم بعض الطرق التي قد تختار بها مؤسسة ISV اعتماد ممارسات مختلفة عما توصي به البنية المفاهيمية للمنطقة المنتقل إليها.

مجموعة إدارة المستوى الأعلى

يتم تضمين التسلسل الهرمي لمجموعة الإدارة ضمن مجموعة إدارة مجموعة جذر المستأجر التي أنشأتها Azure. لا تستخدم مجموعة جذر المستأجر مباشرة.

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

ك SaaS ISV، قد يكون لديك منتج SaaS واحد أو قد يكون لديك بعض منتجات أو خطوط عمل SaaS منفصلة. بينما يجب عليك استخدام نفس المستأجر Azure AD بشكل عام لإدارة موارد Azure عبر جميع منتجاتك (كما تمت مناقشته في قسم المستأجرين Azure AD)، في بعض السيناريوهات قد تختار توزيع تسلسلات هرمية متعددة لمجموعة الإدارة.

ضع في اعتبارك مدى استقلالية منتجاتك عن بعضها البعض، واسأل نفسك:

  • هل تستخدم جميع منتجاتنا نفس الأنظمة الأساسية ل DevOps والهوية والأمان والاتصال والتسجيل؟
  • هل هذه الخدمات المشتركة يديرها فريق مركزي واحد؟

إذا أجبت بنعم على كلا السؤالين، فقم بإنشاء مجموعة إدارة منتجات SaaS واحدة من المستوى الأعلى ضمن مجموعة جذر المستأجر.

إذا أجبت بدلا من ذلك بالرفض، وكان كل منتج من منتجات SaaS الخاص بك تتم إدارته وتشغيله بواسطة فرق نظام أساسي منفصلة، ففكر في إنشاء مجموعة إدارة منفصلة من المستوى الأعلى لكل منتج، مثل مجموعتي إدارة المستوى الأعلى SaaS Product-01وSaaS Product-02.

تلميح

من غير المألوف أن يكون لدى أحد ISV أكثر من عدد قليل من مجموعات الإدارة ذات المستوى الأعلى. في كثير من الأحيان، يمكن دمج العديد من المنتجات معا بسبب أوجه التشابه في كيفية إدارتها وتشغيلها.

يشبه نهج الإدارة هذا نهج الاختبار لمناطق الهبوط على نطاق المؤسسة. ومع ذلك، بدلا من إنشاء ContosoوContoso-Canary ضمن مجموعة جذر المستأجر، في هذا النهج، ستقوم الشركة المثال بإنشاء مجموعات إدارة Contoso-SaaS-Product-01وContoso-SaaS-Product-02وContoso-SaaS-Product-03 ذات المستوى الأعلى ضمنها بدلا من ذلك. يوضح هذا السيناريو في الرسم التخطيطي التالي:

رسم تخطيطي يوضح خيارات مجموعة الإدارة ذات المستوى الأعلى مع مجموعة إدارة واحدة ومجموعات إدارة منفصلة لكل منتج من منتجات SaaS

مجموعة إدارة النظام الأساسي

في التسلسل الهرمي لتنظيم موارد منطقة Azure المنتقل إليها، تحتوي مجموعة إدارة النظام الأساسي على جميع اشتراكات Azure التي تستضيف المكونات والخدمات المشتركة التي تستخدمها أحمال العمل في اشتراكات المنطقة المنتقل إليها. تتضمن أمثلة المكونات المنشورة في النظام الأساسي واشتراكات الخدمات المشتركة البنية الأساسية المركزية للتسجيل (مثل مساحات عمل Log Analytics) وDevOps والأمان والأدوات الآلية وموارد الشبكات المركزية (مثل خطط hub-VNet وDDos Protection) وخدمات مستوى التحكم في ISV.

يتم تقسيم مجموعة إدارة النظام الأساسي بشكل متكرر إلى مجموعات تابعة للهويةوالإدارةوالاتصال لتوفير فصل مناسب للأدوار والسياسات لعملاء المؤسسات.

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

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

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

رسم تخطيطي يوضح تسلسلين هرميين لمجموعة الإدارة. يعرض الخيار A مجموعات منفصلة لإدارة النظام الأساسي للإدارة والاتصال والهوية. يتضمن الخيار B خيار مجموعة إدارة النظام الأساسي مع مجموعة إدارة واحدة.

مجموعة إدارة المناطق المنتقل إليها

تحتوي مجموعة إدارة المناطق المنتقل إليها على اشتراكات Azure التي تستضيف الأنظمة الفرعية الفعلية لحل SaaS وأحمال العمل.

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

  • الامتثال: إذا كان النظام الفرعي لمنتج SaaS الخاص بك يحتاج إلى أن يكون متوافقا مع PCI-DSS، ففكر في إنشاء مجموعة إدارة تابعة ل PCI DSS الأصلية ضمن مناطق الهبوط. يجب وضع جميع اشتراكات Azure التي تحتوي على موارد ضمن نطاق توافق PCI-DSS ضمن مجموعة الإدارة هذه.
  • مستويات: ضع في اعتبارك إنشاء نماذج منفصلة للمنطقة المنتقل إليها لعملاء الطبقة المخصصة لحل SaaS وعملاء المستوى المجاني . تحتوي كل مجموعة من مجموعات الإدارة التابعة على إعدادات نهج Azure مختلفة. على سبيل المثال، قد تقيد النهج في المستوى المجاني عمليات التوزيع لتمكين وحدات SKU معينة للجهاز الظاهري فقط، وقد تتطلب النهج في المستوى المخصص توزيع الموارد في مناطق معينة.

مجموعات الإدارة الخاصة بالبيئة

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

أحد الاختلافات الشائعة بين البيئات هو قواعد Azure RBAC الخاصة بها، مثل من يمكنه الوصول إلى كل مجموعة من الاشتراكات. على سبيل المثال، قد يكون لدى فرق DevOps وSaaSOps والتطوير والاختبار مستويات مختلفة من الوصول إلى بيئات مختلفة.

هام

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

ومع ذلك، يمكن أن يكون ل SaaS ISVs متطلبات مختلفة عن معظم عملاء Azure الآخرين، وقد يكون لديهم سبب وجيه لاستخدام مجموعات الإدارة الخاصة بالبيئة في بعض الحالات.

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

توضح الرسومات التخطيطية التالية خيارين محتملين. يعرض الخيار A سيناريو مع اشتراكات منفصلة لكل بيئة ولكن لا توجد مجموعات إدارة خاصة بالبيئة. يعرض الخيار B سيناريو SaaS ISV مع مجموعات إدارة خاصة بالبيئة ضمن مجموعة إدارة الطوابع العادية . تحتوي كل مجموعة إدارة خاصة بالبيئة على اشتراكات متعددة. مع مرور الوقت، يقوم ISV بتغيير حجم موارد Azure الخاصة به في كل بيئة عبر عدد متزايد من الاشتراكات مع مجموعة مشتركة من النهج وتعيينات الأدوار.

حدد كل علامة تبويب لمشاهدة الرسمين التخطيطيين.

مجموعات الإدارة التي تم إيقاف تشغيلها وبيئة الاختبار المعزولة

توصي إرشادات مؤسسة موارد منطقة Azure المنتقل إليها بما في ذلك مجموعات إدارة Decommissioned و Sandboxes أسفل مجموعة الإدارة ذات المستوى الأعلى مباشرة.

مجموعة الإدارة التي تم إيقاف تشغيلها هي مكان الاحتفاظ لاشتراكات Azure التي يتم تعطيلها وسيتم حذفها في النهاية. يمكنك نقل اشتراك لم يعد قيد الاستخدام إلى مجموعة الإدارة هذه لتعقبه حتى يتم حذف جميع الموارد في الاشتراك نهائيا.

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

هام

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

يوضح الرسم التخطيطي التالي خيارين محتملين. لا يتضمن الخيار A مجموعات إدارة Decommissioned و Sandbox ، بينما الخيار B يتضمن ذلك.

رسم تخطيطي يوضح مجموعات إدارة Decommissioned و Sandboxes على نفس مستوى مجموعات إدارة النظام الأساسي والمناطق المنتقل إليها.

مثال على مناطق هبوط ISV

يتضمن هذا القسم مثالين على بنيات منطقة هبوط Azure ل SaaS ISV. حدد كل علامة تبويب لمقارنة مثالي المناطق المنتقل إليها.

يوضح الرسم التخطيطي التالي مثالا على التسلسل الهرمي لمناطق هبوط SaaS ISV Azure مع الخصائص التالية:

رسم تخطيطي يوضح مثالا للتسلسل الهرمي لمنطقة هبوط Azure ل ISV. يتم حذف معظم المكونات من هذه المقالة.

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