Lastbalansering i OpenStack

I stora molnsystem är frågan om automatisk belastningsbalansering eller justering av belastningen på datorkällor särskilt viktig. Detta problem har också uppmärksammats av Tionix (utvecklare och operatör av molntjänster, en del av Rostelecom-gruppen).

Och eftersom vår huvudsakliga utvecklingsplattform är OpenStack, och vi, precis som alla andra, är lata, beslutades det att välja en färdig modul som redan finns i plattformen. Vårt val föll på Watcher, som vi beslutade att använda för våra behov.

Till att börja med, låt oss gå igenom termer och definitioner.

Termer och definitioner

Syftet — är det människoläsbara, observerbara och mätbara slutresultatet som ska uppnås. För att nå varje mål finns det en eller flera strategier. En strategi är en implementering av en algoritm som kan hitta en lösning för det givna målet.

Handling (Action) — är en grundläggande uppgift som förändrar det nuvarande tillståndet för den målinriktade hanterade resursen i OpenStack-klustret, såsom: migrering av en virtuell maskin (migration), ändring av strömstatus för en nod (change_node_power_state), ändring av status för nova-tjänsten (change_nova_service_state), ändring av flavor (resize), registrering av nop-meddelande (nop), ingen aktivitet under en viss tidsperiod — paus (sleep), överföring av en disk (volume_migrate).

Handlingsplan (Action Plan) — är ett specifikt flöde av åtgärder som utförs i en viss ordning för att uppnå ett specifikt mål. Handlingsplanen innehåller också en bedömning av den globala effektiviteten med en uppsättning prestationsmått. Handlingsplanen genereras av Watcher efter en framgångsrik revision, där den använda strategin hittar en lösning för att nå målet. Handlingsplanen består av en lista över sekventiella handlingar.

Revision (Audit) — är en begäran om att optimera klustret. Optimering utförs för att nå ett mål i detta kluster. För varje framgångsrik revision genererar Watcher en handlingsplan.

Revisionsområde (Audit Scope) — detta är en uppsättning resurser där en granskning utförs (tillgänglighetszon(er), nodaggregatorer, individuella beräkningsnoder eller lagringsnoder, etc.). Granskningsområdet definieras i varje mall. Om granskningsområdet inte anges, granskas hela klustret.

Granskningsmall (Audit Template) — en sparad uppsättning inställningar för att köra en granskning. Mallar är nödvändiga för att upprepade gånger köra granskningar med samma inställningar. Mallen måste innehålla granskningsmålet; om strategier inte anges, väljs de mest lämpliga bland de befintliga strategierna.

Kluster (Cluster) — detta är en uppsättning fysiska maskiner som tillhandahåller beräkningsresurser, lagringsresurser och nätverksresurser och hanteras av samma OpenStack-kontrollnod.

Kluster datamodell (Cluster Data Model, CDM) — detta är en logisk representation av det aktuella tillståndet och topologin av resurser som hanteras av klustret.

Effektivitetsindikator (Efficacy Indicator) — en indikator som visar hur väl en lösning, skapad med hjälp av denna strategi, utförs. Effektivitetsindikatorer är specifika för ett visst mål och används vanligtvis för att beräkna den globala effektiviteten av den slutliga handlingsplanen.

Effektivitets-specifikation (Efficacy Specification) — detta är en uppsättning specifika egenskaper kopplade till varje mål, som definierar olika effektivitetsindikatorer som strategin som säkerställer uppfyllandet av målet måste uppfylla i sin lösning. Varje lösning som föreslås av strategin kommer att kontrolleras mot specifikationen innan dess globala effektivitet beräknas.

“Räknande” motor (Scoring Engine) — detta är en körbar fil som har tydligt definierade ingångar, tydligt definierade utgångar och utför en rent matematisk uppgift. Därmed är beräkningen oberoende av den miljö där den körs — den kommer att ge samma resultat överallt.

Watcher planerare (Watcher Planner) — del av beslutsfattande mekanismen Watcher. Denna modul tar emot en uppsättning åtgärder som genereras av strategin och skapar en arbetsflödesplan som definierar hur dessa olika åtgärder planeras tidsmässigt och för varje åtgärd, vilka förutsättningar som gäller.

Mål och strategier för Watcher

Syftet
Strategier

Dummy-mål
Dummy-strategi 

Dummy-strategi med exempel på bedömningsmotorer

Dummy-strategi med resize

Spara energi
Strategi för att spara energi

Serverkonsolidering
Grundläggande offline serverkonsolidering

VM arbetsbelastningskonsolideringsstrategi

Arbetsbelastningsbalansering
Arbetsbelastningsbalanseringsstrategi vid migrering

Strategi för balansering av lagringskapacitet

Stabilisering av arbetsbelastning

Bullerig granne
Bullerig granne

Termisk optimering
Strategi baserad på utgångstemperatur

Luftflödesoptimering
Strategi för enhetlig luftflödesmigration

Hårdvaruunderhåll
Zonmigrering

Oklassificerat
Ställare

Dummy-mål — ett reservmål som används för testning (reserved goal that is used for testing purposes).

Relaterade strategier: Dummy-strategi, Dummy-strategi med exempel på bedömningsmotorer och Dummy-strategi med resize. Dummy-strategi är en dummy-strategi som används för integrationstester via Tempest. Denna strategi ger ingen användbar optimering, dess enda syfte är att köra Tempest-tester.

Dummy-strategi med exempel på bedömningsmotorer — strategin liknar den föregående, men skiljer sig endast genom att den använder ett exempel på en "bedömningsmotor" som räknar med hjälp av metoder för maskininlärning.

Dummy-strategi med resize — strategin liknar den föregående, men skiljer sig endast genom att den använder förändringar av flavor (migrering och resize).

Används inte i produktion.

Spara energi — att minimera energiförbrukningen. Strategin för detta mål, Spara energi, tillsammans med strategin för VM-arbetsbelastningskonsolidering (Serverkonsolidering) kan utföra funktioner för dynamisk energihantering (DPM) som sparar elektricitet genom dynamisk konsolidering av arbetsbelastningar även under perioder av låg resursbelastning: virtuella maskiner flyttas till färre noder, och onödiga noder stängs av. Efter konsolideringen föreslår strategin en lösning för att sätta på/av noder baserat på angivna parametrar: "min_free_hosts_num" — antal lediga aktiva noder som väntar på belastning, och "free_used_percent" — procentandel av lediga aktiva noder i förhållande till antalet noder som är belagda av maskiner. För att strategin ska fungera måste Ironic vara aktiverat och konfigurerat för att hantera strömförsörjningen på noder.

Parametrar för strategin

parameter
typ
standard
beskrivning

fri_använd procent
Antal
10.0
förhållandet mellan antalet lediga beräkningsnoder och antalet beräkningsnoder med virtuella maskiner

min_ledig_noder_num
Int
1
minimalt antal lediga beräkningsnoder

Det måste finnas minst två noder i molnet. Den använda metoden är att ändra nodens strömstatus (change_node_power_state). Strategin för insamling av mätvärden kräver inte något.

Serverkoncentration - minimera antalet beräkningsnoder (koncentration). Har två strategier: Basic Offline Server Consolidation och VM Workload Consolidation Strategy.

Strategin Basic Offline Server Consolidation minimerar det totala antalet använda servrar och minimerar också antalet migrationer.

Den grundläggande strategin kräver följande mätvärden:

mätvärde
tjänst
plugins
kommentar

compute.node.cpu.percent
ceilometer
none
 

cpu_util
ceilometer
none
 

Strategi-parametrar: migration_attempts - antal kombinationer för att söka efter potentiella kandidater för avstängning (standard, 0, inga begränsningar), period - tidsintervallet i sekunder för att få statisk aggregering från datakälla av mätvärdet (standard, 700).

Använda metoder: migration, ändra status för nova-tjänsten (change_nova_service_state).

Strategin för VM Workload Consolidation Strategy är baserad på en heuristisk algoritm för första bästa valet (first-fit), som fokuserar på mätt CPU-belastning och strävar efter att minimera noder som har antingen för hög eller för låg belastning med hänsyn till resurskapacitetsbegränsningar. Denna strategi ger en lösning som leder till mer effektiv resursanvändning i klustret, genom att använda följande fyra steg:

1. Avlastningsfas - hantering av överutnyttjade resurser;
2. Konsolideringsfas - hantering av underutnyttjade resurser;
3. Optimering av lösning - minska antalet migrationer;
4. Avstängning av oanvända beräkningsnoder.

Strategin kräver följande mätvärden:

mätvärde
tjänst
plugins
kommentar

minne
ceilometer
none
 

disk.root.size
ceilometer
none
 

Följande mätvärden är inte obligatoriska, men ökar noggrannheten i strategin om de är tillgängliga:

mätvärde
tjänst
plugins
kommentar

memory.resident
ceilometer
none
 

cpu_util
ceilometer
none
 

Strategi-parametrar: period - tidsintervallet i sekunder för att få statisk aggregering från datakälla av mätvärdet (standard, 3600).

Använder samma metoder som den föregående strategin. Mer information här.

Arbetsbelastningsbalansering — balansera arbetsbelastningen mellan beräkningsnoder. Målet har tre strategier: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.

Workload Balance Migration Strategy initierar migreringar av virtuella maskiner baserat på arbetsbelastningen på noderna. Beslutet om att flytta tas varje gång CPU- eller RAM-användningen på en nod överskrider den angivna gränsen. Den flyttade virtuella maskinen bör närma noden till den genomsnittliga arbetsbelastningen för alla noder.

Krav

• Användning av fysiska processorer;
• Minst två fysiska beräkningsnoder;
• Installerad och konfigurerad komponent Ceilometer — ceilometer-agent-compute, som körs på varje beräkningsnod, samt Ceilometer API, och insamling av följande mätvärden:

mätvärde
tjänst
plugins
kommentar

cpu_util
ceilometer
none
 

memory.resident
ceilometer
none
 

Strategins parametrar:

parameter
typ
standard
beskrivning

metrics
Sträng
‘cpu_util’
Mätvärdena som ligger till grund för: ‘cpu_util’, ‘memory.resident’.

tröskelvärde
Antal
25.0
Arbetsbelastningströskel för migrering.

period
Antal
300
Sammanlagd tid Ceilometer.

Använd metod — migration.

Workload stabilization — strategi som syftar till att stabilisera arbetsbelastningen genom levande migrering. Strategin baseras på en algoritm för standardavvikelse och bestämmer om det finns överbelastning i klustret, och reagerar på den genom att initiera migrering av maskiner för att stabilisera klustret.

Krav

• Användning av fysiska processorer;
• Minst två fysiska beräkningsnoder;
• Installerad och konfigurerad komponent Ceilometer — ceilometer-agent-compute, som körs på varje beräkningsnod, samt Ceilometer API, och insamling av följande mätvärden:

mätvärde
tjänst
plugins
kommentar

cpu_util
ceilometer
none
 

memory.resident
ceilometer
none
 

Storage Capacity Balance Strategy (strategin implementerades från och med Queens) — strategin flyttar diskar baserat på belastningen på Cinder-poolerna. Beslutet om att flytta tas varje gång användningsgraden för poolen överskrider den angivna gränsen. Den flyttade disken bör närma poolen till den genomsnittliga belastningen för alla Cinder-pooler.

Krav och begränsningar

• Minst två Cinder-pooler;
• Möjlighet att migrera diskar.
• Klustrets datamodell — Cinder cluster data model collector.

Strategins parametrar:

parameter
typ
standard
beskrivning

volume_threshold
Antal
80.0
Tröskelvärde för diskar för volymbalansering.

Använd metod — diskmigrering (volume_migrate).

Noisy Neighbor — att identifiera och flytta "grannmaskinen" — en virtuell maskin med låg prioritet, som negativt påverkar prestanda hos en virtuell maskin med hög prioritet ur IPC-synpunkt, och överanvänder Last Level Cache. Egen strategi: Noisy Neighbor (använd parameter för strategi — cache_threshold (standardvärde — 35), när prestandan faller under angivet värde startar migreringen. För att strategin ska fungera krävs aktiverade LLC (Last Level Cache) metrikor, den senaste Intel-servern med stöd för CMT, samt insamling av följande metrikor:

mätvärde
tjänst
plugins
kommentar

cpu_l3_cache
ceilometer
none
Nödvändig Intel CMT.

Klustermodell (standard): Nova cluster data model collector. Använd metod — migrering.

Arbete med detta mål via Dashboard är inte fullt implementerat i Queens.

Termisk optimering — optimera temperaturregimen. Utgångstemperaturen (utluft) är ett av de viktiga termiska telemetrisystemen för att mäta tillståndet för serverns värme-/arbetsbelastning. För målet finns en strategi — Outlet temperature based strategy, som fattar beslut om att flytta arbetsbelastningar till noder med gynnsam temperaturregim (den lägsta utgångstemperaturen), när utgångstemperaturen för de ursprungliga värdarna når en konfigurerbar tröskel.

För att strategin ska fungera krävs en server med installerad och konfigurerad Intel Power Node Manager 3.0 eller senare version, samt insamling av följande metrikor:

mätvärde
tjänst
plugins
kommentar

hardware.ipmi.node.outlet_temperature
ceilometer
IPMI
 

Strategins parametrar:

parameter
typ
standard
beskrivning

tröskelvärde
Antal
35.0
Temperaturtröskel för migrering.

period
Antal
30
Tidsintervall i sekunder för att få statistisk aggregation från datakällan för metrikor.

Använd metod — migration.

Luftflödesoptimering — optimera ventilationsläget. Egen strategi — Uniform Airflow using live migration. Strategin initierar migreringen av den virtuella maskinen varje gång luftflödet från serverns fläkt överstiger angiven tröskel.

För att strategin ska fungera krävs:

• Hårdvara: beräkningsnoder <med stöd för NodeManager 3.0;
• Minst två beräkningsnoder;
• Installerat och konfigurerat på varje beräkningsnod komponenten ceilometer-agent-compute och Ceilometer API, som kan rapportera sådana metrikor som luftflöde, systemeffekt, inlopps temperatur:

mätvärde
tjänst
plugins
kommentar

hardware.ipmi.node.airflow
ceilometer
IPMI
 

hardware.ipmi.node.temperature
ceilometer
IPMI
 

hardware.ipmi.node.power
ceilometer
IPMI
 

För att strategin ska fungera krävs en server med installerad och konfigurerad Intel Power Node Manager 3.0 eller senare version.

Begränsningar: Konceptet är inte avsett för produktion.

Det rekommenderas att använda denna algoritm med kontinuerliga revisioner, eftersom en migration planeras för endast en virtuell maskin åt gången.

Levande migrationer är möjliga.

Strategins parametrar:

parameter
typ
standard
beskrivning

threshold_airflow
Antal
400.0
Luftflödesgräns för migrationen Enhet är 0.1CFM

threshold_inlet_t
Antal
28.0
Inloppstemperaturgräns för migrationsbeslut

threshold_power
Antal
350.0
Systemkraftgräns för migrationsbeslut

period
Antal
30
Tidsintervall i sekunder för att få statistisk aggregation från datakällan för metrikor.

Använd metod — migration.

Hårdvarunderhåll — underhåll av hårdvaror. Strategin som gäller för detta syfte är zonmigration. Strategin är ett verktyg för effektiv automatisk och minimal migration av virtuella maskiner och diskar när tekniskt underhåll av hårdvaror behövs. Strategin bygger en handlingsplan baserat på vikter: en uppsättning åtgärder med högre vikt kommer att planeras före andra. Det finns två konfigurationsparametrar: åtgärdsvikter (action_weights) och parallellisering.

Begränsningar: konfiguration av åtgärdsvikter och parallellisering krävs.

Strategins parametrar:

parameter
typ
standard
beskrivning

compute_nodes
array
None
Beräkningsnoder för migration.

storage_pools
array
None
Lagringsnoder för migration.

parallel_total
heltal
6
Det totala antal åtgärder som ska utföras parallellt.

parallel_per_node
heltal
2
Antal åtgärder som utförs parallellt för varje beräkningsnod.

parallel_per_pool
heltal
2
Antal åtgärder som utförs parallellt för varje lagringspool.

priority
object
None
Lista över prioriteter för virtuella maskiner och diskar.

with_attached_volume
boolean
Falskt
False — virtuella maskiner kommer att flyttas efter att alla diskar har flyttats. True — virtuella maskiner kommer att flyttas efter att alla anslutna diskar har migrerats.

Element i arrayen av beräkningsnoder:

parameter
typ
standard
beskrivning

src_node
sträng
None
Beräkningsnod från vilken de virtuella maskinerna flyttas (obligatoriskt).

dst_node
sträng
None
Beräkningsnod dit de virtuella maskinerna migreras.

Element i arrayen av lagringsnoder:

parameter
typ
standard
beskrivning

src_pool
sträng
None
Lagringspool från vilken diskar flyttas (obligatoriskt).

dst_pool
sträng
None
Lagringspool dit diskar flyttas.

src_type
sträng
None
Ursprunglig disktyp (obligatoriskt).

dst_type
sträng
None
Slutgiltig disktyp (obligatoriskt).

Element av prioritetsobjekt:

parameter
typ
standard
beskrivning

projekt
array
None
Projektnamn.

compute_node
array
None
Namn på beräkningsnoder.

storage_pool
array
None
Namn på lagringspooler.

compute
enum
None
Parameter för virtuella maskiner [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].

lagring
enum
None
Parameter för diskar [“size”, “created_at”].

Använda metoder — migrering av virtuella maskiner, migrering av diskar.

Oklassificerat — en hjälpmålsättning som används för att underlätta utvecklingen av strategin. Den innehåller inga specifikationer och kan användas varje gång strategin inte är kopplad till ett befintligt mål. Detta mål kan även användas som ett övergångssteg. Strategin kopplad till detta mål är Actuator.   

Skapa ett nytt mål

Watcher Decision Engine har ett plugin-gränssnitt för ”externa mål”, vilket möjliggör integration av ett externt mål som kan uppnås med hjälp av strategin.

Innan du skapar ett nytt mål, bör du försäkra dig om att inget av de befintliga målen uppfyller dina behov.

Skapa en ny plugin

För att skapa ett nytt mål måste du: utöka målets klass, implementera metoden för klassen get_name () för att returnera det unika identifierare för det nya mål du vill skapa. Detta unika identifierare måste överensstämma med namnet på ingångspunkten som du deklarerar senare.

Sedan måste du implementera metoden för klassen get_display_name () för att återge det översatta visningsnamnet för det mål du vill skapa (använd inte en variabel för att returnera den översatta strängen så att den kan samlas automatiskt av översättningsverktyget.).

Implementera metoden för klassen get_translatable_display_name (), för att returnera översättningsnyckeln (faktiskt det engelska visningsnamnet) för ditt nya mål. Det returnerade värdet ska stämma överens med strängen som översattes i get_display_name ().

Implementera dess metod get_efficacy_specification (), för att returnera effektivitetspecifikationen för ditt mål. Metoden get_efficacy_specification () returnerar en instans av Unclassified (), vilken tillhandahålls av Watcher. Denna effektivitetspecifikation är användbar under utvecklingen av ditt mål, eftersom den överensstämmer med en tom specifikation.

→ Mer information här

Watcher-arkitektur (mer information här).

Komponenter

Watcher API — en komponent som implementerar REST API som tillhandahålls av Watcher. Interaktionsmekanismer: CLI, plugin Horizon, Python SDK.

Watcher DB — Watchers databas.

Watcher Applier — en komponent som implementerar utförandet av åtgärdsplanen som skapats av komponenten Watcher Decision Engine.

Watcher Decision Engine — en komponent som ansvarar för att beräkna uppsättningen av potentiella åtgärder för optimering för att uppnå revisionsmålet. Om strategin inte anges väljer komponenten själv det mest lämpliga alternativet.

Watcher Metrics Publisher — en komponent som samlar in och beräknar vissa metrik eller händelser och publicerar dem till CEP-slutpunkten. Komponentens funktionalitet kan också tillhandahållas av Ceilometer publisher.

Complex Event Processing (CEP) Engine — en motor för komplex händelsebehandling. Av prestandaskäl kan flera instanser av CEP Engine köras samtidigt, där varje enskild hanterar en viss typ av metrik / händelser. I Watcher-systemet kör CEP två typer av åtgärder: — skriv relevanta händelser / metrik till tidsseriedatabasen; — skicka relevanta händelser till Watcher Decision Engine-komponenten när denna händelse kan påverka resultatet av den aktuella optimeringsstrategin, eftersom OpenStack-klustret inte är ett statiskt system.

Interaktionen mellan komponenterna sker via AMQP-protokollet.

→ Konfigurering av Watcher

Schema för interaktion med Watcher

Resultat av tester av Watcher

1. På sidan Optimering — Åtgärdsplaner visas 500-fel (både på ren Queens och på en installation med Tionix-moduler), som bara dyker upp efter att revisionen körts och åtgärdsplanen genererats, en tom sida öppnas normalt.
2. På fliken Åtgärdsdetaljer visas fel, det går inte att hämta mål och revisionsstrategi (både på ren Queens och på en installation med Tionix-moduler).
3. Revisioner med målet Dummy (testmål) skapas och körs normalt, åtgärdsplaner genereras.
4. Revisioner med målet Unclassified skapas inte, eftersom målet inte är funktionellt och är avsett för mellaninställningar vid skapande av nya strategier.
5. Revisioner med målet Workload Balancing (strategi för lagringskapacitetsbalansering) skapas framgångsrikt, men åtgärdsplanen genereras inte. Optimering av lagringspooler krävs inte.
6. Revisioner med målet Workload Balancing (strategi för Workload Balance Migration Strategy) skapas framgångsrikt, men åtgärdsplanen genereras inte.
7. Revisioner med målet Workload Balancing (strategi för Workload Stabilization Strategy) avslutas med fel.
8. Revisioner med målet Noisy Neighbor skapas framgångsrikt, men åtgärdsplanen genereras inte.
9. Auditeringar för hårdvarunderhåll skapas framgångsrikt, handlingsplanen genereras inte i sin helhet (effektivitetsindikatorer genereras, men själva åtgärdslistan genereras inte).
10. Ändringar i konfigurationsfilerna nova.conf (i standardsektionen compute_monitors = cpu.virt_driver) på beräknings- och styrnoderna rättar inte till felen.
11. Auditeringar för serverkonsolidering (strategi Basic) avslutas också med fel.
12. Auditeringar för serverkonsolidering (strategi VM workload consolidation) avslutas med fel. Det finns ett fel i loggarna vid hämtning av ursprungliga data. Diskussion om felet, särskilt här.
    Vi försökte ange i Watcher-konfigurationsfilen (det hjälpte inte — i resultatet fel på alla sidor för Optimering, återställning till ursprungligt innehåll i konfigurationsfilen löser inte situationen):

    [watcher_strategies.basic]
    datasource = ceilometer, gnocchi

13. Auditeringar för energibesparing avslutas med fel. Enligt loggarna ligger problemet fortfarande i avsaknaden av Ironic, det kommer inte att fungera utan baremetal-service.
14. Auditeringar för termisk optimering avslutas med fel. Traceback är densamma som för serverkonsolidering (strategi VM workload consolidation) (fel med ursprungliga data)
15. Auditeringar för Airflow-optimering avslutas med fel.

Det finns också följande fel vid avslutning av audit. Traceback i loggarna decision-engine.log (klusterstatus är inte definierad).

→ Diskussion om felet här

Slutsats

Resultatet av vår tvåmånaders forskning blev en tydlig slutsats att för att få ett fullt fungerande lastbalanseringssystem måste vi, i denna del, intensivt arbeta med att vidareutveckla verktygen för Openstack-plattformen.

Watcher har visat sig vara en seriös och snabbt växande produkt med enorm potential, för att använda den fullt ut krävs det dock stort och seriöst arbete.

Men mer om detta – i kommande artiklar i serien.

Källa: habr.com