CPU Scheduler

لو عندك VM ولسبب ما زودت VCPU بدل من 8 VCPUs خلتها 16 VCPUs هل تعقد ان ده هيحسن كفائه VM ولا هتبقى اسوء ؟

فى حالات كتير شفتها بالذات فى Exchange Server او SQL Server كفائه VM بتقل جدا وبيبقى فى Delay رهيب بعد لما الكلاينت زود VCPU اعتقادا منه ان ده هيحسن كفائه VM وده هيخلنا نسال طب ليه بيحصل كده هو مش المنطق بيقول كل ما resource زادت كل ما كفائه السرفير بقت احسن

ده هيخلنا نروح لجزئيه ايه هو CPU Scheduler وبيشغتل ازاى وكمان ايه هو CPU Ready Time وبيتحدد ازاى الموضوع طويل ورخم شويه جيب القهوه بتاعتك وركز معايا

ايه هو CPU Scheduler هي الطريقه اللي بيستخدمها Vsphere بيقدر يوزع بيها CPU على كل Workload عندك بيحث انه يخلى كل VM تقدر تستخدم Physical CPU وطبعا ده بيتحدد بناءا على حاجات كتير زى CPU cache, memory locality, performance needs, priorities, I/O to storage وغيرها من النقط اللى بيحطها CPU Scheduler فى الحسبان عشان يقدر يوزع Physical CPU على كل VMs اللى عندك

بدايه من Vsphere 6.7 هو بيدعم 3 انواع من CPU Scheduler وهما default, SCAv1, SCAv2

بس قبل ما ناخود فكره سريعه عن كل نوع من دول خلينا اقولك الاول CPU vulnerabilities بتعمل لينا مشكله كبيره لانها بتمكن الهكر انه يتخطى كل القيود اللى محطوطه مابين البرسيسور بختلاف Core مثلا او Hyper-Threading وبتقدر تخليه يحصل على الدتا وممكن تكون الدتا دى عباره عن يوزرنيم وباسورد وممكن تكون معلومات تانيه مهمه زى مثلا ثغره L1TF vulnerability اللى بتمكن الهكر انه يسرب البيانات ويحصل عليها مابين 2 threads فى CPU Core بالتحديد فى البروسيسور Intel Hyper-Threading وفى غيرها ثغرات كتير تقدر تقرا عنها واللى بتسبب خطر حقيقي على مستوى الحمايه عندك فى الشبكه وطبعا الشركه المصنعه للبروسيسور بتقابل مهمه صعبه جدا انه تقفل vulnerabilities لان البروسيسور اتصنعت واتركبت فى سرفيرات والسرفيرات اتباعت واشتغلت عند الكاستمر وساعتها بيبقى مافيش غير حل واحد انه تنزل firmware updates او انها تبعت لشركات السوفت وير microcode اللى تقدر تساعد شركات السوفت وير انه تقفل الثغره دى عن طريق السوفت وير بتاعها

وهنا بقى اقدر اقولك ان SCAv1, SCAv2 اللي بيشتغل بيهم CPU Scheduler بيقدريقفل الثغرات دى بستخدام microcode اللى بعتها الشركه المصنعه للبرسيسور لشركه VMware ولكن ده بيكون على حساب capacity و ال performance

سريعا كده هنذكر الفرق مابين انواع CPU Scheduler بس الموضوع تقدرتقراه بالتفصيل من المصادر

Default CPU Scheduler : وده مالوش علاقه باى ثغرات فى البرسيسور والحمايه بتاعته بتكون مابين اتنين ESXI مختلفين عشان كده بيطلق عليه Host Security Boundary ولكن هو احسنهم من حيث الكفائه

Side-Channel Aware Scheduler v1 (SCAv1) : وزى ماقولنا ده بيكون عنده علم وحلول لثغرات البروسيسور والحمايه بتاعته بتكون على مستوى البرسيسور عشان كده بيطلق عليه process Security Boundary ولكن بطئ شويه
Side-Channel Aware Scheduler v2 (SCAv2) : وده كمان بيكون عنده علم وحلول لثغرات البروسيسور والحمايه بتاعته بتكون على مستوى VM عشان كده بيطلق عليه VM Security Boundary ولكن فى نقط كتير لازم تحطها فى الاعتبار ولازم تكون موجوده عندك قبل ما تستخدمه زى مثلا Microsoft VBS

واحب اقفل الجزء من الشرح لاننا ممكن نعد نتكلم فيه لحد بكره انك بتحدد Scheduler اللى هتشتغل بيه بناءا على البيئه عندك وعلى احتياجك كل واحد وليه خصائص وليه عيوب وبناء على احتياجك هتقدر تختار النوع اللى هشتغل بيه وتقدر تقرا باستفاضه فى النقطه دى من المصادر

بعد ما عرفنا ايه هو CPU Scheduler دلوقتى محتاجين نعرف ايه هو CPU Ready Time

CPU Ready Time : ببساطه هو الوقت اللى VM بتنتظره لحد ما Scheduler يحددلها Physical CPUs اللى هتستخدمه الطبيعى انه تكون القيمه دى صغيره لوPhysical Processors عندك متاحه ومافيش اى overload عليها لكن ايه اللى هيحصل فى حاله ان كل Physical CPUs كلها مستخدمه ومافيش اى CPU متاحه

قبل ما اجوبك على السوال ده خلينا نفتكر سوا انك تقدر تحدد فى VM عندك لحد 128 VCPU وتقدر تحدد ده على اكتر من VM ولكن فى الحقيقه انت ماعندكش العدد ده من Physical CPUs يعنى مثلا انت ممكن يكون عندك 2 socket كل Socket فيه 32 cores يبقى عندنا 64 cores مع Hyperthreading بقى عدنا 128 CPUs ازاى بقى اقدر احدد القميه دى على اكتر من VMs فى نفس الوقت مع مرعاه ان VCPU اللى هتحدد على VM الوحده ماتتعدش عدد logical CPUs عندك وان OS بيكون بيدعم Virtual SMP

المعلومات المتاحه من VMware بتقول ان CPU Scheduler بتكون relaxed co-scheduler بدايه من اصدار ESXI 3 وساعتها VMware قدرت انها تتعامل مع CPU Cell Model وكنا بنقدر نحدد 4 VCPUs كحد اقصي للVM الوحده فى حاله لما يكون عندك Physical CPU فيه 4 Cores

من اول اصدار ESXI 4 ومع تطور السريع اللي بيحصل فى االبرسيسور ادركت شركه VMware ان طريقه Cell Model مش هتنفع وعملت طريقه finer-grained locks ودى بتمكن VM انها تقدر تستخدم اكترمن Physical CPU نفس الوقت وتقدرتحدد VCPU واحده لانجاز مهمه معينه وده ادى امكانيه لنظام التشغيل انه يقدر يستخدم VCPU لعمل process لحاجه معينه مما ادى الى التعامل مع Physical CPUs بشكل احسن من الاصدرات السابقه وقدت شركه Vmware ساعتها انها تطلع من 4 VCPUs الى 8 VCPUs لل VM الوحده

من اول اصدار ESXI 5 شركه VMware عملت تحسينات جامده جدا فى الجزء ده بالتحديد فى SMP scheduling وقدرت انه تزود SMT application performance وده خلاها تقدر توصل 32 VCPUs لل VM الوحده
واخيرا قبل ما اقفل الجزء ده لانه فعلا بيحسسنا اننا فى فليم خيال علمى والمعلومات فيه كتير جدا ومعقده اقدر اقولك ان VMware قدرت توصل فى الاصدار Vsphere 6.5 & Vspere 6.7 انك تقدر تحدد 128 VCPUs لل VM الوحده وفى اصدار Vsphere 7 بقيت تقدر تحدد 768 VCPUs لل VM الوحده مع مراعاه النقط اللى قولنها فوق

دلوقتى كلنا نقدر نستنتج ايه اللى هيحصل لو VM محتاجه تقوم بعمل process لدتا معينه ومعندكش اي Physical CPU متاح وكل logical CPU محجزوين وشغالين ل VMs تانيه ساعتها قيمه CPU Ready Time هتبقى عاليه وهتبقى كفاءه VM وحشه جدا وبطيئه وبتهنج وعشان تقدر تشوف CPU Ready Time تقدر تشوفه من اكتر من طريقه ممكن عن طريق Command باستخدام الامر esxtop وممكن عن طريق vCenter بانك تروح

Performance tab. Select Advanced > Chart Options > CPU > Real Time > Ready

فى الاغلب بتكون القيمه مابين 0-50ms وبتتحسب قيمه Real Time بال milliseconds فى الحاله دي بتسمى guest heartbeat وخلينى اقولك انه لحد 250 or 300ms فهو مقبول اعلى من كده هيعمل مشاكل فى VM فى الحاله دى حضرتك محتاج تقلل VCPU لو فعلا الابلكيشن مش محتاجه او تزود Physical CPUs

بعد ماقولتلك ازاى تشوف CPU Ready Time تعاله اقولك ازاى تحسبها وعشان تحسب CPU Ready Time عندك طرقتين

الطريقه اليدويه : هى عن طريق انك هتطبق المعادله الموجوده فى الموقع ده https://kb.vmware.com/s/article/2002181 وهتقدر من خلاله تحسب قيمه Ready Time لل VM بتاعتك فى 5 دقايق وفى يوم وفى اسبوع وفى شهر وتقدر تحدد من خلالها ان فعلا VM عندها مشكله فى performance بالتحديد فى CPU ولا لاء

بعض السيستم بتقدر تحسب Ready Time لل VM بتاعتك وتقدر كمان تديك نصايح بانك مثلا لو محدد 16VCPUs ولكن هى فعلا محتاجه 8VCPUs بناءا على الدتا اللى يجمعها عن VM وقدر يحسب Ready Time فى فتره زمنيه معينه
ومن السيستم الجميله اللى بحبها وتعمل كده VMware vRealize Operations

معلش انا عارف ان المقال طول مني ولكن هو فعلا موضوع معقد نسبيا ومتشعب والكلام فيه مابيخلصش واتمنى انى اكون وضحت ولو فكره بسيطه عنه

CPU Scheduler

لو عندك VM ولسبب ما زودت VCPU بدل من 8 VCPUs خلتها 16 VCPUs هل تعقد ان ده هيحسن كفائه VM ولا هتبقى اسوء ؟

فى حالات كتير شفتها بالذات فى Exchange Server او SQL Server كفائه VM بتقل جدا وبيبقى فى Delay رهيب بعد لما الكلاينت زود VCPU اعتقادا منه ان ده هيحسن كفائه VM وده هيخلنا نسال طب ليه بيحصل كده هو مش المنطق بيقول كل ما resource زادت كل ما كفائه السرفير بقت احسن

ده هيخلنا نروح لجزئيه ايه هو CPU Scheduler وبيشغتل ازاى وكمان ايه هو CPU Ready Time وبيتحدد ازاى الموضوع طويل ورخم شويه جيب القهوه بتاعتك وركز معايا

ايه هو CPU Scheduler هي الطريقه اللي بيستخدمها Vsphere بيقدر يوزع بيها CPU على كل Workload عندك بيحث انه يخلى كل VM تقدر تستخدم Physical CPU وطبعا ده بيتحدد بناءا على حاجات كتير زى CPU cache, memory locality, performance needs, priorities, I/O to storage وغيرها من النقط اللى بيحطها CPU Scheduler فى الحسبان عشان يقدر يوزع Physical CPU على كل VMs اللى عندك

بدايه من Vsphere 6.7 هو بيدعم 3 انواع من CPU Scheduler وهما default, SCAv1, SCAv2

بس قبل ما ناخود فكره سريعه عن كل نوع من دول خلينا اقولك الاول CPU vulnerabilities بتعمل لينا مشكله كبيره لانها بتمكن الهكر انه يتخطى كل القيود اللى محطوطه مابين البرسيسور بختلاف Core مثلا او Hyper-Threading وبتقدر تخليه يحصل على الدتا وممكن تكون الدتا دى عباره عن يوزرنيم وباسورد وممكن تكون معلومات تانيه مهمه زى مثلا ثغره L1TF vulnerability اللى بتمكن الهكر انه يسرب البيانات ويحصل عليها مابين 2 threads فى CPU Core بالتحديد فى البروسيسور Intel Hyper-Threading وفى غيرها ثغرات كتير تقدر تقرا عنها واللى بتسبب خطر حقيقي على مستوى الحمايه عندك فى الشبكه وطبعا الشركه المصنعه للبروسيسور بتقابل مهمه صعبه جدا انه تقفل vulnerabilities لان البروسيسور اتصنعت واتركبت فى سرفيرات والسرفيرات اتباعت واشتغلت عند الكاستمر وساعتها بيبقى مافيش غير حل واحد انه تنزل firmware updates او انها تبعت لشركات السوفت وير microcode اللى تقدر تساعد شركات السوفت وير انه تقفل الثغره دى عن طريق السوفت وير بتاعها

وهنا بقى اقدر اقولك ان SCAv1, SCAv2 اللي بيشتغل بيهم CPU Scheduler بيقدريقفل الثغرات دى بستخدام microcode اللى بعتها الشركه المصنعه للبرسيسور لشركه VMware ولكن ده بيكون على حساب capacity و ال performance

سريعا كده هنذكر الفرق مابين انواع CPU Scheduler بس الموضوع تقدرتقراه بالتفصيل من المصادر

Default CPU Scheduler : وده مالوش علاقه باى ثغرات فى البرسيسور والحمايه بتاعته بتكون مابين اتنين ESXI مختلفين عشان كده بيطلق عليه Host Security Boundary ولكن هو احسنهم من حيث الكفائه

Side-Channel Aware Scheduler v1 (SCAv1) : وزى ماقولنا ده بيكون عنده علم وحلول لثغرات البروسيسور والحمايه بتاعته بتكون على مستوى البرسيسور عشان كده بيطلق عليه process Security Boundary ولكن بطئ شويه
Side-Channel Aware Scheduler v2 (SCAv2) : وده كمان بيكون عنده علم وحلول لثغرات البروسيسور والحمايه بتاعته بتكون على مستوى VM عشان كده بيطلق عليه VM Security Boundary ولكن فى نقط كتير لازم تحطها فى الاعتبار ولازم تكون موجوده عندك قبل ما تستخدمه زى مثلا Microsoft VBS

واحب اقفل الجزء من الشرح لاننا ممكن نعد نتكلم فيه لحد بكره انك بتحدد Scheduler اللى هتشتغل بيه بناءا على البيئه عندك وعلى احتياجك كل واحد وليه خصائص وليه عيوب وبناء على احتياجك هتقدر تختار النوع اللى هشتغل بيه وتقدر تقرا باستفاضه فى النقطه دى من المصادر

بعد ما عرفنا ايه هو CPU Scheduler دلوقتى محتاجين نعرف ايه هو CPU Ready Time

CPU Ready Time : ببساطه هو الوقت اللى VM بتنتظره لحد ما Scheduler يحددلها Physical CPUs اللى هتستخدمه الطبيعى انه تكون القيمه دى صغيره لوPhysical Processors عندك متاحه ومافيش اى overload عليها لكن ايه اللى هيحصل فى حاله ان كل Physical CPUs كلها مستخدمه ومافيش اى CPU متاحه

قبل ما اجوبك على السوال ده خلينا نفتكر سوا انك تقدر تحدد فى VM عندك لحد 128 VCPU وتقدر تحدد ده على اكتر من VM ولكن فى الحقيقه انت ماعندكش العدد ده من Physical CPUs يعنى مثلا انت ممكن يكون عندك 2 socket كل Socket فيه 32 cores يبقى عندنا 64 cores مع Hyperthreading بقى عدنا 128 CPUs ازاى بقى اقدر احدد القميه دى على اكتر من VMs فى نفس الوقت مع مرعاه ان VCPU اللى هتحدد على VM الوحده ماتتعدش عدد logical CPUs عندك وان OS بيكون بيدعم Virtual SMP

المعلومات المتاحه من VMware بتقول ان CPU Scheduler بتكون relaxed co-scheduler بدايه من اصدار ESXI 3 وساعتها VMware قدرت انها تتعامل مع CPU Cell Model وكنا بنقدر نحدد 4 VCPUs كحد اقصي للVM الوحده فى حاله لما يكون عندك Physical CPU فيه 4 Cores

من اول اصدار ESXI 4 ومع تطور السريع اللي بيحصل فى االبرسيسور ادركت شركه VMware ان طريقه Cell Model مش هتنفع وعملت طريقه finer-grained locks ودى بتمكن VM انها تقدر تستخدم اكترمن Physical CPU نفس الوقت وتقدرتحدد VCPU واحده لانجاز مهمه معينه وده ادى امكانيه لنظام التشغيل انه يقدر يستخدم VCPU لعمل process لحاجه معينه مما ادى الى التعامل مع Physical CPUs بشكل احسن من الاصدرات السابقه وقدت شركه Vmware ساعتها انها تطلع من 4 VCPUs الى 8 VCPUs لل VM الوحده

من اول اصدار ESXI 5 شركه VMware عملت تحسينات جامده جدا فى الجزء ده بالتحديد فى SMP scheduling وقدرت انه تزود SMT application performance وده خلاها تقدر توصل 32 VCPUs لل VM الوحده
واخيرا قبل ما اقفل الجزء ده لانه فعلا بيحسسنا اننا فى فليم خيال علمى والمعلومات فيه كتير جدا ومعقده اقدر اقولك ان VMware قدرت توصل فى الاصدار Vsphere 6.5 & Vspere 6.7 انك تقدر تحدد 128 VCPUs لل VM الوحده وفى اصدار Vsphere 7 بقيت تقدر تحدد 768 VCPUs لل VM الوحده مع مراعاه النقط اللى قولنها فوق

دلوقتى كلنا نقدر نستنتج ايه اللى هيحصل لو VM محتاجه تقوم بعمل process لدتا معينه ومعندكش اي Physical CPU متاح وكل logical CPU محجزوين وشغالين ل VMs تانيه ساعتها قيمه CPU Ready Time هتبقى عاليه وهتبقى كفاءه VM وحشه جدا وبطيئه وبتهنج وعشان تقدر تشوف CPU Ready Time تقدر تشوفه من اكتر من طريقه ممكن عن طريق Command باستخدام الامر esxtop وممكن عن طريق vCenter بانك تروح

Performance tab. Select Advanced > Chart Options > CPU > Real Time > Ready

فى الاغلب بتكون القيمه مابين 0-50ms وبتتحسب قيمه Real Time بال milliseconds فى الحاله دي بتسمى guest heartbeat وخلينى اقولك انه لحد 250 or 300ms فهو مقبول اعلى من كده هيعمل مشاكل فى VM فى الحاله دى حضرتك محتاج تقلل VCPU لو فعلا الابلكيشن مش محتاجه او تزود Physical CPUs

بعد ماقولتلك ازاى تشوف CPU Ready Time تعاله اقولك ازاى تحسبها وعشان تحسب CPU Ready Time عندك طرقتين

الطريقه اليدويه : هى عن طريق انك هتطبق المعادله الموجوده فى الموقع ده https://kb.vmware.com/s/article/2002181 وهتقدر من خلاله تحسب قيمه Ready Time لل VM بتاعتك فى 5 دقايق وفى يوم وفى اسبوع وفى شهر وتقدر تحدد من خلالها ان فعلا VM عندها مشكله فى performance بالتحديد فى CPU ولا لاء

بعض السيستم بتقدر تحسب Ready Time لل VM بتاعتك وتقدر كمان تديك نصايح بانك مثلا لو محدد 16VCPUs ولكن هى فعلا محتاجه 8VCPUs بناءا على الدتا اللى يجمعها عن VM وقدر يحسب Ready Time فى فتره زمنيه معينه
ومن السيستم الجميله اللى بحبها وتعمل كده VMware vRealize Operations

معلش انا عارف ان المقال طول مني ولكن هو فعلا موضوع معقد نسبيا ومتشعب والكلام فيه مابيخلصش واتمنى انى اكون وضحت ولو فكره بسيطه عنه