Load Balancing در Openstack

در سیستم های ابری بزرگ، مسئله تعادل خودکار یا تراز کردن بار منابع محاسباتی به ویژه حاد است. Tionix (توسعه دهنده و اپراتور خدمات ابری، بخشی از گروه شرکت های Rostelecom) نیز به این موضوع رسیدگی کرده است.

و از آنجایی که پلتفرم اصلی توسعه ما Openstack است و ما مانند همه افراد تنبل هستیم، تصمیم گرفته شد ماژول آماده ای را انتخاب کنیم که قبلاً در پلتفرم موجود است. انتخاب ما بر عهده Watcher بود که تصمیم گرفتیم برای نیازهای خود از آن استفاده کنیم.
Load Balancing در Openstack
ابتدا به اصطلاحات و تعاریف نگاه می کنیم.

اصطلاحات و تعاریف

هدف یک نتیجه نهایی قابل خواندن، قابل مشاهده و اندازه گیری برای انسان است که باید به آن دست یافت. برای رسیدن به هر هدف یک یا چند استراتژی وجود دارد. استراتژی اجرای الگوریتمی است که قادر به یافتن راه حل برای یک هدف معین است.

عمل یک کار ابتدایی است که وضعیت فعلی منبع مدیریت شده هدف خوشه OpenStack را تغییر می دهد، مانند: مهاجرت یک ماشین مجازی (مهاجرت)، تغییر وضعیت قدرت یک گره (change_node_power_state)، تغییر وضعیت سرویس nova (change_nova_service_state). )، تغییر طعم (تغییر اندازه)، ثبت پیام های NOP (nop)، عدم عملکرد برای مدت زمان معین - مکث (خواب)، انتقال دیسک (volume_migrate).

برنامه عملیاتی - یک جریان خاص از اقدامات انجام شده در یک نظم خاص برای دستیابی به یک هدف خاص. برنامه اقدام همچنین شامل عملکرد جهانی اندازه گیری شده با مجموعه ای از شاخص های عملکرد است. یک برنامه عملیاتی توسط واچر پس از یک حسابرسی موفق ایجاد می شود، در نتیجه استراتژی مورد استفاده راه حلی برای دستیابی به هدف پیدا می کند. یک برنامه اقدام شامل فهرستی از اقدامات متوالی است.

حسابرسی درخواستی برای بهینه سازی خوشه است. بهینه سازی به منظور دستیابی به یک هدف در یک خوشه معین انجام می شود. برای هر ممیزی موفق، Watcher یک برنامه اقدام ایجاد می کند.

محدوده حسابرسی مجموعه ای از منابع است که ممیزی در آنها انجام می شود (منطقه(های) در دسترس بودن، جمع کننده گره ها، گره های محاسباتی منفرد یا گره های ذخیره سازی و غیره). محدوده ممیزی در هر قالب تعریف شده است. اگر دامنه ممیزی مشخص نشده باشد، کل خوشه حسابرسی می شود.

قالب حسابرسی - مجموعه ای از تنظیمات ذخیره شده برای راه اندازی حسابرسی. برای اجرای ممیزی چندین بار با تنظیمات یکسان به الگوها نیاز است. الگو باید الزاماً حاوی هدف ممیزی باشد؛ اگر استراتژی‌ها مشخص نشده باشند، مناسب‌ترین استراتژی‌های موجود انتخاب می‌شوند.

خوشه مجموعه ای از ماشین های فیزیکی است که منابع محاسباتی، ذخیره سازی و شبکه را فراهم می کند و توسط همان گره مدیریت OpenStack مدیریت می شود.

مدل داده های خوشه ای (CDM) یک نمایش منطقی از وضعیت فعلی و توپولوژی منابع مدیریت شده توسط خوشه است.

شاخص کارایی - شاخصی که نشان می دهد راه حل ایجاد شده با استفاده از این استراتژی چگونه انجام می شود. شاخص‌های عملکرد مختص یک هدف خاص هستند و معمولاً برای محاسبه اثربخشی کلی برنامه اقدام حاصل استفاده می‌شوند.

مشخصات اثربخشی مجموعه‌ای از ویژگی‌های خاص مرتبط با هر هدف است که شاخص‌های عملکردی مختلفی را تعریف می‌کند که یک استراتژی برای دستیابی به هدف مربوطه باید در راه‌حل خود به آن دست یابد. در واقع، هر راه حلی که توسط استراتژی پیشنهاد می شود، قبل از محاسبه اثربخشی جهانی آن، با مشخصات آن بررسی می شود.

موتور امتیازدهی یک فایل اجرایی است که دارای ورودی های کاملاً تعریف شده، خروجی های کاملاً تعریف شده است و یک کار کاملاً ریاضی را انجام می دهد. به این ترتیب، محاسبه مستقل از محیطی است که در آن انجام می شود - نتیجه یکسانی را در هر کجا به دست می دهد.

ناظر برنامه ریز - بخشی از موتور تصمیم گیری Watcher. این ماژول مجموعه ای از اقدامات ایجاد شده توسط یک استراتژی را انجام می دهد و یک برنامه گردش کار ایجاد می کند که نحوه زمان بندی این اقدامات مختلف را در زمان مشخص می کند و برای هر اقدام، پیش شرط ها چیست.

اهداف و استراتژی های ناظر

هدف
استراتژی

هدف ساختگی
استراتژی ساختگی 

استراتژی ساختگی با استفاده از موتورهای امتیازدهی نمونه

استراتژی ساختگی با تغییر اندازه

صرفه جویی در انرژی
استراتژی صرفه جویی در انرژی

ادغام سرور
ادغام اولیه سرور آفلاین

استراتژی تلفیق حجم کار VM

تعادل حجم کار
استراتژی مهاجرت تعادل حجم کار

استراتژی تعادل ظرفیت ذخیره سازی

تثبیت بار کاری

همسایه پر سر و صدا
همسایه پر سر و صدا

بهینه سازی حرارتی
استراتژی مبتنی بر دمای خروجی

بهینه سازی جریان هوا
استراتژی یکنواخت مهاجرت جریان هوا

تعمیر و نگهداری سخت افزار
مهاجرت منطقه

طبقه بندی نشده
فعال کننده

هدف ساختگی - هدف رزرو شده که برای اهداف آزمایشی استفاده می شود.

استراتژی‌های مرتبط: استراتژی ساختگی، استراتژی ساختگی با استفاده از موتورهای امتیازدهی نمونه و استراتژی ساختگی با تغییر اندازه. استراتژی ساختگی یک استراتژی ساختگی است که برای آزمایش ادغام از طریق Tempest استفاده می شود. این استراتژی هیچ بهینه سازی مفیدی ارائه نمی دهد، تنها هدف آن استفاده از تست های Tempest است.

استراتژی ساختگی با استفاده از موتورهای امتیازدهی نمونه - استراتژی مشابه استراتژی قبلی است، تنها تفاوت آن استفاده از یک نمونه "موتور امتیاز دهی" است که محاسبات را با استفاده از روش های یادگیری ماشین انجام می دهد.

استراتژی ساختگی با تغییر اندازه - استراتژی شبیه به قبلی است، تنها تفاوت در استفاده از تغییر طعم (مهاجرت و تغییر اندازه) است.

در تولید استفاده نمی شود.

صرفه جویی در انرژی - به حداقل رساندن مصرف انرژی استراتژی صرفه جویی در انرژی این هدف، همراه با استراتژی تلفیق حجم کار VM (تجمیع سرور)، قابلیت مدیریت توان پویا (DPM) را دارد که با یکپارچه‌سازی پویا بارهای کاری حتی در دوره‌های استفاده کم از منابع، در مصرف انرژی صرفه‌جویی می‌کند: ماشین‌های مجازی به گره‌های کمتری منتقل می‌شوند. ، و گره های غیر ضروری غیر فعال می شوند. پس از ادغام، استراتژی تصمیم گیری در مورد روشن/خاموش کردن گره ها مطابق با پارامترهای مشخص شده ارائه می دهد: "min_free_hosts_num" - تعداد گره های فعال رایگان که منتظر بارگذاری هستند، و "free_used_percent" - درصد میزبان های فعال رایگان به تعداد گره هایی که توسط ماشین ها اشغال شده اند. برای اینکه استراتژی کار کند باید وجود داشته باشد Ironic را فعال و پیکربندی کرد تا چرخه نیرو در گره ها را کنترل کند.

پارامترهای استراتژی

پارامتر
тип
به طور پیش فرض
описание

free_used_percent
شماره
10.0
نسبت تعداد گره های محاسباتی آزاد به تعداد گره های محاسباتی با ماشین های مجازی

min_free_hosts_num
INT
1
حداقل تعداد گره های محاسباتی رایگان

ابر باید حداقل دو گره داشته باشد. روش مورد استفاده تغییر وضعیت توان گره (change_node_power_state) است. این استراتژی نیازی به جمع آوری معیارها ندارد.

ادغام سرور - تعداد گره های محاسباتی را به حداقل برسانید (ادغام). این دو استراتژی دارد: Basic Offline Server Consolidation و VM Workload Consolidation Strategy.

استراتژی Basic Offline Server Consolidation تعداد کل سرورهای استفاده شده را به حداقل می رساند و همچنین تعداد مهاجرت ها را به حداقل می رساند.

استراتژی اصلی به معیارهای زیر نیاز دارد:

معیارهای
سرویس
پلاگین ها
تفسیر

compute.node.cpu.percent
ارتفاع سنج
هیچ
 

cpu_util
ارتفاع سنج
هیچ
 

پارامترهای استراتژی: migration_ttempts - تعداد ترکیب‌ها برای جستجوی نامزدهای بالقوه برای خاموش شدن (پیش‌فرض، 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 - ceilometer-agent-compute، در حال اجرا بر روی هر گره محاسباتی، و Ceilometer API را نصب و پیکربندی کرد، و همچنین معیارهای زیر را جمع آوری کرد:

معیارهای
سرویس
پلاگین ها
تفسیر

cpu_util
ارتفاع سنج
هیچ
 

حافظه.ساکن
ارتفاع سنج
هیچ
 

استراتژی تعادل ظرفیت ذخیره سازی (استراتژی که با کوئینز اجرا می شود) - این استراتژی دیسک ها را بسته به بار روی استخرهای Cinder منتقل می کند. هر زمان که نرخ استفاده از استخر از یک آستانه مشخص فراتر رود، تصمیم انتقال گرفته می شود. دیسکی که جابجا می شود باید استخر را به میانگین بار تمام استخرهای Cinder نزدیک کند.

الزامات و محدودیت ها

  • حداقل دو استخر Cinder;
  • امکان مهاجرت دیسک.
  • مدل داده های خوشه ای - جمع آوری کننده مدل داده های خوشه ای Cinder.

پارامترهای استراتژی:

پارامتر
тип
به طور پیش فرض
описание

آستانه_حجم
شماره
80.0
مقدار آستانه دیسک ها برای متعادل کردن حجم ها.

روش مورد استفاده انتقال دیسک (volume_migrate) است.

همسایه پر سر و صدا - یک "همسایه پر سر و صدا" را شناسایی و منتقل کنید - یک ماشین مجازی با اولویت پایین که با استفاده بیش از حد از Last Level Cache بر عملکرد یک ماشین مجازی با اولویت بالا از نظر IPC تأثیر منفی می گذارد. استراتژی شخصی: همسایه پر سر و صدا (پارامتر استراتژی مورد استفاده cache_threshold است (مقدار پیش‌فرض 35 است)، وقتی عملکرد به مقدار مشخص شده کاهش می‌یابد، مهاجرت شروع می‌شود. برای کارکرد استراتژی، فعال است. LLC (آخرین سطح حافظه پنهان) معیارها، آخرین سرور اینتل با پشتیبانی CMT، و همچنین جمع آوری معیارهای زیر:

معیارهای
سرویس
پلاگین ها
تفسیر

cpu_l3_cache
ارتفاع سنج
هیچ
اینتل مورد نیاز است CMT.

مدل داده های خوشه ای (پیش فرض): جمع آوری کننده مدل داده های خوشه ای نوا. روش مورد استفاده مهاجرت است.

کار با این هدف از طریق داشبورد به طور کامل در کوئینز اجرا نمی شود.

بهینه سازی حرارتی - بهینه سازی رژیم دما دمای خروجی (هوای خروجی) یکی از سیستم های تله متری حرارتی مهم برای اندازه گیری وضعیت حرارتی/بار کاری سرور است. هدف یک استراتژی دارد، استراتژی مبتنی بر دمای خروجی، که تصمیم می‌گیرد تا زمانی که دمای خروجی میزبان‌های منبع به یک آستانه قابل تنظیم رسید، بارهای کاری را به میزبان‌های مطلوب حرارتی (پایین‌ترین دمای خروجی) منتقل کند.

برای اینکه این استراتژی کار کند، به یک سرور با Intel Power Node Manager نصب و پیکربندی شده نیاز دارید 3.0 یا بالاتر، و همچنین جمع آوری معیارهای زیر:

معیارهای
سرویس
پلاگین ها
تفسیر

hardware.ipmi.node.outlet_temperature
ارتفاع سنج
IPMI
 

پارامترهای استراتژی:

پارامتر
тип
به طور پیش فرض
описание

آستانه
شماره
35.0
آستانه دما برای مهاجرت

دوره
شماره
30
فاصله زمانی، بر حسب ثانیه، برای به دست آوردن تجمیع آماری از منبع داده های متریک.

روش مورد استفاده مهاجرت است.

بهینه سازی جریان هوا - حالت تهویه را بهینه کنید. استراتژی شخصی - جریان هوای یکنواخت با استفاده از مهاجرت زنده. هر زمان که جریان هوا از طرف فن سرور از یک آستانه مشخص فراتر رود، این استراتژی مهاجرت ماشین مجازی را آغاز می‌کند.

برای اینکه استراتژی کار کند شما نیاز دارید:

  • سخت افزار: گره های محاسبه < پشتیبانی از NodeManager 3.0.
  • حداقل دو گره محاسباتی.
  • مؤلفه ceilometer-agent-compute و Ceilometer API نصب و پیکربندی شده روی هر گره محاسباتی، که می تواند با موفقیت معیارهایی مانند جریان هوا، توان سیستم، دمای ورودی را گزارش کند:

معیارهای
سرویس
پلاگین ها
تفسیر

hardware.ipmi.node.airflow
ارتفاع سنج
IPMI
 

hardware.ipmi.node.temperature
ارتفاع سنج
IPMI
 

hardware.ipmi.node.power
ارتفاع سنج
IPMI
 

برای اینکه این استراتژی کار کند، به یک سرور با Intel Power Node Manager 3.0 یا جدیدتر نصب و پیکربندی شده نیاز دارید.

محدودیت ها: این مفهوم برای تولید در نظر گرفته نشده است.

پیشنهاد می شود از این الگوریتم با ممیزی های مداوم استفاده شود، زیرا تنها یک ماشین مجازی برای انتقال در هر تکرار برنامه ریزی شده است.

مهاجرت های زنده امکان پذیر است.

پارامترهای استراتژی:

پارامتر
тип
به طور پیش فرض
описание

آستانه_جریان هوا
شماره
400.0
آستانه جریان هوا برای واحد مهاجرت 0.1CFM است

threshold_inlet_t
شماره
28.0
آستانه دمای ورودی برای تصمیم گیری مهاجرت

آستانه_قدرت
شماره
350.0
آستانه قدرت سیستم برای تصمیم گیری مهاجرت

دوره
شماره
30
فاصله زمانی، بر حسب ثانیه، برای به دست آوردن تجمیع آماری از منبع داده های متریک.

روش مورد استفاده مهاجرت است.

تعمیر و نگهداری سخت افزار - تعمیر و نگهداری سخت افزار استراتژی مربوط به این هدف مهاجرت منطقه ای است. استراتژی ابزاری برای مهاجرت خودکار و حداقلی ماشین های مجازی و دیسک ها در صورت نیاز به نگهداری سخت افزار است. استراتژی برنامه عملی را مطابق با وزن ها می سازد: مجموعه ای از اقدامات که وزن بیشتری دارند قبل از دیگران برنامه ریزی می شوند. دو گزینه پیکربندی وجود دارد: action_weights و موازی سازی.

محدودیت ها: وزن های عمل و موازی سازی باید پیکربندی شوند.

پارامترهای استراتژی:

پارامتر
тип
به طور پیش فرض
описание

محاسبه_گره ها
صف
هیچ
محاسبه گره ها برای مهاجرت

ذخیره_استخرها
صف
هیچ
گره های ذخیره سازی برای مهاجرت

موازی_کل
عدد صحیح
6
تعداد کل فعالیت هایی که باید به صورت موازی اجرا شوند.

parallel_per_node
عدد صحیح
2
تعداد اقدامات انجام شده به صورت موازی برای هر گره محاسباتی.

parallel_per_pool
عدد صحیح
2
تعداد اقدامات انجام شده به صورت موازی برای هر مخزن ذخیره سازی.

اولویت
هدف
هیچ
لیست اولویت برای ماشین های مجازی و دیسک ها.

with_tached_volume
بولی
غلط
نادرست - ماشین‌های مجازی پس از انتقال همه دیسک‌ها منتقل می‌شوند. درست است - ماشین‌های مجازی پس از انتقال همه دیسک‌های متصل منتقل می‌شوند.

عناصر آرایه گره های محاسباتی:

پارامتر
тип
به طور پیش فرض
описание

src_node
رشته
هیچ
گره محاسباتی که ماشین های مجازی از آن مهاجرت می کنند (الزامی).

dst_node
رشته
هیچ
گره ای که ماشین های مجازی به آن مهاجرت می کنند را محاسبه کنید.

عناصر آرایه گره ذخیره سازی:

پارامتر
тип
به طور پیش فرض
описание

src_pool
رشته
هیچ
مخزن ذخیره‌سازی که دیسک‌ها از آن منتقل می‌شوند (الزامی).

dst_pool
رشته
هیچ
مخزن ذخیره سازی که دیسک ها به آن منتقل می شوند.

src_type
رشته
هیچ
نوع دیسک اصلی (الزامی).

dst_type
رشته
هیچ
نوع دیسک حاصل (الزامی).

عناصر اولویت شی:

پارامتر
тип
به طور پیش فرض
описание

پروژه
صف
هیچ
نام پروژه ها

compute_node
صف
هیچ
محاسبه نام گره ها

storage_pool
صف
هیچ
نام استخرهای ذخیره سازی

محاسبه کردن
شمردن
هیچ
پارامترهای ماشین مجازی ["vcpu_num"، "mem_size"، "disk_size"، "created_at"].

ذخیره سازی
شمردن
هیچ
پارامترهای دیسک ["اندازه"، "created_at"].

روش های مورد استفاده مهاجرت ماشین مجازی، مهاجرت دیسک می باشد.

طبقه بندی نشده - یک هدف کمکی که برای تسهیل فرآیند توسعه استراتژی استفاده می شود. فاقد مشخصات است و زمانی که استراتژی هنوز با یک هدف موجود مرتبط نباشد می توان از آن استفاده کرد. از این هدف می توان به عنوان نقطه گذار نیز استفاده کرد. یک استراتژی مرتبط با این هدف Actuator است.   

ایجاد یک هدف جدید

موتور تصمیم تماشاگر دارای یک رابط پلاگین "هدف خارجی" است که امکان ادغام یک هدف خارجی را فراهم می کند که می توان با استفاده از یک استراتژی به آن دست یافت.

قبل از ایجاد یک هدف جدید، باید مطمئن شوید که هیچ هدف موجود نیازهای شما را برآورده نمی کند.

ایجاد یک افزونه جدید

برای ایجاد یک هدف جدید، باید: کلاس هدف را گسترش دهید، یک متد کلاس را پیاده سازی کنید get_name() برای برگرداندن شناسه منحصر به فرد هدف جدیدی که می خواهید ایجاد کنید. این شناسه منحصر به فرد باید با نام نقطه ورودی که بعداً اعلام می کنید مطابقت داشته باشد.

در مرحله بعد باید متد کلاس را پیاده سازی کنید get_display_name() برای برگرداندن نام نمایشی ترجمه شده هدفی که می خواهید ایجاد کنید (از متغیری برای برگرداندن رشته ترجمه شده استفاده نکنید تا بتواند به طور خودکار توسط ابزار ترجمه جمع آوری شود.).

یک متد کلاسی را اجرا کنید get_translatable_display_name()برای بازگرداندن کلید ترجمه (در واقع نام نمایش انگلیسی) هدف جدید شما. مقدار بازگشتی باید با رشته ترجمه شده به get_display_name() مطابقت داشته باشد.

روش او را اجرا کنید get_efficacy_specification()برای بازگرداندن مشخصات کارایی برای هدف خود. متد get_efficacy_specification() نمونه Unclassified() ارائه شده توسط Watcher را برمی گرداند. این مشخصات عملکرد در فرآیند توسعه هدف شما مفید است زیرا با مشخصات خالی مطابقت دارد.

ادامه مطلب را اینجا بخوانید

معماری ناظر (جزئیات بیشتر) اینجا).

Load Balancing در Openstack

اجزاء

Load Balancing در Openstack

Watcher API - مؤلفه ای که REST API ارائه شده توسط Watcher را پیاده سازی می کند. مکانیسم های تعامل: CLI، پلاگین Horizon، Python SDK.

Watcher DB - پایگاه داده Watcher.

Watcher Applier - مؤلفه ای که اجرای یک برنامه اقدام ایجاد شده توسط مؤلفه Watcher Decision Engine را اجرا می کند.

موتور تصمیم تماشاگر - جزء مسئول محاسبه مجموعه ای از اقدامات بهینه سازی بالقوه برای دستیابی به هدف حسابرسی. اگر استراتژی مشخص نشده باشد، جزء به طور مستقل مناسب ترین را انتخاب می کند.

ناشر Watcher Metrics - مؤلفه ای که برخی از معیارها یا رویدادها را جمع آوری و محاسبه می کند و آنها را در نقطه پایانی CEP منتشر می کند. کارایی کامپوننت را نیز می توان توسط ناشر Ceilometer ارائه کرد.

موتور پردازش رویداد پیچیده (CEP). - موتور برای پردازش رویدادهای پیچیده. به دلایل عملکرد، ممکن است چندین نمونه CEP Engine به طور همزمان در حال اجرا باشند، که هر یک نوع خاصی از متریک/رویداد را پردازش می کند. در سیستم Watcher، CEP دو نوع عمل را راه‌اندازی می‌کند: - ثبت رویدادها / معیارهای مربوطه در پایگاه داده سری زمانی. - هنگامی که این رویداد می تواند بر نتیجه استراتژی بهینه سازی فعلی تأثیر بگذارد، رویدادهای مناسب را به موتور تصمیم گیری Watcher ارسال کنید، زیرا خوشه Openstack یک سیستم ثابت نیست.

اجزا با استفاده از پروتکل AMQP تعامل دارند.

در حال پیکربندی Watcher

طرح تعامل با Watcher

Load Balancing در Openstack

نتایج تست ناظر

  1. در صفحه Optimization - Action Plans 500 (هم در کوئینز خالص و هم در یک پایه با ماژول های Tionix)، تنها پس از راه اندازی ممیزی و ایجاد یک برنامه اقدام ظاهر می شود؛ برنامه خالی به طور معمول باز می شود.
  2. در برگه Action details خطاهایی وجود دارد، امکان دریافت هدف و استراتژی ممیزی وجود ندارد (هم در کوئینز خالص و هم در یک پایه با ماژول های Tionix).
  3. ممیزی ها با هدف ساختگی (تست) به طور معمول ایجاد و راه اندازی می شوند، برنامه های عملیاتی تولید می شوند.
  4. ممیزی برای هدف طبقه بندی نشده ایجاد نمی شود زیرا هدف کاربردی نیست و برای پیکربندی میانی در هنگام ایجاد استراتژی های جدید در نظر گرفته شده است.
  5. ممیزی ها به منظور توازن بار کاری (استراتژی تعادل ظرفیت ذخیره سازی) با موفقیت ایجاد می شوند، اما برنامه عملیاتی ایجاد نمی شود. بدون نیاز به بهینه سازی استخر ذخیره سازی
  6. ممیزی برای هدف متعادل سازی حجم کار (استراتژی مهاجرت تعادل حجم کار) با موفقیت ایجاد می شود، اما برنامه عملیاتی ایجاد نمی شود.
  7. ممیزی برای تعادل حجم کاری (استراتژی تثبیت بار کاری) با شکست مواجه می شود.
  8. ممیزی‌ها برای هدف همسایه پر سر و صدا با موفقیت ایجاد می‌شوند، اما برنامه عملیاتی ایجاد نمی‌شود.
  9. ممیزی برای هدف تعمیر و نگهداری سخت افزار با موفقیت ایجاد می شود، برنامه اقدام به طور کامل ایجاد نمی شود (شاخص های عملکرد تولید می شوند، اما لیست اقدامات خود ایجاد نمی شود).
  10. ویرایش‌های پیکربندی‌های nova.conf (در بخش پیش‌فرض compute_monitors = cpu.virt_driver) روی گره‌های محاسبه و کنترل، خطاها را تصحیح نمی‌کنند.
  11. ممیزی هایی که ادغام سرور (استراتژی اساسی) را هدف قرار می دهند نیز شکست می خورند.
  12. ممیزی برای هدف تلفیق سرور (استراتژی تلفیق حجم کار VM) با یک خطا شکست می خورد. در لاگ ها در به دست آوردن داده های منبع خطا وجود دارد. بحث در مورد خطا، به ویژه اینجا.
    ما سعی کردیم Watcher را در فایل پیکربندی مشخص کنیم (این کمک نکرد - در نتیجه یک خطا در تمام صفحات بهینه سازی، بازگشت به محتوای اصلی فایل پیکربندی وضعیت را اصلاح نمی کند):

    [watcher_strategies.basic] منبع داده = ارتفاع سنج، gnocchi
  13. ممیزی برای صرفه جویی در انرژی شکست خورد. با قضاوت بر اساس لاگ ها، مشکل همچنان عدم وجود Ironic است؛ بدون سرویس baremetal کار نخواهد کرد.
  14. ممیزی برای بهینه سازی حرارتی شکست می خورد. ردیابی همان است که برای ادغام سرور (استراتژی تلفیق حجم کار VM) (خطای داده منبع)
  15. ممیزی برای هدف بهینه سازی جریان هوا با یک خطا شکست می خورد.

خطاهای تکمیل حسابرسی زیر نیز مشاهده می شود. ردیابی در سیاهههای مربوط به engine-engine.log (وضعیت خوشه تعریف نشده است).

→ بحث در مورد خطا اینجا

نتیجه

نتیجه تحقیقات دو ماهه ما این بود که به این نتیجه صریح رسیدیم که برای به دست آوردن یک سیستم متعادل کننده بار کامل و کارآمد، در این بخش باید از نزدیک روی پالایش ابزارهای پلت فرم Openstack کار کنیم.

واچر ثابت کرده است که یک محصول جدی و به سرعت در حال توسعه با پتانسیل بسیار زیاد است که استفاده کامل از آن مستلزم کار جدی زیادی است.

اما در مقالات بعدی این مجموعه بیشتر در این مورد توضیح داده می شود.

منبع: www.habr.com

اضافه کردن نظر