В biz Watcher-dan istifadə cəhdlərimizdən danışdıq və sınaq hesabatını təqdim etdik. Biz vaxtaşırı böyük müəssisə və ya operator buludunun balanslaşdırılması və digər kritik funksiyaları üçün belə testlər keçiririk.
Həll olunan problemin yüksək mürəkkəbliyi layihəmizi təsvir etmək üçün bir neçə məqalə tələb edə bilər. Bu gün biz buludda virtual maşınların balanslaşdırılmasına həsr olunmuş seriyanın ikinci məqaləsini dərc edirik.
Bəzi terminologiya
VmWare şirkəti hazırladıqları və təklif etdikləri virtualizasiya mühitinin yükünü tarazlaşdırmaq üçün DRS (Paylaşdırılan Resurs Planlayıcısı) yardım proqramını təqdim etdi.
Yazdığı kimi
“VMware DRS (Distributed Resource Scheduler) virtual mühitdə mövcud resurslarla hesablama yüklərini tarazlayan bir yardım proqramıdır. Utilit VMware İnfrastructure adlı virtuallaşdırma paketinin bir hissəsidir.
VMware DRS ilə istifadəçilər fiziki resursların virtual maşınlar (VM) arasında paylanması qaydalarını müəyyən edirlər. Köməkçi proqram əl və ya avtomatik idarəetmə üçün konfiqurasiya edilə bilər. VMware resurs hovuzlarını asanlıqla əlavə etmək, silmək və ya yenidən təşkil etmək olar. Arzu edilərsə, resurs hovuzları müxtəlif biznes bölmələri arasında təcrid oluna bilər. Bir və ya bir neçə virtual maşındakı iş yükü kəskin şəkildə dəyişirsə, VMware DRS virtual maşınları fiziki serverlər arasında yenidən paylayır. Ümumi iş yükü azalarsa, bəzi fiziki serverlər müvəqqəti olaraq oflaynlaşdırıla və iş yükü birləşdirilə bilər."
Niyə balanslaşdırma lazımdır?
Fikrimizcə, DRS mütləq olmalıdır bulud xüsusiyyətidir, baxmayaraq ki, bu, DRS həmişə və hər yerdə istifadə edilməli olduğu demək deyil. Buludun məqsədi və ehtiyaclarından asılı olaraq, DRS və balanslaşdırma üsulları üçün müxtəlif tələblər ola bilər. Balanslaşdırmanın ümumiyyətlə lazım olmadığı vəziyyətlər ola bilər. Və ya hətta zərərlidir.
DRS-nin harada və hansı müştərilər üçün lazım olduğunu daha yaxşı başa düşmək üçün onların məqsəd və vəzifələrini nəzərdən keçirək. Buludlar ictimai və özəl bölünə bilər. Bu buludlarla müştəri məqsədləri arasındakı əsas fərqlər bunlardır.
Şəxsi buludlar / Böyük müəssisə müştəriləri
İctimai buludlar / Orta və kiçik biznes, insanlar
Operatorun əsas meyarı və məqsədləri
Etibarlı xidmət və ya məhsul təqdim etmək
Rəqabətli bazarda mübarizədə xidmətlərin dəyərinin azaldılması
Xidmət tələbləri
Bütün səviyyələrdə və bütün sistem elementlərində etibarlılıq
Zəmanətli performans
Virtual maşınlara bir neçə kateqoriyaya üstünlük verin
İnformasiya və fiziki məlumatların təhlükəsizliyi
SLA və XNUMX/XNUMX dəstək
Xidmətin alınmasının maksimum asanlığı
Nisbətən sadə xidmətlər
Məlumatlara görə məsuliyyət müştərinin üzərinə düşür
VM prioritetləşdirmə tələb olunmur
Standart xidmətlər səviyyəsində informasiya təhlükəsizliyi, müştəri üzərində məsuliyyət
Qüsurlar ola bilər
SLA yoxdur, keyfiyyətə zəmanət verilmir
E-poçt dəstəyi
Yedəkləmə lazım deyil
Müştəri Xüsusiyyətləri
Çox geniş tətbiqlər.
Şirkətdə miras qalmış tətbiqlər.
Hər bir müştəri üçün kompleks fərdi arxitektura.
Yaxınlıq qaydaları.
Proqram təminatı 7x24 rejimində dayanmadan işləyir.
On-the-fly ehtiyat alətləri.
Proqnozlaşdırıla bilən dövri müştəri yükü.
Tipik tətbiqlər – şəbəkə balansı, Apache, WEB, VPN, SQL
Tətbiq bir müddət dayana bilər
VM-lərin buludda ixtiyari paylanmasına imkan verir
Müştəri ehtiyat nüsxəsi
Çox sayda müştəri ilə proqnozlaşdırıla bilən statistik orta yük.
Memarlıq üçün təsirlər
Geoklasterləşmə
Mərkəzləşdirilmiş və ya paylanmış saxlama
Lazımsız İBS
Hesablama qovşaqlarında yerli məlumatların saxlanması
Balanslaşdırma Məqsədləri
Düzgün yük paylanması
Maksimum tətbiq reaksiyası
Balanslaşdırma üçün minimum gecikmə vaxtı
Yalnız aydın ehtiyac olduqda balanslaşdırma
Profilaktik təmir üçün bəzi avadanlığın gətirilməsi
Xidmət xərclərini və operator xərclərini azaltmaq
Aşağı yük vəziyyətində bəzi resursların söndürülməsi
Enerjiyə qənaət
Kadr xərclərinin azaldılması
Özümüz üçün aşağıdakı nəticələr çıxarırıq:
Şəxsi buludlar üçüniri korporativ müştərilərə təqdim edilən DRS aşağıdakı məhdudiyyətlərə uyğun olaraq istifadə edilə bilər:
- məlumat təhlükəsizliyi və balanslaşdırma zamanı yaxınlıq qaydalarının nəzərə alınması;
- qəza zamanı ehtiyatda kifayət qədər resursların olması;
- virtual maşın məlumatları mərkəzləşdirilmiş və ya paylanmış saxlama sistemində yerləşir;
- zamanla təəccüblü idarəetmə, ehtiyat və balanslaşdırma prosedurları;
- yalnız müştəri hostlarının məcmusunda balanslaşdırma;
- yalnız güclü disbalans olduqda balanslaşdırma, ən effektiv və təhlükəsiz VM miqrasiyaları (axı, miqrasiya uğursuz ola bilər);
- nisbətən “sakit” virtual maşınların balanslaşdırılması (“səs-küylü” virtual maşınların miqrasiyası çox uzun müddət çəkə bilər);
- "xərc" nəzərə alınmaqla balanslaşdırma - saxlama sisteminə və şəbəkəyə yük (böyük müştərilər üçün xüsusi arxitektura ilə);
- hər bir VM-nin fərdi davranış xüsusiyyətlərini nəzərə alaraq balanslaşdırma;
- Balanslaşdırma işdənkənar saatlarda (gecələr, həftə sonları, bayramlarda) həyata keçirilir.
İctimai buludlar üçünkiçik müştərilərə xidmət göstərən DRS inkişaf etmiş imkanlarla daha tez-tez istifadə edilə bilər:
- informasiya təhlükəsizliyi məhdudiyyətlərinin və yaxınlıq qaydalarının olmaması;
- bulud daxilində balans;
- istənilən ağlabatan zamanda balanslaşdırma;
- istənilən VM-nin balanslaşdırılması;
- "səs-küylü" virtual maşınları balanslaşdırmaq (başqalarını narahat etməmək üçün);
- virtual maşın məlumatları tez-tez yerli disklərdə yerləşir;
- yaddaş sistemlərinin və şəbəkələrinin orta məhsuldarlığını nəzərə alaraq (bulud arxitekturası vahiddir);
- ümumi qaydalara və mövcud məlumat mərkəzi davranış statistikasına əsasən balanslaşdırma.
Problemin mürəkkəbliyi
Balanslaşdırmanın çətinliyi ondan ibarətdir ki, DRS çox sayda qeyri-müəyyən amillərlə işləməlidir:
- müştərilərin informasiya sistemlərinin hər birinin istifadəçilərinin davranışı;
- informasiya sisteminin serverlərinin işinin alqoritmlərini;
- DBMS serverlərinin davranışı;
- hesablama resurslarına, saxlama sistemlərinə, şəbəkəyə yüklənmə;
- bulud resursları uğrunda mübarizədə serverlərin bir-biri ilə qarşılıqlı əlaqəsi.
Çox sayda virtual proqram serverinin və verilənlər bazasının bulud resurslarına yüklənməsi zaman keçdikcə baş verir, nəticələr gözlənilməz bir zaman ərzində gözlənilməz təsirlə özünü göstərə və bir-biri ilə üst-üstə düşə bilər. Hətta nisbətən sadə prosesləri idarə etmək üçün (məsələn, evdə mühərriki, su isitmə sistemini idarə etmək üçün) avtomatik idarəetmə sistemlərindən kompleks istifadə etmək lazımdır. əks əlaqə ilə alqoritmlər.
Bizim vəzifəmiz daha mürəkkəb bir çox böyüklük sifarişidir və istifadəçilərdən heç bir xarici təsir olmasa belə, sistemin ağlabatan müddətdə yükü müəyyən edilmiş dəyərlərə tarazlaya bilməməsi riski var.
İnkişaflarımızın tarixi
Bu problemi həll etmək üçün biz sıfırdan başlamaq yox, mövcud təcrübəyə əsaslanmaq qərarına gəldik və bu sahədə təcrübəsi olan mütəxəssislərlə əlaqə saxlamağa başladıq. Xoşbəxtlikdən problemi başa düşməyimiz tamamilə üst-üstə düşdü.
Mərhələ 1
Biz neyron şəbəkə texnologiyasına əsaslanan sistemdən istifadə etdik və onun əsasında resurslarımızı optimallaşdırmağa çalışdıq.
Bu mərhələnin marağı yeni texnologiyanın sınaqdan keçirilməsində, əhəmiyyəti isə başqa şeylərin bərabər olduğu halda, standart yanaşmaların praktiki olaraq tükəndiyi problemin həllinə qeyri-standart yanaşmanın tətbiqi idi.
Biz sistemi işə saldıq və həqiqətən balanslaşdırmağa başladıq. Buludumuzun miqyası bizə tərtibatçıların söylədiyi optimist nəticələri əldə etməyə imkan vermədi, lakin balanslaşdırmanın işlədiyi aydın idi.
Eyni zamanda, bizim kifayət qədər ciddi məhdudiyyətlərimiz var idi:
- Neyron şəbəkəni öyrətmək üçün virtual maşınlar həftələr və ya aylar ərzində əhəmiyyətli dəyişikliklər olmadan işləməlidir.
- Alqoritm əvvəlki “tarixi” məlumatların təhlili əsasında optimallaşdırma üçün nəzərdə tutulmuşdur.
- Neyron şəbəkənin hazırlanması kifayət qədər böyük miqdarda məlumat və hesablama resursları tələb edir.
- Optimallaşdırma və balanslaşdırma nisbətən nadir hallarda həyata keçirilə bilər - bir neçə saatda bir dəfə, bu, açıq şəkildə kifayət deyil.
Mərhələ 2
Vəziyyət bizi qane etmədiyi üçün sistemdə dəyişiklik etmək qərarına gəldik və bunun üçün cavab verdik. əsas sual - biz bunu kimin üçün edirik?
Birincisi - korporativ müştərilər üçün. Bu o deməkdir ki, bizə tətbiqi sadələşdirən korporativ məhdudiyyətlərlə tez işləyən sistem lazımdır.
İkinci sual – “Təcili” sözü ilə nəyi nəzərdə tutursunuz? Qısa debat nəticəsində biz qərara gəldik ki, 5-10 dəqiqəlik cavab müddəti ilə başlaya bilərik ki, qısamüddətli dalğalanmalar sistemi rezonansa salmasın.
Üçüncü sual – balanslaşdırılmış server sayının hansı ölçüsünü seçmək lazımdır?
Bu məsələ öz-özünə həll olundu. Tipik olaraq, müştərilər server birləşmələrini çox böyük etmirlər və bu, aqreqasiyaları 30-40 serverlə məhdudlaşdırmaq üçün məqalənin tövsiyələrinə uyğundur.
Bundan əlavə, server hovuzunu seqmentləşdirməklə biz balanslaşdırma alqoritminin tapşırığını sadələşdiririk.
Dördüncü sual – uzun öyrənmə prosesi və nadir balanslaşdırma ilə neyron şəbəkəsi bizim üçün nə dərəcədə uyğundur? Biz saniyələr ərzində nəticə əldə etmək üçün ondan daha sadə əməliyyat alqoritmlərinin xeyrinə imtina etmək qərarına gəldik.
Belə alqoritmlərdən istifadə edən sistemin təsviri və onun çatışmazlıqları tapıla bilər
Biz bu sistemi tətbiq etdik və işə saldıq və ümidverici nəticələr əldə etdik - indi o, bulud yükünü mütəmadi olaraq təhlil edir və virtual maşınların köçürülməsi üçün tövsiyələr verir ki, bu da əsasən düzgündür. İndi də aydındır ki, biz mövcud olanların iş keyfiyyətini yaxşılaşdırmaqla yeni virtual maşınlar üçün resursların 10-15% buraxılmasına nail ola bilərik.
RAM və ya CPU-da balanssızlıq aşkar edildikdə, sistem tələb olunan virtual maşınların canlı miqrasiyasını həyata keçirmək üçün Tionix planlaşdırıcısına əmrlər verir. Monitorinq sistemindən göründüyü kimi, virtual maşın bir (yuxarı) digər (aşağı) hosta keçdi və yuxarı hostda yaddaşı boşaltdı (sarı dairələrlə vurğulanır), müvafiq olaraq onu aşağı hissədə tutur (ağ rənglə vurğulanır). dairələr).
İndi biz mövcud alqoritmin effektivliyini daha dəqiq qiymətləndirməyə çalışırıq və onda mümkün səhvləri tapmağa çalışırıq.
Mərhələ 3
Görünür, bununla sakitləşə, sübut edilmiş effektivliyi gözləyə və mövzunu bağlaya bilərsiniz.
Ancaq aşağıdakı aşkar optimallaşdırma imkanları bizi yeni mərhələyə keçirməyə məcbur edir
- Statistika, məsələn, и göstərir ki, iki və dörd prosessorlu sistemlər bir prosessorlu sistemlərə nisbətən performans baxımından əhəmiyyətli dərəcədə aşağıdır. Bu o deməkdir ki, bütün istifadəçilər bir prosessorlu sistemlərlə müqayisədə çoxprosessorlu sistemlərdə alınmış CPU, RAM, SSD, LAN, FC-dən əhəmiyyətli dərəcədə daha az məhsul alırlar.
- Resurs planlaşdırıcılarının özlərində ciddi səhvlər ola bilər, bu mövzuda.
- RAM və keşin monitorinqi üçün Intel və AMD tərəfindən təklif olunan texnologiyalar virtual maşınların davranışını öyrənməyə və onları elə yerləşdirməyə imkan verir ki, “səs-küylü” qonşular “sakit” virtual maşınlara mane olmasın.
- Parametrlər dəstinin genişləndirilməsi (şəbəkə, saxlama sistemi, virtual maşının prioriteti, miqrasiyanın dəyəri, onun miqrasiyaya hazırlığı).
Ümumi
Balanslaşdırma alqoritmlərinin təkmilləşdirilməsi üzrə apardığımız işin nəticəsi aydın nəticə oldu ki, müasir alqoritmlərdən istifadə etməklə məlumat mərkəzinin resurslarının əhəmiyyətli dərəcədə optimallaşdırılmasına (25-30%) nail olmaq və eyni zamanda müştəri xidmətinin keyfiyyətini artırmaq mümkündür.
Neyroşəbəkələrə əsaslanan alqoritm, şübhəsiz ki, maraqlı bir həlldir, lakin əlavə inkişafa ehtiyacı olan bir həlldir və mövcud məhdudiyyətlərə görə, şəxsi buludlar üçün xarakterik olan həcmlərdə bu cür problemi həll etmək üçün uyğun deyil. Eyni zamanda, alqoritm əhəmiyyətli ölçülü ictimai buludlarda yaxşı nəticələr göstərdi.
Prosessorların, planlaşdırıcıların imkanları və yüksək səviyyəli balanslaşdırma haqqında sizə növbəti məqalələrdə ətraflı məlumat verəcəyik.
Mənbə: www.habr.com