ما هو vCPU وكيفية حسابه في Virtualization وCloud؟
في بيئات السيرفرات الحديثة، لم يعد المعالج يُستخدم مباشرةً من نظام تشغيل واحد فقط. اليوم قد يعمل على السيرفر نفسه عشرات الأنظمة الافتراضية Virtual Machines، وكل نظام منها يحصل على عدد محدد من vCPU. هنا تظهر المشكلة العملية: هل 4 vCPU تعني 4 أنوية حقيقية؟ وهل يمكن إعطاء كل VM عدداً كبيراً من vCPU؟ ولماذا أحياناً تصبح VM أبطأ بعد زيادة عدد المعالجات الافتراضية؟
فهم vCPU مهم جداً عند تصميم بيئات VMware وProxmox VE وHyper-V، وكذلك عند اختيار Instance في خدمات Cloud. سوء توزيع vCPU يؤدي إلى بطء، ارتفاع CPU Ready، استهلاك زائد، تكلفة أعلى في السحابة، وأحياناً مشاكل ترخيص مع أنظمة مثل SQL Server أو بعض تطبيقات Enterprise.
في هذا المقال سنشرح vCPU بطريقة عملية: ما هو، كيف يرتبط بالـ CPU الحقيقي، كيف نحسب عدد المعالجات الافتراضية المتاحة، ما معنى Oversubscription، كيف نراقب الأداء، وما أفضل الممارسات لتوزيع المعالج في بيئات الشركات.
ما هو vCPU ومتى تحتاجه؟
الـ vCPU اختصار لـ Virtual CPU، وهو معالج افتراضي يظهر داخل النظام الافتراضي كأنه CPU حقيقي. عندما تنشئ VM وتحدد لها 2 أو 4 أو 8 vCPU، فأنت لا تركّب معالجاً جديداً، بل تطلب من الـ Hypervisor أن يخصص وقتاً من المعالج الحقيقي لهذه الـ VM.
الـ Hypervisor مثل VMware ESXi أو KVM في Proxmox أو Hyper-V هو المسؤول عن جدولة عمل الـ vCPU على الأنوية والخيوط الحقيقية الموجودة في السيرفر. إذا كان لديك عدة VMs تعمل في نفس الوقت، يقوم الـ Hypervisor بتوزيع وقت المعالج بينها حسب الحمل، الأولوية، والإعدادات مثل CPU Reservation أو Limit أو Shares.
| العنصر | وظيفته | الفائدة العملية |
|---|---|---|
| Physical CPU / Socket | المعالج الفعلي المثبت في السيرفر | يمثل مصدر القدرة الحقيقية التي ستتشاركها كل الـ VMs. |
| Core | نواة معالجة فعلية داخل المعالج | كلما زاد عدد الأنوية زادت قدرة السيرفر على تشغيل أحمال متوازية. |
| Thread / Logical Processor | خيط تنفيذ منطقي ينتج غالباً من Hyper-Threading أو SMT | يسمح للنواة الواحدة بتشغيل أكثر من مسار تنفيذ، لكنه لا يساوي نواة كاملة دائماً. |
| vCPU | معالج افتراضي مخصص للـ VM | يحدد مقدار قدرة المعالجة التي تراها VM وتطلبها من الـ Hypervisor. |
| Hypervisor Scheduler | ينظم تشغيل vCPU على الموارد الحقيقية | هو العامل الأساسي في الأداء عند وجود عدة VMs تعمل على نفس Host. |
ليس دائماً. في كثير من بيئات Cloud، يتم احتساب vCPU كخيط منطقي Hardware Thread، وليس كنواة فيزيائية كاملة. في بعض المنصات أو بعض أنواع السيرفرات قد يكون vCPU أقرب إلى Core، وفي حالات أخرى يكون vCPU حصة زمنية يتم جدولتها على المعالج الحقيقي.
لهذا السبب لا يجوز مقارنة السيرفرات بالأرقام فقط. خادم Cloud يحتوي 8 vCPU لا يعني بالضرورة أنه يساوي سيرفراً حقيقياً يحتوي 8 Cores مخصصة بالكامل. الأداء يعتمد على نوع المعالج، تردد المعالج، سياسة المشاركة، مستوى الضغط على Host، نوع التخزين، والشبكة.
- عند تصميم Host لتشغيل عدة VMs على Proxmox أو VMware أو Hyper-V.
- عند اختيار Instance في Cloud ومعرفة هل تكفي 2 vCPU أو تحتاج 4 أو 8.
- عند تشخيص بطء VM رغم أن استخدام CPU داخل النظام لا يبدو مرتفعاً.
- عند ضبط الموارد لخوادم مثل SQL Server أو Domain Controller أو Firewall VM.
- عند حساب تكلفة Cloud أو تراخيص البرامج التي تعتمد على عدد Cores أو vCPU.
أفضل الإعدادات والخيارات حسب بيئة العمل
اختيار عدد vCPU الصحيح يعتمد على نوع الخدمة، طريقة عمل التطبيق، وحجم الحمل. بعض التطبيقات تستفيد من تعدد المعالجات، مثل قواعد البيانات ومحركات التحليل، بينما خدمات أخرى تعمل بشكل ممتاز على 1 أو 2 vCPU. لذلك أفضل قرار ليس أكبر رقم، بل الرقم المناسب للحمل الحقيقي.
| نوع السيرفر أو الخدمة | العدد المبدئي المقترح | ملاحظات عملية |
|---|---|---|
| Domain Controller / DNS / DHCP | 2 vCPU غالباً تكفي | الخدمة حساسة للاستقرار أكثر من احتياجها لمعالج كبير، ويفضل مراقبة الحمل قبل الزيادة. |
| File Server | 2 إلى 4 vCPU | الأداء غالباً يعتمد على Storage وNetwork أكثر من CPU. |
| Web Server | 2 إلى 4 vCPU | يمكن التوسع أفقياً بزيادة عدد السيرفرات بدلاً من تضخيم VM واحدة. |
| SQL / Database Server | 4 إلى 8 vCPU كبداية | يحتاج مراقبة CPU وIO وMemory، وقد يتأثر بالترخيص حسب المنتج. |
| Firewall VM مثل pfSense / OPNsense | 2 إلى 4 vCPU | يعتمد على Throughput وVPN وIPS/IDS وعدد القواعد. |
| Monitoring / Backup Server | 2 إلى 4 vCPU | يجب جدولة مهام Backup خارج أوقات الذروة لتجنب الضغط على Host. |
| Dev/Test Machines | 1 إلى 2 vCPU | يمكن استخدام Oversubscription أعلى لأنها ليست خدمات حرجة غالباً. |
| الحالة | ما الإجراء الأفضل؟ | لماذا؟ |
|---|---|---|
| VM بطيئة وCPU داخلها 95% | زيادة vCPU أو تحسين التطبيق | هنا المعالج داخل VM مستخدم فعلياً، وقد تكون الزيادة مفيدة. |
| VM بطيئة وCPU داخلها 20% | لا تزد vCPU مباشرة | المشكلة قد تكون Storage أو Network أو CPU Ready أو Memory. |
| Host CPU مرتفع دائماً | قلل Oversubscription أو وزع VMs | كل VMs تتنافس على المعالج الحقيقي. |
| CPU Ready مرتفع في VMware | قلل عدد vCPU أو انقل VM إلى Host آخر | الـ VM تنتظر دورها للحصول على وقت CPU. |
| Database مهمة وحساسة | ابدأ بعدد مناسب مع مراقبة دقيقة | الأداء والترخيص والتخزين كلها عوامل مؤثرة. |
الـ Oversubscription يعني تخصيص عدد vCPU للـ VMs أكبر من عدد المعالجات المنطقية المتاحة فعلياً على الـ Host. هذا طبيعي ومستخدم في معظم بيئات Virtualization، لأن كل الـ VMs لا تستخدم CPU بنسبة 100% في نفس اللحظة.
Oversubscription Ratio = Total Assigned vCPU / Available Logical CPUs
Example:
Host Logical CPUs = 40
Total Assigned vCPU = 120
Oversubscription = 120 / 40 = 3:1
نسبة 3:1 قد تكون ممتازة في بيئة خوادم خفيفة، لكنها قد تكون سيئة جداً في بيئة قواعد بيانات أو VDI أو Firewall عالي الحمل. لذلك لا توجد نسبة سحرية تناسب كل الحالات.
| نوع البيئة | نسبة Overcommit كبداية | ملاحظات |
|---|---|---|
| Production Critical | 1:1 إلى 2:1 | مناسب لقواعد البيانات والخدمات الحساسة. |
| خوادم تطبيقات وWeb | 2:1 إلى 4:1 | مناسب إذا كان الحمل متوسطاً وموزعاً. |
| Dev/Test | 4:1 إلى 8:1 | مقبول لأن الخدمات ليست كلها نشطة دائماً. |
| VDI / RDS | حسب الاستخدام | يحتاج اختباراً عملياً لأن الحمل يتغير حسب المستخدمين. |
طريقة التجهيز والاستخدام والتنظيم
لحساب vCPU بشكل صحيح، يجب أن تفرّق بين ثلاثة أرقام: عدد الأنوية الفعلية Physical Cores، عدد الخيوط المنطقية Logical Processors، وعدد vCPU المخصصة للـ VMs. الرقم الأول يعبّر عن القوة الحقيقية، والثاني يعبّر عن القدرة المنطقية التي يراها النظام، والثالث هو ما توزعه أنت على الأجهزة الافتراضية.
Logical CPUs = Number of Sockets × Cores per Socket × Threads per Core
Example:
2 Sockets
12 Cores per Socket
2 Threads per Core
Logical CPUs = 2 × 12 × 2 = 48 Logical CPUs
هذا الرقم لا يعني أنك يجب أن تخصص 48 vCPU فقط ولا أكثر. يمكن تخصيص أكثر من ذلك عبر Oversubscription، لكن نجاح ذلك يعتمد على طبيعة الأحمال. Host يحتوي 48 Logical CPUs قد يعمل عليه 100 أو 150 vCPU مخصصة إذا كانت الأحمال خفيفة، وقد يعاني مع 60 vCPU فقط إذا كانت كلها قواعد بيانات أو عمليات ثقيلة.
- احسب عدد Logical CPUs على الـ Host.
- صنّف كل VM: Critical، Production، Dev/Test، أو Temporary.
- ابدأ بعدد vCPU صغير حسب نوع الخدمة.
- راقب استخدام CPU داخل VM وخارجها على الـ Host.
- راقب مؤشرات الانتظار مثل CPU Ready أو Steal Time.
- زد vCPU تدريجياً فقط إذا كان التطبيق يستخدم CPU فعلياً.
- وثّق السبب عند كل تعديل حتى لا تتحول البيئة إلى أرقام عشوائية.
Windows PowerShell:
Get-CimInstance Win32_Processor |
Select-Object Name,NumberOfCores,NumberOfLogicalProcessors
Linux:
lscpu
Proxmox Host:
lscpu
cat /proc/cpuinfo | grep processor | wc -l
Hyper-V - عرض معالجات VM:
Get-VMProcessor -VMName "SQL01"
Hyper-V - تعديل عدد vCPU:
Set-VMProcessor -VMName "SQL01" -Count 4
Proxmox - تعديل VM ID 101 إلى 4 Cores:
qm set 101 --cores 4 --sockets 1 --cpu host
Proxmox - عرض إعدادات VM:
qm config 101
التشغيل وحل المشاكل الشائعة
تشخيص مشاكل vCPU لا يكون بالنظر إلى استخدام CPU داخل النظام فقط. قد ترى داخل Windows أو Linux أن استخدام CPU منخفض، بينما الـ VM بطيئة بسبب انتظارها للحصول على وقت تنفيذ من الـ Hypervisor. لذلك يجب مراقبة الأداء من داخل VM ومن جهة الـ Host في نفس الوقت.
| المشكلة | السبب المحتمل | الحل المقترح |
|---|---|---|
| VM بطيئة رغم أن CPU داخلها منخفض | CPU Ready أو ضغط على Host أو Storage بطيء | راقب مؤشرات Host، ولا تضف vCPU قبل التأكد من السبب. |
| ارتفاع CPU Ready في VMware | vCPU كثيرة أو Host مزدحم | قلل vCPU غير المستخدمة أو انقل VM إلى Host أقل ازدحاماً. |
| ارتفاع Steal Time في Linux Cloud VM | ضغط على Host أو مشاركة عالية من مزود الخدمة | جرّب Instance Type أعلى أو مزود/خطة مخصصة أكثر. |
| SQL Server بطيء بعد زيادة vCPU | المشكلة قد تكون IO أو Memory أو NUMA أو Query Design | راقب Wait Stats وDisk Latency ولا تجعل CPU هو المتهم الوحيد. |
| Host CPU مرتفع في وقت Backup | مهام Backup أو Antivirus تعمل على عدة VMs في نفس الوقت | وزع الجداول الزمنية خارج أوقات الذروة. |
| تكلفة Cloud مرتفعة | اختيار Instances أكبر من الحاجة أو تشغيلها طوال الوقت | استخدم Right-Sizing وSchedules وReserved Instances عند الحاجة. |
| تطبيق لا يستفيد من كل vCPU | التطبيق Single-threaded أو محدود بخدمة أخرى | لا تزد vCPU؛ حسّن التطبيق أو وزع الحمل أفقياً. |
- CPU Usage داخل VM: هل النظام نفسه يطلب CPU فعلياً؟
- CPU Ready في VMware: هل تنتظر vCPU وقتاً للتنفيذ؟
- CPU Steal في Linux: مفيد خصوصاً في Cloud لمعرفة وقت أخذته البيئة المضيفة.
- Host CPU Utilization: هل الـ Host كله تحت ضغط؟
- Disk Latency: كثير من مشاكل الأداء تبدو كأنها CPU لكنها في الحقيقة Storage.
- Memory Ballooning / Swapping: نقص الذاكرة قد يسبب بطئاً يُفهم خطأً كمشكلة CPU.
Windows داخل VM:
Get-Counter "\Processor(_Total)\% Processor Time"
Get-Counter "\System\Processor Queue Length"
Linux داخل VM:
top
htop
mpstat -P ALL 1
vmstat 1
Linux - مراقبة Steal Time:
top
# ابحث عن قيمة st في سطر CPU
Best Practices لفنيي IT Support
أفضل إدارة للـ vCPU تعتمد على التوازن. هدفك ليس توزيع أكبر عدد من المعالجات الافتراضية، بل تشغيل الخدمات بأداء ثابت مع أقل هدر ممكن. في بيئة شركة، يجب أن يكون هناك معيار واضح لتوزيع المعالج على أنواع السيرفرات المختلفة.
- ابدأ صغيراً: لا تبدأ كل VM بـ 4 أو 8 vCPU. كثير من الخدمات تعمل ممتازاً على 2 vCPU.
- راقب قبل أن تزيد: لا تعتمد على شكوى "السيرفر بطيء" فقط؛ استخدم أرقاماً من Host وGuest.
- لا تستخدم CPU Limit إلا للضرورة: الـ Limits قد تسبب بطئاً غامضاً لاحقاً إذا نسيها الفريق.
- استخدم Reservation بحذر: مناسب للخدمات الحرجة، لكنه قد يقلل مرونة توزيع الموارد.
- انتبه للـ NUMA: في VMs الكبيرة، حاول أن يتناسب عدد vCPU مع حدود NUMA على السيرفر.
- جدول المهام الثقيلة: Backup وAntivirus وReports يجب ألا تعمل كلها في نفس الوقت.
- وثّق كل VM: اكتب سبب اختيار عدد vCPU، نوع الخدمة، ونقطة المراجعة التالية.
- راجع الموارد شهرياً: بعض VMs تأخذ 8 vCPU ولا تستخدم إلا 1 أو 2 فعلياً.
- افصل Production عن Lab: لا تسمح لأجهزة Test بسحب CPU من خدمات الإنتاج.
- احسب الترخيص: بعض المنتجات تعتمد على عدد Cores أو vCPU، والزيادة العشوائية قد ترفع التكلفة.
IT CPU Allocation Standard
Default VM:
- Start with 2 vCPU
- Increase only after monitoring
Domain Controller:
- 2 vCPU
- No CPU Limit
SQL Server:
- Start with 4 vCPU
- Monitor CPU, RAM, Disk Latency, Wait Stats
- Review licensing before increasing
Web Server:
- 2 vCPU
- Prefer horizontal scaling when possible
Dev/Test:
- 1-2 vCPU
- Higher overcommit allowed
Review:
- Monthly right-sizing report
- CPU Ready / Steal Time review
- Remove unused vCPU from idle VMs
مثال عملي من بيئة شركة
لنفترض أن شركة لديها خادمان لتشغيل Proxmox VE أو VMware، وكل خادم يحتوي على 2 CPU، وكل CPU يحتوي على 12 Core، ومع Hyper-Threading يصبح لدينا 48 Logical CPUs لكل Host. الشركة تريد تشغيل خدمات داخلية مثل Active Directory، File Server، SQL Server، ERP، Web Server، Firewall VM، وخادم Backup.
في البداية قام الفريق بإعطاء كل VM عدداً كبيراً من vCPU "للاحتياط". بعد فترة، ظهرت شكاوى من بطء متقطع في ERP وSQL رغم أن الذاكرة والتخزين يبدوان جيدين. عند المراقبة، ظهر أن بعض الـ VMs لا تستخدم CPU فعلياً، لكنها مخصصة بعدد vCPU كبير، مما زاد ضغط الجدولة على الـ Host.
| الخدمة | الإعداد القديم | الإعداد بعد المراجعة | سبب التعديل |
|---|---|---|---|
| DC01 | 4 vCPU | 2 vCPU | الحمل منخفض والخدمة لا تحتاج أكثر. |
| File Server | 8 vCPU | 4 vCPU | المشكلة كانت في التخزين لا المعالج. |
| SQL Server | 8 vCPU | 8 vCPU مع مراقبة دقيقة | الخدمة حرجة وتحتاج CPU فعلياً في أوقات الذروة. |
| ERP App Server | 8 vCPU | 4 vCPU | التطبيق لم يكن يستفيد من كل المعالجات. |
| Web Server | 6 vCPU | 2 vCPU × سيرفرين | التوسع الأفقي أفضل من تضخيم VM واحدة. |
| Backup Server | 4 vCPU وقت الذروة | 4 vCPU مع جدول ليلي | تم نقل الضغط خارج ساعات العمل. |
بعد المراجعة، انخفض عدد vCPU المخصصة غير المستخدمة، وتحسن أداء ERP، وانخفض الضغط على Host خلال ساعات العمل. لم يكن الحل شراء سيرفر جديد، بل إعادة توزيع الموارد بناءً على بيانات حقيقية.
الأسئلة الشائعة
هل vCPU يساوي Core حقيقي؟
ليس دائماً. غالباً vCPU يمثل خيطاً منطقياً أو حصة زمنية من المعالج الحقيقي، ويعتمد ذلك على الـ Hypervisor أو مزود Cloud. لذلك لا تفترض أن 4 vCPU تعني 4 Cores مخصصة بالكامل.
كيف أحسب عدد vCPU المتاحة على السيرفر؟
استخدم المعادلة: عدد المعالجات الفيزيائية × عدد الأنوية لكل معالج × عدد الخيوط لكل نواة. الناتج هو عدد Logical CPUs الذي يمكن للـ Hypervisor جدولته، وليس الحد النهائي لعدد vCPU التي يمكن تخصيصها.
هل زيادة vCPU تحسن الأداء دائماً؟
لا. إذا كان التطبيق لا يستخدم المعالجات الإضافية، فقد لا يتحسن الأداء. وفي حالات الضغط العالي، قد تزيد vCPU الكثيرة من وقت الانتظار وجدولة المعالج، خصوصاً في VMware وبيئات Cloud مزدحمة.
ما هو CPU Ready؟
CPU Ready هو وقت انتظار الـ vCPU قبل أن تحصل على وقت تنفيذ على المعالج الحقيقي. ارتفاعه يعني أن VM تريد العمل لكن الـ Host لا يجد وقت CPU كافياً لها بسرعة.
ما أفضل عدد vCPU لخادم Domain Controller؟
في أغلب الشركات الصغيرة والمتوسطة، 2 vCPU كافية لخادم Domain Controller، بشرط أن يكون DNS مضبوطاً والذاكرة والتخزين مناسبين. الزيادة لا تكون ضرورية إلا عند وجود حمل مصادقة كبير جداً.
ما الفرق بين vCPU في VMware وCloud؟
في VMware أو Proxmox أنت تتحكم بالـ Host والـ Oversubscription. أما في Cloud فأنت تشتري Instance بعدد vCPU محدد، لكن طبيعة مشاركة الموارد تعتمد على نوع Instance وسياسة المزود. لذلك الأداء لا يُقاس بعدد vCPU فقط.
هل يجب تعطيل Hyper-Threading لتحسين الأداء؟
ليس كقاعدة عامة. Hyper-Threading أو SMT يساعد في رفع الاستفادة من المعالج، لكنه لا يضاعف الأداء الحقيقي. بعض الأحمال الحساسة أو متطلبات الترخيص قد تحتاج إعداداً خاصاً، لكن القرار يجب أن يبنى على اختبار ومراقبة.
الخاتمة
الـ vCPU من أهم المفاهيم في عالم Virtualization وCloud، لأنه يربط بين قدرة المعالج الحقيقي وما تراه الأجهزة الافتراضية. فهمه يمنع كثيراً من أخطاء التصميم، مثل إعطاء VMs موارد أكبر من حاجتها، أو تجاهل CPU Ready، أو اختيار Instances سحابية مكلفة دون فائدة حقيقية.
القاعدة العملية هي أن تبدأ بعدد vCPU مناسب، ثم تراقب الأداء من الداخل والخارج. لا تعتمد على CPU Usage داخل VM وحده، بل راقب Host CPU، CPU Ready، Steal Time، Disk Latency، والذاكرة. الأداء الجيد نتيجة توازن كامل بين المعالج والذاكرة والتخزين والشبكة.
الخلاصة: لا تتعامل مع vCPU كرقم تسويقي أو إعداد عشوائي. اعتبره مورداً حساساً يجب حسابه وتوثيقه ومراجعته دورياً. بهذه الطريقة تحصل على بيئة Virtualization مستقرة، تكلفة Cloud أقل، وأداء أفضل للخدمات الحرجة.