مشاركة عبر

نقل بيئات Azure الحالية إلى التصميم الأساسي لمنطقة Azure المنتقل إليها

  • مقالة

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

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

نقل الموارد في Azure

يمكن نقل بعض الموارد في Azure بعد الإنشاء، وهناك أساليب مختلفة يمكن للمؤسسات أن تخضع لأذونات Azure RBAC للمستخدمين في - وعبر النطاقات. يوضح الجدول التالي الموارد التي يمكن نقلها، وفي أي نطاق، والمحترفين/السلبيات المرتبطة بكل منها.

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

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

نقل الاشتراك

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

متطلبات التحكم في الوصول استنادا إلى الدور في Azure

لتقييم اشتراك قبل النقل، من المهم أن يكون لدى المستخدم Azure RBAC المناسب مثل كونه مالكا للاشتراك (تعيين الدور المباشر)، وأن يكون لديه إذن الكتابة في مجموعة الإدارة الهدف (الأدوار المضمنة التي تدعم هذا هي دور المالك ودور المساهم ودور المساهم في مجموعة الإدارة).

إذا كان لدى المستخدم إذن دور المالك الموروث على الاشتراك من مجموعة إدارة موجودة، يمكن نقل الاشتراك فقط إلى مجموعة الإدارة حيث تم تعيين دور المالك للمستخدم.

النهج

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

يمكن استخدام Azure Resource Graph لإجراء مخزون للموارد الموجودة ومقارنة تكوينها بالنهج الموجودة في الوجهة.

بمجرد نقل الاشتراكات إلى مجموعة إدارة مع Azure RBAC والنهج الموجودة، ضع في اعتبارك الخيارات التالية:

  • يمكن أن يستغرق أي Azure RBAC موروث إلى الاشتراكات المنقولة ما يصل إلى 30 دقيقة قبل تحديث رموز المستخدم المميزة في ذاكرة التخزين المؤقت لمجموعة الإدارة. لتسريع هذه العملية، يمكنك تحديث الرمز المميز عن طريق تسجيل الخروج وتسجيل الدخول أو طلب رمز مميز جديد.
  • أي نهج يتضمن فيه نطاق التعيين الاشتراكات المنقولة، سينفذ عمليات التدقيق فقط على الموارد الموجودة. أكثر تحديدًا:
    • سيظهر أي مورد موجود في الاشتراك خاضع لتأثير DeployIfNotExists نهج على أنه غير متوافق ولن تتم معالجته تلقائيا ولكنه يتطلب تفاعل المستخدم لإجراء المعالجة يدويا.
    • سيظهر أي مورد موجود في الاشتراك الخاضع Deny لتأثير النهج على أنه غير متوافق ولن يتم رفضه. يجب على المستخدم التخفيف يدويا من هذه النتيجة حسب الاقتضاء.
    • سيظهر أي مورد موجود في الاشتراك الخاضع AppendModify وتأثير النهج على أنه غير متوافق ويتطلب تفاعل المستخدم للتخفيف من حدته.
    • سيظهر أي مورد موجود في الاشتراك الخاضع AuditAuditIfNotExist وتأثير النهج على أنه غير متوافق ويتطلب تفاعل المستخدم للتخفيف من حدته.
  • تخضع جميع عمليات الكتابة الجديدة إلى الموارد في الاشتراك المنقول للنهج المعينة في الوقت الفعلي كالمعتاد.

نقل الموارد

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

عند إجراء نقل مورد، يتم تأمين كل من مجموعة الموارد المصدر ومجموعة الموارد الهدف (لن يؤثر هذا التأمين على أي من الموارد في مجموعة الموارد) أثناء عملية النقل، ما يعني أنه لا يمكنك إضافة الموارد أو تحديثها أو حذفها في مجموعات الموارد. لن تغير عملية نقل الموارد موقع الموارد.

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

قبل نقل الموارد

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

عملية ما بعد النقل

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

السيناريوهات

لقد قدمنا إرشادات في السيناريوهات: نقل بيئات Azure الحالية إلى البنية المفاهيمية لمنطقة Azure المنتقل إليها للسيناريوهات الشائعة التي قد يطابقها عملاؤنا، أو تكون مشابهة لها، والتي يرغبون في ترحيلها والانتقال منها إلى البنية المفاهيمية لمنطقة Azure المنتقل إليها.

سيناريوهات المراجعة: نقل بيئات Azure الحالية إلى البنية المفاهيمية لمنطقة Azure المنتقل إليها