تعادل بار در Openstack (قسمت 2)

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

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

برخی از اصطلاحات

شرکت VmWare ابزار DRS (Distributed Resource Scheduler) را برای متعادل کردن بار محیط مجازی سازی که توسعه و ارائه کرده بود، معرفی کرد.

طبق searchvmware.techtarget.com/definition/VMware-DRS
VMware DRS (Distributed Resource Scheduler) ابزاری است که بارهای محاسباتی را با منابع موجود در یک محیط مجازی متعادل می کند. این ابزار بخشی از مجموعه مجازی سازی به نام VMware Infrastructure است.

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

چرا تعادل لازم است؟

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

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

ابرهای خصوصی / مشتریان سازمانی بزرگ
ابرهای عمومی / مشاغل متوسط ​​و کوچک، مردم

معیار و اهداف اصلی اپراتور
ارائه خدمات یا محصول قابل اعتماد
کاهش هزینه خدمات در مبارزه در بازار رقابتی

الزامات خدمات
قابلیت اطمینان در تمام سطوح و در تمام عناصر سیستم

عملکرد تضمینی

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

امنیت اطلاعات و داده های فیزیکی

SLA و پشتیبانی XNUMX/XNUMX
حداکثر سهولت دریافت خدمات

خدمات نسبتا ساده

مسئولیت داده ها بر عهده مشتری است

بدون نیاز به اولویت VM

امنیت اطلاعات در سطح خدمات استاندارد، مسئولیت بر عهده مشتری

ممکن است اشکالاتی وجود داشته باشد

بدون SLA، کیفیت تضمین نشده است

پشتیبانی ایمیل

پشتیبان گیری لازم نیست

ویژگی های مشتری
طیف بسیار گسترده ای از برنامه های کاربردی.

برنامه های کاربردی قدیمی که در شرکت به ارث رسیده است.

معماری های سفارشی پیچیده برای هر مشتری.

قوانین قرابت

این نرم افزار بدون توقف در حالت 7x24 کار می کند. 

ابزارهای پشتیبان گیری در حال پرواز

بار چرخه ای مشتری قابل پیش بینی
برنامه های کاربردی معمولی – متعادل سازی شبکه، آپاچی، وب، VPN، SQL

ممکن است برنامه برای مدتی متوقف شود

به توزیع دلخواه ماشین های مجازی در فضای ابری اجازه می دهد

پشتیبان گیری مشتری

بار میانگین آماری قابل پیش بینی با تعداد زیادی مشتری.

مفاهیم برای معماری
خوشه بندی جغرافیایی

ذخیره سازی متمرکز یا توزیع شده

IBS رزرو شده است
ذخیره سازی داده های محلی در گره های محاسباتی

متعادل کردن اهداف
توزیع بار یکنواخت

حداکثر پاسخگویی برنامه 

حداقل زمان تاخیر برای تعادل

ایجاد تعادل فقط در صورت لزوم

بیرون آوردن برخی تجهیزات برای نگهداری پیشگیرانه
کاهش هزینه های خدمات و هزینه های اپراتور 

غیرفعال کردن برخی از منابع در صورت بار کم

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

کاهش هزینه های پرسنل

ما برای خودمان نتایج زیر را می گیریم:

برای ابرهای خصوصیارائه شده به مشتریان شرکت های بزرگ، DRS را می توان با محدودیت های زیر استفاده کرد:

• امنیت اطلاعات و در نظر گرفتن قوانین وابستگی در هنگام تعادل؛
• وجود منابع کافی در ذخیره در صورت وقوع حادثه؛
• داده های ماشین مجازی در یک سیستم ذخیره سازی متمرکز یا توزیع شده قرار دارند.
• اجرای سرسام آور، پشتیبان گیری و رویه های متعادل سازی در طول زمان؛
• ایجاد تعادل فقط در مجموع میزبان های مشتری؛
• متعادل کردن تنها زمانی که عدم تعادل قوی وجود دارد، موثرترین و ایمن ترین مهاجرت های VM (در نهایت، مهاجرت می تواند شکست بخورد).
• متعادل کردن ماشین‌های مجازی نسبتاً "آرام" (مهاجرت ماشین‌های مجازی "پر سر و صدا" می‌تواند زمان زیادی طول بکشد).
• تعادل با در نظر گرفتن "هزینه" - بار روی سیستم ذخیره سازی و شبکه (با معماری های سفارشی برای مشتریان بزرگ).
• تعادل با در نظر گرفتن ویژگی های رفتار فردی هر ماشین مجازی؛
• تعادل ترجیحا در ساعات غیر کاری (شب ها، آخر هفته ها، تعطیلات) انجام می شود.

برای ابرهای عمومیبا ارائه خدمات به مشتریان کوچک، DRS را می توان با قابلیت های پیشرفته تر استفاده کرد:

• عدم وجود محدودیت های امنیت اطلاعات و قوانین وابستگی؛
• تعادل در فضای ابری؛
• ایجاد تعادل در هر زمان معقول؛
• متعادل کردن هر VM
• متعادل کردن ماشین‌های مجازی پر سر و صدا (به طوری که مزاحم دیگران نشود).
• داده های ماشین مجازی اغلب بر روی دیسک های محلی قرار دارند.
• با در نظر گرفتن میانگین عملکرد سیستم های ذخیره سازی و شبکه ها (معماری ابر یکپارچه است)؛
• تعادل بر اساس قوانین کلی و آمار رفتار مرکز داده موجود.

پیچیدگی مشکل

مشکل تعادل این است که DRS باید با تعداد زیادی از عوامل نامشخص کار کند:

• رفتار کاربران هر یک از سیستم های اطلاعاتی مشتریان؛
• الگوریتم های عملکرد سرورهای سیستم اطلاعاتی؛
• رفتار سرورهای DBMS؛
• بار بر روی منابع محاسباتی، سیستم های ذخیره سازی، شبکه؛
• تعامل سرورها با یکدیگر در مبارزه برای منابع ابری.

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

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

تاریخچه تحولات ما

برای حل این مشکل، تصمیم گرفتیم که از صفر شروع نکنیم، بلکه از تجربیات موجود استفاده کنیم و شروع به تعامل با متخصصان با تجربه در این زمینه کردیم. خوشبختانه درک ما از مشکل کاملاً همزمان بود.

مرحله 1

ما از یک سیستم مبتنی بر فناوری شبکه عصبی استفاده کردیم و سعی کردیم منابع خود را بر اساس آن بهینه کنیم.

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

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

در عین حال، ما محدودیت های کاملاً جدی داشتیم:

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

مرحله 2

از آنجایی که ما از وضعیت راضی نبودیم، تصمیم گرفتیم سیستم را اصلاح کنیم و برای انجام این کار، پاسخ دهید. سوال اصلی - برای کی درست می کنیم؟

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

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

سوال سوم – چه اندازه از تعداد متعادل سرورها را انتخاب کنید؟
این موضوع خود به خود حل شد. به طور معمول، کلاینت‌ها تجمیع سرورها را خیلی بزرگ نمی‌کنند و این با توصیه‌های مقاله برای محدود کردن تجمیع‌ها به 30-40 سرور مطابقت دارد.

علاوه بر این، با تقسیم بندی استخر سرور، کار الگوریتم تعادل را ساده می کنیم.

سوال چهارم - یک شبکه عصبی با فرآیند طولانی یادگیری و تعادل نادر چقدر برای ما مناسب است؟ ما تصمیم گرفتیم آن را به نفع الگوریتم‌های عملیاتی ساده‌تر کنار بگذاریم تا در چند ثانیه به نتیجه برسیم.

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

ما این سیستم را پیاده سازی و راه اندازی کردیم و نتایج دلگرم کننده ای دریافت کردیم - اکنون به طور مرتب بار ابر را تجزیه و تحلیل می کند و توصیه هایی برای جابجایی ماشین های مجازی ارائه می دهد که تا حد زیادی درست است. حتی در حال حاضر واضح است که ما می توانیم 10-15٪ از منابع را برای ماشین های مجازی جدید در حالی که کیفیت کار ماشین های موجود را بهبود می بخشیم، به دست آوریم.

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

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

مرحله 3

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

1. به عنوان مثال آمار، اینجا и اینجا نشان می دهد که عملکرد سیستم های دو و چهار پردازنده به طور قابل توجهی کمتر از سیستم های تک پردازنده است. این بدان معناست که همه کاربران خروجی قابل توجهی کمتری از CPU، RAM، SSD، LAN، FC خریداری شده در سیستم های چند پردازنده ای در مقایسه با سیستم های تک پردازنده دریافت می کنند.
2. خود برنامه‌ریزان منابع ممکن است خطاهای جدی داشته باشند، در اینجا یکی از مقالات است در این مورد.
3. فن آوری های ارائه شده توسط اینتل و AMD برای نظارت بر رم و حافظه نهان امکان مطالعه رفتار ماشین های مجازی و قرار دادن آنها را به گونه ای فراهم می کند که همسایگان "پر سر و صدا" با ماشین های مجازی "آرام" تداخل نداشته باشند.
4. گسترش مجموعه پارامترها (شبکه، سیستم ذخیره سازی، اولویت ماشین مجازی، هزینه مهاجرت، آمادگی آن برای مهاجرت).

در کل

نتیجه کار ما برای بهبود الگوریتم های متعادل کننده این نتیجه روشن بود که با استفاده از الگوریتم های مدرن می توان به بهینه سازی قابل توجهی از منابع مرکز داده (25-30٪) دست یافت و در عین حال کیفیت خدمات به مشتریان را بهبود بخشید.

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

در مقالات بعدی در مورد قابلیت های پردازنده ها، زمانبندی ها و بالانس سطح بالا به شما خواهیم گفت.

منبع: www.habr.com