👨🏿 🚴🏿 ↗️ تقييم مقاييس حمل الخادم المتكاملة 🚶🏿 🖊️ 🤲🏾

من خلال العمل في أحد أكبر البنوك في الدولة ، كان عليّ مواجهة مهمة تقييم كفاءة استخدام الموارد لما يقرب من 16 ألف خادم. تمت صياغة المهمة ببساطة شديدة - كان من الضروري تطوير منهجية لتقييم مقاييس حمل الخادم لفترة. من الناحية المثالية ، يجب تقدير حمل الخادم لكل فترة باستخدام رقم واحد أو أكثر (لا يزيد عن 8) أرقام.

بضع كلمات حول ميزات استخدام الخوادم الافتراضية

تمتلك المؤسسات الكبيرة (خاصة البنوك) حديقة حيوانات للتطبيقات القديمة التي يتم نشرها على خوادم مختلفة باستخدام مجموعة متنوعة من تقنيات المحاكاة الافتراضية. تعد السحابة الخاصة تقنية واعدة ، ولكن في الواقع ، ستستخدم المؤسسات الكبيرة لفترة طويلة منصات افتراضية متنوعة لنشر مجموعة متنوعة من التطبيقات.

مع تطور منصات المحاكاة الافتراضية ، يأتي وقت لا يستطيع فيه أحد في الشركة فهم مدى كفاءة استخدام الموارد. حتى أدوات المراقبة الأكثر تقدمًا لا تقدم إجابة على هذا السؤال بسبب سيناريوهات استخدام الخادم المختلفة. على سبيل المثال ، قد يكون لدى القسم خادم تقارير سيتم تحميله بالكامل لفترة محدودة فقط من الوقت. قل 3-4 ساعات في نهاية الشهر. في سيناريوهات الحياة الواقعية ، لا يقوم أحد بتخصيص موارد ديناميكية لمثل هذه الخوادم - وهذا أمر صعب من الناحية الفنية والتنظيمية. يتم تخصيص الموارد للحد الأقصى لتحميل الخادم الدوري ، على الرغم من أنها تحدث بشكل غير متكرر.

وخلاصة القول ، في المنظمات الكبيرة ، تنفق موارد المزرعة الافتراضية بشكل غير فعال للغاية.

أدناه أقترح منهجية يمكنك من خلالها تبرير الزيادة والنقصان في الموارد المخصصة للخادم الظاهري ، بغض النظر عن السيناريو.

منهجية

لتقييم حمل الموارد ، من الضروري جمع إحصائيات العدادات المختلفة ؛ لتقييم حمل الموارد ، سيتم استخدام مقاييس مختلفة. بشكل تقليدي ، يمكن تقسيم العدادات إلى نوعين (وفقًا لمعدل التغيير): "سريع" و "بطيء". من الأمثلة الجيدة على العداد "السريع" عداد تحميل المعالج (٪ CPU). مثال على العداد البطيء هو النسبة المئوية لمساحة القرص الثابت الخالية (٪ FreeSpace).
يتكون تقييم العدادات البطيئة من حساب القيمة القصوى (الحد الأدنى أو الأقصى) للمقياس للفترة. يسمح هذا النهج (على سبيل المثال ، عند تقييم المساحة الخالية على القرص) بتقدير الموارد المجانية ، وإذا لزم الأمر ، تخصيص أحجام إضافية أو تقليل الأحجام الحالية.

للعدادات السريعة ، يتم استخدام نهج مختلف. عيوب استخدام المقاييس المتكاملة البسيطة (المتوسط ، الحد الأقصى ، الحد الأدنى والمتوسط) لتقييم ديناميكيات هذه العدادات موصوفة جيدًا هنا . تشمل العيوب الشائعة نقص المعلومات حول زيادة الأحمال (المتوسطة والذروة). إذا أخذنا القيمة القصوى للفترة كمقياس متكامل ، فإن وجود القيم المتطرفة (على سبيل المثال ، التحميل الفوري لوحدة المعالجة المركزية حتى 100٪ عند بدء البرنامج) لن يعطي معلومات موضوعية.

في المقاليقترح استخدام الكمية 0.9 لتقدير المقياس السريع (هذه قيمة تشير إلى المستوى الذي تكمن دونه القيمة المرصودة في 90٪ من العينات). مع وجود حمل خادم موحد وفقًا لهذا المقياس ، يمكننا تقدير متوسط حمل المعالج بشكل مناسب. لكن هذا النهج له نفس العيوب - نقص المعلومات حول زيادة الأحمال (متوسطة وذروة).

أدناه ، كمثال ، الرسم البياني الأسبوعي واليومي لعداد وحدة المعالجة المركزية٪. كانت قيمة العداد القصوى على الرسوم البيانية 100٪.

يوضح الرسم البياني أنه في الفترة المشار إليها هناك زيادة في الحمل ، والتي تستمر حوالي 3 ساعات. لهذا العداد ، تم حساب مجموعة متنوعة من المقاييس للأسبوع. يوضح الشكل 2 أن الوسيط (الخط الأخضر ، قيمة 5٪) ، المتوسط (أصفر ، قيمة 12٪) و 0.9 كمي (أحمر ، 27٪ قيمة) يقوم بتصفية تغيير الحمل ويتم فقدان المعلومات المتعلقة به.

كتطور لفكرة الكميات ، أود أن أقترح فكرة الكميات المنزلقة. هذا هو نظير المتوسط المتحرك.لكن الكمية 0.9 تستخدم كوظيفة نافذة. علاوة على ذلك ، سوف نستخدم كميتين منزلقتين لتقدير مستوى العداد السريع بفترة قصيرة (ساعة واحدة) وبطيئة مع فترة طويلة (24 ساعة). يعمل الكم السريع على تصفية الانبعاثات الآنية وتوفير معلومات الحمل القصوى. سيسمح لك الكم البطيء بتقدير متوسط الحمل.

كما ترون من الرسوم البيانية ، فإن الكميات المتحركة 0.9 هي خصائص ديناميكية (بني - سريع ، أرجواني - بطيء). من أجل البساطة ، تقييم حالة العداد كمقاييس يُقترح استخدامها:

الحد الأقصى للقيمة الكمية بساعة واحدة ، مما يوضح أقصى حمل مستمر للخادم لهذه الفترة ،
متوسط القيمة الكمية بفترة 24 ساعة ، مما يوضح متوسط حمل الخادم لهذه الفترة.

على الرسم البياني ، القيمة القصوى للكمية السريعة هي الخط الأسود عند 85٪ ، ومتوسط القيمة للكمية البطيئة هو الخط الوردي عند 30٪.

وبالتالي ، عند تحليل حمل موارد الخادم (وفقًا لعداد وحدة المعالجة المركزية٪) ، إذا أخذنا المتوسط للشهر (12٪) كمقياس ، يمكننا اتخاذ قرار خاطئ لتقليل الموارد المخصصة. يظهر المقياس الكمي المزدوج سريع / بطيء الحركة (85 و 30٪) أن هناك موارد مخصصة كافية ، ولكن لا توجد فوائض.

القرار

لقد تحلل تنفيذ تقييم كفاءة استخدام الموارد إلى 3 مهام:

جمع البيانات
تطوير منهجية التقييم
تنفيذ المنهجية في العمارة الحالية

أعلاه ، لقد درست المهمة 2 من هذا التنفيذ ، أدناه سنتحدث قليلاً عن المهمة الثالثة.

تم جمع البيانات في قاعدة بيانات ClickHouse. يعتبر هذا العمود DBMS مثاليًا لتخزين بيانات السلاسل الزمنية. تمت مناقشة هذا بالتفصيل في ClickHouse Meetup في 5 سبتمبر 2019. يمكن العثور على مقارنة لـ ClickHouse مع DBMS لسلسلة زمنية أخرى هنا .
نتيجة لجمع البيانات ، قمنا بتشكيل عدة جداول تم فيها تنظيم البيانات سطرا بسطر (تم كتابة قيم كل عداد في سطر منفصل). وبالطبع ، كانت هناك مشاكل في البيانات الأولية.

المشكلة الأولى هي عدم انتظام الفترات الفاصلة بين إدخالات العداد. على سبيل المثال ، إذا كانت فترة تسجيل العداد القياسي 5 دقائق ، في بعض الأحيان كانت هناك فجوات وكان السجل التالي أكثر من 5 دقائق (حتى 20 دقيقة) من السجل السابق.

المشكلة الثانية هي أنه في بعض الأحيان تأتي بيانات العداد مرتين أو أكثر (بقيم مختلفة) بنفس الطابع الزمني.

والمشكلة الثالثة - ClickHouse ليس لديه وظائف النافذة.

لحل المشكلة الأولى ، يمكنك استخدام ASOF JOIN. الفكرة بسيطة للغاية - لكل عداد لكل خادم إنشاء جدول بالتساوي مع فترات زمنية مملوءة بالتساوي. يسمح استخدام ASOF JOIN بملء القيم في الجدول الجديد بأقرب القيم من جدول البيانات الخام (يمكن تهيئة خيارات التعبئة المشابهة لـ ffill و bfill).

حل المشكلة الثانية هو التجميع مع اختيار القيمة القصوى في وقت معين.

لحل المشكلة الثالثة ، تم النظر في عدة حلول. أولاً ، تم رفض نص Python بسبب الأداء غير الكافي. يبدو أن الحل الثاني - نسخ البيانات الأولية إلى قاعدة بيانات MSSQL ، وحساب المقاييس ، والنسخ مرة أخرى - معقد للغاية بحيث يتعذر تنفيذه. يحتوي MSSQL أيضًا على وظائف النافذة ، ولكن لا توجد وظيفة مجمعة مطلوبة. قد يشعر المرء بالحيرة ويكتب دالة SQL CLR الخاصة بك. ولكن تم رفض هذا الخيار بسبب التعقيد المفرط.

يمكن أن يكون حل العمل هو برنامج نصي لـ ClickHouse. يتم إعطاء مثال على هذا البرنامج النصي أدناه. من أجل البساطة ، نظرت إلى حساب الكمية السريعة فقط لعداد واحد لخوادم متعددة. لا يبدو الحل بسيطًا جدًا وغير ملائم للغاية ، ولكنه يعمل.

نتيجة لذلك ، تم إنشاء تقرير اختبار في PowerBI لإثبات المنهجية.

استنتاج

في الختام ، أود التكهن بتطور الحل. إذا نظرت إلى الحل من وجهة نظر مستودعات البيانات ، يمكنك أن ترى أنه بهذه الطريقة يتم حل مهمة إنشاء مستودع البيانات (مستودع البيانات) من طبقة من البيانات الخام (منطقة التدريج). يمكنك مناقشة البنية ، ولكن بالنسبة إلى ClickHouse كقاعدة بيانات عمود ، فإن التطبيع ليس بالغ الأهمية (أو ربما ضارًا).

يُرى المزيد من تطوير المستودع في إنشاء جداول مجمعة (يوم / أسبوع / شهر) بأعمار مختلفة (TTL). سيؤدي ذلك إلى تجنب التورم المفرط للتخزين.
قد تكون الخطوة التالية هي استخدام البيانات للتحليلات التنبؤية.

ملاحظة:

يتم نشر رمز وبيانات الاختبار هنا .

تقييم مقاييس حمل الخادم المتكاملة

بضع كلمات حول ميزات استخدام الخوادم الافتراضية

منهجية

القرار

استنتاج

More articles: