ما هو حل Azure VMware؟

يوفر حل Azure VMware سحابات خاصة تحتوي على عناقيد VMware vSphere مبنية من بنية Azure المخصصة للمعدن العار. حل Azure VMware متوفر في Azure Commercial و Azure Government. الحد الأدنى للتوزيع الأولي هو ثلاثة مضيفين، مع خيار إضافة المزيد من المضيفين، بحد أقصى 16 مضيف لكل نظام مجموعة. تحتوي جميع السحب الخاصة المقدمة على خادم VMware vCenter وVMware vSAN وVMware vSphere وVMware NSX. وبالتالي، يمكنك نقل أحمال العمل من بيئاتك المحلية، ونشر آلات افتراضية جديدة (VMs)، واستهلاك خدمات Azure من سحبتك الخاصة. للحصول على معلومات حول اتفاقية مستوى الخدمة (SLA)، راجع صفحة اتفاقيات مستوى الخدمة Azure.

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

يوضح المخطط التجاور بين السحب الخاصة وVNets في Azure وخدمات Azure والبيئات المحلية. يوفر الوصول إلى الشبكة من السحب الخاصة إلى خدمات Azure أو VNets تكاملا مدفوعا ب SLA لنقاط نهاية خدمات Azure. يربط ExpressRoute Global Reach بيئتك المحلية بسحابة حل Azure VMware الخاصة.

حل Azure VMware private cloud types

يوفر حل Azure VMware جيلين مختلفين من السحابة الخاصة:

1. يوفر حل Azure VMware Generation 1 عناقيد VMware vSphere مبنية من مضيفين مخصصين من المعدن العاري المنتشر في مرافق مراكز بيانات Azure. توفر <دوائر >ExpressRoutes المدارة Microsoft الاتصال بين مضيفي VMware vSphere وموارد Azure الأصلية المنشورة في الشبكات الافتراضية.

2. حل Azure VMware الجيل الثاني يوفر عناقيد VMware vSphere مبنية من مضيفات مخصصة Azure من المعدن العاري. يتميز حل Azure VMware Generation 2 ببنية شبكة محدثة حيث يتم ربط مضيفي VMware vSphere مباشرة بشبكات Azure الافتراضية. هذا العرض مدعوم فقط على AV64 SKU.

المضيفون والمجموعات والسحب الخاصة

تعتمد عناقيد حل Azure VMware على بنية تحتية متقاربة للغاية. يعرض الجدول التالي مواصفات وحدة المعالجة المركزية والذاكرة والقرص والشبكة للمضيف.

نوع المضيف	وحدة المعالجة المركزية (النوى / جيجاهرتز)	ذاكرة الوصول العشوائي (جيجابايت)	بنية vSAN	طبقة ذاكرة التخزين المؤقت vSAN (TB، raw***)	طبقة سعة vSAN (TB، raw***)	التوفر الإقليمي
AV36	وحدات المعالجة المركزية المزودة ببطاقتي Intel Xeon Gold 6140 (Skylake microarchitecture) مع 18 نواة/ وحدة المعالجة المركزية @ 2.3 غيغاهرتز، وإجمالي 36 نواة مادية (72 نواة منطقية مع فرط الكتابة)	576	OSA	3.2 (NVMe)	15.20 (SSD)	المناطق المحددة (*)
AV36P	وحدات المعالجة المركزية المزودة ببطاقتي Intel Xeon Gold 6240 (Cascade Lake microarchitecture) مع 18 نواة/ وحدة المعالجة المركزية @ 2.6 غيغاهرتز / 3.9 غيغاهرتز توربو، إجمالي 36 نواة مادية (72 نواة منطقية مع فرط الكتابة)	768	OSA	1.5 (ذاكرة التخزين المؤقت Intel)	19.20 (NVMe)	المناطق المحددة (*)
AV48	وحدات المعالجة المركزية المزودة ببطاقتي Intel Xeon Gold 6442Y (Sapphire Rapids microarchitecture) مع 24 ذاكرة أساسية/ وحدة المعالجة المركزية @ 2.6 غيغاهرتز / 4.0 غيغاهرتز توربو، إجمالي 48 نواة مادية (96 نواة منطقية مع فرط الكتابة)	1,024	ESA	N/A	25.6 (NVMe)	المناطق المحددة (*)
AV52	وحدات المعالجة المركزية المزودة ببطاقتي Intel Xeon Platinum 8270 (Cascade Lake microarchitecture) مع 26 نواة/ وحدة المعالجة المركزية @ 2.7 غيغاهرتز / 4.0 غيغاهرتز توربو، إجمالي 52 نواة مادية (104 نواة منطقية مع فرط الكتابة)	1,536	OSA	1.5 (ذاكرة التخزين المؤقت Intel)	38.40 (NVMe)	المناطق المحددة (*)
AV64	وحدات المعالجة المركزية المزودة ببطاقتي Intel Xeon Platinum 8370C (البنية الدقيقة ل Ice Lake) مع 32 نواة/ وحدة المعالجة المركزية @ 2.8 غيغاهرتز / 3.5 غيغاهرتز توربو، إجمالي 64 نواة مادية (128 نواة منطقية مع فرط الكتابة)	1,024	النوى المفتوحة / ESA****	3.84 (NVMe) / غير متوفر	15.36 (NVMe) / 19.25 (NVMe)****	المناطق المحددة (**)

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

تحتوي جميع أنواع المضيفين السابقة على معدل نقل واجهة شبكة بسرعة 100 جيجابت في الثانية.

*التفاصيل متوفرة عبر حاسبة أسعار Azure.

**المتطلب الأساسي ل AV64: يتطلب الأمر وجود سحابة خاصة من حل Azure VMware مع AV36 أو AV36P أو AV48 أو AV52 قبل إضافة AV64.

يستند Raw إلى المعيار الدولي للوحدات (SI) الذي أبلغت عنه الشركات المصنعة للأقراص. مثال: 1 تيرابايت Raw = 100000000000 بايت. المساحة المحسوبة بواسطة كمبيوتر ثنائي (ثنائي 1 تيرابايت = 1099511627776 بايت ثنائي) تساوي 931.3 غيغابايت محولة من الرقم العشري الخام.

تنطبق ESA على عمليات نشر AV64 Gen 2.

يمكنك نشر سحابات خاصة جديدة أو توسع موجودة من خلال بوابة Azure أو Azure CLI.

حل Azure VMware Private Cloud extension with AV64 node size

يعد AV64 وحدة تعريف مضيف حل Azure VMware، وهي متاحة لتوسيع السحابة الخاصة حل Azure VMware المبنية باستخدام وحدات AV36 أو AV36P أو AV52 الحالية. إذا كنت تريد نشر AV64 مباشرة، راجع حل Azure VMware في الشبكة الافتراضية في Azure. استخدم وثائق Microsoft للتحقق من توفر وحدة تخزين AV64 في المنطقة.

المتطلبات الأساسية لتوسيع AV64 على AV36 وAV36P وAV52

راجع المتطلبات الأساسية التالية لنشر نظام المجموعة AV64.

• يتم إنشاء حل Azure VMware الخاص باستخدام AV36 أو AV36P أو AV48 أو AV52 بتقنية AV64 المدعومة region/AZ.

• تحتاج إلى كتلة عنوان /23 أو ثلاثة (متجاورة أو غير متجاورة) /25 لإدارة نظام مجموعة AV64.

إمكانية دعم سيناريوهات العملاء

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

1. احصل على موافقة AV64 quota من Microsoft مع حد أدنى من ثلاث عقد. أضف تفاصيل أخرى حول السحابة الخاصة حل Azure VMware التي تخطط لتوسيعها باستخدام AV64.
2. استخدم سير عمل إضافة تجمع موجود في حل Azure VMware مع مضيفات AV64 للتوسع.

العميل يخطط لإنشاء سحابة خاصة حل Azure VMware جديدة: عندما يرغب العميل في سحابة خاصة حل Azure VMware جديدة يمكنها استخدام وحدة تخزين AV64 ولكن فقط للتوسعة. في هذه الحالة، يستوفي العميل الشرط الأساسي لامتلاك سحابة خاصة من حل Azure VMware مبنية باستخدام وحدة تخزين AV36 أو AV36P أو AV52. يحتاج العميل إلى شراء ما لا يقل عن ثلاث عقد من AV36 أو AV36P أو AV52 SKU قبل التوسع باستخدام AV64. بالنسبة لهذا السيناريو، استخدم الخطوات التالية:

1. احصل على موافقة AV36 أو AV36P أو AV52 وAV64 quota من Microsoft مع ثلاث عقد على الأقل لكل منها.
2. إنشاء سحابة خاصة حل Azure VMware باستخدام AV36 أو AV36P أو AV52.
3. استخدم سير عمل إضافة تجمع موجود في حل Azure VMware مع مضيفات AV64 للتوسع.

حل Azure VMware العناقيد الممتدة السحابية: وحدة تعريف AV64 غير مدعومة مع حل Azure VMware العناقيد الممتدة في السحابة الخاصة. هذا يعني أن توسعة مبنية على AV64 غير ممكنة لسحابة خاصة من حل Azure VMware الممتدة في عناقيد الكلود.

Note

ستستخدم جميع نسبة استخدام الشبكة من مضيف AV64 نحو شبكة العملاء عنوان IP لواجهة شبكة VMKernel 1.

التوافق المحسنة مع vMotion (EVC) مع امتداد AV64

إضافة عقد AV64 إلى سحابة خاصة حل Azure VMware تخلق بيئة غير متجانسة، مما يؤدي إلى مشاكل Enhanced vMotion Compatibility (EVC) بين عناقيد AV64 وعناقيد وحدات SKU الأساسية باستخدام وحدات AV36 أو AV36P أو AV52. تستخدم عناقيد AV64 وضع EVC من Icelake بسبب معالجات Intel Icelake، بينما لا تحتوي عناقيد AV36 وAV36P وAV52، المبنية على معالجات Intel الأقدم، بوضع EVC صريح. تفاصيل حول أجيال المعالج لكل وحدة تخزين تم توفيرها أعلاه.

تمثل تباينة أوضاع EVC عبر المجموعات تحديات لعمليات vMotion الحية كما حددتها Broadcom، بناء على السيناريو المحدد واتجاه الهجرة. يقدم القسم التالي ملخصا لتجربة المستخدم عند أداء vMotion المباشر بين AV64 والمجموعات الأساسية.

• vMotion إلى عنقود AV64 من عنقود SKU الأساسي – هذا يعمل بشكل جيد لأن الجهاز الافتراضي يتم تحويله من عنقود وضع EVC منخفض إلى عنقود وضع EVC أعلى.

• vMotion إلى عنقود SKU الأساسي من عنقود AV64 – سيناريوهين

  • إذا تم نقل الآلة الافتراضية سابقا من عنقود القاعدة ولم يتم تشغيلها بالطاقة، فإن vMotion المباشر ينجح.

  • إذا تم إنشاء الآلة الافتراضية على عنقود AV64 أو تم تشغيلها بالطاقة، رغم أنها كانت قد تم تحويلها سابقا إلى vMotion من عنقود SKU الأساسي، فإن vMotion المباشر سيفشل مع خطأ توافق EVC.

يمكن للعملاء تجنب مشاكل vMotion الحية بين وحدات SKU الأساسية وعناقيد AV64 عن طريق ضبط وضع EVC على مستوى الآلة الافتراضية ليطابق EVC في عنقود قاعدة أقل، أو عن طريق إيقاف تشغيل الجهاز الافتراضي وتنفيذ vMotion بارد.

تصميم وتوصيات مجال خطأ AV64 Cluster vSAN (FD)

لا تحتوي عناقيد حل Azure VMware التقليدية على تكوين vSAN FD صريح. المنطق هو أن منطق تخصيص المضيف يضمن، داخل العناصر، ألا يوجد مضيفان في نفس مجال الخطأ الفيزيائي ضمن منطقة Azure. توفر هذه الميزة بطبيعتها المرونة والتوافر العالي للتخزين، والتي من المفترض أن يجلبها تكوين vSAN FD. يمكن العثور على مزيد من المعلومات حول vSAN FD في وثائق VMware.

تحتوي عناقيد حل Azure VMware AV64 على تكوين نطاق خطأ vSAN (FD) صريح. يقوم حل Azure VMware بتكوين سبعة نطاقات خطأ vSAN (FDs) لمجموعات AV64. يتم موازنة المضيفين بالتساوي عبر FDs السبعة حيث يقوم المستخدمون بتوسيع نطاق المضيفين في نظام مجموعة من ثلاث عقد إلى 16 عقدة. لا تزال بعض مناطق Azure تدعم ما يصل إلى خمسة وحدات FD كحد أقصى كجزء من الإصدار الأولي لوحدة تعريف AV64. راجع جدول توزيع نوع نوع المضيف Azure لمنطقة توفر المنطقة لمزيد من المعلومات.

توصية حجم نظام المجموعة

الحد الأدنى لحجم مجموعة عقد vSphere المدعوم في حل Azure VMware هو ثلاثة. تتم معالجة تكرار بيانات vSAN عن طريق التأكد من أن الحد الأدنى لحجم نظام المجموعة لثلاثة مضيفين في vSAN FDs مختلفة. في نظام مجموعة vSAN مع ثلاثة مضيفين، كل في FD مختلف، إذا فشل FD (على سبيل المثال، فشل أعلى مفتاح الحامل)، فستتم حماية بيانات vSAN. قد تفشل عمليات مثل إنشاء كائن (جهاز ظاهري جديد وVMDK وغيرها). وينطبق الشيء نفسه على أي أنشطة صيانة حيث يتم وضع مضيف ESXi في وضع الصيانة و/أو إعادة التشغيل. لتجنب سيناريوهات مثل هذه، التوصية هي نشر مجموعات vSAN مع أربعة مضيفين ESXi كحد أدنى.

سير عمل إزالة مضيف AV64 وأفضل الممارسات

بسبب تكوين نطاق خطأ VSAN الخاص بعنقود AV64 والحاجة إلى مضيفين متوازنين عبر جميع وحدات التوزيع المخصصة، يختلف إزالة المضيف من عنقود AV64 عن عناقيد حل Azure VMware التقليدية مع وحدات SKU أخرى.

حاليا، يمكن للمستخدم تحديد مضيف واحد أو أكثر لإزالته من نظام المجموعة باستخدام المدخل أو واجهة برمجة التطبيقات. أحد الشروط هو أن نظام المجموعة يجب أن يحتوي على ما لا يقل عن ثلاثة مضيفين. ومع ذلك، يعمل نظام مجموعة AV64 بشكل مختلف في سيناريوهات معينة عندما يستخدم AV64 vSAN FDs. يتم التحقق من أي طلب إزالة مضيف مقابل عدم التوازن المحتمل في vSAN FD. إذا كان طلب إزالة المضيف يخلق عدم توازن، يتم رفض الطلب مع استجابة http 409-Conflict. يشير رمز حالة استجابة http 409-Conflict إلى تعارض طلب مع الحالة الحالية للمورد الهدف (المضيفين).

تعرض السيناريوهات الثلاثة التالية أمثلة على المثيلات التي تحدث خطأ عادة وتوضح الأساليب المختلفة التي يمكن استخدامها لإزالة المضيفين دون إنشاء خلل في مجال خطأ vSAN (FD).

• تؤدي إزالة مضيف إلى إنشاء عدم توازن vSAN FD مع اختلاف المضيفين بين معظم وأقل FD ملء ليكون أكثر من واحد. في المثال التالي للمستخدمين، تحتاج إلى إزالة أحد المضيفين من FD 1 قبل إزالة المضيفين من FDs الأخرى.

  

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

  

• تؤدي إزالة المضيف المحدد إلى أقل من ثلاثة VSAN FDs نشطة. لا يتوقع حدوث هذا السيناريو نظرا لأن جميع مناطق AV64 تحتوي على خمس أو سبع أقراص FD. أثناء إضافة المضيفين، يتولى مستوى التحكم حل Azure VMware إضافة المضيفين من جميع وحدات FD السبعة بالتساوي. في المثال التالي، يمكن للمستخدمين إزالة أحد المضيفين من FD 1، ولكن ليس من FD 2 أو 3.

  

كيفية تحديد المضيف الذي يمكن إزالته دون التسبب في عدم توازن vSAN FD: يمكن للمستخدم الانتقال إلى واجهة عميل vSphere للحصول على الحالة الحالية ل vSAN FDs والمضيفين المقترنين بكل منهم. يساعد هذا في تحديد المضيفين (استنادا إلى الأمثلة السابقة) التي يمكن إزالتها دون التأثير على رصيد vSAN FD وتجنب أي أخطاء في عملية الإزالة.

تكوين RAID المدعوم AV64

يوفر هذا الجدول قائمة بتكوين RAID المدعوم ومتطلبات المضيف في مجموعات AV64. يتم دعم نهج RAID-6 FTT2 و RAID-1 FTT3 مع AV64 SKU في بعض المناطق. في مناطق Azure التي تقتصر حاليا على خمسة وحدات FD، تسمح Microsoft للعملاء باستخدام سياسة تخزين RAID-5 FTT1 vSAN لمجموعات AV64 التي تحتوي على ست عقد أو أكثر للوفاء باتفاقية مستوى الخدمة (SLA). راجع جدول توزيع نوع نوع المضيف Azure لمنطقة توفر المنطقة لمزيد من المعلومات.

تكوين RAID	حالات الفشل في تحمل (FTT)	الحد الأدنى من المضيفين المطلوبين
الإعداد الافتراضي RAID-1 (النسخ المتطابق).	1	3
RAID-5 (ترميز المحو)	1	4
RAID-1 (النسخ المتطابق)	2	5
RAID-6 (ترميز المحو)	2	6
RAID-1 (النسخ المتطابق)	3	7

Storage

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

Networking

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

عند نشر سحابة خاصة، يتم إنشاء شبكات خاصة للإدارة والتزويد وvMotion. يمكنك استخدام هذه الشبكات الخاصة للوصول إلى خادم VMware vCenter وVMware NSX Manager والجهاز الظاهري vMotion أو النشر.

يستخدم ExpressRoute Global Reach لتوصيل السحب الخاصة بالبيئات المحلية. يربط الدوائر مباشرة على مستوى Microsoft Edge. يتطلب الاتصال شبكة ظاهرية (vNet) مع دائرة ExpressRoute إلى محلي في اشتراكك. والسبب هو أن بوابات vNet (بوابات ExpressRoute) لا يمكنها نقل البيانات، ما يعني أنه يمكنك إرفاق دائرتين بنفس البوابة، ولكنها لا ترسل حركة المرور من دائرة إلى أخرى.

كل بيئة حل Azure VMware هي منطقة ExpressRoute خاصة بها (جهاز MSEE افتراضي خاص بها)، مما يتيح لك توصيل Global Reach بموقع الارتباط 'المحلي'. يتيح لك توصيل عدة نسخ من حل Azure VMware في منطقة واحدة إلى نفس موقع الارتباط.

Note

بالنسبة للمواقع التي لا يتم فيها تفعيل ExpressRoute Global Reach، على سبيل المثال، بسبب اللوائح المحلية، يجب عليك بناء حل توجيه باستخدام أجهزة Azure IaaS الافتراضية. لبعض الأمثلة، انظر Azure Cloud Adoption Framework - طوبولوجيا الشبكة والاتصال ل حل Azure VMware.

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

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

الوصول والأمان

تستخدم السحب الخاصة حل Azure VMware التحكم في الوصول القائم على الأدوار في vSphere لتعزيز الأمان. يمكنك دمج قدرات vSphere SSO LDAP مع Microsoft Entra ID. لمزيد من المعلومات، راجع صفحة بنية الوصول والهوية .

يتم تمكين تشفير البيانات الثابتة vSAN افتراضيا ويستخدم لتوفير أمان مخزن بيانات vSAN. لمزيد من المعلومات، راجع بنية التخزين.

بيانات موقع البيانات والعملاء

حل Azure VMware لا يخزن بيانات العملاء.

إصدارات برامج VMware

يسرد الجدول التالي إصدارات البرمجيات المستخدمة في النشرات الجديدة للسحابات الخاصة حل Azure VMware.

Software	Version	رقم البنية
خادم VMware vCenter	8.0 U3k	25600417
VMware ESXi	8.0 U3k	25595708
VMware vSAN	8.0 [أو3]	25595708
VMware vSAN Witness	8.0 [أو3]	25595708
تنسيق VMware vSAN على القرص	20	N/A
بنية تخزين VMware vSAN	الجيل 1: OSA ، Gen2: ESA	N/A
VMware NSX	4.2.3.2	25077145
VMware HCX	4.11.4	25238712
استعادة موقع VMware Live	9.0.2.1	24401761
النسخ المتماثل ل VMware vSphere	9.0.2.1	24383568

إذا لم يتطابق رقم الإصدار المدرج مع رقم الإصدار المدرج في ملاحظات الإصدار، فهذا بسبب تطبيق تصحيح مخصص لموفري السحابة.

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

صيانة دورة حياة المضيف والبرامج

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

مراقبة السحابة الخاصة بك

بمجرد نشر حل Azure VMware في اشتراكك، يتم توليد Azure Monitor السجلات تلقائيا.

في السحابة الخاصة بك، يمكنك:

• جمع السجلات على كل من الأجهزة الظاهرية الخاصة بك.
• قم بتحميل وتثبيت MMA agent على لينكس وأجهزة Windows الافتراضية.
• فعل إضافة Azure diagnostics .
• إنشاء استعلامات جديدة وتشغيلها.
• قم بتشغيل نفس الاستعلامات التي تقوم بتشغيلها عادة على الأجهزة الظاهرية الخاصة بك.

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

التواصل مع العملاء

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

مصفوفة المسؤولية حل Azure VMware - Microsoft vs customer

ينفذ حل Azure VMware نموذج مسؤولية مشتركة يحدد الأدوار والمسؤوليات المميزة للطرفين المشاركين في العرض: العميل وMicrosoft. يتم توضيح مسؤوليات الدور المشتركة بمزيد من التفصيل في الجدولين التاليين.

يوضح جدول مصفوفة المسؤولية المشتركة المهام الرئيسية التي يتولاها كل من العملاء وMicrosoft في نشر وإدارة كل من أحمال عمل السحابة الخاصة وتطبيقات العملاء.

يوفر الجدول التالي قائمة مفصلة بالأدوار والمسؤوليات بين العميل وMicrosoft، والتي تشمل المهام والتعريفات الأكثر شيوعا. للمزيد من الأسئلة، تواصل مع Microsoft.

الدور	Task/details
Microsoft - حل Azure VMware	البنية الأساسية المادية مناطق Azure مناطق توفر Azure الطريق السريع / الوصول العالمي Compute/Network/Storage مضيفو الحامل وطاقة Bare Metal معدات شبكة الرف والطاقة توزيع/دورة حياة السحابة الخاصة نشر VMware ESXi وتصحيحه وترقيته نشر VMware vCenter Servers وتصحيحها وترقيتها نشر VMware NSX وتصحيحه وترقيته نشر VMware vSAN وتصحيحه وترقيته شبكة السحابة الخاصة - تكوين موفر VMware NSX عقدة/عنقود Microsoft Edge، إعداد مضيف VMware NSX موفر المستوى 0 وبوابة المستأجر من المستوى 1 الاتصال من المستوى 0 (باستخدام BGP) إلى شبكة Azure عبر ExpressRoute الحوسبة السحابية الخاصة - تكوين موفر خادم VMware vCenter إنشاء نظام مجموعة افتراضي تكوين الشبكات الظاهرية ل vMotion والإدارة وvSAN وغيرها النسخ الاحتياطي/الاستعادة السحابية الخاصة النسخ الاحتياطي واستعادة خادم VMware vCenter النسخ الاحتياطي واستعادة VMware NSX Manager مراقبة صحة السحابة الخاصة والإجراءات التصحيحية، على سبيل المثال: استبدال المضيفين الفاشلين (اختياري) يتم نشر VMware HCX مع ملف تعريف حساب مكون بالكامل على جانب السحابة كوظيفة إضافية (اختياري) تقوم VMware SRM بنشر وترقية وتوسيع نطاق لأعلى/لأسفل الدعم - الأنظمة الأساسية السحابية الخاصة وVMware HCX
Customer	Request حل Azure VMware host quote with Microsoft خطط وأنشئ طلبا للسحب الخاصة على بوابة Azure باستخدام: عدد المضيفين نطاق شبكة الإدارة معلومات أخرى تكوين شبكة السحابة الخاصة والأمان (VMware NSX) مقاطع الشبكة لاستضافة التطبيقات المزيد من أجهزة التوجيه -1 من المستوى Firewall VMware NSX LB IPsec VPN NAT عناوين IP العامة جدار الحماية الموزع/جدار حماية البوابة ملحق الشبكة باستخدام VMware HCX أو VMware NSX تكوين AD/LDAP ل RBAC تكوين السحابة الخاصة - خادم VMware vCenter تكوين AD/LDAP ل RBAC نشر وإدارة دورة حياة Virtual Machines (VMs) والتطبيق تثبيت أنظمة التشغيل تصحيح أنظمة التشغيل تثبيت برنامج الحماية من الفيروسات تثبيت برنامج النسخ الاحتياطي تثبيت برنامج إدارة التكوين تثبيت مكونات التطبيق شبكات الأجهزة الظاهرية باستخدام مقاطع VMware NSX ترحيل Virtual Machines (VMs) تكوين VMware HCX لايف vMotion الترحيل البارد مزامنة مكتبة المحتويات تكوين السحابة الخاصة - vSAN تحديد نهج vSAN VM وصيانتها إضافة مضيفين للحفاظ على "مساحة السماح" الكافية تكوين VMware HCX تنزيل وتوزيع موصل HCA OVA في أماكن العمل إقران موصل VMware HCX المحلي تكوين ملف تعريف الشبكة، وملف تعريف الحوسبة، وتشابك الخدمة تكوين ملحق شبكة VMware HCX/MON تكوين الشبكة للاتصال بالشبكة المحلية أو الشبكة الظاهرية أو الإنترنت إضافة طلبات المضيفين إلى نظام المجموعة أو حذفها من المدخل توزيع/إدارة دورة حياة حلول الشركاء (الجهات الخارجية)
النظام البيئي للشركاء	دعم المنتج/الحل الخاص بهم. للمرجعية، فيما يلي بعض الحلول/المنتجات الشريكة المدعومة من حل Azure VMware: BCDR - VMware SRM و JetStream وZerto وغيرها النسخ الاحتياطي - Veeam وCommvault وRurik وغيرها VDI - Horizon، Citrix VMware Cloud Director, VMware Cloud Directory Availability (VCDA) حلول الأمان - BitDefender، TrendMicro، Checkpoint منتجات VMware الأخرى - مجموعة آريا، NSX Advanced Load Balancer

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

الخطوة التالية هي تعلم مفاهيم بنية السحابة الخاصة الرئيسية.