اعتبارات وحدة المعالجة المركزية والذاكرة

أنواع وحدات المعالجة المركزية

يتيح إعداد نوع وحدة المعالجة المركزية الاختيار بناءً على جيل المعالج وميزاته، مما يضمن وظائف متسقة حتى إذا كانت البنية التحتية للسحابة الخاصة تستخدم معالجات مختلفة. ومع ذلك، لا يتم ضمان الهجرة الحية بين معالجات Intel وAMD.

اختيار “host” في أسفل القائمة المنسدلة سيستخدم نفس وحدة المعالجة المركزية الموجودة في الجهاز المضيف الفعلي، مما يزيد من الكفاءة. ومع ذلك، يمنع هذا الهجرة الحية بين المضيفين بأجيال مختلفة، مما قد يسبب مشكلات إذا تمت إضافة وحدات HRPC جديدة إلى مركز البيانات الافتراضي في المستقبل.

تعمل معظم أنظمة التشغيل الحديثة مع x86-64-v2، والتي تدعم مجموعات التعليمات مثل SSE3، SSSE3، SSE4.1، SSE4.2، POPCNT، وCMPXCHG16B. يتضمن خيار x86-64-v2-aes تعليمات تشفير AES، مما يتيح أداءً أسرع لبرامج التشفير.

اختيار x86-64-v3 يتيح استخدام تعليمات AVX وAVX2، بينما يضيف x86-64-v4 دعمًا لتعليمات AVX-512.

تدعم جميع موديلات السحابة الخاصة HRPC من 6Gt فصاعدًا x86-64-v4.

يلخص الجدول التالي هذه المعلومات:

المعالج	x86-64-v1	x86-64-v2	x86-64-v2-aes	x86-64-v3	x86-64-v4
التعليمات المدعومة	مجموعة تعليمات x86-64 الأساسية	SSE3، SSSE3، SSE4.1، SSE4.2، POPCNT، CMPXCHG16B	x86-64-v2 + AES	AVX، AVX2، BMI1، BMI2، FMA، MOVBE	عائلة AVX-512 (AVX-512F، AVX-512CD، AVX-512DQ، AVX-512BW، AVX-512VL، إلخ.)
Intel Xeon	سلسلة Intel Xeon 3000/5000/7000 (الجيل الأول)	سلسلة Intel Xeon 5500 (Nehalem) وما بعد	سلسلة Intel Xeon 5600 (Westmere) وما بعد	Intel Xeon E3 v3 (Haswell) وما بعد، Intel Xeon E5/E7 v3 (Haswell-EP/EX) وما بعد، معالجات Intel Xeon Scalable الجيل الأول (Skylake-SP) وما بعد	معالجات Intel Xeon Scalable الجيل الثاني (Cascade Lake-SP) وما بعد، معالجات Intel Xeon Scalable الجيل الثالث (Ice Lake-SP)
AMD Opteron	سلسلة AMD Opteron 100/200/800 (SledgeHammer)	سلسلة AMD Opteron 4200/6200 (Bulldozer) وما بعد	سلسلة AMD Opteron 4300/6300 (Piledriver) وما بعد	غير قابل للتطبيق	غير قابل للتطبيق
AMD EPYC	غير قابل للتطبيق	الجيل الأول AMD EPYC (Naples)	الجيل الأول AMD EPYC (Naples)	سلسلة AMD EPYC 7002 (Rome) وما بعد	سلسلة AMD EPYC 7003 (Milan) وما بعد

إدارة ذاكرة KVM وبرنامج Ballooning

باختصار، برنامج Ballooning غير ضروري في بنية HRPC ويُوصى بتعطيله.

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

يمكن ملاحظة ذلك في قسم “استخدام الذاكرة” في ملخص المضيف أو الآلة الافتراضية. على سبيل المثال، قد تستخدم آلة افتراضية تم تخصيص 32 جيجابايت من الذاكرة لها 13.56 جيجابايت فقط في الواقع.

في نظام Proxmox VE النموذجي، يمكن إنشاء الآلات الافتراضية طالما أن هناك ذاكرة متاحة. ومع ذلك، إذا بدا أن “استخدام الذاكرة” المعروض منخفض، فقد يقوم المسؤولون بتخصيص ذاكرة أكثر مما هو متاح فعليًا، مما يؤدي إلى التزام زائد بالذاكرة. عندما تطالب الآلات الافتراضية فجأة بمزيد من الذاكرة، قد يتسبب ذلك في عدم الاستقرار، مما قد يؤدي إلى تشغيل Out-Of-Memory Killer في نظام تشغيل المضيف، والذي قد ينهي عمليات النظام الحرجة بشكل عشوائي.

تم تصميم HRPC 6Gf للاستخدام المؤسسي مع التركيز على العزلة، مما يضمن عدم إمكانية إنشاء آلات افتراضية تتجاوز سعة الذاكرة المتاحة.

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

كما ذكرنا سابقًا، يمنع الهايبرفايزر المخصص في HRPC 6Gf إنشاء آلات افتراضية غير ضرورية، مما يجعل جهاز Ballooning غير ذي صلة إلى حد كبير في هذه البيئة.