Usawazishaji wa Mzigo katika Openstack (Sehemu ya 2)

Π’ makala ya mwisho tulizungumza kuhusu majaribio yetu ya kutumia Watcher na kutoa ripoti ya mtihani. Mara kwa mara tunafanya majaribio kama haya kwa kusawazisha na kazi zingine muhimu za biashara kubwa au wingu la waendeshaji.

Utata wa juu wa tatizo linalotatuliwa huenda ukahitaji makala kadhaa kuelezea mradi wetu. Leo tunachapisha nakala ya pili katika safu, iliyowekwa kwa kusawazisha mashine za mtandaoni kwenye wingu.

Istilahi fulani

Kampuni ya VmWare ilianzisha matumizi ya DRS (Distributed Resource Scheduler) ili kusawazisha mzigo wa mazingira ya uboreshaji waliyotengeneza na kutoa.

Kulingana na searchvmware.techtarget.com/definition/VMware-DRS
β€œVMware DRS (Mratibu wa Rasilimali Zilizosambazwa) ni shirika linalosawazisha mizigo ya kompyuta na rasilimali zinazopatikana katika mazingira pepe. Huduma ni sehemu ya kitengo cha uboreshaji kiitwacho VMware Infrastructure.

Kwa VMware DRS, watumiaji hufafanua sheria za kusambaza rasilimali kati ya mashine pepe (VMs). Huduma inaweza kusanidiwa kwa udhibiti wa mwongozo au otomatiki. Mabwawa ya rasilimali ya VMware yanaweza kuongezwa, kuondolewa, au kupangwa upya kwa urahisi. Ikiwa inataka, mabwawa ya rasilimali yanaweza kutengwa kati ya vitengo tofauti vya biashara. Ikiwa mzigo wa kazi kwenye mashine moja au zaidi za mtandaoni utabadilika sana, VMware DRS husambaza tena mashine pepe kwenye seva halisi. Ikiwa jumla ya mzigo wa kazi utapungua, baadhi ya seva halisi zinaweza kuondolewa mtandaoni kwa muda na mzigo wa kazi kuunganishwa."

Kwa nini kusawazisha kunahitajika?


Kwa maoni yetu, DRS ni kipengele cha lazima cha wingu, ingawa hii haimaanishi kwamba DRS lazima itumike daima na kila mahali. Kulingana na madhumuni na mahitaji ya wingu, kunaweza kuwa na mahitaji tofauti ya DRS na mbinu za kusawazisha. Kunaweza kuwa na hali ambapo kusawazisha hakuhitajiki kabisa. Au hata madhara.

Ili kuelewa vyema zaidi wapi na kwa wateja gani DRS inahitajika, hebu tuzingatie malengo na malengo yao. Clouds inaweza kugawanywa katika umma na binafsi. Hapa kuna tofauti kuu kati ya malengo haya ya clouds na wateja.

Mawingu ya kibinafsi / Wateja wa biashara kubwa
Mawingu ya umma / Biashara za kati na ndogo, watu

Kigezo kuu na malengo ya mwendeshaji
Kutoa huduma au bidhaa ya kuaminika
Kupunguza gharama za huduma katika mapambano katika soko la ushindani

Mahitaji ya huduma
Kuegemea katika viwango vyote na katika vipengele vyote vya mfumo

Utendaji wa uhakika

Zipe kipaumbele mashine pepe katika kategoria kadhaa 

Usalama wa habari na data halisi

SLA na usaidizi wa XNUMX/XNUMX
Upeo wa urahisi wa kupokea huduma

Huduma rahisi kiasi

Wajibu wa data ni wa mteja

Hakuna kipaumbele cha VM kinachohitajika

Usalama wa habari katika kiwango cha huduma za kawaida, wajibu kwa mteja

Kunaweza kuwa na makosa

Hakuna SLA, ubora haujahakikishwa

Msaada wa barua pepe

Hifadhi nakala sio lazima

Sifa za Mteja
Upana mpana sana wa maombi.

Maombi ya urithi yaliyorithiwa katika kampuni.

Usanifu tata wa kawaida kwa kila mteja.

Sheria za ushirika.

Programu inafanya kazi bila kuacha katika hali ya 7x24. 

Zana za kuhifadhi nakala popote ulipo.

Mzigo unaotabirika wa mzunguko wa mteja.
Programu za kawaida - kusawazisha mtandao, Apache, WEB, VPN, SQL

Programu inaweza kusimama kwa muda

Huruhusu usambazaji kiholela wa VM katika wingu

Hifadhi nakala ya mteja

Mzigo unaotabirika wa kitakwimu na idadi kubwa ya wateja.

Athari kwa usanifu
Geoclustering

Hifadhi ya kati au iliyosambazwa

IBS iliyohifadhiwa
Hifadhi ya data ya ndani kwenye nodi za hesabu

Kusawazisha Malengo
Hata usambazaji wa mzigo

Upeo wa mwitikio wa programu 

Muda wa chini wa kuchelewa kwa kusawazisha

Kusawazisha tu wakati ni muhimu

Kuleta baadhi ya vifaa kwa ajili ya matengenezo ya kuzuia
Kupunguza gharama za huduma na gharama za operator 

Inalemaza baadhi ya rasilimali ikiwa kuna mzigo mdogo

Kuokoa nishati

Kupunguza gharama za wafanyikazi

Tunajitolea wenyewe hitimisho zifuatazo:

Kwa mawingu ya kibinafsizinazotolewa kwa wateja wa kampuni kubwa, DRS inaweza kutumika chini ya vikwazo vifuatavyo:

  • usalama wa habari na kuzingatia sheria za ushirika wakati wa kusawazisha;
  • upatikanaji wa rasilimali za kutosha katika hifadhi katika tukio la ajali;
  • data ya mashine halisi iko kwenye mfumo wa hifadhi ya kati au iliyosambazwa;
  • usimamizi wa kushangaza, taratibu za kuhifadhi nakala na kusawazisha kwa wakati;
  • kusawazisha ndani ya jumla ya waandaji wateja;
  • kusawazisha tu wakati kuna usawa wa nguvu, uhamiaji wa VM wenye ufanisi zaidi na salama (baada ya yote, uhamiaji unaweza kushindwa);
  • kusawazisha mashine za mtandaoni "tulivu" (uhamiaji wa mashine "zenye kelele" unaweza kuchukua muda mrefu sana);
  • kusawazisha kwa kuzingatia "gharama" - mzigo kwenye mfumo wa uhifadhi na mtandao (na usanifu uliobinafsishwa kwa wateja wakubwa);
  • kusawazisha kwa kuzingatia sifa za tabia za kila VM;
  • Kusawazisha ni vyema kufanywa wakati wa saa zisizo za kazi (usiku, wikendi, likizo).

Kwa mawingu ya ummakutoa huduma kwa wateja wadogo, DRS inaweza kutumika mara nyingi zaidi, na uwezo wa juu:

  • kutokuwepo kwa vikwazo vya usalama wa habari na sheria za ushirika;
  • kusawazisha ndani ya wingu;
  • kusawazisha wakati wowote unaofaa;
  • kusawazisha VM yoyote;
  • kusawazisha mashine za kawaida za "kelele" (ili usisumbue wengine);
  • data ya mashine ya kawaida mara nyingi iko kwenye diski za ndani;
  • kwa kuzingatia utendaji wa wastani wa mifumo ya uhifadhi na mitandao (usanifu wa wingu ni umoja);
  • kusawazisha kulingana na sheria za jumla na takwimu za tabia za kituo cha data zinazopatikana.

Utata wa tatizo

Ugumu wa kusawazisha ni kwamba DRS lazima ifanye kazi na idadi kubwa ya sababu zisizo na uhakika:

  • tabia ya watumiaji wa kila moja ya mifumo ya habari ya mteja;
  • algorithms kwa uendeshaji wa seva za mfumo wa habari;
  • tabia ya seva za DBMS;
  • mzigo kwenye rasilimali za kompyuta, mifumo ya uhifadhi, mtandao;
  • mwingiliano wa seva na kila mmoja katika mapambano ya rasilimali za wingu.

Mzigo wa idadi kubwa ya seva za maombi ya kawaida na hifadhidata kwenye rasilimali za wingu hutokea kwa muda, matokeo yanaweza kujidhihirisha na kuingiliana na athari isiyoweza kutabirika kwa muda usiojulikana. Hata kudhibiti michakato rahisi (kwa mfano, kudhibiti injini, mfumo wa kupokanzwa maji nyumbani), mifumo ya kudhibiti kiotomatiki inahitaji kutumia ngumu. sawia-jumla-kutofautisha algorithms na maoni.

Usawazishaji wa Mzigo katika Openstack (Sehemu ya 2)

Kazi yetu ni maagizo mengi ya ukubwa ngumu zaidi, na kuna hatari kwamba mfumo hautaweza kusawazisha mzigo kwa maadili yaliyowekwa kwa wakati unaofaa, hata ikiwa hakuna mvuto wa nje kutoka kwa watumiaji.

Usawazishaji wa Mzigo katika Openstack (Sehemu ya 2)

Historia ya maendeleo yetu

Ili kutatua tatizo hili, tuliamua si kuanza kutoka mwanzo, lakini kujenga juu ya uzoefu uliopo, na kuanza kuingiliana na wataalamu wenye uzoefu katika eneo hili. Kwa bahati nzuri, uelewa wetu wa shida uliendana kabisa.

Hatua 1

Tulitumia mfumo kulingana na teknolojia ya mtandao wa neva na tukajaribu kuboresha rasilimali zetu kulingana na mfumo huo.

Nia ya hatua hii ilikuwa katika kujaribu teknolojia mpya, na umuhimu wake ulikuwa katika kutumia mbinu isiyo ya kawaida ya kutatua tatizo ambapo, mambo mengine yakiwa sawa, mbinu za kawaida zilikuwa zimechoka yenyewe.

Tulizindua mfumo, na kwa kweli tulianza kusawazisha. Ukubwa wa wingu wetu haukuturuhusu kupata matokeo ya matumaini yaliyoelezwa na wasanidi programu, lakini ilikuwa wazi kuwa kusawazisha kulikuwa kunafanya kazi.

Wakati huo huo, tulikuwa na mapungufu makubwa kabisa:

  • Ili kutoa mafunzo kwa mtandao wa neva, mashine pepe zinahitaji kufanya kazi bila mabadiliko makubwa kwa wiki au miezi.
  • Algorithm imeundwa kwa ajili ya uboreshaji kulingana na uchambuzi wa data ya awali ya "kihistoria".
  • Kufunza mtandao wa neva kunahitaji kiasi kikubwa cha data na rasilimali za kompyuta.
  • Uboreshaji na usawazishaji unaweza kufanywa mara chache - mara moja kila masaa machache, ambayo ni wazi haitoshi.

Hatua 2

Kwa kuwa hatukuridhika na hali ya mambo, tuliamua kurekebisha mfumo, na kufanya hivyo, jibu swali kuu - tunatengeneza kwa ajili ya nani?

Kwanza - kwa wateja wa kampuni. Hii ina maana kwamba tunahitaji mfumo unaofanya kazi haraka, wenye vikwazo hivyo vya ushirika vinavyorahisisha tu utekelezaji.

Swali la pili - unamaanisha nini kwa neno "mara moja"? Kama matokeo ya mjadala mfupi, tuliamua kwamba tunaweza kuanza na muda wa majibu wa dakika 5-10, ili mawimbi ya muda mfupi yasiweze kuanzisha mfumo katika resonance.

Swali la tatu - ni saizi gani ya nambari ya usawa ya seva ya kuchagua?
Suala hili lilitatuliwa lenyewe. Kwa kawaida, wateja hawafanyi mijumuisho ya seva kuwa kubwa sana, na hii inaambatana na mapendekezo ya makala ili kupunguza ujumlisho hadi seva 30-40.

Kwa kuongeza, kwa kugawanya bwawa la seva, tunarahisisha kazi ya algorithm ya kusawazisha.

Swali la nne - Je, mtandao wa neva unafaaje kwetu na mchakato wake mrefu wa kujifunza na kusawazisha nadra? Tuliamua kuiacha ili kupendelea algoriti rahisi za uendeshaji ili kupata matokeo kwa sekunde.

Usawazishaji wa Mzigo katika Openstack (Sehemu ya 2)

Maelezo ya mfumo unaotumia algorithms vile na hasara zake zinaweza kupatikana hapa

Tulitekeleza na kuzindua mfumo huu na kupokea matokeo ya kutia moyo - sasa inachanganua mzigo wa wingu mara kwa mara na kutoa mapendekezo ya kusongesha mashine pepe, ambayo kwa kiasi kikubwa ni sahihi. Hata sasa ni wazi kwamba tunaweza kufikia 10-15% ya kutolewa kwa rasilimali kwa mashine mpya za mtandaoni huku tukiboresha ubora wa kazi ya zilizopo.

Usawazishaji wa Mzigo katika Openstack (Sehemu ya 2)

Wakati kukosekana kwa usawa katika RAM au CPU kunapogunduliwa, mfumo hutoa amri kwa kipanga ratiba cha Tionix kutekeleza uhamishaji wa moja kwa moja wa mashine pepe zinazohitajika. Kama inavyoonekana kutoka kwa mfumo wa ufuatiliaji, mashine ya kawaida ilihamia kutoka kwa mwenyeji mmoja (juu) hadi mwingine (chini) na kuweka kumbukumbu kwenye seva ya juu (iliyoangaziwa kwenye miduara ya manjano), mtawaliwa ikiikalia kwenye ile ya chini (iliyoangaziwa kwa nyeupe. miduara).

Sasa tunajaribu kutathmini kwa usahihi zaidi ufanisi wa algorithm ya sasa na tunajaribu kupata makosa iwezekanavyo ndani yake.

Hatua 3

Inaweza kuonekana kuwa mtu anaweza kutuliza juu ya hili, subiri ufanisi uliothibitishwa na ufunge mada.
Lakini tunasukumwa kutekeleza hatua mpya kwa fursa zifuatazo dhahiri za uboreshaji

  1. Takwimu, kwa mfano, hapa ΠΈ hapa inaonyesha kuwa mifumo ya vichakataji viwili na vinne iko chini sana katika utendaji kuliko mifumo ya kichakataji kimoja. Hii inamaanisha kuwa watumiaji wote hupokea pato kidogo kutoka kwa CPU, RAM, SSD, LAN, FC iliyonunuliwa katika mifumo ya vichakataji vingi ikilinganishwa na ile ya kichakataji kimoja.
  2. Wapangaji rasilimali wenyewe wanaweza kuwa na makosa makubwa, hapa ni moja ya makala juu ya mada hii.
  3. Teknolojia zinazotolewa na Intel na AMD kwa ajili ya ufuatiliaji wa RAM na cache hufanya iwezekanavyo kujifunza tabia ya mashine za kawaida na kuziweka kwa njia ambayo majirani "wa kelele" hawaingilii na mashine za "kimya".
  4. Upanuzi wa seti ya vigezo (mtandao, mfumo wa kuhifadhi, kipaumbele cha mashine ya kawaida, gharama ya uhamiaji, utayari wake wa uhamiaji).

Katika jumla ya

Matokeo ya kazi yetu ya kuboresha algorithms ya kusawazisha ilikuwa hitimisho wazi kwamba kwa kutumia algorithms ya kisasa inawezekana kufikia ufanisi mkubwa wa rasilimali za kituo cha data (25-30%) na wakati huo huo kuboresha ubora wa huduma kwa wateja.

Algorithm kulingana na mitandao ya neural hakika ni suluhisho la kufurahisha, lakini ambalo linahitaji maendeleo zaidi, na kwa sababu ya mapungufu yaliyopo, haifai kwa kutatua shida ya aina hii kwa viwango vya kawaida vya mawingu ya kibinafsi. Wakati huo huo, algorithm ilionyesha matokeo mazuri katika mawingu ya umma ya ukubwa mkubwa.

Tutakuambia zaidi kuhusu uwezo wa wasindikaji, wapangaji ratiba, na kusawazisha kwa kiwango cha juu katika makala zifuatazo.

Chanzo: mapenzi.com

Kuongeza maoni