{"id":37745,"date":"2019-10-31T22:19:28","date_gmt":"2019-10-31T19:19:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/balansirovka-nagruzki-v-openstack-chast-2\/"},"modified":"2019-10-31T22:19:28","modified_gmt":"2019-10-31T19:19:28","slug":"balansirovka-nagruzki-v-openstack-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/balansirovka-nagruzki-v-openstack-chast-2","title":{"rendered":"Lastbalancering i Openstack (Del 2)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>I <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/rostelecom\/blog\/461483\/\">den forrige artikel<\/a><\/noindex> Vi har fortalt om fors\u00f8gene med at bruge Watcher og pr\u00e6senteret en testrapport. S\u00e5danne tests gennemf\u00f8rer vi j\u00e6vnligt for at balancere og andre kritiske funktioner af store corporate- eller operat\u00f8rscloud.<\/p>\n<p>Den h\u00f8je kompleksitet i opgaven kan kr\u00e6ve flere artikler til at beskrive vores projekt. I dag offentligg\u00f8r vi den anden artikel i r\u00e6kken, der handler om balancering af virtuelle maskiner i skyen. <\/p>\n<h3>Lidt terminologi<\/h3>\n<p>\nVmWare har introduceret DRS (Distributed Resource Scheduler) v\u00e6rkt\u00f8jet til belastningsbalancering i den af dem udviklede og tilbudte virtualiseringsmilj\u00f8. <\/p>\n<p>Som n\u00e6vnt p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/searchvmware.techtarget.com\/definition\/VMware-DRS\">searchvmware.techtarget.com\/definition\/VMware-DRS<\/a><\/noindex><br \/>\n<i>\u201cVMware DRS (Distributed Resource Scheduler) er et v\u00e6rkt\u00f8j, der balancerer beregningsoverlast med de tilg\u00e6ngelige ressourcer i et virtuelt milj\u00f8. V\u00e6rkt\u00f8jet er en del af et virtualiseringspakke kaldet VMware Infrastructure.<\/p>\n<p>Med VMware DRS definerer brugerne regler for distribution af fysiske ressourcer mellem virtuelle maskiner (VM). V\u00e6rkt\u00f8jet kan konfigureres til manuel eller automatisk administration. VMware-ressourcepuljer kan let tilf\u00f8jes, fjernes eller omorganiseres. Hvis \u00f8nskes, kan ressourcepuljerne isoleres mellem forskellige forretningsenheder. Hvis arbejdsbyrden p\u00e5 en eller flere virtuelle maskiner \u00e6ndrer sig drastisk, omfordeler VMware DRS de virtuelle maskiner mellem de fysiske servere. Hvis den samlede arbejdsbyrde mindskes, kan nogle fysiske servere midlertidigt slukkes, og arbejdsbyrden kan konsolideres.<\/i><\/p>\n<h3>Hvorfor er balancering n\u00f8dvendig?<\/h3>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nEfter vores mening er DRS en uundg\u00e5elig funktion i skyen, selvom det ikke betyder, at DRS skal bruges altid og overalt. Afh\u00e6ngig af form\u00e5let og behovene i skyen kan der v\u00e6re forskellige krav til DRS og balanceringsmetoder. Der kan v\u00e6re situationer, hvor balancering overhovedet ikke er n\u00f8dvendig. Eller endda skadelig.<\/p>\n<p>For bedre at forst\u00e5, hvor og for hvilke kunder DRS er n\u00f8dvendigt, lad os overveje deres m\u00e5l og opgaver. Skydes kan opdeles i offentlige og private. Her er de vigtigste forskelle mellem disse skyer og kundernes m\u00e5l.<\/p>\n<p>Private skyer \/ Store virksomhedskunder<br \/>\nOffentlige skyer \/ Sm\u00e5 og mellemstore virksomheder, mennesker<\/p>\n<p>Hovedkriterium og m\u00e5l for operat\u00f8ren<br \/>\nAt levere en p\u00e5lidelig service eller produkt<br \/>\nReduktion af serviceomkostninger i konkurrencen p\u00e5 markedet<\/p>\n<p>Krav til tjenesten<br \/>\nP\u00e5lidelighed p\u00e5 alle niveauer og i alle systemelementer<\/p>\n<p>Garanteret ydeevne<\/p>\n<p>Prioritering af virtuelle maskiner i flere kategorier\u00a0<\/p>\n<p>Informations- og fysisk datasikkerhed<\/p>\n<p>SLA og d\u00f8gnsupport<br \/>\nMaksimal enkelhed i modtagelse af tjenesten<\/p>\n<p>Relativt enkle tjenester<\/p>\n<p>Ansvarsomr\u00e5der for data ligger hos kunden<\/p>\n<p>Prioritering af VM er ikke p\u00e5kr\u00e6vet<\/p>\n<p>Informationssikkerhed p\u00e5 niveau med standardtjenester, ansvar ligger hos kunden<\/p>\n<p>Der kan forekomme nedbrud<\/p>\n<p>Ingen SLA, kvaliteten er ikke garanteret<\/p>\n<p>Support via e-mail<\/p>\n<p>Backup er ikke obligatorisk<\/p>\n<p>Kundeegenskaber<br \/>\nMeget bredt spektrum af applikationer.<\/p>\n<p>Legacy applikationer, arvet i virksomheden.<\/p>\n<p>Kompleks tilpasset arkitektur for hver kunde.<\/p>\n<p>Affinity-regler.<\/p>\n<p>Software fungerer uden afbrydelse i 7x24.\u00a0<\/p>\n<p>Backup-v\u00e6rkt\u00f8jer \"on-the-fly\".<\/p>\n<p>Forudsigelig cyklisk belastning for kunden.<br \/>\nStandard applikationer \u2013 netv\u00e6rksbalancering, Apache, WEB, VPN, SQL<\/p>\n<p>Appen kan stoppe i en kort periode<\/p>\n<p>Belastningsfordeling af VM i skyen er tilladt<\/p>\n<p>Backup udf\u00f8res af kunden<\/p>\n<p>Forudsigelig belastning statistisk gennemsnitligt med mange kunder.<\/p>\n<p>Konsekvenser for arkitekturen<br \/>\nGeoklustering<\/p>\n<p>Centraliseret eller distribueret SAN<\/p>\n<p>Reservede SRK<br \/>\nLokal datalagring p\u00e5 computermoduler<\/p>\n<p>Balanceringsm\u00e5l<br \/>\nJ\u00e6vn fordeling af belastning<\/p>\n<p>Maksimal responsivitet af applikationer\u00a0<\/p>\n<p>Minimal forsinkelse ved balancering<\/p>\n<p>Balancering kun i tilf\u00e6lde af \u00e5benbare behov<\/p>\n<p>Uds\u00e6ttelse af dele af udstyret til forebyggende vedligeholdelse<br \/>\nReduktion af omkostninger ved tjenesten og operat\u00f8rens omkostninger\u00a0<\/p>\n<p>Deaktivering af dele af ressourcerne ved lav belastning<\/p>\n<p>Energibesparelse<\/p>\n<p>Nedbringelse af personaleomkostninger<\/p>\n<h3> Vi drager f\u00f8lgende konklusioner:<\/h3>\n<p>\n<b>For private skyer<\/b>, der leveres til store virksomhedskunder, kan DRS anvendes med forbehold for begr\u00e6nsninger:<\/p>\n<ul>\n<li>informationssikkerhed og hensyntagen til affinity-regler ved balancering;<\/li>\n<li>tilstedev\u00e6relse af tilstr\u00e6kkelige ressourcer i reserve i tilf\u00e6lde af uheld;<\/li>\n<li>data fra virtuelle maskiner er placeret p\u00e5 en centraliseret eller distribueret SAN;<\/li>\n<li>spredning af administrative, backup- og belastningsbalanceringsprocedurer over tid;<\/li>\n<li>belastningsbalancering kun inden for aggregatet af kundens v\u00e6rter;<\/li>\n<li>belastningsbalancering kun ved st\u00e6rk ubalance, de mest effektive og sikre VM-migrationer (for migrationen kan ende med at v\u00e6re mislykket);<\/li>\n<li>belastningsbalancering i forhold til 'stille' virtuelle maskiner (migration af 'st\u00f8jende' virtuelle maskiner kan tage meget lang tid);<\/li>\n<li>belastningsbalancering med hensyn til 'omkostninger' \u2014 belastning p\u00e5 lagringssystem og netv\u00e6rk (ved tilpassede arkitekturer for store kunder);<\/li>\n<li>belastningsbalancering med hensyn til de individuelle adf\u00e6rdsm\u00f8nstre for hver VM;<\/li>\n<li>belastningsbalancering b\u00f8r helst ske uden for arbejdstid (om natten, i weekenden, p\u00e5 helligdage).<\/li>\n<\/ul>\n<p>\n<b>For offentlige skyer<\/b>, der leverer tjenester til sm\u00e5 kunder, kan DRS anvendes langt oftere, med udvidede muligheder:<\/p>\n<ul>\n<li>mangel p\u00e5 restriktioner for informationssikkerhed og affinitetsregler; <\/li>\n<li>belastningsbalancering inden for skyen;<\/li>\n<li>belastningsbalancering til enhver rimelig tid;<\/li>\n<li>belastningsbalancering af enhver VM; <\/li>\n<li>belastningsbalancering af 'st\u00f8jende' virtuelle maskiner (for ikke at forstyrre de andre); <\/li>\n<li>data for virtuelle maskiner findes ofte p\u00e5 lokale diske;<\/li>\n<li>overvejelse af den gennemsnitlige ydeevne for lagringssystemer og netv\u00e6rk (skyarkitekturen er ensartet);<\/li>\n<li>belastningsbalancering baseret p\u00e5 generelle regler og eksisterende adf\u00e6rdsm\u00f8nstre for datacentre.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Problemernes kompleksitet<\/h2>\n<p>\nKompleksiteten ved belastningsbalancering ligger i, at DRS skal arbejde med mange ubestemte faktorer:<\/p>\n<ul>\n<li>brugernes adf\u00e6rd i hver af kundens informationssystemer;<\/li>\n<li>algoritmerne for informationssystemernes servere;<\/li>\n<li>adf\u00e6rden for databaserne servere;<\/li>\n<li>belastningen p\u00e5 beregningsressourcer, lagringssystemer, netv\u00e6rk; <\/li>\n<li>interaktionen mellem serverne i kampen om skyens ressourcer.<\/li>\n<\/ul>\n<p>\nBelastningen fra et stort antal virtuelle applikations- og databaservere p\u00e5 skyens ressourcer opst\u00e5r over tid, og konsekvenserne kan manifestere sig og overlappe hinanden med uforudsigelige effekter over uforudsigelig tid. Selv for styring af forholdsvis simple processer (for eksempel til styring af en motor, et vandopvarmningssystem i et hus) skal automatiserede regulatoriske systemer bruge komplekse <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%9F%D0%98%D0%94-%D1%80%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%82%D0%BE%D1%80\">proportional-integral-derivative <\/a><\/noindex>algoritmer med feedback. <\/p>\n<p><img decoding=\"async\" alt=\"Lastbalancering i Openstack (Del 2)\" src=\"\/wp-content\/uploads\/2019\/09\/5270ddb943db9b4921a887e67c4f2a8f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVores opgave er mange gange mere kompleks, og der er en risiko for, at systemet ikke vil kunne gennemf\u00f8re belastningsbalanceringen til etablerede v\u00e6rdier inden for rimelig tid, selvom der ikke opst\u00e5r eksterne p\u00e5virkninger fra brugerne. <\/p>\n<p><img decoding=\"async\" alt=\"Lastbalancering i Openstack (Del 2)\" src=\"\/wp-content\/uploads\/2019\/09\/5214b3af233e7c718fd40e6336472903.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Historien om vores udviklinger<\/h2>\n<p>\nFor at l\u00f8se dette problem besluttede vi os for ikke at begynde fra bunden, men at bygge videre p\u00e5 eksisterende erfaringer og begyndte at samarbejde med specialister, der har erfaring inden for dette omr\u00e5de. Heldigvis var vi fuldst\u00e6ndigt enige om problemstillingen. <\/p>\n<h3>Trin 1<\/h3>\n<p>\nVi brugte et system baseret p\u00e5 neural netv\u00e6rksteknologi og fors\u00f8gte at optimere vores ressourcer p\u00e5 den baggrund.<\/p>\n<p>Dette trin var interessant, da det indebar afpr\u00f8vning af en ny teknologi, og dets betydning l\u00e5 i anvendelsen af en ukonventionel tilgang til l\u00f8sning af opgaven, hvor standardmetoder i n\u00e6sten identiske vilk\u00e5r n\u00e6sten var udt\u00f8mt.<\/p>\n<p>Vi startede systemet, og vi oplevede faktisk belastningsbalancering. Omfanget af vores sky tillod os ikke at f\u00e5 de optimistiske resultater, som udviklerne havde angivet, men det var tydeligt, at balanceringen fungerede. <\/p>\n<p>Vi havde dog nogle ret alvorlige begr\u00e6nsninger:<\/p>\n<ul>\n<li>For at tr\u00e6ne det neurale netv\u00e6rk er det n\u00f8dvendigt, at de virtuelle maskiner fungerer uden v\u00e6sentlige \u00e6ndringer i flere uger eller m\u00e5neder.<\/li>\n<li>Algoritmen er designet til at optimere baseret p\u00e5 analyse af tidligere 'historiske' data.<\/li>\n<li>For at tr\u00e6ne det neurale netv\u00e6rk kr\u00e6ves der en ganske stor m\u00e6ngde data og beregningsressourcer. <\/li>\n<li>Optimering og belastningsbalancering kan g\u00f8res relativt sj\u00e6ldent \u2013 en gang hver par timer, hvilket \u00e5benlyst ikke er tilstr\u00e6kkeligt. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Trin 2<\/h3>\n<p>\nDa vi ikke var tilfredse med situationen, besluttede vi at modificere systemet og for dette at besvare <b>det hovedsp\u00f8rgsm\u00e5l<\/b> \u2013 hvem laver vi det til?<\/p>\n<p>F\u00f8rst og fremmest \u2013 til virksomhedskunder. Det betyder, at vi har brug for et system, der fungerer hurtigt, med de virksomhedsm\u00e6ssige begr\u00e6nsninger, der kun forenkler implementeringen.<\/p>\n<p><b>Det andet sp\u00f8rgsm\u00e5l<\/b> \u2013 hvad mener vi med 'hurtigt'? Efter en kort debat besluttede vi, at vi kunne tage udgangspunkt i en reaktionstid p\u00e5 5 \u2013 10 minutter, s\u00e5 kortvarige udsving ikke bringer systemet i resonans.<\/p>\n<p><b>Det tredje sp\u00f8rgsm\u00e5l<\/b> \u2013 hvilken st\u00f8rrelse af de balancerede servere skal v\u00e6lges?<br \/>\nDette sp\u00f8rgsm\u00e5l l\u00f8ste sig selv. Som regel g\u00f8r kunderne ikke serveraggregater meget store, og det er i overensstemmelse med anbefalingerne fra artiklen om at begr\u00e6nse aggregater til 30-40 servere.<\/p>\n<p>Desuden, ved at segmentere serverpuljen, forenkler vi opgaven for balanceringsalgoritmen.<\/p>\n<p><b>Det fjerde sp\u00f8rgsm\u00e5l<\/b> \u2013 hvor passende er det for os at bruge et neuralt netv\u00e6rk med sin lange l\u00e6ringsproces og sj\u00e6ldne balanceringer? Vi har besluttet at opgive det til fordel for mere enkle operationelle algoritmer for at opn\u00e5 resultater p\u00e5 sekunder. <\/p>\n<p><img decoding=\"async\" alt=\"Lastbalancering i Openstack (Del 2)\" src=\"\/wp-content\/uploads\/2019\/09\/73fb927b304ca5d61090a5c045568931.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeskrivelse af systemet, der bruger s\u00e5danne algoritmer og dets mangler, kan findes her <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/416391\/\">her <\/a><\/noindex><\/p>\n<p>Vi har implementeret og lanceret dette system og f\u00e5et opmuntrende resultater \u2013 det analyserer regelm\u00e6ssigt belastningen i skyen og giver anbefalinger om placering af virtuelle maskiner, som i betydelig grad viser sig at v\u00e6re korrekte. Selv nu er det tydeligt, at vi kan opn\u00e5 en 10-15% frigivelse af ressourcer til nye virtuelle maskiner med forbedret kvalitet p\u00e5 de eksisterende.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/ie\/ky\/wa\/iekywainupnidp_73j55hc1dbnw.png\"><img decoding=\"async\" alt=\"Lastbalancering i Openstack (Del 2)\" src=\"\/wp-content\/uploads\/2019\/09\/f1f0919ae653dc9b8c78b4d32d839313.png\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>N\u00e5r der opdages ubalance i RAM eller CPU, giver systemet kommandoer til Tionix-planl\u00e6ggeren om at udf\u00f8re live-migreringen af de kr\u00e6vede virtuelle maskiner. Som det fremg\u00e5r af overv\u00e5gningssystemet, er den virtuelle maskine flyttet fra en (\u00f8verste) host til en anden (nederste) host og har frigivet hukommelse p\u00e5 den \u00f8verste host (markeret med gule cirkler) og optaget den p\u00e5 den nederste (markeret med hvide cirkler).<\/p>\n<p>Vi pr\u00f8ver nu at vurdere effektiviteten af den nuv\u00e6rende algoritme mere pr\u00e6cist og fors\u00f8ger at finde mulige fejl i den.<\/p>\n<h3>Trin 3<\/h3>\n<p>\nDet kunne synes, at vi kunne slappe af her, vente p\u00e5 dokumenterede resultater og afslutte emnet.<br \/>\nMen vi bliver presset til at gennemf\u00f8re et nyt trin af de tydelige muligheder for optimering,<\/p>\n<ol>\n<li>Statistikker, for eksempel, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cpubenchmark.net\/multi_cpu.html\">her <\/a><\/noindex>og <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cpubenchmark.net\/high_end_cpus.html\">her <\/a><\/noindex>viser, at to- og fireprocessor-systemer er v\u00e6sentligt langsommere end enprocessor-systemer. Dette betyder, at alle brugere f\u00e5r en betydeligt lavere ydelse af de CPU, RAM, SSD, LAN, FC, der er k\u00f8bt i multiprocessorsystemer, sammenlignet med enprocessorsystemer. <\/li>\n<li>Selve ressourceplanl\u00e6ggerne kan have alvorlige fejl, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ece.ubc.ca\/~sasha\/papers\/eurosys16-final29.pdf\">her er en af artiklerne<\/a><\/noindex> om dette emne. <\/li>\n<li>De teknologier, som Intel og AMD tilbyder til overv\u00e5gning af RAM og cache, muligg\u00f8r studier af adf\u00e6rden hos virtuelle maskiner og placering af dem, s\u00e5 \"st\u00f8jsende\" naboer ikke forstyrrer de \"rolige\" virtuelle maskiner. <\/li>\n<li>Udvidelse af parametre (netv\u00e6rk, lager, prioritet for den virtuelle maskine, omkostninger ved migration, dens beredskab til migration).<\/li>\n<\/ol>\n<p><\/p>\n<h2>I alt<\/h2>\n<p>\nResultatet af vores arbejde med at forbedre balanceringsalgoritmerne er en entydig konklusion om, at nutidige algoritmer kan f\u00f8re til betydelige ressourceoptimeringer (25-30%) i datacentre og samtidig forbedre kvaliteten af kundeservice.<\/p>\n<p>Algorit\u00admen, der baserer sig p\u00e5 neurale netv\u00e6rk, er uden tvivl interessant, men kr\u00e6ver yderligere udvikling og er p\u00e5 grund af eksisterende begr\u00e6nsninger ikke velegnet til at l\u00f8se denne type opgaver i de m\u00e6ngder, der er typiske for private skyer. I de offentlige skyer af betydelig st\u00f8rrelse har algoritmen dog vist gode resultater.<\/p>\n<p>Vi vil uddybe mulighederne for processorer, planl\u00e6ggere og h\u00f8j-niveau belastningsbalancering i de kommende artikler.<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/rostelecom\/blog\/465715\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u043e\u043f\u044b\u0442\u043a\u0430\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Watcher \u0438 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\u0438 \u043e\u0442\u0447\u0435\u0442 \u0438\u0441\u043f\u044b\u0442\u0430\u043d\u0438\u0439. \u0422\u0430\u043a\u0438\u0435 \u0438\u0441\u043f\u044b\u0442\u0430\u043d\u0438\u044f \u043c\u044b \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u043c \u0434\u043b\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u043a\u0438 \u0438 \u0434\u0440\u0443\u0433\u0438\u0445 \u043a\u0440\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0444\u0443\u043d\u043a\u0446\u0438\u0439 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u043e\u0433\u043e \u0438\u043b\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0441\u043a\u043e\u0433\u043e \u043e\u0431\u043b\u0430\u043a\u0430. \u0412\u044b\u0441\u043e\u043a\u0430\u044f \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0440\u0435\u0448\u0430\u0435\u043c\u043e\u0439 \u0437\u0430\u0434\u0430\u0447\u0438, \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043f\u043e\u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 \u0434\u043b\u044f \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c \u0432\u0442\u043e\u0440\u0443\u044e \u0441\u0442\u0430\u0442\u044c\u044e \u0446\u0438\u043a\u043b\u0430, \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u043d\u0443\u044e \u0431\u0430\u043b\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u043a\u0435 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0432 \u043e\u0431\u043b\u0430\u043a\u0435. \u041d\u0435\u043c\u043d\u043e\u0433\u043e \u0442\u0435\u0440\u043c\u0438\u043d\u043e\u043b\u043e\u0433\u0438\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28330,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37745","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u043e\u043f\u044b\u0442\u043a\u0430\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Watcher \u0438 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\u0438 \u043e\u0442\u0447\u0435\u0442 \u0438\u0441\u043f\u044b\u0442\u0430\u043d\u0438\u0439.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/balansirovka-nagruzki-v-openstack-chast-2\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0411\u0430\u043b\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u043a\u0430 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u0432 Openstack (\u0427\u0430\u0441\u0442\u044c 2) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u043e\u043f\u044b\u0442\u043a\u0430\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Watcher \u0438 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\u0438 \u043e\u0442\u0447\u0435\u0442 \u0438\u0441\u043f\u044b\u0442\u0430\u043d\u0438\u0439.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/balansirovka-nagruzki-v-openstack-chast-2\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:19:28+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:19:28+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Belastningsbalancering i Openstack (Del 2) | ProHoster","description":"I den tidligere artikel fortalte vi om vores fors\u00f8g med at anvende Watcher og pr\u00e6senterede testrapporten.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/balansirovka-nagruzki-v-openstack-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0411\u0430\u043b\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u043a\u0430 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u0432 Openstack (\u0427\u0430\u0441\u0442\u044c 2) | ProHoster","og:description":"\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u043e\u043f\u044b\u0442\u043a\u0430\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Watcher \u0438 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b\u0438 \u043e\u0442\u0447\u0435\u0442 \u0438\u0441\u043f\u044b\u0442\u0430\u043d\u0438\u0439.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/balansirovka-nagruzki-v-openstack-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:19:28+00:00","article:modified_time":"2019-10-31T19:19:28+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37745","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 19:08:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:21:23","updated":"2026-01-23 19:08:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37745","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=37745"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/37745\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28330"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=37745"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=37745"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=37745"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}