منذ بعض الوقت ، قال أحد زملائي أن المكان في DC ينفد ، ولا يوجد مكان لوضع الخادم ، والحمل ينمو وليس من الواضح ما يجب فعله ، ومن المحتمل أن تضطر إلى تغيير جميع الخوادم المتاحة إلى خوادم أكثر قوة.
في ذلك الوقت كنت منخرطًا في مهمة تجميع الجداول المثلى ، وفكرت - ولكن ماذا لو طبقنا خوارزميات التحسين لزيادة استخدام الخادم في العاصمة؟ من هنا ولد المشروع الذي أريد أن أكتب عنه.
بالنسبة للمستخدمين المتقدمين ، سأقول على الفور أننا سنتحدث في هذه المقالة عن تعبئة سلة المهملات ، وبالنسبة للبقية الذين يرغبون في تعلم كيفية توفير ما يصل إلى 30٪ من موارد الخادم باستخدام حسابات بسيطة نسبيًا ، مرحبًا بكم في القطط.
لذلك ، لدينا DC مع ما يقرب من 100 خادم ، يستضيف حوالي 7000 جهاز افتراضي. ما هو داخل الأجهزة الافتراضية - لا نعرف ولا يجب أن نعرف. من الضروري وضع أجهزة افتراضية على الخوادم لإجراء SLA وفي نفس الوقت استخدام الحد الأدنى من الخوادم.
نحن نعلم:
- قائمة الخادم
- كمية الموارد على كل خادم (وقت وحدة المعالجة المركزية ، وحدة المعالجة المركزية ، ذاكرة الوصول العشوائي ، القرص ، القرص الصلب ، شبكة الاتصال).
- قائمة الأجهزة الافتراضية (VM)
- مقدار الموارد التي يستهلكها كل جهاز ظاهري (وقت وحدة المعالجة المركزية ، ونواة وحدة المعالجة المركزية ، وذاكرة الوصول العشوائي ، والقرص ، والقرص io ، والشبكة io).
- استهلاك الموارد من قبل النظام المضيف على الخوادم.
نحتاج إلى توزيع الأجهزة الافتراضية بين الخوادم بحيث لا يتجاوز كل من الموارد الموجودة على كل خادم الكمية المتاحة من المورد ، وفي نفس الوقت يستخدم الحد الأدنى من الخوادم.
تسمى هذه المهمة في الأدبيات العلمية مشكلة التعبئة بن (كيف ستكون باللغة الروسية؟). بعبارات بسيطة ، هذه مهمة حول كيفية دفع الصناديق الصغيرة ذات الأحجام العشوائية إلى مربعات كبيرة ، وفي نفس الوقت استخدام الحد الأدنى لعدد الصناديق الكبيرة. يتم حل المشكلة المعروفة في الرياضيات ، NP-complete ، على وجه التحديد فقط من خلال البحث الشامل ، الذي تتزايد تكلفته بشكل توافقي.
توضح الصورة أدناه جوهر خوارزمية تعبئة الصندوق للحالة أحادية البعد:
التين. 1. توضيح مشكلة تعبئة الصندوق ، وضعه غير الأمثلفي الشكل الأول ، يتم توزيع العناصر بطريقة أو بأخرى بين السلال وتستخدم 3 سلال لوضعها.
التين. 2. توضيح مشكلة التعبئة بن ، الوضع الأمثلتظهر الصورة الثانية التوزيع الأمثل ، الذي تحتاج إليه فقط سلتين.
تفترض الصيغة القياسية لخوارزمية تعبئة الصناديق أيضًا أن جميع السلال متشابهة. خوادمنا ليست هي نفسها ، حيث تم شراؤها في أوقات مختلفة وتكوينها مختلف - عدد مختلف من نوى المعالج والذاكرة والقرص وقوة المعالج المختلفة.
يمكن الحصول على حل دون المستوى الأمثل باستخدام الاستدلال ، والخوارزميات الجينية ، والبحث عن أشجار مونت كارلو والشبكات العصبية العميقة. استقرنا على خوارزمية BestFit الإرشادية ، والتي تتقارب إلى حل لا يزيد عن 1.7 مرة أسوأ من الحل الأمثل ، وكذلك على بعض الاختلافات في الخوارزمية الجينية. أدناه سأعطي نتائج طلبهم.
ولكن أولاً ، دعنا نناقش ما يجب فعله مع المقاييس المتغيرة بمرور الوقت ، مثل استخدام وحدة المعالجة المركزية ، القرص io ، الشبكة io. أسهل طريقة هي استبدال المقياس المتغير بثابت. ولكن كيف تختار قيمة هذا الثابت؟ لقد أخذنا القيمة القصوى للمقياس لبعض الفترة المميزة (القيم المتطرفة السابقة للقيم). تحول الأسبوع إلى فترة مميزة في حالتنا ، حيث أن الموسمية الرئيسية في الحمل كانت مرتبطة بأيام العمل وأيام العطلات.
في هذا النموذج ، يتم تخصيص شريط موارد لكل جهاز افتراضي بحجم الحد الأقصى لقيمة الموارد المستهلكة ، ويتم وصف كل جهاز افتراضي بواسطة الثوابت القصوى لاستخدام وحدة المعالجة المركزية ، وذاكرة الوصول العشوائي ، والقرص ، والحد الأقصى للقرص io ، والحد الأقصى لشبكة IO.
بعد ذلك ، نستخدم الخوارزمية لحساب التعبئة المثلى والحصول على خريطة لموقع الخوادم المادية VM.
تبين الممارسة أنه إذا لم تترك هامشًا معينًا لكل من الموارد الموجودة على الخادم ، فعندما يتم تخصيص VM بكثافة ، يصبح الخادم مثقلًا. لذلك ، بالنسبة لاستخدام وحدة المعالجة المركزية ، نترك هامشًا بنسبة 30٪ ، لذاكرة الوصول العشوائي 20٪ ، للقرص io - 20٪ ، للشبكة io - 20٪ ، يتم تحديد هذه الحدود بشكل تجريبي.
لدينا أيضًا عدة أنواع من الأقراص (محركات أقراص SSD سريعة ومحركات أقراص ثابتة بطيئة رخيصة الثمن) ، لكل نوع من أنواع الأقراص نأخذ مقاييس القرص والأقراص io بشكل منفصل ، لذلك يصبح النموذج النهائي أكثر تعقيدًا إلى حد ما ولديه أبعاد أكثر.
تظهر نتيجة تحسين وضع VM في الرسم التخطيطي:
التين. 3. نتيجة تحسين وضع VMs على الخوادمأفقي - عدد الخوادم التي تم تحسينها ، رأسيًا - عدد الخوادم التي تم تحريرها لاستدلال BestFit والخوارزمية الجينية.
ما هي الاستنتاجات التي يمكن استخلاصها من الرسم التخطيطي؟
- بالنسبة للمهام الحالية ، يمكنك استخدام خوادم أقل بنسبة 20-30٪.
- كلما زاد عدد الخوادم التي تقوم بتحسينها في كل مرة ، كلما فزت بنسبة٪ ، مع عدد الخوادم 40 وما فوق ، يحدث التشبع.
- الخوارزمية الجينية أعلى قليلاً من BestFit الإرشادي. إذا أردنا تحسين نتائجنا بشكل أكبر ، فسوف نحفر في هذا الاتجاه.
ما هي المشاكل الأخرى التي ظهرت عمليا؟
- إذا كنت ترغب في تغيير حوالي 100 خادم باستخدام 7000 جهاز افتراضي ، فإن حجم عمليات الترحيل سيكون كبيرًا للغاية ، بحيث لا يمكن تحقيق الفكرة بأكملها. ولكن إذا كنت تعمل مع مجموعات من 20 إلى 40 خادمًا بالتسلسل ، فسيكون التأثير الذي ستحصل عليه هو نفسه تقريبًا ، ولكن عدد عمليات الترحيل سيكون أقل عدة مرات. ويمكنك تحسين DC الخاص بك في أجزاء.
- إذا كان يجب عليك القيام بعمليات الترحيل الحية ، فقد تواجه موقفًا لا يمكن أن تنتهي فيه الهجرة. هذا يعني أنه يوجد داخل الجهاز الظاهري كتابة مكثفة على القرص و / أو حالة تغيرات الذاكرة ، وأن حالات الجهاز الظاهري بين النسخ المتماثلة القديمة والجديدة ليس لديها وقت للمزامنة حتى تتغير حالة النسخة المتماثلة القديمة. في هذه الحالة ، تحتاج إلى التحديد المسبق لآلات VM هذه ووضع علامة عليها على أنها غير متحركة. وهذا بدوره يتطلب تعديل خوارزميات التحسين. ما يرضي هو أن إجمالي الربح مستقل عمليًا عن عدد هذه الآلات ، إذا لم يكن هناك أكثر من 10-15 ٪ من إجمالي عدد الأجهزة الظاهرية.
كيف يتغير تحميل الخادم بعد تحسين وضع VM؟
حسنًا ، لقد قمنا بتحسين موضع VM. ربما تكون الحالة الجديدة الناتجة هشة للغاية فيما يتعلق بزيادة الحمل؟ ربما تعمل الخوادم إلى الحد الأقصى وأي زيادة في الحمل ستقتلها؟
قارنا استخدام موارد الخادم قبل التحسين وبعد فترة لمدة أسبوع واحد. ما حدث مبين في الشكل 2:
التين. 4. التغيير في حمل وحدة المعالجة المركزية بعد تحسين تخصيص VMوفقًا لاستخدام وحدة المعالجة المركزية: ارتفع متوسط استخدام وحدة المعالجة المركزية من 10٪ إلى 18٪ فقط. على سبيل المثال لدينا هامش ثلاثي لأداء وحدة المعالجة المركزية ، بينما ستبقى الخوادم في ما يسمى بالمنطقة "الخضراء".
كيف تم ذلك في البرنامج؟
نجمع المقاييس التي نحتاجها في Yandex.ClickHouse (لقد جربنا InfluxDB ، ولكن في استعلامات أحجام البيانات لدينا مع التجميع يتم إجراؤها ببطء شديد) بتردد 30 ثانية. من هناك ، تقوم مهمة حساب الحالة المثلى بقراءة المقاييس ، وحساب الحد الأقصى من الاستهلاك منها ، وإنشاء مهمة حساب يتم وضعها في قائمة الانتظار. بمجرد اكتمال مهمة الحساب ، يتم تشغيل الاختبارات للتحقق من أن النتيجة لا تتجاوز الحدود المحددة.
هل قام أي شخص بذلك بالفعل؟
من المعروف لنا ، توجد خوارزميات مماثلة داخل VMware vSphere و Nutanix وتظهر داخل OpenStack (مشروع OpenStack Watcher).
هل من الممكن القيام بعمل أفضل؟
نعم يمكنك ذلك. في المقالة التالية ، سأخبرك بكيفية حزم الأجهزة الافتراضية حتى أكثر كثافة دون انتهاك SLA ، ولماذا هناك حاجة للخلايا العصبية لهذا الغرض.