اوپن اسٹیک میں لوڈ بیلنسنگ

بڑے کلاؤڈ سسٹمز میں، کمپیوٹنگ وسائل پر خودکار توازن یا بوجھ کو برابر کرنے کا مسئلہ خاص طور پر شدید ہے۔ Tionix (کلاؤڈ سروسز کا ایک ڈویلپر اور آپریٹر، Rostelecom گروپ آف کمپنیوں کا حصہ) نے بھی اس مسئلے کا خیال رکھا ہے۔

اور، چونکہ ہمارا بنیادی ترقیاتی پلیٹ فارم اوپن اسٹیک ہے، اور ہم، تمام لوگوں کی طرح، سست ہیں، اس لیے یہ فیصلہ کیا گیا کہ کچھ ریڈی میڈ ماڈیول منتخب کریں جو پہلے سے پلیٹ فارم میں شامل ہیں۔ ہمارا انتخاب واچر پر پڑا، جسے ہم نے اپنی ضروریات کے لیے استعمال کرنے کا فیصلہ کیا۔

سب سے پہلے، آئیے اصطلاحات اور تعریفوں کو دیکھیں۔

شرائط اور تعریفیں

گول ایک انسانی پڑھنے کے قابل، قابل مشاہدہ اور قابل پیمائش نتیجہ ہے جسے حاصل کرنا ضروری ہے۔ ہر مقصد کو حاصل کرنے کے لیے ایک یا زیادہ حکمت عملی ہوتی ہے۔ حکمت عملی ایک الگورتھم کا نفاذ ہے جو کسی مقررہ مقصد کے لیے حل تلاش کرنے کے قابل ہو۔

عمل ایک ابتدائی کام ہے جو OpenStack کلسٹر کے ہدف کے زیر انتظام وسائل کی موجودہ حالت کو تبدیل کرتا ہے، جیسے: ورچوئل مشین کو منتقل کرنا (مائیگریشن)، نوڈ کی پاور اسٹیٹ کو تبدیل کرنا (change_node_power_state)، نووا سروس کی حالت کو تبدیل کرنا (change_nova_service_state) )، ذائقہ تبدیل کرنا (سائز تبدیل کرنا)، NOP پیغامات کا اندراج (nop)، ایک خاص وقت کے لیے کارروائی کی کمی - روکنا (نیند)، ڈسک کی منتقلی (volume_migrate)۔

عملی منصوبہ - کسی خاص مقصد کو حاصل کرنے کے لیے ایک خاص ترتیب میں کیے جانے والے اعمال کا ایک مخصوص بہاؤ۔ ایکشن پلان میں کارکردگی کے اشاریوں کے ایک سیٹ کے ساتھ عالمی کارکردگی کی پیمائش بھی ہوتی ہے۔ ایک کامیاب آڈٹ کے بعد واچر کی طرف سے ایک ایکشن پلان تیار کیا جاتا ہے، جس کے نتیجے میں استعمال کی گئی حکمت عملی مقصد کو حاصل کرنے کے لیے حل تلاش کرتی ہے۔ ایک ایکشن پلان ترتیب وار کارروائیوں کی فہرست پر مشتمل ہوتا ہے۔

آڈٹ کلسٹر کو بہتر بنانے کی درخواست ہے۔ دیے گئے کلسٹر میں ایک مقصد حاصل کرنے کے لیے اصلاح کی جاتی ہے۔ ہر کامیاب آڈٹ کے لیے، واچر ایک ایکشن پلان تیار کرتا ہے۔

آڈٹ دائرہ کار وسائل کا ایک مجموعہ ہے جس کے اندر آڈٹ کیا جاتا ہے (دستیابی کے علاقے)، نوڈ ایگریگیٹرز، انفرادی کمپیوٹ نوڈس یا اسٹوریج نوڈس وغیرہ)۔ آڈٹ کا دائرہ ہر ٹیمپلیٹ میں بیان کیا گیا ہے۔ اگر آڈٹ کے دائرہ کار کی وضاحت نہیں کی گئی ہے، تو پورے کلسٹر کا آڈٹ کیا جاتا ہے۔

آڈٹ ٹیمپلیٹ - آڈٹ شروع کرنے کے لیے سیٹنگز کا ایک محفوظ کردہ سیٹ۔ ایک ہی ترتیبات کے ساتھ متعدد بار آڈٹ چلانے کے لیے ٹیمپلیٹس کی ضرورت ہوتی ہے۔ ٹیمپلیٹ میں لازمی طور پر آڈٹ کا مقصد ہونا ضروری ہے؛ اگر حکمت عملیوں کی وضاحت نہیں کی گئی ہے، تو سب سے موزوں موجودہ حکمت عملیوں کا انتخاب کیا جاتا ہے۔

جھرمٹ فزیکل مشینوں کا ایک مجموعہ ہے جو کمپیوٹ، سٹوریج اور نیٹ ورکنگ کے وسائل مہیا کرتی ہے اور اسی OpenStack مینجمنٹ نوڈ کے ذریعے ان کا نظم کیا جاتا ہے۔

کلسٹر ڈیٹا ماڈل (CDM) کلسٹر کے زیر انتظام وسائل کی موجودہ حالت اور ٹوپولوجی کی منطقی نمائندگی ہے۔

کارکردگی کا اشارہ - ایک اشارے جو اس بات کی نشاندہی کرتا ہے کہ اس حکمت عملی کا استعمال کرتے ہوئے تخلیق کردہ حل کیسے انجام دیا جاتا ہے۔ کارکردگی کے اشارے کسی خاص مقصد کے لیے مخصوص ہوتے ہیں اور عام طور پر نتیجے میں ہونے والے ایکشن پلان کی عالمی تاثیر کا حساب لگانے کے لیے استعمال ہوتے ہیں۔

افادیت کی تفصیلات ہر ایک گول سے وابستہ مخصوص خصوصیات کا ایک مجموعہ ہے جو کارکردگی کے مختلف اشاریوں کی وضاحت کرتا ہے جو متعلقہ گول کو حاصل کرنے کی حکمت عملی کو اس کے حل میں حاصل کرنا ضروری ہے۔ درحقیقت، حکمت عملی کے ذریعہ تجویز کردہ ہر حل کو اس کی عالمی تاثیر کا حساب لگانے سے پہلے تفصیلات کے خلاف جانچا جائے گا۔

اسکورنگ انجن ایک قابل عمل فائل ہے جس میں اچھی طرح سے بیان کردہ ان پٹ، اچھی طرح سے وضاحت شدہ آؤٹ پٹس ہیں، اور یہ خالصتاً ریاضیاتی کام انجام دیتا ہے۔ اس طرح، حساب کتاب اس ماحول سے آزاد ہے جس میں اسے انجام دیا جاتا ہے- یہ کہیں بھی وہی نتیجہ دے گا۔

نگران منصوبہ ساز - واچر فیصلہ سازی کے انجن کا حصہ۔ یہ ماڈیول ایک حکمت عملی کے ذریعے پیدا ہونے والی کارروائیوں کا ایک سیٹ لیتا ہے اور ایک ورک فلو پلان بناتا ہے جو بتاتا ہے کہ ان مختلف کارروائیوں کو وقت پر کیسے شیڈول کیا جائے اور ہر ایکشن کے لیے، پیشگی شرائط کیا ہیں۔

نگہبان اہداف اور حکمت عملی

گول
ترکیب، حکمت عملی

ڈمی گول
ڈمی حکمت عملی 

نمونہ اسکورنگ انجنوں کا استعمال کرتے ہوئے ڈمی حکمت عملی

سائز تبدیل کرنے کے ساتھ ڈمی حکمت عملی

توانائی کی بچت
توانائی کی بچت کی حکمت عملی

سرور کنسولیڈیشن
بنیادی آف لائن سرور کنسولیڈیشن

VM کام کے بوجھ کے استحکام کی حکمت عملی

کام کے بوجھ میں توازن
ورک لوڈ بیلنس ہجرت کی حکمت عملی

ذخیرہ کرنے کی صلاحیت کے توازن کی حکمت عملی

کام کا بوجھ استحکام

شور مچانے والا پڑوسی
شور مچانے والا پڑوسی

تھرمل آپٹیمائزیشن
آؤٹ لیٹ درجہ حرارت پر مبنی حکمت عملی

ایئر فلو کی اصلاح
یکساں ہوا کے بہاؤ کی منتقلی کی حکمت عملی

ہارڈ ویئر کی دیکھ بھال۔
زون کی منتقلی

غیر مرتب شدہ
اداکار

ڈمی گول - مخصوص ہدف جو جانچ کے مقاصد کے لیے استعمال ہوتا ہے۔

متعلقہ حکمت عملی: ڈمی حکمت عملی، نمونہ سکورنگ انجنوں کا استعمال کرتے ہوئے ڈمی حکمت عملی اور سائز تبدیل کرنے کے ساتھ ڈمی حکمت عملی۔ ڈمی حکمت عملی ایک ڈمی حکمت عملی ہے جو ٹیمپیسٹ کے ذریعے انضمام کی جانچ کے لیے استعمال ہوتی ہے۔ یہ حکمت عملی کوئی مفید اصلاح فراہم نہیں کرتی، اس کا واحد مقصد Tempest ٹیسٹوں کا استعمال کرنا ہے۔

نمونہ اسکورنگ انجنوں کا استعمال کرتے ہوئے ڈمی حکمت عملی - یہ حکمت عملی پچھلی حکمت عملی سے ملتی جلتی ہے، فرق صرف ایک نمونہ "اسکورنگ انجن" کا استعمال ہے جو مشین لرننگ کے طریقوں سے حساب کتاب کرتا ہے۔

نیا سائز کے ساتھ ڈمی حکمت عملی - حکمت عملی پچھلے ایک سے ملتی جلتی ہے، فرق صرف ذائقہ (ہجرت اور سائز تبدیل کرنے) کو تبدیل کرنے کا ہے۔

پیداوار میں استعمال نہیں کیا جاتا ہے۔

توانائی کی بچت - توانائی کی کھپت کو کم سے کم کریں۔ اس مقصد کی بچت توانائی کی حکمت عملی، VM ورک لوڈ کنسولیڈیشن حکمت عملی (سرور کنسولیڈیشن) کے ساتھ، متحرک پاور مینجمنٹ (DPM) خصوصیات کے قابل ہے جو کم وسائل کے استعمال کے دوران بھی کام کے بوجھ کو متحرک کرکے توانائی کی بچت کرتی ہے: ورچوئل مشینیں کم نوڈس پر منتقل ہوتی ہیں۔ ، اور غیر ضروری نوڈس غیر فعال ہیں۔ استحکام کے بعد، حکمت عملی مخصوص پیرامیٹرز کے مطابق نوڈس کو آن/آف کرنے کا فیصلہ پیش کرتی ہے: "min_free_hosts_num" - مفت فعال نوڈس کی تعداد جو لوڈ کا انتظار کر رہے ہیں، اور "free_used_percent" - مفت فعال میزبانوں کا فیصد نوڈس کی تعداد جن پر مشینوں کا قبضہ ہے۔ حکمت عملی کام کرنے کے لئے وہاں ہونا ضروری ہے نوڈس پر پاور سائیکلنگ کو ہینڈل کرنے کے لیے Ironic کو فعال اور کنفیگر کیا گیا۔

حکمت عملی کے پیرامیٹرز

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

مفت_استعمال شدہ_فیصد
نمبر
10.0
مفت کمپیوٹنگ نوڈس کی تعداد اور ورچوئل مشینوں کے ساتھ کمپیوٹنگ نوڈس کی تعداد کا تناسب

min_free_hosts_num
Int
1
مفت کمپیوٹنگ نوڈس کی کم از کم تعداد

بادل میں کم از کم دو نوڈس ہونے چاہئیں۔ استعمال شدہ طریقہ نوڈ کی طاقت کی حالت کو تبدیل کر رہا ہے (change_node_power_state)۔ حکمت عملی کو میٹرکس جمع کرنے کی ضرورت نہیں ہے۔

سرور کنسولیڈیشن - کمپیوٹنگ نوڈس کی تعداد کو کم سے کم کریں۔ اس کی دو حکمت عملییں ہیں: بنیادی آف لائن سرور کنسولیڈیشن اور VM ورک لوڈ کنسولیڈیشن اسٹریٹیجی۔

بنیادی آف لائن سرور کنسولیڈیشن کی حکمت عملی استعمال کیے گئے سرورز کی کل تعداد کو کم کرتی ہے اور نقل مکانی کی تعداد کو بھی کم کرتی ہے۔

بنیادی حکمت عملی کے لیے درج ذیل میٹرکس کی ضرورت ہوتی ہے:

میٹرکس
سروس
پلگ ان
تبصرہ

compute.node.cpu.percent
سیلومیٹر
کوئی نہیں
 

cpu_util
سیلومیٹر
کوئی نہیں
 

حکمت عملی کے پیرامیٹرز: migration_attempts - شٹ ڈاؤن کے لیے ممکنہ امیدواروں کو تلاش کرنے کے لیے امتزاج کی تعداد (پہلے سے طے شدہ، 0، کوئی پابندی نہیں)، مدت - میٹرک ڈیٹا سورس (پہلے سے طے شدہ، 700) سے جامد جمع حاصل کرنے کے لیے سیکنڈ میں وقت کا وقفہ۔

استعمال شدہ طریقے: ہجرت، نووا سروس کی حالت کو تبدیل کرنا (change_nova_service_state)۔

VM ورک لوڈ کنسولیڈیشن سٹریٹیجی ایک فرسٹ فٹ ہوورسٹک پر مبنی ہے جو ماپا CPU بوجھ پر توجہ مرکوز کرتی ہے اور ایسے نوڈس کو کم سے کم کرنے کی کوشش کرتی ہے جن میں وسائل کی گنجائش کی رکاوٹوں کے باعث بہت زیادہ یا بہت کم بوجھ ہوتا ہے۔ یہ حکمت عملی ایک ایسا حل فراہم کرتی ہے جس کے نتیجے میں درج ذیل چار مراحل کا استعمال کرتے ہوئے کلسٹر وسائل کا زیادہ موثر استعمال ہوتا ہے۔

1. اتارنے کا مرحلہ - زیادہ استعمال شدہ وسائل کی پروسیسنگ؛
2. استحکام کا مرحلہ - کم استعمال شدہ وسائل کو سنبھالنا؛
3. حل کی اصلاح - نقل مکانی کی تعداد کو کم کرنا؛
4. غیر استعمال شدہ کمپیوٹ نوڈس کو غیر فعال کرنا۔

حکمت عملی کو درج ذیل میٹرکس کی ضرورت ہے:

میٹرکس
سروس
پلگ ان
تبصرہ

میموری
سیلومیٹر
کوئی نہیں
 

disk.root.size
سیلومیٹر
کوئی نہیں
 

درج ذیل میٹرکس اختیاری ہیں لیکن اگر دستیاب ہوں تو حکمت عملی کی درستگی کو بہتر بنائیں گے۔

میٹرکس
سروس
پلگ ان
تبصرہ

میموری. رہائشی
سیلومیٹر
کوئی نہیں
 

cpu_util
سیلومیٹر
کوئی نہیں
 

حکمت عملی کے پیرامیٹرز: مدت — میٹرک ڈیٹا سورس (ڈیفالٹ، 3600) سے جامد جمع حاصل کرنے کے لیے سیکنڈ میں وقت کا وقفہ۔

پچھلی حکمت عملی کے طور پر وہی طریقے استعمال کرتا ہے۔ مزید تفصیلات یہاں.

کام کے بوجھ میں توازن - کمپیوٹنگ نوڈس کے درمیان کام کے بوجھ کو متوازن رکھیں۔ مقصد کی تین حکمت عملییں ہیں: ورک لوڈ بیلنس مائیگریشن اسٹریٹجی، ورک لوڈ اسٹیبلائزیشن، سٹوریج کیپیسٹی بیلنس اسٹریٹجی۔

ورک لوڈ بیلنس ہجرت کی حکمت عملی میزبان ورچوئل مشین کے کام کے بوجھ کی بنیاد پر ورچوئل مشین کی منتقلی کو چلاتی ہے۔ منتقلی کا فیصلہ اس وقت کیا جاتا ہے جب کسی نوڈ کے % CPU یا RAM کا استعمال مخصوص حد سے تجاوز کر جائے۔ اس صورت میں، منتقل شدہ ورچوئل مشین کو نوڈ کو تمام نوڈس کے اوسط کام کے بوجھ کے قریب لانا چاہیے۔

کے تقاضے

• جسمانی پروسیسرز کا استعمال؛
• کم از کم دو فزیکل کمپیوٹنگ نوڈس؛
• Ceilometer جزو - ceilometer-agent-compute کو انسٹال اور کنفیگر کیا، ہر کمپیوٹ نوڈ پر چل رہا ہے، اور Ceilometer API، نیز درج ذیل میٹرکس کو جمع کرنا:

میٹرکس
سروس
پلگ ان
تبصرہ

cpu_util
سیلومیٹر
کوئی نہیں
 

میموری. رہائشی
سیلومیٹر
کوئی نہیں
 

حکمت عملی کے پیرامیٹرز:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

میٹرکس
سلک
'cpu_util'
بنیادی میٹرکس ہیں: 'cpu_util', 'memory.resident'۔

حد
نمبر
25.0
نقل مکانی کے لیے کام کے بوجھ کی حد۔

مدت
نمبر
300
مجموعی وقت کی مدت سیلومیٹر۔

استعمال شدہ طریقہ نقل مکانی ہے۔

ورک لوڈ اسٹیبلائزیشن ایک حکمت عملی ہے جس کا مقصد لائیو ہجرت کے ذریعے کام کے بوجھ کو مستحکم کرنا ہے۔ حکمت عملی معیاری انحراف الگورتھم پر مبنی ہے اور یہ تعین کرتی ہے کہ آیا کلسٹر میں بھیڑ ہے اور کلسٹر کو مستحکم کرنے کے لیے مشین کی منتقلی کو متحرک کرکے اس کا جواب دیتی ہے۔

کے تقاضے

• جسمانی پروسیسرز کا استعمال؛
• کم از کم دو فزیکل کمپیوٹنگ نوڈس؛
• Ceilometer جزو - ceilometer-agent-compute کو انسٹال اور کنفیگر کیا، ہر کمپیوٹ نوڈ پر چل رہا ہے، اور Ceilometer API، نیز درج ذیل میٹرکس کو جمع کرنا:

میٹرکس
سروس
پلگ ان
تبصرہ

cpu_util
سیلومیٹر
کوئی نہیں
 

میموری. رہائشی
سیلومیٹر
کوئی نہیں
 

ذخیرہ کرنے کی صلاحیت کے توازن کی حکمت عملی (کوئینز سے شروع ہونے والی حکمت عملی) - حکمت عملی سنڈر پولز پر بوجھ کے لحاظ سے ڈسکوں کو منتقل کرتی ہے۔ جب بھی پول کے استعمال کی شرح ایک مخصوص حد سے تجاوز کر جائے تو منتقلی کا فیصلہ کیا جاتا ہے۔ منتقل ہونے والی ڈسک کو پول کو تمام سنڈر پولز کے اوسط بوجھ کے قریب لانا چاہیے۔

تقاضے اور پابندیاں

• کم از کم دو سنڈر پول؛
• ڈسک کی منتقلی کا امکان۔
• کلسٹر ڈیٹا ماڈل - سنڈر کلسٹر ڈیٹا ماڈل کلیکٹر۔

حکمت عملی کے پیرامیٹرز:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

حجم_حد
نمبر
80.0
حجم کو متوازن کرنے کے لیے ڈسک کی حد کی قیمت۔

استعمال شدہ طریقہ ڈسک کی منتقلی (volume_migrate) ہے۔

شور والا پڑوسی - ایک "شور پڑوسی" کی شناخت اور منتقلی کریں - ایک کم ترجیح والی ورچوئل مشین جو آخری درجے کی کیش کو زیادہ استعمال کرکے IPC کے لحاظ سے ایک اعلی ترجیحی ورچوئل مشین کی کارکردگی پر منفی اثر ڈال رہی ہے۔ اپنی حکمت عملی: شور والا پڑوسی (استعمال شدہ حکمت عملی کا پیرامیٹر cache_threshold ہے (پہلے سے طے شدہ قدر 35 ہے)، جب کارکردگی متعین قدر تک گر جاتی ہے، منتقلی شروع ہو جاتی ہے۔ حکمت عملی کے کام کرنے کے لیے، فعال ایل ایل سی (آخری سطح کی کیش) میٹرکس، CMT سپورٹ کے ساتھ تازہ ترین انٹیل سرور، نیز درج ذیل میٹرکس کو جمع کرنا:

میٹرکس
سروس
پلگ ان
تبصرہ

cpu_l3_cache
سیلومیٹر
کوئی نہیں
انٹیل کی ضرورت ہے۔ CMT.

کلسٹر ڈیٹا ماڈل (ڈیفالٹ): نووا کلسٹر ڈیٹا ماڈل کلیکٹر۔ استعمال شدہ طریقہ نقل مکانی ہے۔

ڈیش بورڈ کے ذریعے اس مقصد کے ساتھ کام کرنا کوئنز میں مکمل طور پر نافذ نہیں ہے۔

تھرمل آپٹیمائزیشن - درجہ حرارت کے نظام کو بہتر بنائیں۔ آؤٹ لیٹ (ایگزاسٹ ایئر) کا درجہ حرارت سرور کے تھرمل/کام کے بوجھ کی حیثیت کی پیمائش کرنے کے لیے ایک اہم تھرمل ٹیلی میٹری سسٹم ہے۔ ہدف کے پاس ایک حکمت عملی ہے، آؤٹ لیٹ درجہ حرارت پر مبنی حکمت عملی، جو کام کے بوجھ کو تھرمل طور پر سازگار میزبانوں (سب سے کم آؤٹ لیٹ درجہ حرارت) پر منتقل کرنے کا فیصلہ کرتی ہے جب سورس ہوسٹس کا آؤٹ لیٹ درجہ حرارت قابل ترتیب حد تک پہنچ جاتا ہے۔

حکمت عملی کے کام کرنے کے لیے، آپ کو انٹیل پاور نوڈ مینیجر انسٹال اور کنفیگرڈ سرور کی ضرورت ہے۔ 3.0 یا بعد میں، نیز درج ذیل میٹرکس کو جمع کرنا:

میٹرکس
سروس
پلگ ان
تبصرہ

hardware.ipmi.node.outlet_temperature
سیلومیٹر
آئی پی ایم آئی
 

حکمت عملی کے پیرامیٹرز:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

حد
نمبر
35.0
منتقلی کے لیے درجہ حرارت کی حد۔

مدت
نمبر
30
وقت کا وقفہ، سیکنڈوں میں، میٹرک ڈیٹا ماخذ سے شماریاتی جمع حاصل کرنے کے لیے۔

استعمال شدہ طریقہ نقل مکانی ہے۔

ایئر فلو کی اصلاح - وینٹیلیشن موڈ کو بہتر بنائیں۔ اپنی حکمت عملی - براہ راست منتقلی کا استعمال کرتے ہوئے یکساں ہوا کا بہاؤ۔ جب بھی سرور کے پرستار سے ہوا کا بہاؤ ایک مخصوص حد سے تجاوز کر جاتا ہے تو حکمت عملی ورچوئل مشین کی منتقلی کو متحرک کرتی ہے۔

کام کرنے کی حکمت عملی کے لیے آپ کو ضرورت ہے:

• ہارڈ ویئر: کمپیوٹ نوڈس < سپورٹنگ نوڈ مینجر 3.0؛
• کم از کم دو کمپیوٹنگ نوڈس؛
• سیلومیٹر-ایجنٹ-کمپیوٹ اور سیلومیٹر API جزو ہر کمپیوٹنگ نوڈ پر نصب اور ترتیب دیا گیا ہے، جو کامیابی سے میٹرکس کی رپورٹ کر سکتا ہے جیسے ہوا کا بہاؤ، سسٹم پاور، انلیٹ درجہ حرارت:

میٹرکس
سروس
پلگ ان
تبصرہ

hardware.ipmi.node.airflow
سیلومیٹر
آئی پی ایم آئی
 

hardware.ipmi.node.temperature
سیلومیٹر
آئی پی ایم آئی
 

hardware.ipmi.node.power
سیلومیٹر
آئی پی ایم آئی
 

حکمت عملی کے کام کرنے کے لیے، آپ کو Intel Power Node Manager 3.0 یا بعد میں انسٹال اور کنفیگر کردہ سرور کی ضرورت ہے۔

حدود: تصور پیداوار کے لیے نہیں ہے۔

اس الگورتھم کو مسلسل آڈٹ کے ساتھ استعمال کرنے کی تجویز ہے، کیونکہ فی تکرار صرف ایک ورچوئل مشین کو منتقل کرنے کا منصوبہ ہے۔

لائیو ہجرت ممکن ہے۔

حکمت عملی کے پیرامیٹرز:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

threshold_airflow
نمبر
400.0
منتقلی یونٹ کے لیے ہوا کے بہاؤ کی حد 0.1CFM ہے۔

threshold_inlet_t
نمبر
28.0
منتقلی کے فیصلے کے لیے داخلی درجہ حرارت کی حد

threshold_power
نمبر
350.0
منتقلی کے فیصلے کے لیے سسٹم پاور کی حد

مدت
نمبر
30
وقت کا وقفہ، سیکنڈوں میں، میٹرک ڈیٹا ماخذ سے شماریاتی جمع حاصل کرنے کے لیے۔

استعمال شدہ طریقہ نقل مکانی ہے۔

ہارڈ ویئر کی بحالی - ہارڈ ویئر کی دیکھ بھال۔ اس مقصد سے متعلق حکمت عملی زون کی منتقلی ہے۔ حکمت عملی ہارڈ ویئر کی دیکھ بھال کی ضرورت کی صورت میں ورچوئل مشینوں اور ڈسکوں کی موثر خودکار اور کم سے کم منتقلی کے لیے ایک ٹول ہے۔ حکمت عملی وزن کے مطابق عمل کا منصوبہ بناتی ہے: اعمال کا ایک مجموعہ جس کا وزن زیادہ ہوتا ہے دوسروں سے پہلے منصوبہ بندی کی جائے گی۔ ترتیب کے دو اختیارات ہیں: ایکشن_ویٹ اور متوازی۔

حدود: کارروائی کے وزن اور ہم آہنگی کو ترتیب دینے کی ضرورت ہے۔

حکمت عملی کے پیرامیٹرز:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

compute_nodes
صف
کوئی بھی نہیں
نقل مکانی کے لیے نوڈس کی گنتی کریں۔

اسٹوریج_پولز
صف
کوئی بھی نہیں
ہجرت کے لیے سٹوریج نوڈس۔

متوازی_کل
عددی
6
سرگرمیوں کی کل تعداد جو متوازی طور پر انجام دی جانی چاہئیں۔

parallel_per_node
عددی
2
ہر کمپیوٹ نوڈ کے لیے متوازی طور پر انجام دی گئی کارروائیوں کی تعداد۔

parallel_per_pool
عددی
2
ہر سٹوریج پول کے لیے متوازی طور پر کی جانے والی کارروائیوں کی تعداد۔

ترجیح
اعتراض
کوئی بھی نہیں
ورچوئل مشینوں اور ڈسکوں کے لیے ترجیحی فہرست۔

کے ساتھ_منسلک_ والیوم
بولین
جھوٹی
False — ورچوئل مشینیں تمام ڈسکوں کے منتقل ہونے کے بعد منتقل ہو جائیں گی۔ درست — تمام منسلک ڈسکوں کے منتقل ہونے کے بعد ورچوئل مشینیں منتقل ہو جائیں گی۔

کمپیوٹنگ نوڈس کی صف کے عناصر:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

src_node
سٹرنگ
کوئی بھی نہیں
کمپیوٹ نوڈ جس سے ورچوئل مشینیں منتقل کی جا رہی ہیں (ضروری)۔

dst_node
سٹرنگ
کوئی بھی نہیں
اس نوڈ کا حساب لگائیں جس میں ورچوئل مشینیں منتقل ہو رہی ہیں۔

ذخیرہ نوڈ سرنی عناصر:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

src_pool
سٹرنگ
کوئی بھی نہیں
سٹوریج پول جہاں سے ڈسکیں منتقل کی جا رہی ہیں (ضروری)

dst_pool
سٹرنگ
کوئی بھی نہیں
اسٹوریج پول جس میں ڈسکیں منتقل ہوتی ہیں۔

src_type
سٹرنگ
کوئی بھی نہیں
اصل ڈسک کی قسم (ضرورت ہے)۔

dst_type
سٹرنگ
کوئی بھی نہیں
نتیجے میں ڈسک کی قسم (ضروری)۔

آبجیکٹ ترجیحی عناصر:

پیرامیٹر
قسم۔
پہلے سے طے شدہ
تفصیل

منصوبے
صف
کوئی بھی نہیں
پروجیکٹ کے نام۔

compute_node
صف
کوئی بھی نہیں
نوڈ کے ناموں کی گنتی کریں۔

اسٹوریج_پول
صف
کوئی بھی نہیں
اسٹوریج پول کے نام۔

شمار کرو
enum
کوئی بھی نہیں
ورچوئل مشین کے پیرامیٹرز ["vcpu_num"، "mem_size"، "disk_size"، "created_at"]۔

ذخیرہ
enum
کوئی بھی نہیں
ڈسک کے پیرامیٹرز ["سائز"، "created_at"]۔

استعمال شدہ طریقے ورچوئل مشین کی منتقلی، ڈسک کی منتقلی ہیں۔

غیر مرتب شدہ - ایک معاون مقصد جو حکمت عملی کی ترقی کے عمل کو آسان بنانے کے لیے استعمال کیا جاتا ہے۔ کوئی تصریحات پر مشتمل نہیں ہے اور جب بھی حکمت عملی کسی موجودہ مقصد سے وابستہ نہیں ہے تو استعمال کیا جا سکتا ہے۔ اس مقصد کو ٹرانزیشن پوائنٹ کے طور پر بھی استعمال کیا جا سکتا ہے۔ اس مقصد سے متعلقہ حکمت عملی ایکچوایٹر ہے۔   

ایک نیا مقصد بنانا

واچر فیصلہ انجن اس کا ایک "بیرونی مقصد" پلگ ان انٹرفیس ہے جو ایک بیرونی مقصد کو مربوط کرنا ممکن بناتا ہے جسے حکمت عملی کے ذریعے حاصل کیا جا سکتا ہے۔

نیا ہدف بنانے سے پہلے، آپ کو یہ یقینی بنانا چاہیے کہ کوئی بھی موجودہ اہداف آپ کی ضروریات کو پورا نہیں کرتا۔

ایک نیا پلگ ان بنانا

نیا ہدف بنانے کے لیے، آپ کو: ہدف کی کلاس کو بڑھانا، کلاس کا طریقہ نافذ کرنا چاہیے۔ get_name() نئے ہدف کی منفرد ID واپس کرنے کے لیے جسے آپ بنانا چاہتے ہیں۔ یہ منفرد شناخت کنندہ آپ کے بعد میں اعلان کردہ انٹری پوائنٹ کے نام سے مماثل ہونا چاہیے۔

اگلا آپ کو کلاس کے طریقہ کار کو نافذ کرنے کی ضرورت ہے۔ get_display_name() جس ہدف کو آپ بنانا چاہتے ہیں اس کا ترجمہ شدہ ڈسپلے نام واپس کرنے کے لیے (ترجمہ شدہ اسٹرنگ کو واپس کرنے کے لیے متغیر کا استعمال نہ کریں تاکہ اسے ترجمہ ٹول کے ذریعے خودکار طور پر جمع کیا جا سکے۔)

کلاس کا طریقہ نافذ کریں۔ get_translatable_display_name()اپنے نئے ہدف کا ترجمہ کلید (دراصل انگریزی ڈسپلے نام) واپس کرنے کے لیے۔ واپسی کی قیمت get_display_name() میں ترجمہ شدہ سٹرنگ سے مماثل ہونی چاہیے۔

اس کے طریقہ کار پر عمل کریں۔ حاصل_افادیت_تعریف()اپنے ہدف کے لیے کارکردگی کی تفصیلات واپس کرنے کے لیے۔ get_eficacy_specification() طریقہ واچر کے ذریعہ فراہم کردہ غیر درجہ بند () مثال کو لوٹاتا ہے۔ کارکردگی کی یہ تصریح آپ کے مقصد کو تیار کرنے کے عمل میں مفید ہے کیونکہ یہ خالی تصریح کے مساوی ہے۔

→ مزید یہاں۔

واچر فن تعمیر (مزید تفصیلات) یہاں).

اجزاء

واچر API - ایک ایسا جزو جو واچر کے ذریعہ فراہم کردہ REST API کو نافذ کرتا ہے۔ تعامل کے طریقہ کار: CLI، Horizon پلگ ان، Python SDK۔

واچر ڈی بی - واچر ڈیٹا بیس۔

واچر اپلائر — ایک ایسا جزو جو واچر ڈیسیژن انجن کے جزو کے ذریعے بنائے گئے ایکشن پلان پر عمل درآمد کرتا ہے۔

واچر فیصلہ انجن - آڈٹ کے مقصد کو حاصل کرنے کے لیے ممکنہ اصلاحی کارروائیوں کے ایک سیٹ کی گنتی کے لیے ذمہ دار جزو۔ اگر کوئی حکمت عملی متعین نہیں کی گئی ہے، تو جزو آزادانہ طور پر سب سے مناسب کا انتخاب کرتا ہے۔

واچر میٹرکس پبلیشر - ایک جزو جو کچھ میٹرکس یا واقعات کو اکٹھا اور حساب کرتا ہے اور انہیں CEP اینڈ پوائنٹ پر شائع کرتا ہے۔ جزو کی فعالیت بھی سیلومیٹر پبلشر کے ذریعہ فراہم کی جاسکتی ہے۔

کمپلیکس ایونٹ پروسیسنگ (CEP) انجن - پیچیدہ ایونٹ پروسیسنگ کے لیے انجن۔ کارکردگی کی وجوہات کی بناء پر، متعدد CEP انجن مثالیں بیک وقت چل رہی ہیں، ہر ایک مخصوص قسم کے میٹرک/ایونٹ پر کارروائی کر رہا ہے۔ واچر سسٹم میں، سی ای پی دو طرح کی کارروائیوں کو متحرک کرتا ہے: - ٹائم سیریز ڈیٹا بیس میں متعلقہ واقعات/ میٹرکس کو ریکارڈ کریں۔ - مناسب واقعات واچر فیصلہ انجن کو بھیجیں جب یہ واقعہ موجودہ اصلاحی حکمت عملی کے نتیجے کو متاثر کر سکتا ہے، کیونکہ اوپن اسٹیک کلسٹر ایک جامد نظام نہیں ہے۔

اجزاء AMQP پروٹوکول کا استعمال کرتے ہوئے تعامل کرتے ہیں۔

→ واچر کو ترتیب دینا

واچر کے ساتھ تعامل کی اسکیم

واچر ٹیسٹ کے نتائج

1. آپٹیمائزیشن پر - ایکشن پلانز 500 صفحہ (دونوں خالص کوئنز پر اور ٹیونکس ماڈیولز والے اسٹینڈ پر)، یہ صرف آڈٹ شروع ہونے اور ایکشن پلان تیار ہونے کے بعد ظاہر ہوتا ہے؛ خالی والا عام طور پر کھلتا ہے۔
2. ایکشن کی تفصیلات والے ٹیب پر غلطیاں ہیں، آڈٹ کا مقصد اور حکمت عملی حاصل کرنا ممکن نہیں ہے (دونوں خالص کوئنز پر اور Tionix ماڈیولز کے ساتھ اسٹینڈ پر)۔
3. ڈمی (ٹیسٹ) کے مقصد کے ساتھ آڈٹ بنائے جاتے ہیں اور عام طور پر شروع کیے جاتے ہیں، ایکشن پلان تیار کیے جاتے ہیں۔
4. غیر مرتب شدہ ہدف کے لیے آڈٹ اس لیے نہیں بنائے جاتے کیونکہ ہدف فعال نہیں ہے اور نئی حکمت عملی بناتے وقت اس کا مقصد انٹرمیڈیٹ کنفیگریشن کے لیے ہوتا ہے۔
5. ورک لوڈ بیلنسنگ (اسٹوریج کیپیسٹی بیلنس اسٹریٹجی) کے مقصد کے لیے آڈٹ کامیابی کے ساتھ بنائے جاتے ہیں، لیکن ایکشن پلان تیار نہیں ہوتا ہے۔ اسٹوریج پول کو بہتر بنانے کی ضرورت نہیں ہے۔
6. ورک لوڈ بیلنسنگ گول (ورک لوڈ بیلنس مائیگریشن سٹریٹیجی) کے لیے آڈٹ کامیابی کے ساتھ بنائے جاتے ہیں، لیکن ایکشن پلان تیار نہیں ہوتا ہے۔
7. ورک لوڈ بیلنسنگ (ورک لوڈ سٹیبلائزیشن سٹریٹیجی) کے آڈٹ ناکام ہو جاتے ہیں۔
8. شور مچانے والے پڑوسی ہدف کے لیے آڈٹ کامیابی کے ساتھ بنائے جاتے ہیں، لیکن ایکشن پلان تیار نہیں ہوتا ہے۔
9. ہارڈ ویئر کی دیکھ بھال کے مقصد کے لیے آڈٹ کامیابی کے ساتھ بنائے جاتے ہیں، ایکشن پلان مکمل طور پر تیار نہیں ہوتا ہے (کارکردگی کے اشارے تیار ہوتے ہیں، لیکن اعمال کی فہرست خود تیار نہیں ہوتی ہے)۔
10. کمپیوٹ اور کنٹرول نوڈس پر nova.conf configs میں ترمیم (ڈیفالٹ سیکشن compute_monitors = cpu.virt_driver میں) غلطیوں کو درست نہیں کرتی ہے۔
11. سرور کنسولیڈیشن (بنیادی حکمت عملی) کو نشانہ بنانے والے آڈٹ بھی ناکام ہو جاتے ہیں۔
12. سرور کنسولیڈیشن (VM ورک لوڈ کنسولیڈیشن سٹریٹیجی) کے مقصد کے لیے آڈٹ غلطی کے ساتھ ناکام ہو جاتے ہیں۔ لاگز میں سورس ڈیٹا حاصل کرنے میں ایک خرابی ہے۔ خاص طور پر غلطی کی بحث یہاں.
    ہم نے کنفگ فائل میں واچر کی وضاحت کرنے کی کوشش کی (اس سے کوئی فائدہ نہیں ہوا - تمام اصلاحی صفحات پر غلطی کے نتیجے میں، کنفگ فائل کے اصل مواد پر واپس آنے سے صورتحال درست نہیں ہوتی):
    [watcher_strategies.basic] ڈیٹا سورس = سیلومیٹر، گنوچی
13. توانائی کی بچت کے لیے آڈٹ ناکام ہو گئے۔ نوشتہ جات کے مطابق، مسئلہ اب بھی Ironic کی عدم موجودگی ہے؛ یہ baremetal سروس کے بغیر کام نہیں کرے گا۔
14. تھرمل آپٹیمائزیشن کے لیے آڈٹ ناکام ہو گئے۔ ٹریس بیک وہی ہے جیسا کہ سرور کنسولیڈیشن (VM ورک لوڈ کنسولیڈیشن اسٹریٹجی) (ماخذ ڈیٹا کی خرابی)
15. ایئر فلو آپٹیمائزیشن کے مقصد کے لیے آڈٹ ایک غلطی کے ساتھ ناکام ہو جاتے ہیں۔

آڈٹ کی تکمیل میں درج ذیل غلطیاں بھی سامنے آتی ہیں۔ Decision-engine.log لاگز میں ٹریس بیک (کلسٹر حالت کی وضاحت نہیں کی گئی ہے)۔

→ خرابی کی بحث یہاں

حاصل يہ ہوا

ہماری دو ماہ کی تحقیق کا نتیجہ یہ غیر واضح نتیجہ تھا کہ ایک مکمل، ورکنگ لوڈ بیلنسنگ سسٹم حاصل کرنے کے لیے، ہمیں، اس حصے میں، Openstack پلیٹ فارم کے لیے ٹولز کو بہتر بنانے پر قریب سے کام کرنا ہوگا۔

واچر بہت زیادہ صلاحیتوں کے ساتھ ایک سنجیدہ اور تیزی سے ترقی پذیر پروڈکٹ ثابت ہوا ہے، جس کے مکمل استعمال کے لیے بہت زیادہ سنجیدہ کام کی ضرورت ہوگی۔

لیکن سیریز کے اگلے مضامین میں اس پر مزید۔

ماخذ: www.habr.com