إدارة مشاريع Azure Migrate على نطاق واسع باستخدام Azure Lighthouse

يوفر هذا الموضوع نظرة عامة حول كيفية مساعدة Azure Lighthouse في استخدام Azure Migrate بطريقة قابلة للتطوير عبر العديد من مستأجري Microsoft Entra.

يتيح Azure Lighthouse لموفري الخدمات إجراء العمليات التي تغير الحجم عبر عدة مستأجرين في وقت واحد، مما يزيد فاعلية مهام الإدارة.

يقدم ترحيل Azure مركزًا محوريًا لتقييم الخوادم المحلية والبنية الأساسية والتطبيقات والبيانات الخاصة بـ Azure وترحيلهما.

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

تلميح

بالرغم من أننا نشير إلى موفري الخدمات والعملاء في هذا الموضوع، فإن هذا الإرشاد ينطبق أيضاً على المؤسسات التي تستخدم Azure Lighthouse لإدارة عدة مستأجرين.

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

إشعار

باستخدام Azure Lighthouse، يمكن للشركاء إجراء الاكتشاف والتقييم والترحيل لأجهزة VMware الظاهرية المحلية وأجهزة Hyper-V الظاهرية والخوادم الفعلية ومثيلات AWS/GCP. بالنسبة لترحيل VMware VM، يمكن استخدام طريقة الترحيل المستندة إلى العامل فقط لمشروع ترحيل في اشتراك عميل مفوض. الترحيل باستخدام النسخ المتماثل بدون عامل غير مدعوم حاليا من خلال الوصول المفوض إلى نطاق العميل.

إنشاء مشروع Azure Migrate في مستأجر العميل

إن أحد الخيارات عند استخدام Azure Lighthouse هو إنشاء مشروع Azure Migrate في مستأجر العميل. يمكن للمستخدمين في المستأجر الإداري بعد ذلك تحديد اشتراك العميل عند إنشاء مشروع الترحيل. من المستأجر الإداري، يمكن لموفر الخدمة تنفيذ عمليات الترحيل اللازمة. قد يتضمن ذلك نشر جهاز Azure Migrate لاكتشاف أحمال العمل، مما يُقيم أحمال العمل عن طريق تجميع «الأجهزة الظاهرية» وحساب التكاليف المتعلقة بالسحابة، ومراجعة جاهزية «الجهاز الظاهري»، وتنفيذ الترحيل.

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

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

سيتشابه سير العمل لهذا النموذج مع ما يلي:

  1. يتم إلحاق العميل بـ Azure Lighthouse. إن الدور المضمن «للمساهم» مطلوب للهوية التي سيتم استخدامها في Azure Migrate. راجع قالب نموذج delegated-resource-management-azmigrate لرؤية مثال يستخدم هذا الدور. تأكد من تعديل ملف المعلمة لتُظهر بيئتك قبل نشر القالب.

  2. يسجل المستخدم المُعيّن الدخول إلى المستأجر الإداري في مدخل Azure، ثم ينتقل إلى Azure Migrate. يقوم هذا المستخدم بإنشاء مشروع Azure Migrate، مُحدّدًا اشتراك العميل المفوض المناسب.

  3. ثم يقوم المستخدم بتنفيذ خطوات للاكتشاف والتقييم.

    بالنسبة إلى أجهزة VMware الظاهرية، قبل تكوين الجهاز، يمكنك أن تُقصر الاكتشاف على مراكز بيانات خادم vCenter، أو المجموعات أو مجلد من المجموعات، أو المضيفين، أو مجلد المضيفين، أو «الأجهزة الظاهرية» الفردية. لتعيين النطاق، قم بتعيين أذونات على الحساب الذي يستخدمه الجهاز للوصول إلى خادم vCenter. يكون ذلك مفيدًا إذا تم استضافة أجهزة ظاهرية متعددة للعملاء على برنامج hypervisor. لا يمكنك الحد من نطاق اكتشاف Hyper-V.

    إشعار

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

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

تلميح

قبل الترحيل، يجب نشر منطقة هبوط لتوفير موارد البنية الأساسية وإعداد الاشتراك الذي سيتم ترحيل الأجهزة الظاهرية إليه. قد يكون الدور المضمن للمالك مطلوبا للوصول إلى بعض الموارد أو إنشائها في منطقة الهبوط هذه. نظرا لأن هذا الدور غير مدعوم حاليا في Azure Lighthouse، فقد يحتاج العميل إلى توفير وصول الضيف إلى موفر الخدمة، أو تفويض وصول المسؤول عبر نموذج اشتراك Cloud Solution Provider (CSP).

لمزيد من المعلومات حول المناطق المنتقل إليها متعددة المستأجرين، راجع الاعتبارات والتوصيات لسيناريوهات منطقة هبوط Azure متعددة المستأجرين والحل التجريبي لمناطق الهبوط متعددة المستأجرين على GitHub.

إنشاء مشروع Azure Migrate في المستأجر الإداري

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

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

سيتشابه سير العمل لهذا النموذج مع ما يلي:

  1. يتم إلحاق العميل بـ Azure Lighthouse. إن الدور المضمن «للمساهم» مطلوب للهوية التي سيتم استخدامها في Azure Migrate. راجع قالب نموذج delegated-resource-management-azmigrate لرؤية مثال يستخدم هذا الدور. تأكد من تعديل ملف المعلمة لتُظهر بيئتك قبل نشر القالب.

  2. يسجل المستخدم المُعيّن الدخول إلى المستأجر الإداري في مدخل Azure، ثم ينتقل إلى Azure Migrate. ينشئ هذا المستخدم مشروع Azure Migrate في اشتراك ينتمي إلى المستأجر الإداري.

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

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

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

التعرف على الشريك لترحيل العملاء

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

لمزيد من المعلومات، راجع ربط معرف شريك.

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