Nelle grandi soluzioni cloud, la questione del bilanciamento automatico o dell'ottimizzazione del carico sulle risorse di calcolo è particolarmente rilevante. Anche noi di Tionix (sviluppatore e operatore di servizi cloud, parte del gruppo Rostelecom) ci siamo occupati di questo tema.
E dato che la nostra piattaforma di sviluppo principale è Openstack, e noi, come tutte le persone, tendiamo alla pigrizia, abbiamo deciso di trovare un modulo già pronto incluso nella piattaforma. La nostra scelta è ricaduta su Watcher, che abbiamo deciso di utilizzare per le nostre esigenze.
Iniziamo a chiarire i termini e le definizioni.
Termini e definizioni
Obiettivo — è un risultato finale leggibile, osservabile e misurabile che deve essere raggiunto. Per il raggiungimento di ogni obiettivo, esiste una o più strategie. Una strategia è l'implementazione di un algoritmo che è in grado di trovare una soluzione per l'obiettivo in questione.
Azione (Action) — è un compito elementare che modifica lo stato attuale della risorsa gestita target del cluster OpenStack, come: migrazione della macchina virtuale (migration), cambio dello stato di alimentazione di un nodo (change_node_power_state), cambio dello stato del servizio nova (change_nova_service_state), modifica del flavor (resize), registrazione di un messaggio NOP (nop), inattività per un certo periodo di tempo — pausa (sleep), migrazione del disco (volume_migrate).
Piano d'azione (Action Plan) — un flusso specifico di azioni intraprese in un certo ordine per raggiungere un obiettivo specifico. Il piano d'azione contiene anche un'efficacia globale stimata con un insieme di indicatori di performance. Il piano d'azione viene generato dal Watcher dopo un audit riuscito, a seguito del quale la strategia utilizzata trova una soluzione per raggiungere l'obiettivo. Il piano d'azione è composto da un elenco di azioni sequenziali.
Audit (Audit) — è una richiesta di ottimizzazione del cluster. L'ottimizzazione viene eseguita per raggiungere un obiettivo specifico in questo cluster. Per ogni audit riuscito, il Watcher genera un piano d'azione.
Ambito dell'audit (Audit Scope) — è un insieme di risorse all'interno delle quali viene eseguita la valutazione (zona(e) di disponibilità, aggregatori di nodi, singoli nodi di calcolo o nodi di storage, ecc.). L'area di valutazione è definita in ogni modello. Se l'area di valutazione non è specificata, viene valutato l'intero cluster.
Modello di valutazione (Audit Template) — un insieme salvato di impostazioni per eseguire una valutazione. I modelli sono necessari per eseguire più volte valutazioni con le stesse impostazioni. Il modello deve contenere l'obiettivo della valutazione; se non vengono indicate strategie, vengono selezionate le più appropriate tra quelle esistenti.
Cluster (Cluster) — è un insieme di macchine fisiche che forniscono risorse di calcolo, risorse di storage e risorse di rete, gestite dallo stesso nodo di controllo OpenStack.
Modello di dati del cluster (Cluster Data Model, CDM) — è una rappresentazione logica dello stato attuale e della topologia delle risorse gestite dal cluster.
Indicatore di efficacia (Efficacy Indicator) — indicatore che mostra come viene eseguita la soluzione creata tramite questa strategia. Gli indicatori di prestazione sono specifici per un determinato obiettivo e vengono generalmente utilizzati per calcolare l'efficacia globale del piano d'azione finale.
Specifiche di efficacia (Efficacy Specification) — è un insieme di caratteristiche specifiche associate a ciascun obiettivo, che definisce vari indicatori di prestazione che la strategia, finalizzata al raggiungimento dell'obiettivo corrispondente, deve garantire nella sua soluzione. Ogni soluzione proposta dalla strategia sarà infatti verificata rispetto alle specifiche prima di calcolare la sua efficacia globale.
Motore di scoring (Scoring Engine) — è un file eseguibile che ha input chiaramente definiti, output chiaramente definiti e svolge un compito puramente matematico. Pertanto, il calcolo non dipende dall'ambiente in cui viene eseguito: produrrà lo stesso risultato ovunque.
Pianificatore Watcher (Watcher Planner) — parte del meccanismo di decisione di Watcher. Questo modulo accetta un insieme di azioni generate dalla strategia e crea un piano di lavoro che definisce come pianificare nel tempo queste diverse azioni e, per ogni azione, quali sono le condizioni preliminari.
Obiettivi e strategie di Watcher
Obiettivo
Strategie
Obiettivo fittizio
Strategia fittizia
Strategia fittizia che utilizza motori di scoring esemplificativi
Strategia fittizia con ridimensionamento
Risparmio energetico
Strategia di risparmio energetico
Consolidamento server
Consolidamento server offline di base
Strategia di consolidamento carico di lavoro VM
Bilanciamento del carico di lavoro
Strategia di migrazione del bilanciamento del carico di lavoro
Strategia di bilanciamento della capacità di archiviazione
Stabilizzazione del carico di lavoro
Vicino rumoroso
Vicino rumoroso
Ottimizzazione termica
Strategia basata sulla temperatura di uscita
Ottimizzazione del flusso d'aria
Strategia di migrazione del flusso d'aria uniforme
Manutenzione hardware
Migrazione della zona
Non classificato
Attuatore
Obiettivo fittizio — obiettivo riservato utilizzato per scopi di test.
Strategie collegate: Strategia fittizia, Strategia fittizia che utilizza motori di scoring esemplificativi e strategia fittizia con ridimensionamento. La strategia fittizia è una strategia di prova utilizzata per il testing di integrazione tramite Tempest. Questa strategia non fornisce alcuna ottimizzazione utile, il suo unico obiettivo è utilizzare i test Tempest.
Strategia fittizia che utilizza motori di scoring campione — la strategia è simile alla precedente, ma si distingue per l'uso di un "motore di valutazione" che calcola utilizzando metodi di machine learning.
Strategia fittizia con ridimensionamento — la strategia è simile alla precedente, ma si differenzia per l'uso della modifica della dimensione (migrazione e ridimensionamento).
Non utilizzato in produzione.
Risparmio energetico — ridurre il consumo energetico. La strategia Saving Energy Strategy, insieme alla strategia VM Workload Consolidation Strategy (Server Consolidation), è in grado di svolgere funzioni di gestione dinamica dell'alimentazione (DPM), risparmiando elettricità grazie alla consolidazione dinamica dei carichi di lavoro anche durante i periodi di bassa utilizzo delle risorse: le macchine virtuali vengono spostate su un numero ridotto di nodi, mentre i nodi non necessari vengono spenti. Dopo la consolidazione, la strategia propone una soluzione per accendere/spegnere i nodi in base ai parametri definiti: “min_free_hosts_num” — numero di nodi liberi accesi in attesa di carico, e “free_used_percent” — rapporto percentuale dei nodi liberi accesi rispetto al numero di nodi occupati da macchine. Per funzionare, la strategia deve essere attivata e configurata Ironic per gestire l'accensione/spegnimento dell'alimentazione sui nodi.
Parametri della strategia
parametro
tipo
predefinito
descrizione
free_used_percent
Numero
10.0
rapporto tra il numero di nodi computazionali liberi e il numero totale di nodi computazionali con macchine virtuali
min_free_hosts_num
Int
1
numero minimo di nodi computazionali disponibili
Nel cloud devono esserci almeno due nodi. Il metodo utilizzato è il cambiamento dello stato di alimentazione del nodo (change_node_power_state). La strategia di raccolta delle metriche non è richiesta.
Server Consolidation — minimizzare il numero di nodi computazionali (consolidamento). Presenta due strategie: Basic Offline Server Consolidation e VM Workload Consolidation Strategy.
La strategia Basic Offline Server Consolidation riduce il numero complessivo di server utilizzati e minimizza anche il numero di migrazioni.
La strategia base richiede le seguenti metriche:
metrica
servizio
plugin
commento
compute.node.cpu.percent
none
cpu_util
none
Parametri della strategia: migration_attempts — numero di combinazioni per cercare potenziali candidati da spegnere (di default, 0, nessuna limitazione), period — intervallo di tempo in secondi per ottenere un'aggregazione statica dalla fonte dati metrica (di default, 700).
Metodi utilizzati: migrazione, cambiamento dello stato del servizio nova (change_nova_service_state).
La Strategia di Consolidamento del Carico di Lavoro VM si basa su un algoritmo euristico di primo adatto (first-fit), che si concentra sul carico misurato della CPU e cerca di ridurre al minimo i nodi che hanno un carico eccessivo o insufficiente, tenendo conto delle limitazioni della capacità delle risorse. Questa strategia offre una soluzione che porta a un uso più efficiente delle risorse del cluster, seguendo questi quattro passaggi:
- Fase di scarico — gestione delle risorse sovrasfruttate;
- Fase di consolidamento — gestione delle risorse sottoutilizzate;
- Ottimizzazione della soluzione — riduzione del numero di migrazioni;
- Disattivazione dei nodi computazionali non utilizzati.
La strategia richiede le seguenti metriche:
metrica
servizio
plugin
commento
memory
none
disk.root.size
none
Le seguenti metriche non sono obbligatorie, ma aumentano l'accuratezza della strategia se disponibili:
metrica
servizio
plugin
commento
memory.resident
none
cpu_util
none
Parametri della strategia: period — intervallo di tempo in secondi per l'aggregazione statica da una fonte di dati delle metriche (di default, 3600).
Utilizza gli stessi metodi della strategia precedente. Maggiori dettagli. .
Bilanciamento del carico di lavoro — bilanciare il carico di lavoro tra i nodi di calcolo. L’obiettivo ha tre strategie: Strategia di Migrazione del Bilanciamento del Carico di Lavoro, Stabilizzazione del Carico di Lavoro, Strategia di Bilanciamento della Capacità di Archiviazione.
La Strategia di Migrazione del Bilanciamento del Carico di Lavoro avvia migrazioni delle macchine virtuali basate sul carico di lavoro delle macchine virtuali dei nodi. La decisione di trasferire viene presa ogni volta che l'utilizzo della CPU o della RAM di un nodo supera la soglia specificata. Inoltre, la macchina virtuale spostata deve avvicinare il nodo alla media del carico di lavoro di tutti i nodi.
Requisiti
- Utilizzo di processori fisici;
- Minimo due nodi di calcolo fisici;
- Componente Ceilometer installato e configurato: ceilometer-agent-compute, funzionante su ciascun nodo di calcolo, e Ceilometer API, oltre alla raccolta delle seguenti metriche:
metrica
servizio
plugin
commento
cpu_util
none
memory.resident
none
Parametri della strategia:
parametro
tipo
predefinito
descrizione
metriche
Stringa
‘cpu_util’
Metriche fondamentali: ‘cpu_util’, ‘memory.resident’.
threshold
Numero
25.0
Soglia del carico di lavoro per la migrazione.
period
Numero
300
Periodo cumulativo di Ceilometer.
Metodo utilizzato: migrazione.
Stabilizzazione del carico di lavoro — una strategia mirata a stabilizzare il carico di lavoro attraverso la migrazione live. Questa strategia si basa su un algoritmo di deviazione standard e determina se esiste un sovraccarico nel cluster, rispondendo attivando la migrazione delle macchine per stabilizzare il cluster.
Requisiti
- Utilizzo di processori fisici;
- Minimo due nodi di calcolo fisici;
- Componente Ceilometer installato e configurato: ceilometer-agent-compute, funzionante su ciascun nodo di calcolo, e Ceilometer API, oltre alla raccolta delle seguenti metriche:
metrica
servizio
plugin
commento
cpu_util
none
memory.resident
none
Strategia di bilanciamento della capacità di archiviazione (strategia implementata a partire da Queens) — la strategia trasferisce i dischi in base al carico dei pool Cinder. La decisione sul trasferimento viene presa ogni volta che il tasso di utilizzo del pool supera la soglia specificata. Il disco trasferito deve avvicinare il pool al carico medio di tutti i pool Cinder.
Requisiti e limitazioni
- Minimo due pool Cinder;
- Possibilità di migrazione dei dischi.
- Modello dati del cluster — raccoglitore del modello dati cluster Cinder.
Parametri della strategia:
parametro
tipo
predefinito
descrizione
volume_threshold
Numero
80.0
Valore soglia per il bilanciamento dei volumi.
Metodo utilizzato — migrazione del disco (volume_migrate).
Noisy Neighbor — identificare e spostare il “vicino rumoroso” — una macchina virtuale a bassa priorità che influisce negativamente sulle prestazioni di una macchina virtuale ad alta priorità in termini di IPC, utilizzando eccessivamente l'Ultimo Livello di Cache. Strategia proprietaria: Noisy Neighbor (parametro strategico utilizzato — cache_threshold (valore predefinito — 35), quando le prestazioni scendono al valore indicato, viene avviata la migrazione. Per il funzionamento della strategia sono necessarie metriche LLC (Last Level Cache) abilitate. metriche LLC (Last Level Cache), l'ultimo server Intel con supporto CMT, oltre alla raccolta delle seguenti metriche:
metrica
servizio
plugin
commento
cpu_l3_cache
none
Necessario Intel .
Modello di dati del cluster (predefinito): Nova cluster data model collector. Metodo applicato — migrazione.
Lavorare con questo obiettivo tramite Dashboard non è stato completamente implementato in Queens.
Ottimizzazione termica — ottimizzare la gestione termica. La temperatura in uscita (aria di scarico) è uno dei sistemi di telemetria termica fondamentali per misurare lo stato del carico termico / operativo del server. Per questo obiettivo esiste una strategia: la strategia basata sulla temperatura di uscita, che prende decisioni sul trasferimento dei carichi di lavoro verso nodi con una gestione termica favorevole (la temperatura di uscita più bassa), quando la temperatura di uscita degli host sorgente raggiunge la soglia configurabile.
Per l'implementazione della strategia è necessario un server con Intel Power Node Manager installato e configurato , oltre alla raccolta delle seguenti metriche:
metrica
servizio
plugin
commento
hardware.ipmi.node.outlet_temperature
IPMI
Parametri della strategia:
parametro
tipo
predefinito
descrizione
threshold
Numero
35.0
Soglia di temperatura per la migrazione.
period
Numero
30
Intervallo di tempo in secondi per l'aggregazione statistica dal fonte dati della metrica.
Metodo utilizzato: migrazione.
Ottimizzazione del flusso d'aria — ottimizzare la modalità di ventilazione. La strategia proprietaria è il Flusso d'Aria Uniforme con migrazione live. La strategia avvia la migrazione della macchina virtuale ogni volta che il flusso d'aria dal ventilatore del server supera la soglia specificata.
Per l'implementazione della strategia sono necessari:
- Hardware: nodi computazionali <con supporto per NodeManager 3.0;
- Almeno due nodi computazionali;
- Un componente ceilometer-agent-compute installato e configurato su ogni nodo computazionale e Ceilometer API, in grado di segnalare con successo metriche come il flusso d'aria, la potenza del sistema e la temperatura in ingresso:
metrica
servizio
plugin
commento
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Per l'implementazione della strategia è necessario un server con Intel Power Node Manager 3.0 o versione successiva installato e configurato.
Limitazioni: il concetto non è destinato all'uso in produzione.
Si consiglia di utilizzare questo algoritmo con audit continui, poiché in un'unica iterazione è prevista la migrazione di una sola macchina virtuale.
Sono possibili migrazioni in tempo reale.
Parametri della strategia:
parametro
tipo
predefinito
descrizione
threshold_airflow
Numero
400.0
Soglia di flusso d'aria per la migrazione. L'unità è 0.1CFM
threshold_inlet_t
Numero
28.0
Soglia di temperatura in ingresso per la decisione di migrazione
threshold_power
Numero
350.0
Soglia di potenza del sistema per la decisione di migrazione
period
Numero
30
Intervallo di tempo in secondi per l'aggregazione statistica dal fonte dati della metrica.
Metodo utilizzato: migrazione.
Manutenzione hardware — manutenzione hardware. La strategia relativa a questo obiettivo è la migrazione della zona. Questa strategia è uno strumento per la migrazione automatica e minimizzata delle macchine virtuali e dei dischi in caso di necessità di manutenzione hardware. La strategia definisce un piano d'azione in base ai pesi: un insieme di azioni con un peso maggiore sarà programmato prima di altre. Ci sono due parametri di configurazione: pesi delle azioni (action_weights) e parallelizzazione (parallelization).
Vincoli: è necessaria la configurazione dei pesi delle azioni e della parallelizzazione.
Parametri della strategia:
parametro
tipo
predefinito
descrizione
nodi_computazionali
array
Nessuno
Nodi computazionali per la migrazione.
pools_di_archiviazione
array
Nessuno
Nodi di archiviazione per la migrazione.
parallel_totale
intero
6
Numero totale di azioni che devono essere eseguite in parallelo.
parallel_per_nodo
intero
2
Numero di azioni eseguite in parallelo per ogni nodo computazionale.
parallel_per_pool
intero
2
Numero di azioni eseguite in parallelo per ogni pool di archiviazione.
priorità
oggetto
Nessuno
Elenco delle priorità per le macchine virtuali e i dischi.
con_volume_allegato
booleano
Falso
Falso — le macchine virtuali saranno trasferite dopo il trasferimento di tutti i dischi. Vero — le macchine virtuali saranno trasferite dopo la migrazione di tutti i dischi connessi.
Elementi dell'array dei nodi di calcolo:
parametro
tipo
predefinito
descrizione
src_node
stringa
Nessuno
Nodo di calcolo da cui vengono trasferite le macchine virtuali (obbligatorio).
dst_node
stringa
Nessuno
Nodo di calcolo a cui migrare le macchine virtuali.
Elementi dell'array dei nodi di archiviazione:
parametro
tipo
predefinito
descrizione
src_pool
stringa
Nessuno
Pool di archiviazione da cui vengono trasferiti i dischi (obbligatorio).
dst_pool
stringa
Nessuno
Pool di archiviazione a cui vengono trasferiti i dischi.
src_type
stringa
Nessuno
Tipo di disco sorgente (obbligatorio).
dst_type
stringa
Nessuno
Tipo di disco di destinazione (obbligatorio).
Elementi di priorità degli oggetti:
parametro
tipo
predefinito
descrizione
project
array
Nessuno
Nomi dei progetti.
compute_node
array
Nessuno
Nomi dei nodi di calcolo.
storage_pool
array
Nessuno
Nomi dei pool di archiviazione.
compute
enum
Nessuno
Parametri della macchina virtuale [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
storage
enum
Nessuno
Parametri dei dischi [“size”, “created_at”].
Metodi utilizzati — migrazione delle macchine virtuali, migrazione dei dischi.
Non classificato — obiettivo ausiliario, utilizzato per semplificare il processo di sviluppo della strategia. Non contiene specifiche e può essere utilizzato ogni volta che la strategia non è ancora collegata a un obiettivo esistente. Questo obiettivo può anche essere usato come fase transitoria. La strategia collegata a questo obiettivo è — Actuator.
Creazione di un nuovo obiettivo
Watcher Decision Engine ha un'interfaccia plugin per il "target esterno", che consente di integrare un obiettivo esterno, che può essere raggiunto tramite la strategia.
Prima di creare un nuovo obiettivo, assicurati che nessuno degli obiettivi esistenti soddisfi le tue esigenze.
Creazione di un nuovo plugin
Per creare un nuovo obiettivo, devi: estendere la classe dell'obiettivo, implementare il metodo della classe get_name () per restituire un identificatore unico del nuovo obiettivo che desideri creare. Questo identificatore unico deve corrispondere al nome del punto di ingresso che dichiari in seguito.
Successivamente, è necessario implementare il metodo della classe get_display_name () per restituire il nome visualizzato tradotto dell'obiettivo che desideri creare (non utilizzare una variabile per restituire la stringa tradotta affinché possa essere automaticamente raccolta dallo strumento di traduzione).
Implementa il metodo della classe get_translatable_display_name (), per restituire la chiave di traduzione (in effetti il nome visualizzato in inglese) del tuo nuovo obiettivo. Il valore restituito deve corrispondere alla stringa tradotta in get_display_name ().
Implementa il suo metodo get_efficacy_specification (), per restituire la specifica di efficienza per il tuo obiettivo. Il metodo get_efficacy_specification () restituisce un'istanza di Unclassified (), fornita da Watcher. Questa specifica di efficienza è utile durante lo sviluppo del tuo obiettivo, poiché corrisponde a una specifica vuota.
→
Architettura di Watcher (ulteriori dettagli ).
Componenti
Watcher API — componente che implementa l'API REST fornita da Watcher. Meccanismi di interazione: CLI, plug-in Horizon, Python SDK.
Watcher DB — database di Watcher.
Watcher Applier — componente che implementa l'esecuzione del piano d'azione creato dal componente Watcher Decision Engine.
Watcher Decision Engine — un componente responsabile del calcolo di un insieme di azioni potenziali per l'ottimizzazione in base all'obiettivo dell'audit. Se non viene specificata una strategia, il componente seleziona autonomamente l'opzione più adatta.
Watcher Metrics Publisher — un componente che raccoglie e calcola alcune metriche o eventi e li pubblica nel punto finale CEP. Le funzionalità del componente possono essere fornite anche dal publisher Ceilometer.
Complex Event Processing (CEP) Engine — un motore di elaborazione complessa degli eventi. Per motivi di prestazioni, possono esserci più istanze di CEP Engine che operano simultaneamente, ognuna delle quali elabora un determinato tipo di metrica / evento. Nel sistema Watcher, il CEP avvia due tipi di azioni: — registrare eventi / metriche pertinenti nel database di serie temporali; — inviare eventi pertinenti al componente Watcher Decision Engine, quando questo evento può influenzare il risultato dell'attuale strategia di ottimizzazione, poiché il cluster OpenStack non è un sistema statico.
L'interazione tra i componenti avviene tramite il protocollo AMQP.
→
Schema di interazione con Watcher
Risultati dei test di Watcher
- Nella pagina Optimization — Action plans si verifica un errore 500 (sia su Queens pulito che su un stand con i moduli Tionix) solo dopo l'avvio dell'audit e la generazione del piano d'azione; la pagina vuota si apre normalmente.
- Nella scheda Action details si verificano errori, non è possibile ottenere l'obiettivo e la strategia dell'audit (sia su Queens pulito che su un stand con i moduli Tionix).
- Gli audit con obiettivo Dummy (test) vengono creati e avviati normalmente, con piani d'azione generati.
- Gli audit con obiettivo Unclassified non vengono creati, poiché l'obiettivo non è funzionale ed è previsto per la configurazione intermedia durante la creazione di nuove strategie.
- Gli audit con obiettivo Workload Balancing (strategia Storage Capacity balance) vengono creati con successo, tuttavia il piano d'azione non viene generato. Non è necessaria l'ottimizzazione dei pool di storage.
- Gli audit con obiettivo Workload Balancing (strategia Workload Balance Migration Strategy) vengono creati con successo, tuttavia il piano d'azione non viene generato.
- Gli audit con obiettivo Workload Balancing (strategia Workload Stabilization Strategy) terminano con un errore.
- Gli audit con obiettivo Noisy Neighbor vengono creati con successo, tuttavia il piano d'azione non viene generato.
- Gli audit per la manutenzione hardware vengono creati con successo, il piano d'azione non viene generato completamente (vengono generati indicatori di prestazione, ma non viene generato l'elenco delle azioni).
- Le modifiche nei file di configurazione nova.conf (nella sezione default compute_monitors = cpu.virt_driver) sui nodi di calcolo e di gestione non correggono gli errori.
- Gli audit per la consolidazione dei server (strategia Base) terminano anch'essi con un errore.
- Gli audit per la consolidazione dei server (strategia di consolidamento del carico di lavoro VM) terminano con un errore. Nei log si registra un errore nel recupero dei dati di origine. Discussione sull'errore, in particolare, .
Abbiamo provato a indicare nel file di configurazione di Watcher (non ha funzionato: di conseguenza, si verificano errori su tutte le pagine di ottimizzazione, il ripristino al contenuto originale del file di configurazione non risolve la situazione):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Gli audit per il risparmio energetico terminano con un errore. A giudicare dai log, il problema sembra essere nella mancanza di Ironic, non funzionerà senza il servizio baremetal.
- Gli audit per l'ottimizzazione termica terminano con un errore. Il traceback è lo stesso di quello per la consolidazione dei server (strategia di consolidamento del carico di lavoro VM) (errore nei dati di origine)
- Gli audit per l'ottimizzazione di Airflow terminano con un errore.
Si verificano anche i seguenti errori al termine dell'audit. Traceback nei log decision-engine.log (stato del cluster non definito).
→ Discussione dell'errore
Conclusione
Il risultato delle nostre ricerche durate due mesi è chiaro: per ottenere un sistema di bilanciamento del carico completo e funzionante, dovremo lavorare intensamente sullo sviluppo degli strumenti per la piattaforma Openstack.
Watcher si è dimostrato un prodotto serio e in rapida evoluzione con un enorme potenziale, per il pieno utilizzo del quale sarà necessaria una grande e seria opera.
Ma di questo parleremo nei prossimi articoli del ciclo.
Fonte: habr.com
