В puhuimme yrityksistämme käyttää Watcheria ja toimitimme testiraportin. Suoritamme ajoittain tällaisia testejä suuren yrityksen tai operaattoripilven tasapainotusta ja muita kriittisiä toimintoja varten.
Ratkaistavan ongelman monimutkaisuus saattaa vaatia useita artikkeleita projektimme kuvaamiseksi. Tänään julkaisemme sarjan toisen artikkelin, joka on omistettu virtuaalikoneiden tasapainottamiseen pilvessä.
Hieman terminologiaa
VmWare-yritys esitteli DRS-apuohjelman (Distributed Resource Scheduler) tasapainottamaan kehittämänsä ja tarjoamansa virtualisointiympäristön kuormitusta.
Kuten hän kirjoittaa
"VMware DRS (Distributed Resource Scheduler) on apuohjelma, joka tasapainottaa laskentakuormituksen käytettävissä olevien resurssien kanssa virtuaaliympäristössä. Apuohjelma on osa VMware Infrastructure -nimistä virtualisointipakettia.
VMware DRS:n avulla käyttäjät määrittävät säännöt fyysisten resurssien jakamisesta virtuaalikoneiden (VM) kesken. Apuohjelma voidaan konfiguroida manuaaliseen tai automaattiseen ohjaukseen. VMware-resurssivarantoja voidaan helposti lisätä, poistaa tai järjestää uudelleen. Haluttaessa resurssipoolit voidaan eristää eri liiketoimintayksiköiden välillä. Jos yhden tai useamman virtuaalikoneen työmäärä muuttuu dramaattisesti, VMware DRS jakaa virtuaalikoneet uudelleen fyysisten palvelimien kesken. Jos kokonaistyökuormitus pienenee, jotkin fyysiset palvelimet voidaan väliaikaisesti ottaa offline-tilaan ja työtaakka konsolidoitua."
Miksi tasapainotusta tarvitaan?
Mielestämme DRS on pakollinen pilviominaisuus, vaikka tämä ei tarkoita, että DRS:ää pitäisi käyttää aina ja kaikkialla. Pilven tarkoituksesta ja tarpeista riippuen DRS:lle ja tasapainotusmenetelmille voi olla erilaisia vaatimuksia. Saattaa olla tilanteita, joissa tasapainotusta ei tarvita ollenkaan. Tai jopa haitallista.
Ymmärtääksemme paremmin, missä ja mille asiakkaille DRS:ää tarvitaan, pohditaanpa heidän tavoitteitaan ja tavoitteitaan. Pilvet voidaan jakaa julkisiin ja yksityisiin. Tässä ovat tärkeimmät erot näiden pilvien ja asiakkaiden tavoitteiden välillä.
Yksityiset pilvet / Suuryritysasiakkaat
Julkiset pilvet / Keski- ja pienyritykset, ihmiset
Toimijan pääkriteeri ja tavoitteet
Luotettavan palvelun tai tuotteen tarjoaminen
Palvelujen kustannusten alentaminen taistelussa kilpailluilla markkinoilla
Palveluvaatimukset
Luotettavuus kaikilla tasoilla ja kaikissa järjestelmän elementeissä
Taattu suorituskyky
Priorisoi virtuaalikoneet useisiin luokkiin
Tieto- ja fyysinen tietoturva
Palvelutasosopimus ja XNUMX/XNUMX-tuki
Palvelun vastaanottaminen on mahdollisimman helppoa
Suhteellisen yksinkertaiset palvelut
Vastuu tiedoista on asiakkaalla
VM-priorisointia ei vaadita
Tietoturva peruspalvelujen tasolla, vastuu asiakkaalla
Saattaa olla vikoja
Ei SLA:ta, laatua ei taata
Sähköpostituki
Varmuuskopiointi ei ole välttämätön
Asiakasominaisuudet
Erittäin laaja valikoima sovelluksia.
Yritykselle perityt vanhat sovellukset.
Monimutkaiset mukautetut arkkitehtuurit jokaiselle asiakkaalle.
Affiniteettisäännöt.
Ohjelmisto toimii pysähtymättä 7x24-tilassa.
On-the-fly varmuuskopiointityökalut.
Ennustettava syklinen asiakaskuormitus.
Tyypillisiä sovelluksia – verkon tasapainotus, Apache, WEB, VPN, SQL
Sovellus voi pysähtyä hetkeksi
Mahdollistaa virtuaalikoneiden mielivaltaisen jakelun pilvessä
Asiakkaan varmuuskopio
Ennustettava tilastollisesti keskimääräinen kuormitus suurella asiakasmäärällä.
Vaikutukset arkkitehtuuriin
Geoklusterointi
Keskitetty tai hajautettu tallennustila
Varattu IBS
Paikallinen tietojen tallennus laskentasolmuissa
Tasapainottavat tavoitteet
Tasainen kuorman jakautuminen
Sovelluksen maksimaalinen vaste
Tasapainotuksen vähimmäisviiveaika
Tasapainottaa vain silloin, kun se on selvästi välttämätöntä
Joidenkin laitteiden tuominen ulos ennaltaehkäisevää huoltoa varten
Palvelu- ja operaattorikustannusten aleneminen
Joidenkin resurssien poistaminen käytöstä alhaisen kuormituksen vuoksi
Energiansäästö
Henkilöstökulujen vähentäminen
Teemme itsellemme seuraavat johtopäätökset:
Yksityisille pilvillesuurille yritysasiakkaille tarjottua DRS:ää voidaan käyttää seuraavin rajoituksin:
- tietoturva ja affiniteettisääntöjen huomioon ottaminen tasapainotettaessa;
- riittävien resurssien saatavuus onnettomuuden sattuessa;
- virtuaalikoneen tiedot sijaitsevat keskitetyssä tai hajautetussa tallennusjärjestelmässä;
- hallinto-, varmuuskopiointi- ja tasapainotusmenettelyjen aikaerottaminen;
- tasapainottaminen vain asiakaspalvelimien aggregaatin sisällä;
- tasapainottaminen vain, kun on vahva epätasapaino, tehokkaimmat ja turvallisimmat VM-siirrot (siirtyminen voi loppujen lopuksi epäonnistua);
- suhteellisen "hiljaisten" virtuaalikoneiden tasapainottaminen ("meluisten" virtuaalikoneiden siirto voi kestää hyvin kauan);
- tasapainotus ottaen huomioon "kustannukset" - tallennusjärjestelmän ja verkon kuormitus (räätälöidyt arkkitehtuurit suurille asiakkaille);
- tasapainottaminen ottaen huomioon kunkin virtuaalikoneen yksilölliset käyttäytymisominaisuudet;
- Tasapainotus tehdään mieluiten työajan ulkopuolella (iltaisin, viikonloppuisin, pyhäpäivinä).
Julkisille pilvilletarjoamalla palveluita pienille asiakkaille, DRS:ää voidaan käyttää paljon useammin kehittyneillä ominaisuuksilla:
- tietoturvarajoitusten ja affiniteettisääntöjen puuttuminen;
- tasapainottaminen pilven sisällä;
- tasapainottaminen milloin tahansa kohtuulliseen aikaan;
- minkä tahansa virtuaalikoneen tasapainottaminen;
- "meluisten" virtuaalikoneiden tasapainottaminen (jotta ei häiritä muita);
- virtuaalikoneen tiedot sijaitsevat usein paikallisilla levyillä;
- ottaen huomioon tallennusjärjestelmien ja -verkkojen keskimääräinen suorituskyky (pilviarkkitehtuuri on yhtenäinen);
- tasapainottaminen yleisten sääntöjen ja saatavilla olevien palvelinkeskusten käyttäytymistilastojen mukaisesti.
Ongelman monimutkaisuus
Tasapainotuksen vaikeus on se, että DRS:n on toimittava useiden epävarmien tekijöiden kanssa:
- kunkin asiakkaan tietojärjestelmän käyttäjien käyttäytyminen;
- Tietojärjestelmäpalvelimien toiminnan algoritmit;
- DBMS-palvelinten käyttäytyminen;
- laskentaresurssien, tallennusjärjestelmien, verkon kuormitus;
- palvelimien vuorovaikutus toistensa kanssa taistelussa pilviresursseista.
Suuren määrän virtuaalisia sovelluspalvelimia ja tietokantoja kuormitetaan pilviresursseihin ajan myötä, seuraukset voivat ilmetä ja mennä päällekkäin arvaamattomilla vaikutuksilla arvaamattoman ajan kuluessa. Jopa suhteellisen yksinkertaisten prosessien ohjaamiseksi (esimerkiksi moottorin, vedenlämmitysjärjestelmän ohjaamiseksi kotona), automaattisten ohjausjärjestelmien on käytettävä monimutkaisia algoritmit palautteen kera.
Tehtävämme on monta suuruusluokkaa monimutkaisempi, ja on olemassa riski, että järjestelmä ei pysty tasapainottamaan kuormitusta vakiintuneisiin arvoihin kohtuullisessa ajassa, vaikka käyttäjiltä ei olisikaan ulkoisia vaikutteita.
Kehityshistoriamme
Tämän ongelman ratkaisemiseksi päätimme olla aloittamatta tyhjästä, vaan rakentaa olemassa olevaan kokemukseen ja aloimme olla vuorovaikutuksessa asiantuntijoiden kanssa, joilla on kokemusta tällä alalla. Onneksi ymmärryksemme ongelmasta osui täysin yhteen.
Vaihe 1
Käytimme hermoverkkoteknologiaan perustuvaa järjestelmää ja yritimme optimoida resurssejamme sen pohjalta.
Tämän vaiheen mielenkiinnon kohteena oli uuden teknologian testaus ja sen merkitys oli epästandardin lähestymistavan soveltaminen ongelman ratkaisemiseen, jossa normaalit lähestymistavat olivat muiden asioiden jatkuessa käytännössä uupuneet.
Otimme järjestelmän käyttöön ja aloimme todella tasapainottaa. Pilvimme mittakaava ei antanut meille lupaa saada kehittäjien esittämiä optimistisia tuloksia, mutta oli selvää, että tasapainotus toimi.
Samaan aikaan meillä oli melko vakavia rajoituksia:
- Neuroverkon kouluttamiseksi virtuaalikoneiden on toimittava ilman merkittäviä muutoksia viikkoja tai kuukausia.
- Algoritmi on suunniteltu aikaisempien "historiallisten" tietojen analyysiin perustuvaan optimointiin.
- Neuroverkon kouluttaminen vaatii melko paljon dataa ja laskentaresursseja.
- Optimointia ja tasapainottamista voidaan tehdä suhteellisen harvoin - kerran muutaman tunnin välein, mikä ei selvästikään riitä.
Vaihe 2
Koska emme olleet tyytyväisiä asioiden tilaan, päätimme muuttaa järjestelmää ja vastata tähän pääkysymys – kenelle teemme sen?
Ensinnäkin - yritysasiakkaille. Tämä tarkoittaa, että tarvitsemme nopeasti toimivan järjestelmän sellaisin yritysrajoituksin, jotka vain yksinkertaistavat toteutusta.
Toinen kysymys - mitä tarkoitat sanalla "viikoimmin"? Lyhyen keskustelun tuloksena päätimme, että voisimme aloittaa 5–10 minuutin vasteajalla, jotta lyhytaikaiset ylitykset eivät vie järjestelmää resonanssiin.
Kolmas kysymys – minkä kokoinen tasapainotetusta palvelimien määrästä valita?
Tämä ongelma ratkesi itsestään. Tyypillisesti asiakkaat eivät tee palvelinryhmistä kovin suuria, ja tämä on yhdenmukainen artikkelin suositusten kanssa rajoittaa aggregaatiot 30–40 palvelimeen.
Lisäksi segmentoimalla palvelinpoolin yksinkertaistamme tasapainotusalgoritmin tehtävää.
Neljäs kysymys – kuinka sopiva neuroverkko on meille pitkällä oppimisprosessillaan ja harvinaisella tasapainotuksellaan? Päätimme luopua siitä ja käyttää yksinkertaisempia toimintaalgoritmeja saadaksemme tuloksia sekunneissa.
Selostus tällaisia algoritmeja käyttävästä järjestelmästä ja sen haitoista löytyy
Otimme ja lanseerasimme tämän järjestelmän ja saimme rohkaisevia tuloksia - nyt se analysoi säännöllisesti pilvikuormitusta ja antaa suosituksia virtuaalikoneiden siirtämiseen, jotka ovat suurelta osin oikein. Jo nyt on selvää, että voimme saavuttaa 10-15% resurssien vapautumisen uusille virtuaalikoneen parantamiseksi olemassa olevien virtuaalikoneiden työn laatua.
Kun RAM-muistissa tai suorittimessa havaitaan epätasapaino, järjestelmä antaa komennot Tionix-aikataululle suorittaakseen vaadittujen virtuaalikoneiden reaaliaikaisen siirron. Kuten valvontajärjestelmästä voidaan nähdä, virtuaalikone siirtyi yhdeltä (ylemmalta) toiselle (alemmalle) isännälle ja vapautti muistia ylemmästä isännästä (korostettu keltaisilla ympyröillä) ja miehitti sen vastaavasti alemmassa (korostettu valkoisella) ympyrät).
Nyt yritämme arvioida tarkemmin nykyisen algoritmin tehokkuutta ja yrittää löytää mahdollisia virheitä siinä.
Vaihe 3
Vaikuttaa siltä, että voidaan rauhoittua tähän, odottaa todistettua tehokkuutta ja sulkea aihe.
Mutta seuraavat ilmeiset optimointimahdollisuudet pakottavat meidät toteuttamaan uuden vaiheen
- Tilastot, esim. и osoittaa, että kahden ja neljän prosessorin järjestelmien suorituskyky on huomattavasti heikompi kuin yhden prosessorin järjestelmät. Tämä tarkoittaa, että kaikki käyttäjät saavat huomattavasti vähemmän ulostuloa moniprosessorijärjestelmissä ostetuista prosessoreista, RAM-muistista, SSD:stä, LAN:sta ja FC:stä verrattuna yhden prosessorin järjestelmiin.
- Resurssien ajoittajissa itsellään voi olla vakavia virheitä, tästä aiheesta.
- Intelin ja AMD:n tarjoamat tekniikat RAM:n ja välimuistin valvontaan mahdollistavat virtuaalikoneiden käyttäytymisen tutkimisen ja niiden sijoittamisen siten, että "meluiset" naapurit eivät häiritse "hiljaisia" virtuaalikoneita.
- Parametrijoukon laajentaminen (verkko, tallennusjärjestelmä, virtuaalikoneen prioriteetti, siirtokustannukset, sen valmius siirtoon).
Yhteensä
Tasapainotusalgoritmien kehittämistyömme tuloksena oli selkeä johtopäätös, että nykyaikaisilla algoritmeilla on mahdollista saavuttaa merkittävää konesalin resurssien optimointia (25-30 %) ja samalla parantaa asiakaspalvelun laatua.
Hermoverkkoihin perustuva algoritmi on varmasti mielenkiintoinen, mutta jatkokehittämistä vaativa ratkaisu, joka ei nykyisten rajoitusten vuoksi sovellu tämän kaltaisen ongelman ratkaisemiseen yksityisille pilville tyypillisillä volyymeillä. Samaan aikaan algoritmi osoitti hyviä tuloksia merkittävän kokoisissa julkisissa pilvissä.
Kerromme sinulle lisää prosessorien, aikataulujen ja korkean tason tasapainottamisen ominaisuuksista seuraavissa artikkeleissa.
Lähde: will.com