أجهزة الكمبيوتر هي الأجهزة. واليوم عدنا إلى نقطة البداية ، بمعنى أنك نادرًا ما تجد مضيفًا فعليًا يتم تنفيذ مهمة واحدة عليه. حتى في حالة تشغيل تطبيق واحد فقط على الخادم ، فمن المحتمل أن يتكون من عدة عمليات أو حاويات أو حتى أجهزة افتراضية (VMs) ، وجميعها تعمل على نفس الخادم. تتواءم Red Hat Enterprise Linux 7 بشكل جيد مع توزيع موارد النظام في مثل هذه المواقف ، ولكن بشكل افتراضي تتصرف مثل الجدة اللطيفة ، وتعامل أحفادها مع كعكة محلية الصنع وتقول: "على قدم المساواة مع الجميع ، على قدم المساواة مع الجميع".
من الناحية النظرية ، مبدأ "مقسم بالتساوي" جميل بالطبع ، ولكن من الناحية العملية ، بعض العمليات أو الحاويات أو VMs أكثر أهمية من غيرها ، وبالتالي يجب أن تتلقى المزيد.
كان لدى Linux منذ فترة طويلة أدوات إدارة الموارد (لطيفة ، ulimit ، وما إلى ذلك) ، ولكن مع ظهور Red Hat Enterprise Linux 7 و systemd ، أصبح لدينا أخيرًا مجموعة قوية من هذه الأدوات المدمجة في نظام التشغيل نفسه. والحقيقة هي أن المكون الرئيسي في systemd هو مجموعة جاهزة ومخصصة من مجموعات cg يتم استخدامها بالكامل على مستوى نظام التشغيل.
حسنًا ، ما نوع هذه المجموعات ، وأين تذهب إدارة الموارد أو الأداء؟
التحكم بمستوى النواة
بدءًا من الإصدار 2.6.24 ، الذي تم إصداره في يناير 2008 ، قدمت نواة Linux ما تم اختراعه وإنشاءه في الأصل من قِبل Google تحت اسم "حاويات المعالجة" ، وفي Linux أصبح يُعرف باسم "مجموعات التحكم" cgroups المختصرة. باختصار ، cgroups هي آلية kernel تتيح لك تقييد الاستخدام والاحتفاظ بالسجلات وعزل استهلاك موارد النظام (وحدة المعالجة المركزية ، والذاكرة ، وإدخال / إخراج القرص ، والشبكة ، وما إلى ذلك) على مستوى مجموعات العمليات. يمكن لـ Cgroups أيضًا تجميد عمليات التحقق وإعادة التشغيل. ظهرت وحدات تحكم Cgroups لأول مرة في الإصدار 6 من Red Hat Enterprise Linux ، ولكن كان يجب تكوينها يدويًا. ولكن مع ظهور Red Hat Enterprise Linux 7 و systemd ، تأتي المجموعة المكونة مسبقًا من مجموعات cg مجمعة مع نظام التشغيل.
كل هذا يعمل على مستوى نواة نظام التشغيل وبالتالي يضمن رقابة صارمة على كل عملية. لذلك من الصعب للغاية على أي برنامج ضار تحميل النظام حتى يتوقف عن الاستجابة ويتجمد. على الرغم من أن رمز عربات التي تجرها الدواب بالطبع مع وصول مباشر إلى الأجهزة (على سبيل المثال ، برامج التشغيل) لا يزال قادرًا على ذلك. في الوقت نفسه ، يوفر Red Hat Enterprise Linux 7 واجهة للتفاعل مع مجموعات cg ، ويتم كل العمل معهم بشكل أساسي من خلال أمر systemd.
قطعة الكعكة الخاصة بك
يوضح الرسم البياني أدناه ، الذي يذكرنا بفطيرة شرائح ، ثلاث مجموعات cg بشكل افتراضي على خادم Red Hat Enterprise Linux 7 - النظام والمستخدم والجهاز. كل من هذه المجموعات تسمى "شريحة" (قطاع شريحة). كما ترى في الشكل ، يمكن أن تحتوي كل شريحة على قطاعات تشريح للأطفال. وكما هو الحال في الكعكة ، في المجموع ، تعطي جميع الشرائح 100 ٪ من المورد المقابل.
الآن دعونا نلقي نظرة على العديد من مفاهيم مجموعات cg باستخدام موارد المعالج كمثال.
يوضح الشكل أعلاه أن وقت المعالج مقسم بالتساوي بين شرائح المستوى الأعلى الثلاثة (النظام والمستخدم والجهاز). ولكن هذا يحدث فقط تحت الحمل. إذا طلبت بعض العمليات من شريحة المستخدم 100٪ من موارد المعالج ، ولا يحتاج أي شخص آخر إلى هذه الموارد في الوقت الحالي ، فستحصل على 100٪ من وقت المعالج.
تم تصميم كل شريحة من الشرائح الثلاث عالية المستوى لنوع عبء العمل الخاص بها ، والذي يقوم بتقطيع القطاعات الفرعية داخل الشريحة الرئيسية:
- النظام - الشياطين والخدمات.
- جلسات المستخدم - المستخدم. يتلقى كل مستخدم شريحة فرعية ، وجميع الجلسات التي لها نفس معرف المستخدم "مباشرة" في نفس الشريحة ، بحيث لا يمكن للمختصين الماكرين بشكل خاص الحصول على الموارد أكثر مما ينبغي.
- الآلة - الأجهزة الافتراضية ، مثل ضيوف KVM.
بالإضافة إلى ذلك ، يتم استخدام مفهوم ما يسمى بـ "الكرة" (حصة) للتحكم في استخدام الموارد. الكرة هي معلمة عددية نسبية ؛ قيمتها منطقية فقط بالمقارنة مع قيم الكرات الأخرى المدرجة في نفس المجموعة. بشكل افتراضي ، تحتوي جميع الشرائح على كرة تساوي 1024. في شريحة النظام في الشكل أعلاه ، يتم تعيين كرات CPU تساوي 1024 على httpd و sshd و crond و gdm. قيم الكرة لشرائح النظام والمستخدم والآلة هي أيضًا 1024. هل هذا مربك قليلاً؟ في الواقع ، يمكن تمثيل ذلك كشجرة:
- النظام - 1024
- httpd - 1024
- SSD - 1024
- صليب - 1024
- غدم - 1024
- المستخدم - 1024
- باش (mrichter) - 1024
- باش (دورف) - 1024
- آلة - 1024
في هذه القائمة ، لدينا عدة برامج تشغيل ، واثنين من المستخدمين ، وجهاز افتراضي واحد. تخيل الآن أنهم جميعًا يطلبون في نفس الوقت كل وقت المعالج الذي يمكن الحصول عليه.
باختصار:
- يتلقى نظام Slice System 33.333٪ من وقت المعالج ويشاركه بالتساوي بين أربعة شياطين ، مما يمنح كل واحد منهم 8.25٪ من موارد وحدة المعالجة المركزية.
- تتلقى شريحة المستخدم 33.333٪ من وقت وحدة المعالجة المركزية وتشاركها بين مستخدمين اثنين ، كل منهما يحتوي على 16.5٪ من موارد وحدة المعالجة المركزية. إذا قام المستخدم بتسجيل خروج أو إيقاف جميع عملياته الجارية ، فسيتمكن dorf من الوصول إلى 33٪ من موارد وحدة المعالجة المركزية.
- تتلقى Slice Machine 33.333٪ من وقت المعالج. إذا قمت بإيقاف تشغيل الجهاز الظاهري أو وضعه في وضع الخمول ، فستتلقى شرائح النظام والمستخدم حوالي 50٪ من موارد وحدة المعالجة المركزية ، والتي سيتم مشاركتها بعد ذلك بين الشرائح الفرعية.
بالإضافة إلى ذلك ، بالنسبة لأي برنامج خفي أو مستخدم أو جهاز افتراضي ، لا يمكنك إدخال قيود نسبية فحسب ، بل أيضًا قيودًا مطلقة على استهلاك وقت المعالج ، وليس واحدًا فقط ، ولكن أيضًا معالجات متعددة. على سبيل المثال ، شريحة المستخدم لها خاصية CPUQuota. إذا قمت بتعيينه إلى 20٪ ، فلن يتلقى Mrichter تحت أي ظرف من الظروف أكثر من 20٪ من موارد وحدة المعالجة المركزية الواحدة. على الخوادم متعددة النواة ، يمكن أن تكون CPUQuota أكثر من 100٪ بحيث يمكن للشريحة استخدام موارد أكثر من معالج واحد. على سبيل المثال ، باستخدام CPUQuota = 200٪ ، يمكن للشريحة أن تستخدم نواتين للمعالج بشكل كامل. من المهم أن نفهم أن CPUQuota لا تحجز ، بمعنى آخر ، أنها لا تضمن نسبة معينة من وقت المعالج لأي تحميل للنظام - وهذا هو الحد الأقصى فقط الذي يمكن تخصيصه للشريحة مع مراعاة جميع الشرائح والإعدادات الأخرى.
تطور إلى أقصى حد!
كيف يمكنني تغيير إعدادات الشريحة؟
لهذا ، كل شريحة لها خصائص مخصصة. وبما أنه Linux ، يمكننا كتابة الإعدادات يدويًا في ملفات التكوين أو تعيينها من سطر الأوامر.
في الحالة الثانية ، يتم استخدام الأمر systemctl set-property. إليك ما سيحدث على الشاشة إذا كتبت هذا الأمر ، وأضف اسم الشريحة في النهاية (في حالتنا ، المستخدم) ثم اضغط على مفتاح Tab لعرض الخيارات:
ليست كل الخصائص في لقطة الشاشة هذه هي إعدادات cgroup. نحن مهتمون بشكل رئيسي بتلك التي تبدأ على Block و CPU و Memory.
إذا كنت لا تفضل سطر الأوامر ، ولكن ملفات التكوين (على سبيل المثال ، للنشر الآلي على عدة مضيفين) ، فسيتعين عليك التعامل مع الملفات الموجودة في المجلد / etc / systemd / system. يتم إنشاء هذه الملفات تلقائيًا عند تعيين الخصائص باستخدام الأمر systemctl ، ولكن يمكن أيضًا إنشاؤها في محرر نصوص ، أو ختمها من خلال Puppet ، أو حتى إنشاؤها بواسطة النصوص البرمجية أثناء التنقل.
لذا ، مع المفاهيم الأساسية للمجموعات ، يجب أن يكون كل شيء واضحًا. في المرة القادمة سنتناول بعض السيناريوهات ونرى كيف تؤثر التغييرات في خصائص معينة على الأداء.
وغداً ، ندعو الجميع إلى Red Hat Forum Russia 2018 - ستكون هناك فرصة لطرح الأسئلة مباشرة على مهندسي Red Hat.منشورات مجموعات أخرى من سلسلة Resource Resource لدينا متوفرة على: