Nelle grandi sistemi di cloud, la questione del bilanciamento automatico o dell'equilibrio del carico sulle risorse di calcolo è particolarmente pressante. Anche Tionix (sviluppatore e operatore di servizi cloud, appartenente al gruppo di aziende Rostelecom) si è occupata di questo problema.
E poiché la nostra principale piattaforma di sviluppo è Openstack, e noi, come tutte le persone, siamo pigri, è stata presa la decisione di scegliere 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 raggiungere ogni obiettivo, esiste una o più strategie. Una strategia è l'implementazione di un algoritmo in grado di trovare una soluzione per il dato obiettivo.
Azione (Action) è un compito elementare che modifica lo stato attuale della risorsa controllata del cluster OpenStack, come: migrazione di una macchina virtuale (migration), cambiamento dello stato di alimentazione di un nodo (change_node_power_state), modifica dello stato del servizio nova (change_nova_service_state), modifica del flusso (resize), registrazione di un messaggio NOP (nop), nessuna azione per un periodo di tempo determinato - pausa (sleep), migrazione di un disco (volume_migrate).
Piano d'azione (Action Plan) è un flusso specifico di azioni eseguite in un ordine determinato per raggiungere un obiettivo specifico. Il piano d'azione contiene anche un'efficacia globale valutabile con un insieme di indicatori di prestazione. Il piano d'azione è generato da Watcher dopo un audit andato a buon fine, durante il quale la strategia utilizzata trova una soluzione per raggiungere l'obiettivo. Il piano d'azione consiste in un elenco di azioni sequenziali.
Audit (Audit) è una richiesta di ottimizzazione del cluster. L'ottimizzazione viene effettuata per raggiungere un obiettivo nel cluster specificato. Per ogni audit riuscito, Watcher genera un piano d'azione.
Ambito di audit (Audit Scope) — è un insieme di risorse all'interno del quale viene effettuata l'audit (zona(e) di accessibilità, aggregatori di nodi, singoli nodi di calcolo o nodi di archiviazione, ecc.). L'area di audit è definita in ogni modello. Se l'area di audit non è specificata, viene eseguita l'audit dell'intero cluster.
Modello di audit (Audit Template) — un insieme di impostazioni salvate per l'esecuzione dell'audit. I modelli sono necessari per eseguire ripetutamente audit con le stesse impostazioni. Il modello deve contenere necessariamente l'obiettivo dell'audit; se le strategie non sono specificate, vengono selezionate le più appropriate tra quelle esistenti.
Cluster (Cluster) — è un insieme di macchine fisiche che forniscono risorse di calcolo, risorse di archiviazione e risorse di rete e sono gestite dallo stesso nodo di controllo di OpenStack.
Modello 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) — è un indicatore che mostra come si svolge la soluzione creata con questa strategia. Gli indicatori di efficacia sono specifici per l'obiettivo concreto e sono 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 efficacia che la strategia, che garantisce il raggiungimento del corrispondente obiettivo, deve assicurare nella sua soluzione. Infatti, ogni soluzione proposta dalla strategia sarà verificata rispetto alla specifica, prima di calcolarne l'efficacia globale.
Motore di punteggio (Scoring Engine) — è un eseguibile che ha ingressi chiaramente definiti, uscite chiaramente definite e svolge un compito puramente matematico. Pertanto, il calcolo non dipende dall'ambiente in cui viene eseguito: fornirà lo stesso risultato ovunque.
Pianificatore Watcher (Watcher Planner) — parte del meccanismo di presa di decisione di Watcher. Questo modulo riceve un insieme di azioni generate dalla strategia e crea un piano di lavoro che determina come pianificare nel tempo queste diverse azioni e quali sono le condizioni preliminari per ciascuna azione.
Obiettivi e strategie di Watcher
Obiettivo
Strategie
Obiettivo fittizio
Strategia fittizia
Strategia fittizia usando motori di scoring di esempio
Strategia fittizia con ridimensionamento
Risparmio energetico
Strategia di risparmio energetico
Consolidamento dei 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 archiviazione
Stabilizzazione del carico di lavoro
Vicino rumoroso
Vicino rumoroso
Ottimizzazione termica
Strategia basata sulla temperatura dell'uscita
Ottimizzazione del flusso d'aria
Strategia di migrazione uniforme del flusso d'aria
Manutenzione hardware
Migrazione di zona
Non classificato
Attuatore
Obiettivo fittizio — obiettivo riservato utilizzato per scopi di test (reserved goal that is used for testing purposes).
Strategie correlate: Strategia fittizia, Strategia fittizia usando motori di scoring di esempio e Strategia fittizia con ridimensionamento. La strategia fittizia è una strategia di prova utilizzata per i test di integrazione attraverso Tempest. Questa strategia non fornisce alcuna ottimizzazione utile, il suo unico scopo è quello di utilizzare i test di Tempest.
Strategia fittizia usando motori di scoring di esempio — questa strategia è simile alla precedente, differisce solo per l'uso di un campione di 'motore di valutazione' che conta utilizzando metodi di apprendimento automatico.
Strategia fittizia con ridimensionamento — questa strategia è simile alla precedente, differisce solo per l'uso della modifica del flavor (migrazione e ridimensionamento).
Non utilizzato in produzione.
Risparmio energetico — minimizzare il consumo energetico. La strategia di questo obiettivo, Strategia di risparmio energetico, insieme alla strategia di Consolidamento del carico di lavoro delle VM (Consolidamento dei server), è in grado di svolgere funzioni di gestione dinamica dell'alimentazione (DPM), che risparmiano energia elettrica mediante la consolidazione dinamica dei carichi di lavoro anche durante i periodi di bassa occupazione delle risorse: le macchine virtuali vengono spostate su un minor numero di nodi e i nodi inutilizzati vengono spenti. Dopo la consolidazione, la strategia propone una soluzione sull'accensione/spegnimento dei nodi in base ai parametri impostati: 'min_free_hosts_num' — numero di nodi accesi e liberi in attesa di carico, e 'free_used_percent' — percentuale di nodi accesi e liberi rispetto al numero di nodi occupati dalle macchine. Per far funzionare la strategia deve essere attivato e configurato Ironic per gestire l'accensione/spegnimento della potenza sui nodi.
Parametri della strategia
parametro
tipo
predefinito
descrizione
percentuale_utilizzo_gratuito
Numero
10.0
rapporto tra il numero di nodi di calcolo liberi e il numero di nodi di calcolo con macchine virtuali
num_nodi_libero_min
Int
1
numero minimo di nodi di calcolo liberi
Ci devono essere almeno due nodi nel cloud. Il metodo utilizzato è la modifica dello stato di alimentazione del nodo (change_node_power_state). La strategia di raccolta delle metriche non richiede.
Server Consolidation - minimizzare il numero di nodi di calcolo (consolidamento). Ha due strategie: Basic Offline Server Consolidation e VM Workload Consolidation Strategy.
La strategia Basic Offline Server Consolidation minimizza il numero totale di server utilizzati e riduce il numero di migrazioni.
La strategia di 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 alla disattivazione (di default, 0, nessun limite), period - intervallo di tempo in secondi per ottenere un'aggregazione statica dalla fonte dati delle metriche (di default, 700).
Metodi utilizzati: migrazione, modifica dello stato del servizio nova (change_nova_service_state).
La strategia VM Workload Consolidation Strategy si basa su un algoritmo euristico first-fit, che si concentra sul carico di CPU misurato e cerca di minimizzare i nodi che presentano un carico troppo elevato o troppo basso, tenendo conto dei vincoli di capacità delle risorse. Questa strategia offre una soluzione che porta a un utilizzo più efficace delle risorse del cluster, utilizzando le seguenti quattro fasi:
- Fase di scarico - gestione delle risorse sovrascritte;
- Fase di consolidamento - gestione delle risorse sotto-utilizzate;
- Ottimizzazione della soluzione - riduzione del numero di migrazioni;
- Disattivazione dei nodi di calcolo non utilizzati.
La strategia richiede le seguenti metriche:
metrica
servizio
plugin
commento
memoria
none
disk.root.size
none
Le seguenti metriche non sono obbligatorie, ma migliorano la precisione della strategia, se disponibili:
metrica
servizio
plugin
commento
memory.resident
none
cpu_util
none
Parametri della strategia: period - intervallo di tempo in secondi per ottenere un'aggregazione statica dalla fonte 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: Workload Balance Migration Strategy, stabilizzazione del carico di lavoro, Storage Capacity Balance Strategy.
La Workload Balance Migration Strategy avvia le migrazioni delle macchine virtuali in base al carico di lavoro delle macchine virtuali dei nodi. La decisione di spostare viene presa ogni volta che la % di utilizzo della CPU o della RAM del nodo supera una soglia specificata. In questo caso, la macchina virtuale spostata deve avvicinare il nodo al carico di lavoro medio di tutti i nodi.
Requisiti
- Utilizzo di processori fisici;
- Almeno due nodi di calcolo fisici;
- Componente Ceilometer installato e configurato — ceilometer-agent-compute, in esecuzione su ogni nodo di calcolo, e Ceilometer API, nonché raccolta delle seguenti metriche:
metrica
servizio
plugin
commento
cpu_util
none
memory.resident
none
Parametri della strategia:
parametro
tipo
predefinito
descrizione
metriche
String
‘cpu_util’
Metriche sottostanti: ‘cpu_util’, ‘memory.resident’.
threshold
Numero
25.0
Soglia del carico di lavoro per la migrazione.
periodo
Numero
300
Periodo totale di tempo di Ceilometer.
Metodo utilizzato — migrazione.
La Workload stabilization è una strategia mirata a stabilizzare il carico di lavoro tramite la migrazione in vivo. La strategia si basa su un algoritmo di deviazione standard e determina se esiste un sovraccarico nel cluster, rispondendo con l'avvio della migrazione delle macchine per stabilizzare il cluster.
Requisiti
- Utilizzo di processori fisici;
- Almeno due nodi di calcolo fisici;
- Componente Ceilometer installato e configurato — ceilometer-agent-compute, in esecuzione su ogni nodo di calcolo, e Ceilometer API, nonché raccolta delle seguenti metriche:
metrica
servizio
plugin
commento
cpu_util
none
memory.resident
none
La Storage Capacity Balance Strategy (strategia implementata a partire da Queens) sposta i dischi in base al carico dei pool Cinder. La decisione di spostare viene presa ogni volta che il tasso di utilizzo del pool supera una soglia specificata. Il disco spostato deve avvicinare il pool al carico medio di tutti i pool Cinder.
Requisiti e limitazioni
- Almeno due pool Cinder;
- Possibilità di migrare dischi.
- Modello dei dati del cluster — modello di dati del cluster Cinder.
Parametri della strategia:
parametro
tipo
predefinito
descrizione
volume_threshold
Numero
80.0
Valore soglia dei dischi per il bilanciamento dei volumi.
Metodo utilizzato — migrazione disco (volume_migrate).
Vicino Rumoroso — identificare e spostare il “vicino rumoroso” — macchina virtuale a bassa priorità che influisce negativamente sulle prestazioni della macchina virtuale ad alta priorità dal punto di vista IPC, utilizzando eccessivamente l'ultimo livello di cache. Strategia propria: Noisy Neighbor (parametro della strategia utilizzato — cache_threshold (valore predefinito — 35), quando le prestazioni scendono al valore specificato, viene avviata la migrazione. Per il funzionamento della strategia è necessario attivare le 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 dati cluster (predefinito): modello dati cluster Nova. Metodo applicato — migrazione.
Il lavoro con questo obiettivo tramite Dashboard non è stato realizzato completamente in Queens.
Ottimizzazione termica — ottimizzare il regime di temperatura. La temperatura in uscita (aria di scarico) è uno dei principali sistemi di telemetria termica per misurare lo stato del carico termico / operativo del server. Per l'obiettivo c'è una strategia — strategia basata sulla temperatura in uscita, che prende decisioni sul trasferimento dei carichi di lavoro su nodi con regime di temperatura favorevole (la temperatura più bassa in uscita), quando la temperatura in uscita dei host di origine raggiunge una soglia configurabile.
Per il funzionamento 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.
periodo
Numero
30
Intervallo di tempo in secondi per ottenere l'aggregazione statistica dalla fonte dati metriche.
Metodo utilizzato — migrazione.
Ottimizzazione del flusso d'aria — ottimizzare la modalità di ventilazione. Strategia propria — flusso d'aria uniforme utilizzando la 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 il funzionamento della strategia sono necessari:
- Hardware: nodi computazionali <con supporto NodeManager 3.0;
- Minimo due nodi computazionali;
- Componente ceilometer-agent-compute installato e configurato su ogni nodo computazionale e API Ceilometer, che può segnalare con successo metriche come flusso d'aria, potenza di sistema, temperatura in ingresso:
metrica
servizio
plugin
commento
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Per il funzionamento della strategia è necessario un server con Intel Power Node Manager 3.0 o versione successiva installato e configurato.
Limitazioni: Il concetto non è destinato alla produzione.
Si raccomanda di utilizzare questo algoritmo con audit continui, poiché in un singolo iterazione è prevista la migrazione solo di una macchina virtuale.
Sono possibili migrazioni live.
Parametri della strategia:
parametro
tipo
predefinito
descrizione
threshold_airflow
Numero
400.0
Soglia di flusso d'aria per la migrazione Unità è 0.1CFM
threshold_inlet_t
Numero
28.0
Soglia di temperatura dell'ingresso per la decisione di migrazione
threshold_power
Numero
350.0
Soglia di potenza del sistema per la decisione di migrazione
periodo
Numero
30
Intervallo di tempo in secondi per ottenere l'aggregazione statistica dalla fonte dati metriche.
Metodo utilizzato — migrazione.
Manutenzione Hardware — manutenzione delle attrezzature. La strategia relativa a questo obiettivo è la migrazione dell'area. La strategia è uno strumento per una migrazione automatica ed efficiente delle macchine virtuali e dei dischi in caso di necessità di manutenzione hardware. La strategia stabilisce un piano d'azione in base ai pesi: il set di azioni che ha un peso maggiore sarà pianificato prima delle altre. Ci sono due parametri di configurazione: pesi delle azioni (action_weights) e parallelizzazione (parallelization).
Limitazioni: è necessaria la configurazione dei pesi delle azioni e della parallelizzazione.
Parametri della strategia:
parametro
tipo
predefinito
descrizione
compute_nodes
array
Nessuno
Nodi di calcolo per la migrazione.
storage_pools
array
Nessuno
Nodi di archiviazione per la migrazione.
parallel_total
intero
6
Numero totale di azioni che devono essere eseguite in parallelo.
parallel_per_node
intero
2
Numero di azioni eseguite in parallelo per ogni nodo di calcolo.
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.
with_attached_volume
campo
False
Falso — le macchine virtuali verranno trasferite dopo il trasferimento di tutti i dischi. Vero — le macchine virtuali verranno trasferite dopo la migrazione di tutti i dischi collegati.
Elementi dell'array dei nodi di calcolo:
parametro
tipo
predefinito
descrizione
src_node
string
Nessuno
Nodo di calcolo da cui vengono trasferite le macchine virtuali (obbligatorio).
dst_node
string
Nessuno
Nodo di calcolo su cui vengono migrate le macchine virtuali.
Elementi dell'array dei nodi di archiviazione:
parametro
tipo
predefinito
descrizione
src_pool
string
Nessuno
Pool di archiviazione da cui vengono trasferiti i dischi (obbligatorio).
dst_pool
string
Nessuno
Pool di archiviazione su cui vengono trasferiti i dischi.
src_type
string
Nessuno
Tipo di disco sorgente (obbligatorio).
dst_type
string
Nessuno
Tipo di disco di destinazione (obbligatorio).
Elementi di priorità degli oggetti:
parametro
tipo
predefinito
descrizione
progetto
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 facilitare il processo di sviluppo della strategia. Non contiene specifiche e può essere utilizzato ogni volta che la strategia non è ancora legata a un obiettivo esistente. Questo obiettivo può anche essere utilizzato come fase intermedia. La strategia associata a questo obiettivo è Actuator.
Creazione di un nuovo obiettivo
Watcher Decision Engine ha un'interfaccia per il plugin “obiettivo esterno”, che consente di integrare un obiettivo esterno, raggiungibile tramite 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 obiettivo, implementare il metodo della classe get_name () per restituire un identificatore unico per il nuovo obiettivo che desideri creare. Questo identificatore unico deve corrispondere al nome del punto d'ingresso che dichiari successivamente.
Successivamente, devi 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 compilata 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 efficacia per il tuo obiettivo. Il metodo get_efficacy_specification () restituisce un'istanza di Unclassified (), fornita da Watcher. Questa specifica di efficacia è utile nel processo di sviluppo del tuo obiettivo, poiché corrisponde a una specifica vuota.
→
Architettura di Watcher (maggiore ).
Componenti
API di Watcher — componente che implementa l'API REST fornita da Watcher. Meccanismi di interazione: CLI, plugin 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 che si occupa del calcolo di un insieme di azioni potenziali per l'ottimizzazione al fine di raggiungere l'obiettivo dell'audit. Se la strategia non è specificata, il componente sceglie autonomamente la più adatta.
Watcher Metrics Publisher — un componente che raccoglie e calcola alcune metriche o eventi e li pubblica nel punto finale CEP. La funzionalità del componente può essere fornita anche dal publisher Ceilometer.
Complex Event Processing (CEP) Engine — un motore di elaborazione complessa degli eventi. Per motivi di prestazioni, possono esserci più istanze del CEP Engine in esecuzione contemporaneamente, ognuna delle quali elabora un determinato tipo di metriche / eventi. Nel sistema Watcher, il CEP avvia due tipi di azioni: — registrare eventi / metriche pertinenti nel database delle serie temporali; — inviare eventi pertinenti al componente Watcher Decision Engine, quando questi eventi possono 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 del testing di Watcher
- Nella pagina Optimization — Action plans errore 500 (sia su Queens pulito che su un ambiente con moduli Tionix), appare solo dopo che viene avviato un audit e viene generato un piano d'azione, la versione vuota si apre normalmente.
- Nella scheda Action details errori, non riesce a ottenere l'obiettivo e la strategia dell'audit (sia su Queens pulito che su un ambiente con moduli Tionix).
- Gli audit con obiettivo Dummy (di test) vengono creati e avviati normalmente, generando piani d'azione.
- Gli audit con obiettivo Unclassified non vengono creati, poiché l'obiettivo non è funzionale ed è destinato alla 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) si concludono con un errore.
- Gli audit con obiettivo Noisy Neighbor vengono creati con successo, tuttavia il piano d'azione non viene generato.
- Le audit per la manutenzione hardware vengono creati con successo, ma il piano d'azione non viene generato completamente (vengono generati indicatori di prestazione, ma non viene generata la lista stessa delle azioni).
- Le modifiche nei file di configurazione nova.conf (nella sezione predefinita compute_monitors = cpu.virt_driver) sui nodi di calcolo e di gestione non risolvono gli errori.
- Le audit per la consolidazione dei server (strategia Base) terminano comunque con un errore.
- Le audit per la consolidazione dei server (strategia consolidamento del carico di lavoro VM) terminano con un errore. Nei log si riscontra un errore nel recupero dei dati di origine. Discussione dell'errore, in particolare, .
Abbiamo provato a specificare nel file di configurazione del Watcher (non ha aiutato - a causa degli errori su tutte le pagine di ottimizzazione, il ritorno al contenuto originale del file di configurazione non risolve la situazione):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Le audit per il risparmio energetico terminano con un errore. Da quanto si evince dai log, il problema risulta comunque nella mancanza di Ironic, non funzionerà senza il servizio baremetal.
- Le audit per l'ottimizzazione termica terminano con un errore. Il traceback è lo stesso di quello per la consolidazione dei server (strategia consolidamento del carico di lavoro VM) (errore nei dati di origine)
- Le audit per l'ottimizzazione del flusso d'aria terminano con un errore.
Si riscontrano anche i seguenti errori di completamento dell'audit. Traceback nei log decision-engine.log (stato del cluster non definito).
→ Discussione dell'errore
Conclusione
Il risultato delle nostre indagini di due mesi è stata la conclusione chiara che, per ottenere un sistema di bilanciamento del carico completo e funzionante, dovremo concentrarci sul miglioramento degli strumenti per la piattaforma Openstack.
Watcher si è dimostrato un prodotto serio e in rapida evoluzione con un enorme potenziale, il cui utilizzo completo richiederà un grande e serio lavoro.
Ma di questo - nei prossimi articoli del ciclo.
Fonte: habr.com
