Nei grandi sistemi cloud, la questione del bilanciamento automatico o del livellamento del carico sulle risorse informatiche è particolarmente acuta. Anche Tionix (sviluppatore e gestore di servizi cloud, parte del gruppo di società Rostelecom) si è occupata di questo problema.
E poiché la nostra principale piattaforma di sviluppo è Openstack e noi, come tutte le persone, siamo pigri, si è deciso di selezionare un modulo già pronto che è già incluso nella piattaforma. La nostra scelta è caduta su Watcher, che abbiamo deciso di utilizzare per le nostre esigenze.
Innanzitutto, diamo un'occhiata ai termini e alle definizioni.
Termini e definizioni
bersaglio è un risultato finale leggibile dall’uomo, osservabile e misurabile che deve essere raggiunto. Esistono una o più strategie per raggiungere ciascun obiettivo. Una strategia è l'implementazione di un algoritmo in grado di trovare una soluzione per un determinato obiettivo.
Azione è un'attività elementare che modifica lo stato corrente della risorsa gestita di destinazione del cluster OpenStack, ad esempio: migrazione di una macchina virtuale (migrazione), modifica dello stato di alimentazione di un nodo (change_node_power_state), modifica dello stato del servizio nova (change_nova_service_state ), modifica del sapore (ridimensionamento), registrazione dei messaggi NOP (nop), mancanza di azione per un certo periodo di tempo - pausa (sospensione), trasferimento del disco (volume_migrate).
Piano d'azione - un flusso specifico di azioni eseguite in un certo ordine per raggiungere un obiettivo specifico. Il piano d'azione contiene anche la misurazione della performance globale con una serie di indicatori di prestazione. Dopo un audit positivo, Watcher genera un piano d'azione, a seguito del quale la strategia utilizzata trova una soluzione per raggiungere l'obiettivo. Un piano d'azione è costituito da un elenco di azioni sequenziali.
Controllo è una richiesta per ottimizzare il cluster. L'ottimizzazione viene eseguita per raggiungere un obiettivo in un dato cluster. Per ogni audit andato a buon fine, Watcher genera un piano d'azione.
Ambito dell'audit è un insieme di risorse all'interno delle quali viene eseguito il controllo (zone di disponibilità, aggregatori di nodi, singoli nodi di calcolo o nodi di archiviazione, ecc.). L'ambito dell'audit è definito in ciascun modello. Se non viene specificato un ambito di controllo, viene controllato l'intero cluster.
Modello di controllo — una serie di impostazioni salvate per l'avvio di un audit. I modelli sono necessari per eseguire controlli più volte con le stesse impostazioni. Il modello deve necessariamente contenere lo scopo dell'audit; se non vengono specificate le strategie vengono selezionate le strategie esistenti più idonee.
Grappolo è una raccolta di macchine fisiche che forniscono risorse di elaborazione, archiviazione e rete e sono gestite dallo stesso nodo di gestione OpenStack.
Modello dati cluster (CDM) è una rappresentazione logica dello stato attuale e della topologia delle risorse gestite dal cluster.
Indicatore di efficienza - un indicatore che indica come viene eseguita la soluzione creata utilizzando questa strategia. Gli indicatori di prestazione sono specifici per un obiettivo particolare e vengono generalmente utilizzati per calcolare l'efficacia globale del piano d'azione risultante.
Specifica di efficacia è un insieme di caratteristiche specifiche associate a ciascun Obiettivo che definisce i vari indicatori di prestazione che una strategia per raggiungere il corrispondente Obiettivo deve raggiungere nella sua soluzione. Infatti, ogni soluzione proposta dalla strategia verrà verificata rispetto alle specifiche prima di calcolarne l’efficacia globale.
Motore di punteggio è un file eseguibile che ha input ben definiti, output ben definiti ed esegue un compito puramente matematico. In questo modo, il calcolo è indipendente dall’ambiente in cui viene eseguito: darà lo stesso risultato ovunque.
Pianificatore dell'Osservatore - parte del motore decisionale di Watcher. Questo modulo prende una serie di azioni generate da una strategia e crea un piano di flusso di lavoro che specifica come pianificare queste diverse azioni nel tempo e, per ciascuna azione, quali sono le precondizioni.
Obiettivi e strategie dell'Osservatore
bersaglio
strategia
Gol fittizio
Strategia fittizia
Strategia fittizia utilizzando motori di punteggio campione
Strategia fittizia con ridimensionamento
Risparmiare energia
Strategia di risparmio energetico
Consolidamento del server
Consolidamento di server offline di base
Strategia di consolidamento del carico di lavoro delle VM
Bilanciamento del carico di lavoro
Strategia di migrazione del bilanciamento del carico di lavoro
Strategia di bilanciamento della capacità di storage
Stabilizzazione del carico di lavoro
Vicino rumoroso
Vicino rumoroso
Ottimizzazione termica
Strategia basata sulla temperatura di uscita
Ottimizzazione del flusso d'aria
Strategia uniforme di migrazione del flusso d'aria
Manutenzione dell'hardware
Migrazione di zona
Non classificati
attuatore
Gol fittizio — obiettivo riservato utilizzato a scopo di test.
Strategie correlate: strategia fittizia, strategia fittizia che utilizza motori di punteggio campione e strategia fittizia con ridimensionamento. La strategia fittizia è una strategia fittizia utilizzata per i test di integrazione tramite Tempest. Questa strategia non fornisce alcuna ottimizzazione utile, il suo unico scopo è utilizzare i test Tempest.
Strategia fittizia che utilizza motori di punteggio di esempio: la strategia è simile alla precedente, l'unica differenza è l'uso di un "motore di punteggio" di esempio che esegue calcoli utilizzando metodi di apprendimento automatico.
Strategia fittizia con ridimensionamento: la strategia è simile alla precedente, l'unica differenza è l'uso della modifica del sapore (migrazione e ridimensionamento).
Non utilizzato nella produzione.
Risparmiare energia — ridurre al minimo il consumo energetico. La strategia di risparmio energetico di questo obiettivo, insieme alla strategia di consolidamento del carico di lavoro VM (consolidamento del server), è dotata di funzionalità di gestione dinamica dell'alimentazione (DPM) che consentono di risparmiare energia consolidando dinamicamente i carichi di lavoro anche durante i periodi di basso utilizzo delle risorse: le macchine virtuali vengono spostate su un numero inferiore di nodi e i nodi non necessari vengono disabilitati. Dopo il consolidamento, la strategia offre la possibilità di decidere se attivare/disattivare i nodi in base ai parametri specificati: "min_free_hosts_num" - il numero di nodi abilitati liberi in attesa di caricamento e "free_used_percent" - la percentuale di host abilitati liberi rispetto al numero di nodi occupati dalle macchine. Affinché la strategia funzioni, è necessario che ci sia abilitato e configurato Ironic per gestire il ciclo di accensione e spegnimento sui nodi.
Parametri della strategia
parametro
тип
per impostazione predefinita
descrizione
free_used_percent
Numero
10.0
rapporto tra il numero di nodi di calcolo gratuiti e il numero di nodi di calcolo con macchine virtuali
min_free_hosts_num
Int
1
numero minimo di nodi informatici gratuiti
Il cloud deve avere almeno due nodi. Il metodo utilizzato sta modificando lo stato di alimentazione del nodo (change_node_power_state). La strategia non richiede la raccolta di parametri.
Consolidamento del server: minimizza il numero di nodi di elaborazione (consolidamento). Dispone di due strategie: consolidamento dei server offline di base e strategia di consolidamento del carico di lavoro delle VM.
La strategia di consolidamento server offline di base riduce al minimo il numero totale di server utilizzati e riduce al minimo anche il numero di migrazioni.
La strategia di base richiede le seguenti metriche:
metrica
ufficio
plugins
commento
calcolo.nodo.cpu.percent
nessuna
cpu_util
nessuna
Parametri della strategia: migration_attempts: numero di combinazioni per cercare potenziali candidati per l'arresto (impostazione predefinita, 0, nessuna restrizione), periodo: intervallo di tempo in secondi per ottenere l'aggregazione statica dall'origine dati metrica (impostazione predefinita, 700).
Metodi utilizzati: migrazione, modifica dello stato del servizio nova (change_nova_service_state).
La strategia di consolidamento del carico di lavoro delle VM si basa su un'euristica di primo adattamento che si concentra sul carico misurato della CPU e tenta di ridurre al minimo i nodi che hanno un carico eccessivo o insufficiente dati i vincoli di capacità delle risorse. Questa strategia fornisce una soluzione che si traduce in un utilizzo più efficiente delle risorse del cluster utilizzando i seguenti quattro passaggi:
- Fase di scarico: elaborazione delle risorse sovrautilizzate;
- Fase di consolidamento: gestione delle risorse sottoutilizzate;
- Ottimizzazione della soluzione - riduzione del numero di migrazioni;
- Disabilitazione dei nodi di calcolo inutilizzati.
La strategia richiede le seguenti metriche:
metrica
ufficio
plugins
commento
memoria
nessuna
disco.root.dimensione
nessuna
Le seguenti metriche sono facoltative ma miglioreranno l'accuratezza della strategia, se disponibili:
metrica
ufficio
plugins
commento
memoria.residente
nessuna
cpu_util
nessuna
Parametri della strategia: periodo: intervallo di tempo in secondi per ottenere l'aggregazione statica dall'origine dati metrici (impostazione predefinita, 3600).
Utilizza gli stessi metodi della strategia precedente. Più dettagli .
Bilanciamento del carico di lavoro — bilanciare il carico di lavoro tra i nodi informatici. L'obiettivo prevede tre strategie: strategia di migrazione del bilanciamento del carico di lavoro, stabilizzazione del carico di lavoro, strategia di bilanciamento della capacità di storage.
La strategia di migrazione del bilanciamento del carico di lavoro esegue le migrazioni delle macchine virtuali in base al carico di lavoro della macchina virtuale host. Una decisione di migrazione viene presa ogni volta che la percentuale di utilizzo della CPU o della RAM di un nodo supera la soglia specificata. In questo caso, la macchina virtuale spostata dovrebbe avvicinare il nodo al carico di lavoro medio di tutti i nodi.
Requisiti
- Utilizzo di processori fisici;
- Almeno due nodi di calcolo fisici;
- Installato e configurato il componente Ceilometer - ceilometer-agent-compute, in esecuzione su ciascun nodo di calcolo e l'API Ceilometer, oltre a raccogliere i seguenti parametri:
metrica
ufficio
plugins
commento
cpu_util
nessuna
memoria.residente
nessuna
Parametri della strategia:
parametro
тип
per impostazione predefinita
descrizione
metrica
Corda
'cpu_util'
Le metriche sottostanti sono: "cpu_util", "memory.resident".
soglia
Numero
25.0
Soglia del carico di lavoro per la migrazione.
periodo
Numero
300
Ceilometro del periodo di tempo cumulativo.
Il metodo utilizzato è la migrazione.
La stabilizzazione del carico di lavoro è una strategia volta a stabilizzare il carico di lavoro utilizzando la migrazione in tempo reale. La strategia si basa su un algoritmo di deviazione standard e determina se c'è una congestione nel cluster e risponde ad essa attivando la migrazione della macchina per stabilizzare il cluster.
Requisiti
- Utilizzo di processori fisici;
- Almeno due nodi di calcolo fisici;
- Installato e configurato il componente Ceilometer - ceilometer-agent-compute, in esecuzione su ciascun nodo di calcolo e l'API Ceilometer, oltre a raccogliere i seguenti parametri:
metrica
ufficio
plugins
commento
cpu_util
nessuna
memoria.residente
nessuna
Strategia di bilanciamento della capacità di archiviazione (strategia implementata a partire da Queens): la strategia trasferisce i dischi in base al carico sui pool Cinder. Una decisione di trasferimento viene presa ogni volta che il tasso di utilizzo del pool supera una soglia specificata. Il disco spostato dovrebbe avvicinare il pool al carico medio di tutti i pool Cinder.
Requisiti e restrizioni
- Minimo due pool di Cinder;
- Possibilità di migrazione del disco.
- Modello dati cluster: raccoglitore di modelli dati cluster Cinder.
Parametri della strategia:
parametro
тип
per impostazione predefinita
descrizione
soglia_volume
Numero
80.0
Valore soglia dei dischi per il bilanciamento dei volumi.
Il metodo utilizzato è la migrazione del disco (volume_migrate).
Vicino rumoroso: identifica e migra un "vicino rumoroso", una macchina virtuale a bassa priorità che sta incidendo negativamente sulle prestazioni di una macchina virtuale ad alta priorità in termini di IPC utilizzando eccessivamente la cache di ultimo livello. Strategia propria: Noisy Neighbor (il parametro della strategia utilizzato è cache_threshold (il valore predefinito è 35), quando le prestazioni scendono al valore specificato, viene avviata la migrazione. Affinché la strategia funzioni, abilitata Metriche LLC (Last Level Cache), ultimo server Intel con supporto CMT, oltre a raccogliere le seguenti metriche:
metrica
ufficio
plugins
commento
cpu_l3_cache
nessuna
Intel richiesta .
Modello dati cluster (predefinito): raccoglitore modello dati cluster Nova. Il metodo utilizzato è la migrazione.
Il lavoro con questo obiettivo tramite la Dashboard non è completamente implementato nel Queens.
Ottimizzazione termica — ottimizzare il regime di temperatura. La temperatura di uscita (aria di scarico) è uno dei sistemi di telemetria termica più importanti per misurare lo stato termico/del carico di lavoro di un server. L'obiettivo ha una strategia, la strategia basata sulla temperatura di uscita, che decide di migrare i carichi di lavoro su host termicamente favorevoli (temperatura di uscita più bassa) quando la temperatura di uscita degli host di origine raggiunge una soglia configurabile.
Affinché la strategia funzioni, è necessario un server con Intel Power Node Manager installato e configurato , oltre a raccogliere le seguenti metriche:
metrica
ufficio
plugins
commento
hardware.ipmi.node.outlet_temperature
IPMI
Parametri della strategia:
parametro
тип
per impostazione predefinita
descrizione
soglia
Numero
35.0
Soglia di temperatura per la migrazione.
periodo
Numero
30
L'intervallo di tempo, in secondi, per ottenere l'aggregazione statistica dall'origine dati metrici.
Il metodo utilizzato è la migrazione.
Ottimizzazione del flusso d'aria — ottimizzare la modalità di ventilazione. Strategia propria: flusso d'aria uniforme utilizzando la migrazione in tempo reale. La strategia attiva la migrazione della macchina virtuale ogni volta che il flusso d'aria proveniente dalla ventola del server supera una soglia specificata.
Perché la strategia funzioni è necessario:
- Hardware: nodi di calcolo <supporto NodeManager 3.0;
- Almeno due nodi di calcolo;
- Il componente ceilometer-agent-compute e Ceilometer API installato e configurato su ciascun nodo di elaborazione, che può riportare con successo parametri quali flusso d'aria, potenza del sistema, temperatura di ingresso:
metrica
ufficio
plugins
commento
hardware.ipmi.node.airflow
IPMI
temperatura.del.nodo.hardware.ipmi
IPMI
hardware.ipmi.node.power
IPMI
Affinché la strategia funzioni, è necessario un server con Intel Power Node Manager 3.0 o versione successiva installato e configurato.
Limitazioni: il concept non è destinato alla produzione.
Si propone di utilizzare questo algoritmo con controlli continui, poiché è prevista la migrazione di una sola macchina virtuale per iterazione.
Sono possibili migrazioni in tempo reale.
Parametri della strategia:
parametro
тип
per impostazione predefinita
descrizione
soglia_flusso d'aria
Numero
400.0
La soglia del flusso d'aria per l'unità di migrazione è 0.1 CFM
soglia_ingresso_t
Numero
28.0
Soglia della temperatura in ingresso per la decisione sulla migrazione
soglia_potenza
Numero
350.0
Soglia di potenza del sistema per la decisione di migrazione
periodo
Numero
30
L'intervallo di tempo, in secondi, per ottenere l'aggregazione statistica dall'origine dati metrici.
Il metodo utilizzato è la migrazione.
Manutenzione dell'hardware — manutenzione dell'hardware. La strategia correlata a questo obiettivo è la migrazione delle zone. La strategia è uno strumento per un'efficace migrazione automatica e minima di macchine virtuali e dischi in caso di necessità di manutenzione dell'hardware. La strategia costruisce un piano d’azione in base ai pesi: un insieme di azioni che hanno più peso verranno pianificate prima delle altre. Sono disponibili due opzioni di configurazione: action_weights e parallelizzazione.
Limitazioni: i pesi delle azioni e la parallelizzazione devono essere configurati.
Parametri della strategia:
parametro
тип
per impostazione predefinita
descrizione
compute_nodes
schieramento
Nessuna
Nodi di calcolo per la migrazione.
storage_pools
schieramento
Nessuna
Nodi di archiviazione per la migrazione.
parallelo_totale
numero intero
6
Il numero totale di attività che devono essere eseguite in parallelo.
parallelo_per_nodo
numero intero
2
Il numero di azioni eseguite in parallelo per ciascun nodo di calcolo.
parallel_per_pool
numero intero
2
Il numero di azioni eseguite in parallelo per ciascun pool di archiviazione.
priorità
oggetto
Nessuna
Elenco di priorità per macchine virtuali e dischi.
con_volume_allegato
booleano
Falso
Falso: la migrazione delle macchine virtuali verrà eseguita dopo la migrazione di tutti i dischi. Vero: la migrazione delle macchine virtuali verrà eseguita dopo la migrazione di tutti i dischi connessi.
Elementi dell'array di nodi di calcolo:
parametro
тип
per impostazione predefinita
descrizione
nodo_src
stringa
Nessuna
Il nodo di calcolo da cui viene eseguita la migrazione delle macchine virtuali (obbligatorio).
dst_node
stringa
Nessuna
Calcola il nodo su cui stanno migrando le macchine virtuali.
Elementi dell'array del nodo di archiviazione:
parametro
тип
per impostazione predefinita
descrizione
src_pool
stringa
Nessuna
Il pool di archiviazione da cui viene eseguita la migrazione dei dischi (obbligatorio).
dst_pool
stringa
Nessuna
Il pool di archiviazione in cui vengono migrati i dischi.
tipo_src
stringa
Nessuna
Tipo di disco originale (richiesto).
dst_type
stringa
Nessuna
Il tipo di disco risultante (obbligatorio).
Elementi di priorità dell'oggetto:
parametro
тип
per impostazione predefinita
descrizione
progetto
schieramento
Nessuna
Nomi dei progetti.
nodo_di calcolo
schieramento
Nessuna
Calcola i nomi dei nodi.
storage_pool
schieramento
Nessuna
Nomi dei pool di archiviazione.
computare
enum
Nessuna
Parametri della macchina virtuale ["vcpu_num", "mem_size", "disk_size", "created_at"].
conservazione
enum
Nessuna
Parametri del disco [“dimensione”, “creato_at”].
I metodi utilizzati sono la migrazione della macchina virtuale, la migrazione del disco.
Non classificati - un obiettivo ausiliario utilizzato per facilitare il processo di sviluppo della strategia. Non contiene specifiche e può essere utilizzata ogni volta che la strategia non è ancora associata ad un obiettivo esistente. Questo obiettivo può essere utilizzato anche come punto di transizione. Una strategia correlata a questo obiettivo è Actuator.
Creare un nuovo obiettivo
Motore decisionale dell'osservatore ha un'interfaccia plug-in "obiettivo esterno" che consente di integrare un obiettivo esterno che può essere raggiunto utilizzando una strategia.
Prima di creare un nuovo obiettivo, dovresti assicurarti che nessun obiettivo esistente soddisfi le tue esigenze.
Creazione di un nuovo plugin
Per creare un nuovo target, è necessario: estendere la classe target, implementare un metodo della classe prendi_nome() per restituire l'ID univoco del nuovo target che desideri creare. Questo identificatore univoco deve corrispondere al nome del punto di ingresso dichiarato in seguito.
Successivamente è necessario implementare il metodo class get_nome_visualizzato() per restituire il nome visualizzato tradotto della destinazione che desideri creare (non utilizzare una variabile per restituire la stringa tradotta in modo che possa essere raccolta automaticamente dallo strumento di traduzione).
Implementare un metodo di classe get_translatable_display_name()per restituire la chiave di traduzione (in realtà il nome visualizzato in inglese) del tuo nuovo target. Il valore restituito deve corrispondere alla stringa tradotta in get_display_name().
Implementa il suo metodo get_efficacia_specifica()per restituire le specifiche di efficienza per l'obiettivo. Il metodo get_efficacy_specification() restituisce l'istanza Unclassified() fornita da Watcher. Questa specifica di prestazione è utile nel processo di sviluppo del tuo obiettivo perché corrisponde alla specifica vuota.
→
Architettura Watcher (maggiori dettagli) ).
Componenti
API dell'osservatore - un componente che implementa l'API REST fornita da Watcher. Meccanismi di interazione: CLI, plugin Horizon, Python SDK.
DB Osservatore — Banca dati degli osservatori.
Applicatore osservatore — un componente che implementa l'esecuzione di un piano d'azione creato dal componente Watcher Decision Engine.
Motore decisionale dell'osservatore - Il componente responsabile del calcolo di una serie di potenziali azioni di ottimizzazione per raggiungere l'obiettivo dell'audit. Se non viene specificata una strategia, il componente seleziona autonomamente quella più appropriata.
Editore delle metriche di Watcher - Un componente che raccoglie e calcola alcuni parametri o eventi e li pubblica sull'endpoint CEP. La funzionalità del componente può essere fornita anche dall'editore Ceilometer.
Motore di elaborazione di eventi complessi (CEP). — motore per l'elaborazione di eventi complessi. Per motivi di prestazioni, potrebbero essere presenti più istanze del motore CEP in esecuzione contemporaneamente, ciascuna delle quali elabora un tipo specifico di parametro/evento. Nel sistema Watcher, CEP attiva due tipologie di azioni: - registrare gli eventi/metriche corrispondenti nel database delle serie temporali; - inviare eventi appropriati al Watcher Decision Engine quando questo evento può influenzare il risultato dell'attuale strategia di ottimizzazione, poiché il cluster Openstack non è un sistema statico.
I componenti interagiscono utilizzando il protocollo AMQP.
→
Schema di interazione con Watcher
Risultati del test dell'osservatore
- Nella pagina Ottimizzazione - Piani d'azione 500 (sia su Queen pure che su stand con moduli Tionix), appare solo dopo aver avviato l'audit e generato un piano d'azione; quello vuoto si apre normalmente.
- Sono presenti errori nella scheda Dettagli azione, non è possibile ottenere l'obiettivo e la strategia dell'audit (sia su Regine pure che su uno stand con moduli Tionix).
- Gli audit con lo scopo di Dummy (test) vengono creati e avviati normalmente, vengono generati piani d'azione.
- I controlli per l'obiettivo Non classificato non vengono creati perché l'obiettivo non è funzionale ed è destinato alla configurazione intermedia durante la creazione di nuove strategie.
- I controlli ai fini del bilanciamento del carico di lavoro (strategia di bilanciamento della capacità di storage) vengono creati correttamente, ma non viene generato un piano d'azione. Non è richiesta alcuna ottimizzazione del pool di archiviazione.
- I controlli per l'obiettivo di bilanciamento del carico di lavoro (strategia di migrazione del bilanciamento del carico di lavoro) vengono creati correttamente, ma non viene generato un piano d'azione.
- I controlli per il bilanciamento del carico di lavoro (strategia di stabilizzazione del carico di lavoro) falliscono.
- I controlli per la destinazione Noisy Neighbor vengono creati correttamente, ma non viene generato un piano d'azione.
- Gli audit ai fini della manutenzione dell'hardware vengono creati con successo, il piano d'azione non viene generato completamente (vengono generati gli indicatori di prestazione, ma l'elenco delle azioni stesso non viene generato).
- Le modifiche nelle configurazioni nova.conf (nella sezione predefinita compute_monitors = cpu.virt_driver) sui nodi di calcolo e controllo non correggono gli errori.
- Anche i controlli mirati al consolidamento dei server (strategia di base) falliscono.
- I controlli ai fini del consolidamento del server (strategia di consolidamento del carico di lavoro della VM) falliscono con un errore. Nei log si è verificato un errore nell'ottenimento dei dati di origine. Discussione dell'errore, in particolare .
Abbiamo provato a specificare Watcher nel file di configurazione (non ha aiutato: a causa di un errore su tutte le pagine di ottimizzazione, il ritorno al contenuto originale del file di configurazione non corregge la situazione): [watcher_strategies.basic] datasource = ceilometer, gnocchi - Gli audit per il risparmio energetico falliscono. A giudicare dai log, il problema è ancora l'assenza di Ironic; non funzionerà senza il servizio baremetal.
- I controlli per l'ottimizzazione termica falliscono. Il traceback è lo stesso del consolidamento del server (strategia di consolidamento del carico di lavoro della VM) (errore dei dati di origine)
- I controlli ai fini dell'ottimizzazione del flusso d'aria falliscono con un errore.
Vengono inoltre rilevati i seguenti errori di completamento del controllo. Traceback nei log decision-engine.log (lo stato del cluster non è definito).
→ Discussione dell'errore
conclusione
Il risultato della nostra ricerca durata due mesi è stata la conclusione inequivocabile che per ottenere un sistema di bilanciamento del carico completo e funzionante, dovremo, in questa parte, lavorare a stretto contatto sul perfezionamento degli strumenti per la piattaforma Openstack.
Watcher ha dimostrato di essere un prodotto serio e in rapido sviluppo con un enorme potenziale, il cui pieno utilizzo richiederà molto lavoro serio.
Ma ne parleremo più diffusamente nei prossimi articoli della serie.
Fonte: habr.com