المرجع الشامل لأفضل الممارسات العالمية على مستوى الـ VM

السلام عليكم ورحمة الله وبركاته

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

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

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

عند انشاء VM، هنالك شيء يعرف بالـ Sizing والموضوع أبعد من إضافة vCPU و RAM للـ VM ، لأن لها دور كبير في الأداء وعند عدم اتباع هذه الممارسات سيؤثر على الـ Services والـ Operation بداخل الـ vSphere وستبدأ مشاكل الأداء بالظهور.

نبدأ بشرح الـ NUMA : كلمة NUMA هي اختصار لـ Non Uniform Memory Access وهي وصف لنظام لديه أكثر من System bus، وعندما نجمع الـ CPU والـ RAM معاً فهنا تسمى NUMA node.

وبشكل عام ومبسط نستطيع القول أن الـ NUMA هو نهج لمعمارية السيرفر حيث يحدد أقرب RAM للـ CPU وذلك لتقليل أي تأخير يحصل في معالجة البيانات، حيث أن كل CPU يخصص له Local RAM للوصول السريع.

ومن فكرة الـ NUMA ظهرت تقنية أخرى تسمى vNUMA وهي المستخدمة في الـ Virtualization بشكل عام، وهي على مستوى الـ VM ونستطيع القول أنها آلية لمساعدة الـ OS والـ Application بداخل الـ VM على فهم الـ NUMA architecture للهاردوير الخاص بالـ Physical Host، وهو تمثيل Logical لعملية كيف أن الـ CPU يستطيع الوصول للـ RAM عبر الـ Hypervisor ، وفائدتها تقليل الـ Bottleneck على الـ Memory، وخصوصاً اذا كانت موارد الـ VM عالية أو في حال وجود أكثر من VMs على vApp.

( ملاحظة: يستحسن دائماً أن تكون الـ Hosts Physical بنفس المواصفات "Specs" ، وذلك في حال عمل vMotion لـ VM الى هوست أخر بمواصفات مختلفة "Different NUMA architecture"، فإن الـ vNUMA ستختلف مما يترتب على ذلك عدم استقرار النظام بداخل الـ VM ، ويستثنى من ذلك الـ VMs ذات الموارد الصغيرة ).

وهذه الصورة توضح الفكرة بشكل عام:

صورة توضح عندما يتم الوصول الى NUMA أخرى (غير مستحسن لأنه يقلل الأداء) :

وكما تلاحظون في الصورة أعلاه، الـ CPU 1 لم يتصل بالـ RAM الخاصة به على نفس الـ Node ، بل اتصل بالـ Node الأخرى وفي هذه الحالة يكون الوصول للـ RAM بطئ حيث أن الـ Latency ازداد، وهذه الحالة تسمى Remote Memory ويجب أن نتجنبها بقدر المستطاع.

عندما يتم تفعيل الـ vNUMA فإن نظام التشغيل على نفس الـ VM سيعرض نفسه على الـ Physical NUMA وبدوره سيسمح للنظام والبرامج الموجودة على نفس الـ VM بالاستفادة من الـ Physical NUMA وهذا سيرفع أداء الـ VM بشكل كبير.

نقاط يجب الانتباه لها للـ vNUMA:

تستطيع تفعيل او تعطيل الـ vNUMA على أي VM عن طريق الاعدادات المتقدمة (الأفضل تركه كما هو)
تقليل الـ Bottleneck بين الـ CPU والـ RAM وهذا سيساعد على التوسع بشكل أفضل " scalability"
شرح عن الـ Bottleneck https://en.wikipedia.org/wiki/Bottleneck_(software)
سيتم تفعيل الـ vNUMA بشكل تلقائي إذا الـ VM كانت تحوي أكثر من 8 vCPU
اذا تم تفعيل ميزة CPU Hot Add فإن الـ vNUMA سيتم تعطيله، وبدون الـ vNUMA النظام الموجود على الـ VM لا يستطيع رؤية الـ Virtual Topology على الـ ESXi "والمقصود هنا الـ CPU والـ RAM"

أفضل الممارسات العالمية والموصى بها:

تقليل الـ VM من استخدام أكثر من NUMA وذلك لتقليل الاتصال بـ RAM أخرى
عند تعيين vCPU، يجب الانتباه أن تكون متناسقة مع الـ Physical CPU (عدد الأنوية لكل Socket)
في حال احتجت أن تعطي vCPU أو RAM أكثر من الموجودة في الـ NUMA الواحدة، فيجب تقسيمها بالتساوي على عدد الـ NUMA لديك ( بالأسفل تم شرحها بأمثلة ليسهل فهم هذه النقطة )
حاول قدر المستطاع أن لا تنشئ VM تكون مواصفاتها أعلى من مواصفات "Specs" الـ Physical Host لديك.
عند تعيين الـ vCPU، يجب الانتباه أن تكون على عدد الموارد المطلوبة للـ Application المثبت على الـ VM، حتى لو كان الـ Application أو نظام التشغيل لا يستعمل الـ vCPU فإن الـ vCPU الغير المستخدمة ستسبب ضغط ""overhead على الـ Physical CPU بدون أي فائدة
يفضل ببعض الحالات أن تبدأ بـعدد اثنين vCPU لكل VM سيتم انشائها ويتم زيادة العدد عند الحاجة، والسبب يرجع أنه سيحد من توفر الموارد للـ VMs الأخرى ويزيد من الـ CPU ready wait time
مراقبة الـ co-stop بشكل دوري والتأكد من أن النسبة قليلة، ويمكن معرفة نسبة الـ co-stop عن طريق الـ esxtop ثم تفحص النسبة في عامود بإسم %CSTP ، وفي حالة أن النسبة كانت من 3-4% فيجب الانتباه أنها إشارة خطرة ويجب تقليل الموارد المعطاه للـ VM.
مراقبة أداء استخدام الـ CPU للـ VM وتحديد اذا كان هناك حاجة لزيادة الـ vCPU أم لا، ويمكن مراقبة الاستهلاك عن طريق برنامج مراقبة متخصص أو عن طريق نظام التشغيل نفسه أو عن طريق الـ vCenter ، ويجب الانتباه أن نسبة الاستهلاك "Utilization" يجب أن يكون 80% أو أقل، وفي حالة الاستهلاك كان أكثر من 85% فيجب زيادة الـ vCPU ، وأيضاً يمكن قياس الأداء عن طريق الـ CPU Ready وينصح دائماً بأن تكون نسبة الـ CPU Ready أقل من 5% (يمكن قياس الـ CPU Ready عن طريق الـ esxtop ثم تفحص النسبة في عامود بإسم %RDY)
عندما يكون أكثر من vNUMA مفعل، يجب عدم تعيين أرقام فردية للـ vCPU ويجب أن تكون زوجية ( مثل : إعطاء السيرفر 10 vCPU )
كما ذكرت سابقاً، الأفضل تعطيل ميزة CPU Hot Add وذلك لأنها غير متوافقة مع الـ vNUMA ( إطفاء هذه الميزة سيسبب عبء كبير عند زيادة موارد الـ VM، لكن يمكن الاتفاق مع مسؤول الـ Server بيوم معين كل أسبوع وساعة معينة حيث سيتم إيقاف تشغيل الـ VM والتعديل على الموارد )
عند استخدام OVA الأفضل التواصل مع الـ Vendor لتغيير الـ vCPU بما يتناسب مع الـ Physical CPU اذا كان ذلك ممكناً
لا تستهلك كل موارد الـ Host، وذلك حتى تتأكد أن الأنظمة لديك ستعمل بسلاسة في أوقات الذروة، بالإضافة الى أن الـ Hypervisor يستخدم هذه الموارد، وأيضاً من أجل ومتطلبات الـ HA والـ Failover ، والأفضل دائماً أن يكون نسبة استهلاك الموارد من 70-75% للبيئات الحساسة وذلك لضمان أفضل أداء
كما هو متعارف عليه أن اغلب المعالجات لديها تقنية Hyperthreads، ويتم حساب الـ logical processors كالتالي (Cores x Hyper-threads )، ( مثال : معالج لديه 10 أنوية، فسيكون الـ logical processors 20 ، تم حسابها كالتالي (10x2=20) )، مع توضيح لما تم ذكره في السابق فإنه لا ينصح بإعطاء أي VM أكثر من عدد الأنوية الحقيقية للمعالج، ( مثل : 20 vCPU لمعالج فيه 10 أنوية حقيقية )
الغاية من الـ Hyperthreads هو إبقاء النواة الحقيقية نشطة، فإذا كانت توجد عملية على نواة واستهلكتها بنسبة 100% فإن الـ Hyperthreads على النواة التي فيها العملية لن تعمل، ولذلك فإن حجز vCPU أكثر من عدد الأنوية الحقيقية فإنه سيضعف الأداء ولا ينصح به أبداً
في حال تم طلب VM كبيرة جداً، حيث أن عدد الـ vCPU أكثر من عدد الأنوية في المعالج ( مثال: 40 vCPU على معالج لديه 20 نواة ومع تقنية الـ Hyperthreads يكون 40) بشكل عام لا ينصح بعمل هذا الشيء لأنه سيسبب مشاكل في الأداء، والسبب أن نظام التشغيل على الـ VM سيتواصل مع التطبيق بأن يجدول الحمل على 40 نواة، ولكن الـ Host لا يستطيع الاستجابة لهذه الجدولة.
في حال تم طلب VM كبيرة جداً، كما في المثال السابق ( مثل : 40 vCPU )، فالأفضل اذا أمكن تقسيمها لأربعة VM، وهنا تسمى Over Allocation وفي حالة المثال السابق تكون النسبة 2:1 وهذا سيساعد الـ VMware CPU Schedule بإبقاء كل شيء تحت السيطرة.

يوجد معلومة خاطئة بخصوص الـ Hyper-threads ويجب الانتباه لها، الـ Hyper-threading لا يضاعف عدد أنوية الـ CPU ولكنه يعمل على توفير عملية افتراضية على نفس الـ Core، لذلك عند وجود Thread خاملة أو تنتظر وصول الأوامر عليها، عندها سيقوم الـ Hyper-threading بتنفيذ الأوامر على Thread أخرى، وبدوره سيزيد أداء المعالج من 25%-30% على الأكثر.

عوامل الـ Sizing للـ vCPU:pCPU :

المقدار الكافي للـ Over Commitment لإستيعاب قدرة الـ CPU يعتمد بالكامل على الـ VM والـ Application الذي يعمل عليه، وبشكل عام يمكن عمل Over provision للاستفادة من هذه الخاصية وتوفير المال بدلاً من شراء Hosts جديدة، ولكن إساءة استخدام هذه الميزة سيؤثر على الأداء، ويمكن عمل التالي مع مراقبة الأداء (Co-stop و CPU Ready):

1:1 لن يسبب مشاكل في الأداء أبداً وهو الموصى به من قبل VMware، ولكن ليس من المنطق عدم استغلال الموارد لديك، ويفضل اتباع هذا النهج في حالة أن لديك أنظمة وApplication حساسة جداً.
2:1 يعطي أداء ممتاز وهو مناسب للأنظمة أو الـ DB التي تستهلك الموارد بشكل عالي.
3:1 يمكن أن يسبب القليل من البطء في الأداء، وينصح فيها للأنظمة والتطبيقات العادية.
4:1 يسبب مشاكل في الأداء وعادةً يوصى به اذا لديك أنظمة أو Application ذات أولية منخفضة.
5:1 يسبب مشاكل كبيرة في الأداء ولكن ينصح به للـ VDI.

ومع ذلك يمكن أن يكون الـ Sizing غير مناسب للـ Environment التي لديك حيث أن ما يحدد ذلك هو عبئ العمل "Workload" على الـ VMs.

يجب الانتباه أن الـ Over commitment للـ RAM مختلف تماماً عن الـ CPU، حيث أن الـ Host يستخدم 4 طرق لإدارة الـ RAM وهي:

Transparent page sharing
Ballooning
Memory page compression
Swapping

( لن أدخل في تفاصيل الـ RAM ولكن لأختصر عليكم الموضوع، يفضل دائماً عدم استهلاك الـ RAM بشكل كامل بأي حال من الأحوال لأنه يسبب بطئ بالأداء بشكل ملحوظ جداً وسيؤثر على سير العمل )

تطبيق عملي لما تم شرحه:

كيف يتم اختيار الـ vCPU على النحو الأمثل ( عدد المعالجات x عدد الأنوية لكل معالج ) :

عند انشاء أو تعديل موارد VM يجب الانتباه أن الـ vCPU الذي تم تعيينه يقسم على عدد الأنوية لكل معالج، في الصورة السابقة يوجد 20 vCPU مقسم على 10 "عدد الأنوية" والناتج هو 2 معالج، يمكننا القول " 2 معالج x 10 أنوية لكل معالج

مثال: تم طلب VM ليكون عليها Microsoft SQL 2019، في حال تم انشائه بـ 8 معالج x 2 أنوية لكل معالج فإنه سيشتغل بشكل مختلف عند انشائه بـ 2 معالج x 8 أنوية لكل معالج، وهذا يرجع الى الـ Soft NUMA الموجودة في الـ SQL لأنه يتم تكوينها بشكل تلقائي بناء على عدد الأنوية التي يستخدمها النظام.

لذلك الأفضل اتباع التالي:

يجب اختيار الـ vCPU بناءً على عدد الأنوية لكل معالج، حتى يتم تجاوز عدد الأنوية الحقيقية في الـ pNUMA أو حتى يتم تجاوز المجموع الكلي للرامات في الـ pNUMA الواحدة ( الجدول بالأسفل سيسهل فهم هذه النقطة )
في حال يجب تعيين vCPU أكثر من عدد الأنوية الحقيقية في الـ pNUMA أو تعيين رامات أكثر من المحتوية بداخل الـ pNUMA فالأفضل تقسيمها بشكل متساوي، بحيث يكون عدد الـ vCPU متوزع على أقل عدد ممكن من الـ NUMA (مرة أخرى الجدول سيسهل فهم هذه النقطة)

أمثلة عملية لتسهيل الشرح لكم:

مثال 1: