إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يوفر حل Azure VMware سحبا خاصة تحتوي على مجموعات VMware vSphere مبنية من بنية أساسية مخصصة Azure بلا نظام تشغيل. يمكنك ترحيل أحمال العمل من البيئات المحلية الخاصة بك، ونشر أجهزة ظاهرية جديدة (VMs)، واستهلاك خدمات Azure من السحب الخاصة بك. يمكنك استخدام مزيج من VMware والقدرات الأصلية Azure لتمكين قابلية الوصول العالية والمرونة لأحمال العمل الخاصة بك.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
توضح هذه المقالة كيفية جعل حل Azure VMware مرنة في مواجهة الانقطاعات والمشاكل المحتملة، بما في ذلك الأخطاء العابرة وانقطاعات منطقة التوفر وانقطاع المنطقة. كما يصف كيف يمكنك استخدام النسخ الاحتياطية للتعافي من أنواع أخرى من المشكلات ويسلط الضوء على بعض المعلومات الرئيسية حول اتفاقية مستوى الخدمة حل Azure VMware (SLA).
توصيات نشر الإنتاج
تتطلب عمليات النشر حل Azure VMware تخطيطا دقيقا عبر مجموعة من المناطق وغالبا ما تتطلب خدمات Azure متعددة. لمزيد من المعلومات، راجع حل Azure VMware أحمال العمل في إطار عمل Azure Well-Architected.
نظرة عامة على بنية الموثوقية
يستخدم حل Azure VMware بنية أساسية شديدة التقارب (HCI) مع مجموعات VMware vSphere.
عند نشر حل Azure VMware، يمكنك نشر سحابة خاصة، والتي تحتوي على مجموعة واحدة أو أكثر. تحتوي كل مجموعة على مضيفي ESXi الذين يوفرون الحوسبة والتخزين من خلال SAN الظاهري (vSAN) والشبكات من خلال VMware NSX. هناك جيلان من حل Azure VMware:
يستخدم Gen 1 أجهزة متخصصة بلا نظام تشغيل للعقد ويستخدم نهج شبكة مخصصة. لمزيد من المعلومات حول المفاهيم الرئيسية، راجع حل Azure VMware مفاهيم السحابة والمجموعة الخاصة.
يستخدم Gen 2 أنواع الأجهزة الظاهرية القياسية Azure والشبكات الظاهرية Azure. تعمل هذه البنية على تبسيط بنية الشبكات، وتحسين سرعات نقل البيانات، وتقليل زمن الانتقال لأحمال العمل، وتحسين الأداء عند الوصول إلى خدمات Azure الأخرى.
التسامح مع الخطأ
يوفر حل Azure VMware العديد من الآليات للتعامل مع الأخطاء على مستوى البنية الأساسية والتطبيق:
vSphere High Availability (HA): يراقب vSphere HA مضيفي ESXi والأجهزة الظاهرية. إذا فشل المضيف، فإنه يقوم تلقائيا بإعادة تشغيل الأجهزة الظاهرية المتأثرة على المضيفين الأصحاء. يتم تشغيل vSphere HA بشكل افتراضي ويحتفظ بسعة الحوسبة والذاكرة لفشل عقدة واحدة.
التسامح مع الخطأ vSAN: تحمي نهج التخزين vSAN من الأخطاء العابرة على مستوى التخزين من خلال الاحتفاظ بنسخ متعددة من البيانات عبر المضيفين. إذا واجه مسار التخزين أو القرص مشاكل عابرة، فإن vSAN يعالج تلقائيا تجاوز الفشل إلى مسارات تخزين سليمة.
تكرار الشبكة: يوفر حل Azure VMware مسارات شبكة زائدة عن الحاجة ومحولات شبكة VMkernel متعددة لمعالجة الأخطاء العابرة على مستوى الشبكة.
المرونة في مواجهة الأعطال العابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. الأخطاء العابرة تصحح نفسها بعد فترة زمنية قصيرة. من المهم أن تتمكن تطبيقاتك من معالجة الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة ل Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمزيد من المعلومات، راجع توصيات للتعامل مع الأخطاء العابرة.
بالنسبة للتطبيقات التي تعمل على الأجهزة الظاهرية حل Azure VMware، قم بتنفيذ الممارسات القياسية لمعالجة الأخطاء العابرة:
إعداد نهج إعادة المحاولة المناسبة مع التراجع الأسي.
استخدم أنماط قاطع الدوائر لمكالمات الخدمة الخارجية.
مراقبة صحة التطبيق وتنفيذ تدهور رشيق.
تصميم تطبيقات عديمة الحالة عندما يكون ذلك ممكنا لتقليل تأثير إعادة تشغيل الجهاز الظاهري.
المرونة في مواجهة حالات فشل منطقة التوفر
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
يدعم حل Azure VMware Gen 1 مناطق التوفر من خلال مجموعات ممتدة، والتي توزع مضيفي ESXi عبر منطقتين للتوفر داخل المنطقة. يحدد Microsoft المناطق التي تريد استخدامها. يتم تشغيل نظام المجموعة الخاص بك في تكوين نشط-نشط عبر المنطقتين، وتمتد vSAN أيضا عبر مناطق متعددة. يمكنك تعيين ما إذا كان يتم نشر كل حمل عمل في منطقتين أو منطقتين.
يتم نشر عقدة المراقب تلقائيا في منطقة توفر ثالثة لتوفير الحصة لسيناريوهات تقسيم الدماغ. يدير Microsoft عقدة المراقب تلقائيا.
نظام المجموعة القياسي هو نظام مجموعة غير ممتد عبر المناطق. في نظام مجموعة قياسي، تعتبر المجموعة وجميع مضيفيها ESXi غير مناطقية أو إقليمية. قد يتم وضع المجموعات غير المناطقية في أي منطقة توفر داخل المنطقة، Microsoft تحديد المنطقة. إذا واجهت منطقة توفر في المنطقة انقطاعا، فقد تكون المجموعات والمضيفون غير المناطقيين في المنطقة المتأثرة وقد تواجه وقت تعطل.
يدعم حل Azure VMware Gen 2 عمليات التوزيع النطاقي للسحب الخاصة. عند إعداد سحابة خاصة نطاقية، يتم نشر كل مجموعة من مجموعاتها وجميع مضيفي ESXi الخاصة بهم في منطقة توفر واحدة تحددها.
لا تحمي السحابة الخاصة النطاقية من فشل منطقة التوفر. يمكنك نشر سحب خاصة متعددة في مناطق توفر منفصلة للحصول على مرونة أعلى، ولكنك مسؤول عن نشر كل سحابة خاصة وتكوينها بشكل مستقل.
إذا لم تحدد منطقة توفر، فإن السحابة الخاصة بك ومجموعاتها وجميع مضيفي ESXi الخاصة بهم تعتبر غير مناطقية أو إقليمية. قد يتم وضع المجموعات غير المناطقية في أي منطقة توفر داخل المنطقة، Microsoft تحديد المنطقة. إذا واجهت منطقة توفر في المنطقة انقطاعا، فقد تواجه المجموعات غير المناطقية في المنطقة المتأثرة وقت تعطل.
لمزيد من المعلومات حول دعم منطقة التوفر للأجيال الأخرى، حدد الجيل المناسب في بداية هذه المقالة.
متطلبات
دعم المنطقة: تتوفر المجموعات الممتدة فقط في مناطق Azure التي تدعم تكوين نظام المجموعة الممتدة. تحقق من منطقة توفر المنطقة Azure لاستضافة جدول تعيين النوع للحصول على دعم المنطقة الحالي.
الحد الأدنى من المضيفين: نشر ما لا يقل عن ستة مضيفين عبر منطقتين للتوفر (ثلاثة مضيفين لكل منطقة) لتمكين تكوين نظام المجموعة الممتدة. عند التحجيم أو التحجيم، يجب تغيير الحجم في أزواج بحيث يكون لكل منطقة عدد متساو من المضيفين.
وحدات SKU المضيفة: تدعم أنواع مضيفي AV36 وAV36P وAV52 المجموعات الممتدة. لا يدعم AV64 SKU المجموعات الممتدة.
- دعم المنطقة: يمكنك نشر السحب الخاصة النطاقية في المناطق التي تدعم كل من حل Azure VMware Gen 2ومناطق التوفر.
الاعتبارات
يمكن أن تدعم كل منطقة توفر في منطقة أنواع مضيفين محددة. للحصول على قائمة مفصلة وأنواع المضيف المتوفرة في كل منطقة، راجع Azure منطقة توفر المنطقة لاستضافة جدول تعيين النوع.
Cost
تتحمل تكاليف لكل عقدة في نظام المجموعة، بغض النظر عن تكوين منطقة توفر نظام المجموعة. للحصول على معلومات تسعير مفصلة، راجع حل Azure VMware التسعير.
تكوين دعم منطقة التوفر
نشر نظام مجموعة جديد: عند إنشاء سحابة خاصة حل Azure VMware جديدة في منطقة مدعومة، يمكنك إعدادها ككتلة ممتدة أثناء النشر. يوزع هذا التكوين المضيفين عبر منطقتين من مناطق التوفر تلقائيا. لمزيد من المعلومات، راجع نشر مجموعات vSAN الممتدة.
المجموعات الموجودة: لا يمكنك تحويل مجموعة قياسية إلى مجموعة ممتدة، ولا يمكنك تحويل مجموعة ممتدة إلى مجموعة قياسية. بدلا من ذلك، تحتاج إلى نشر نظام مجموعة جديد وترحيل أحمال العمل الخاصة بك.
نشر نظام مجموعة جديد: عند إنشاء سحابة خاصة حل Azure VMware جديدة في منطقة مدعومة، يمكنك تحديد منطقة التوفر الخاصة بها.
المجموعات الموجودة: لا يمكنك تغيير تكوين منطقة التوفر لمجموعة موجودة. بدلا من ذلك، تحتاج إلى نشر نظام مجموعة جديد وترحيل أحمال العمل الخاصة بك.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تمديد مجموعتك وتشغيل جميع مناطق التوفر.
عملية عبر المناطق: يمكن تشغيل الأجهزة الظاهرية على المضيفين في أي من منطقة التوفر. يمكنك التحكم في موضع الجهاز الظاهري باستخدام ترابط vSphere Distributed Resource Scheduler (DRS) وقواعد عدم الترابط لتحسين متطلبات الأداء أو التوفر.
النسخ المتماثل للبيانات عبر المناطق: يقوم vSAN بنسخ البيانات بشكل متزامن عبر مناطق التوفر. تؤكد كلتا المنطقتين كل عملية كتابة قبل اكتمالها لضمان تكامل البيانات المتسقة.
يصف هذا القسم ما يمكن توقعه عند نشر مجموعتك في سحابة خاصة نطاقية، وتكون جميع مناطق التوفر قيد التشغيل.
عملية عبر المناطق: تعمل الأجهزة الظاهرية على المضيفين داخل منطقة توفر نظام المجموعة.
النسخ المتماثل للبيانات عبر المناطق: لا يتم نسخ أي بيانات إلى منطقة أخرى.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تمديد نظام المجموعة الخاص بك وحدوث انقطاع في منطقة التوفر.
- الكشف والاستجابة: يدير حل Azure VMware الاستجابة على مستوى البنية الأساسية لفشل المنطقة. يكشف vSphere HA تلقائيا عن حالات فشل المنطقة ويبدأ إجراءات إعادة تشغيل الجهاز الظاهري إذا لزم الأمر.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام حالة خدمة Azure لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
الطلبات النشطة: تتم إعادة تشغيل أي أجهزة ظاهرية تعمل في منطقة التوفر الفاشلة على المضيفين في منطقة التوفر السليمة. يتم إنهاء الطلبات النشطة والاتصالات بالأجهزة الظاهرية المتأثرة، ويتحمل العملاء مسؤولية إعادة المحاولة.
وقت التعطل المتوقع: عادة ما يكون وقت إعادة تشغيل الأجهزة الظاهرية الفاشلة في المنطقة السليمة بضع دقائق، اعتمادا على تكوين الجهاز الظاهري وإجراءات بدء التشغيل. ولا تزال المجموعة الممتدة تعمل بسعة مخفضة.
إذا كانت منطقة التوفر الفاشلة تحتوي على عقدة المراقب، يصبح الشاهد غير قابل للوصول. طالما تظل النسخ المتماثلة للبيانات كافية متاحة، يستمر مضيفو البيانات وأحمال العمل قيد التشغيل في العمل دون فقدان فوري للبيانات. ومع ذلك، يفقد vSAN وعي الحصة في هذه الحالة. فقدان الحصة يمنعه من اتخاذ قرارات الإيداع والاسترداد بأمان. كما يحظر عمليات معينة، مثل تشغيل الجهاز الظاهري بعد الفشل وإعادة التوازن والإصلاحات.
فقدان البيانات المتوقع: نظرا لأن vSAN يستخدم النسخ المتماثل المتزامن بين المناطق، فمن المتوقع عدم فقدان البيانات أثناء فشل المنطقة.
إعادة التوزيع: يقوم vSphere DRS تلقائيا بإعادة توزيع أحمال عمل الجهاز الظاهري إلى منطقة التوفر السليمة. يتكيف توجيه نسبة استخدام الشبكة من خلال VMware NSX مع موضع الجهاز الظاهري الجديد تلقائيا.
يصف هذا القسم ما يجب توقعه عند نشر مجموعتك في سحابة خاصة نطاقية، ويحدث انقطاع في منطقة التوفر.
- الكشف والاستجابة: تحتاج إلى الكشف عن فقدان منطقة توفر. إذا لزم الأمر، يمكنك بدء تجاوز الفشل إلى مجموعة ثانوية تقوم بإنشائها مسبقا في منطقة توفر أخرى.
- الإعلام: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Resource Health لمراقبة صحة كل مورد على حدة، ويمكنك إعداد تنبيهات Resource Health لإبلاغك بالمشاكل. يمكنك أيضا استخدام حالة خدمة Azure لفهم الصحة العامة للخدمة، بما في ذلك أي أعطال في المناطق، ويمكنك إعداد تنبيهات صحة الخدمة لإبلاغك بالمشاكل.
الطلبات النشطة: يتم إنهاء الطلبات النشطة والاتصالات بالأجهزة الظاهرية المتأثرة، ويتحمل العملاء مسؤولية إعادة المحاولة.
وقت التعطل المتوقع: عندما تكون المنطقة غير متوفرة، تكون المجموعة وأحمال العمل الخاصة بها غير متوفرة حتى استرداد منطقة التوفر.
فقدان البيانات المتوقع: لا تتوفر البيانات في المنطقة المتأثرة حتى تسترد المنطقة.
إعادة التوزيع: أنت مسؤول عن تبديل نسبة استخدام الشبكة إلى مجموعات أخرى في مناطق صحية، إذا لزم الأمر.
استعادة المنطقة
عند استرداد منطقة التوفر، يمكن ل vSphere DRS إعادة توزيع الأجهزة الظاهرية اختياريا مرة أخرى إلى المنطقة المستردة استنادا إلى تكوين DRS وقواعد الترابط. يمكنك أيضا التحكم يدويا في موضع الجهاز الظاهري باستخدام عمليات vMotion.
عند استرداد منطقة التوفر، تتوفر المجموعات والمضيفون في المنطقة مرة أخرى. أنت مسؤول عن أي إجراءات استرداد للمنطقة ومزامنة البيانات التي تتطلبها أحمال العمل الخاصة بك.
اختبار فشل المنطقة
للتحضير لحالات فشل المنطقة، اختبر مرونة التطبيق الخاص بك لإعادة تشغيل الجهاز الظاهري وتغييرات مسار الشبكة، خاصة عندما تكون قد قمت بتمديد المجموعات أو نشر التطبيقات عبر مجموعات منفصلة في مناطق مختلفة.
نظرا لأن حل Azure VMware يدير استجابة البنية الأساسية لفشل المنطقة، فأنت بحاجة في المقام الأول إلى اختبار استجابة تطبيقك لإعادة تشغيل الجهاز الظاهري.
أنت مسؤول عن أي استجابة للبنية الأساسية لحالات فشل المنطقة، مثل تجاوز الفشل إلى مجموعة أخرى في منطقة أو منطقة مختلفة. تأكد من اختبار عمليات الاستجابة بدقة.
القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة
يتم نشر كل مجموعة حل Azure VMware داخل منطقة Azure واحدة. إذا أصبحت المنطقة غير متوفرة، تصبح السحابة الخاصة وجميع الموارد داخلها غير متوفرة.
ومع ذلك، يمكنك أيضا تصميم حلول متعددة المستويات مخصصة تجمع بين نهج مختلفة أو تتكامل مع بنيتك الأساسية الحالية لتلبية متطلبات عملك المحددة وأهداف الاسترداد.
حلول متعددة المستويات مخصصة للمرونة
لتحقيق مرونة متعددة المناطق باستخدام حل Azure VMware، تحتاج إلى نشر سحب خاصة منفصلة في مناطق متعددة وتنفيذ حلول تجاوز الفشل وغيرها من حلول التعافي من الكوارث (DR).
تدعم مجموعة من الخيارات متطلبات المرونة المختلفة. لمزيد من المعلومات، راجع حلول التعافي من الكوارث للأجهزة الظاهرية حل Azure VMware.
النسخ الاحتياطي والاستعادة
تقوم حل Azure VMware تلقائيا بنسخ مكونات الإدارة احتياطيا، مثل vCenter Server وNSX Manager وHCX Manager إذا تم تمكينها. لاستعادة المكونات من النسخ الاحتياطية للإدارة هذه، قم بإنشاء طلب Azure support.
بالنسبة لأحمال عمل الجهاز الظاهري، يدعم حل Azure VMware نهج النسخ الاحتياطي المتعددة. لمزيد من المعلومات، راجع حلول النسخ الاحتياطي لأجهزة حل Azure VMware الظاهرية.
المرونة في صيانة الخدمة
يقوم Azure بالصيانة التلقائية للنظام الأساسي لتطبيق تحديثات الأمان ونشر ميزات جديدة وتحسين موثوقية الخدمة.
لمعرفة كيفية تأثير الصيانة على مكونات حل Azure VMware، وفهم المكونات التي تتحمل مسؤولية صيانتها مقابل المكونات التي Microsoft صيانتها، راجع حل Azure VMware صيانة السحابة الخاصة.
يمكنك إعداد نوافذ الصيانة لنظام المجموعة لتقليل احتمالية تأثير الصيانة على أحمال عمل الإنتاج. لمزيد من المعلومات، راجع تخطيط صيانة الخدمة الذاتية حل Azure VMware.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.
يوفر حل Azure VMware اتفاقيات مستوى الخدمة لقابلية الوصول المختلفة للبنية الأساسية لحمل العمل وعمليات الإدارة.
تحتوي المجموعات التي قمت بإعدادها كتجمعات ممتدة على اتفاقية مستوى خدمة أعلى لتوافر البنية الأساسية لحمل العمل.
ومع ذلك، للتأهل لاتفاقيات مستوى الخدمة للتوفر، يجب عليك إعداد نظام المجموعة بطرق محددة. لمزيد من المعلومات، راجع نص اتفاقية مستوى الخدمة.