Loadbalancing in OpenStack

In grote cloudsystemen is het probleem van het automatisch balanceren of nivelleren van de belasting van computerbronnen bijzonder acuut. Tionix (een ontwikkelaar en exploitant van clouddiensten, onderdeel van de Rostelecom-bedrijvengroep) heeft dit probleem ook opgepakt.

En aangezien ons belangrijkste ontwikkelingsplatform Openstack is en wij, net als alle mensen, lui zijn, werd besloten een kant-en-klare module te selecteren die al in het platform is opgenomen. Onze keuze viel op Watcher, die we besloten te gebruiken voor onze behoeften.
Loadbalancing in OpenStack
Laten we eerst eens kijken naar de termen en definities.

Termen en definities

doelwit is een voor mensen leesbaar, waarneembaar en meetbaar eindresultaat dat behaald moet worden. Er zijn een of meer strategieën om elk doel te bereiken. Een strategie is de implementatie van een algoritme dat in staat is een oplossing te vinden voor een bepaald doel.

Actie is een elementaire taak die de huidige status van de beheerde doelbron van het OpenStack-cluster verandert, zoals: het migreren van een virtuele machine (migratie), het wijzigen van de energiestatus van een knooppunt (change_node_power_state), het wijzigen van de status van de nova-service (change_nova_service_state ), smaak veranderen (formaat wijzigen), NOP-berichten registreren (nop), gebrek aan actie gedurende een bepaalde tijd - pauzeren (slaap), schijfoverdracht (volume_migrate).

Actieplan - een specifieke stroom van acties die in een bepaalde volgorde worden uitgevoerd om een ​​specifiek doel te bereiken. Het actieplan bevat ook gemeten mondiale prestaties met een reeks prestatie-indicatoren. Bij een succesvolle audit wordt door Watcher een actieplan gegenereerd, waardoor de gehanteerde strategie een oplossing vindt om het doel te bereiken. Een actieplan bestaat uit een lijst met opeenvolgende acties.

Controle is een verzoek om het cluster te optimaliseren. Er wordt geoptimaliseerd om één doel in een bepaald cluster te bereiken. Voor elke succesvolle audit genereert Watcher een actieplan.

Reikwijdte van de audit is een reeks bronnen waarbinnen de audit wordt uitgevoerd (beschikbaarheidszone(s), knooppuntaggregators, individuele rekenknooppunten of opslagknooppunten, enz.). De reikwijdte van de audit wordt in elke sjabloon gedefinieerd. Als er geen auditscope is opgegeven, wordt het hele cluster gecontroleerd.

Auditsjabloon — een opgeslagen set instellingen voor het starten van een audit. Sjablonen zijn nodig om audits meerdere keren uit te voeren met dezelfde instellingen. Het sjabloon moet noodzakelijkerwijs het doel van de audit bevatten; als er geen strategieën zijn gespecificeerd, worden de meest geschikte bestaande strategieën geselecteerd.

TROS is een verzameling fysieke machines die reken-, opslag- en netwerkbronnen bieden en worden beheerd door hetzelfde OpenStack-beheerknooppunt.

Clustergegevensmodel (CDM) is een logische weergave van de huidige status en topologie van de bronnen die door het cluster worden beheerd.

Efficiëntie-indicator - een indicator die aangeeft hoe de oplossing die met deze strategie is gecreëerd, wordt uitgevoerd. Prestatie-indicatoren zijn specifiek voor een bepaald doel en worden doorgaans gebruikt om de globale effectiviteit van het resulterende actieplan te berekenen.

Werkzaamheidsspecificatie is een reeks specifieke kenmerken die aan elk doel zijn gekoppeld en die de verschillende prestatie-indicatoren definiëren die een strategie om het overeenkomstige doel te bereiken in zijn oplossing moet bereiken. Elke oplossing die door de strategie wordt voorgesteld, zal worden getoetst aan de specificatie voordat de globale effectiviteit ervan wordt berekend.

Scoremachine is een uitvoerbaar bestand met goed gedefinieerde invoer en uitvoer, en voert een puur wiskundige taak uit. Op deze manier is de berekening onafhankelijk van de omgeving waarin deze wordt uitgevoerd en zal overal hetzelfde resultaat opleveren.

Watcher-planner - onderdeel van de Watcher-besluitvormingsengine. Deze module neemt een reeks acties gegenereerd door een strategie en creëert een workflowplan dat specificeert hoe deze verschillende acties op tijd moeten worden gepland en voor elke actie, wat de randvoorwaarden zijn.

Watcher-doelen en -strategieën

doelwit
strategie

Dummy doel
Dummy-strategie 

Dummystrategie met behulp van voorbeeldscore-engines

Dummy-strategie met formaatwijziging

Energie besparen
Energiebesparingsstrategie

Serverconsolidatie
Basis offline serverconsolidatie

Consolidatiestrategie voor VM-workloads

Werklast balanceren
Migratiestrategie voor werklastbalans

Strategie voor evenwicht in opslagcapaciteit

Stabilisatie van de werklast

Luidruchtige buurman
Luidruchtige buurman

Thermische optimalisatie
Op uitlaattemperatuur gebaseerde strategie

Luchtstroom optimalisatie
Uniforme strategie voor luchtstroommigratie

Hardware-onderhoud
Zonemigratie

Geclassificeerde
Aandrijving

Dummy doel — gereserveerd doel dat wordt gebruikt voor testdoeleinden.

Gerelateerde strategieën: Dummy-strategie, Dummy-strategie met behulp van voorbeeldscore-engines en Dummy-strategie met formaatwijziging. Dummy-strategie is een dummy-strategie die wordt gebruikt voor integratietests via Tempest. Deze strategie biedt geen enkele nuttige optimalisatie, het enige doel is het gebruik van Tempest-tests.

Dummy-strategie met behulp van voorbeeldscore-engines - de strategie is vergelijkbaar met de vorige, het enige verschil is het gebruik van een voorbeeld-score-engine die berekeningen uitvoert met behulp van machine learning-methoden.

Dummystrategie met formaat wijzigen - de strategie is vergelijkbaar met de vorige, het enige verschil is het gebruik van het veranderen van de smaak (migratie en formaat wijzigen).

Niet gebruikt in de productie.

Energie besparen – het energieverbruik minimaliseren. De Saving Energy Strategy van dit doel is, samen met de VM Workload Consolidation Strategy (Server Consolidation), in staat tot dynamische power management (DPM)-functies die energie besparen door workloads dynamisch te consolideren, zelfs tijdens perioden van laag resourcegebruik: virtuele machines worden naar minder knooppunten verplaatst en onnodige knooppunten zijn uitgeschakeld. Na consolidatie biedt de strategie een beslissing over het in-/uitschakelen van knooppunten in overeenstemming met de opgegeven parameters: “min_free_hosts_num” - het aantal vrij ingeschakelde knooppunten dat wacht op belasting, en “free_used_percent” - het percentage gratis ingeschakelde hosts voor de aantal knooppunten dat wordt bezet door machines. Wil de strategie werken, dan moet dat zo zijn Ironic ingeschakeld en geconfigureerd om power cycling op knooppunten af ​​te handelen.

Strategieparameters

parameter
тип
standaard
описание

gratis_gebruikte_percent
Telefoon Nummer
10.0
verhouding tussen het aantal vrije rekenknooppunten en het aantal rekenknooppunten met virtuele machines

min_free_hosts_num
Int
1
minimumaantal vrije computerknooppunten

De cloud moet minimaal twee knooppunten hebben. De gebruikte methode is het wijzigen van de energiestatus van het knooppunt (change_node_power_state). De strategie vereist geen verzameling van statistieken.

Serverconsolidatie - minimaliseer het aantal computerknooppunten (consolidatie). Het heeft twee strategieën: Basic Offline Server Consolidation en VM Workload Consolidation Strategy.

De Basic Offline Server Consolidation-strategie minimaliseert het totale aantal gebruikte servers en minimaliseert ook het aantal migraties.

De basisstrategie vereist de volgende statistieken:

statistieken
onderhoud
plug-ins
комментарий

compute.node.cpu.percent
hoogtemeter
geen
 

cpu_util
hoogtemeter
geen
 

Strategieparameters: migratie_attempts - aantal combinaties om te zoeken naar potentiële kandidaten voor afsluiting (standaard, 0, geen beperkingen), periode - tijdsinterval in seconden om statische aggregatie te verkrijgen van de metrische gegevensbron (standaard, 700).

Gebruikte methoden: migratie, wijziging van de nova-servicestatus (change_nova_service_state).

De VM Workload Consolidation Strategy is gebaseerd op een first-fit heuristiek die zich richt op de gemeten CPU-belasting en probeert knooppunten te minimaliseren die te veel of te weinig belasting hebben, gegeven de beperkingen van de resourcecapaciteit. Deze strategie biedt een oplossing die resulteert in een efficiënter gebruik van clusterbronnen met behulp van de volgende vier stappen:

  1. Ontladingsfase - verwerking van overgebruikte bronnen;
  2. Consolidatiefase - omgaan met onderbenutte middelen;
  3. Optimalisatie van de oplossing - vermindering van het aantal migraties;
  4. Ongebruikte rekenknooppunten uitschakelen.

De strategie vereist de volgende statistieken:

statistieken
onderhoud
plug-ins
комментарий

geheugen
hoogtemeter
geen
 

schijf.root.grootte
hoogtemeter
geen
 

De volgende statistieken zijn optioneel, maar verbeteren de nauwkeurigheid van de strategie, indien beschikbaar:

statistieken
onderhoud
plug-ins
комментарий

geheugen.resident
hoogtemeter
geen
 

cpu_util
hoogtemeter
geen
 

Strategieparameters: periode — tijdsinterval in seconden om statische aggregatie te verkrijgen uit de metrische gegevensbron (standaard, 3600).

Gebruikt dezelfde methoden als de vorige strategie. Meer details hier.

Werklast balanceren — breng de werklast tussen computerknooppunten in evenwicht. Het doel heeft drie strategieën: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.

Workload Balance Migration Strategy voert virtuele machinemigraties uit op basis van de werklast van de virtuele hostmachine. Er wordt een migratiebeslissing genomen wanneer het % CPU- of RAM-gebruik van een knooppunt de opgegeven drempelwaarde overschrijdt. In dit geval zou de verplaatste virtuele machine het knooppunt dichter bij de gemiddelde werklast van alle knooppunten moeten brengen.

Eisen

  • Gebruik van fysieke verwerkers;
  • Ten minste twee fysieke computerknooppunten;
  • De Ceilometer-component - ceilometer-agent-compute, die op elk rekenknooppunt draait, en de Ceilometer-API geïnstalleerd en geconfigureerd, en de volgende statistieken verzameld:

statistieken
onderhoud
plug-ins
комментарий

cpu_util
hoogtemeter
geen
 

geheugen.resident
hoogtemeter
geen
 

Strategieparameters:

parameter
тип
standaard
описание

metriek
Draad
'cpu_util'
De onderliggende statistieken zijn: 'cpu_util', 'memory.resident'.

drempel
Telefoon Nummer
25.0
Werkbelastingdrempel voor migratie.

periode
Telefoon Nummer
300
Cumulatieve tijdsperiode Ceilometer.

De gebruikte methode is migratie.

Werklaststabilisatie is een strategie gericht op het stabiliseren van de werkdruk met behulp van live migratie. De strategie is gebaseerd op een standaardafwijkingsalgoritme en bepaalt of er sprake is van congestie in het cluster en reageert hierop door machinemigratie te activeren om het cluster te stabiliseren.

Eisen

  • Gebruik van fysieke verwerkers;
  • Ten minste twee fysieke computerknooppunten;
  • De Ceilometer-component - ceilometer-agent-compute, die op elk rekenknooppunt draait, en de Ceilometer-API geïnstalleerd en geconfigureerd, en de volgende statistieken verzameld:

statistieken
onderhoud
plug-ins
комментарий

cpu_util
hoogtemeter
geen
 

geheugen.resident
hoogtemeter
geen
 

Storage Capacity Balance Strategy (strategie geïmplementeerd vanaf Queens) - de strategie draagt ​​schijven over, afhankelijk van de belasting van de Cinder-pools. Er wordt een overdrachtsbeslissing genomen wanneer de bezettingsgraad van de pool een bepaalde drempel overschrijdt. De schijf die wordt verplaatst zou de pool dichter bij de gemiddelde belasting van alle Cinder-pools moeten brengen.

Vereisten en beperkingen

  • Minimaal twee Cinder-zwembaden;
  • Mogelijkheid tot schijfmigratie.
  • Clustergegevensmodel - Verzamelaar van Cinder-clustergegevensmodellen.

Strategieparameters:

parameter
тип
standaard
описание

volume_drempel
Telefoon Nummer
80.0
Drempelwaarde van schijven voor het balanceren van volumes.

De gebruikte methode is schijfmigratie (volume_migrate).

Lawaaierige buur - Identificeer en migreer een "luidruchtige buur" - een virtuele machine met lage prioriteit die een negatieve invloed heeft op de prestaties van een virtuele machine met hoge prioriteit in termen van IPC door overmatig gebruik van Last Level Cache. Eigen strategie: Noisy Neighbor (gebruikte strategieparameter is cache_threshold (standaardwaarde is 35). Wanneer de prestaties dalen tot de opgegeven waarde, wordt de migratie gestart. Om de strategie te laten werken, moet deze zijn ingeschakeld LLC-statistieken (Last Level Cache), nieuwste Intel-server met CMT-ondersteuning, evenals het verzamelen van de volgende statistieken:

statistieken
onderhoud
plug-ins
комментарий

cpu_l3_cache
hoogtemeter
geen
Intel vereist CMT.

Clustergegevensmodel (standaard): Nova-clustergegevensmodelverzamelaar. De gebruikte methode is migratie.

Het werken met dit doel via het Dashboard is in Queens nog niet volledig geïmplementeerd.

Thermische optimalisatie — het temperatuurregime optimaliseren. De uitlaattemperatuur (uitlaatlucht) is een van de belangrijke thermische telemetriesystemen om de thermische/werklaststatus van een server te meten. Het doel heeft één strategie, de op uitlaattemperatuur gebaseerde strategie, die besluit werkbelastingen te migreren naar thermisch gunstige hosts (laagste uitlaattemperatuur) wanneer de uitlaattemperatuur van de bronhosts een configureerbare drempel bereikt.

Om de strategie te laten werken, heb je een server nodig waarop Intel Power Node Manager is geïnstalleerd en geconfigureerd 3.0 of hoger, evenals het verzamelen van de volgende statistieken:

statistieken
onderhoud
plug-ins
комментарий

hardware.ipmi.node.outlet_temperatuur
hoogtemeter
IPMI
 

Strategieparameters:

parameter
тип
standaard
описание

drempel
Telefoon Nummer
35.0
Temperatuurdrempel voor migratie.

periode
Telefoon Nummer
30
Het tijdsinterval, in seconden, voor het verkrijgen van de statistische aggregatie uit de metrische gegevensbron.

De gebruikte methode is migratie.

Luchtstroom optimalisatie — optimaliseer de ventilatiemodus. Eigen strategie - Uniforme luchtstroom met behulp van live migratie. De strategie activeert de migratie van virtuele machines wanneer de luchtstroom van de serverventilator een bepaalde drempel overschrijdt.

Om de strategie te laten werken, hebt u het volgende nodig:

  • Hardware: rekenknooppunten <ondersteunt NodeManager 3.0;
  • Ten minste twee computerknooppunten;
  • De ceilometer-agent-compute en Ceilometer API-component geïnstalleerd en geconfigureerd op elk computerknooppunt, die met succes statistieken zoals luchtstroom, systeemvermogen en inlaattemperatuur kan rapporteren:

statistieken
onderhoud
plug-ins
комментарий

hardware.ipmi.node.airflow
hoogtemeter
IPMI
 

hardware.ipmi.node.temperatuur
hoogtemeter
IPMI
 

hardware.ipmi.node.power
hoogtemeter
IPMI
 

Om de strategie te laten werken, hebt u een server nodig waarop Intel Power Node Manager 3.0 of hoger is geïnstalleerd en geconfigureerd.

Beperkingen: Het concept is niet bedoeld voor productie.

Er wordt voorgesteld om dit algoritme te gebruiken met continue audits, aangezien er slechts één virtuele machine per iteratie zal worden gemigreerd.

Live migraties zijn mogelijk.

Strategieparameters:

parameter
тип
standaard
описание

drempel_luchtstroom
Telefoon Nummer
400.0
Luchtstroomdrempel voor migratie-eenheid is 0.1 CFM

drempel_inlaat_t
Telefoon Nummer
28.0
Drempel van de inlaattemperatuur voor migratiebeslissing

drempel_macht
Telefoon Nummer
350.0
Systeemstroomdrempel voor migratiebeslissing

periode
Telefoon Nummer
30
Het tijdsinterval, in seconden, voor het verkrijgen van de statistische aggregatie uit de metrische gegevensbron.

De gebruikte methode is migratie.

Hardware onderhoud — hardware-onderhoud. De strategie met betrekking tot dit doel is Zonemigratie. De strategie is een hulpmiddel voor effectieve automatische en minimale migratie van virtuele machines en schijven in geval van hardwareonderhoud. Strategie bouwt een actieplan op in overeenstemming met gewichten: een reeks acties die meer gewicht hebben, zullen vóór andere worden gepland. Er zijn twee configuratieopties: action_weights en parallellisatie.

Beperkingen: actiegewichten en parallellisatie moeten worden geconfigureerd.

Strategieparameters:

parameter
тип
standaard
описание

reken_nodes
reeks
Geen
Rekenknooppunten voor migratie.

opslag_pools
reeks
Geen
Opslagknooppunten voor migratie.

parallel_totaal
geheel getal
6
Het totale aantal activiteiten dat parallel moet worden uitgevoerd.

parallel_per_knooppunt
geheel getal
2
Het aantal acties dat parallel wordt uitgevoerd voor elk rekenknooppunt.

parallelle_per_pool
geheel getal
2
Het aantal acties dat parallel wordt uitgevoerd voor elke opslagpool.

prioriteit
object
Geen
Prioriteitenlijst voor virtuele machines en schijven.

met_bijgevoegd_volume
boolean
Niet waar
Niet waar: virtuele machines worden gemigreerd nadat alle schijven zijn gemigreerd. Waar: virtuele machines worden gemigreerd nadat alle aangesloten schijven zijn gemigreerd.

Elementen van de reeks computerknooppunten:

parameter
тип
standaard
описание

src_knooppunt
snaar
Geen
Het rekenknooppunt van waaruit de virtuele machines worden gemigreerd (vereist).

dst_knooppunt
snaar
Geen
Bereken het knooppunt waarnaar de virtuele machines migreren.

Array-elementen voor opslagknooppunten:

parameter
тип
standaard
описание

src_pool
snaar
Geen
De opslagpool waaruit de schijven worden gemigreerd (vereist).

dst_pool
snaar
Geen
De opslagpool waarnaar schijven worden gemigreerd.

src_type
snaar
Geen
Origineel schijftype (vereist).

dst_type
snaar
Geen
Het resulterende schijftype (vereist).

Elementen objectprioriteit:

parameter
тип
standaard
описание

project
reeks
Geen
Projectnamen.

reken_knooppunt
reeks
Geen
Namen van rekenknooppunten.

opslag_pool
reeks
Geen
Namen van opslagpools.

berekenen
opsomming
Geen
Parameters van virtuele machines [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].

mediaopslag
opsomming
Geen
Schijfparameters [“size”, “created_at”].

De gebruikte methoden zijn migratie van virtuele machines en schijfmigratie.

Geclassificeerde - een hulpdoel dat wordt gebruikt om het strategieontwikkelingsproces te vergemakkelijken. Bevat geen specificaties en kan worden gebruikt wanneer de strategie nog niet aan een bestaand doel is gekoppeld. Dit doel kan ook als overgangspunt worden gebruikt. Een strategie die verband houdt met dit doel is Actuator.   

Een nieuw doel creëren

Watcher-beslissingsengine heeft een “extern doel” plugin-interface die het mogelijk maakt om een ​​extern doel te integreren dat kan worden bereikt met behulp van een strategie.

Voordat u een nieuw doel maakt, moet u ervoor zorgen dat geen enkele bestaande doelstelling aan uw behoeften voldoet.

Een nieuwe plug-in maken

Om een ​​nieuw doel te maken, moet u: de doelklasse uitbreiden, een klassenmethode implementeren get_name() om de unieke ID te retourneren van het nieuwe doel dat u wilt maken. Deze unieke identificatie moet overeenkomen met de naam van het toegangspunt die u later declareert.

Vervolgens moet u de klassenmethode implementeren get_display_name() om de vertaalde weergavenaam te retourneren van het doel dat u wilt maken (gebruik geen variabele om de vertaalde tekenreeks terug te geven, zodat deze automatisch kan worden verzameld door de vertaaltool).

Implementeer een klassenmethode get_translable_display_name()om de vertaalsleutel (eigenlijk de Engelse weergavenaam) van uw nieuwe doel terug te geven. De geretourneerde waarde moet overeenkomen met de tekenreeks die is vertaald in get_display_name().

Implementeer zijn methode get_efficacy_specificatie()om de efficiëntiespecificatie voor uw doel terug te geven. De methode get_efficacy_specification() retourneert de Unclassified()-instantie van Watcher. Deze prestatiespecificatie is nuttig bij het ontwikkelen van uw doel, omdat deze overeenkomt met de lege specificatie.

Lees hier meer

Watcher-architectuur (meer details) hier).

Loadbalancing in OpenStack

Onderdelen

Loadbalancing in OpenStack

Watcher-API - een component die de REST API van Watcher implementeert. Interactiemechanismen: CLI, Horizon-plug-in, Python SDK.

Waarnemer DB - Watcher-database.

Watcher-applicator — een component die de uitvoering implementeert van een actieplan dat is gemaakt door de Watcher Decision Engine-component.

Watcher-beslissingsengine - De component die verantwoordelijk is voor het berekenen van een reeks potentiële optimalisatieacties om het auditdoel te bereiken. Als er geen strategie is gespecificeerd, selecteert de component zelfstandig de meest geschikte strategie.

Watcher Metrics-uitgever - Een component die bepaalde statistieken of gebeurtenissen verzamelt, berekent en deze publiceert naar het CEP-eindpunt. De functionaliteit van de component kan ook worden geleverd door Ceilometer-uitgever.

Complexe gebeurtenisverwerkingsengine (CEP). — motor voor complexe gebeurtenisverwerking. Om prestatieredenen kunnen er meerdere CEP Engine-instanties tegelijkertijd actief zijn, waarbij elke instantie een specifiek type statistiek/gebeurtenis verwerkt. In het Watcher-systeem activeert CEP twee soorten acties: - registreer de overeenkomstige gebeurtenissen / statistieken in de tijdreeksdatabase; - stuur geschikte gebeurtenissen naar de Watcher Decision Engine wanneer deze gebeurtenis het resultaat van de huidige optimalisatiestrategie kan beïnvloeden, aangezien het Openstack-cluster geen statisch systeem is.

De componenten werken samen met behulp van het AMQP-protocol.

Watcher configureren

Schema van interactie met Watcher

Loadbalancing in OpenStack

Watcher-testresultaten

  1. Op de pagina Optimalisatie - Actieplannen 500 (zowel op pure Queens als op een stand met Tionix-modules) verschijnt deze pas nadat de audit is gestart en een actieplan is gegenereerd; de lege gaat normaal open.
  2. Er staan ​​fouten op het tabblad Actiedetails, het is niet mogelijk om het auditdoel en de strategie te krijgen (zowel op pure Queens als op een stand met Tionix-modules).
  3. Audits met het doel Dummy (test) worden normaal aangemaakt en gelanceerd, er worden actieplannen gegenereerd.
  4. Er worden geen audits voor het niet-geclassificeerde doel gemaakt omdat het doel niet functioneel is en bedoeld is voor tussentijdse configuratie bij het maken van nieuwe strategieën.
  5. Audits ten behoeve van Workload Balancing (Storage Capacity balance-strategie) zijn succesvol aangemaakt, maar er wordt geen actieplan gegenereerd. Geen optimalisatie van de opslagpool vereist.
  6. Audits voor het doel Workload Balancing (Workload Balance Migration Strategy) zijn succesvol gemaakt, maar er wordt geen actieplan gegenereerd.
  7. Audits voor het verdelen van de werklast (strategie voor werklaststabilisatie) mislukken.
  8. Audits voor het doelwit Lawaaierige buur zijn met succes gemaakt, maar er is geen actieplan gegenereerd.
  9. Audits ten behoeve van hardwareonderhoud zijn met succes aangemaakt, het actieplan wordt niet volledig gegenereerd (prestatie-indicatoren worden gegenereerd, maar de lijst met acties zelf wordt niet gegenereerd).
  10. Bewerkingen in de nova.conf-configuraties (in de standaardsectie compute_monitors = cpu.virt_driver) op de reken- en controleknooppunten corrigeren de fouten niet.
  11. Ook audits ten behoeve van Server Consolidatie (Basisstrategie) mislukken.
  12. Audits ten behoeve van Serverconsolidatie (consolidatiestrategie voor VM-werklasten) mislukken vanwege een fout. In de logboeken staat een fout bij het verkrijgen van brongegevens. Bespreking van de fout, in het bijzonder hier.
    We hebben geprobeerd Watcher in het configuratiebestand op te geven (het hielp niet - als gevolg van een fout op alle optimalisatiepagina's corrigeert het terugkeren naar de oorspronkelijke inhoud van het configuratiebestand de situatie niet):

    [watcher_strategies.basic] datasource = ceilometer, gnocchi
  13. Audits voor energiebesparing mislukken. Afgaande op de logboeken is het probleem nog steeds de afwezigheid van Ironic; het zal niet werken zonder baremetal-service.
  14. Audits voor thermische optimalisatie mislukken. De traceback is hetzelfde als voor Server Consolidation (consolidatiestrategie voor VM-werklasten) (brongegevensfout)
  15. Audits ten behoeve van Airflow Optimization mislukken met een fout.

De volgende fouten bij het voltooien van de audit komen ook voor. Traceback in beslissingsengine.log-logboeken (clusterstatus is niet gedefinieerd).

→ Bespreking van de fout hier

Conclusie

Het resultaat van ons twee maanden durende onderzoek was de ondubbelzinnige conclusie dat we, om een ​​volwaardig, werkend load-balancing systeem te verkrijgen, in dit deel nauw zullen moeten samenwerken aan het verfijnen van de tools voor het Openstack-platform.

Watcher heeft bewezen een serieus en zich snel ontwikkelend product te zijn met een enorm potentieel, waarvan het volledige gebruik veel serieus werk zal vergen.

Maar hierover meer in de volgende artikelen van de serie.

Bron: www.habr.com

Voeg een reactie