AWS Transform: نقل سحابة VMware على AWS إلى Amazon EC2 باستخدام الذكاء الاصطناعي الوكيل

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

منظر جوي للأشجار والطريق مع سيارة صفراء أو شاحنة تسير عليها

المؤلفون

Matt Lewis

Chief AWS Architect

Arnaud Lauer

Partner Solution Architect

AWS

Tarun Chawla

Senior Solutions Architect

AWS

تعد AWS Transform for VMware، المتاحة الآن للجميع، خدمة جديدة تستخدم الذكاء الاصطناعي الوكيل لتوجيه العملاء خلال رحلة الترحيل بأكملها. وتساعد هذه الخدمة المجموعات على تبسيط عمليات الترحيل وتسريعها من بيئات VMware إلى خدمات AWS الأصلية. وتوفر الأتمتة بمساعدة الذكاء الاصطناعي طوال دورة حياة الترحيل، ما يقلل بشكل كبير من التعقيد والجهد المرتبطين عادةً بعمليات الترحيل السحابية.

تقوم IBM® Consulting بدعم VMware Cloud الشامل على AWS لإدارة رئيسية في القطاع العام في المملكة المتحدة. ونظرًا لأن هذا القسم لديه توجه إستراتيجي للسحابة الأصلية، فإن الخطوة الأولى المنطقية هي إعادة استضافة التطبيقات من سحابة VMware على AWS إلى Amazon EC2. وقد قلل هذا النهج من مخاطر تعرضهم لممارسات الترخيص التقليدية، بما في ذلك الإغلاق والزيادات الشديدة في الأسعار.

بالتعاون مع AWS، قامت IBM® Consulting بتطبيق VMCloud على AWS لترحيل التطبيقات القديمة من Windows بشكل منهجي إلى Amazon EC2. ومن خلال هذه العملية، نجحوا في استخدام AWS Transform لتقليل جهد الترحيل بنسبة 60% للمهام المؤتمتة مع الحفاظ على وظائف التطبيق الكاملة والأمان. ويوفر النهج الآتي—بدءًا من اختيار التطبيق المستهدف مرورًا بمراحل الترحيل—إطار عمل قابل للتكرار، يمكن للمؤسسات الأخرى اعتماده لمبادرات التحول إلى السحابة الأصلية الخاصة بها.

اختيار التطبيق للتحديث

استهدف فريق IBM® Consulting جهازًا ظاهريًا يعمل بنظام Windows 2008 في بيئة تطوير سحابة VMware على AWS الخاصة بالعميل. ويعمل التطبيق في الجهاز الظاهري الخاص به ويستخدم مثيل Amazon RDS SQL Server في حساب عميل. لقد قدم هذا التطبيق حالة اختبار مثالية لسببين:

  1. يتضمن نظام تشغيل القديم (Windows Server 2008، الآن نهاية الدعم) مع اعتبارات التوافق المحتملة.
  2. إنه يمثل أحمال التشغيل إنتاجية لها تأثير تجاري حقيقي.

يوضح الشكل 1 المقدم هنا البنية عالية المستوى للتطبيق في بيئة التطوير. في هذه الحالة الأصلية، يوجد جهاز افتراضي Windows Server 2008 VM يعمل في السحابة VMware على AWS يتصل بخادم Amazon RDS SQL Server في حساب العميل على AWS

تمثيل البنية عالية المستوى للتطبيق في بيئة التطوير.

تشغيل دليل التقنية

بعد تمكين AWS Transform في مجموعات AWS والوصول إلى عنوان URL للتطبيق، تم تحديد مساحة عمل لتشغيل مهمة التحويل لترحيل تطبيق VMware إلى Amazon EC2.

فهم خيارات الترحيل

كما هو موضّح في الشكل 2، هناك أربعة أنواع مدعومة من مهام ترحيل برنامج VMware:

  1. الترحيل من البداية إلى النهاية
  2. ترحيل الشبكة فقط
  3. ترحيل الشبكة والخادم
  4. الاكتشاف وترحيل الخادم

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

يجب أن تتضمن خطة الترحيل النهائية تفاصيل البنية التحتية لشبكة AWS المستهدفة (VPC والشبكات الفرعية ومجموعات الأمان). ويمكن للمستخدمين استخدام ميزة المحادثة باللغة الطبيعية داخل AWS Transform عندما يحتاجون إلى تحديث أي معلومات، مثل تعديل أسماء الوظائف.

نص من موجِّه الذكاء الاصطناعي يعرض أربعة أنواع مدعومة من مهام ترحيل VMware

مرحلة الاكتشاف: وضع الأساس

تقوم AWS Transform بأتمتة عملية الاكتشاف من خلال التكامل مع خدمة AWS Application Discovery Service لجمع معلومات مفصلة حول تكوينات الخادم ومقاييس الأداء واتصالات الشبكة. وتشكل هذه البيانات الأساس لتخطيط الترحيل الدقيق وتوصيات التحجيم والترحيل.

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

بعد إنشاء مهمة الترحيل الأولية، كانت الخطوة الحاسمة التالية هي إنشاء اتصال بين AWS Transform وحساب الاكتشاف. سيقوم حساب AWS المخصص هذا بتخزين بيانات البنية التحتية المكتشفة واستضافتها، ما يمكّن AWS Transform من إنشاء توصيات ترحيل دقيقة. وقد قام فريق IBM® Consulting بتسهيل هذا الاتصال من خلال إنشاء طلب موصل بأذونات محددة، وتخويل AWS Transform لقراءة حاويات S3 وكتابتها وإدارتها، وتكوينات خدمة Application Discovery Service (ADS) من AWS.

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

يوضح الشكل 3 وحدة تحكم AWS Migration Hub التي تعرض خادم Windows 2008 المكتشف مع مواصفات النظام واتصالات الشبكة الخاصة به مرئية بوضوح. قام وكيل الاكتشاف بجمع معلومات مفصلة حول وحدة المعالجة المركزية والذاكرة واستخدام القرص واتصالات الشبكة لمساعدة AWS Transform على إنشاء توصيات ترحيل دقيقة.

تعرض وحدة تحكم AWS Migration Hub خادم Windows 2008 المكتشف مع مواصفات النظام واتصالات الشبكة.

مرحلة التخطيط: إستراتيجية الترحيل المستندة إلى الذكاء الاصطناعي

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

بعد تشغيل مهمة الاكتشاف لمدة سبعة أيام، بدأ فريق IBM® Consulting خطوة تنفيذ الاكتشاف في مهمة AWS Transform لمراجعة البيانات. وفي عمليات الترحيل الأكبر، يقترح AWS Transform تلقائيًا مجموعات التطبيقات والموجات في ملف CSV، والتي يمكن لفرق الترحيل تقييمها وتعديلها. وبمجرد التأكيد، أنشأ AWS Transform تلقائيًا مجموعات التطبيقات والموجات في خدمة ترحيل التطبيقات AWS (MGN). واستند هذا الإعداد إلى المعلومات المقدمة في ملف CSV.

بعد الاكتشاف، قام فريق IBM® Consulting بتوصيل AWS Transform بحساب AWS المستهدف حيث سيتم تنفيذ الخوادم المهاجرة. ويتطلب هذا الاتصال VPC افتراضيًا في منطقة AWS المستهدفة. ونظرًا لأن الفريق احتاج إلى استهداف VPC معين، فقد قاموا يدويًا بإنشاء VPC الافتراضي وتعديل الأدوار المرتبطة بالخدمة التي تم إنشاؤها تلقائيًا لضمان الأذونات المناسبة لمعرف VPC المستهدف.

من خلال العمل من خلال سير العمل الموجه AWS Transform، قام فريق IBM® Consulting بتعيين توصيات مثيل Amazon EC2، بما في ذلك تفضيلات الحجم وتفضيلات نوع المثيل والاستثناءات لأنواع معينة من المثيلات. أنشأ AWS Transform المخزون لموجة الترحيل، بما في ذلك مواصفات نوع مثيل EC2 وتفاصيل الإيجار. وقام الفريق بتنزيل هذا الملف وتحديثه للإشارة إلى VPC والشبكة الفرعية ومجموعات الأمان المحددة للمثيل الجديد (جميعها موسومة بـ CreatedFor:AWSTransform) وأعاد تحميله إلى AWS Transform.

مراحل التكرار والاختبار

يعمل AWS Transform على تبسيط عملية التكرار من خلال تنسيق خدمة الترحيل التطبيقية من AWS (MGN) لإجراء تكرار على مستوى الكتلة من خوادم المصدر إلى AWS.

لتنفيذ الترحيل، يجب تثبيت عامل تكرار على كل خادم مصدر. ويمكن لـ AWS Transform أتمتة هذه العملية أو يمكن للمستخدمين تثبيتها يدويًا. وبمجرد توصيل العامل بخدمة AWS MGN، تتم مزامنة أولية للجهاز الظاهري المصدر.

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

لقطة شاشة لتطبيق يعرض جاهزية الخوادم للاختبار بحالة النسخ المتماثل للبيانات السليمة

في هذه المرحلة، أطلقت AWS Transform مثيل اختبار استنادًا إلى أحدث ملف مخزون. ويظهر مثيل الاختبار هذا في وحدة تحكم AWS EC2، ما يسمح للفريق بإجراء اختبار القبول بينما تستمر بيئة المصدر في التشغيل بشكل طبيعي. وأكد اختبار التحقق الذي أجراه فريق IBM® Consulting ما يأتي:

  • تم بدأ نظام التشغيل بشكل صحيح
  • لقد عملت مصادقة Active directory بشكل صحيح
  • وعملت عناصر التطبيق كما هو متوقع
  • تم الحفاظ على اتصال الشبكة بقاعدة بيانات RDS

مرحلة التحويل: تقليل فترة التعطل

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

بعد إطلاق مثيل التحويل، أجرى فريق IBM® Consulting فحوصات التحقق التي تؤكد ما يأتي:

  • تم تحديث سجل DNS
  • يمكن الوصول إلى المثيل من خلال بيانات اعتماد Active Directory
  • تم تكوين اسم المضيف بشكل صحيح
  • أشارت المجموعة المستهدفة من موازن تحميل التطبيق بشكل صحيح إلى المثيل الجديد

بعد التحقق الناجح، أنهت AWS Transform عملية القطع. وأوقفت هذه العملية التكرار من الخادم المصدر، وألغت تثبيت الوكلاء وحركة الخادم المصدر تلقائيًا من الحالة النشطة إلى الحالة المؤرشفة في خدمة AWS MGN. يتم الآن وضع علامة على مهمة AWS Transform على أنها مكتملة.

يعرض الشكل 5 شاشة إكمال مهمة AWS Transform. ويؤكد أن الترحيل قد اكتمل بنجاح. كما تعرض مؤشرات الحالة أن جميع المراحل من الاكتشاف إلى الانتقال قد اكتملت وتم أرشفة الخادم المصدر في خدمة AWS MGN.

شاشة إكمال مهمة تحويل AWS

يوضح الشكل 6 البنية النهائية بعد اكتمال الترحيل. ويعمل التطبيق الآن على مثيل Amazon EC2 مباشرةً في حساب AWS الخاص بالعميل، متصلاً بقاعدة بيانات SQL Server الموجودة.

رسم توضيحي يمثل البنية النهائية بعد اكتمال الترحيل

فوائد استخدام AWS Transform

قد مكّن تصميم AWS Transform البديهي فريق IBM® Consulting من تنفيذ عملية الترحيل هذه بكفاءة دون الحاجة إلى تخصص عميق في كل خدمة أساسية من خدمات AWS. كان الفريق قادرًا على التركيز على سير عمل الترحيل ومتطلبات العمل. ووفرت خدمة AWS Transform فوائد مثل واجهة مركزية لتشغيل مثيل اختبار وتتبع حالة الترحيل وإجراء عملية التحويل—ما يوضح كيف تعمل الخدمة على تحسين إنتاجية الفريق وتخصيص الموارد.

عندما كان النشاط اليدوي مطلوبًا، قدمت AWS Transform إرشادات خطوة بخطوة وروابط للوثائق ذات الصلة. وقد عمل فريق IBM® Consulting عن كثب مع مهندس حلول AWS الخاص بالعميل وفريق خدمة AWS Transform لإزالة أي مشكلات واجهته وحلها في الوقت المناسب.

ومن الميزات القيّمة الأخرى هي ميزة التعاون المدمجة التي تتيح للعديد من أعضاء الفريق المشاركة في مشروع الترحيل. ويجب تعيين كل متعاون في أحد الأدوار الأربعة الآتية:

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

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

تقلل AWS Transform من المخاطر في عملية الترحيل من خلال العديد من الآليات الرئيسية. ويُعد تعديل مستوى الكتلة من بيانات الخوادم المصدر إلى AWS في زمن شبه حقيقي غير تدخلي. كما تستمر خوادم المصدر في العمل بكامل طاقتها طوال عملية التكرار.

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

توسيع نطاق AWS Transform عبر المحفظة

لقد منح الترحيل الناجح لتطبيق VMware إلى Amazon EC2 من خلال AWS Transform كلاً من فريق IBM® Consulting والعميل الثقة لتوسيع نطاق استخدام AWS Transform.

قام برنامج AWS Transform for VMware بتحسين مهام اكتشاف التطبيقات وكفاءة ترحيل التطبيقات بنسبة 60% لهذا الترحيل. ومن المتوقع تحقيق المزيد من المكاسب عند تطبيق هذه المنهجية على عمليات الترحيل على نطاق أوسع، حيث سيؤدي تحليل الخدمة لبيانات الاكتشاف لإنشاء مجموعات التطبيقات وخطط الموجات إلى التخلص من الجهد اليدوي. ويعمل برنامج AWS Transform على تبسيط رحلة تحديث العميل وتسريعها، ما يقلل من الحاجة إلى تطوير الخبرات الداخلية العميقة، ويقلل الوقت اللازم للقيمة، ويعزز إنتاجية الفريق.

البدء باستخدام AWS Transform

إذا كنت تفكر في AWS Transform لترحيل VMware الخاص بك، فإليك ثلاث خطوات لبدء رحلتك:

  • تواصل مع فريق حساب AWS الخاص بك لمناقشة كيفية دمج AWS Transform في الإستراتيجية الخاصة بك.
  • اختر تطبيقًا غير حساس مع تعقيد تمثيلي لإثبات مبدئي للتقنية.
  • قم بتمكين AWS Transform في مجموعة AWS الخاصة بك واستكشف واجهة تطبيق الويب لفهم القدرات.

قراءة وثائق AWS Transform

تعرف على خدمة AWS Application Discovery Service

استكشف خدمة ترحيل تطبيقات AWS

عرض توضيحي لمركز ترحيل AWS