أتمتة النظام الأساسي لسيناريو على مستوى المؤسسة Azure VMware Solution
تستخدم المنطقة المنتقل إليها على نطاق المؤسسة سلسلة من أفضل الممارسات للأتمتة وDevOps. يمكن أن تساعد أفضل الممارسات هذه في نشر سحابة خاصة ل Azure VMware Solution. يوفر هذا الدليل نظرة عامة على اعتبارات التوزيع للتوزيع الأولي ل Azure VMware Solution. كما يوفر إرشادات للأتمتة التشغيلية. يتبع هذا التنفيذ بنية وأفضل ممارسات Cloud Adoption Framework، ويركز على التصميم للمقياس.
يتكون هذا الحل من جزأين رئيسيين. الجزء الأول هو إرشادات حول ممارسات التوزيع والأتمتة ل Azure VMware Solution. الجزء الثاني هو مجموعة من البيانات الاصطناعية مفتوحة المصدر التي يمكن تكييفها للمساعدة في نشر السحابة الخاصة بك. بينما يهدف هذا الحل إلى بدء رحلة أتمتة شاملة، يمكن لمؤسستك تحديد المكونات التي سيتم توزيعها يدويا استنادا إلى الاعتبارات الواردة في هذه المقالة.
تم تصميم أتمتة مسرع المنطقة المنتقل إليها ل Azure VMware Solution لمساعدتك على البدء في نشر Azure VMware Solution باستخدام القوالب والبرامج النصية داخل هذا المستودع. قبل التوزيع، نوصي بمراجعة القوالب لفهم الموارد التي يتم توزيعها والتكاليف المرتبطة بها.
تتناول هذه المقالة الاعتبارات والتوصيات في المجالات التالية:
- خيارات النشر ل Azure VMware Solution، بما في ذلك يدويا وآليا.
- اعتبارات المقياس التلقائي وتفاصيل التنفيذ.
- اعتبارات الأتمتة على مستوى VMware SDDC داخل سحابة خاصة.
- تم توسيع التوصيات المتعلقة بنهج الأتمتة من منطقة هبوط المؤسسة.
- اعتبارات حول تقنيات التشغيل التلقائي لاستخدامها في النشر والإدارة، مثل Azure CLI وAzure Resource Manager وBicep وPowerShell.
استراتيجية التوزيع
يمكن نشر Azure VMware Solution يدويا أو باستخدام أدوات تلقائية منسقة.
النشر بشكل يدوي
يمكنك تكوين ونشر سحابة خاصة ل Azure VMware Solution رسوميا من خلال مدخل Microsoft Azure. هذا الخيار مناسب لعمليات النشر على نطاق أصغر. إذا كنت ترغب في نشر طبولوجيا Azure VMware Solution واسعة النطاق بطريقة قابلة للتكرار، ففكر في التوزيع التلقائي. يمكنك أيضا تكوين الاتصال بالسحابة الخاصة، ثم تغيير حجمه يدويا عبر مدخل Microsoft Azure.
الاعتبارات:
- يمكنك استخدام عمليات التوزيع اليدوية للطيارين الأوليين والبيئات الصغيرة. يمكنك أيضا استخدامها حيث لا يكون لديك أتمتة موجودة أو ممارسة البنية الأساسية كتعلم برمجي في مكانها.
- عند نشر Azure VMware Solution عبر مدخل Microsoft Azure أو Azure CLI أو وحدات Azure PowerShell النمطية، سترى سلسلة من الشروط والأحكام حول حماية البيانات في الحل. إذا كنت تستخدم واجهات برمجة تطبيقات Azure Resource Manager مباشرة أو تقوم بالتوزيع عبر قالب Azure Resource Manager أو Bicep، ففكر في مراجعة هذه الشروط والأحكام قبل توزيع التشغيل التلقائي.
- بالنسبة للبيئات عند الطلب التي يتم تجميعها كما هو مطلوب، ضع في اعتبارك أتمتة عملية إنشاء السحابة الخاصة ل Azure VMware Solution للحد من مقدار التفاعل اليدوي.
- يمكنك استخدام شفرة عمليات التوزيع لمجموعة الموارد الهدف داخل مدخل Microsoft Azure لمراقبة عملية إنشاء السحابة الخاصة. بمجرد نشر السحابة الخاصة، تأكد من أنها في حالة Succeeded قبل المتابعة. إذا كانت السحابة الخاصة تعرض حالة فشل، فقد لا تتمكن من الاتصال بخادم vCenter. قد تكون هناك حاجة إلى إزالة السحابة الخاصة وإعادة توزيعها.
توصيات:
- إذا اخترت أسلوب توزيع يدوي، فمن المهم توثيق التكوين الذي تستخدمه لتوفير السحابة الخاصة. بمجرد التوزيع، قم بتنزيل قالب التوزيع الذي استخدمته لأغراض الوثائق. يحتوي عنصر القالب هذا على قالب ARM المستخدم لتوزيع السحابة الخاصة. يحتوي عنصر القالب أيضا على ملف معلمات يحتوي على التكوين الذي حددته.
- إذا كنت ستتفاعل مع السحابة الخاصة في مدخل Microsoft Azure بانتظام، نوصي بوضع تأمين مورد لتقييد حذف الموارد. يمكنك أيضا استخدام تأمين الموارد للقراءة فقط لتقييد عمليات المقياس.
النشر بشكل تلقائي
يمكنك استخدام عمليات التوزيع التلقائية لتوزيع بيئات Azure VMware Solution بطريقة قابلة للتكرار. يمكنك بعد ذلك تصميم البيئات وتوزيعها عند الطلب. يؤدي هذا الاستخدام إلى آلية توزيع فعالة لنشر بيئات ومناطق متعددة على نطاق واسع. كما أنها توفر عملية توزيع منخفضة المخاطر عند الطلب وقابلة للتكرار.
خيارات تنفيذ Azure VMware Solution التلقائية
الاعتبارات:
- قد يستغرق نشر السحابة الخاصة ل Azure VMware Solution عدة ساعات لإكماله. ضع في اعتبارك مراقبة هذه العملية باستخدام حالة توزيع Azure Resource Manager أو خاصية الحالة على السحابة الخاصة. يمكنك استخدام البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع أو التوزيع برمجيا عبر PowerShell أو Azure CLI. إذا كان الأمر كذلك، فتأكد من تحديد قيم المهلة المناسبة لاستيعاب عملية توفير السحابة الخاصة.
- يمكنك تخصيص نطاقات العناوين مسبقا للسحب الخاصة وشبكات حمل العمل مسبقا وفقا للتوصيات الواردة في تخطيط الشبكة والاتصال. ثم أضفها إلى تكوين البيئة أو ملفات المعلمات. لم يتم التحقق من صحة تداخل نطاق العنوان في وقت التوزيع. يمكن أن يؤدي هذا النقص في التحقق من الصحة إلى مشكلات إذا كان لدى سحابتين خاصتين نفس نطاق العنوان. يمكن أن تحدث المشكلات أيضا إذا تداخل النطاق مع الشبكات الموجودة داخل Azure أو محليا.
- يمكنك استخدام كيانات الخدمة للتوزيع لتوفير وصول أقل امتيازا. يمكنك أيضا استخدام التحكم في الوصول المستند إلى دور Azure (RBAC) للحد من الوصول لعملية النشر.
- يمكنك استخدام استراتيجية DevOps لتوزيع السحابة الخاصة، باستخدام البنية الأساسية لبرنامج ربط العمليات التجارية لعمليات التوزيع التلقائية والتكرار دون الاعتماد على الأدوات المحلية.
توصيات:
- انشر الحد الأدنى من السحابة الخاصة ثم قم بالتحجيم كما هو مطلوب.
- طلب الحصة النسبية للمضيف أو السعة مسبقا لضمان التوزيع الناجح.
- مراقبة كل من عملية نشر السحابة الخاصة وحالة السحابة الخاصة قبل توزيع الموارد الفرعية. لا يمكن معالجة تحديثات التكوين الإضافية للسحابة الخاصة إلا بمجرد أن تكون السحابة الخاصة في حالة ناجحة . بالنسبة للسحب الخاصة التي تكون في حالة فشل، نوصيك بإيقاف أي عمليات أخرى ورفع تذكرة دعم لحلها.
- قم بتضمين أقفال الموارد ذات الصلة داخل التوزيع التلقائي أو تأكد من تطبيقها عبر النهج.
الاتصال التلقائي
بمجرد نشر السحابة الخاصة ل Azure VMware Solution، يمكنك إعداد الاتصال عبر ExpressRoute. هناك مساران مهمان لاتصال الشبكة الموضحين داخل مجموعة الإنشاء هذه:
- الاتصال بشبكة ظاهرية أو Azure Virtual WAN عبر بوابة شبكة ظاهرية.
- الاتصال بين Azure VMware Solution وExpressRoute موجود عبر Global Reach.
لمزيد من المعلومات حول تخطيطات الشبكة الموصى بها، راجع تخطيط الشبكة والاتصال.
الاعتبارات:
- يمكنك توصيل سحابة خاصة Azure VMware Solution بشبكة Azure الظاهرية أو ExpressRoute موجود. يعلن هذا الاتصال تلقائيا عن المسارات من كل من شبكات الإدارة وشبكات حمل العمل داخل السحابة الخاصة. نظرا لعدم وجود عمليات فحص متداخلة، ضع في اعتبارك التحقق من صحة الشبكات المعلن عنها قبل الاتصال.
- يمكنك محاذاة أسماء مفاتيح تخويل ExpressRoute مع أنظمة التسمية الحالية للموارد التي تتصل بها. توفر هذه المحاذاة تحديدا سهلا للموارد ذات الصلة.
- قد تعيش بوابات الشبكة الظاهرية ExpressRoute والدوائر ExpressRoute في اشتراك مختلف عن سحابة Azure VMware Solution الخاصة. حدد ما إذا كنت تريد أن يكون لمدير خدمة واحد حق الوصول إلى جميع هذه الموارد أو إذا كنت تريد الاحتفاظ بها منفصلة.
- يمكن لشبكة حمل عمل NSX-T Data Center عبر مدخل Microsoft Azure نشر موارد الشبكة الأساسية في سحابة خاصة، ولكن NSX-T Manager يمنح المزيد من التحكم في مكونات مركز بيانات NSX-T. من المفيد النظر في مستوى التحكم الذي تحتاج إليه على قطاعات الشبكة.
- استخدم شبكة حمل عمل مركز بيانات NSX-T داخل مدخل Microsoft Azure لإعداد مناطق نظام أسماء المجالات (DNS) لتكامل DNS الخاص.
- بالنسبة لطوبولوجيا الشبكة التي تتطلب بوابة واحدة فقط، استخدم شبكة حمل عمل مركز بيانات NSX-T داخل مدخل Microsoft Azure.
- بالنسبة للتكوينات المتقدمة، يمكنك استخدام NSX-T Manager مباشرة.
- ضع في اعتبارك مستوى مهارة مسؤولي الشبكة. إذا كان مسؤولو الشبكة لديك لديهم معرفة قليلة أو معدومة بمركز بيانات VMware NSX-T، ففكر في استخدام مدخل Microsoft Azure بدلا من ذلك لتقليل مخاطر عمليات الشبكة.
توصيات:
- إذا كنت تستخدم كيانات خدمة منفصلة لتوزيع Azure VMware Solution بدلا من تكوين ExpressRoute، فاستخدم Azure Key Vault أو مخزن سري مشابه لتمرير مفاتيح التخويل بين عمليات التوزيع إذا لزم الأمر.
- هناك حدود لعدد العمليات المتوازية التي يمكن إجراؤها عبر سحابة Azure VMware Solution الخاصة في أي لحظة. بالنسبة للقوالب التي تحدد العديد من الموارد الفرعية السحابية الخاصة ل Azure VMware Solution، نوصي باستخدام التبعيات للنشر بطريقة تسلسلية.
مقياس تلقائي
بشكل افتراضي، يحتوي نظام مجموعة Azure VMware Solution على عدد ثابت من المضيفين المحددين بواسطة مقياس نظام المجموعة. يمكنك تعديل التحجيم لكل نظام مجموعة برمجيا، بحيث يمكنك التوسع والتحجيم عبر الأتمتة. قد تكون هذه الأتمتة عند الطلب، أو على جدول زمني، أو في رد فعل على تنبيهات Azure Monitor.
الاعتبارات:
- يمكن أن يوفر التوسع التلقائي المزيد من السعة عند الطلب، ولكن من المهم مراعاة تكلفة المزيد من المضيفين. تقتصر هذه التكلفة على الحصة النسبية المقدمة للاشتراك، ولكن يجب أن تكون الحدود اليدوية في مكانها.
- قبل أتمتة التوسع، ضع في اعتبارك التأثير على تشغيل أحمال العمل وسياسات التخزين المطبقة داخل نظام المجموعة. على سبيل المثال، لا يمكن توسيع نطاق أحمال العمل التي تم تعيين RAID-5 لها إلى نظام مجموعة مكون من ثلاث عقد. من المهم أيضا مراعاة استخدام الذاكرة والتخزين، حيث قد يمنع هذا الاستخدام عملية توسيع النطاق.
- يمكن إجراء عملية واحدة فقط على نطاق واحد في كل مرة، لذلك من المهم مراعاة تنسيق عمليات المقياس بين مجموعات متعددة.
- عملية مقياس Azure VMware Solution ليست فورية، ويجب مراعاة الوقت المستغرق لإضافة عقدة أخرى إلى نظام مجموعة موجود.
- قد لا تتوقع حلول الجهات الخارجية والتكاملات أن تتم إزالة المضيفين وإضافتها باستمرار. ضع في اعتبارك التحقق من صحة سلوك جميع منتجات الجهات الخارجية. يضمن التحقق من الصحة هذا عدم الحاجة إلى مزيد من الخطوات لتحديث المنتج أو إعادة تكوينه عند إضافة المضيفين أو إزالتهم.
توصيات:
- وضع حدود ثابتة لكل من عمليات التوسيع والتوسيع خارج الحصة النسبية.
- طلب الحصة النسبية مسبقا حتى لا تؤثر على عملية المقياس. الحصة النسبية ليست ضمانا للسعة، بل القدرة على النشر حتى حد معين. راجع حد الحصة النسبية بانتظام للتأكد من وجود غرفة رأس دائما.
- تأكد من مراقبة أي نظام تحجيم تلقائي وأنه ينبهك عند الانتهاء من عملية التحجيم. يضمن هذا التنبيه عدم وجود أحداث مقياس غير متوقعة.
- استخدم مقاييس Azure Monitor لتأكيد سعة نظام المجموعة قبل عمليات التوسيع لضمان وجود غرفة رأس كافية. انتبه إلى وحدة المعالجة المركزية والذاكرة والتخزين قبل أي عمليات مقياس وأثناءها وبعدها. يضمن هذا الاهتمام بالسعة عدم تأثيرها على اتفاقية مستوى الخدمة (SLA).
تكامل Azure
يمكن للسحابة الخاصة ل Azure VMware Solution أيضا استخدام العديد من خدمات Azure الأصلية المختلفة. يمكنك تضمين هذه الخدمات ضمن توزيع Azure VMware Solution أو توزيعها كمكونات منفصلة. عندما تكون خارج نطاق المقالة، نوصي باستخدام الأنماط الموجودة داخل بنية المنطقة المنتقل إليها على نطاق المؤسسة للتكامل مع هذه الخدمات.
الاعتبارات:
ضع في اعتبارك دورة حياة التوزيع لكل مكون تخطط لأتمتته. يجب تجميع مكونات المجموعة المرتبطة بإحكام لدورة حياتها معا، ما يسمح بالنشر كوحدة واحدة. فصل المكونات مع دورات حياة مختلفة.
أدوات الأتمتة
توجد سحابة خاصة ل Azure VMware Solution كمورد داخل Resource Manager Azure، ما يوفر التفاعل عبر العديد من أدوات الأتمتة المختلفة. تميل أدوات Microsoft من الطرف الأول التي تم إنشاؤها من مواصفات Azure Resource Manager إلى دعم الميزات بعد وقت قصير من إصدارها. من منظور التنفيذ التلقائي، يتم توفير الاعتبارات الواردة في هذه المقالة بطريقة يمكن تطبيقها عبر مجموعات أدوات مختلفة.
الاعتبارات:
- استخدم الأدوات التعريفية مثل قوالب Azure Resource Manager وBicep بحيث يمكنك تعريف التكوين كأداة واحدة. تتطلب الأدوات المستندة إلى سطر الأوامر والبرامج النصية مثل Azure CLI وPowerShell نهجا خطوة بخطوة للتنفيذ يتماشى أكثر مع النشر اليدوي.
- يمكنك استخدام أدوات الأتمتة التابعة لجهة خارجية مثل Terraform لنشر Azure VMware Solution وخدمات Azure الأصلية. من المهم التأكد من تضمين الميزات التي تريد استخدامها داخل Azure VMware Solution حاليا ضمن الموارد المتوفرة.
- عند اتباع نهج قائم على البرنامج النصي للتوزيع، ضع في اعتبارك دائما الآثار المترتبة على الفشل في النشر والمراقبة بشكل مناسب. بالنسبة إلى Azure VMware Solution على وجه التحديد، ضع في اعتبارك مراقبة كل من التوزيع وحالة السحابة الخاصة. لمزيد من المعلومات حول مراقبة Azure VMware Solution، راجع إدارة ومراقبة Azure VMware Solution.
توصيات:
- استخدم Azure CLI أو PowerShell أو قالب تعريفي مثل Azure Resource Manager أو Bicep لنشر Azure VMware Solution بطريقة تلقائية.
- حيثما أمكن، استخدم what-if لتأكيد التغييرات قبل التنفيذ، مع إيقاف حذف المورد مؤقتا للتحقق.
- بالنسبة للعمليات التي تعد توزيعا واحدا، ولكنها لا تزال تتطلب بنية أساسية كتعلم برمجي، استخدم Azure Blueprints. توفر Azure Blueprints عمليات توزيع مخصصة وقابلة للتكرار دون الحاجة إلى مسارات التنفيذ التلقائي.
نهج DevOps
يجب عليك تنفيذ أتمتة توزيع Azure VMware Solution كسلسلة من الخطوات القابلة للتكرار، من الناحية المثالية عبر سير عمل أو مسار. من المهم تحديد نطاق الخطوات المطلوبة التي تخطط لتضمينها ضمن التوزيع. قد تتضمن هذه الخطوات:
- نشر السحابة الخاصة.
- اتصال بوابة ExpressRoute.
- اتصال Global Reach.
- NSX-T Data Center DHCP وDNS وإنشاء مقطع مبسط.
بعد نشر السحابة الخاصة بك، يمكنك نشر الموارد داخل السحابة الخاصة. لمزيد من المعلومات، راجع أتمتة النظام الأساسي VMware SDDC.
الاعتبارات:
- قد يكون لديك ممارسة أتمتة موجودة، أو قمت بإنشاء استراتيجية DevOps كجزء من المنطقة المنتقل إليها على نطاق المؤسسة. إذا كان الأمر كذلك، ففكر في إعادة استخدام نفس الأنماط لعمليات توزيع Azure VMware Solution للحفاظ على نمط أتمتة متسق عبر اللوحة.
- لمزيد من المعلومات، راجع أتمتة النظام الأساسي للمنطقة المنتقل إليها على نطاق المؤسسة ووثائق DevOps.
أتمتة النظام الأساسي VMware
ضمن سحابة Azure VMware Solution الخاصة، قد تختار أيضا أتمتة إنشاء الموارد داخل vCenter Server وNSX-T Manager. يتم سرد السلسلة التالية من الاعتبارات للمساعدة في تصميم الأتمتة على مستوى VMware SDDC.
أتمتة خادم vCenter - PowerCLI
الاعتبارات:
- استخدم PowerCLI لإنشاء وتكوين الأجهزة الظاهرية (VMs) وتجمعات الموارد وقوالب الأجهزة الظاهرية، مما يمنحك تحكما برمجيا كاملا في خادم vCenter.
- نظرا لأن خادم vCenter متوفر فقط من خلال الاتصال الخاص أو IP الخاص، يجب تشغيل PowerCLI على جهاز لديه خط رؤية لشبكات إدارة Azure VMware Solution. ضع في اعتبارك استخدام عامل مستضاف ذاتيا لتنفيذ البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بك. باستخدام هذا العامل، يمكنك تشغيل PowerCLI على جهاز ظاهري داخل شبكة ظاهرية أو مقطع مركز بيانات NSX-T.
- قد لا يكون لديك حق الوصول للقيام بعمليات معينة، حيث أنك مقيد بدور CloudAdmin. ضع في اعتبارك تعيين الأذونات المطلوبة للأتمتة التي تخطط لتنفيذها والتحقق من صحتها مقابل أذونات CloudAdmin.
- للحصول على أقل امتياز للوصول، ضع في اعتبارك استخدام حساب خدمة للأتمتة على مستوى خادم vCenter عبر تكامل Active Directory.
أتمتة مركز بيانات NSX-T - PowerCLI
الاعتبارات:
- في سحابة Azure VMware Solution الخاصة، يتمتع المستخدم المسؤول بالوصول الإداري إلى مركز بيانات NSX-T بشكل افتراضي. بسبب هذا الوصول الافتراضي، ضع في اعتبارك تأثير التغييرات التي تم إجراؤها عبر PowerCLI أو واجهات برمجة تطبيقات مركز بيانات NSX-T مباشرة. لا يسمح بإجراء تعديلات على المكونات التي تديرها Microsoft مثل منطقة النقل وبوابة من المستوى الصفري، وينصح بالحذر.
- الاتصال الخاص مطلوب من الجهاز الظاهري الذي يقوم بتشغيل PowerCLI إلى سحابة Azure VMware Solution الخاصة للتفاعل مع مركز بيانات NSX-T.
- يمكنك التحكم في شبكات حمل العمل عبر Azure Resource Manager. يتيح عنصر التحكم هذا إجراء مجموعة فرعية من العمليات عبر واجهة برمجة تطبيقات Azure Resource Manager، والتي تمكن بعد ذلك العمليات عبر Azure CLI وPowerShell باستخدام Azure RBAC بدلا من هوية مركز بيانات NSX-T.
موفرو مركز بيانات Terraform vSphere وNSX-T
الاعتبارات:
- يمكنك استخدام موفري vSphereوNSX-T Data Center ل Terraform لنشر الموارد. يتم نشر هذه الموارد ضمن نطاق السحابة الخاصة بطريقة تعريفية.
- نظرا لأن Terraform يحتاج إلى التحدث إلى نقاط نهاية واجهة برمجة التطبيقات داخل vCenter Server وNSX-T Manager، فإنه يحتاج إلى اتصال خاص بشبكة إدارة السحابة الخاصة. ضع في اعتبارك النشر من جهاز Azure ظاهري يمكنه التوجيه إلى السحابة الخاصة.
vRealize Automation وvRealize Operations
الاعتبارات:
- يمكنك استخدام vRealize Automation بشكل مشابه لبيئة محلية، بحيث يمكنك أتمتة توفير الأجهزة الظاهرية داخل Azure VMware Solution.
- هناك قيود على نماذج التوزيع المدعومة على Azure VMware Solution. ضع في اعتبارك استخدام vRealize Cloud Management، أو استضافة أجهزة vRealize Automation المحلية.
- كما هو الحال مع PowerCLI، يلزم الاتصال الخاص ب Azure VMware Solution من البيئة التي تكون فيها أجهزة vRealize Automation وvRealize Operations .
الأتمتة على مستوى حمل العمل
ضمن أحمال العمل الفردية على Azure VMware Solution، يمكنك اختيار إعداد التشغيل التلقائي على مستوى كل جهاز ظاهري. يتم تحقيق هذه الأتمتة بنفس الطريقة التي يتم بها تحقيقها محليا وهي خارج نطاق هذه المقالة. تتضمن أمثلة هذه الأتمتة Microsoft Configuration Manager و Chef و Puppet و Ansible. يمكنك أيضا استخدام Azure Automation للتكوين على مستوى الجهاز الظاهري باستخدام العامل المحلي.
الخطوات التالية
الآن بعد أن قرأت مجالات التصميم، تعرف على النهج المعماري والتنفيذ ل Azure VMware Solution في سيناريو على نطاق المؤسسة.